I’ve set up our SVN repository like the Subversion book suggests, and this is also how my previous companies have done it. It looks something like this:
/trunk
/branches
/tags
/extlibs
/docs
where the first three are pretty obvious, and extlibs is for 3rd party assemblies that we wouldn’t typically recompile ourselves.
All of this works great for the daily development stuff.
Now I’ve installed TeamCity and have builds, unit tests, code coverage, and code analysis running. Everything is great, except for the fact that this code structure results in too much code getting downloaded.
So here’s the catch 22, in my opinion: it’s silly to download all of aforementioned folders from the SVN repo when I only need /trunk and /extlibs. But I can only specify one repo folder to download in the TeamCity VCS settings. So then the other possibility is to put the /extlibs folder into /trunk, but in order to compile branches, /extlibs would have to go into all of those as well (since I usually branch the trunk, and not individual subfolders… and this would seem infinitely more evil since /extlibs could actually be larger than /trunk and /branches, with all of the binaries stored there…
Do you guys have any suggestions for me? Thanks!
It looks like you have two different issues you need to address:
For your VCS, leave your setup as you have it – at the root of your repository. In each build configuration, you can add checkout rules to prune your checkout to the right folders.
For instance, you can use the following to make the trunk folder the root folder of the checkout:
Or for a branch, you can do something like:
You can add multiple checkout rules if desired, including adding any files/folders from your extlib folder:
You can even remove files/folders using checkout rules:
For your external libs, as stated in other answers, you can include external folders using SVN. However, I would not get heavy handed with the inclusion of the entire extlibs folder. Only include the specific library revisions that you need to build the project. Also, make sure your extlibs folders are well-protected from change. By being fine-grained about your externals, you can avoid the issue of trying to build an old version because your project will be linked to the correct version. If you have triggered builds enabled, you will also avoid a library change triggering a build. For example, you could configure your snv:external libs like so: