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

[Mike Hommey]

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)

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

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

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

Mike