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

[Benoit Boissinot]

On Tue, Apr 13, 2010 at 09:24:21PM -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?

I think it's not a problem. "parser.l" is supposed to indicate the end of
the lazy file, everything afterward is not lazy (I checked the other
users they are fine).

(it's quite bad that in pratice the tests don't exercise split-revlogs
and lazy-indexes...)

cheers,

Benoit

-- 
:wq