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.
Related
I have automatic build numbering setup, based on build date/name, using approach proposed by John Robbins from Wintellect described here. So the version/resource file is automatically created on build time but not checked-in.
I wonder how to approach a problem of rebuilding historical versions (based on labels) and having the original build number/name in them. Is it possible to detect 'GetVersion' parameter of MSBuild and try to recreate the original build name from it?
Is it a sane approach anyway? What alternatives do you see?
It's not easy to build a specific changeset (though possible, if you pass the changeset number into your build script and modify the "Get Latest" portion of the build).
However, one easier way of handling this is to create a branch of your code. You can branch at a specific date or changeset, which will create a copy of code from that point in time. Your build scripts can then be pointed at this code.
With respect to your versioning problem: you may find that the only sensible way to do this is to hardcode the required version number. My understanding of your version numbering strategy is that it doesn't relate to anything you can derive from the source (such as the changeset number, date, or file content), and it isn't checked in - so re-calculating it will be pretty complicated!
You ask question Rebuilding historical builds but it actually Rebuilding historical change Set or label, I know what you mean but I am trying to tell you what I need to say, so I don't see that we need to build a label with the specific name the label or change set can has many build as needed and since we use the date and time in the build number it will more realistic to has the current time and date the build was taken instead of old one
Thanks
M.Radwan
We are planning to move from StarTeam to TFS for source control and are in the midst of refining our ALM procedures. Maybe I am misunderstanding something about how labels work in TFS, but it appears that you can apply a label to files by Changeset. I am trying to create a label on only the files/versions in the specific changeset.
I have attempted to do this like so:
1) Main Menu -> Source Control -> Apply Label
2) 'New Label' dialog appears
3) Leave path as is (Dev Branch)
4) Select 'Changeset' from 'Version' dropdown, enter my changeset #
5) Click Create.
... which results in the entire branch getting labeled. The changeset may be 1 - 100s of files, so individually labeling files is not practical.
We do this all the time in starteam: label changesets related to features, then move a build label up onto the labeled changeset. Am I missing something fundamental? (Thanks for any guidance)
Note the name... you are labeling by changeset not labeling a changeset.
Labeling in TFS is like marking a point in time. So when you label by changeset you are basically saying this is what my source control looked like at this point in time.
It sounds more like you area saying you want to be able to find a set of changes (changeset) not everything at the point in time that changeset was made.
You could pick a branching strategy that would allow you to branch by feature. The downside of this is that it will involve a lot of merging.
Another options would be to link the changesets for any specific feature to a work item and then you will have a list of changesets that you will want to merge up once you have completed that feature. In 2008 this can be a little troublesome because merging changesets that are not sequential can be more time consuming than necessary. (meaning there are changesets in between on that branch not that the changeset numbers are sequential)
Fortunately, you can try out different branching strategies and as long as you think it through it isn't to tough to switch if you don't like how you were doing it.
In TFS2010 I tested adding lables to a changeset and I am seeing the same behavior you reported.
When reviewing a changeset it will only contain the files that were checked in.
When reviewing a label that was created on the same changeset it will contain all of the files in the branch, with each file showing the changeset version of the last check-in.
I don't know why it works this way.
Does TFS offer a way to save, track, and later redeploy builds by build number, or can you only deploy .dlls compiled from the current codebase? I'm looking for functionality similar to what you find in Changeman DS.
Yes. Every build definition in Team Build has a "retention policy" that defines how many historical builds should be kept, depending on certain criteria. You can also mark individual builds as "keep indefinitely." Kind of like a Tivo...
Example walkthru with screenshots: http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
If you need to recover a build that has already been deleted from the drop share, you can do that too -- you'll just have to rebuild it. Simply queue up the build definition, but before you hit Go, type /p:GetVersion="XXX" in the text area at the bottom labeled "additional MSBuild arguments." XXX can be any versionspec, just like you'd use at the tf.exe command line. Examples might be "C12345" or "D1/10/2010" or "LsomeLabel".
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.