> From: David Sandberg [mailto:david.sandb...@hickorytech.com] > Sent: Wednesday, March 20, 2013 1:18 PM > > 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!
As Thorsten pointed out, the keywords do not store the actual revision number. Only the unexpanded "$Rev$" is stored on the server. Its sounds like "svn:keywords" isn't set correctly on Sam's feature branch. Whenever a new revision of a file is created (such as after a merge) the revision keyword should match the "Last Changed Rev:" (which you can see when you run "svn info" on the file.) What does Sam see when he runs "svn info" in step 4? After Sam's merge in step 4 (and before Sam's commit,) does a "svn diff" show any differences in the file? If the merge didn't actually change anything, then the file won't change, so the "Last Changed Rev:" doesn't change, so the revision keyword doesn't change. Also, you won't see the revision keyword change in the file until after you do a commit.
