[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: Sander Striker <striker_at_apache.org>
Date: 2002-02-16 00:41:56 CET

> From: Mark Benedetto King [mailto:bking@answerfriend.com]
> Sent: 15 February 2002 22:37

>> On Fri, Feb 15, 2002 at 03:08:12PM -0600, Karl Fogel wrote:
[...]
>> Yes, completely agree. Really perfect merging is much more
>> sophisticated than either diff+patch or diff3, and is non-trivial to
>> implement. Giving clients plug-in options is part of it (we'll have
>> to supply that fourth file -- the true common ancestor -- for them,
>> too!)
>>
>
> Speaking of four-file merges, the case that we've been talking
> about *does* have a use for them:
>
> imagine:
>
> foo:1 -> foo:2 -> foo:3
> |
> bar:1 -> bar:2 -> ... -> bar:6 -> bar:7
>
> And we want to merge bar:6->bar:7 into foo:3.
>
> Now, consider that foo:3 and bar:6 might be wildly
> different, due to highly divergent development.
>
> There are 3 relevant diff chunks:
>
> Wander1 = foo:1/bar:1 -> foo:3
> Wander2 = foo:1/bar:1 -> bar:6
> Change = bar:6 -> bar:7
>
> Now, in order to apply Change to foo:3, we need to know *where* to
> apply it. The location in bar:6 could be vastly different from the
> location in foo:3, and foo:3 could have repetitive data (we all know about
> cut-n-paste programmers), so matching on context could be dangerous.
> However, all is not lost, if we use Wander1 and Wander2 to generate
> fixup information on Change.
>
> Basically, Wander2 can put Change into foo:1/bar:1's "co-ordinate system"
> and Wander1 can translate *that* change into foo:3's "co-ordinate system".

For me: Wander1, Wander2 and Change are all edit scripts.

Now actually to get the best alignment we want:

Wander1 = foo:1/bar:1 -> foo:3

Wander2a = foo:1/bar:1 -> bar:6
Wander2b = foo:1/bar:1 -> bar:7

Wander2 = Wander2b - Wander2a

We then try to merge Wander1 and Wander2 (line them up on matching elements).
We then can identify conflicting changes, and simply merge the non conflicting
ones.

Sidenote: From the point where we have only 2 edit scripts, Wander1 and Wander2,
we have the same as in an update. In an update we would have:

Wander1 = baseline -> repos
Wander2 = baseline -> working copy

>> The paper is www/variance-adjusted-patching.html, by the way. It
>> probably suffers from making up terminology for things that already
>> had accepted words, but the meaning is the same anyway.
>>
>
> I mentioned this to Karl on IRC and he told me to read v-a-p.html,
> so I probably should.
>
>> I don't think we're aiming for perfect merging right now. We just
>> need to be as good as CVS, and that means diff3 with three files, no
>> one of which is necessarily a common ancestor.
>
> Yeah, but we might as well do as good a job as we can.

I agree. And if we make good progress on our own diff/merge library,
we should definately see if that gives us better results. I think it will.
Now we need the code to prove it ;)
 
> "Aiming at timelessness is a way to make yourself find the best answer: if
> you can imagine someone surpassing you, you should do it yourself. Some of
> the greatest masters did this so well that they left little room for those
> who came after. Every engraver since Durer has had to live in his shadow."
>
> Excerpted from http://www.paulgraham.com/taste.html,
> which, btw, is a pretty good read.
>
> --ben

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