[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "svn diff" and "svn merge" sittin' in a tree

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-02-15 20:20:19 CET

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

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

> 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

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

     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


as corresponding to to the FOO line 8 in the middle of


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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.