I was thinking the other day about how many version control systems I’ve made my way through over the years of being a professional developer, and I figured it would be fun to put it in graph form. Of course, this is entirely from memory and gives the illusion of being more empirical than it actually is, but hey, everyone loves graphs, right? Yes, I really didn’t use any source control back in 1994, barring backing up to 3.
I’m pleased to announce that I’m finally ready to make my first fully-fledged commercial Mac OS X application available to the world! SourceTree is a user-friendly Mac OS X front-end for Mercurial and Git, the two most popular distributed version control systems used today. The goal was to create a single tool which could deal with both systems efficiently, and to give a developer quick and intuitive access to the things (s)he needs to just get on with building software.
I’ve already posted about my experiences with Git and Mercurial, the end result of which was a vastly increased respect for Git but a basically confirmed preference for Mercurial, based on ease of use, platform consistency and resilience. Mercurial’s conversion tools are really quite good - the core tools worked fine but I was impressed by hgsubversion’s speed and that it seemed to just work, in both initial conversion and pulling subsequent updates.
So, I’ve just about completed my practical experiments & review of Mercurial and Git.
In the end, I had far too many separate notes and sets of experiences to post, so I boiled the argument down into the 10 most important factors to me, and scored Mercurial and Git on a scale of 1-5 based on what I’d found when using them. Here are the (annoying) results:
|1||Ease of use - command line||4||5|
|2||Ease of use - GUI||4||4|
|3||Platform support - core||3||5|
|4||Platform support - GUI||4||4|
|5||Web Host Functionality||5||4|
|6||Reliability & error handling||3||5|
|10||OGRE Community support||5||4|
I’ll explain the scores, and my conclusion, after the jump.
As you know I’ve been reviewing DVCSs lately. I’m taking my time doing real use cases on them, and deliberately not doing the sort of feet-first leap into whatever looks best / most popular on the surface because I don’t particularly want to discover unexpected problems down the track. It’s consuming a lot more time than I expected - I’m writing up my findings and may publish the entire results later on if I can find the time to clean them up and format them better, but for the moment I thought I’d share some experiences with the conversion process of a relatively large, long-lived, multi-branch repository (OGRE) from Subversion to Git and Mercurial, because that’s what I’ve been wrestling with in the last few days.
A few weeks ago I decided to start seriously investigating switching to a DVCS. I’m currently up to my eyes in work and haven’t really had time to progress that in the last few weeks; however some absolutely abhorrent performance / reliability problems with Sourceforge’s Subversion server made a large merge process so costly to me (in the end I had to commit in small chunks, breaking transactional consistency, and it needed so much babysitting because of the speed / reliability it took me 4 bloody hours just to commit!
Ok, so I’ve posted my initial feelings about tinkering with Mercurial and Git, and that seems to have generated some interest. It’s time to get a bit more formal about how I’m going to evaluate them against each other, to decide which one I like to use most in real, practical scenarios. So, I decided to come up with a list of use cases for the things that I typically have to deal with when managing the repositories for a software project (open source and otherwise), so that I can methodically test them out and see how I feel about each system.
I’ve been interested in DVCS for a while; having done my fair share of branch management, something which makes that process easier and more transparent is definitely very attractive. I particularly like the way a DVCS makes it easier for people to collaborate in pockets of their own, away from the centralised environment, and track other repositories and keep their local mods up to date more easily - public-branch-on-demand if you will.