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 thought I’d answer a few background questions on this that I get asked on occasion:

Why Mercurial AND Git?

Other apps tend to concentrate on just one version control system, so why am I supporting two? Well, as a developer I’m regularly coming across projects from both sides of the fence, and in practice I find I need to use both fairly regularly. I personally chose Mercurial for my own projects (and discussed why here), but I still use Git when dealing with other projects, and spend a fair amount of time hopping between the two. It struck me that even though they have their differences, they are both based on the same distributed principles, so having to use two separate tools was just unnecessary. I wanted a single tool which provided a common interface where that made sense, while still exposing the things they do differently where that was useful too. SourceTree 1.0 is my first attempt at that.

Why only Mac OS X?

There were actually multiple reasons for this choice:

1. I wanted to learn Objective-C and Cocoa on a real project
2. I know from experience that designing for multiple platforms can be a distraction, with more time spent on compatibility issues, and less on functionality – and that’s before you even consider the compromises  you have to make, particularly on UI conventions which are far from uniform across platforms. I’ve been a multi-platform developer for more than 10 years, and for a change I just wanted to focus on the end user results and nothing else. I’m aware that schedules slip very easily when you overcomplicate, and I’m already supporting multiple DVCS systems (something I consider to be an important feature point), so I deliberately chose to keep this element simple.
3. Mac OS X has become my own platform of choice for most things now. The combination of stability, user-friendliness, Unix underpinnings and well designed hardware match my current needs perfectly. I’m done with the ‘some assembly required’ PCs that I loved tinkering with over the past 15 years

What about Subversion?

A few people have asked me if I plan to add Subversion support too. I actually did intend to originally, until I realised how much time it was going to take to just do a decent job on Mercurial and Git. Within the time constraints, I focussed on the subject areas that I felt I could contribute most to – there are already quite a few Subversion tools out there for Mac OS X, but Mercurial and Git are much less well served, so that’s where I focussed my efforts.

I still have Subversion support tentatively on my work plan, but it’s not top of the list. I think it’s better to do your most important features well before diversifying. Plus, there are problems with Subversion – it’s very, very slow compared to Mercurial and Git, so to match the performance in SourceTree of things like the interactive searches and dynamic refreshing / log population I’d probably have to do a ton of extra caching just so the user wasn’t sat tapping their fingers.

Edit: I made my decision on this: I don’t plan to support local Subversion, but to support operating with Subversion servers with Mercurial and Git locally via hgsvn and git-svn.

Why didn’t you make it open source?

Sorry folks, while I love contributing to open source (I’ve done a bit on SourceTree too, sending a patch back to BWToolkit), making it work as a business is very hard indeed. I half-killed myself trying to combine being an open source project leader and doing other commercial activities at the same time, so now I’m trying a more traditional approach. One thing I learned in the last few years is that there are some sectors & application types where being an open source maintainer is very compatible with also running a business based on that project, and there are others where you can really only do one or the other simultaneously without flaming out. Sucks, but there it is

What’s Next?

I have a public, official roadmap for SourceTree and encourage users to suggest things they think should be on there, via the support system. I learned from running an open source project for 10 years that being open about your plans can be a big benefit – users like to know where things are likely to be going, and often have better ideas than the developer on what could do with a bit more spit and polish. They can also tell you what’s important to them, which is crucial for prioritising – as developers we tend to get carried away with things we want to work on, but in the end, it’s scratching the customer’s itch that matters most.

And while I’m really quite proud of SourceTree 1.0, there are plenty of features I’d like to continue to add, and definitely more room for some totally unnecessary beautification which I didn’t have time for in the first release. Hey, this is OS X

SourceTree is available now on a 21-day trial license. Go get it already

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. It was missing a couple of features that I wanted though – firstly the ability to reflect merge points between branches during the conversion, and secondly to be able to ‘squash’ ancient history down to a simple snapshot to save space.

At OGRE, we’d carried forward all our history from CVS to Subversion and as such have almost 8 years of history, including a couple of file reorganisations. Mercurial’s storage efficiency falls down compared to Git when files are moved around, because a file stored in more than one place in the tree over the history of the project is physically stored multiple times too, whilst Git stores the content only once with pointers from the various locations / history points. Most of this overhead could be removed just by eliminating old history we didn’t need anymore – history that does no harm in Subversion since only the server holds it, but does cause unwanted overheads in a DVCS since every user gets the entire repository. Removal of history is something that Mercurial shuns – rightly so in the case of public repositories but in these rare cases it would be nice if there was a tool for removing old history; again Git allows this but it has to be used with care. In the absence of that, doing it at conversion seemed the best way.

