monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] propagate oddities (bugs?), sure lca bugs


From: Nathaniel Smith
Subject: Re: [Monotone-devel] propagate oddities (bugs?), sure lca bugs
Date: Thu, 20 Jan 2005 03:16:50 -0800
User-agent: Mutt/1.5.6+20040907i

On Thu, Jan 20, 2005 at 12:01:57PM +0100, Christof Petig wrote:
> Nathaniel Smith schrieb:
> >I'm not sure from this what your problem with propagate was.
> 
> I can clearly say that it chose the wrong ancestor. But I had the
> _vague_ impression that propagate chose a different node than the heads
> of the two branches, and since I did not write it down and unfortunately
> closed the terminal I can not be sure (neither repeat). So _ignore_ my
> feeling of unease about propagate (once the lca[d] problem is fixed). I
> will definitely try again and look closer next time [I tried on an older
> db and it worked well (besides lca)].

Okay.

> >Monotone-viz just displays things the way it does because it thinks
> >that will make things clearer; it has no semantic meaning.  If you
> >click on a circle (merge) node then it will tell you in the little
> >box at the bottom the revision you're looking at's id.
> 
> So IMHO it's a bug in monotone-viz to display propagates as rectangular
> boxes. [Displaying _all_ kinds of merges in rounded rectangles _with_
> the ID might be a good compromise] Do you agree with me (so I might tell
> Olivier about it)?

Well, AFAIK he reads the list, so I assume he's heard about it now :-)

If I had to guess the reasoning is that usually merges are not
interesting, because they contain no "new" work.  Propagates are more
interesting, because they give you reference points on where branches
were related.  Makes some sense to me... though I admit that I've
not uncommonly wanted to see the revision id for merges.  Having a
context menu command "copy id to clipboard" would be very nice.
Having merge ids displayed, at least optionally, might be nice too.

> lcad (and 2-arg explicit merge) give
> 927cfe2588b7dcaceed47e602e5fe89232069289 which is a common ancestor (but
> one of the oldest grand grand grand ancestors) and not the newest ID
> where the graphs connect (that's the latest propagate from 0b17415...).
> 
> I do not know whether this merge is supposed to work but _only_ if I
> explicitely state 0b17415... as lca 3-way-merge is _not_ started. So
> lcad does not work for me here ...

Yes.  This isn't a bug, it's a misfeature :-).  Using LCA for merges
is unsafe (search the archives for "criss-cross merge" if you're
curious about why).  Using LCAD is safe.  However, LCAD can be
unnecessarily conservative sometimes, as very dramatically
demonstrated recently because of the old branches that have been being
merged in.  So while LCAD doesn't give the result one would
necessarily want, it is behaving as designed; as coming up with a
better design is high on our priority list.

> first glance) ... And I can't upload my latest changes to off.net ...]

If you mean that netsync'ing to off.net isn't connecting, that'd be
because it was down earlier, but is up again.  If you mean that you
netsync to off.net, and it seems to be working fine but then freezes
instead of finishing, than this is my fault fork breaking netsync in a
few recent revision of mainline; update and you should be fine :-) (or
if you're really wedged, I can email you a snapshot or something, I
guess.)

-- Nathaniel

-- 
Eternity is very long, especially towards the end.
  -- Woody Allen




reply via email to

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