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

Re: svn diff uses internal diff!, WAS: RE: Diff plugins

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-02-16 14:32:21 CET

Greg Stein <gstein@lyra.org> writes:

> On Sat, Feb 15, 2003 at 01:46:26AM +0100, Sander Striker wrote:
> >...
> > Ok, we can get rid of diff-cmd and SVN_CLIENT_DIFF right now. The diff3
> > stuff is a bit different. I haven't merged over the internal merge code
> > yet because there is no opt out (yet). I'm guessing we will need a
> > merge-cmd option (and we will need a merge_fn once we move to the provider
> > scheme). Anyway, thoughts on whether we should move to internal or hold
> > off on it until we have an opt-out?
> Switch it. The opt-out isn't required; we're only asking for it for safety's
> sake. Worst case, somebody can always get the two files and diff them. Or
> just wait a few days for the functionality to arrive.

I think that's a bit premature. We need some more merge regression
tests, in particular more extensive conflict detection. We need to
make sure that the internal merge is not going to lose local
modifications during an update. I'm thinking of scenarios like: I add
four new lines to a file, the update is going to merge two new lines
that happen to exactly match two of my new lines. In that sort of
case it's important that internal merge doesn't destroy my local
change. The straightforward way to "backup" my local mods before
running update is to use diff, but if that uses the internal diff and
has a bug then the "backup" may fail.

I have no reason to believe that there is any failure to detect
conflicts with the current internal merge, but without a regression
test such a problem could get introduced at any time.

I have no problem with the internal diff/merge being enabled as the
default right now, but until we have more regression tests I think we
should provide an option to allow a paranoid user to disable use of
the internal library and fall back on the external programs.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 16 14:33:13 2003

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