[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: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 19 Sep 2012 15:25:54 +0200

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.
Received on 2012-09-19 15:26:39 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.