monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: [BUG] monotone merge leads to irrecoverable db


From: Nathaniel Smith
Subject: Re: [Monotone-devel] Re: [BUG] monotone merge leads to irrecoverable db
Date: Fri, 22 Jul 2005 23:22:38 -0700
User-agent: Mutt/1.5.9i

On Fri, Jul 22, 2005 at 05:36:03PM +0200, Peter Simons wrote:
> Rene Wagner writes:
> 
>  > I'd appreciate any type of feedback from a core developer as
>  > this type of random breakage along with no reaction to bug
>  > reports certainly doesn't speak for using monotone [...].
> 
> I feel inclined to agree with Rene. The amount of energy one has
> to invest into getting any kind of reaction to a bug report is
> really quite high.

Yeah.  I agree, and apologize.  Partly it's just a matter of
developers not having time, but (speaking for myself, anyway) it's
also a matter of not having much to say about these recurrent merge
problems.  Which is never a fun way to respond :-/.

The basic problem is:
  -- merging, as a problem (ignoring the question of monotone's
     particular implementation), is a horrid mess
  -- the basic merge algorithm we currently use, 3-way merge, cannot
     in general work at all[1].
  -- to make it worse, the current changeset-handling code in general,
     and merging code in particular, is ugly and a pain to deal with.
     (Also slow, e.g. this is what makes initial pulls so slow.)

Graydon's started work on rewriting the changeset handling code in a
branch, net.venge.monotone.rewrites.csets.  The basic plan is to use
this to get changeset handling code sane, then when we have a sane
base to work from get a better merge algorithm working.  (Or maybe do
both of these at once, or something, but that's the rough idea.)

Unfortunately, this is somewhat long term.  Probably some of the bugs
people are seeing are caused by the unavoidable inherent flaws in
3-way merge, and some of them are just bugs in our changeset handling
code.  I guess no-one has been feeling super-motivated to work on
either, since the hope is they will both go away.  Which is kind of
silly, since the latter kind can at least be fixed, but it's just not
very fun work... and again, there's the matter of finding time.

About all I can offer at this exact moment is:
  -- hopefully the flood of problems will motivate some more people to
     hunt down problems? :-)
  -- apparently some of the merge errors can be worked-around by
     overriding monotone's ancestor selection by hand, and using a
     different ancestor.  (by using explicit_merge instead of merge.)
     Which makes some sense, since the 3-way merge bugs are
     exacerbated by choosing really ancient ancestors, and monotone's
     default ancestor selection algorithm tends to choose really
     ancient ancestors, especially when there are long-lived branches,
     which I get the impression the openembedded/nslu2 folks have...
  -- I think we need to make getting .csets in working order a higher
     priority :-)

Hope this helps some, and wish I could help more :-/.

[1] If anyone's curious about what the problem is:
   http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264

-- Nathaniel

-- 
"But in Middle-earth, the distinct accusative case disappeared from
the speech of the Noldor (such things happen when you are busy
fighting Orcs, Balrogs, and Dragons)."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]