VCS Root Maintenance Strategy For Multiple Projects in One Repository

Hi TeamCity Experts!

On my current project we are dealing with a fairly large SVN repository that has multiple project roots. The svn tree looks like:










Is it practical to create a single VCS Root that points to /repos/RepoName and use checkout rules to point to individual project trunks for each build configuration. This way we have 1 VCS root to maintain. What are the pros and cons of this? I personally don't see any cons, but I've heard it through the grapevine that there can be performance issues with this.

Thanks for your help.

Comment actions Permalink

It's hard to say for sure which way is better. With single VCS root and many checkout rules the process of changes collecting can take more time than with separate VCS roots for each repository. But maybe it will not be a problem in your case. Anyway you can start with single VCS root and see how it goes.

Comment actions Permalink

I'm not sure exactly what is going on behind the scenes, but it feels like using a single VCS root and multiple check-out rules is a lot slower. The "Changes" drop down in a build also shows commits that do not lie underneath the check-out rules locations. Not sure if we're doing something wrong, but we've had to go back to individual VCS root per project even though they are under the same repository.

Does a single VCS root with with many build configuration check-out rules result in less chatty communication to the SVN server?

Comment actions Permalink

Mixing of changes is not a intended behavior, checkout rules should split them between projects.
Can you show by screenshots, how VCS root and checkout rules are configured please.

Comment actions Permalink

For the performance question, could you please show an example of a build log, I'm interesting in a first part with a checkout step.



Please sign in to leave a comment.