We're using TFS 2008 for our source control. We're currently doing embedded work so our actual build process is using Analog Devices VisualDSP++ IDE. However, we do still use labels on TFS. What I had hoped was for the ability to have a script run when a label is applied. The idea here is to update version information in some data files. This would help ensure that every label programmatically updated that version string. Currently we have to do this manually.
I'm used to Subversion and Git to some extent and was hunting around for post-commit type hooks or something similar. TFS seems like a different beast.
I'm not a stranger to .NET and (so far as I know) could write a simple app that did the grunt work of updating our files and then applied the label programmatically but it seems like there's got to be an easier way.
Am I right? Is there some mechanism that I can attach a script/batch file when a label is applied in TFS?
No, sorry, there's no server-side event fired when labels are created/updated. I'd recommend using branches instead of labels. Then you can hook the CheckinEvent (filtered by the path of the branch[es] in question).
For more info on subscribing to CheckinEvent (including filters), check out Buck's blog + updates + links: http://blogs.msdn.com/buckh/archive/2006/09/29/checkinevent-path-filter.aspx
For a code sample that illustrates what your event listener might look like, check out Martin Woodward's "bunny": http://www.woodwardweb.com/vsts/behind_brian_th.html
For info on using branches instead of labels for code promotion, try http://tfsbranchingguideiii.codeplex.com/
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.
I'm attempting to modify my build process file for TFS 2010. I have a flag that is set when queuing the build, and when said flag is set, I want to create a Label, and add all the source files in the compiled project to that label.
On sequential builds, with the flag set, I than want to replace older source files in said label with anything new in the changeset being compiled.
I've been attempting to do this with LabelSources with no luck, and there is but vary poor documentation on either LabelSources or LabelWorkspace (whats the difference?).
Here's what I currently have:
<mtbwa:LabelSources
Child="[LabelChildOption.Replace]"
Comment="Published to Container"
DisplayName="Create Container Label"
sap2010:WorkflowViewState.IdRef="LabelSources_1"
Items="[{"$/Foo/LabelTest/Sandbox/"}]"
Name="[String.Format("{0}-{1}", LabelName, Version_Container)]"
Recursion="[RecursionType.Full]"
Scope="$/Foo"
mva:VisualBasic.Settings="Assembly references and imported namespaces serialized as XML namespaces"
Version="T" />
It definitely hits the action, but no labels can be found after the fact.
Any help would be much appreciated. and Any tangible documentation, other than Class Documentation with sparse definitions would also be greatly appreciated
Edit 1: Tried to clear up my goal.
What you are trying to do is built into the existing template. There should be an option in the process definition that refers to Clean Sources which will be set to True.
This option controls wither the build sources get cleaned, deleted and start afresh. Or if a differential is done.
If you have a lot of source code you can set clean sources to false and save a bunch of time getting the code.
You can also speed the build by placing a TFS Proxy on the build box which will cache the files and make a clean build quicker.
In my experience, Most of the built-in activities are poorly-documented for a reason - their only well-tested use case is their use inside TFS' built-in templates (DefaultTemplate.11.0.xaml, etc.). I'm afraid you're going to have to write some custom code, in the form of a custom activity, powershell script or something, to achieve other goals.
That said, I don't really understand the process you're trying to set up. Do you just want to have a label set as your latest-successfully-built sources? Why not use the one created automatically by the build itself?
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.
I would like to get the issue list from Bugzilla and JIRA for an open-source project. For each issue, I'd like to collect the corresponding compilation units(for java projects, class/or interfaces files), which may relate to the issue.
Any idea on implementing this feature would be appreciated.
Many thanks!
For JIRA, there are some solutions out there you could use out of the box. See the documentation to integrate with source control for JIRA how to do it. This only works for some source control systems, you should which ones are supported. This gives you a list of change sets (e.g. for Subversion) for each issue.
Another approach could be to do it on your own through an interface to the source control system yourself. The following prerequisits have to be in place:
Your developers have the tools to add the information which issue was worked on by which commit on a per commit base.
You have rules that changes to the sources should all the time being done only for one issue at one time.
You are able to parse the additional information you will get from your version control system e.g. by a script or a program.
For Subversion and JIRA, it could work like that:
Ensure that all commits are only done if the Subversion commit message contains at least one JIRA ticket number. You may even ensure that by a pre-commit hook
Learn how to get the following information from the subversion log
The ticket IDs (by parsing the message) for each change set
The files that had changes for each change set
Collect for each file all tickets.
Show them in a format you like.
I think that this is not too useful, because ticket per class is too fine grained. Perhaps you should have a mapping of the files to modules, sub-projects, ... and collect tickets for them.
All solutions will be different depending on your selection of tools. JIRA and Subversion are here just examples :-)
The best way is to first integrate your issue tracking system with your source control. That means that whenever a developer commits a new change, it determines the set of issues related to this change. This linkage is managed by your issue tracking system and it can show you all the source files, resource files, config files that have changed in the context of an issue.
This info, will be available through the api of that issue tracking system as well.
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.