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!!) that it bumped it up my agenda a bit. I don’t have to do merges / commits of that size very often – in this case the problem was wholesale license header changes for our MIT switch – but still, it’s totally unacceptable to have to deal with that. I raised a support request with Sourceforge, but I’ve seen other reports of bad SVN performance from several weeks ago from others, so I’m not holding my breath. It’s time to start considering alternative hosting I think.
I’m not done with my evaluation yet, because I just don’t have the dedicated time I really want to spend on this right now. But, here’s my early-stage results.
I’ve discussed before that I don’t like the where Git has come from. It’s overly complicated, Windows support was clearly not a priority, and it switched existing VCS terminology around just for the sake of it a lot of the time. It practically shouts “I’m different, live with it!” at you, which is frankly a typical elitist geek attitude and not one I particularly respect. This attitude permeates the documentation, reinforced by the absolute insistence of most tutorials that you need to understand Git’s underlying data model before you start using it. Er, right – sorry, but when normal people want to learn how to use a new tool, we just want to know how to use it, not how it’s built. If understanding how it’s built is a prerequisite to using it, then I’m sorry, it fails miserably at being user friendly.
Nevertheless, it’s fast, it’s efficient in storage, it’s the most popular & fashionable DVCS (probably due to GitHub) and that has weight. Of particular interest to me is that TortoiseGit has come along in leaps and bounds, and is really quite pleasant to use. Of course, the reason it’s pleasant is because it hides the majority of the nonsensical changes that Git decided to make to existing VCS terminology; for example ‘Revert’ in TortoiseGit does what you expect (undoes your working copy changes), rather than needing to use ‘git reset –hard’, which is only intuitive to those who live on Mars (git revert, in contrast, records a new commit to undo a previous commit – why the hell do you need a special command for that??). Thus, it’s an odd situation – using TortoiseGit is pleasant, but only because it ushers the underlying git behind a curtain and gives you what most people really wanted from it in the first place. The downside is that using TortoiseGit really doesn’t teach you how to use the command line very well, like most other VCS tools do. In fact, it may well mislead you into thinking Git is friendlier than it actually is. For example, it saves you from the ridiculous need to remember the “-a” argument to “git commit” – without which what you actually get in your commit is the state of the file when you did “git add”, not the version in your working copy. If that makes sense to anyone, raise your hand. Thought not.
Hosting & collaboration wise, GitHub seems very good.
Mercurial on the command line is nice. It behaves the same way centralised VCS’s do, except in the cases where it needs to be different. This is pragmatic design – not being different just to make a point, but being different where it needs to be. It doesn’t break old concepts and does what you expect it to, and contrary to what some people think, that’s a very valuable feature.
It’s not all roses though. TortoiseHg is clunkier than TortoiseGit, despite being based on a more intuitive core tool. The UI just feels a bit wrong (like putting action buttons on the toolbar – who does that?), and I’ve sworn at it for being unintuitive more than once. The other problem is that the Mac GUI tools are not really that great either – MacMercurial only allowed me to do a subset of the operations I needed to do, and Murky just crashed when I tried it. GitX in comparison works quite well on the Mac.
So despite a more intuitive command line and core concepts, and a more pragmatic approach generally to DVCS for ‘regular’ people, when it comes to GUIs Mercurial lags a bit now. This was unexpected to me since it is Git that has traditionally been poor on the GUI front. There are also a few other minor issues like branches being totally permanent and needing to be globally uniquely named, which can make local experiments more cumbersome.
Hosting wise, BitBucket seems quite competent, if a little less polished than GitHub.
I’ve only just started experimenting with Bazaar, and so far I’m quite impressed. It has the pragmatic approach of Mercurial, but also has a built-in GUI which is really quite nice to use and leads you through the initial setup and configuration. There’s also TortoiseBzr which feels somewhere in between TortoiseHg and TortoiseGit. I haven’t tried it on the Mac yet. Performance was always the issue listed as the major downside of Bazaar, but this has improved since 2.0 and while it’s not as fast as Git, it seems to be fast enough.
The main downside for Bazaar is adoption. It trails both Git and Mercurial in terms of the number of people using it, and therefore adopting it for a public project would have the disadvantage of making people use a tool they’re less likely to already be familiar with. Also for hosting, Launchpad is quite new; it looks quite good, and has more features than GitHub, but it doesn’t have the option to host private projects (not an issue for Ogre of course) or a graduated commercial plan – you can self-host of course but that’s not as easy.
Conclusions so far
The sad fact is that none of the 3 are an instant win for me; they all have positive and negative aspects. Summary so far:
|Git||Fastest & most efficient
GUIs actually good
|Command line overcomplicated & unintuitive
Mistakes easier to make
|GUIs a bit rough in places|
Built-in GUI good
TortoiseBzr also good
|Not very popular
Statistically the slowest
Launchpad is quite new
So, I’m basically in a no-win scenario. If I pick Git, it’ll work fine via the GUIs but it’s too easy to screw things up when using the command line, and I’m bound to get annoyed at the needless obscurity from time to time. But, lots of people will be happy to use it. If I pick Mercurial, I’ll be happier with the overall core concepts & command line, but the rough edges on the GUIs are going to annoy me day to day. But, quite a few people will be happy with it all the same. If I pick Bazaar, I’ll be happy with both the core concepts and the GUIs, but being the least fashionable option almost no-one in the community will be happy that I picked it over the other two, and lots will bitch about having to use another tool.
I’m reluctantly acknowledging that the least of the evils appears to be Git right now, even though I personally hate its underlying interface. Somehow it feels wrong to only like using it when it’s hidden beneath a GUI – I’ve been a regular user of the command line for CVS and SVN for the best part of a decade, and I like being happy with both modes. I can imagine tolerating Git’s command line, but never liking it just because of the unnecessary idiosyncracies (like commit -a).
I still have lots more detailed tests to do anyway, which will have to wait a month or so until I have more time.