<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 17, 2019, 06:52 Pierre-Yves David <<a href="mailto:pierre-yves.david@ens-lyon.org">pierre-yves.david@ens-lyon.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 4/17/19 3:49 PM, Martin von Zweigbergk wrote:<br>
> <br>
> <br>
> On Wed, Apr 17, 2019, 06:47 Pierre-Yves David <br>
> <<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>>> <br>
> wrote:<br>
> <br>
> <br>
> <br>
> On 4/17/19 3:06 PM, Martin von Zweigbergk wrote:<br>
> ><br>
> ><br>
> > On Wed, Apr 17, 2019, 03:34 Pierre-Yves David<br>
> > <<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>>>><br>
> > wrote:<br>
> ><br>
> > On 4/17/19 4:59 AM, Martin von Zweigbergk wrote:<br>
> > ><br>
> > ><br>
> > > On Tue, Apr 16, 2019, 16:46 Pierre-Yves David<br>
> > > <<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>><br>
> > <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>>><br>
> > <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>><br>
> > <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a><br>
> <mailto:<a href="mailto:pierre-yves.david@ens-lyon.org" target="_blank" rel="noreferrer">pierre-yves.david@ens-lyon.org</a>>>>><br>
> > > wrote:<br>
> > ><br>
> > > # HG changeset patch<br>
> > > # User Pierre-Yves David<br>
> <<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a> <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a>><br>
> > <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a><br>
> <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a>>><br>
> > > <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a><br>
> <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a>><br>
> > <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a><br>
> <mailto:<a href="mailto:pierre-yves.david@octobus.net" target="_blank" rel="noreferrer">pierre-yves.david@octobus.net</a>>>>><br>
> > > # Date 1551881213 -3600<br>
> > > # Wed Mar 06 15:06:53 2019 +0100<br>
> > > # Node ID ed796867a06764cd78a57b2ed0249353f5809319<br>
> > > # Parent 9bec7491e9b4cabdfa4d264e5213b1f416ec2607<br>
> > > # EXP-Topic verify<br>
> > > # Available At<br>
> <a href="https://bitbucket.org/octobus/mercurial-devel/" rel="noreferrer noreferrer" target="_blank">https://bitbucket.org/octobus/mercurial-devel/</a><br>
> > > # hg pull<br>
> > > <a href="https://bitbucket.org/octobus/mercurial-devel/" rel="noreferrer noreferrer" target="_blank">https://bitbucket.org/octobus/mercurial-devel/</a> -r ed796867a067<br>
> > > verify: also check full manifest validity during<br>
> verify runs<br>
> > ><br>
> > > Before this changes, `hg verify` only checked if a<br>
> manifest<br>
> > revision<br>
> > > existed and<br>
> > > referenced the proper files. However it never checked the<br>
> > manifest<br>
> > > revision<br>
> > > content itself.<br>
> > ><br>
> > > Mercurial is expecting manifest entries to be sorted<br>
> and will<br>
> > crash<br>
> > > otherwise.<br>
> > > Since `hg verify` did not attempted a full restoration of<br>
> > manifest<br>
> > > entry, it<br>
> > > could ignore this kind of corruption.<br>
> > ><br>
> > > This new check significantly increases the cost of a<br>
> `hg verify`<br>
> > > run. This<br>
> > > especially affects large repository not using<br>
> > `sparse-revlog`. For<br>
> > > now, this is<br>
> > > hidden behind the `--full` experimental flag.<br>
> > ><br>
> > > diff --git a/mercurial/verify.py b/mercurial/verify.py<br>
> > > --- a/mercurial/verify.py<br>
> > > +++ b/mercurial/verify.py<br>
> > > @@ -337,6 +337,16 @@ class verifier(object):<br>
> > > filenodes.setdefault(fullpath,<br>
> > > {}).setdefault(fn, lr)<br>
> > > except Exception as inst:<br>
> > > self._exc(lr, _("reading delta %s")<br>
> % short(n),<br>
> > > inst, label)<br>
> > > + if not dir and self._level >= VERIFY_FULL:<br>
> > ><br>
> > ><br>
> > > What does the "not dir" mean? I guess it's to do this<br>
> check only<br>
> > for the<br>
> > > root directory when using tree manifests. Should we do it<br>
> for all<br>
> > > directories?<br>
> ><br>
> > That is used earlier in the same function to denote "the root<br>
> > manifest".<br>
> > I think check the root manifest will trigger checks of the<br>
> sub manifest<br>
> > but I am not sure, I am not too familiar tree manifest.<br>
> ><br>
> ><br>
> > I'm pretty sure it's about tree manifests. I asked just to make sure<br>
> > since it surprised me that you used that as part of the condition<br>
> here.<br>
> <br>
> I know it is about tree manifest, I am reusing a pattern used by<br>
> earlier<br>
> code.<br>
> <br>
> > Can we double<br>
> > check/fix this as a follow up ?<br>
> ><br>
> ><br>
> > It should be easy to check (just add a print statement and run<br>
> tests,<br>
> > for example), so I don't see much reason to fix such a simple<br>
> thing in a<br>
> > follow-up.<br>
> <br>
> The question here is "Does reading the top level manifest will<br>
> validated<br>
> the content of the sub manifest too". I don't know how reliably to<br>
> check<br>
> it in a reasonable amount of time. I am not exposed to any tree<br>
> manifest<br>
> user myself.<br>
> <br>
> <br>
> Ah, no, it won't read sub manifests. You're simply skipping sub <br>
> manifests by including the "not dir" check.<br>
<br>
so should we just drop the "not dir" ?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, that's what I would have expected.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
Pierre-Yves David<br>
</blockquote></div></div></div>