We leave mine as NULL in svn_wc_entry_t since 1.0 in this case. libsvn_wc, svn, and all other users should just handle this properly. Where they don’t there is a bug, that should be fixed here instead of by redesigning the way we store binary file conflicts. (Note that there were more cases were some markers are missing... We call these tree conflicts today, but we hadn’t those in 1.5)
Storing the path itself in the skel will break other code. (Like the code that removes all the markerfiles in a dir. And the feature that a conflict can be resolved by removing the marker files. Not to forget svn_wc_entry_t) . Whatever we store in the transient/in memory only svn_wc_conflict_description2_t is less well defined. I’m guessing we just copied svn_wc_entry_t at first in cases like info (caused by missing tests and knowledge for this case), but pass the actual path in an interactive situation.
Bert
Sent from Windows Mail
From: Stefan Sperling
Sent: Thursday, March 19, 2015 1:02 AM
To: Bert Huijben
Cc: Branko Čibej, dev_at_subversion.apache.org
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 07:22:47 CET