Subversion and the Mainline Model

Subversion: Built for the Best Branching Model

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.

SVN Mainline Model

SVN Mainline Model

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 [1] 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.

 [1] The Git community uses the term topic branch.  Other names include task branches, development branches, and feature branches.  But I think topic branch captures the use case perfect – a branch that holds one small topic of work.

 

2 Responses to “Subversion and the Mainline Model”


  • Hi

    The trunk/tags/branches approach uses tags to mark specific revisions, allowing an easy access to a specific point in time of the repository.

    I believe that a developer should be allowed to commit the changes even when the code is not build worthy, but that does not fit the continuous delivery model. I’m afraid that developers are not allowed to commit small progress milestones or end of day status.

    What are you takes on this?
    Why not to use the tags to state what is build worthy?

  • There are some mechanical issues with tags (they’re really just branches in Subversion anyway).

    But the bigger issue is just the model: continuous delivery requires that tasks are very small and can be reliably tested and put into a release pipeline rapidly. Otherwise you have code lingering in feature branches.

    If you just need a place to store work in progress you can use private branches or shelves (or their equivalents).

Leave a Reply