Karl Fogel <kfogel@newton.ch.collab.net> writes:
> 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).
It's what happend all the time in our development model. All
development was carried out on sub-branches, and when the task was
complete the entire branch was merged back to the main branch. The
only development that happenend on the main branch was merging
sub-branches.
As far as merging part of a branch goes, I agree it could happen, I
won't argue with that, obviously it could occur. I have no idea which
is the more common case. (Is it true that it is common in CVS because
repeatedy merging an entire branch causes problems? This should not
happen if the metadata is used correctly to identify a "closer" common
ancestor.)
> 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
Hey, you might be right, I've never tried to design a 3-way merge
system before. I'm not even sure that everything I would like is
possible. Using ClearCase it usually just worked and I never thought
any more about it. This is hard!
> I
> understand that we have to have all three files present (which we
> already do). And we can use diff3 on them.
I think this scenario is an even more complicated than a basic 3-way
merge.
In this case the BAR:3-->BAR:5 delta will need to be adjusted to
account for both the FOO:3-->BAR:3 and the FOO:3-->FOO:8 changes
before it will apply to the revision FOO:8. If you don't do this you
are back into using a simple diff+patch and hoping that patch can
adjust the relevant context. How about an example:
FOO : 3 FOO : 8
line1 xxxlineA1
line2 xxxlineA2
line3 xxxlineA3
line4 xxxlineA4
line1
line2
xxxlineC
line3
xxxlineD
line4
BAR : 3 BAR : 5
yyy yyy
line1 line1
yyy yyy
line2 line2
yyy yyy
line3 LINE3
yyy yyy
line4 line4
yyy yyy
The BAR:3-->BAR:5 change is
< line3
> LINE3 the change
This is simple and a person could apply it to FOO:8. However unless
the merge process somehow first takes out the FOO:3-->BAR:3 changes
and then puts in the FOO:3-->FOO:8 changes, merge will find hard to
make the change. Without going via FOO:3 it may not be possible to
identify the BAR line 6 in the middle of
yyy
line3
yyy
as corresponding to to the FOO line 8 in the middle of
xxxlineC
line3
xxxlineD
My feeling is that FOO:3 is essential, I guess it's a 4-way merge :)
I don't know whether the GNU diff3 and/or merge can do this, but I
susect not. We can certainly write our own algorithm to do it, it's
just a question of time/effort. As before we can start with a simple
diff+patch or diff3 or merge and later move to a more sophisticated
algorithm.
--
Philip
---------------------------------------------------------------------
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