I’m continually surprised at how much discussion exists about how to manage releases and development branches in enterprise source code repositories. Many of the smartest, most experienced people I’ve worked with have come to the same conclusions about the best way to manage a source code repository. I suppose I just assume that everyone in the industry has accepted these strategies as a best practice, but maybe I’m wrong! I enjoy working with subversion the most, so my analysis assumes it is the tool being used to manage the repository, although the ideas can be generalized to most SCM tools.

I prefer to use this classic structure:
/repository/branches
/repository/tags
/repository/trunk

There are a few basic principles that define my preferred approach to SCM:

1) trunk is king. 98% of new development should be done against trunk.

2) trunk is always golden. All code builds and all tests pass all the time. Use a continuous build system to make sure trunk always works. Use a code coverage tool to make sure untested code breaks the build. If it’s not tested, it’s not complete and it should not be checked in.

3) Update often. Since trunk always builds it’s easy to update, do it so that you’re not working against stale code and merges become easier.

4) Check in often. Each time you get a new test to pass, get latest, run all unit tests, and check in. Early and often integration prevents merge problems and allows for increased collaboration.

5) No developer branches. Please don’t have a branch for each developer. The merges become a nightmare and it prevents people from collaborating effectively. Plus the current code-base is not readily acceptable until all the developer branches are merged. Really…it’s not a good idea.

6) Have refactoring branches. Ok, that 2% of new development that is not done in trunk is done here. Do major development that may destabilize the system on a refactoring or feature branch.

7) Tag when you branch and tag when you merge. All merges should be done from tag to tag, this makes it much easier to keep it straight when you need to update one branch with code from another.

Branch for releases. That way you can go back and fix bugs.

For projects that have many branches (and thus many tags) I advocate extending the repository structure like so:

/repository/branches/development
*This is where the feature/refactoring branches go

/repository/branches/QA
* For interim releases or hotfixes

/repository/branches/releases
* For end-of-iteration releases

/repository/tags/branch_name
* Put all tags in a subdirectory according to the branch they were tagged from, this makes it easier to identify for merges

/repository/trunk