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

Reply via email to