monotone-devel
[Top][All Lists]

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

 From: Kevin Smith Subject: [Monotone-devel] Re: [cdv-devel] more merging stuff (bit long...) Date: Sun, 07 Aug 2005 16:40:17 -0400 User-agent: Mozilla Thunderbird 1.0.6 (X11/20050727)

```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

```