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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
