How do I efficiently share a large content VCS root between multiple build configurations?

Hello all,

I am trying out TeamCity 4.5 EAP and the situation I have is that I am trying to efficiently share a Perforce VCS root that contains a large amount of content (over 2GB of data) between multiple build configurations.  I have been browsing through the discussions but I haven't found any real similar situation to the one that I am trying.  What I would like is for the VCS root to be synced to the latest rev once and then it never has to be cleaned and only updated as infrequent changes are made.  Now, I have tried a couple of different situations.  First, I added this VCS Root (lets say VCS1) alongwith the VCS root that builds my software in a build configuration (VCS2).  This does serve my purposes well, as it works across build agents and only does one get of VCS1 until I want to clean the checkout directory, because I would only like to clean the source for VCS2 but not VCS1 since VCS1 is large and takes time to sync from clean.  Thats where this option breaks down.  So then I tried adding a separate build configuration that syncs VCS1 and make the rest of my software builds depend on that.  The problem with that is if a downstream project that depends on VCS1 is sent to a different build agent, then that build configuration for VCS1 may not have been run on the other agent, making the dependant files missing.

So after all this, my question is, is there a better way for me to be able to get the desired behaviour?  I am still tinkering with this to get it to work just right, and I would really appreciate some suggestions.

Thanks in advance

Hamad

5 comments
Comment actions Permalink

Why do you need to clean checkout directory? Maybe you can configure your build to clean some files produced by the build, but not the whole directory?

0
Comment actions Permalink

As part of our build process for some of our components, files from source control get moved around (for example, when creating installers) and we like to clean our checkout directory before we resync to perforce so that there are no artifacts remaining from a previous build.  That is why we would like to clean the checkout directory for some VCS roots but not all of them (specially the large content VCS root that do not experience any change during the build process).  I could have a specifc build script to do the clean and resync of the checkout directory, but I was hoping that I could stick to using TC's built-in VCS root features than bypassing them with my own scripts.

0
Comment actions Permalink

All I can suggest now is to modify build script to clean artifacts left from the previous build before other build tasks start. Usually in build scripts there is some cleanup stage which cleans files produced by previous builds.

We also work on a plugin which will automate such tasks, i.e. when build finishes or when next build starts it will clean new files produced by the previous build (except files checked out from VCS). Unfortunately this plugin is in early development stage now, and I cannot give you any links.

0
Comment actions Permalink

Thanks for the suggestion....I am still playing around with things so I might stumble upon something that works....the reason why things are a little complicated is my gratuitous use of hard links in NTFS to reduce build times by eliminating copy operations and the side effect of that is that it makes it difficult to keep track of smaller items copied to links to other places......

0
Comment actions Permalink

Here is how I have figured out the solution to my problem.  I created a separate build configuration to checkout the large content VCS root to a custom checkout directory like %agent.work.dir%/%teamcity.projectName% and then I created another build configuration to run the checkout configuration on all agents prior to starting my software builds, which are configured to look for the checkout directory to reference the content of the VCS Root.  Hope that is useful to anyone who is interested in doing a similar thing

0

Please sign in to leave a comment.