Re: svn commit: r1667280 - in /subversion/trunk/subversion: libsvn_wc/merge.c tests/cmdline/merge_tests.py

Stefan Sperling wrote on Thu, Mar 19, 2015 at 11:31:09 +0100:
> On Thu, Mar 19, 2015 at 10:19:18AM +0100, Stefan Sperling wrote:
> > I agree with Daniel's point that resolving to 'mine-full' is not the same as
> > resolving to 'working'. Else, why do we even have these two different options?
> >
> > Perhaps the answer is to stop offering 'mine-full' for binaries, since SVN
> > does not preserve the pre-update state which corresponds to 'mine-full',
> > and never did.
>
> See r1667691 and r1667692. Is this better?

I haven't reviewed the code, but making "mine-full" always mean "the
working file as it was just before the conflict" (and erroring out if
that option is selected when that file is unavailable) makes sense to me.

Incidentally, the error message added in r1667691 doesn't seem to get
triggered when a non-binary file's .mine file is missing:

% ls
iota iota.mine iota.r1 iota.r2
% rm iota.mine
% svn resolve --accept=mf iota
svn: warning: W155027: Unable to resolve conflicts on '/tmp/svn/wc/iota'
svn: E155027: Failure occurred resolving one or more conflicts

It would be nice to have the r1667691 error in this case too, since the
present error doesn't explain the reason resolution failed.

(In the above excerpt, iota is a non-binary file.)

Daniel
Received on 2015-03-20 00:39:25 CET