Philip Martin <philip@codematters.co.uk> writes:
> A picture is worth a thousand words, but you need the right
> picture :-)
>
> Here is the common ancestor
>
> $ cat file2
> line 1
> line 2
> line 3
> line 4
> line 5
>
> Here is what I want to merge from (the branch perhaps)
>
> $ cat file3
> line 1
> line 2 change A
> line 3
> line 4 change B
> line 5
This terminology I don't quite understand. One doesn't want to merge
"from" a single file -- one wants to merge the changes between files X
and Y into file Z. X may be an ancestor of Z, or it may be cousin
(see below).
> Here is what I want to merge to (the trunk perhaps)
>
> $ cat file1
> change C
> line 1
> line 2 change A
> line 3
> line 4
> line 5
> line 6
>
> Here is basic diff + patch
>
> $ diff -u file2 file3 | patch file1
> patching file `file1'
> Hunk #1 FAILED at 1.
> 1 out of 1 hunk FAILED -- saving rejects to file1.rej
>
> Here is a 3-way merge, 3-way diff, whatever you want to call it
>
> $ merge -p file1 file2 file3
> change C
> line 1
> line 2 change A
> line 3
> line 4 change B
> line 5
> line 6
>
> A simple diff + patch can be used, but merge results in fewer
> conflicts. The merge algorithm may not work in all cases (I would
> like to work on a better one myself) but the important bit is to have
> all three files available as that enables the possibility of a more
> intelligent algorithm. Who knows, perhaps we can select the merge
> algorithm based on file type, there is no reason why merge has to be
> limited to a line by line comparison. A specialised merge could parse
> the file and do something very sophisticated.
I'm not saying that we shouldn't use diff3 under the hood, or whatever
program will give us the fewest spurious conflicts. And I understand
the mechanism by which it results in fewer conflicts (thanks also to
Greg Hudson for the explanation about patch-walking).
Here's what I still don't understand. You have constructed an example
in which the object you call the "common ancestor" really is plausibly
a common ancestor. But that's not usually the case in merges (see my
mail just now responding to Sander Striker). So why call it a "common
ancestor"??? That's what's completely baffling me, but that term is
used so consistently that it must be important...
In
.-----| BAR:1 ---> BAR:2 ---> BAR:3 ---> BAR:4 ---> BAR:5
/
/
FOO:3 ---> FOO:4 ---> FOO:5 ---> FOO:6 ---> FOO:7 ---> FOO:8
(This means BAR:1 == FOO:3, it's the branch point.)
If we say "I want to merge BAR:5 into FOO:8", that's just a compressed
way of saying
"I want to merge the changes from BAR:1 --> BAR:5 into FOO:8"
By saying the sentence in its fully expanded from, we see immediately
that we have more choice -- we don't have to use BAR:1, we could say
instead
"I want to merge the changes from BAR:3 --> BAR:5 into FOO:8"
and that's still a perfectly valid merge (and one that people do all
the time). But BAR:3 is not a common ancestor of FOO:8 and BAR:5!
It's an ancestor of BAR:5 and a cousin of FOO:8. There could be huge
changes from BAR:1 to BAR:3 that are not present anywhere in the FOO
line, but which might not interfere with the merge.
I'm still *completely* missing some theoretical point here. I
understand that we have to have all three files present (which we
already do). And we can use diff3 on them.
But why is one of them considered ancestor to the other two? It's
just not, as far as I can tell. It's probably ancestor to one of
them, and may or may not be ancestor to the other.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006