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...
