subversion release management with TeamCity

Question

We currently use Subversion for our release management, and tag all of our releases (both to QA and to our production servers). However, we'd like to create a single Release directory reflecting our newest release instead. This way we can have TeamCity always pull from the same folder for continuous builds. Also, if someone has to make a quick bug fix to production, they won't accidentally make it to the wrong branch.

For example, below is our current structure with a 'release' folder added. Would there be an easy way to move a tagged branch to 'release' each time, or even have 'release' be a link to the newest release_* version?

Clarification

Here's an example of how our build/release process currently works:

• Today, I release a version of our web app to QA after TeamCity successfully builds it. When doing so, I branch/tag it
• Tomorrow onward, devs continue making updates in the trunk. These will not be pushed to QA until the next QA release
• On Wednesday, our QA team notifies us that they've found a bug. We make a bug fix on the QA branch, merge the change back to the trunk, and push the updated QA branch back to QA. ISSUE #1: TeamCity is no longer working for us since we're in a #'d QA branch
• On Friday, QA approves the release for production, so we publish and branch/tag
• On Monday, a client calls with an issue requiring a small change to production. We make the change in the release branch and merge back to the trunk. ISSUE #2: Once again, we're making a change without TeamCity helping us

Answer 1

I would (and do) take a slightly different approach to this. Source control management is primarily for, well, managing source and treating it as a means of tracking or implying releases can make life a little tricky. This is really the purpose of your continuous integration environment and it does a far better job of it than what SVN does.

I use TeamCity as the means of identifying both path and revision number to pull from SVN. It's easy enough to define this at build runtime and any release to production is always done with caution (i.e. carefully check both path and revision). In the absolute worst case, if you do screw it up, you can always re-run the build with revised parameters.

You really don't want to end up making code changes directly to a "Releases" folder - this is what the trunk is for if it's mainstream development or branches are for if you've had to adjust an earlier revision. It's sort of beating SVN into submission to do something that's not its core strength! On that front, you might find some of the tips in The 10 commandments of good source control management useful.