We are using TeamCity for continuous integration and TFS as our VCS. I am able to apply a label to a build using the VCS Labeling build feature. This works exactly as we expect it to but with one minor glitch that we can’t seem to figure out.
In the TFS source control explorer, I go to the top level of the project. From there I can select view history. On the view history I select the Labels tab. Here I see something like this.
Name | User | Date |Changeset | Comment
MyLabel |username|datetime|12345 |TeamCity automatic label
This is all well and good except that the Changeset number is always the very first one that was ever done for this branch. Is there a way to configure the changeset setting? As a bonus, setting the comment would also be great.
Thanks
This is not a glitch, but rather how TFS labels works.
The change set shown on the label is the change set of when the root folder within the label was last modified.
The reason for this is because labels are not a point in time snapshot of files as they are mutable.
Related
Scenario if given 2 builds how do you view the changesets in the later build that aren't in he earlier. Are there any other ways to view and query changes...
Any thoughts appreciated
Since a label can be edited post hoc it's not possible to get the raw changesets between two labels. The diff commands will only give you file or folder differences.
However, if your builds label by changeset (or label the tip), which is a pretty typical scenario, then it is possible to look at the project history (by changeset) between the times when the two labels were created and build up a picture of what's changed between two points in time.
As a general rule, if your build system supports it, it's always helpful to put something useful in the label comments like 'Label xxxx created for build yyy at changeset zzz' which makes the label history a lot easier to interpret.
If you use Teambuild the build template can be configured to give you a breakdown of changesets since the previous successful build label, which might save you some work going back retrospectively to find the information.
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'm evaluating TFS as a replacement source control option for company, and documenting how our current processes would change or stay the same if we start using it.
We use labels fairly heavily in our current product, not just for creating snapshots of a given build, but also for targetting specific modifications for future builds. Our standard is to always check-in each file with a label of the release version it's intended for.
Our current software has an option for "Label" right on the check-in screen, so checkin/label is a one-step process. Is there a way to do this with TFS? I see that you can open the source control explorer and label things after the fact, but if users are going to have to go clicking around to find the right changeset to label after the fact, I want to be sure to document that...
I'm not aware of a way of auto labelling every check in, but a couple of options spring to mind.
You can set up a list of text fields that must be filled in (in the check in notes section of the pending changes dialog), and even make these fields compulsory, so it would be easy to add a "for version" note to every check in. IIRC this is set up by right clicking on the team project in team explorer and going to the source control options.
TFS raises events for actions like check ins, so you can use the TFS api to handle the event on your server and add a label automatically. You could even pick up the check in notes to tell your code what the label should be.
This may be where you need to change your current processes. With TFS (or other version control systems), all the developers targetting a particular release should all be working with the same branch in TFS, i.e., you have a dedicated branch for each parallel development stream. Thus the need for labels is reduced. This is a much better approach than using labels, because you can look at a branch and see what will be in that release, without having to sift through labels to see if a particular change applies to the release.
I suggest having a look at the Visual Studio Team Foundation Server Branching And Merging Guide.
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!
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.