We are leveraging svn:mergeinfo to reconcile revisions made on branches (pending releases), onto other branches (future releases), and ultimately the trunk (ongoing development, CI).
Occasionally we have svn:mergeinfo that gets stepped on (deleted) as developers are merging changes back toward the trunk.
Let me try to spell out the steps, but I'll focus on the property changes and not the code changes, as that is where the issue is:
User A commits changes on /branches/patch and create revision 100.
User A merges those changes, specifying revision number 100, from /branches/patch to /branches/major.
User A commits to /branches/major and in that revision we see the property changes of revision '100' being added to svn:mergeinfo
User B commits changes on /branches/patch and create revision 110.
User B merges those changes, specifying revision number 110, from /branches/patch to /branches/major.
User B commits to /branches/major and in that revision we see the property changes of revision '110' being added but revision '100' being removed from svn:mergeinfo
To clarify;
User B is probably using an existing WC pointed at /branches/major and not doing a switch on the WC used to commit to /branches/patch to perform the merge.
User B says he did an 'svn up' prior to the merge (but who knows).
User B was not warned (or prevented) during the commit that an update was needed.
I am seeing this issue with both my CLI and TortoiseSVN user base (possibly Subclipse also).
I have not narrowed this down to see if User B (or A) is always doing a straight up merge or a 'record-only' during this issue.
We are all are using v1.7.x SVN clients and we are using v1.7.5 on the server side.
Randall Fisher
Navicure, Inc.
2055 Sugarloaf Circle
Suite 600
Duluth, GA 30097
770-342-0207
rfisher_at_navicure.com<mailto:rfisher_at_navicure.com>
www.navicure.com<http://www.navicure.com/>
Received on 2014-05-27 16:57:41 CEST