20
votes

I am setting up TeamCity and I am wondering what should be used as the VCS Root.

My svn repository is located at http://obfuscatedserver/svn/main/MyProject1/

Should I set the VCS Root at http://obfuscatedserver/svn/main/MyProject1/ or use the trunk folder at http://obfuscatedserver/svn/main/MyProject1/trunk/ ?

Right now I am not using the trunk folder and I had to set the Build Runner "Build file path" setting to "trunk/MyProject1.proj" (using msbuild).

Which location is the appropriate one?

3

3 Answers

24
votes

I would recommend using http://obfuscatedserver/svn/main/ as the VCS Root, and then restricting which folders are checked out using checkout rules.

Add the following checkout rules (section 2 of the build config):

  +:/MyProject1/trunk

You will probably also need to update the location of your msbuild file to

  MyProject1/trunk/MyProject1.proj

and set the working directory to

  MyProject1/trunk

This does seem like a lot of work, but next time you want to add a new build, you don't have to create a new VCSroot.

However, the real benefit comes when TeamCity polls your SVN repo. Polling your repo once will discover all the changes for all your builds. This is especially important if your repository is hosted somewhere like sourceforge or googlecode. You certainly don't want to be polling their servers for every build you have configured.

Also, if your repo is hosted by a third party, you might want to set the vcsRoot's Checking interval to once an hour or similar. You can always ask teamcity to check for pending changes from the actions menu on any of the build overview pages if you can't be bothered waiting for the hour to elapse.

2
votes

You should use .../trunk/ as it will speed up the checkout, otherwise TeamCity will get all the branches as well which you probably don't need for the build.

2
votes

Up to the present, I have used ../trunk as the root. This is nice because in my case all the projects are located below trunk and so I can do the complete checkout easily.

But the labeling feature does not work because you need to use a rule like "trunk => tags" and a root that is a parent of these directories. As I'd like to label every release build I now think about changing to a layout similar to the one CrazyCoder suggested.