[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 19 Mar 2015 01:02:12 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.