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

On Thu, Mar 19, 2015 at 07:27:54AM +0000, Bert Huijben wrote:
> If Subversion considers the file to be unmergeable, the .mine file isn't
> created, since it would be identical to the working file.)

I don't think that's a very good argument. There are two problems with this:

The book's argument hinges on the assumption that the working file is owned
by SVN. But it is owned by the user so it's not safe to assume its contents
match some known state.

And the pre-update state is not preserved for binary files, while it is for
text files. That's inconsistent, and perhaps inconvenient for the user.
What if they changed the binary in an attempt to resolve the conflict but
then decide they'd rather have the pre-update state back?

But I won't bother arguing about historical behaviour. I'll try to fix the
problem without changing what's stored in the conflict storage.

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.

There is clearly a gaping disconnect between the resolver user interface and
the conflict storage implementation. There were too many cooks working during
different time periods and not talking to each other...
Received on 2015-03-19 10:26:53 CET