The what, why and how of Team Foundation Server - Part 2

In Part One of this article I talked about the TFS work item tracking feature and started looking at the version control features. In part two, I am going to continue looking at version control and introduce Team Build and the reporting facilities within TFS.

Branching and Merging Code

For teams that are supporting one or more versions of code in production, use and development of a new version of their software and the ability to maintain two separate versions of their code base is critical. Branching and merging are the tools used to make this possible and are available in most modern version control systems. Team Foundation Version Control is no exception.

TFS branching support, at least on the surface is not too dissimilar to Subversion or VSS where a copy of one part of the tree is placed in another path. For example you might branch $/DemoProject/Trunk to $/DemoProject/Branches/FeatureTeam1 so that a feature team can work on their new code without destabilising the trunk.

Creating a branch is simple; first you need to select the folder that you want to branch from (the source) in Source Control Explorer, then from the context menu select Branch. This will present a dialog that allows you to browse to or enter the specific target that you want to create the copy of the source in.

Once OK is clicked the branch is created in your local workspace and you must then go and separately check that code in. In Source Control Explorer a pending branch operation is identified by two diverging arrows.

Because branches exist in a logically separate part of the tree it is possible for a developer to work on source files in both branches at once and commit changes to the version control store which impacts both branches. While this may seem odd it makes a lot of sense when you have different versions of the code base which are being supported and a single bug fix needs to be applied across all of them.

Performing a Merge

Some say that branching is easy; it is the merge that hurts. In my opinion there is a lot of truth in that, especially if the branch exists away from the trunk for a long time. It is usually a good idea for development teams to merge code on a regular basis just to make sure that there are no nasty surprises. Activities like re-factoring in common code areas can cause problems and unfortunately there is no good way to combat this at the moment.

Performing a merge from a technical point of view is straightforward. You need to first select the branch that you wish to merge in Source Control Explorer and select Merge from the context menu; this will provide a wizard which assists with the merge process.

One thing that the merge wizard stops you from doing is baseless merges where you merge code from two locations in the source tree that do not have a direct ancestral relationship. This limitation is mostly there because it leads to complexity and then confusion, however if you do want to perform a baseless merge consider taking a look at the Team Foundation Server Power Toys.

Merge operations seldom occur without some kind of conflict (that's the whole point) and so when TFS detects the conflict it presents a dialog which allows developers to choose which changes win.

In an ideal world you could just select Auto Merge All and go and grab a cup of coffee but in my experience it is not wise to do this; the Auto Merge feature sometimes makes weird choices so I prefer to manually merge each file.

My advice for larger and complex merge operations is to take key team members away and put them in a room with a projector and a laptop and get them to perform the merge together because their collective knowledge of the code will be required.