Subversion Best Practices: Branching and Merging (because we've been doing it wrong all along)

Despite having read the chapter on branching and merging in the svn book, and spent a lot of time thinking about how it should be done, the subversion repository structure at both my current job as well as my previous one have left something to be desired. Branching and Merging never quite worked as nicely or smoothly as it was supposed to. Eventually we just looked at how the Apache project did it and the correct method became clear to us and although we are not suggesting exactly what they're doing (they have active development happening in several branches) it took looking at their project to make the light go on.


The Old Way

1. Trunk was supposed to mirror what was in production, although we were never actually able to achieve this which sparked the many discussions about how else we could do it.
   
2. All Development happened in a numbered branch and a new branch was created for development every time we wanted to push to testing in preparation for staging (which made for messy SVN logs and much difficulty with Merging caused by confusing ancestry).
3. Bug fixes would be made to the old development branch which would then require us to either make the same bug fix to the new branch or merge the old branch up and then back down into the new branch or even a merge directly across between the 2 branches, all of which added to the mess in some way causing conflicts or ambiguous ancestry.
4. Tags were made when something was pushed to staging/production but it was unclear how/when these tags should be created.
5. It was confusing to explain the branching procedures to new people and difficult to enforce/maintain.

The New Way

1. Development occurs in the trunk. Trunk is ultimately the development branch itself. The majority of development will occur in the trunk.
2. Branching occurs when:
   
   1. We want to create a release of current feature set. This can be done as a Tag, or a branch and a Tag. The latter method would create a branch for doing bug fixes and new tags would need to be created for that branch every time a set of bug fixes are pushed as a release.
      
   2. Development of a new feature would seriously disrupt normal development
3. Release branches will be pushed to Testing, then to Staging and finally production. Bug fixes to these branches will be done within the branch and then merged up into the trunk. This way bug fixes are always included in the trunk (dev) and there is no messy merging across or down from trunk into a current dev branch.
4. Every set of fixes/changes made to the old branch are tagged so we know which version contains which set of fixes.
5. Easy to explain to new people.
6. Easy to maintain.