I'm currently trying to eliminate the need for check in comments in TFS 2010 as the information about each change we make is already documented within an associated work item. The only issue with this is when you look at the file change history, the "Comments" column is blank thus making it difficult to find the change you are looking for.
To resolve this we enter the name of the work item in the check in comments but I am wondering if there is a way that I can have TFS automatically do this.
For example:
If I have a Change Request work item called "Add New Feature 1" and I check in the changes against this, I would like the check in comments to automatically have "Add New Feature 1" included in them.
Anyone know if this is possible and if so how I can accomplish this?
Thanks
You'd need to either write a Server Plugin or maybe a policy (not sure if policies can change the checkin comment though).
Checkout the following plugin which associates workitems based on the checkin comment.
http://embeddedworkitems.codeplex.com/ It's the reverse of what you want but should be adaptable.
Related
Disclosure: Newbie with TFS and couldn't find useful SO answers
A coworker submitted a bunch of changesets to source control -- Can I just get the most recent one to get all of his changes? Or would I need to get each one individually? In other words, do changesets compound?
And more generally, what's the easiest way to ensure my local repo is identical to the server repo (minus the new things I'm working on).
I'm much more familiar with Git if that would help explain this
With your source control set to TFS in VS (Tools > Options...) just right click on your project file in Solution Explorer and select Source Control > Get Latest Version (Recursive). I do it twice just to make sure I get a message saying "up to date".
You can also use Source Control Explorer and get a specific changeset by right clicking the change set and selecting a similar option, and yes, these will get all changes up to the one you clicked.
Edit:
A little confused rereading your title it sounds like you want the server to match local, then your question is about matching your local to the server. So let me address both.
To get the server to match your local this would be most like a "Check in" (or 'push' in Git) this will merge your files into the server. You can perform a check in by clicking the Team Explorer tab and selecting "Pending Changes" then type a description and click "Check In". Where there are conflicts your will be notified and asked how to proceed, but in most cases following best practices this will not be the case.
Then you will want to match your local with the server (basically a 'pull' in Git) by right clicking the project file and selecting 'Get Latest Version (Recursive)'
Hope this helps.
I want to use the TFS 2013 Code Review system to ask a colleague to have a look at the current or latest version of one specific file. I cannot seem to find an option to do so. Is this possible?
I've tried:
Right-clicking the file in Solution Explorer, checking the Source Control context menu, but the option to ask for a review is not there;
This solution from a blog where you request the review from a file's "View History" overview, but this ended up sending a review for the entire changeset instead of that one file;
Opening the file and right-clicking the tab header, but no Source Control options are available in that context menu;
Check out the options in the Team Explorer, but I couldn't find an option to do what I want;
Is it even possible to request a Code Review of one specific file?
Check the file out and in Pending Changes exclude everything else, leaving just the one file. Then from Pending Changes window => Actions => Request Review but this obviously won't highlight your changes as I'm assuming they have already been committed.
I don't want to use only Tasks in TFS Some times a Bug or a backlog Item are so small that there is no need to create tasks underneath it. HOw do i automatically make it Mark the Item as done in tfs when i check it in.
There is no way for me to make it relative in this case. Because it is a backlog Item as opposed to a Task.
Does anyone have a way to make this work?
If you use visual studio to checkin then it asks for a comment and a work item to associate with the checkin. There is a area where you can provide the state of workitem as Resolve or Associate after this checkin happens you can put the state to resolve it would mark the item as done.
In TFS how do I link a changeset with a work item? In other issue trackers, you can do this through the comments (for instance JIRA):
"Fix for bug-1234. Had to add document ready."
The issue tracker will then add this changeset to the history for work item bug-1234, and the changeset history can be viewed in the issue tracker UI.
Does TFS support anything like this? I haven't been able to find any clear links. Note that I am looking to link a TFS work item to a changeset and not to link source to a work item. I am aware of a Product SourceLinks that does and have already started using it.
When you check in code the check-in dialog allows you to select a Work Item (Task, Bug, etc. ) That Work Item will be associated with that check-in/changeset. [every check in creates a changeset]
Then when you view the Bug details you can see all the links/associations:
Is there a way to Link a WorkItem to a Label. Under "All Links" when I create a new WorkItem in Visual Studio I can select many diffrent Link Types, like Changeset, VersionedItem, etc, but theres no type for Label.
The reason why I want to do it is, that I label my releases (like Version 1.0, Version 1.1) and I want to associate a Bug to a specific version of my software.
Isn´t it support to link a WorkItem to a Label or how should I associate a Bug to a version of my software?
Update:
I´m following the Single Team Branching Model (one Dev and one Main branch) documented in the Visual Studio TFS Branching Guide 2010.
You cannot link to a label. However you can achieve your goal in other ways.
First of all, I suggest to use branching instead of labelling to keep track of multiple released versions. In my opninion using branches is a better mechanism then labelling. See also the branching guidance on codeplex
To link your bug to a version of your software, use the Iteration Path in the work item. This field is exactly for that purpose.
Using iteration path field is one option and it gives you the ability to track a work item between versions.
But if you want higher resolution, there is another way:
Team Build marks source code with a label before every build. The bug item type in CMMI project template contains fields called "Found In" and "Fixed In". In these fields you can select from build labels.
Use of these fields allow you to mark any work item with two specific builds. One for when it was found and one for when it was fixed.
Additionally Team Build updates "Fixed In" field of every work item with the label of the build, after the build completes successfully and all tests are ran without a problem.
If you don't have these fields on your work item type, you can always add them using the work item template editor that comes with TFS Power Tools.