Pages

Tuesday, June 17, 2008

TFS Labeling and Branching

I've been doing some labeling and branching in TFS lately. The difference between how labels behave in VSS versus TFS has been explored on various blogs around the net. My understanding is that VSS and TFS labels are essentially the same with one difference. TFS allows you to "move" a label after it's been established.

Basically, labeling "snaps a line" across all module generations that are to be included in the label. In VSS this is Gospel - you can't change the label after you create it. In TFS you can change what generations are in the label. For example, say you labeled everything as "V1.0" and then did some testing and found some bugs. You change a module or two and check them in which creates a few new generations. In TFS you can modify the label to include these newer generations.

Here's a diagram from Microsoft's "Team Foundation Server Branching Guidance" document:



Doesn't this changing of labels make for some confusion though?

   "I found a bug in Release 1", says my tester.

   "Which Release 1?", I ask.

Furthermore (you'll love this), TFS does not maintain any history of changes to the label. I'm not kidding. Isn't the primary purpose of source code management to provide histories for modules and versions?

I could conclude that, given VSS labels were sufficient for what they were intended, TFS labels are too - just don't change the TFS label once it's set. Remember, just because you can do something doesn't mean you should. One annoying difference is that the TFS labels don't appear in the module history. There's supposed a logical reason for this, i.e. TFS labels are "point in time". Whatever.

I'm going to pretend that TFS is labeling just like VSS and see how long I can get away with it. I'll keep you posted.

No comments: