[PATCH] manifest: avoid intersectfiles for matches > 100 files

[Martin von Zweigbergk]

On Thu, Mar 19, 2015 at 9:40 AM Durham Goode <durham at fb.com> wrote:

>
>
> On 3/19/15 7:59 AM, Martin von Zweigbergk wrote:
>
>
>
> On Thu, Mar 19, 2015 at 7:54 AM Durham Goode <durham at fb.com> wrote:
>
>>  Hg histedit a few commits and change the last pick to mess.  As long as
>> the last commit doesn't add any new files it will trigger the issue (since
>> the issue only happens when all files being matched exist in the manifest
>> already).
>>
> I agree with the fix, but if I understood correctly from our discussion on
> IRC yesterday, the description is not accurate. Wasn't the problem rather
> that the part after the "or" evaluates "util.all(fn in self for fn in
> files)", which is almost the same thing as intersectfiles() and it's called
> only to determine whether to call intersectfiles(). But if that's the case,
> I guess I don't understand why the overall condition does not evaluate to
> True (before your patch). Is it that all the files are not in the changeset
> (self)?
>
> The problem I encountered is that the overall condition *did* evaluate to
> true, because all the files were in self.  So it went down into
> intersectfiles.  The description in the commit message is a little
> different from what I encountered, but probably still an accurate case that
> could cause the issue.
>

Sure, it may be accurate, but so far, we don't know that it's relevant. How
about the following, which we know is relevant?

"Previously we tried to avoid manifest.intersectfiles for exact matches
with less than 100 files. However, when the left side of the "or" is false,
the right side gets evaluated, of course, and the evaluation of "util.all(fn
in self for fn in files)" is both costly in itself, and likely to be true,
causing intersectfiles() to be called after all. Fix this by moving the
check for less than 100 files outside of the "or" expression, thereby also
making it apply for a non-exact matcher, should one be passed in."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150319/feac80ac/attachment.html>