monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: 3-way merge considered harmful


From: Florian Weimer
Subject: [Monotone-devel] Re: 3-way merge considered harmful
Date: Sun, 01 May 2005 18:51:54 +0200

* Nathaniel Smith:

> Fortunately, it seems like codeville-merge is a viable replacement
> here (it can be applied to both content merges and tree rearrangement
> merges), and with some recent improvements that Bram and some other
> people (including me) have been playing with, it may (I'm not sure
> yet) be strictly more powerful than 3-way merge.

Is there some formal model of codeville-merge which one could check?

I should admit that I believe in what could be called a pessmistic
theory of merging.  Say you have two trees T_1, T_2 (with their
respective histories), some merge operator M, and a tree invariant I
such that both I(T_1) and I(T_2) hold.  What you really want is that
M(T_1, T_2) either fails, or yields a merged tree T_12 such that
I(T_12) holds.  Obviously, this is impossible unless I is known to M
and is explicitly checked by M (for example, it might be test case).

Now back to your example.  Source files contain lots of redunancy.
Often, it's possible to make a particular change in different ways,
and with truly distributed development, this isn't entirely unlikely
to happen.  The redundancy means that the changes won't necessarily
conflict in the sense of codeville-merge, and you still end up with
the same situation you described (a zombie changeset which is
resurrected from the dead).

In other worse, unless codeville-merge needs comparable resources to
the current approach, it might not be worth it.  I also fear that it
introduces spurious conflicts when several developers apply the same
diff to their development lines.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]