On Mon, Oct 31, 2011 at 09:59:32AM +0100, Michael.Rumpf_at_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_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.
Received on 2011-10-31 14:39:29 CET