35

I am trying to come up with best practices regarding use of TFS source control. Right now, anytime we do a build, we label the files that are checked into the TFS with the version number. Is this approach better or worse than simply checking the files in and having the version number in the comments? Can you then use the changeset to go back if necessary or the labels are still more versatile?

Thanks!

laconicdev
  • 6,360
  • 11
  • 63
  • 89

4 Answers4

35

They have two different purposes, ChangeSets are when the files have actually changed and you wish to keep a permanent record of that change. Labels mark a certain version of the files so that you can easily go back to that point. Unless your build actually changes files under source control and you wish to record these changes. You should be labeling.

Also, labeling is much less resource intensive. And you can have multiple labels on the same version of a file.

Alex
  • 12,749
  • 3
  • 31
  • 45
  • 17
    Labels can be scary, they can be applied to only part of the codebase, they can be changed after the fact and they can be deleted. The CS number is a constant. It can't be changed, should always get the latest version (unless the TFS Administrator used Destroy to delete files from source control, which a label can't restore either). In my experience, a label is nice since you can give it a human readable name and can be searched. The CS number works just fine as an alternative. – jessehouwing Feb 13 '13 at 10:24
  • Labels are nice until you realize that the changeset that they refer to is not the last changeset when you applied the label. Can somebody explain this? – toscanelli Jul 30 '18 at 14:52
7

You should label the versions of source files that make up your build. If you're using TeamBuild, it does that for you automatically. It combines the name of your build definition, date, and the build number. So you don't need to do anything.

Your other option is not very conventional and requires a lot of unnecessary work. If I understand it correctly, you would check out your source files during the build process and then check them back in with a version number specified in the check-in comments. This is as Alex mentioned very resource intensive in terms of your build process and also your source control repository. Moreover, how would you get the source files for a particular version if the version information is embedded in the comments? It will be very hard and you would have to sit down and write your own application that uses TFS source control api to download the source files to a workspace by searching for the version number in the check-in comments. This creates unnecessary complexity and headaches.

If you use labels instead, you can do a get by label in VS IDE to download the source files that make up that label. You can even tell TeamBuild to use a label instead of downloading the latest source files during build automation. That way you can build previous versions of your application easily. With labels, you can also apply later changesets to an existing label if there were code changes by simply getting that label and then getting specific changesets and then doing a quick label or creating a brand new label.

Labeling is very powerful, convenient to use, and is a part of TFS. Rather than coming up with your custom solution that requires a lot of effort to make it work and maintain, just try to use what's already available.

Mehmet Aras
  • 5,284
  • 1
  • 25
  • 32
3

Right now, anytime we do a build, we label the files that are checked into the TFS with the version number

You don't need to do this. TFS can refer to a state of the codebase in numerous ways, of which labels are indeed one - but so are builds and even changesets. You can see the available ways to reconstruct a particular point in time by doing a Get Specific Version... and examining the options in the Type dropdown:

Changeset
Date
Label
Latest Version
Workspace Version

Changeset allows you to get just after any changeset; Date is obvious; Label is too, except that builds automatically* create labels (choose Label from this dropdown then have a look in the Find Label dialog).

*I think it's automatic! Unless it's something we've set up specially where I am at the moment...

AakashM
  • 62,551
  • 17
  • 151
  • 186
  • 3
    Team Build can label automatically, when you choose the option in the Build Definition settings (under the advanced section). – jessehouwing Feb 13 '13 at 10:22
1

StackOverflow won't let me comment on the answers above, so I'm writing this as a new "answer". I want to clarify some of the misconceptions listed above.

First, using TFVC Labels is MORE resource intensive than using changesets. A lot more. Commands such as Branch, Merge, and Get by Label is slower. For enterprise servers with huge databases you do not want to be using labels.

Second, Builds don't automatically create labels, although the default build steps include a step to create a label.

Third, as others already mentioned, labels can be moved or deleted, so they are much less dependable than changesets which are immutable.

Overall I recommend you NOT use labels. The simplest alternative is to just remember the changeset number for your builds. Or if you want to isolate different release versions, you should create release branches.

Labels are OK for small systems, but are not good for large enterprises.

Will Lennon - MSFT
  • 41
  • 2
  • In our setup, we have the Build process on the VSTS agent create a Label on that version of the code after the build is successful. This doesn't mitigate the performance issues you've talked about, but does make Labels more reliable in that they are referencing something just as permanent and definitive as a Chanset number. It allows us to easily find the version of the code included in a Build, but if someone edited or deleted the Label, it wouldn't be a disaster. – Philip Stratford Aug 22 '17 at 14:18
  • Did you mean "it _would_ be a disaster"? Because, as long as the build key is **immutable**, as Lennon said, the build is reliable. Label is not, while the ChangeSet is. – Noble Feb 21 '20 at 22:08