As an experiment to examine how well compressed things were already, I tarrred and bz2′ed both repositories. I found that both hardly changed at all, suggesting they’re both well compressed already – Git shrunk from 116MB to just 113MB, and Mercurial from 207MB to 200MB.

So it’s not compression, and that also suggests there won’t be any significant further gains during compressed network transfer. As I say, looking inside the filesystems of the repositories the main issue appears to be that Mercurial stores data in a filewise fashion so moved binaries are less efficient than in Git where a hashed binary is stored once regardless of how many folders it has existed in over the history. Generally, historical filesystem reorganisation is less efficient in Mercurial because of the filewise storage, it just shows up more obviously in binaries. Hopefully they might find a way to handle this more efficiently in the future, or at least give us a tool for stripping off old history before a certain date / revision. In the meantime I think I may have to go via Git just to strip off history, which is not ideal.

What definition of repository size do you use?

As for design vs bugs, this also supports Mercurial over Git for me. That’s not to say Git has a bad (technical) design, clearly it doesn’t, but Mercurial’s overall approach also sits a little more comfortably with me; cross-platform core, re-using existing knowledge rather than reinventing, being simple & intuitive to use wherever possible.

@Face: I’m actually using hgsubversion, because the results are faster and a little better for me (I even modified it so that merges can be ready on conversion), and you can incrementally pull revisions from SVN afterwards. It has a filemap option too – I haven’t managed to get it to do what I want yet.

For your repo size problem I can only propose to use “hg convert” with the filemap option to get rid of those big files. Maybe you can get the size down by using the branch-sort option, too.

I’m sure the ten parts of the final score aren’t equally valuable to you, so adding a weight score to the table might bring out more useful values to go on.

Also, bear in mind that anything that isn’t bad by design, but bad due to bugs, not having enough developer time/love yet, etc, is bound to be fixed sooner or later. Since OGRE will be worked on for years to come, considering future usage is a good idea.

Probably obvious stuff, but thought I’d bring it up anyways Going to read the post now.

As I say, the primary difference between Mercurial and Git seems to be that Mercurial stores new copies of binaries when you move them, whilst Git identifies that the hash is the same and doesn’t store it again. In our (distant) history media has been moved a couple of times which is likely a major cause of the problem. If I can figure out how to prune old history I think it will make a major difference. I’m thinking of trying to go via Git just for the history pruning then go back to Mercurial for the final.

The other bugbear I have with Mercurial is that is has no progress meter on remote operations. When you’re clonin / pushing large amounts of data you have no indication of how long it will take or even whether it’s still working; Git however has a nice % completion and K/s report which gives you confidence it’s all ok. With a big Mercurial repo I’m concerned people will kill the clone, thinking it’s not working.

But yes, overall I have to say that I agree with haffax & Eric, having confidence in your tools is very important. Yes, Git only failed when I was using git-svn, which I won’t need to use after the transition. But, the fact that when it did fail it wasn’t at all helpful in reporting why gives me pause. It doesn’t matter if a tool fails rarely – when it’s a critical tool, its behaviour under fail conditions is very, very significant. Mercurial was very transparent – not only do you get a full stack trace and exception message, since Mercurial is all Python I found it considerably easier to investigate. Hell, I even felt comfortable enough to enhance a Mercurial extension (hgsubversion) to handle merges the way I wanted. In contrast Git was a lot more opaque; even with all the theory that’s packed into their documentation it didn’t really assist me in where I should start looking when git-svn fell over; I just had to randomly experiment. So on a gut level I feel happier with Mercurial than Git.

I know that lots of big projects are using Git. I also know that the vast majority of them are Linux-oriented projects (even Qt/Nokia are very Linux/KDE focussed – the majority of the devs at Qt Dev Days were running Linux on their MacBooks!). Being a Linux project implies a certain affinity with the innards of Unix-like systems and, dare I say, a higher than average tolerance for complexity over intuitiveness, which is the slot that Git fits in too. Linux and Git were definitely cut from the same cloth – they’re both extremely clever, very technical pieces of work, but they also require more of the user, particularly in ’sticky’ situations.

So for the same reason that I prefer my Mac over a desktop Linux, my preference is for Mercurial, although my appreciation for Git is far, far greater than it was at the start of this review. Git’s a superb tool – it just has a few too many Linuxy traits for mere mortals like me to prefer it over the more intuitive Mercurial. I just really, really want to get this repo size down a bit first.