I asked about these things in the hgsubversion community, but the tradition of open source is that if you really want something urgently, you know where the code is Mercurial is really nice when it comes to hacking because it’s all Python; so there’s a nice unified API in one place that you can refer to – that’s one of the reasons I like it over Git which is far more fragmented in technology terms. I’m not a Python guru by any means, but I managed to implement both these features – I did the “mergemap” support a little while ago and added the “skipto” option today – it’s called that because “skipto” was already referred to in the hgsubversion code but it had no implementation.

The result is that the OGRE Mercurial repository with only the last ~3 years of history (back to when the v1.4 branch was created) is now only 74MB, rather than the 206MB of the original, complete conversion (in comparison Git was 116MB for the whole thing). By dropping the history I’ve removed most of the instances of reorganisation which is where most of the space has gone. I  hope eventually that Mercurial adds a utility to deal with stripping ancient history (right now, you can only strip branches) but this solves my primary conversion issue. Since this new repo can be kept in sync in a very lightweight fashion with the existing Subversion repo, I’ll be periodically updating it and doing more tests to reassure myself that the content really is ok.

If you’d like to get my custom version of hgsubversion with these features, it’s here: http://bitbucket.org/sinbad/hgsubversion/. I make no promises that it’s error-free, use at your own risk. It currently assumes that you’re using the standard Subversion layout, are converting from the root of that and have the ‘svn’ command on your path.

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:

I’ll explain the scores, and my conclusion, after the jump.

1. Ease of use – command line

This criterion boils down to how easy is it to learn to do all the operations required of a typical developer, many of which I’ve listed in a separate thread, how consistent and intuitive those commands are, how natural the defaults are, and how easy it is to screw something up by accident. This is by nature a subjective measure. While Git improved greatly in my perception during the course of the evaluation, there is absolutely no doubt that the command-line of git takes more time to learn to operate effectively than Mercurial does. I deliberately learned Git first to avoid being biased by a command set that was closer to what I was used to, and grew to be happy with most of the Git commands, but it took me longer and I had to refer to the help and Google for things more often. The included help in both is good, but git has a lot more options (hence the win on flexibility later) and lots more discussion on edge cases and how the physical repository implementation is affected, which may be interesting technically but can cloud the issue when you’re trying to learn how to do something. Unusual terminology also confuses people from other systems – “git reset –hard HEAD” is simply not as intuitive as “hg revert –all”  for the migrators. I felt more comfortable with Mercurial’s command-line faster than I did in Git, despite learning Git first. I did, however, feel that I could use Git fairly happily after going through the learning process, and my attitude towards it moderated after some experience – this is why there is only a single point difference between them – if you’re at the start of the learning process Git is probably a 3 rather than a 4.

2. Ease of use – GUI

Linux users typically care less about this than those on Windows and Mac, and since I rarely use Linux on the desktop I’ve concentrated on Windows and Mac here. I tried TortoiseGit, GitX, TortoiseHg and Murky (SmartGit is another but it wasn’t considered stable when I was looking). In practice I found both systems to have shortcomings; on Mac the GUIs are still quite limited in functionality, and on Windows there are some things that work better in TortoiseGit (it feels like other Tortoises so initial impressions are superior to TortoiseHg which is a different layout), but TGit also has some bugs (such as not listing all branches in Switch if there’s more than about 20) and relies on msysGit which is not ideal especially when you need to abort an action and it leaves a git.exe lying around locking files. In practice they’re all about equal in their imperfections, no clear winner. I’m sure they’ll both improve over time but both are usable now, with users needing to drop to the command line for more complex tasks (see point 1).

3. Platform support – core

This is about whether the core toolset runs well across at least Windows, Linux and Mac OS X. This covers not only the ability to run on each of the platforms consistently, but also to exchange data between the platforms without issues and deal with line ending differences etc. Git came of worst here, because it is inherently designed to require a Unix-like environment, built as it is on common Unix tools like the shell and perl. On Windows it requires msysGit which in most cases works (I tested with 1.6.4 and 1.6.5) but is both significantly slower than under Linux – something you only notice for large operations but it’s up to a factor of about 6 in my tests – and still has bugs. git-svn for example is completely unusable on Windows in my experience against non-trivial repositories – the Ogre repository killed it consistently. Also the core Git developers openly admit that they don’t care much about Windows support, so commitment to the platform isn’t there. Mercurial on the other hand runs on Python and in my tests operated identically on all platforms, and is officially supported wherever Python runs. Both systems handled automatically converting line endings and did a better job than Subversion (which requires properties per file).

