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

Kevin Smith wrote:

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

Yep, that's pretty much it.

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

The problem here is that this really is a very bizarre case, and it's hard
to wrap one's brain around. In the event where it actually happens, the
reversion really is the right things to do, but they're hard to
understand.

One good example is when you have two people who both put in the same
experimental patch, both commit to their public repository, then both
revert, then both update from the other's public repository. They both
undid the changes, but for now they both have them. After one updates
again, the changes should clearly go away, but it has this funny property
that the descendant is different from both parents.

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

That's an interesting thought, but I don't immediately see what it leads
to in all examples.

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

A weave is a data structure where you store all lines which have ever
appeared in the file in order. One neat property of a weave is that you
can figure out for each individual line whether it should be included
currently and then simply put the included ones in order and you've got
the current version. That reduces the merging problem to the problem of
merging the included/not included status of each line independantly.

So yes, lines within a file are versioned, but they're versioned as
included/not included, not as modified values. If you 'modify' a line, the
version control system treats that as deleting the old one and adding a
new, unrelated one.

-Bram