[darcs-devel] bug in get_extra revival

[David Roundy]

On Mon, May 02, 2005 at 08:37:15PM +0200, Tomasz Zielonka wrote:
> On Mon, May 02, 2005 at 08:40:57AM -0400, David Roundy wrote:
> > On Sun, May 01, 2005 at 11:29:53PM +0200, Tomasz Zielonka wrote:
> > > I managed to reduce the test case. I attach three patch bundles, all
> > > to be applied to tag 1.0.2:
> > 
> > Thanks for tracking this down!
> > 
> > >   to      - a repo to pull to
> > >   from    - a repo to pull from, causes get_extra bug
> > >   from-ok - a repo to pull from, doesn't cause get_extra bug
> > > 
> > > Note that 'from' and 'from-ok' contain the same set of patches,
> > > but in different order.
> > 
> > Argh.  This is a case of eight-deep nested mergers.
> 
> I noticed that they are deeply nested. Is this OK?

Yeah, that's what happens with merger patches when you've got a few
mergers.  It's related to why they can get so inefficient.

> > :( I'm afraid it may not be worth tracking down exactly why exactly
> > this fails.
> 
> I feel it's a good opportunity to get a better understanding of merger
> patches and their problems... or is it not worth it?
> 
> If I understand correctly, both 'from' and 'from-ok' are correct repos,
> the problems is that darcs is unable to commute "eight-deep nested
> merger" with some patch/patches that constitute the conflict?

Yeah, this is a symptom of the lack of a "transitive property" in the
merger commutation.  I'd guess that it's fixable, but think that it may be
better to simply avoid it when possible.  The problem is that it takes a
long time to wrap one's brain around what it's doing.  Given the effort
required, I'd rather apply it to the new code than the old, especially
since it doesn't look to me like there's potential for corruption here.
Just major inconvenience.

> > I'd rather invest the time in the replacement conflictor code, which I
> > have greater confidence will be bug-free than the merger code.  :(
> 
> Now I have a small problem - I can't pull from unstable to stable. I
> think I'll try to work-around this by removing the offending patch from
> my copy of unstable. 
> 
> Or... maybe we could reorder stable or unstable?

Yeah, I'd say we ought to be able to reorder stable and/or unstable to fix
this.  It may be that a simple optimize --reorder would do it... okay, it
seems that optimize --reorder fails when run on the unstable repository.
 :(  In fact, darcs get --tag 1.0.3rc1 also fails with an error on the
darcs-unstable repo.

I think this is worth looking into.  :(

Tomasz, would you like to take a shot at figuring out what's going wrong?
It might be simplest to look into the get --tag bug, which I'm sure is
triggered by the same root bug, because in that case there's really no
ambiguity, and there's only one repository involved.  It's just a question
of being able to commute all the patches that aren't in that tag beyond the
tag itself.
-- 
David Roundy
http://www.darcs.net