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

Re: Patch command execution

From: Colin Putney <cputney_at_whistler.net>
Date: 2002-02-08 02:22:37 CET

On Thursday, February 7, 2002, at 05:09 PM, Greg Stein wrote:

> On Thu, Feb 07, 2002 at 04:53:14PM -0800, Zack Weinberg wrote:
>>
>> I still don't understand why we use diff+patch to do this instead of a
>> real 3-way merge program (which has more information and therefore can
>> do a better job).
>
> The binary diffs do not have context. So we take the original text,
> apply
> the svndiff to get the new fulltext, then run the two through "diff" to
> get
> a unified diff. Then, we pipe that into patch to apply that diff to the
> user's (potentially modified) working copy.
>
> The context is the issue.

I think what Zack is suggesting is that a "real 3-way merge program"
would
scan both the original text and the new fulltext created by the binary
diff
and apply the changes to the working copy, all in one step.

This is potentially better than separating the operations into
diff/patch, because
the single program has the complete source files available when applying
the
patch, rather than just n lines of context. This lets it deal with
modifications in the
working copy more intelligently.

I think. Zack may want to correct me.

It sounds like a good idea to me... as long as we're talking about
creating our own
diff/patch/merge tools, we might as well make them do exactly what we
want.

Cheers,

Colin

------------------

Colin Putney www.whistler.com
Information Systems (877) 932-0606
Whistler.com (604) 935-0035 x221

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