subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael T <>
Subject RE: Subtree mergeinfo
Date Wed, 19 Sep 2012 15:55:27 GMT

Stefan Sperling <stsp <at>> 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:
> 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?



View raw message