Hi,
I'm searching for the best way to lock a certain label.
I would like to realize a code freeze with TFVC. What I mean is that at a certain point of time no one besides the administrators of TFVC can move, delete or set a certain label.
On our ClearCase system this is done right at code freeze during a stabilization phase when no one should be able to add any changes to the code marked with the night build label. While no changes are submitted errors can be solved and the version can be stabilized. As soon as the version is stabile the label is free again and can be used again.
I hope this draws the picture of what I'm looking for good enough. Pls let me know if not.
Tom
Locking a Label
CorneVR
Hi Tom:
Team Foundation Server by default locks the label use to those users who are given that permission by the project administrator (this is done by enabling Allow for the Label Permission). Past that requirement, you also have the fact that to modify or delete labels only the owner or the users who have Administer Labels permission are allowed those operations.
So in short I think that we pretty much lock it by default and the only thign you need to be careful of is the users that have Adminsiter Labels permissions. If possible also have those users create these labels so the owner permission becomes a no issue.
If you would like to read more about labels follow this link: http://msdn2.microsoft.com/en-us/library/9ew32kd1(d=ide).aspx
Thanks, mario
Jonas Beckeman
thanks for your answer. As I put some more thoughts into what it means to use labels the way they are commonly unused in CC I got a better picture. I would like to point out my thoughts and maybe get some feedback on them.
Many teams base their nightly builds upon a certain label that indicates to use this version of the file for the nightly build. In many instances this necessary because there exist later versions of that particular file. These versions include further developments and changes. The reason why those versions are not wanted in the nightly build is that they will brake the build, e.g. for not yet existing references, changes in interfaces, etc.
This seems to be a bad practice. As mentioned in several places one should have a least one DEVELOPMENT branch. Right after a file is added to source control a branch should be added for developing purposes. Whenever made changes are ready for nightly or continuous builds the DEVELOPMENT branch can be merged into the MAIN branch. From this point of time the changes will be in effect and included in the automated build process.
Whenever a milestone version is reached it can be labeled. No one of the development team should be allowed to move or delete this label except the team or project leader. This can be realized on several ways. Easiest would be that the label is placed in the first place by someone with the permission to set or change those label if needed. If handled this way you don't have to think about how to lock a label as I did when posting my original question.
One might think now, but what if we add more files to the DEVELOPMENT branch - do we have to add them also in the MAIN branch. Thanks to the guys from Microsoft - it's all taken care for. You simply add your files to the branch you are developing your code and whenever you merge back to your MAIN branch the file will be added to it. The convenient thing about it - all files that are merged are in a checked out state after the merge. This gives you the chance to test your code before you submit your merged changes to the MAIN branch. You use check-in pending changes just as if you had made code changes directly to the MAIN branch.
You can keep on working on your DEVELOPMENT branch after the merge to the MAIN branch - it is still there. Whenever you are ready you can do another merge to the MAIN branch to get the code into the nightly or continuous build process of your team.
Feedback and comments on this strategy are welcome. I hope this explains how one can avoid the need for moving labels around and locking them so they are not moved around any more.
Tom
Deb Magsam
powerful than VSS labels -- they can hold any set of [file, version]
pairs – but they’re still not as powerful and not nearly as convenient
as branches. In practice, the fact that TFS has atomic checkins means
that a Changeset (or Date) versionspec is precise enough 99% of the
time.
At least in our tools, using labels for code promotion sounds tedious
and risky. With branching, it’s always clear which code is going where:
you don’t have to rely on users specifying a special label during every
Get operation just to avoid breaking changes.
A code promotion model can have as many levels as you want, and can
include automated/rolling builds at any point. For example, let’s say
you had a 3-stage promotion:
Main/Production
|----- Test
|------- Development
Some teams might decide that “Dev” should be considered highly unstable,
to the point where builds might not always work, i.e. only Test and Main
do nightly builds. Personally, I think any branch used by >1 person
should have a minimum quality bar, an automated build process, and
hopefully some automated tests. Those practices become exponentially
more important higher up in the promotion model.
To add a 4th level of promotion (Private/Unstable) you can simply use a
workspace. In that case “Forward Integration” from its “parent branch”
is just a matter of running Get. Keeping important work in a local
store isn’t a good option on some source control systems, but in TFS
shelving makes it feasible: shelvesets are an easy and safe way to store
backups and submit code reviews / buddy builds. Of course, you can
always create an actual private branch if you want.
These are big, overlapping topics. Hope my rambles help.