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.