A blog states
Labels come with a big warning though - labels themselves are not
version controlled, meaning that there is no way to track or audit the
history of activity on a label. Plus, labels don't keep copies of
versions in case of a file deletion, so if a file gets deleted, any
label that relies on a version of that file is essentially hosed.
This is not the only place I've read similar information regarding TFS labels. The lack of history is clear enough. The second part "labels don't keep copies of versions..." is unclear. In fact, I created a test project > labeled it > deleted a file > performed a Get by Label and the file came back. So what is this referring to? Has the label functionality changed in TFS as of recent?
I realize that a file deletion does not actually remove history, is that the cause? In other words, if I run
tf destroy "$/MyTeamProject/Project/FileName.cs"
Is that what it means to delete a file? If so, that seems an extraordinary circumstance to even consider. I mean, its an intentional unrecoverable deletion of history. Changesets are not going to be any improvement over labels in such a case.
When we apply a label we do so to a version of source control at a point in time. Intuitively, because we initially created a snapshot of source control at a point in time one may assume the snapshot represents source code at a point in time.
This is incorrect. Labels can be edited after creation.
Conceptually, a label defines a product and the product’s bug-fixes (source). A real world example may help. Let’s say we have a product called AlphaBoogerBear. AlphaBoogerBear is a product, not a version (think pre-release Windows names). AlphaBoogerBear can be made into a Label, AlphaBoogerBearLabel. We perform a release of AlphaBoogerBear. There are some bugs. We fix them.
Now, we go back and edit AlphaBoogerBearLabel to include the bugfixes. The label no longer represents a snapshot at a point in time. Instead, it represents the most stable release of AlphaBoogerBear.
Finally, we move to BetaBoogerBear. We have the option to go back and grab a label that represents the old product at its best version in time.
In my opinion, if one requires a snapshot of version of source control it's better to branch. If one requires an edit-able snapshot that represents a product release then a Label is useful. Albeit, it seems a difficult balance of trust and convenience.
As far as the author's intentions, I really can't say for sure. He could mean to say that items can be deleted from a label and thus when you Get by Label the item will be gone. Though, the item is still stored in TFS history so although it is a confusing situation, not all is lost.
I'm not sure what is meant by the sentence about labels getting affected by file deletions. But you have it right, a regular file delete won't affect labels, but a destroy will.
What it's cautioning you about with respect to not being version controlled though, is that somebody can come and edit a label, by including or excluding files from the label, or changing the versions of files included in the label. And there will be no history of these changes to the label definition.
As I understand it, a label in TFS is basically a set/collection of changesets.
Let's say you label a directory with two files in it. The label would then consist of three changesets: one for the directory and one for each file. Deleting one of these files in TFS will produce a new changeset for the directory, so doing a Get by Label at this stage would get the deleted file "back" since it contains the changeset prior to the deletion. Destroying a file would remove it from any changeset records it has appeared in, thus also destroying the information in the label.
Since the label is identified by its name only, it is also very easy to overwrite it with a new label, destroying the old information. The /child parameter to this command can change this behavior somewhat: using /child:merge will keep the changesets that were previously recorded along with the new one, /child:replace will exchange the old changeset with the new. In the example above, none of these alternatives would make any difference, since Get by Label would still retrieve the highest changeset.
Related
In order to clean up my project structure, I moved a folder into another (new) folder through the TFS Power Tools Shell-Extension (Rename/Move).
After checking the history at the new place, the move is the only entry. (I tried one folder up, down, even on single files in the moved folder.. same result.)
I had also put on some labels on versions of the folder before the move, since there were some important states of the code I wanted to get back to.
So.. what went wrong, and how can I either get the history or at least find out the label names again and check out those versions?
Turns out it is pretty easy.
In Visual Studio 2010, go to Tools->Options. There you can find the option to show "deleted" items (roughly in the middle of the dialog box). The old folder got deleted during the move - it will be displayed again after activating that option. (They will be kind of grayed with a red cross.)
Labels seem to have disappeared, though, so I had to go by version.
In the Source Explorer you have the normal operations again - like View History or Get.
DISCLAIMER: For reference of everyone that gets here, this answer is not fixing #Andreas problem, just giving some context on why this happens and offering a couple of workarounds.
Seems that losing history when moving folders in TFS 2010 is not a bug, is a "feature". (still happening in TFS2012. From this MSDN link you can read official Microsoft answer:
Thanks for the feedback here. The previous comment about this being by design is correct, and there is an option on the command line. In the UI, history of folders is recursive - always. This is because most of the time, users care about the history of the contents of the folder. Files on the other hand dont have the concept of recursive history - you always see the history for the file itself. Now, from the command line, there is an option to show recursive history (/r) and if you run tf history on a folder without the recursive option, you'll see the changes to the folder itself. This would include changes such as a rename for the folder itself.
Workaround to get history once lost: As you can see there, you have a workaround using tf history.
Workaround to avoid losing history: If you want to avoid losing history in folders instead of using move feature, you can use TFS Integration tool to migrate code from one folder to other preserving history, migrating from $/TFSCode/FolderA to $/TFSCode/FolderB. It is a little bit overkill but if the history is pretty important for you is much better than looking for it in deleted folders
It is true that the folder history is lost, but the individual file history is actually not lost. It is hidden under the little "expand me" arrow at the far left on a file history line. Expand it on the oldest history entry for a file, or anywhere you see it, and you will see history of that individual file also from an old location that no longer exists.
At the top of History window you can edit Source location, put the old name and get the full history before it has been moved.
Also, is good to mention that you can get the full history back by moving/rename the branch back to the old location/name.
Using the TFS API I am trying to approximate bugs/file.
A bug (as I define it) originates from a file in a change set that has been associated with a work item that has type WorkItemType = 'Bug'. For example, in branch-a, branch-a/1.txt and branch-a/2.txt are checked in and associated with a 'Bug' work item. Call this changeset X. There are now two bugs in branch-a associated with those two files.
If I merge branch-a back into its parent (the root branch), the root also gains these bugs, so root/1.txt and root/2.txt are also bugs - basically the root branch has gained the buggy history of it child. Bugs can be inherited in this fashion. This property is preserved across renames. So if root/1.txt was renamed to root/hello.txt it's still a bug.
I start with iterating over all "Bug" work items in the TFS project:
In this example there is a single work item, which is associated with changeset X, which is associated with changes on branch-a/1.txt and branch-a/2.txt (although those files could be renamed now in the present).
Now I want to know all places where branch-a/1.txt and branch-a/2.txt ended up (once again, even with renames).
So, given a Changeset cs and a Change c within cs, I want know for each branch if c made it into that branch and the most recent file name where c resides.
Another way to think about the problem is thinking about moving forward through history. I start at specific point in time with a change in a single branch. Now this change needs to be tracked all the way to the present.
Any ideas? I can provide clarification as needed.
Thank you!
Have you tried tracking the changeset?
View History on the file that has the change (1.txt) > Right Click on the changeset > Track Changeset > Check all visible > Visualize.
Not sure if this is exactly what you want but it might a good place to start.
Video that shows it: YouTube video
Not sure if it's possible using the API. This link seems to suggest that it's not possible using API calls. This link seems to suggest that it is possible.
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!
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.
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.
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...
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.
I'm extremely new to TS and it's not apparent to me. It's seems to me that it must be in there. Could someone please point out how to go about marking a whole solution with a version number or label and then retrieving that specific version back from the repository?
Thx
Applying the label isn't the easiest thing to find. You can get to it by right clicking on the folder containing your solution file in the Source Control Explorer window (which you can get to by double-clicking on the Source Control node in Team Explorer). When you apply the label, apply it to the folder containing the things you want included in the label. Then ensure that the next screen shows you the contents of that folder (i.e. all the files you want to label)
In TFS a label is a bit like a tag. It is actually something that can be edited and you can have files of different versions included in it if you really needed to.
There is also the concept of "Changesets" in TFS. A changeset is a number that always increments on a particular server (or Project Collection in TFS2010). The number represents a unique point in time for that server instance.
To get the files from a particular version, in Solution Explorer right click on your solution and do "Get Specific Version..." In the Version group box you can change the type from the default Latest Version to specifing the Changeset, Date or Label if you want to get a version from an older point in time.
Hope that helps.
Martin.
We're using Team Foundation Server and we are using Labels to create points in our version history where specific versions (either internal or external) were produced.
Right now we were wondering if a particular changeset was done before or after a specific label (and thus included in that version or not), but we must be looking in the wrong place. This information is usually provided in the bug-tracking system but this time this field was left open so we thought we could use TFS to figure it out.
The version history for a file doesn't include labels applied. To find labels, the place I know to look is to use the "Get Specific Version" dialog, set type to Label and use the Label selection dialog to see which labels we've made, but this dialog doesn't tell me the changeset before/after the label was applied.
Is the only way to figure out if a particular change was part of that release or not to create a new workspace, map up the directory with the files to a temporary directory on disk, use the Get Specific Version dialog to extract that release and do a file-diff?
Please tell me how stupid I am and point me in the right direction.
Run in your local workspace
tf history . /stopafter:1 /noprompt /r /version:Lmylabel
to get
Changeset User Date Comment
--------- ------------- ---------- --------------------------------------------
88888 brian_low 11/11/2012 did some work
Have you tried opening Source Control Explorer, File -> Source Control -> Labels -> Find Label? [EDIT: that may have been in a beta version, and I don't have TFS here atm...]
Also, are you using SideKicks? The Labels SideKick allows you to find a label and see the related changesets.
A label in TFS does not represent a specific point in time - and a label can actually be edited after the event. See the following posts for more information:
Buck Hodges: Finding Changes between two labels in TFS VC
Brian Harry: Why TFS Label are not like VSS Labels.
For this reason, I tend to use Changesets in TFS when recording the point in time for a particular release (in fact we label our binaries and installers with the actual changeset number that they were built from just to make it easier to track). (A changeset does represent a unique point in time for the state of the repository).
Hope this helps,
Martin.
Faced this issue for the first time today. From now on I am including the changeset-number in the label-comment. Not very elegant workaround, but meets my needs.