Stefan Sperling <stsp <at> elego.de> writes:
> On Wed, Sep 19, 2012 at 01:12:50PM +0000, Michael T wrote:
[...]
> > 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?)
>
> 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.
Stefan, thanks for your reply. Would a clean-up like I described (gathering
changesets from all mergeinfo from all subtrees within a branch and setting it
all on the branch root) be even theoretically correct then, or am I being
misled by my incomplete understanding of mergeinfo? And would the 71874-75960
range I mentioned pose a problem for automatic elision, or is it clever enough
to deal with that?
Regards,
Michael
