[PATCH 6 of 6] manifest: rename matches to _matches

[Durham Goode]

On 3/6/17 5:32 PM, Martin von Zweigbergk wrote:
> On Fri, Mar 3, 2017 at 11:34 AM, Durham Goode <durham at fb.com> wrote:
>> # HG changeset patch
>> # User Durham Goode <durham at fb.com>
>> # Date 1488517595 28800
>> #      Thu Mar 02 21:06:35 2017 -0800
>> # Node ID 1bed8ee65389133923b9076909e04f66ef26f1b8
>> # Parent  207763e895c7d24885df22f5b9c0df5494d77daf
>> manifest: rename matches to _matches
>>
>> Now that there are no external consumers of manifest.matches, let's rename it to
>> _matches so it remains internal. This means alternative manifest implementations
>> no longer have to implement it, and can instead implement efficient versions of
>> diff() and filesnotin().
>
> matches() still seems like a sensible method. Once "hg files" gains a
> "-v" or "--flags" option so it can really replace "hg manifest" (or if
> "hg manifest" started accepting a file pattern), it seems natural to
> implement that using manifest.matches(). Would it be a problem to
> queue patches 1-5 but not this one?

It's not a problem to queue 1-5 without 6, but given the performance 
criticalness of the manifest, I'd lean towards not giving it functions 
that could enable future bad algorithms.  If we need the ability to 
iterate over the entire manifest in the future, maybe we could add a 
manifest.walk(match=None) function that returns an iterator.  The 
'walk()' part exposes caller to the fact that it is going to be an 
expensive operation, and the iterator aspect means we don't have to 
allocate an entire dict and we don't have to worry about people abusing 
it as a way of doing naive set math using manifests.  That gets the 
manifest a little closer to resembling a dirstate as well.