4. Platform support – GUI

So does either system support the platform range better than the other via the GUI? Not really – as mentioned in the ease of use section they’re both pretty good but still a little flawed in places. On Windows you still require msysGit even with a GUI which makes Git a little slower than on other platforms, but TortoiseGit is surprisingly good considering the vibe of general disinterest in Windows around Git. GitX and Murky are competent if limited on Mac OS X. Both systems have a core Tcl/Tk interface if you really need it, but honestly anyone in the slightest bit sensitive to nice GUI design won’t want to touch them with a 20 foot barge pole, they’re ugly - Tcl/Tk makes Windows 3.0 look shiny in comparison. No clear winner here.

5. Web Host Functionality

A few online services have sprung up to support the DVCS workflows better than simple hosting on Sourceforge or Google Code. Everyone seems to talk about GitHub all the time, but while it’s very pretty, functionally it’s soundly eclipsed by Gitorious which has considerably more robust support for dealing with merge / pull requests, handling them much like a patch tracker but with repository-aware, multi-revision URLs and inline reviewing instead of patch files. They also allow integration of contributor license agreements. GitHub in contrast only allows fire-and-forget pull requests or generalised browsing of commits people have made to other forks, which is not as useful.

BitBucket (for Mercurial) is functionally pretty much the same as GitHub (including the fire-and-forget merge/pull requests and general fork lists), except that it’s not quite as flashy. If we were comparing GitHub and BitBucket, the scores would be the same since aesthetics are not very important in the grand scheme of things, but Gitorious ups the ante, which is why Git wins in this category. I’ve actually talked to the guys at BitBucket, who are extremely friendly and eager to help, and Gitorious-style merge requests are on their TODO lists. They even offered to bump it up their priority lists if it was important to us. Very helpful chaps, but Gitorious still has to win based on the current status.

As an aside, it’s also worth noting that Launchpad is also extremely good in the merge request tracking area, on par with Gitorious. I dropped Bazaar from my evaluation due to lack of time and because it’s the least popular of the 3 in our community by a massive margin (and also, I don’t like the branch containment model they use very much), but Holger played with it and it’s clear that Launchpad deserves a mention for nailing this feature set very well. GitHub may be the poster child, but functionally others deserve more attention.

6. Reliability and Error Handling

As a wise man once said, sh*t happens. How easy a system is to break, and how it behaves when things go wrong is just as important as how well it works under normal operating circumstances, especially for something as critical as a source control system. I didn’t specifically go out of my way to cause problems, but during my many use cases I did encounter some sticking points, which was precisely the point.

Q. How often did problems occur? A. On Mercurial, I never had a crash, on any platform, that I didn’t accidentally cause myself. The two crash incidents I had were during conversion from Subversion, and were caused by firstly an rsync kicking in and changing the source Subversion file system under the feet of the conversion process, and secondly when I killed the process manually because I wanted to interrupt it. So in essence, I have yet to see Mercurial fail unless I break it. On Git, I normal operations behaved fine but during conversion from Subversion I had many problems. Git 1.6.4 and 1.6.5 on Windows regularly crashed mid-conversion, as did Git 1.5 on Linux. Git 1.6.5 on Linux behaved better, but only if you upgraded the (admittedly old) Subversion 1.3 repository to 1.5 or 1.6 first. Mercurial on the other hand seemed to cope with any combination I threw at it, on any platform.

Q. How good was the error reporting, and how easy was it to recover? On Mercurial, when I did get a crash (self-inflicted) I got a full Python stack trace with an exception message which was consistently useful, allowing me to quickly rectify the issue. The repository was also valid even in those cases. On Git, all the crashes I had on Windows and Linux simply resulted in the process terminating with no message. I only managed to figure out how to resolve the problems through trial and error, Git was absolutely no help. The repository left behind after these crashes was corrupt.

