On 17.03.2015 22:53, Stefan Sperling wrote: > On Tue, Mar 17, 2015 at 10:11:28PM +0100, Bert Huijben wrote: >> >>> -----Original Message----- >>> From: s...@apache.org [mailto:s...@apache.org] >>> Sent: dinsdag 17 maart 2015 13:05 >>> To: comm...@subversion.apache.org >>> Subject: svn commit: r1667280 - in /subversion/trunk/subversion: >>> libsvn_wc/merge.c tests/cmdline/merge_tests.py >>> >>> Author: stsp >>> Date: Tue Mar 17 12:05:10 2015 >>> New Revision: 1667280 >>> >>> URL: http://svn.apache.org/r1667280 >>> Log: >>> Always install a .mine file for conflicted binary files, not just in >>> case the binary file was detranslated. >>> >>> This makes the 'mine-full' option work again from the conflict prompt. >>> Before this change, an assertion in libsvn_wc failed when the 'mine-full' >>> option was used since no path for 'mine' was recorded in conflict storage. >> 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. >> >> In case of conflicts of a binary file there is no pre-merged file with >> conflict markers and therefore we just leave the 'mine' file just where it >> is... At the original location. >> (For text conflicts we move it to a different location, and then install the >> pre-merged file with conflict markers there) >> >> >> This patch introduces a second copy of the same file, while clients always >> had to handle this case for 1.0-1.8 anyway. >> >> >> If the interactive conflict resolver needs a patch, we should probably also >> backport this patch. >> >> Bert >> > The problem is that choosing 'mine-full' crashes in libsvn_wc. > Are you suggesting we shouldn't offer the 'mine-full' option for binary files?
What does providing that option have to do with creating a duplicate file in the WC? -- Brane
