Wednesday 7 April 2010

Time to get with distributed versioning

I decided to bite the bullet and get on board with a distributed versioning system over Easter.

There were a number of reasons for this. Firstly other developers at ILRT were using it and extolling its virtues, the primary one for me being that DVCS is by its nature more in keeping with the open source ethos. In that its architecture promotes a communal distribution of the source, there is no overall control via a central repository and HEAD, but instead there can be many distributed repositories with their own 'TIPS' and an original set of source code can more easily evolve for different use cases. So its ownership is more open.

Another reason is that it seems to have gained a lot of development effort in the last few years, with the two leaders Mercurial and Git gaining features more quickly than the leading versioning system in the open source world, SVN (which in turn supplanted CVS). The other advantages of DVCS are the more mundane ones of performance and convenience. Since there is no need for server access when checking in changes etc. then this can be significant. Instead of directories stuck all through your code you just get one or two at the top level holding the whole repo for that code locally.

So which DCVS have I gone for. I basically used the same reasoning as Google Code which has plumped for adding Mercurial alongside SVN, ie. it is easier to learn when coming from SVN since the basic commands are the same. It has wider platform compatibility / tools (e.g. TortoiseHg). Along with the fact that its all python which I know well, and that Google Code has chosen it along with BitBucket already being available. Making two of the main open source hosters Mercurial to GitHub's one. Having said that I found using it on Google Code problematic and  its interface less intuitive than BitBucket's so I have plumped for that as my open source hoster. Its also got a cooler name - and offers Basecamp integration which we use.

Currently I am just moving in my public open source projects that are not already available in a public SVN repo (ie the plone collective). I guess time will tell whether it makes sense to pay a few dollars a month to use this hoster for private repos too, or to set up Mercurial locally with integrated wiki and issue tracker.