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.tu...@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
