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

Bryan O'Sullivan bos at serpentine.com
Thu Jun 27 17:54:35 CDT 2013

On Thu, Jun 13, 2013 at 6:06 AM, Pierre-Yves David <
pierre-yves.david at logilab.fr> wrote:

> This is not supposed to happen. The repoview object should just proxy
> everything to the original localrepo object.

Every access to repo.mq results in a new mq.queue object being created and
destroyed. I don't know quite why this is happening, but I can see it

> I'm not saying that repoview can't be bugged. But it should not prevent you
> from doing what you are trying to.

Since I can't maintain any state on the repo object (because mq is deleted
and recreated every time I access it), it is very definitely preventing me
from doing what I am trying to do :-)

Here is what I can reconstruct so far.

When I ask for repo.mq, this ends up invoking propertycache.__get__ on a
localrepo.proxycls object.

That tries to setattr the attribute, which (via inheritance) calls
repoview.repoview.__setattr__. This seems to set the field on the mq.mqrepo
object correctly, but next time the attribute is retrieved, the
propertycache.__get__ method is called again, a new object is created as a
result, and the previous one is deleted once the attribute is set again.

In other words, something bizarre is absolutely definitely happening with
that complicated interaction between proxycls, propertycache, and repoview.
I don't understand it, and I don't have time to dig deeper, but it's easy
to reproduce.

Here is a trivial repro: http://pastebin.com/GshjKqCW

You can trigger this by applying the patch and running "hg tip". You'll see
that it prints "new queue" four times, indicating that a new queue object
is being constructed every time self.mq is being accessed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130627/36e12089/attachment.html>

More information about the Mercurial-devel mailing list