VCS checkout rules ruining my versioning/build number

I don't think this used to be a problem in TeamCity 4.5...
After I upgraded to 5.0 the checkout exclude rules started messing with my build.vcs.number property.

To explain I'm going to give an example of my setup.
Let's say that I have my directory structure put up like this in subversion:


and I have 2 build configurations; BuildCraphics and BuildCode.
Both builds have the project folder as the vcs root, and both builds use the ${build.vcs.number} in ANT for debug version labeling.
The graphics are processed and packaged every time a graphic  designer checks in new assets, a time consuming process and they don't change often.
The code is built and tested with the graphics artifacts from the BuildCraphics build every time a coder checks in code. A quick process that happens quite often.

Every time BuildCraphics completes running, it triggers BuildCode to run to make sure all graphics are compatible.
Whenever BuildCode is to be run, it runs BuildCraphics first if there are changes in its code.

Since the graphics directory is huge, I use a checkout rule to exclude that directory in the BuildCode build and vice versa for the BuildCraphics build.
What I expect to happen when a new graphic asset is checked in to subversion is that BuildCraphics runs with the ${build.vcs.number} as the current build number, which is does, and also for the BuildCode build, which it does NOT. Since the BuildCode build excludes the graphics directory it uses the vcs number of when code was last checked in but not a graphic asset. I can fix it by not excluding the graphics folder, but it is huge and takes several minutes just to check out. So now my two different builds from the same vcs root are giving me two different numbers for the ${build.vcs.number} property.

They should both give me the same number, even though they have a rule to exclude the specific file that was in the latest revision.
How can I get that number without downloading the whole project every time I have to build one component of it?


Hello Ari,

Due to user requests there were changes made in TeamCity 5.0 according to
TW-4527 to switch build revision from global repository revision to the "last included" revision. That's why you see different behavior of {build.vcs.number} after upgrade.

Actually, current behavior seems more appropriate since the build is not affected by the changes in the repository that are not checked out to the agent (at least from TeamCity's point of view).

As I understand in your case you use the global repository revision in the BuildCode build to mark the "checked" state. However, since the BuildCode uses artifacts of the BuildCraphics build (and not original graphics sources), this approach can produce inconsistent results (e.g. if a graphics build is not yet run with the latest changes and the code build runs earlier, the code build may mark the current repository revision as good, while it will turn into failing after the graphics build finishes and re-triggers the code build).

You can probably use a revision of the graphics build inside your code build using the dep. properties.
Also, you can consider using TeamCity Snapshot dependency form Code build to Graphics and remove VCS trigger from graphics build. This way TeamCity will ensure code build always uses corresponding graphics build.

Kind regards,


Thanks for the reply Marina,

I am currently using Snapshot Dependency, even though both builds use the same VCS number the build.vcs.number shows two different numbers.
Is there any way to use the old global revision via plugin or parameters? I saw somewhere that it is possible to feed teamcity this parameter:

Is this what I'm looking for? Or does it do something else maybe?

Thanks for the help,

Hello Ari,

Unfortunately there is no way to reference VCS revision for the whole build chain. I've filled the feature request that addresses the issue. Please watch/vote for it.

Kind regards,


Okay, I'll use another method of numbering it then.
Thanks alot for clearing this up for me =)



Please sign in to leave a comment.