Re: [cdv-devel] more merging stuff (bit long...)

Bram Cohen wrote:

> If you could go over the post and point out which examples
> you dislike, that would be helpful.


> Specifically, in this case:
>
> a
> |\
> b \
> |  \
> a   c
>
> The result should be c, since the b is toasted by a revision to a. 

If I (as the maintainer) did a->b->a, and a random contributor did a->c, 
I don't necessarily want to silently take their change to c.

> As I mentioned previously, this results in one very bizarre case:
>
>   a
>  / \
> /   \
> b    b
> |\  /|
> a \/ a
> | /\ |
> |/  \|
> b    b

I'm not good at bizarre cases yet.

> On both sides we have one do and one implicit undo, so both sides merged
> clean to 'do', but when you put them together there are undos of both dos,
> so the result should clean merge to a, even though both ancestors are b.

At first glance, that makes no sense at all. Superficially, merging b 
and b and getting a result of a seems comical. But with more notation I 
can attempt a rational argument:

  a
 / \
/   \
Xb  Pb
|\  /|
Ya\/Ra
| /\ |
|/  \|
Zb  Sb

It looks to me like when Y and P were merged to create Z, someone 
specifically chose b over a. Same for RX->S. So two different mergers 
chose b over a. b should win.

Ah, but going back a step, I see that with your implicit undo rules, the 
merges creating Z and S would have both been resolved implicitly, rather 
than explicitly. Obviously that would shatter my argument, since in your 
world, nobody was explicit after Y and R were created, and thus the last 
explicit choices (which were both a over b) should win.

To me, the confusing and unexpected results of this case convince me 
even more that allowing implicit undo to make automatic changes is 
dangerous.

> > Do you still have the same opinion if the graph is:
> >    |
> >    a
> >    |
> >    b
> >   / \
> >  c   b
> >  |  / \
> >  b  b  c
> >  \ /
> >   b
>
>
> In this case the b overriding c was an undo, rather than a new value, so
> it has null effect. The c should win. This is a case where having undos
> makes the correct behavior clearer.

These are getting complex. Um...If that leftmost path is me, and the 
right paths are other people, then I really don't think their c should 
automatically replace the b that I specifically chose over c earlier.

Maybe my preference, which might translate badly to an algorithm, is 
that any time my changes might win over someone elses, take mine, but 
whenever theirs might win, be conservative and generate a conflict. I 
haven't thought it through carefully, but as a maintainer, I definitely 
place a higher value on my own changes than on those of someone else.

It might also depend on what tools I have available to review the 
changes before and/or after the merge takes place. Personally, I would 
prefer to have a GUI merger similar to the CVS tool in eclipse, which 
allows me to easily review each change, and take it or not, OR to hit a 
button to automatically merge all non-conflicting changes and handle the 
rest manually. With that, I *definitely* prefer conflicts over implicit 
(and possibly incorrect) automatic merging.

However, if I am using primitive tools (such as are available for most 
distributed SCM's today), I might find excessive conflicts to be so 
painful that I would take some risk of incorrect merges. Well, if I were 
on a big project anyway. Most of my projects are small enough that I 
prefer (and can manage) fine control.



One other question: Nathanial seemed to stress that none of this applied 
to line merges, but rather was aimed at tree-level changes. But your 
examples were of someone inserting and removing a single debugging 
statement. Do you view the scope of this as including lines within a file?

Kevin