> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: Wednesday, September 19, 2012 6:26 AM
> To: Michael T
> Cc: users_at_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
Received on 2012-09-19 18:44:11 CEST