So, my personal experience was that Mercurial was very robust, and in the rare case of a problem it reported it well. Git was ok most of the time, but some operations were fragile and for example only a very specific version & platform worked for converting the OGRE repository. When Git did fail, my experience was that it didn’t report any useful errors and it basically left you high & dry, scrabbling on the net for answers. Mercurial wins this one outright based on my experiences.

7. Storage Efficiency

A simple one to measure – after converting the 375MB OGRE repository to both systems, and before any custom pruning, Mercurial was about 200Mb and Git about 180Mb. A manual pruning operation by community member guyver6 brought the Git repository down to 116Mb; after pruning out branches in Mercurial I only managed to remove about 7Mb. It appears that the primary reason for that is that moved binaries end up getting stored twice in Mercurial, while Git only stores them once once the data has been packed. Mercurial always packs its data as you operate on the repository, while Git lets its storage get sub-optimal in size while you’re working on it in order to give you maximum run-time performance, and ‘git gc’ needs to be run every so often (some commands do this automatically) to re-pack the data for storage efficiency; which is best depends on your point of view, whether you prefer a uniform behaviour or a split behaviour. But overall, Git wins here. In OGRE we actually have a number of moved binaries in our history which Mercurial clearly does not store as efficiently as Git does.

8. Run-time performance

This was a bit of a mixed bag. I found that Git on Windows was a poor performer on local batch operations that were not constrained by the network, compared to Mercurial. On Linux or OS X performing local operations, performance was practically indistinguishable between the two. Bulk operations that did require network access were a little faster using Git, but not by much. When it came down to everyday operations, the slightly slower msysGit for local operations, and the slightly slower network performance of Mercurial, were barely perceptible. A wash, both systems are fine.

9. Flexibility

When you need to do unusual activity X, can you do it? In Git, the answer is almost always ‘yes’ – it has an enormous number of commands and options and doesn’t really stop you from doing anything, even if it’s a bad idea. Mercurial on the other hand defaults to being quite strict, but there are a number of extensions, both official and unofficial, that can bring the functionality fairly close to Git, but not all the way. A few examples:

Local branches: this is a very useful feature of Git, where you can create lightweight branches in your local repository that you can use for experiments or patch processing without having them become a permanent part of the upstream history. Mercurial branches are all permanent by default, unless you use the LocalBranch extension which is not official. You can replicate the behaviour to a degree with Queues, which is official, but it’s more complicated. Git is better here.

History Modification: changing history is a very bad idea if you’re upstream of anyone else, but in a local private repository it can sometimes be useful. Git provides features such as rebase –interactive in which you can squash together and reorder commits to reorganise them before upstream submission, and filter-branch to make wholesale changes to the history, for example post-conversion to simplify the repository. Mercurial has basic support for some history modification (MQ again, and unofficial extensions like histedit), but they are not as flexible. Most of the time this isn’t an issue, but occasionally it can be limiting – for example I have not so far found a way to remove history before a certain date (or collapse revisions together before a certain date) – the unofficial histedit and collapse extensions do not work for this and MQ won’t let me import regions for qfolding that exist before branches are taken (which is what I want to do – I need my more recent branch history, I don’t need the old stuff). I don’t understand this restriction, I’ve already stripped all the early branches so the early history is entirely linear, why should it care that there’s a branch taken later on?

So, Git wins here. In everyday use you won’t care about this, which is why there’s only a single point between the scores when otherwise Git might deserve a 2-point lead here, but certainly when you’re doing uncommon things Mercurial puts more barriers in your way. In day-to-day operations that’s probably a good thing, since it encourages you not to do stupid things. But when you have a specific need to do something for a very good but rare reason, it’s annoying when you can’t.

10. OGRE Community Support

We ran a survey on this to see what people were using already. Git tends to get a lot of fans talking about it, but I’m also very aware that evangelists aren’t usually the best people to listen to. By asking people what they used practically, rather than which one they thought they might like to use, I hoped to tease out usage numbers. Of course, popularity is no guaranteed measure of quality, but it’s a reasonable indication of how each system might be received by our community. As it turned out, and not unexpectedly, most people had only seriously used one of the DVCSs and liked the one they were using, but had no real view on any of the others.

The sample wasn’t huge – only 64 people voted (but pleasingly a power of 2!) – and the numbers were as follows: Git 52% Mercurial 41% (Bazaar 8%). This nicely translates objectively into a score!

Conclusion

