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
