I have a pair of subversion repositories - Supporting and Products. The former contains DLLs and svn:externals references to those open-source repositories that we pull from to build said DLLs - we then version the output and include them into our own products via a single svn:external reference in our Products repository. So:
/various other tools that we use and keep in svn for xcopy deployment
/reference (which contains sample source code we find in blogs that we want to refer to easily)
/libraries (which has a bunch of svn:externals pointing at OS repository-roots)
svn:external to Supporting/trunk/library
This lets us (as developers) check out Products/trunk locally and be able to build (after running a batch file to generate AssemblyInfo.cs). It works well.
However, we've got a bunch of feature branches going, and we'd like to set up CI against each - preferably, frictionlessly (that's feature request #1 - a function in TC "create branch build-config" which is like "copy build config" but infers the VCS settings based on convention and the branch name - what it does is ask for the branch name, then create the branch in our svn repo, and copy the TC build-config and switch the copy to pull from the branch. It also fires off a build so the creator can see that it succeeded, and the branch is off to a clean start).
TeamCity is set up so we have a build configuration with VCS roots:
Fine. This works well too. While we just have one build configuration anyway.
I would have preferred to set up two global VCS roots, Supporting and Products, and then in each build configuration, set up checkout rules like:
+:trunk/library => library
+:trunk/ProductA => ProductA
This would have the benefit of not requiring us to maintain copies of the VCS roots per build configuration - we'd just have to tweak the checkout rules (which are tied to build config). This would let us easily copy a build configuration to create a branched configuration.
However, there's a warning that pops up in the VCS settings if we have "checkout on agent" selected with rules like these, to the effect that the agent will check out from the VCS root, then delete according to the exclusions. In this case, it seems like it should be possible to optimise this - the agent should realise that the first "exclude everything" rule means that it can then iterate through the rest of the rules and individually check-out, rather than pulling down everything and deleting. In our case, pulling down everything and deleting is big, because until we realised this was happening, we had the repo root as the VCS root - which included all branches and tags etc. Ouch. So, that's feature request #2; modify the behaviour so either the agent intelligently notices the exclude-all rule at the top and does one checkout per subsequent rule, or make the default behaviour optional to be "lazy" rather than "eager".