[Top][All Lists]
[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.