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

Keyword substitutions not being merged correctly

From: David Sandberg <david.sandberg_at_HickoryTech.com>
Date: Wed, 20 Mar 2013 12:17:58 -0500

Hi, folks. I am having problems with revisions that include keyword substitutions being merged into a different branch incorrectly. Specifically, we are setting the Revision keyword on certain files. Those revisions are being reflected properly in the repository when they are committed, and when other users update their working copies from that same branch, they get the updated revision numbers in those files just fine. However, when those same revisions are merged into a different branch, the revision numbers are never updated even though other changes to the same files in the same revision do get merged automatically. There is no prompt for a file conflict or anything like that ... both TortioseSVN and the SVN 1.7.8 command line client simply report the file was merged successfully.

To be clear, I'm talking about a scenario like the following:

1) User Jim commits a new file A with the Revision keyword to the trunk in revision 101.
2) User Sam merges trunk revision 101 into his feature branch, and the new file A comes across fine and shows revision 101 in the keyword substitution part of the file.
3) Jim commits an update to file A to the trunk, in revision 200. (If other users who are working in the trunk pull this file at this time, it updates and the keyword in their updated file correctly reads 200.)
4) Now, Sam merges trunk revision 200 into his feature branch. The merge happens automatically without prompts for conflicts or anything, and the resulting file A contains MOST of the changes from the trunk revision ... EXCEPT for the Revision keyword, which stays at 101!

This has happened in 100% of our tests ... it's not just an intermittent problem. I have tried these merges with and without the auto-props properties being set on the merging system, and it doesn't matter. I have also tried creating plain .txt files with these revisions in case it was an issue with the file type, and that is broken in precisely the same way.

Our SVN server is running v1.6.15-1, in case that matters.

Because we have business logic that depends upon these revision numbers being merged properly, this problem has a segment of our company actively talking about switching back to VSS, for goodness sake, so if anyone has a solution for this I would be very appreciative. Thanks for your time in reading this.

David Sandberg
Received on 2013-03-20 18:18:17 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.