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...
Received on 2015-03-19 01:06:03 CET