SVN Merge Tracking Issues

[Michael.Rumpf]

Hi,

we have migrated a SVN repository that heavily relies on the relatively new 
merge tracking feature. By doing that we have been struggeling with two major 
issues:

1. Svn move does not fix svn:mergeinfo property values
2. Svn merge operation does not realize that the code has been moved to a new 
location

Issue 1.
In order to align the repository folder hierarchy to the pattern of a 
multi-project repository layout we had to move the Java and COBOL sources from 
folder /proj/import/.../0500_COBOL/appA (imported from a SVN dump) into 
/proj/source/cobol/appA.
The appA folder was "SVN moved" by Drag&Drop in the Tortoise SVN Client Repo 
Browser View to the new location. The users afterwards complained that the 
Merge Tracking Feature was broken and that they could not see the still to be 
merged changesets anymore.
After analyzing the issue we found that the merge-tracking property 
"svn:mergeinfo" was still pointing to the initial import location.
After running a script that fixes the svn:mergeinfo property values by a set of 
sed operations, the merge tracking view in the TortoiseSVN client was working 
again.

Issue 2.
After one user merged a changeset, another user was complaining that he could 
not see what the first user just merged. An analysis revealed that the value of 
svn:mergeinfo, generated by the svn merge opertaion had again the old location 
from where the changeset was coming from:
svn:mergeinfo= /proj/import/.../0500_COBOL/appA 12345
It seems as if the svn merge operation takes the svn:mergeinfo information from 
the revision it is merging. Because the properties have been changed on the 
HEAD only, the old revisions still contain the old paths.
That leads back to issue number 1 which has to be fixed by our sed script again.
The idea is now to run a script regularly which adapts the paths to the new 
location, but with an hourly Cron script there is still the potential that the 
users are running into trouble. The idea to let an SVN pre-commit hook fix the 
properties seems to be dangerous when referring to the docs: "While hook 
scripts can do almost anything, there is one dimension in which hook script 
authors should show restraint: do not modify a commit transaction using hook 
scripts"

To me it seems as if the SVN merge tracking feature still has a few open ends 
and that if your are relying on the feature, you can _never_ reorganize your 
folder layout without breaking the merge tracking feature at least for the 
revisions that have not yet been merged.

Regards,
 Michael

RE: SVN Merge Tracking Issues

[Michael.Rumpf]

Hi Stefan,

thanks for the quick reply.

>Please never, ever, modify mergeinfo manually.
...
>Then load this dump file into a new repository and use that repository
>instead of the old one.

We have created a backup (Hotcopy) of the repository before we did the property 
changes so we might get back to it any time (almost any time, see below ;) )

>Which releases of Subversion are you using?
...
>At this time, the latest release in the 1.6.x series is 1.6.17.
>The latest release in the 1.7.x series is 1.7.1.

The server is reporting the following version:
Powered by Subversion version 1.6.16 (r1073529).
Tortoise SVN shows 1.6.16.21511

>> Issue 2.
>> After one user merged a changeset, another user was complaining that
...
>please let me know what the differences are so we can walk through
>an example which matches your problem.

OK

>Suppose we start off with the following structure:
>
>revision 2 ("r2"):
>  /branch (copy of trunk@r1)
>  /trunk
>
>We now make an edit in /trunk in r3:
>
>  $ svn co http://svn.example.com/repos/trunk
>  $ cd trunk
>  $ echo foo >> somefile
>  $ svn ci -m "edit somefile"
>
>and merge this edit to /branch in r4.
>
>  $ cd branch-working-copy
>  $ svn co http://svn.example.com/repos/branch
>  $ cd branch
>  $ svn merge ^/trunk
>
>Now someone clever comes a long and renames ^/trunk to ^/master in r5:
>
>  $ cd trunk
>  $ svn mv ^/trunk ^/master -m "rename trunk to master"
>  $ svn switch ^/master   # update trunk working copy to the new
>location
>
>In r6, we make another edit on the trunk (now 'master'):
>
>  $ cd trunk
>  $ echo foo >> somefile
>  $ svn ci -m "edit somefile"
>
>In the branch working copy, asking for unmerged revisions from
>^/trunk@HEAD fails because ^/trunk doesn't appear in the HEAD
>revision anymore:
>
>  $ cd branch
>  $ svn mergeinfo --show-revs eligible ^/trunk
>  svn: E160013: File not found: revision 6, path '/trunk'
>
>Note that the mergeinfo command still works if we specify a peg-revision
>in the URL to tell Subversion to look for the path /trunk at revision 4
>instead of in the HEAD revision (the default peg-revision is HEAD where
>/trunk does not exist anymore):
>
>  $ svn mergeinfo --show-revs merged ^/trunk@4
>  r3
>
>Likewise, if the new name is used, the eligible revisions appear:
>
>  $ svn mergeinfo --show-revs eligible ^/master
>  r6
>
>And we can also merge from the new name:
>
>  $ svn merge  ^/master
>  --- Recording mergeinfo for merge of r4 into '.':
>   U   .
>  --- Merging r5 through r6 into '.':
>  Ualpha
>  --- Recording mergeinfo for merge of r5 through r6 into '.':
>   G   .
>  $ svn propget -v svn:mergeinfo .
>  Properties on '.':
>svn:mergeinfo
>  /master:5-6
>  /trunk:2-4
>
>Does this match the situation you were facing?
>If so, can you point out where you think the behaviour is wrong?
>Would you expect Subversion to merge from ^/master if ^/trunk
>is specified as a merge source? If so, keep in mind that peg-revisions
>are important in this context. If they aren't specified, Subversion
>might behave differently to what you expect, because a peg-revision of
>HEAD will be assumed by default for all paths.

This seems to be exactly the issue we are facing. The developers are using 
TortoiseSVN and not the command-line, so I need to map the commands to the UI 
client:

1. Open the Merge Editor 
2. Open the browser window "URL to merge from: -> ..."
You need to enter a URL, otherwise the "..." will not open any window.
If you enter the old ^/trunk it switches back to the current root, as the 
window opens with "HEAD" revision.
3. Go back to the revision before the rename/move operation happened: 4 in your 
example above (69398 in my case)
4. Select the Branch URL for the old location from which you want to merge
5. Click OK
6. Click on Show Log for the "Revisions range to merge"
No eligible revisions are shown in the list, instead it says 
'/svn/REPO/!svn/bc/5/trunk' path not found (69402 in my case)

For this test I turned back my local working copy to the revision before the 
svn:mergeinfo change (rev 69508). I currently do not have the chance to get the 
server repository back to the hotcopy version as no admin is available until 
wednesday because there is a public holiday tomorrow in Germany ;)

Regards,
 Michael