[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