We have a fairly standard release procedure using Visual Source Safe for labeling a build before it is released. This allows us to do a get from that label if there are any problems and use it to branch if changes are necessary.
We have several different projects and always label using the builds version number.
e.g. "V1.0"
After moving some projects to TFS we have noticed that if you try to label using the same version number as another solution e.g. Solution A and Solution B both release "V1.5" then TFS will not let you do this as the Label name is treated globally. After reading a few blogs on the subject which discusses how TFS labels are not a point in time but a collection of files I am thinking that we will have to start including the project name in the label to get around this e.g. label as "Project A V1.5" and "Project B V1.5". Does this sound like the right approach?
If you haven't read Brian Harry's Why TFS labels aren't like SourceSafe labels, please do.
Basically the answer to your question is YES!
Related
As in subject:
Go to "Find Changeset" option.
Find a changeset.
Double-click on changeset to open Changeset Details window.
It gives a list of all files that have been checked in within given changeset.
Why I cannot apply a label on those files from that level where I have them all in one place? Especially, that very often they are part of different solutions and projects, so normally I would have to create a label for one file and then search and add one by one to the existing one.
It is so inefficient!
Is it some bug or lack of functionality? If the second - it is hard to believe MS guys forgot about such handy function.
How do you deal guys with such situation?
EDIT - to clarify my reasoning:
If I use jessehouwing's method - yes, it works and it's simple.
But then when I search in the future for that label and want to see what code was included, it gives me a list of all solutions - even those totally unrelated (IWP and PDPRO are the unwanted ones):
If I use it my way - it gives me that:
I think it looks cleaner and gives directly the information of what solutions and files underneath where included at the time when I put stuff into Production environment and applied corresponding PROD label.
The feature you're looking for doesn't exist. generally a single file or group of files at a label doesn't make a lot of sense. While it's possible to "scope" labels in TFVC, it's only possible through the commandline.
generally you'd create a label at the repo or branch level at the specified changeset. That will include all files, including the ones you just checked in. Creatign such label is relatively easy from the source control explorer, though you need to copy the changeset number:
It's unclear to me why you'd only want the changed files to be included in the label, maybe you can elaborate a little more on that requirement.
Update: What you desire isn't possible from inside VS and isn't simple from the commandline either. I suppose that with a bit of Powershell Magic against the TFS Client Object Model you can do this from the commandline and it should also be possible to build this as a Visual Studio Extension (or maybe suggest it to the author of the TFS Source Control Explorer Extensions.
Our code is branched in TFS along project lines, and each has its own separate build process
We label each project with the build number, e.g. Build_1, etc however I made the dumb mistake of forgetting that TFS labels must be unique and forgot to label my project with the name of the project.
To explain, I have labelled the P5624 folder four times with Build_1, Build_2, Build_3 & Build_4 when I should have used labels like P5624-Build_1, etc.
So, I am looking for a way to rename the labels. I couldn't find anything directly related on SO, and the microsoft Help on the TF Label command (link here) doesn't give any indication that it can be done.
We don't do any automated builds or have anything that relies on a label name, so even if your solution is a "do it at your own risk" then I would still be happy to hear it.
Renaming Labels is not supported by TFS. You can only create a new Label based on the old Label you want to remove.
If your are using Visual Studio, here are the steps how to do it
Right click the folder at Source Control Explorer to open
ContextMenu and select 'Apply Label'
Change the Version-Combobox at the bottom to Label and find the old Label "P5624"
Name the new label "P5624-Build_1" and create it
Delete the old label if it isn't needed more.
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.
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.
We currently are using both Visual Source Safe and Team Foundation Server at work (VSS for old projects, TFS for current or new projects).
We have always used Labels in source control for each build. In VSS if you chose to see a file history you could include labels. In TFS I cannot find an option to include the lables in the history window.
Since one of the most common questions that I get asked by support or management is 'What version did we fix/add/remove/change xxxx?', I have always relied on our build labels showing up in the history.
Can I get Labels to show up in a file history?
In the 2008 version of TFS, you don't see labels in the standard history of files and folders. If you really want to know why - see Brian Harry's blog post "Why TFS Labels are not like VSS Labels".
To find labels in Visual Studio, go to File, Source Control, Label, Find Label... From that you can see what versions of files were included in that label.
The team have definitely heard that this is not ideal, and the next version of TFS (Team Foundation Server 2010, codenamed "Rosario") will include improvements to the History view to make labels easier to find - see http://go.microsoft.com/?linkid=7807943 for the spec of improvements to the History view in TFS 2010.
BTW - I actually moved to changeset based build numbering with TFS which makes labelling less necessary. See http://www.woodwardweb.com/vsts/changeset_based.html for more details.
Hope that helps,
Martin.
This very issue has been killing us.
The best solution I've found is with the use of a third party tool called Team Foundation SideKicks available for free here http://www.attrice.info/cm/tfs/.
Under the "History Sidekick" there is a label tab. You can highlight any folder or file and it will show you every label that was dropped on that folder or file and at what changeset.
Unfortunately you can not see a full view of a folder or file's history with labels included.
Under the "Label Sidekick" you can highlight any specific label at it can tell you what folders/files and changesets are in the label. This functionality is pretty much the same as what is available from within Visual Studio and is not as helpful.
One caveat is the need for a TFS server 2008 or above. Using the tool with TFS server 2005 is painfully slow and basically unusable.
-ephi
[due to the complexity of TFS-style labels this is a quite difficult problem when applied to folders; based on a comment above I'm going to assume searching for labels on a file is sufficient]
Unfortunately this is one of the very few edge cases of the TFS client API that is not exposed anywhere in tf.exe or VS2008. You'll have to call the API directly. Please see http://msdn.microsoft.com/en-us/library/bb138967.aspx - the "versionFilterItem" parameter does what you're looking for.
TFS 2010 has a very useful "Labels" view (rather than "Changesets") in the history of any branch. Unfortunately, it only shows labels in the branch you have chosen, rather than labels in all child branches/folders.
I started to play with trying to create my own SQL to do this and run it directly against the TFS database(s) themselves. This SQL was run against TFS 2008. This little snippet will show ALL the labels and changesets for ALL the branches ordered with the most recently created branch/modified label first. The next step in developing this would be to somehow traverse the changesets and the labels to only bring back areas I'm interested in (like 'Main' or some particluar branch). I imagine if I created SQL that would do all of this, it would be dog slow, and wouldn't have the full GUI I want to dive into the history for a particular file, see labels with that, etc. Sigh.
select DisplayName, cs.CreationDate, Comment, 'CheckIn'
from TfsVersionControl.dbo.tbl_Identity i, TfsVersionControl.dbo.tbl_ChangeSet cs
where cs.ownerid = i.IdentityId
union
select DisplayName, LastModified, Comment, 'Label'
from TfsVersionControl.dbo.tbl_Identity i, TfsVersionControl.dbo.tbl_Label l
where l.ownerid = i.IdentityId
order by 2 desc
I've used TFS branch history for this before. It's not the greatest UI in the world and only lets you show history per file but it gets the job done.