<div dir="ltr"><br><div class="gmail_quote">On Wed, Mar 18, 2015 at 3:28 PM Matt Mackall <<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2015-03-16 at 16:27 -0700, Martin von Zweigbergk wrote:<br>
> # HG changeset patch<br>
> # User Martin von Zweigbergk <<a href="mailto:martinvonz@google.com" target="_blank">martinvonz@google.com</a>><br>
> # Date 1426435855 25200<br>
> #      Sun Mar 15 09:10:55 2015 -0700<br>
> # Node ID 0d969d6efeef08935c93afc416bf40<u></u>6def6b8e59<br>
> # Parent  567ae53657544744155897ada91f16<u></u>f8af61ad8a<br>
> treemanifest: create treemanifest class<br>
><br>
> There are a number of problems with large and flat manifests. Copying<br>
> from <a href="http://mercurial.selenic.com/wiki/ManifestShardingPlan" target="_blank">http://mercurial.selenic.com/<u></u>wiki/ManifestShardingPlan</a>:<br>
><br>
>  * manifest too large for RAM<br>
><br>
>  * manifest resolution too much CPU (long delta chains)<br>
><br>
>  * committing is slow because entire manifest has to be hashed<br>
><br>
>  * impossible for narrow clone to leave out part of manifest as all is<br>
>    needed to calculate new hash<br>
><br>
>  * diffing two revisions involves traversing entire subdirectories<br>
>    even if identical<br>
><br>
> This is a first step in a series introducing a manifest revlog per<br>
> directory.<br>
><br>
> This change adds boolean configuration option<br>
> experimental.treemanifest. When the option is enabled, manifests are<br>
> parsed into a new tree data structure with one tree node per<br>
> directory. At this point, it is just a different data structure in<br>
> memory; there is still just a single manifest revlog on disk.<br>
<br>
I think the right way to do this is:<br>
<br>
- at repo create time, check the flag<br>
   - add treemanifest to requires file<br>
- at startup, check requires file<br>
   - unconditionally use treemanifest if set<br></blockquote><div><br></div><div>I agree with the second step, but I'm not sure about the first. After the 5 patches in this series, using treemanifest is still not a final decision; the manifest is still stored in the regular flat format. In other words, --config experimental.treemanifest=True can be passed to any command without affecting anything besides performance. It seems like the above would unnecessarily make it a final decision. I was rather planning on writing the requires flag when a treemanifest is first written to disk using the future submanifest revlog structure. I would even be possible to unconditionally read into the treemanifest structure (if we imagine it got fast enough). Then the config would clearly only be about writing. What do you think?</div><div><br></div></div></div>