Sharing labels in TFS?

Question

If I've created a label in TFS, assigning it to several files, my coworkers cannot change the versions of files (nor add other files) to that label. We get this error:

TF14077: The owner of a label cannot be changed.

Researching the problem, I found this article, which states:

It is possible that a user could be allowed to manipulate a shared label in the development folder but only manipulate labels that they own in a production folder. (emphasis mine)

Try as I might, I can't find any reference to "shared labels". So far as I can see, a label must have an owner.

FWIW, what I'm trying to do is employ a "floating" label so that developers can indicate that their code is ready to become part of the build by tagging it with a particular label. Then the build process would just need to get everything having that label, and automatically get the most recent stuff that's actually ready to be built, ignoring both past versions as well as newer stuff that's not ready for prime time.

---

Update: I figure if I can't make a truly shared label, I can at least give users the right to edit labels created by their coworkers. This is pretty explicitly supported. Regular Contributor users don't have this right, but according to MSDN (see article Team Foundation Server Permissions, under Source Control Permissions), it can be granted by way of the LabelOther permission:

Source control permissions are specific to source code files and folders. You can set these permissions by right-clicking the folder or file in Source Control Explorer, clicking Properties, and on the Security tab, selecting the user or group for which you want to change permissions, and then editing the permissions listed in Permissions. You can set these permissions by using the tf command-line utility for source control.

...

Administer labels | tf: LabelOther | Users who have this permission can edit or delete labels created by another user.

So I've assigned that right to the Domain group that contains all the developers, as suggested above. I can verify that it's set using the tf permission command:

tf permission /group:"CORP\Web Team"

and the result is as expected (I also assigned Label, just for fun)

===============================================================================
Server item: $/Test1/TeamBuildTypes (Inherit: Yes)
  Identity: CORP\Web Team
    Allow:
    Deny:
    Allow (Inherited): Label, LabelOther
    Deny (Inherited):

Yet my test user still is not being allowed to edit a label I created.

Answer 1

Would shelve sets be a better solution for what you are doing? IIRC there is a fairly rich API for working with shelve sets such as committing them as part of a build (or other) process.

I found labels in TFS to be very limited when I used it.

Answer 2

I never was able to make this work with labels. Instead, we devised a whole different process using branching, which I now strongly recommend to anyone reading this.

We set up a branching scheme so that there's a general development branch; from that, each developer has his/her own branch with which they can do what they want, and there's a Production branch.

• Developers do their "dirty" work in their private branch without fear of accidentally releasing stuff, or even interfering with their coworkers.
• When they've got something ready to integrate they merge the changes into the development branch. We do continuous builds there, and test the results.
• When an integrated build is fully tested and ready for deployment, the changes are merged to the Production branch. This is built and deployed.

I had said I wanted

what I'm trying to do is employ a "floating" label so that developers can indicate that their code is ready to become part of the build by tagging it with a particular label.

The scheme that I outlined above fully achieves this, and more.