Labels and branches in Team Foundation Server

December 5, 2007

(This post comes with a TLDR warning)

In one project, we’ve just moved from Visual Source Safe (VSS) to Team Foundation Server (TFS) and its source control. The most confusing thing to me so far has been the difference in how labels behave. Whereas in VSS you could mark your files with a label and then easily see what changes have been made to them afterwards in the history, the TFS labels don’t even show when you click “View history”. I found this very hard to get my head around. We had been using labels to mark releases, which made it easy to see what code was in production and so on. It seems as though labels in TFS aren’t point-in-time labels the way they are in VSS. For understanding this, I recommend the excellent post Why TFS labels aren’t like SourceSafe labels from bharry’s WebLog.

Let’s say you’ve got the three environments: development, test and production. The best way to handle things (at least when there is only a small number of developers) seems to be to create two branches in TFS: one that contains the code that is in production and one that you are developing new features on. This way you can switch to the production branch and make changes that require little testing before releasing, in case there are any urgent bugs that need to be fixed. After that you merge the bug fixes into your development branch. This way you don’t have to test every new feature in order to get a new bug fix out quickly.

I know this differs a lot from the proposed “Single release scenario” in the Microsoft paper Team Foundation Server Branching Guide, where they have four branches. But I want to keep the number of branches at a minimum in order to reduce complexity.

I thought about creating a new branch for the testing environment, so that you know what code is there and you can continue developing new features while the testers get to work. If they give a green light, you just release the test branch code to production, and you don’t have to worry that any untested code from development leaks through. However, after talking to the very knowledgeable Magnus Timner (TFS certified) of Transcendent Group, I realized you can accomplish this with labels. This way you don’t have to have a separate test branch all the time, which should minimize the dangers of synchronizing between branches and merging problems etc.

Whenever you release something to test, just label the code in your development branch. When the testers give a green light you can either take your development code (if no changes have been made) or create a new temporary branch from the label which you can release. After that, merge it into the production branch and delete the temporary branch.

If your testing cycles are longer than a few days, labels might not be the way to go though. I quote the aforementioned document:

“While powerful in its own respect, we’d like to caution against the over-use of labels given that:

  • Team Foundation Server does not retain a history of changes made to the label.
  • Given certain permissions, labels might be deleted or otherwise invalidated by changes, and there is no way of auditing those changes.
  • There can be contention for a given label if more than more person wants to use and modify the label or the files contained in the label.

As such, we recommend using labels only in cases where you need a snapshot of sources for a short duration of time or if you can guarantee via permissions that the label won’t be changed.”

What do you think? I’m only beginning to learn the TFS way, so I’d be more than happy to receive insightful comments.


3 Responses to “Labels and branches in Team Foundation Server”

  1. You seem to be heading down the right path. I have found that it is best to have a Mainline and use it as an Active Development Line while creating Release Lines to be able to handle hot fixes and maintenance releases. If you want to learn more of (vendor independent) branching and other software configuration management best practices I can really recommend Steve Berczuks and Brad Appletons book “Software Configuration Management Patterns: Effective Teamwork, Practical Integration” ( If you’re interested I can bring it the next time we hook up for lunch. ;-)

  2. microserf Says:

    You bet!

    And bring some other books as well, I need stuff to read when I’m back up north for christmas.

  3. […] deleting the label if the build failed (in essence rolling back our changes). Due to the way TFS handles labels, we could check in Assembly.cs with the updated build number and get it included in the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: