3

I'm evaluating TFS as a replacement source control option for company, and documenting how our current processes would change or stay the same if we start using it.

We use labels fairly heavily in our current product, not just for creating snapshots of a given build, but also for targetting specific modifications for future builds. Our standard is to always check-in each file with a label of the release version it's intended for.

Our current software has an option for "Label" right on the check-in screen, so checkin/label is a one-step process. Is there a way to do this with TFS? I see that you can open the source control explorer and label things after the fact, but if users are going to have to go clicking around to find the right changeset to label after the fact, I want to be sure to document that...

user1221970
  • 31
  • 1
  • 3
  • 1
    How are these 'target release'-labels used later in your process? I can see a few possible alternatives, but would need to know that first. – Torbjörn Bergstedt Jul 02 '12 at 11:22
  • Probably easiest to give an example: 1.22 is in production. We start development of 1.23. At this point, all files in the project are labeled for 1.23. As changes are checked in, that label is bumped up so that at any time, anyone can do a "get" on 1.23 and compile. As delivery date for 1.23 gets closer, some tasks gets bumped to 1.24. So, all 1.23 items are ALSO labeled 1.24. The end goal is to do a grab of a given release and compile w/o fuss. It looks like the branching/merge is what I'll need to accomplish similar, but if you have other suggestions, they're welcome. :) Thx. – user1221970 Jul 03 '12 at 14:48
  • I see your point in using labels without having to "mess" with branches. If the purpose had been more of a documentational/reporting type, I would have suggested associating with work items mandatory, and then add a Release field to those WI's you would use. But that doesn't solve your issue now, so I'd suggest going by ShellShock's answer below and use a branching scenario from the guide that suits your needs. You **will** have to adapt your process, and create release branches at suitable points in time. – Torbjörn Bergstedt Jul 04 '12 at 12:17

2 Answers2

1

I'm not aware of a way of auto labelling every check in, but a couple of options spring to mind.

  • You can set up a list of text fields that must be filled in (in the check in notes section of the pending changes dialog), and even make these fields compulsory, so it would be easy to add a "for version" note to every check in. IIRC this is set up by right clicking on the team project in team explorer and going to the source control options.

  • TFS raises events for actions like check ins, so you can use the TFS api to handle the event on your server and add a label automatically. You could even pick up the check in notes to tell your code what the label should be.

Jason Williams
  • 56,972
  • 11
  • 108
  • 137
1

This may be where you need to change your current processes. With TFS (or other version control systems), all the developers targetting a particular release should all be working with the same branch in TFS, i.e., you have a dedicated branch for each parallel development stream. Thus the need for labels is reduced. This is a much better approach than using labels, because you can look at a branch and see what will be in that release, without having to sift through labels to see if a particular change applies to the release.

I suggest having a look at the Visual Studio Team Foundation Server Branching And Merging Guide.

Polyfun
  • 9,479
  • 4
  • 31
  • 39