Mercurial vs. Bazaar speedtest clone and log - update: hg 1.1 vs. bzr 1.10
Adrian Buehlmann
adrian at cadifra.com
Sun Dec 14 08:20:36 UTC 2008
On 14.12.2008 04:32, 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.
>
Since I am the one who did the 'fncache' patch for Mercurial 1.1, I'll
comment a bit on that new "format".
fncache didn't really change any single bit in the underlying data structures
of Mercurial (revlog, indices, changelog, manifest, etc. are all the same).
We reorganized just the revlog data file *names* (and directory names) inside
the store to work around some nasty file name limitations of Windows (long
path names, names reserved by Windows).
This introduced a non-reversible encoding for long path names in the
store (hybrid hashing of path names), which triggered the introduction of
an additional file called 'fncache', which simply contains a redundant list
of the so-called "direncoded" path names of all files in the repo, to allow
for enumerating the data files at a reasonable speed (currently only used when
doing a 'clone --uncompressed').
The 'fncache' file is entirely redundant information and built from scratch
(i.e. all manifest revisions) if you do a 'clone --pull' (which is implied
if you do a clone over the wire). As a side note, the wire protocol of course
didn't change a single bit, so you can combine Mercurial versions on each
end of the wire as you want.
Since this was a backwards-incompatible change in the way the files in
the store are *named*, we introduced an new format specifier ('fncache')
in the 'requires' file, thus telling old versions of Mercurial that it
should keep its fingers off from new 'fncache' repositories (since we know
those old versions of Mercurial won't know how to find the files in
the store).
But the "format" is not really new, since the contents of the files in the
store did not change. We just changed *where* we store the bits - not *how*
we store them.
More information about the Mercurial
mailing list