Drill through merges in TFS2010

January 5, 2009

In the current available versions of Team Foundation Server [TFS2005 and TFS2008] it’s hard to look up changes that originated in another branch. Let me explain this by an example.

I have a Main branch and two feature branches that were both branched from Main. Now let’s assume certain changes are made to FeatureBranch1. These changes are merged (reverse integration) to Main and at a later stage a release branch (1.1) is split off to the Release folder (from Main). Some time later the code file is being inspected in the 1.1 branch (release folder) where the code change of FeatureBranch1 was executed. In the Annotate window [a new feature in TFS2008] you would be able to see that on line x a change was made by person y on time z. So far so good! The question that now pops up is : “What do you really want to see in the changeset details?”. The best answer of course is that you immediately want to see that those changes originated from the FeatureBranch1, but at this moment TFS2008 won’t provide you with this information. You will have to manually drill down the branch hierarchy to find out that this change came from a check-in into the FeatureBranch1 by person x. TFS 2008 only gives you the information (via the annotate feature) that the change came from a merge (Main branch). This is not ideal, because you will have to step into the history and dig deeper to find out the original changeset in FeatureBranch1.

TFS 2010 will come to the rescue in the future and will provide you with the details you are really looking for in that type of situation. In the tooltip of changeset 74, TFS drills down through all merges and loads the details of the initial check-in at FeatureBranch1. Note that the screenshot is taken in the source of code in the 1.1 release branch.

Right-clicking on the changeset 74 hyperlink will even give you the option to view the original changeset details of the FeatureBranch1 check-in or to view the history …

The history window as seen above will now give you a hierarchical view on how the changeset came into the release 1.1 branch. To top it off, you can also track the 74 changeset visually by right-clicking …

The first view in the screenshots below is a timeline view where you can follow the merge history of changeset 74 and the second view is a hierachical view where you can detect the hierarchical dependencies between branches.

Very nice features I wish I had already at my disposal right now …

Branches in TFS2010

December 21, 2008

Let’s face it : managing branches and controlling the merge activities in Team Foundation Server isn’t optimal for the moment and it takes some effort to know what’s going on in a Team Project. At least development teams should enforce the most appropriate branching & merging strategy at the start of their project, but TFS could definitely do a better job in helping to control this complexity.

One of the features of TFS2010 I like a lot and can’t wait to make use of in the future is the improved support for parallel development. In this post I would like to highlight the way branches are treated in TFS2010 …

First of all, branches will be treated as first class citizens. If you look at the next screenshot you can see that branches are now differently displayed in the Source Control Explorer with another icon.

Branches may be organized in folders and each branch has now its own special properties :

  • General Branch Properties

  • Relationships

  • Permissions

Conversion to branches/folders can be executed via the context menu in the Source Control Explorer.

In a next post I’ll start exploring the new branching and merging possibilities, but before I close this post I would like to point you to the new TFS Branching Guide (2.0) that was recently released and contains a lot of essential information how to choose the best strategy for branching (and merging) your Team Projects. I like the way Jeff Beehler stressed the importance of having such a strategy :

Selecting the right branching strategy is one of the most important aspects of TFS deployment. Picking the right strategy can lead to optimized team cooperation, increased productivity and a successful adoption. On the other hand, selecting a bad branching strategy can cause frustration, damage productivity and derail TFS adoption in an organization.