Subversion: Branch per Environment?

Question

I am currently working on a project in .NET which consists of several logical layers and multiple front-ends. Here is a rough representation of our SVN structure:

trunk
---doc
---lib
---src
------console
---------console.vbproj
------domain
---------domain.vbproj
------...
------web
---------web.vbproj
---.sln

All of our day-to-day development occurs in trunk - this is where all developers checkout from/commit to.

I am looking for a way to cleanly and easily deploy between environments (test and production).

My thought is to create two branches, test and production, from trunk - solution and all. I am justifying this to myself for the following reasons:

1. I have complete control over which modifications flow to which environments by only merging from trunk to the test branch and from the test branch to the production branch
2. I can easily see what code is executing in each environment by simply looking at the log of the corresponding branch in Subversion

Has anyone had any experience with a solution similar to this? Are there any potential pitfalls or oversights that I am missing?

Answer 1

Has anyone had any experience with a solution similar to this?

Yes :-)

Are there any potential pitfalls or oversights that I am missing?

You will face the problem that over time the test and release branches will drift away from the development environment as you will very likely not merge every change from trunk. The developers will then work in a slightly different environment and you will waste much time by keeping the branches in sync. This is known as the merge-mania anti-pattern.

I would rather advise to create a release branch from trunk for each planned release once you got all features for it implemented. At the time you branch both are equal. Then have a team to stabilize and test on the release branch. The development goes in parallel on trunk. Once your release was polished merge the fixes back to trunk.

Repeat the procedure for each release. This way you will limit the number of merges and have the folks working on something that always is the cutting edge.

I hope these aspects help you in your decision. The link also shows many other anti-patterns. Have a read to all of them maybe you'll recognize some lessons learned and will get some hints to solve it better.