We use a lot of of python to do much of our deployment and would be handy to connect to our TFS server to get information on iteration paths, tickets etc. I can see the webservice but unable to find any documentation. Just wondering if anyone knew of anything?
Shelving has many uses. The main ones are:
- Context Switching: Saving the work on your current task so you can switch to another high priority task. Say you're working on a new feature, minding your own business, when your boss runs in and says "Ahhh! Bug Bug Bug!" and you have to drop your current changes on the feature and go fix the bug. You can shelve your work on the feature, fix the bug, then come back and unshelve to work on your changes later.
- Sharing Changesets: If you want to share a changeset of code without checking it in, you can make it easy for others to access by shelving it. This could be used when you are passing an incomplete task to someone else (poor soul) or if you have some sort of testing code you would never EVER check in that someone else needed to run. h/t to the other responses about using this for reviews, it is a very good idea.
- Saving your progress: While you're working on a complex feature, you may find yourself at a 'good point' where you would like to save your progress. This is an ideal time to shelve your code. Say you are hacking up some CSS / HTML to fix rendering bugs. Usually you bang on it, iterating every possible kludge you can think up until it looks right. However, once it looks right you may want to try and go back in to cleanup your markup so that someone else may be able to understand what you did before you check it in. In this case, you can shelve the code when everything renders right, then you are free to go and refactor your markup, knowing that if you accidentally break it again, you can always go back and get your changeset.
Any other uses?
Here's what you should do:
- Open the Visual Studio Command Prompt. This will give you a command line window with the PATH set to run VS / TFS tools
Download the Work Item Type definition that you want to modify (e.g. Bug, Task):
witadmin exportwitd /collection:collectionurl /p:project /n:typename [/f:filename]
This will give you the WIT's definition, in XML format.
- Open the XML file. You will edit the rules for the Assigned To field. Find the term "System.AssignedTo"
- In the Allowed Values rule element, modify (or add if none exists) your List Item element to limit the values to members of one (or more) TFS / Active Directory group(s). Your field definition should look like this:
<FIELD name="Assigned To" refname="System.AssignedTo" type="String" syncnamechanges="true" reportable="dimension">
<HELPTEXT>The person currently working on this bug</HELPTEXT>
<ALLOWEDVALUES expanditems="true" filteritems="excludegroups">
<!-- Below is a TFS group. Note you actually type "[project]" verbatim -->
<LISTITEM value="[project]\Contributors" />
<!-- Below is an AD group. The name and group are examples only -->
<LISTITEM value="MYDOMAIN\Developers" /> </ALLOWEDVALUES>
Importing your changes:
- Save your file.
- In the command line window type the following:
witadmin importwitd /collection:collectionurl /p:project /f:filename
That's it. Your work item type is now limited to the people you want.