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_at_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_at_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_at_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 '.':
> U alpha
> --- 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
Received on 2011-10-31 17:22:00 CET