TeamCity - SVN Update?

Question

We use VisualSVN as our source code repository at work. I do not have control over it (Dev does) and I need to work my automation efforts around how they are currently using it.

Each application is broken up into different code branches which for how Dev currently uses it, also acts as its versioning. As such, I am deploying from a branch folder for each app in SVN as opposed to Trunk.

Some of them are builds that build out common files utilized by many other applications being developed and act as prerequisites for those builds. Because some of the repo's used contain multiple branches where one branch is used by one application and another branch for another app, it does not behoove me to setup TeamCity to do a clean/checkout and then have to rebuild all those branches again.

To get around this, I thought just un-checking the "Clean" option in checkout settings would rectify this. However I've noticed that simply unchecking the clean option does not necessarily translate to a simple SVN Update as it would occur performing the update manually.

Example: Manually, if I went into my checked out directory and deleted one of the code branch folders, I could then go back and do a right-click -> SVN Update on the root folder and it would detect I was missing that branch and pull it back down.

In TeamCity however, deleting a code branch folder out of the checkout folder and then rerunning the job, it does not detect that that branch is missing and recheck it out. The build of course fails and that's that. That makes me think that when a new branch comes into place, it won't check it out?

Am I missing some other parameter or obvious option to get TeamCity to perform this update?

Answer 1

I think using a build chain / snapshot dependencies in TeamCity isn't the right approach for your problem - eg. the JetBrains website suggests that,

The most common use case for specifying a build chain is running the same test suite of your project on different platforms. For example, before a release build you want to make sure the tests are run correctly under different platforms and environments. For this purpose, you can instruct TeamCity to run tests, then an integration build first and a release build after that.

Instead, using SVN Externals allows you to checkout your code and all dependencies (which can be anywhere else in the SVN repo, for example), and refer to the dependencies in your project with relative paths. The downside is that you will build all dependencies each time.

Alternatively, packaging your own NuGet packages (can be done by TeamCity) means your project references only the NuGet package (at a specific version), and thus doesn't need to build the dependency. You will need to setup a NuGet store, but this can be as simple as a shared folder.

The advantage of these approaches is that they work locally as well as in TeamCity - i.e. otherwise you'd need to manually build each dependency.