Over the years Subversion has taken a few lumps for its branching and merging tools, but the latest release has fixed a key problem, and it’s worth remembering that the workflow Subversion supports best is also the best workflow: the mainline model. This model is the recommended approach in the continuous integration and continuous delivery communities. In this article we’ll look at Subversion and the mainline model from a high level.
Most of the workflows that are popular in the Git community can be used for SVN as well; even if the implementation differs, the mainline model is just about the same.
In the mainline model, you have very few long lived branches. Most commits happen directly on trunk, and developers are encouraged to commit frequently. Avoiding long lived feature branches ensures that integration happens sooner rather than later, avoids painful merges, and gives you all the benefit of continuous integration practices.
The diagram above shows what your branching model looks like if you’re a true believer in the mainline model, meaning you don’t branch until you hit a release point and need to start isolating bug fixes from new development work. Topic branches  are used for very short periods of time, primarily to give developers a private area to save work before committing to trunk. Topic branches also are natural points for pre-flight code review and continuous integration.
If this simple diagram looks familiar, it’s because it’s the model that Subversion was built for, matching the familiar trunk/branches/tags layout of a Subversion repository. As of Subversion 1.8, Subversion’s merge engine handles this model well. Merges are primarily done to keep a topic branch up to date, and since a topic branch only lives for a very short time, the merges are easy. Similarly, symmetric merges between trunk and release branches are handled very well.
It’s also worth recalling one of Subversion’s perennial strong points: making branches is cheap and easy, requiring only one command or a few clicks in a Subversion GUI. There’s no overhead with Subversion branches, so developers can make as many private topic branches as they like without incurring any penalties. Making a lot of very small, short-lived topic branches is a much safer practice than working on a few big feature branches. Similarly, you can tag (make a read-only branch) at any point to indicate key milestones. If making a branch is hard in your SCM tool, or you’ve been warned not to make too many branches in order to avoid a performance problem, then you should take a look at Subversion or Git. The open source SCM tools have solved this problem.
Subversion’s merge engine may not be perfect, but it works very well as part of a continuous delivery system. If you have an elaborate branching model with multiple levels and a lot of sideways merges, no merge engine will save you from eventual trouble. Not only will your revision graph look like spaghetti, but you’ll eventually run into bigger workflow and process problems.
And of course, you can scale Subversion to support a large distributed software team using WANdisco’s suite of MultiSite products. The mainline model isn’t limited to a small co-located team anymore.
Trying to figure out the best way to deploy Subversion? WANdisco has a team of SVN experts waiting to help!
Subversion is a registered trademark of the Apache Software Foundation.