Re: [Monotone-devel] cooperative/parallel/resumed merging

[Christof Petig]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick Mauritz schrieb:
> On Tue, Jun 22, 2004 at 12:31:27PM -0400, graydon hoare wrote:
>
> >         +---- LEFT  -----+                 +--- RESIDUAL LEFT
> > --- ANC1 +                + -- SEMIMERGE -- +
> >         +---- RIGHT -----+                 +--- RESIDUAL RIGHT
> >
> > I'm not really sure this is the "least expected" situation; the two new 
> > residual heads look like "slightly more similar" versions of the 
> > previous two heads. otherwise it's the same situation.

With least expected I referred to the fact that if you last worked at 
LEFT, some of your recent changes (ANC1->LEFT) suddenly disappeared in 
SEMIMERGE [if SEMIMERGE is intended to ever looked at seriously]

> basically it merges everything from left and right that does not conflict
> with changes of the other side. the result ("semimerge" here) will likely
> be broken, too and "residual (left|right)" will probably not work out of
> the box either.

That is the point which I dislike about this proposal. Of course if the 
two trees merge well you will never notice any problems. [Changelog is 
good for destroying that hope]

> unlike conflict markers this approach still allows to make use of the
> development tools that monotone provide, namely versioning and diffs
> (how often did you forget a conflict deep inside your sources?) as well
> as interactive merging using the "normal" tools.

A really good point in favor of your proposal.

> using conflict markers you need two tool sets for managing conflicts,
> one for interactive merges, one for premerged tree states, or one tool
> that can cope with both situations.

My proposal is based on the concept of in tree merge.
As I envisioned it the procedure would be:
  [need a _fully_commited_ (aka unchanged) tree to start *]
  monotone merge <other head>
  (modifies your tree to contain the merge)
  (you can do whatever you want (e.g. test it))
  monotone commit / revert

*) otherwise conflict resolving really gets hard and you might loose 
your changes on conflict (happened often enough with CVS)

IIRC this procedure is agreed upon (and on the TODO list for monotone). 
Isn't it?

You need a file to store the two heads** (or only the head you merged 
with since the old ID is still in the tree (MT/manifest IIRC)). This is 
also common ground. [graydon proposed MT/merge-inputs, though I would 
restrict to merging only two heads at a time]

**) Actually this does not have to be a head. ***

The only problem arises from conflicts. Possibilities are:

- - CVS style markers (perhaps inferior to real 3way merge tools). 
Conflicts might get overlooked and commited (does CVS do pattern 
matching to tell whether a conflict was resolved or modification time 
comparison?)

- - note the two/three file revisions to merge somewhere. Do something to 
the conflicting file to make the user aware of the conflict? 
Provide/Reuse a tool to merge the file heads. [Prevent the user from 
committing partially resolved trees.] Commit.

- - any more?

Actually the first possibility is a specific variant of the second. 
Nothing controversial up to here. (?)

If we agree on this I will try to show how my proposal will implement 
the steps sanely (and offer additional possibilities you need not use).

    Christof

***) a special case would be cherry picking (IIRC applying one 
node/patch (ID1->ID2) from a different branch (neither ID1 nor ID2 need 
to be ancestors)). IIRC this should not modify the ancestry.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFA2S0eng+R+0ucfO0RAla2AJ0esD2bkKki9C7+B7hAF+y0yPa/2ACfRzkw
IwVPd1QmzsDTNN+8AgEfL+A=
=MZzT
-----END PGP SIGNATURE-----