Well, this is annoying. My 10 criteria actually resulted in equal scores – trust me, I didn’t fake this; I thought very hard about these scores because I found myself being indecisive between the two systems because they both had positive and negative aspects, and I figured the only way to resolve the overall result was to try to score them and let math solve the problem. So much for that idea – it seems when I set them out numerically they are as balanced as they were more abstractly in my head.

So in the end, it comes down to the relative importance of these 10 items. I tried to pick 10 things that were of roughly equal importance to avoid skewing anything, but if really pushed I’d have to say that consistency across platforms and confidence in the reliability and error reporting has to be more important to me personally than most of the other factors. The one exception is the storage size – I want people to clone the source repository so they are encouraged to get involved in development, and I’m aware that the larger it is, the more that’s a disincentive. 200MB is pushing it a bit, and it’ll only get larger – and according to Mercurial’s specs that’s already compressed. In comparison, right now according to my measurements someone grabbing our Subversion repository has to transfer about 48MB of data (compressed) per branch over the network, so Git’s 116Mb (again, compressed) is looking very attractive compared to Mercurial’s heft.

I think that if I can find a way to reduce the size of the Mercurial repository to around 100MB, perhaps by stripping the old trunk history somehow (stripping old branches doesn’t appear to have made a great deal of difference), but while still keeping branches after this point, I’d go with Mercurial just because on balance it behaved more consistently for me. If I can’t, I’m still annoyingly on the fence becuase 200Mb feels too big, but I can’t afford to trash all my history or branches. There is lots of talk in the Mercurial wiki about shallow clones and potential history trimming extensions, but nothing seems solid right now. Anyone have any suggestions?

Source Subversion repositiory specifications

Revisions: 9215 (as of today)
Branches:  9 permanent, 22 temporary / experimental
Size: 375 MB

Also of note is that the source repository is still at Subversion 1.3 – this is because Sourceforge was stuck on this version for a long time and we haven’t upgraded the repository since they started supporting newer versions. We never bothered because it requires locking out the repository while you download the whole thing to a local machine, upgrade it and re-upload it, which is a hassle, especially when you have things to do. In practice the server-side version hasn’t been a major issue since you can still use newer clients with it and svnmerge operates regardless.

General Approach

I rsync the OGRE repository down to a local Linux server several times a week, so that was the source of all my conversions, eliminating most of the network time. I tried to convert the repositories using Windows clients in the first instance, because that was easier to use the latest versions of the tools (my Linux Server is on Ubuntu 8.04 LTS and even with hardy-backports available it’s not as up to date – and for simplicity because this is an important server I stick to the official versions). There is a 1Gb network connection between the machines so it could be pretty speedy.

The principle is that I want to preserve all history, all branches, and all tags. In practice I may actually prune off some branches later on, so that the clone process is quicker, but the base principle is that it should be a lossless conversion in the first instance. Definitely no top-skimming of the trunk like some conversion articles advocate – we have stable branches that must be maintained and regularly have work that we want to keep in experimental branches. In particular, post conversion it must be possible to continue committing to and merging from stable branches.

Git Conversion Experience

I’d previously converted some other, small and fairly simple Subversion repositories using git-svn (less than 500 revisions, and 2-3 branches) and it worked fine. However, when trying it against the considerably more complex OGRE repository I hit problems very quickly. On Windows, using msysGit 1.6.4 the process failed after 1900 revisions, just after doing the automatic repository tidy (git gc). The error message was simply ‘fatal error running git-svn’, even though it had been running exactly that command for the last 1900 revisions. Thinking there might be an msysGit issue here, I switched to the Linux server (git 1.5.4) and tried the same thing. This time it fell over at revision 176 with absolutely no error message. In both cases the repository left behind was corrupt so I could not resume the process.

The other thing I noticed was how long the process took on Windows. 1900 revisions took 5 hours (!) and thus I wasn’t in a hurry to retry the process there. On Linux the process was much faster, as far as it got. It’s worth noting that this is not caused by running across 2 machines – not only do I have a very adequate 1Gb link, Mercurial managed significantly faster conversions using the same topology. msysGit’s git-svn conversion is simply incredibly slow.

At this point I decided to try upgrading the Subversion repository, just in case git-svn hadn’t been tested with older repository versions. My Linux server had svn 1.5 on it, so I upgraded the OGRE repository to that locally and re-ran the git-svn process on the Linux machine (as I say, I wasn’t keen on repeating the glacially slow msysGit conversion). Sure enough, this time all 9200-odd revisions converted fine, in only about 1 hour 40 minutes, or about 15 times faster than doing it on Windows.

