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

[Nathaniel Smith]

On Thu, Jan 20, 2005 at 01:02:47AM +0100, Christof Petig wrote:
> While trying to demonstrate monotone propagate to a friend I stumbled
> over some problems:
> 
> Monotone-viz shows propagate nodes as rectangles but merge nodes as
> circles. This indicates that there is a difference in data structures
> but I can't imagine the semantical difference (I used (the 3 argument)
> explicit_merge as an emergency fallback which did exactly what I
> (thought I) asked propagate to do).

I'm not sure from this what your problem with propagate was.

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.

explicit_merge is a way to do more arbitrary merges, when you need an
emergency fallback.  'propagate A B' is almost equivalent to
  let h1 = head of A (or fail if there are multiple heads)
  let h2 = head of B (or fail if there are multiple heads)
  explicit_merge h1 h2 B
There's no magic in 'propagate', it's just a tool to encapsulate one
really common use case.

(Actually, I lie, there's a little touch of magic to handle a few edge
cases, but it usually doesn't matter.)

> But since I did not write down the proposed heads* to merge I can only
> guess/hope that at least _they_ were correctly chosen (since the merge
> already happened in my database I cannot reproduce the command). Though
> Monotone chose (and will choose) the wrong ancestor, that I can tell for
> sure:
> 
> monotone lca e3623ca77d2a8b45817ecaa5b67018c453652830
> 7d5918d0181f7bb9adba2ee63234146d23bcf83e
> 
> should be 0b17415d7aa112060e8ead9ae7a486510dc61a9d
> but is ce860bae312c4bb8483d5b3b2a8cd3bebe2323d5

I can confirm this, and it does indeed seem to be a bug.  Odd.
Filed...

Fortunately it shouldn't effect much; the only places we currently use
the lca algorithm, we really just want a common ancestor, and the lca
is a convenient but not necessary choice.

'lcad', which is the algorithm that calculates ancestors for merges,
appears to give correct results on those two revisions.

> PS: My CVS client class [net.venge.monotone.cvssync] can already
> successfully retrieve all necessary information (changelog, -time,
> author, tags, file contents/patches) for a full import from a remote
> 1.11 or 1.12 cvs server.

Wow, awesome.

Does it know how to trace branches?  I've realized belatedly that
dealing with CVS branches makes the synchronization problem harder
than I, at least, was thinking...

-- Nathaniel

-- 
.i dei jitfa fanmo xatra