A better release management strategy?

Question

I work for a company that makes a web based tool. As part of my job, I was given the task of release engineering for this product(something I had never done before). I've setup the following system using SVN(Sorry, we can't use another repository before someone suggests switching to GIT or perforce or one of the myriad of other options!)

Trunk is what is on the production servers at all times There are 2 branches open at any given time 1) Maintenance release. This is released every Wednesday 2) Sprint branch. This is released by weekly(on Wednesday with that weeks maint branch)

Prior to release I merge that weeks branches into the trunk.

I have found that when running svn merge, it usually creates a ton of problems when it merges. We have thus switched to a manual merging meeting once a week, which takes anywhere from 10 minutes to 1 hour, where I literally winmerge the 2 directories on my system and ask each developer "was this your change? which version of this code should we keep?"

This system definitely is NOT ideal.

Can someone suggest something better?

Answer 1

Your trunk branch should contain all of the latest development code, which includes new and untested features and any code from other branches. It is very important that all code gets merged into this branch.

When you're ready (or think you're ready) for testing, create a stable branch off of your trunk branch. Use this branch for testing and fixing bugs only. Do not add any new features or improvements to your application here, or it might destabilize your existing code. Do not forget to merge changes made in this branch into your trunk branch.

When you're ready to release (your testing is complete), create a release branch off of your stable branch. This is the branch you release into production and maintain/support if bugs/issues are found in production. As with the stable branch, do not add anything new to this branch. This branch is usually tagged in order to identify it in production. Do not forget to merge changes made in this branch into the stable branch, so that other release branches created from the stable branch get the benefit of any bug fixes made.

The branch hierarchy will look like the following:

trunk
|-- stable 1.0
  |-- release 1.0
  |-- release 1.1
|-- stable 2.0
  |-- release 2.0

Using this hierarchy, your development team is free to develop in your trunk branch, while the stable and release branches allow for maintaining current and previous versions of your application.

Answer 2

The statement "there are 2 branches open at any given time" is troublesome to me. At least in my practice branches are created for stabilization before a release or for bug fixing, and they are usually short lived.

My question is - what do you use the trunk for? It should not be what is on production, rather production should be running a tagged (therefore released) version.

Your merge problems are self-inflicted, as far as I can see.