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

[Christof Petig]

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)].

> 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)?

> 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.)

That's exactly the behaviour I expected.

> > 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...

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 ...

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

see above. I had the impression that lca gave the 'better' result so I
reported that one.

> > 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.

[Actually I have a problem with update giving a conflict on _one_ file
between unchanged (!) 1.6 and 1.7 - strange, perhaps my lame dead->Exp
handling is the cause (1.6 might be dead thought it does not seem so at
first glance) ... And I can't upload my latest changes to off.net ...]

> 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...

It can tell the user about tagged branches (which might get imported
into a different (or even the same) monotone branch with a separate
cvs_pull command). I do not want monotone to guess a name for side
branches (or import them by default). Dealing with each CVS branch
separately greatly simplifies the logic (both within monotone and the
user's head).

    Christof

signature.asc
Description: OpenPGP digital signature