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

[Mike Hommey]

On Wed, Apr 01, 2015 at 09:19:03PM -0500, Matt Mackall wrote:
> 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.

The sha1 for a manifestv2 would be the same as the corresponding
(flattened) manifestv1? O_o

> 
> > - 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.

This question was not related to merges, but to the copyrev thing there
is for files. I guess it's not very important to have that for
manifests.

Mike