So, I may have had a few problems, and being forced to upgrade the repository before converting was a bit of a pain, but at least it worked and was fast (on Linux anyway). After that, I started cloning the repository both on Linux and Windows and tried performing some standard operations.

The first thing that surprised me was that when cloning the converted repository, I could only see the ‘master’ branch on the remote machine. It’s common practice for Git not to create any local branches other than master on clone, but usually you can do ‘git branch -a’ to see all the remote branches that are available, which show up as something like ‘origin/v1-6′ – you can then check them out to local branches. However, no branches other than ‘origin/master’ showed up, even though I knew they’d been converted. It turns out that git-svn converts all branches except master into remote branches in the converted repository, referencing the original Subversion URL – so very much like having cloned from another Git repository. That sort of makes sense, but in the context of a full conversion to a repository that is destined to become the upstream master, isn’t that useful. In practice what you need to do is after the git-svn conversion is complete, git checkout each of the branches that you care about in your converted repository, thus creating local branches in that repository which subsequent cloners will be able to checkout themselves.

So, once I’d figured this out I started to check out different branches to test if it had worked. At first it seemed to, when checking out the first branch (switching from master to v1-6 in a local clone from the conversion). When I came to try to switch back to master however, Git complained that I had modified files in my working directory. WTF? I’d only just checked out the clean copy of the v1-6 branch. But sure enough, git status told me I had 5 modified files. Diffing them showed no changes, and “git reset –hard” returned with no error, but git status still showed these files as modified. Bizarre. A git checkout -f still let me switch, but again after completion a set of other files showed up as modified. Switching back and forth (with -f) a few times revealed that the list of modified files after checkout was different each time. Again worried that this was a Windows thing, I tried checking out on my Linux machine instead (so at that stage the entire process, conversion to checkout, was done on Linux). But no, the same problem occurred – a random selection of 5-7 modified files on clean checkout.

This has raised some serious concerns about using Git for me. Firstly the flaky conversion which requires a bunch of extra steps just to get it to work at all, then the post-conversion bizarre behaviour of thinking files are modified when they’re not. I had none of these problems with smaller repositories, created from scratch or converted, which up until now I’d been using for testing (and Git had been winning me over in fact since it had been working well). But the bottom line is that this process needs to work reliably for the OGRE repository. If it doesn’t, it’s pretty much untenable.

Mercurial Conversion Experience

I started off with the in-built ‘hg convert’ process. It all went smoothly and took about 8 hours, and the resulting repository was mostly fine. However, the default behaviour is to process the revisions in an order which “produces the fewest jumps between branches in the commit log”. In practice, I found that this meant the revision log when reviewing multiple branches was badly jumbled and difficult to use; the use of the ‘–datesort’ option resolved this but increased the conversion time to just under 10 hours (still faster than msysGit but a lot slower than git on Linux).

The guys from BitBucket, who I’d talked to to see if they would offer free unlimited hosting for OGRE since we wouldn’t fit in the default 150MB limit (result was that they were super-friendly and offered not only that but lots of advice), suggested that I try hgsubversion instead. I was initially put off by their website suggesting it wasn’t fit for production use (they’ve removed this statement now), but BitBucket told me that was a little out of date, and in fact the Python project is using it for their conversion, which is obviously of major size. So, I gave it a shot and got some good help from the hgsubversion guys, and the results were great – 1hour 40 minutes from the Windows end (coincidentally the same speed Git managed on the local Linux machine), and the log view was properly ordered right off the bat.

The one remaining issue I had (and this is true of git-svn too) is that all of the branches are open-ended on conversion – that is, no record is made of merges that have been done between branches. That means you would have problems continuing a branch and then merging it, because Mercurial would think it has to merge everything from the point the branch was taken. Neither svnmerge or svn:merge properties are taken into account.

One way to resolve this is to manually create a merge point to close off the branches. The easiest way to do this is:

• Grab the default tip
• Open a command line and define a temporary environment variable “HGMERGE=internal:local”. This means that you want to keep the local files and throw away the other source when doing a merge, which is important for our dummy merge
• hg merge <source_branch> -y
  
• commit – only the .hgtags file should be modified, the rest of the commit is merely metadata alteration to close off the source_branch

