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

RE: Subtree mergeinfo

From: Michael T <raselmsh_at_hotmail.com>
Date: Wed, 19 Sep 2012 17:55:27 +0200

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:
> 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?



Received on 2012-09-19 18:14:43 CEST

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.