On Thu, Feb 07, 2002 at 05:22:37PM -0800, Colin Putney wrote:
>
> 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.
Precisely. It's a well-known algorithm. If you have RCS installed on
your computer, "man merge" will describe one implementation. The
"diff3" utility is also handy.
> 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.
Again yes. In fact, since CVS uses 3-way merge (using rcs's merge
utility) and there are plenty of situations where merge will get a
conflict resolution right and diff+patch won't, I could argue that
this represents a regression from CVS and has to be fixed before 1.0 :-)
zw
---------------------------------------------------------------------
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