Mercurial vs. Bazaar speedtest clone and log - update: hg 1.1 vs. bzr 1.10

[Matt Mackall]

On Sun, 2008-12-14 at 14:32 +1100, Robert Collins wrote:
> On Sat, 2008-12-13 at 18:09 +0100, Isaac Jurado wrote:
> > On Sat, Dec 13, 2008 at 6:02 PM, Matt Nordhoff
> > <mnordhoff at mattnordhoff.com> wrote:
> > >
> > > 1.9 will probably never be made the default format, because more
> > format
> > > work is in the pipeline right now. (1.9 replaced the indexes but
> > didn't
> > > change anything else.)
> > 
> > Seriously?  Is bzr ever going to have a minimally stable format?
> 
> Yes, when there is nothing at the disk level that needs improving. The
> current bzr default, 0.92-pack, was released in October 2007 - so thats
> over a year - I'd call that minimally stable, at a minimum.
> 
> There have been two other formats recently, 1.6 adds stacking (similar
> to history punching), and 1.9 was a improvement to the index layer
> (increasing the selectivity of probes in the index by around two orders
> of magnitude.
> 
> I find the tone of the question strange given that hg is (as far as I
> can tell) changing its formats too, and at approximately the same pace).
> For instance,
> http://www.selenic.com/mercurial/wiki/index.cgi/fncacheRepoFormat.

The significant changes we've made are:

Apr05: first release
May05: switch away from hashed filenames
Aug05: escape directories ending in .i or .d
Apr06: tweak index format, add interleaving (RevlogNG)
Dec06: add 'store' file naming scheme (for Windows quirks)
Oct08: introduce fncache file naming scheme (more Windows quirks)

Note the widening gaps. Also note that all but one of those is just a
change of file naming schemes. The most significant one that actually
touches the underlying data structures (RevlogNG) is still fairly minor:
the backward compatibility code is a mere 28 lines (see
revlog.py:revlogoldio). 

In all that time, the wire protocol hasn't changed, so you can pull
between any two versions without any awareness of the version skew. You
can pull from 1.1 to 0.6 to 1.1 without data loss. Further, there aren't
any switches or options the user needs to know about so users can be
basically oblivious to the changes. Newly-cloned or inited repos simply
get the new format.

I can't say I've followed bzr development, but every time this
performance discussion comes up, the question is always 'are you using
the latest format in your bzr tests?' The last time this question was
relevant for Mercurial was Apr06. 

So by comparison it seems that bzr's storage is very much in flux while
Mercurial has done some fine-tuning.

-- 
Mathematics is the supreme nostalgia of our time.