Once you’ve done that, your branch is joined back to the trunk and you can carry on as before, any new commits to that branch will merge across cleanly. The only downside of this is that the merge is strictly at the wrong point – if you view the history in the trunk it won’t be technically accurate and you’ll need to use your commit messages as the real guide to the actual merges before the conversion.

A better way to do this would be to record the merges during the conversion, that is for merge commits in Subversion to have 2 parents. So far, none of the conversion tools read svnmerge or svn:merge metadata to implement this, but the standard ‘hg convert’ has an option called ‘–splicemap’ where you can specify merge points to be applied during the conversion. Unfortunately I’ve tried to use this twice so far, and both times it hasn’t worked (just silently done nothing). The documentation for –splicemap is not great so it could be I got the URLs wrong. But anyhow, following 2 failed attempts (20 hours! because this was the standard hg convert with –datesort) I decided I’d try to get a similar bit of functionality working in hgsubversion instead, since that’s much faster (1hr 40m a pop). Right now I’m hacking away on it to try to make this work, so far it’s not but I’ll let you know if I eventually succeed. One of the benefits of Mercurial is that it’s all in Python so it’s very easy to modify, compared to Git which runs all kinds of random scripts and executables, including sh and perl so it’s much more tangled to dig into.

Conclusions, so far

I started my DVCS evaluation very pro-Mercurial and very anti-Git. While working through my detailed use cases, a process which I’ve not quite completed yet, Git has grown on me a great deal, and I discovered a few things about Mercurial which I found a bit limiting at first, but which are mitigated via extensions – Rebase, Queues and Transplant particularly. My recent experience with more complicated, full-scale and imported repositories has once again gone in Mercurial’s favour though, and I saw a nastier side of Git – when it goes wrong, it’s a lot more difficult to figure out why. In contrast when I’ve had my Mercurial conversion crash – and I stress this only happened due to my own screw up, once because it ran overnight when my rsync kicked in and changed the repository under its feet, and a few times when I’ve been experimenting with hacking the Python to get the merges done – the reason has always been clear; a nice Python trace, and the repository was always intact anyhow – in the case of the core hg convert the conversion even restarted from where it left off once I’d fixed it.

If I were to graph my relative opinion of the two over the period I’ve been doing this so far, it would look something like this:

Git totally came up from behind and I was really starting to dig it, until it started freaking out on me with the conversion and I started to try to diagnose why and found it mostly unhelpful. Again I stress I’m not done with my tests yet, but I’m perhaps 75% of the way through now and the conversion problems I’ve had with Git in the last few days don’t look good. Bazaar, I’m afraid, is no longer likely to be part of the evaluation – it takes a long time to do these evaluations properly rather than just trivially, and our survey has indicated that it is the least commonly used among our community by a very large margin, so I’m focussing on the ones more users are likely to already be comfortable with.

The evaluation process continues…

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.

Git

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

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.

Bazaar

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:

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.

I’ve presented my work-in-progress list below, feel free to suggest more use cases I can test. I really want to see what these things are like in practice in the kinds of situations I encounter in real projects, without actually risking a real project in the process! Like a backup / restore strategy, it’s no good doing it for the first time when the sh*t has already hit the fan.

Oh, and for fun, allegedly Git is MacGyver and Mercurial is James Bond .

Due to the nature of a DVCS, all these use cases must be tested both in isolation, and  after pushing those changes to another potentially ‘superset’ repository.

1. General
   1. Commit a few changes to local repository ‘A’ but don’t push to central yet. Push a number of different changes to the central repository from a different repository ‘B’. Then, pull ‘B’s changes from the central repos to local repository ‘A’  to bring it up to date, again without pushing A’s outstanding changes yet. This is equivalent to doing an ‘svn update’ while you have local uncommitted changes in Subversion, but while using the local commit features of the DVCS. How does this work in practice? [Suggested by Arseny Kapoulkine]
2. Branching
   1. Create a new public, official branch (stable branch)
   2. Create a new long-term feature branch which is intended for public consumption / collaboration
   3. Create lots of short-term development branches (or equivalent structures) intended for local consumption only
      1. What are the size overheads? (Git claims superiority here)
      2. Does this excessively clutter the public repository when pushed?
      3. Is there a better way of handling multiple local changesets which you may or may not decide to push individually, such as testing many patches (Mercurial queues seem very interesting, Git equivalent?)
      4. . Rename a branch? (optional)
