subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: svn commit: r1667280 - in /subversion/trunk/subversion: libsvn_wc/merge.c tests/cmdline/merge_tests.py
Date Thu, 19 Mar 2015 23:36:40 GMT
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

Mime
View raw message