Shared VCS root

Is there any downside or issue with using a single VCS root across hundreds of build configurations and using configuration parameters to specify the path/branch name? Am I going to regret attempting this setup?

15 comments
Comment actions Permalink

From what I can tell there is at least one hidden gotcha: We've been learning TeamCity over the last week and when using the same VCS Root in different Build Configurations (using 'checkout on Agent'), it appears that all of the products of previous builds stay in the single folder that the root is stored in.

For example, we have a configuration that builds xyz.dll, if you run another configuration that is using the same VCS Root, that xyz.dll will still be in the folder tree that you are building your second configuration from. This can cause some unexpected behavior. I'm trying to figure out how to circumvent it so that we can have the benefit of fewer VCS roots while still having a clean build environment.

0
Comment actions Permalink

We've been using TeamCity for a while and the behavior has always been that each build config gets its own directory on the agent to checkout sources to and build in. We already use a VCS root shared across all projects for the build scripts and it works this way. Does this change if you share a VCS root with parameters?

0
Comment actions Permalink

I don't know how parameters would affect it, but when I switched over to Server-side checkout instead of Agent-side, it began to use different folders for each configuration.

0
Comment actions Permalink

What VCS do you use? We use Subversion and Mercurial w/ agent side checkout.

0
Comment actions Permalink

Ah that's probably why the discrepancy. We are using TFS.

0
Comment actions Permalink

Out of curiosity, why do you use TeamCity in conjuction with TFS? To put it another way, what does TeamCity give that TFS doesn't? Bear in mind that I've never used TFS, just curious.

0
Comment actions Permalink

TFS is just Microsoft's source control system that integrates with Visual Studio. MS has some sort of Build Server solution, but we liked TeamCity better. We also use SVN for a few projects.

0
Comment actions Permalink

Hi

Working directory is shared if build configuration have the same set of VCS roots and checkout rules. It allows to speed up the process because there is no need to checkout sources twice.
Consider using Build Files Cleaner to automatically rollback changes performed during the build.

Michael

0
Comment actions Permalink

And sharing the working directory is determined after parameters have been expanded in the VCS root and checkout rules, correct? So if the repository URL in the VCS root has a parameter, two different values for the parameter will result in different working directories, correct?

0
Comment actions Permalink

Parameters should not affect the behavior. Hash name for checkout directory is calculated after parameter substitution.

0
Comment actions Permalink

Yes, of course.
If the parameter has different values, then builds should be performed over different sets of sources. So the agent stores them separatelly.

0
Comment actions Permalink

Cool, that's what I expected, but it never hurts to ask. However, sometimes it hurts to not ask.

This brings me back to my original question, is there any reason why I should not have one shared VCS root across all my build configs and use parameters to differentiate the VCS root directory, branch name, etc? Performance reasons or anything else outside of issues in TeamCity itself, obviously (*shock!* not possible)? We currently have about 600 build configs. Thanks.

0
Comment actions Permalink

From the administration point of view it is good to have minimum set of meta VCS roots shared among different projects. Probably, in some cases it is possible to have exactly one such VCS root.
Practically we had some issues with similar setup in the past. For example, if you have really huge Subversion repository with a lot of externals, it can be resource consuming to work with it as a whole. In such case having separate VCS roots pointing to different parts of the repository can be better. From the other hand, now you can have parameter %url% in the URL setting of Subversion VCS root and tune it as you wish with help of project or build configuration parameters.

So, if all of your projects work with single VCS repository (but with different parts of it), now you can setup shared meta VCS root, containing credentials and the first part of URL, and customize it as you wish. Internally, based on your parameters TeamCity will create required number of concrete VCS roots pointing to different parts of this VCS repository.

Hope I answered your question.

0
Comment actions Permalink

Basically, behind the scenes, TeamCity turns a parameterized VCS root into multiple VCS roots. So there really is no difference between providing a %projectname% variable in my project and making that part of the path of the shared VCS root and creating a VCS root for each project with the full, hard-coded path. I think that answers the question that this setup is not inherently a bad idea. Thank you!

0
Comment actions Permalink

Sharing VCS root does really reduce traffic on the TeamCity Server?

0

Please sign in to leave a comment.