[PATCH 1 of 9 sparse] localrepo: add sparse caches

Martin von Zweigbergk martinvonz at google.com
Thu Jul 6 18:15:08 EDT 2017


On Thu, Jul 6, 2017 at 3:13 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> On Thu, Jul 6, 2017 at 3:08 PM, Martin von Zweigbergk
> <martinvonz at google.com> wrote:
>>
>> On Thu, Jul 6, 2017 at 2:54 PM, Gregory Szorc <gregory.szorc at gmail.com>
>> wrote:
>> > # HG changeset patch
>> > # User Gregory Szorc <gregory.szorc at gmail.com>
>> > # Date 1499368853 25200
>> > #      Thu Jul 06 12:20:53 2017 -0700
>> > # Node ID 56de1555b77f5cd553032c54bddb79645316c86d
>> > # Parent  ca4b78eb11e7a67600e85784df4da2655351b6d2
>> > localrepo: add sparse caches
>> >
>> > diff --git a/hgext/sparse.py b/hgext/sparse.py
>> > --- a/hgext/sparse.py
>> > +++ b/hgext/sparse.py
>> > @@ -421,7 +421,7 @@ def _wraprepo(ui, repo):
>> >              """Returns the signature string representing the contents
>> > of the
>> >              current project sparse configuration. This can be used to
>> > cache the
>> >              sparse matcher for a given set of revs."""
>> > -            signaturecache = self.signaturecache
>> > +            signaturecache = self._sparsesignaturecache
>> >              signature = signaturecache.get('signature')
>> >              if includetemp:
>> >                  tempsignature = signaturecache.get('tempsignature')
>> > @@ -523,7 +516,7 @@ def _wraprepo(ui, repo):
>> >                  '\n'.join(sorted(include)),
>> >                  '\n'.join(sorted(exclude)))
>> >              self.vfs.write("sparse", raw)
>> > -            self.invalidatesignaturecache()
>> > +            sparse.invalidatesignaturecache(self)
>>
>> What's the point of invalidatesignaturecache() when hgext/sparse.py
>> clearly knows about repo._signaturecache anyway?
>
>
> It /could/ be inlined in sparse.py. Since caching is hard and I didn't want
> to rewrite the world, I decided to cargo cult the standalone function (which
> also increases readability IMO). I can inline in a follow-up if you want.
>

Yes, please do. Either a follow-up that inlines it or one that does a
better job of encapsulating it. I'm not sure which I'd prefer, so
inlining seems fine for now at least.


More information about the Mercurial-devel mailing list