Version Control Techniques

I’ve spent quite a bit of downtime of late thinking about version control systems. There has been a lot of talk at the NLUG about DVCSs, Martin even gave a niece overview of current systems and techniques, which has lead to me pondering usage models for VCSs. More recently some of the developers of Adium have been writing about a switch to DVCSs.

I am beginning to think that a better model for VCS, particularly in open source projects, is a centralised VCS for mainline/trunk with DVCS for individual developer branches with a push to the central repository when a feature is ready to be integrated.

If we use, for example, Subversion for the central repository with Bazaar-NG and bzrsvn we can have a central Subversion repository for Trunk from which developers clone branches using Bazaar to work on new features while users just wishing to test the latest code need only pull a copy of the Subversion repository. Releases can then be performed by tagging svn trunk and building from that tag, release management is an area which will likely be very hairy with DVCSs so the centralised repository for all releasable code makes sense from a project management viewpoint too.

I think this method will highlight the pros of both systems while reducing the associated cons.

Centralised pros:

  • Central place for latest, official, code which is easier to manage with permissions etc.
  • Simpler VCS paradigm for people only wishing to pull and build latest code, or any user who does not wish to commit changes.

Distributed pros:

  • Offline commits.
  • Merging.
  • Cheap branches.
  • No need for commit permissions.

Combinatorial cons:

  • Developers will have a slight learning curve in having to use two systems, this is the reason I chose Bazaar-NG – it has a very similar command interface to Subversion.

I spotted a link on Reddit this morning to a post by a Subversion developer hinting that Subversion 2 intends to implement the best features of DVCSs and, as far as I can tell, will result in a working model very similar to the one I have outlined here.


  1. If you replace subversion in your model with DVCS, but still have a policy that it is the “main” repository that people push to when things are stable, what do you lose?

    Nothing that I can see.

    On the other hand what you gain is consistency (same tool used everywhere) and most likely better stability (git and bzrs svn integration are both less than perfect right now in my experience)

    To me it looks like you have defined a good set of working policies, but that’s no reason to limit yourself to svn as the main repo.

  2. Martin, you make a good point – there is no reason to limit myself to Subversion. I can see the pure DVCS approach being a problem in some scenarios though.

    * DVCSs seem to be less well supported on non-Linux OS’s. Bazaar has a Windows installer but not a Mac on for example.
    * Server support; it’s much easier to find a publicly hosted SVN repository for an open source project than anything else. A lot of web hosts provide subversion support nowadays too.
    * Pulling from SVN is much easier if you just want latest code, there’s more to pulling from a DVCS as you probably don’t want the entire change history just to build the latest code. So you have to know how to limit revision history etc.

    Thinking on it further the pure DVCS approach will probably work for me and my projects, so long as I can find a decent place to host a bzr repository.

Comments are closed.