Return-Path: 
 <users-return-16236-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org>
X-Original-To: apmail-subversion-users-archive@minotaur.apache.org
Delivered-To: apmail-subversion-users-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id EAA86D11C
	for <apmail-subversion-users-archive@minotaur.apache.org>;
 Wed, 19 Sep 2012 16:14:37 +0000 (UTC)
Received: (qmail 68069 invoked by uid 500); 19 Sep 2012 16:14:37 -0000
Delivered-To: apmail-subversion-users-archive@subversion.apache.org
Received: (qmail 68023 invoked by uid 500); 19 Sep 2012 16:14:37 -0000
Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@subversion.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@subversion.apache.org>
List-Post: <mailto:users@subversion.apache.org>
List-Id: <users.subversion.apache.org>
Delivered-To: mailing list users@subversion.apache.org
Delivered-To: moderator for users@subversion.apache.org
Received: (qmail 10803 invoked by uid 99); 19 Sep 2012 15:55:56 -0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of raselmsh@hotmail.com designates
 65.54.190.153 as permitted sender)
Message-ID: <BAY171-W22EF9B34E200116926BCD8D09B0@phx.gbl>
X-Originating-IP: [84.130.181.251]
From: Michael T <raselmsh@hotmail.com>
To: <stsp@elego.de>
CC: <users@subversion.apache.org>
Subject: RE: Subtree mergeinfo
Date: Wed, 19 Sep 2012 17:55:27 +0200
Importance: Normal
In-Reply-To: <20120919132554.GH16430@ted.stsp.name>
References: 
 <loom.20120919T150111-47@post.gmane.org>,<20120919132554.GH16430@ted.stsp.name>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Sep 2012 15:55:26.0863 (UTC)
 FILETIME=[2FAF19F0:01CD967F]


Stefan Sperling <stsp <at> elego.de> writes:
> On Wed=2C Sep 19=2C 2012 at 01:12:50PM +0000=2C Michael T wrote:
[...]
> > We have a large project with multiple branches versioned with Subversio=
n=20
> > (most
> > of us are using 1.6 clients at the moment).=A0 There is a lot of mergin=
g done
> > between branches=2C and it has happened on numerous occasions that merg=
ing has
> > been done to branch (or trunk) subtrees which should have been done to =
the
> > branch root - in fact=2C no merge should ever have gone to a subtree.=
=A0 The=20
> > obvious
> > result is unwanted mergeinfo changes blossoming through the tree (thoug=
h=20
> > even
> > that is not quite consistent=2C as people sometimes do not commit merge=
info
> > changes on subtrees=2C and I am sure that a few have been omitted which=
=20
> > perhaps
> > should not have been).=A0 I have been looking for a way to clean things=
 up -
> > basically=2C to determine for a given branch all changesets which have =
been=20
> > merged
> > to it=2C to set that information on the branch root and remove (or let=
=20
> > Subversion
> > elide) the information on the subtrees.=A0 So far I haven't found a goo=
d=20
> > solution=2C
> > and in particular I have been defeated by things like finding 71874-759=
60=20
> > in the
> > mergeinfo because only change 71874=2C 75960 and a few in-between appli=
ed to a
> > particular subtree.=A0 (Would Subversion 1.6 even handle elision correc=
tly=20
> > here?)
>=20
> 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 :)
>=20
> 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
>=20
> Mergeinfo elision is still very basic=2C even in 1.7. Mergeinfo will only
> ever elide if the revision ranges merged to parent and child match
> exactly=2C 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=2C thanks for your reply.=A0 Would a clean-up like I described (gath=
ering=20
changesets from all mergeinfo from all subtrees within a branch and setting=
 it
=A0all on the branch root) be even theoretically correct then=2C or am I be=
ing=20
misled by my incomplete understanding of mergeinfo?=A0 And would the 71874-=
75960=20
range I mentioned pose a problem for automatic elision=2C or is it clever e=
nough=20
to deal with that?

Regards=2C

Michael

 		 	   		  =