Stefan Sperling wrote:
> [moving this thread from users@ to dev@]
>
> On Thu, May 31, 2012 at 05:22:41PM +0200, Stefan Sperling wrote:
>> On Thu, May 31, 2012 at 02:36:56PM +0100, Neil.Tuffs_at_rwe.com wrote:
>> > I would like to confirm this issue in v 1.6.17 - using binary files
>> > via TortoiseSVN. Test scenario was to create a binary file in trunk
>> > with the "svn:keywords = Revision" property set*; branch the trunk to
>> > $BAU; change the file in $BAU (and commit); merge the change revision
>> > from $BAU back into trunk, this reported the file as a conflict
>> > (performing same on a second file without the property set worked
>> > without conflict).
>>
>> Hi Neil,
>>
>> We don't fix these kinds of bugs in the 1.6 series anymore.
>> The 1.6 series receives only security or data corruption fixes.
>>
>> By code inspection I would guess that 1.7 has the same problem, however.
>> Can you confirm that? If so, please file an issue. I believe there might
>> be a bug where the merge compares a version of the file with keywords
>> expanded to a version of a file with keywords contracted. I don't have
>> time right now to dig deeper so it would be great if you could help by
>> confirming that the same problem exists in 1.7. Cheers!
>
> I've spent some time on this now and I can reproduce the issue.
>
> You've added a comment to issue #4155 but I am not sure if that is
> really the same problem.
>
> What is happening here is that your assumption to use svn:keywords
> on a binary file conflicts with how the merge logic is currently
> implemented. The merge logic purposefully skips keyword handling
> on binary files entirely (see the detranslate_wc_file() function in
> libsvn_client/merge.c), yet keywords are still expanded in the binary file.
>
> This is inconsistent behaviour. But I'm not sure which way we should fix it.
>
> I'm inclined to fix the merge logic to assume that binary files might have
> keywords expanded. Fixing the inconsistency the other way, by preventing
> keyword expansion in binary files in the first place, would be a more
> invasive change and possibly be perceived as a regression by users (Neil
> included :)
>
> Any thoughts from others about this?
I have no particular preference for what to do here; your analysis sounds fine.
- Julian
Received on 2012-05-31 20:00:57 CEST