[PATCH 0 of 2 STABLE RFC] issue2137: revlog has stale data after unbundle()

[Matt Mackall]

On Tue, 2010-04-13 at 21:24 -0400, Greg Ward wrote:
> On Tue, Apr 13, 2010 at 8:48 PM, Benoit Boissinot
> <benoit.boissinot at ens-lyon.org> wrote:
> > On Tue, Apr 13, 2010 at 06:32:33PM -0400, Greg Ward wrote:
> >> These patches demonstrate the bug described in
> >> http://mercurial.selenic.com/bts/issue2137.  There's no fix yet, just
> >> a failing test.  I wanted to get some feedback before attempting a
> >> fix.
> >>
> >> Incidentally, I forget to mention that the reason for the
> >> repo.lookup() failure is that revlog._partialmatch() depends on
> >> revlog.lazyparser.__iter__(), which in turn relies on self.p.l being
> >> accurate.  It's not, and that's why repo.lookup() fails, which is why
> >> I think the problem is something to do with lazyparser.
> >
> > diff --git a/mercurial/revlog.py b/mercurial/revlog.py
> > --- a/mercurial/revlog.py
> > +++ b/mercurial/revlog.py
> > @@ -294,8 +294,7 @@
> >         return key in self.p.map
> >     def __iter__(self):
> >         yield nullid
> > -        for i in xrange(self.p.l):
> > -            ret = self.p.index[i]
> > +        for i, ret in enumerate(self.p.index):
> >             if not ret:
> >                 self.p.loadindex(i)
> >                 ret = self.p.index[i]
> 
> Right, that should fix revlog._partialmatch() and therefore
> repo.lookup().  But is this the right fix?  Is it a problem that the
> lazyparser's 'l' (length) attribute is stale after unbundle?

Oh, almost anything that looks like a bug with lazyparser probably is.
lazyparser is a sad thing. It's fat and slow and overly-complicated. If
some day we can figure out a way to cleanly move from lazyparser at
start-up to on-demand non-lazy lists and dicts, that'd be great.

-- 
http://selenic.com : development and support for Mercurial and Linux