[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge bug -- svn:keywords and conflict resolution

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 31 May 2012 18:34:49 +0200

[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?
Received on 2012-05-31 18:35:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.