> -----Original Message----- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Wednesday, September 19, 2012 6:26 AM > To: Michael T > Cc: users@subversion.apache.org > Subject: Re: Subtree mergeinfo > > On Wed, Sep 19, 2012 at 01:12:50PM +0000, Michael T wrote: > > Hello, > > > > I am aware that this is a much asked question, but since I have > > nonetheless been unable to find an answer which quite works for me I > > will ask it again. Feel free to point me to a FAQ I have missed by > way of answer if appropriate! > > > > We have a large project with multiple branches versioned with > > Subversion (most of us are using 1.6 clients at the moment). There is > > a lot of merging done between branches, and it has happened on > > numerous occasions that merging has been done to branch (or trunk) > > subtrees which should have been done to the branch root - in fact, no > > merge should ever have gone to a subtree. The obvious result is > > unwanted mergeinfo changes blossoming through the tree (though even > > that is not quite consistent, as people sometimes do not commit > > mergeinfo changes on subtrees, and I am sure that a few have been > > omitted which perhaps should not have been). I have been looking for > > a way to clean things up - basically, to determine for a given branch > > all changesets which have been merged to it, to set that information > > on the branch root and remove (or let Subversion > > elide) the information on the subtrees. So far I haven't found a good > > solution, and in particular I have been defeated by things like > > finding 71874-75960 in the mergeinfo because only change 71874, 75960 > > and a few in-between applied to a particular subtree. (Would > > Subversion 1.6 even handle elision correctly here?) > > > > I would be very grateful for suggestions about how to clean this up as > > automatically as possible if this is even feasible! > > > > Many thanks, > > > > Michael > > > > By the way, I am not subscribed to this list, but I will monitor it > > for a few weeks for responses. > > Save yourself the hassle of "cleaning up" mergeinfo. You're likely to > make things worse unless you're 100% sure how Subversion's internal > merge-tracking calculations work (in which case you probably would not > be asking your question in the first place :) > > The easiest thing to do is to just leave the mergeinfo alone and upgrade > all clients to 1.7. This will get rid of superfluous mergeinfo > modifications during merges. See here for more information: > http://subversion.apache.org/docs/release-notes/1.7.html#subtree- > mergeinfo-recording > > Mergeinfo elision is still very basic, even in 1.7. Mergeinfo will only > ever elide if the revision ranges merged to parent and child match > exactly, such that the only difference between the svn:mergeinfo > properties are path differences that disappear when paths in the child's > mergeinfo are adjusted relative to the parent.
Good advice. Get users on 1.7 clients! For the cases where a sub-tree was merged, a relatively safe thing to do is to run the same (branches/revs) merges into the root of your trunk. Assuming the sub-trees already picked up the real content changes, these additional merge changes should just be updating the root-level meta-data, and if you get all such branches, then the merge-info will elide from the sub-tree. Let the merge command do the dirty work, rather than edit merge-info! -Steve
