[PATCH v2] shelve: add a shelve extension to save/restore working changes

dsp at experimentalworks.net dsp at experimentalworks.net
Mon Sep 9 14:25:42 CDT 2013


> Replacing the ``setattr(obj, self.name, value)`` call with ``obj.__dict__[self.name] = value`` would bypass repoview magic.
> 
> I'm actually a bit surprise that propertycache on repoview are so broken for two versions. As far as I understand the current code:
> (1) All propertycache computed repoview side are actually store on the unfiltered repo. That would expect the unfiltered repo be confused.
> (2) All repoview seems to not use the cached value anymore. I would have expected some performance impact there.

I looked into this today and want to clarify what's going on:

Due to multiple inheritance in the proxycls class we inherit all
attributes and propertycache descriptors from localrepo/mqrepo as well
as the __getattr__/__setattr__ from repoview.

Attribute lookups in Python prefer descriptors (e.g. the propertycache
decorator) over instance values, over __getattr__/__setattr_
implementations [1].

When repo.mq is accessed, Python will choose the __get__ implementation
from propertycache. When propertycache calls setattr it will choose (due
to the nonexisting instance value) the __setattr__ from repoview,
causing an instance variable creation in the unfiltered repo object (as
repoview redirects to the unfiltered object)

The next time repo.mq is accessed, the code will still call __get__ as
the propertycache never set a value on the proxycls object. This is
causing a new mq object to be created.

So the propertycache invariant is that when we setattr on an object,
it's the same object as on which __get__ is called, which in our code,
doesn't always hold true.

I am looking into ways to fix this issue. At the moment I think we have
to cache the value in the propertycache itself, as we can guarantee that
values are set and get with the same preference.

[1] http://docs.python.org/2/howto/descriptor.html#invoking-descriptors


More information about the Mercurial-devel mailing list