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: stsp_at_apache.org [mailto:stsp_at_apache.org]
>>> Sent: dinsdag 17 maart 2015 13:05
>>> To: commits_at_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
Received on 2015-03-18 02:01:46 CET