[PATCH 4 of 5] manifestv2: add support for reading new manifest format

Matt Mackall mpm at selenic.com
Wed Apr 1 21:19:03 CDT 2015


On Thu, 2015-04-02 at 09:01 +0900, Mike Hommey wrote:
> On Wed, Apr 01, 2015 at 10:34:49AM -0700, Martin von Zweigbergk wrote:
> > # HG changeset patch
> > # User Martin von Zweigbergk <martinvonz at google.com>
> > # Date 1427520401 25200
> > #      Fri Mar 27 22:26:41 2015 -0700
> > # Node ID aca6ee57dddf4b39732833a2bb603dcd19148754
> > # Parent  7530c75651b04d04e0871c84dfda487b4e9e96b4
> > manifestv2: add support for reading new manifest format
> > 
> > The new manifest format is designed to be smaller, in particular to
> > produce smaller deltas. It stores hashes in binary and puts the hash
> > on a new line (for smaller deltas). It also uses stem compression to
> > save space for long paths. The format has room for metadata, but
> > that's there only for future-proofing. The parser thus accepts any
> > metadata and throws it away. For more information, see
> > http://mercurial.selenic.com/wiki/ManifestV2Plan.
> 
> I have several questions related to that document:
> - Since manifest creation is done when committing, what is the plan wrt
>   what should happen when a commit with manifestv2 is pushed (server may
>   not support them, or may not want them even if it does)

Not fully decided. Possibly on-the-fly conversion.

> - What is the metadata expected to be used for in the header and in the
>   file entries? How would they be set, and what's the expected interaction
>   for merge conflicts on these metadata?

No precise plans yet. All metadata is presumed to be optional/ignorable,
so can be skipped by merge.

> - Why put file entries on two lines? The 20-byte nodeid could be
>   preceded with a null character, which would solve the readdelta
>   issue mentioned at the end of the document, but maybe the goal is to
>   make deltas smaller when only the nodeid changes?

http://mercurial.selenic.com/wiki/ImprovingManifestCompressionPlan

> - Relatedly, the manifest sharding plan seems now to essentially be to
>   have a manifest per directory, with one revlog each. Is there a plan
>   to handle moved/renamed directories like it's done with files?

So many questions! Merge already handles directory moves implicitly, so
this should just work without changing existing semantics.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list