[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

SVN Merge Tracking Issues

From: <Michael.Rumpf_at_t-systems.com>
Date: Mon, 31 Oct 2011 09:59:32 +0100

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
Received on 2011-10-31 13:09:02 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.