[PATCH 5 of 5] subrepo: propagate matcher to subrepos when archiving

[Patrick Mézard]

Le 20/06/12 15:11, Matt Harbison a écrit :
> Patrick Mézard <patrick <at> mezard.eu> writes:
> 
>>
>> Le 20/06/12 06:45, Matt Harbison a écrit :
>>> # HG changeset patch
>>> # User Matt Harbison <matt_harbison <at> yahoo.com>
>>> # Date 1339901591 14400
>>> # Node ID eacce55ea7903d33760f761d01bbba492697657f
>>> # Parent  8d07024897537dc44357830c4c57f13160c629e1
>>> subrepo: propagate matcher to subrepos when archiving
>>>
>>> The archiving process for subrepos now properly considers -X and -I options.
>>>
>>> diff --git a/hgext/largefiles/overrides.py b/hgext/largefiles/overrides.py
>>>      if subrepos:
>>>          for subpath in ctx.substate:
>>>              sub = ctx.sub(subpath)
>>> -            sub.archive(repo.ui, archiver, prefix)
>>> +            submatch = matchmod.narrowmatcher(subpath, matchfn)
>>> +            sub.archive(repo.ui, archiver, prefix, submatch)
>>
>> Passing matchfn to narrowmatcher requires it to be a match object. This
>> should not be a problem, at least in
>> hg codebase, but you should adjust the function docstring saying:
>> """
>> matchfn is function to filter names of files to write to archive.
>> """
>> to explicitely mention it.
>>
> 
> Can you explain a bit more?  I was (pleasantly) surprised it worked.  But I
> didn't change the input to archival.archive()- it is still taking in the same
> matching function.  Do you mean add something like "This function must be
> compatible with narrowmatcher."?

"Being compatible with narrowmatcher" is the same thing as "being a match object" in practice, and is very unlikely to change. Before your patch, archival.archive() was testing matchfn as a boolean and calling it so it could have been any kind of callable, this is no longer the case. Anyway, that is not terribly important, almost all if not all our matching functions are match objects, which is why you did not have to change anything.

--
Patrick Mézard