Understanding Label Limitations

Question

A status blog

Labels come with great warning, although the labels themselves are not a controlled version, which means that there is no way to track or activity history on the label. In addition, the labels do not contain a version if the file is deleted, therefore, if the file is deleted, any label that relies on the version of this file is essentially closed.

This is not the only place I read similar information about TFS methods. The lack of history is clear enough. The second part, "Shortcuts do not store copies of versions ..." is unclear. In fact, I created a test project> tagged it> deleted file> executed Get by Label, and the file returned. So what does this mean? Has label functionality changed in TFS recently?

I understand that deleting a file does not actually delete the history, is that the reason? In other words, if I ran

tf destroy "$ / MyTeamProject / Project / FileName.cs"

Is that what file deletion means? If so, this seems an unusual circumstance even for consideration. I mean his intentional incorrigible deletion of history. Changes in this case will not be an improvement over shortcuts.

Answer 1

When we apply a shortcut, we do this up to version control version at a particular point in time. Intuitively, because we initially created the snapshot of the source control at a specific point in time, we can assume that the snapshot represents the source code at a specific point in time.

This is not true. Shortcuts can be edited after creation.

Conceptually, the label defines the correction of a product and products ( source ). A real world example can help. Let's say we have a product called AlphaBoogerBear. AlphaBoogerBear is a product, not a version (think about pre-release versions of Windows names). AlphaBoogerBear can be done in Label, AlphaBoogerBearLabel. We are releasing AlphaBoogerBear. There are some errors. We are fixing them.

Now we will go back and edit the AlphaBoogerBearLabel to include the fixes. A tag no longer represents a snapshot at a specific point in time. Instead, it is the most stable release of AlphaBoogerBear.

Finally, move on to BetaBoogerBear. We have the opportunity to go back and grab a label that represents the old product at its best in time.

In my opinion, if you need an instant copy of the version control version, it’s better to fork it. If you want an editable snapshot that represents a product release, then the shortcut is useful. Although it seems to be a difficult balance of trust and convenience.

As for the author’s intentions, I really can’t say for sure. He could say that the elements can be removed from the label, and thus, when you get the label, the element will be deleted. Although the item is still stored in the TFS history, therefore, although this is a confusing situation, not everything is lost.

Answer 2

I'm not sure what is meant by the suggestion that the tags are damaged by deleting files. But you have everything in order, the usual deletion of the file will not affect the labels, but it will destroy it.

What he warns you of that which is not version controlled is that someone can come and edit the shortcut by including or excluding files from the tag or changing the versions of the files included in the tag. And there will be no changes in the definition of the label.

Answer 3

As I understand it, a label in TFS is a set / set of change sets.

Suppose you wrote a directory with two files in it. Then the label will consist of three sets of changes: one for the directory and one for each file. Deleting one of these files in TFS will create a new set of changes for the directory, so at this point Get by Label will get the deleted file back, since it contains the set of changes before it is deleted. Destroying the file will remove it from any records in the changeset in which it appeared, which also destroys the information in the shortcut.

Since a tag is identified only by its name, it is also easy to overwrite it with a new tag, destroying the old information. The /child parameter for this command can slightly change this behavior: with /child:merge changes that were previously recorded with the new one will be saved, /child:replace will exchange the old changeset with the new one. In the above example, none of these alternatives will make any difference, since Get by Label will still pull the highest set of changes.