Last week I responded to a post by Martin Woodward on how he approached the complexities of branching within Team Foundation Version Control (TFVC). Martin posted a comment on my the tail of my post suggesting that I provide some more detail about my approach. I thought the easiest way was tell a bit of a tale of the life of a product under version control. Once upon a time . . .

Starting Simple

My approach assumes that most teams are going to simply start using Team Foundation Version Control in the most obvious way. That is - after they create a team project they are going to check-in a solution, probably of the same name. In this case a team project called “MyApp” has been created and a solution called “MyApp” has been added to the area that was created.

Many projects hosted in Team Foundation Server will probably never evolve past this point because they don’t do any concurrent development streams and the size of the team doesn’t warrant branching off from the trunk to evolve any significant part of the code base. Some times however, do need to branch off to do development work whilst keeping the main trunk stable.

In this case the team branched off on a per feature basis using the naming convention “MyApp-FeatureX” where “FeatureX” could be anything you like, although its a good idea to make it descriptive.

When branching of this nature is done its good to keep a handle on code changes that are being made to the main trunk because at some point you are going to need to reverse integrate and the more changes that have been made to the trunk since the branch the harder its going to be. The way to mitigate this is to frequently forward integrate from the trunk onto the branch.

Driving to Release

At some point a project is going to have to ship some code. Sometimes this can be a challenge, especially when you are only shipping pre-release versions and you still need to continue doing feature development whilst trying to get stable enough for end users to try out. Branching can help here by branching off the codebase and stabilising on the branch whilst feature development continues on the trunk (or feature branches).

In my approach to branching the final release of the code is actually made from the trunk but you could conceivably make it from another branch. Either way you need to carefully control commits to the code base at this point to ensure that nothing slips in that you didn’t expect – using permissions to lock the final release branch/trunk down and only giving a few people access is a good way of doing this.

Ding Ding, Round Two!

One of the things that I think a lot of teams fail to do is adequately plan for how they are going to manage code in subsequent versions of the product. Fortunately TFVC helps us out here by creating top level areas. When we create the next versions Team Project we simply point to the previous top level area and tell it to create a branch.