TFS Q&A: Deleted items will not be available

We have a support library and some shipped artifacts based on .NET 1.1. The support library was reused in new components targeting .NET 4. At the moment I have a double set of csproj files based on a common set of .cs files targeting .NET frameworks 1.1 and 4, respectively. We now wish to develop further on the support library, which involves migrating the .cs files to .NET 4. This will make the .NET 1.1 csproj files unable to build.

I doubt that there will be support issues, but I still wish to retain the possibility to establish maintenance activity on the shipped .NET 1.1 product and support library.

According to page 14 on the Q&A Document on TFS Branching guide it is possible to use labels for this purpose. I can, if situation requires, branch from a label.

But then I read something that scares me a bit.

Depending on the permissions granted to specific users, labels can be modified – files can be changed, added, removed from the label. While powerful in its own respect, labels need to be used with caution given that:

• Team Foundation Server does not retain history of changes made to the label.
• Given certain permissions, labels might be deleted or otherwise invalidated by changes, and there is no way of auditing those changes.
• There can be contention for a label name as label names must be unique throughout a specified scope
• Items deleted will not be available in a label.

Does the bottom item mean that 开发者_开发技巧I must, for all foreseeable future, avoid deleting files requiring to build the .NET 1.1 version? Because part of this effort is the cleanup of double set of files. Or was the last item referring to some special administrator privilege type of "delete" (ie a continuation of "Given certain permissions...")?

I asked the question under the Branching Guide discussion group. The answer is that the guide referred to the fact that labels are not immutable. This will prevent you from guaranteeing integrity.

The specific item which prompted my question was not referring to the ordinary action of delete while developing on the latest version of the codebase, but rather explicit deletion whilst editing the label.

In short, labels aren't tampering proof and tampering leaves no audit trail.