is the condition I was referring to in my previous post…

I assume it wasn’t possible to move the label from stage to live.
In your post you have this condition:

based on that I assumed it wasn’t possible, and that confused me a bit because the logical approach is to move the label ‘up’ from stage to live.

A promotion can be done from your workstation by executing the command line c:\>msbuild tfsbuild.proj @tfsbuild.rsp /p:SolutionRoot=”[project source code directory]” /target:promote /p:FromLabel=[pre-stage/stage/live...] /p:ToLabel=[pre-stage/stage/live]. It does not have to execute on the server as it is only moving labels in the version control system. Provided that it is executed in a folder where TFS can determine your workspace.

That’s correct, a separate build must be configured and set to checkout the source code for a specific label. In our configuration I have separate builds configured to use a different response file (.rsp) that specifies the version of source code to use. This is done using the /version:L[pre-stage/stage/live...] parameter of the tf.exe utility.

thanks for the response, I think I almost get it.
If I understand it correct, you manually asign the live label?

Where do you execute the msbuild, has to be on the server?
If I want to kick off a build for a specific promotion group I probably have to configure the build to only use sources with a specific label?

Again thanks

Labels are used to mark and group a set of files that belong together, for example, the set of source files that make up the internal test version. Now, assuming that there aren’t any other labels in the version control system, you would want to apply this new “internal-test” label to current version of source code, which is known as “T”. T (Tip) is a well known version specification in Team Foundation Server. That will result in the “internal-test” label to be at the same level as T. As soon you start developing and follow that up with a check-in, the internal-test label will be at a level above or below (it’s a perspective thing) the T version. The point of the matter is that we are continually moving the “internal-test” label to the latest version T, whether you see that below or above the latest version T.

After development is done, you would simply execute the target called “Promote” which is defined in the build file as:

<Target Name=”Promote”>
… all the code in the post …
</Target>

It will typically be executed from the command line as:

c:\>msbuild tfsbuild.proj @tfsbuild.rsp /p:SolutionRoot=”[project source code directory]” /target:promote /p:FromLabel=pre-stage /p:ToLabel=T

That will execute the Promote target and pass it two parameters, namely FromLabel and ToLabel with pre-stage and T as the respective parameter values. This will result in the pre-stage label being removed from the current set of files it marks and re-applied to the current version T.

A build can be automatically kicked off by using the Exec task to execute the tfsbuild.exe start command.

this is a very interesting post, but there are a few things I don’t quite understand

– why are the labels in the version control system being shifted downwards?
How do you work with the labels then? What do you do when development is done and you want to promote it for the internal test

– i have no experience using MSBuild targets, so how does executing it work?

– you say that “for every source code promotion there is a corresponding build process that kicks-off”.
How have you realised that?

A lot of questions I know, but we are investigating if we want to use Team System so we don’t have a lot of experience with it and we havn’t worked with MSBuild also…

T.i.a.