Inside TFS

Branch By Release in TFS 2010 - Part 2

Mickey Gousset shows us how to implement Branch By Release merges using TFS 2010, and some new visualization features.

• By Mickey Gousset
• 09/18/2010

In our previous column on Branch By Release using Team Foundation Server 2010, we discussed the theory around Branch By Release, its merging patterns, and how to implement it using Team Foundation Server 2010. In this column we are going to build off the previous column around Branch By Release, by showing how to forward integrate bug fixes, as well as look at some of the different branch visualization options available in Team Foundation Server 2010.

Forward Integration of Bug Fixes

In Figure 1, you can see the general pattern for how bug fixes are merged from one release to the next using the Branch By Release pattern.

[Click on image for larger view.]

Figure 1. Branch By Release Merge Pattern.

Let's look at how, building off the branches we made in our previous article, we can implement this merging process. For this scenario, we have moved our Release 1 code into testing, so we have branched our code into Release 2, to allow the developers to continue working on the next release. While testing Release 1, we have found a bug and fixed it on the Release 1 branch. We now need to Forward Integrate, or merge, this bug into Release 2.

In Visual Studio 2010, in Source Control Explorer, right-click on the Release 1 branch, and from the Context Menu select Branching and Merging | Merge. This opens the Source Control Merge Wizard window, shown in Figure 2.

[Click on image for larger view.]

Figure 2. Source Control Merge Wizard -- First Screen.

In this window you can select the source and target branches for your merge process, as well as how to specify what changes you want to merge. For this scenario, Release 1 is the source branch, Release 2 is the target branch, and we want to merge all changes up to a specific version, so we will take the defaults on this page and click Next.

On the next page of the wizard is where we select exactly what version of code we want to merge, as shown in Figure 3.

[Click on image for larger view.]

Figure 3. Source Control Merge Wizard -- Screen 2.

As you can see, we have several different options, including merging the latest version of the code, merging a particular changeset, merging by date, or by label. Again, for this scenario, we want to move the latest version of our code from Release 1 to Release 2, as it will contain the bug fixes. Select Latest Version from the drop down list box and click Next. Then click the Finish button to perform the merge.

In this example, there were no merge conflicts, so the merge was performed automatically. However, as with when we created the branch, the merge itself happens locally in your workspace, so we still need to check our changes into Team Foundation Server to finish the merge process. In the Pending Changes window (shown in Figure 4) you can see the file waiting to be checked in. Notice how it is marked as "merge, edit", indicating this file is part of a merge process. Click the Check-in button to move the changes into Team Foundation Server and complete the merge process.

[Click on image for larger view.]

Figure 4. Pending Changes Window.

Admittedly, this is a rather simplistic merge example. We will look at some more complex examples, as well as how to deal with merge conflicts, in future columns.

Branch Visualization
Most version control systems do not provide a nice way to show the relationships between different branches, i.e. which branches are parents or children of other branches. In earlier versions of Team Foundation Server, you could right-click on a branch, go to its Properties window, and one of the tabs would show some branch information, which was better than nothing, but still not ideal. With Team Foundation Server 2010 though, branches are now first class citizens, and as such, have new visualization around them, making it very easy to see the parent-child relationships.

In Visual Studio 2010, in Source Control Explorer, right-click on the Release 1 branch, and from the Context Menu select Branching and Merging | View Hierarchy. This will open a new tab in Visual Studio, showing a branch visualization (Figure 5).

[Click on image for larger view.]

Figure 5. Branch Visualization.

As Figure 5 shows, Release 1 is the parent branch of Release 2, and Release 2 is the parent branch of Release 3. This diagram shows us quickly and easily the relationship between the different branches. From this window, you can save this diagram to an image file for distribution, customize the view to show only specific aspects of the branching hierarchy, navigate to the branched code in Source Control Explorer, compare branches, and even create new branches.

Changeset Visualization

Another new visualization added to Team Foundation Server 2010 is the ability to view which branches a changeset has been merged to. To get started, select a file or folder in Source Control Explorer, right-click on it, and from the context menu select View History. This opens the History tab in Visual Studio, showing you all the changesets related to this file or folder (Figure 6).

[Click on image for larger view.]

Figure 6. History Tab.

Right-click on a particular changeset, and from the context menu select Track Changeset. This will open a dialog box where you can select the branches you want to display. Check the Check All Visible checkbox to select all the branches and click Visualize. This will create a visualization tracking the changeset across all the branches it has been merged into, as shown in Figure 7.

[Click on image for larger view.]

Figure 7. Changeset Visualization.

In Figure 7, Changeset 86 was initially created in the Release 1 branch. It was then merged into the Release 2 branch as Changeset 87, and ultimately merged into the Release 3 branch as Changeset 88. Changeset visualizations are a great way to see if a particular fix has been moved into a particular branch. You can even drag and drop changesets from one branch to another in the visualization diagram to perform a merge.

As we've mentioned, Branch By Release in its basic form is an easy to understand branching pattern with several different uses. In our next column, we are going to look at a slightly more complicated version of the Branch By Release pattern, when you would use it, and how to implement it using Team Foundation Server 2010.