On Wed, Mar 18, 2015 at 10:53:11PM +0100, Bert Huijben wrote: > (Extending my original answer) > > Mine-full should just be implemented as a simple resolve without changing the > file. The right 'mine' file is already in the right place on a conflict of a > binary file. > > Creating a copy of a file, to allow replacing the original file with an > identical copy is not that useful. > > > For text conflicts we create a file with conflict markers, and make the > original file available as mine. > For binary files we can't (and don't) create such a file, so the file is > untouched. > > Where does creating a copy help? > > Bert
Implementing the "mine-full" option as a simple resolve sounds good. Restoring the working file from a copy might be a bad idea indeed. Perhaps the user did change the file after we copied it! So we could store the file's working copy path as "mine". However, this isn't really what I thought we were discussing. You said: "I think it is better to make the interactive conflict resolver work the way we always installed binary conflicts since 1.0, than to change the way we install conflict markers for a bugfix of the conflict resolver." The way I understand this statement is: Don't change libsvn_wc, change the conflict resolver in 'svn' instead. Am I misunderstanding? I don't see a way of fixing this problem in 'svn' since we'll need to store some path as 'mine' in conflict meta data, or we need to fix the parser in libsvn_wc to never leave the 'mine' path as NULL. A NULL path will cause an assertion in libsvn_wc if the client passes svn_wc_conflict_choose_mine_full. Hence my question whether you want to stop using 'mine-full' altogether...
