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

Re: Keyword substitutions not merging properly

From: Simon Large <simon.tortoisesvn_at_gmail.com>
Date: Wed, 20 Mar 2013 17:15:52 +0000

On 20 March 2013 16:01, David Sandberg <david.sandberg_at_hickorytech.com> wrote:
> Update: I have just verified that the same behavior exists with the svn command line client, so I probably posted this to the wrong list, since it does not seem to be specific to TSVN. I will look into posting it to the main SVN mailing list (if I can find it), but if anyone reading this here has any information to share about the issue, I would still be very appreciative of that. Thanks!
>
> - David
>
>> Hi, folks. I am having problems with revisions with keyword substitution 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 ... TSVN simply reports 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.

The keyword is the revision of the file that it sits in, so until that
file is committed the revision doesn't change. Presumably the keyword
does get set once you commit the file (and possibly update)? How would
subversion know what revision to use before the file is committed? The
revision of the file you merged in would not be right either. What
would happen if you merged two different trunk revisions into the
branch file?

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

You have my deepest sympathy.

Simon

-- 
:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3051544
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-03-20 18:16:05 CET

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

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