You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mi...@t-systems.com on 2011/10/31 09:59:32 UTC
SVN Merge Tracking Issues
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
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 31, 2011 at 02:38:54PM +0100, Stefan Sperling wrote:
> $ svn merge ^/master
> --- Recording mergeinfo for merge of r4 into '.':
> U .
> --- Merging r5 through r6 into '.':
> U alpha
I forgot to edit this output, sorry.
To match up with other commands in the example, this should have said:
U somefile
Re: SVN Merge Tracking Issues
Posted by Neil Bird <ne...@jibbyjobby.co.uk>.
Around about 31/10/11 16:21, Michael.Rumpf@t-systems.com typed ...
> 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
Isn't that wrong? In this example, you should be selecting
"<REPO-URL>/master", not going back to the old trunk. By going backwards,
aren't you effectively restricting the revs. you want to merge to that point
in the past?
--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit
Re: SVN Merge Tracking Issues
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 31, 2011 at 05:21:12PM +0100, Michael.Rumpf@t-systems.com wrote:
> >Does this match the situation you were facing?
> This seems to be exactly the issue we are facing.
Great! So it should "just work" if the tool is driven in the right way.
> 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)
>
I think you should ask on the tortoisesvn users mailing list about
this (see http://tortoisesvn.net/community.html).
It is possible that this is a problem in the way TortoiseSVN queries
the SVN API. Maybe it passes a wrong peg-revision, without allowing
the user to specify a different one?
I'm not familiar with TortoiseSVN internals so I'm afraid I
cannot help further.
RE: SVN Merge Tracking Issues
Posted by Mi...@t-systems.com.
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 '.':
> 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
Re: SVN Merge Tracking Issues
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 31, 2011 at 09:59:32AM +0100, Michael.Rumpf@t-systems.com wrote:
> 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.
Please never, ever, modify mergeinfo manually.
This can cause a lot of problems.
Mergeinfo should only be modified by Subversion.
What you did is wrong because mergeinfo is supposed to record
paths as they existed at particular revisions. If Subversion used
the old path in mergeinfo, then it was likely correct in doing so.
You should dump and the repository and undo your manual mergeinfo edits
in older revisions in this dump file using the 'transform-prop'
subcommand of svndumptool (http://svn.borg.ch/svndumptool/0.6.1/README.txt).
Then load this dump file into a new repository and use that repository
instead of the old one.
Which releases of Subversion are you using?
Please make sure your Subversion clients are recent versions.
A lot of merge-tracking fixes have been made in patch releases,
and if you are using older releases you might run into problems
that are fixed in newer versions.
For instance, 1.7.0 contains this fix, which is similar to the
problem you are seeing (though not necessarily the same problem):
* fixed: target moved after branching breaks reintegrate (issue #3640)
(from https://svn.apache.org/repos/asf/subversion/trunk/CHANGES)
See the issue details here:
http://subversion.tigris.org/issues/show_bug.cgi?id=3640
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.
> 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.
Yes, support for moves is still lacking for some important use cases.
But work is being done to improve the situation in future releases.
However, I am not convinced that you are seeing a real problem.
It does not sound like you ran into an unsupported use case.
It sounds more like your developers don't understand how to merge
from branches which have been renamed.
I am not entirely sure what your situation was really like (your
description is lacking some details), but let me try to explain
with a made-up example. If this example doesn't fit your situation,
please let me know what the differences are so we can walk through
an example which matches your problem.
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 '.':
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.