Merging Work Items in TFS 2010

In TFS 2010, branching and merging have been greatly improved with support for branch visualization and tracking of changesets and work items across branches. A simple example of this looks like this:

image       image

Here we track Work Item nr 3 which was originally resovled in the Test branch (with changeset 35). We can also see that the work item has been merged into the Production branch (as changeset 37), back to Main (62) and finally to FeatureC (140).
If we switch to the Timeline view, we get a nice view of the order of these merges, together with the dates.

 

Unfortunately, this does not solve one of the bigger problems when it comes to branches and work items. When you merge your changes into another branch, you must remember to asociated the corresponding work item again, otherwise that information is lost and the work item will not show up in the build report from the builds running off the target branches. A typical example is that we have 3 bugs in the Test branch, and we perform (at least) 3 changesets and each changeset is associated to the corresponding work item. When it is time to merge the bug fixes to the Production branch, we must manually associated the merge with the work item again. If we peform one merge operation that brings all changes from Test to Main, we must associate all 3 work items. There is really no support for “merging” work items across branches in TFS, only changesets can be merged.

What you really want is to have the tool automatically assign the work items that were associated with the changesets that you are merging. One way to implement this is with a checkin policy, which we have done at our company. The reason for choosing a checkin policy as the tool of choice is because it is executed on the client at the time of the checkin, and we can display the work items to the developers before they check in.

So, how does it work? Lets look at an example:

In my development branch, I have 3 bugs (Bug1, Bug2 and Bug3) that I need to fix. I fix each one in a changeset that gets checked in and associated with the corresponding work item. Then it is time to merge the fixes to the Main branch (trunk).
I perform a merge by just using the normal Merge operation from source control. This leaves me with the following pending merge:

clip_image002

 

Now, I would normally go to the Work Items tab and link to the work items that I know were resolved by the changes that I am currently merging. But now I don’t need to do this but instead I just click on the Check In button. This will evaluate all checkin policies, and one of them is the Merge Work Items policy that pops up the following dialog:

clip_image002[5]

This dialog shows me a list of the work items that were associated with the changesets that I am currently merging in. The checkin policy uses the TFS Version Control API to locate the merge sources of each pending merge item and basically shows the union of these work items (several changesets can be associated with the same work item). If I check in now, the changeset will automatically be associated with these 3 work items! The beauty of this comes when running the builds off the Main branch, the build summary show me that these 3 work items have been resolved in this build:

 

image

In another post I will show the interesteing parts of the implementation

0 thoughts on “Merging Work Items in TFS 2010”

  1. Originally posted on: http://geekswithblogs.net/jakob/archive/2010/10/27/merging-work-items-in-tfs-2010.aspx#544831

    You could also create a workflow activity that will look at the associated changesets and check to see which changesets were merged into it and grab those work items. You can do it recursively even across multiple branches if you wanted to.

    I have done this to create release notes in the MAIN branch’s build to get the original changesets with the original work items that were associated with them. This prevents you from having to associate merge changesets with the original work items.

    Also – Track Changes on the Work Item (right-click work item form and choose Track Work Item) works correctly without having to associate merge changesets with the work item as well.

    Reply

  2. Originally posted on: http://geekswithblogs.net/jakob/archive/2010/10/27/merging-work-items-in-tfs-2010.aspx#544912

    Cheers Ed, I have actually included this functionality in a custom build activity as well. I wanted to try to use a checkin policy first to see how it works, but we might move to a solution where this is done by the build instead. What I like about this solution is that you get confirmation about the changes that you are currently merging before checkin in. Often the changeset information is not enough.

    Reply

  13. Originally posted on: http://geekswithblogs.net/jakob/archive/2010/10/27/merging-work-items-in-tfs-2010.aspx#624657

    Hi Jakob,

    After searching the net for a long time,most of the links are pointing to your blog so I here I am requesting for your help in similar scenario.

    We have a Development branch
    – Group1 branch created from Development
    – Group2 branch created from Development

    Now when I am trying to merge my changes i.e. Source as Group1 I get 2 options to select Target location which is Group2 and Development

    I want to create some custom check in policy or something like that which will restrcit to merge in Development from Group1 I want to force the user to merge into Group2 only and from Group2 to Development.

    I have crated the structure of my check in policy but not sure what condition to write to get this check..Any help is really appreciated.

    Reply

Leave a Reply

Your email address will not be published.