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?