3. Merging
   1. Merge changes unidirectionally from one branch to another, without having to manually pick revisions. Make more changes in the source branch and repeat.
   2. Bidirectional merge – a feature branch which is not yet ready to be merged into the trunk wants to resynchronise from the trunk and continue branched development. Merge of this branch into the trunk must be tested later after further changes
4. Tagging
   1. Create a tag against a specific branch; probably at the HEAD but look for the option to specify a revision
   2. Correct / modify / move a tag following a mistake or last-minute revision (pre-release) without having to make duplicate commits or other such spurious activity
5. Firefighting
   1. Screw-up: developer commits change to trunk instead of stable branch. Merge / move it to the stable instead – change can be left in the trunk or can be removed for re-merging, so long as the procedure is clear.
   2. Screw-up: developer commits change to stable branch that is interface-breaking, must be removed and moved to the trunk. Must be removed from the stable branch and moved.
   3. Screw-up: Revert a single change from the repository, that is not at the HEAD
6. External patch submission tests:
   1. Patch file from same branch, no conflicts
   2. Patch file from same branch, with conflicts
   3. Patch file generated on a different branch to the one we want to apply it to (include conflicts)
   4. Pull from third-party repository, entire branch
   5. Pull from third-party respository, specific changes
   6. Patch file generated from non-repository source copy
7. Backup multiple work-in-progress changes on a local machine that are not ready for public consumption; approaches:
   1. Store a patch per local branch (this is how it’s done with SVN, but too much hassle if you use lightweight local branching, DVCSs can do better)
   2. Push to a backup repository on another machine across existing protocols – ssh, https, Samba share (Git can’t do the latter?)
   3. Push to a backup respository on a USB stick (Git can’t do this?)
8. Binary files
   1. Revise a binary file over a few versions, test storage efficiency
   2. Binary file conflict resolution
9. Conversion from Subversion
   1. Import retaining history
   2. Import multiple branches
   3. Import tags
10. Integration
    1. Mailing list / RSS notifications of commits on official repository
    2. Bugtrackers
    3. CIA.vc et al?
    4. Good free & open source GUI clients for all platforms
    5. Line ending conversions between platforms

Don’t get me wrong, I’m sure Git is technically excellent. But a number of things about it remind me of the somewhat stubborn purisms of  ‘old Linux’, such as:

• The documentation is hugely daunting. Whenever anyone tried to convince me why Git is amazing, they point me at documentation that just makes me not want to touch it for anything important. The impression I get is akin to some Linux forums: – this thing is powerful, but it gives you plenty of rope to if not hang yourself, then to tie yourself in knots if you don’t know what you’re doing.
• It requires a Unix back end, to the extent that you have to run it under Cygwin on Windows, and its rigid filesystem requirements mean it won’t work on FAT or Windows network drives. I get the impression there’s something rather aloof about the fact that the core team don’t consider it an issue that Git won’t run on native Windows environments. There are external projects working on that, but the fact that it’s not core is a concern, since I prefer all my 3 platforms to be supported equally.
• The UIs still don’t seem very user-friendly, and most responses I see to the question of why that is boil down to “Git is too powerful to be captured in a GUI”. Sorry, but I don’t buy that – no system is too complex to be captured in a user-friendly tool, it just takes the will to do it, and like ‘old Linux’, there seems to be little will to make Git more approachable.

So, I’ve never had great vibes from Git, despite it’s doubtless technical merits. So, I decided to check out Mercurial instead – from what I read, Git is the fashionable DVCS that all the cool kids want to be seen using, but when it comes down to it Mercurial does exactly the same thing – except that it has native support for all platforms out of the box and TortoiseHg is looking pretty mature. I also read that it handles binary files better than Git too, since it does binary diffs everywhere. The documentation seemed much more approachable too, so I figured I’d have a play.

My first impressions are incredibly positive. The most impressive thing of all is that I imported a (relatively small- about 100 revisions) Subversion repository, with all the history intact, about 5 minutes after installing it, and was bouncing that across Linux and Windows immediately afterwards (haven’t tried OS X yet). TortoiseHg is instantly familiar, and despite the fact that the concepts are the same as Git, the presence of some familiarity, together with some distinctly less intimidating documentation, has me feeling far happier than the times I’ve dipped into the Git docs. Mercurial’s approachability is a positive contrast to Git’s Unix-purist, RTFM style I think. I know which I prefer so far.