[Monotone-devel] Re: Merging issue

[Lapo Luchini]

Peter Schanhorst wrote:
> NOTE: the "mtn explicit_merge rev1 rev3 --branch=branch1" is
> DISALLOWED by mtn, and there is not possible to enforce it using some
> special cmd parameter.

I may be completely wrong (and I know nothing of ClearCase, in fact),
but I think the main problem is not what merge does, but rather what you
do expect it to do (I guess, probably, because the metaphor behind
clearcase merge is simply different from the one in monotone...).

In you example rev2 shows an explicit human intervention that states
"code in rev1 is wrong, I want this new code". Of course monotone
doesn't (and can't) know that the committer of rev2 is less experienced
than the comitter of rev1.

Merge works assuming that EVERY explicit human intervention (e.g. a star
in star-merge algorithm) is precious.

If rev1 committer wants to say "no, rev2 is no good, rev1 is good" it
must say it explicitly disapproving rev2: that's the only way the
history graph can show that "explicit choice" made by rev1 committer.

Now you have two heads (one made by rev1 committer, one by rev3
committer), and now you can do you nice normal "merge" (normal merge, no
need for an explicit one... in years of using monotone I needed
explicit_merge only a couple of times, IMvHO it's not the correct tool
for what you are doing).

I don't think this is "an ugly hack", it is IMHO "the correct way to go"
in a DAG-based versioning system; deprecating rev2 in rev4 is simply the
"linear" approximation old non-DAG-based tools convinced us was the best
way (it was indeed the best - but only if you are limited to a linear
history!).
More of this here:
http://www.venge.net/mtn-wiki/DaggyFixes

my own .02$...
I leave to more experienced users to dissect the proposed problem in
deeper, because don't get me wrong: I'm *not* saying that your problem
is a non-problem, I'm only saying that we should *also* consider the
chance it is a documentation problem or a metaphor problem. Your
use-case is as good as anyonelse's and it's correct to find a "perfect"
solution to your case. And if that needs change to the code or the UI,
se be it, if OTOH it only needs to rewrite parts of the manual to be
more clear in that regard, so be it. ;-)

    Lapo