Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: local policy)
From: Bob Archer <Bob.Archer@amsi.com>
To: Andrey Paramonov <paramon@acdlabs.ru>
CC: Johan Corveleyn <jcorvel@gmail.com>, Daniel Shahaf
	<d.s@daniel.shahaf.name>, "users@subversion.apache.org"
	<users@subversion.apache.org>
Date: Fri, 21 Oct 2011 09:32:12 -0400
Subject: RE: Merge strategies?
Thread-Topic: Merge strategies?
Thread-Index: AcyPuftzlQkibTubRnmGzo/9fKZ8DAAOmDFA
Message-ID: <CB4587DA62024B40B9F929ECF639210F32C24D2219@USALWEXMB4.infor.com>
References: <4E9D2D75.6070507@acdlabs.ru>
 <20111018160528.GA16629@daniel3.local> <4E9E705E.9000106@acdlabs.ru>
 <CAB84uBVZiRYC0prxRZqt7PJ6puBCedegzbU-jKxqxuNxyWr97w@mail.gmail.com>
 <4E9E88AD.8030301@acdlabs.ru> <20111019100034.GC18377@ted.stsp.name>
 <4E9EA2BF.4000104@acdlabs.ru>
 <CB4587DA62024B40B9F929ECF639210F32C24D1FF0@USALWEXMB4.infor.com>
 <4EA02D18.4020300@acdlabs.ru>
 <CB4587DA62024B40B9F929ECF639210F32C24D219A@USALWEXMB4.infor.com>
 <4EA10FE4.80102@acdlabs.ru>
In-Reply-To: <4EA10FE4.80102@acdlabs.ru>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

> On 21.10.2011 1:56, Bob Archer wrote:
> >> 1) Do you usually merge upstream or downstream?
> >> 2) Do you set mergeinfo when merging downstream?
> >> 3) Do you set mergeinfo when merging upstream?
> >> 4) Do you set mergeinfo when merging from feature branch?
> >>
> >
> > 1) We generally only merge up version. A fix is made in the earliest ve=
rsion
> path where we are going to release it and then merged up to the newer
> versions. There may be a case where we made a change in a version and
> needed it in the old version. I'm not sure that happened yet. I assume if=
 it is
> ever don I would do a record-only merge of the rev in the next version's =
path
> so it won't conflict in future merges.
> >
> > 2, 3 and 4) We always use mergeinfo. (svn sets it automatically)
> >
> > BOb
>=20
> Hm, it looks like you should have really huge svn:mergeinfo in your lates=
t
> VersionX. Did you notice any slowdown?

I'm not sure I would call it huge. Here is the mergeinfo on our newest in d=
ev  version path root:

/Product/branches/B_01490:39129-39612
/Product/branches/v6.0.0.1:3913-4250
/Product/branches/v6.0.1-BOD:29569-30097
/Product/branches/v6.5.1 B-06016 and B-06017:38413-38505
/Product/branches/v6.5.2:39097-39128
/Product/trunk:39633-40031
/Product/v6.5.1:40032-42329
/Product/v6.5.2:40827-45486
/Product/v6.5.3:42165-45488
/Product/v6.5.4:44500-46506
/Product/v7.0.1:45519-46535
/Product/v7.0.2:46560-47506
/Product/v7.1.0:47440-48031

(of course product isn't actually the product name)

Keep in mind... whenever you merge the merge info is updated. The high numb=
er of the range is changed rather than a new line being added. So each merg=
e line there from say 7.1.0 represents multiple merges (I think three at th=
is point). This also includes some merge info from back when we still used =
trunk and release branches. As you see we do very few feature branches.

No, I don't notice any slowdown.

> Also, as you usually merge upstream, I presume you could encounter
> svn:mergeinfo conflict when 2 users merge i.e. into latest VersionX
> simultaneously. Has it ever happened to you?

No, we have a weekly task to merge and usually one person does it. However,=
 I don't see how there could be a conflict since it would be caught as a co=
nflict at commit time if two people tried to commit the same merge.


>  From what I read, I see you use mergeinfo to prevent accidental cyclic
> merges. Do you use it for something else? So far I don't understand how t=
he
> mergeinfo about upstream merges could be really useful.

No, our merge policy is to prevent cyclic merges not the mergeinfo. The mer=
geinfo is used for exactly what it is meant for. To keep track of previous =
merges so they won't be duplicated. Prior to merginfo (was it added in 1.5 =
I guess?) we had to record that info in our commit message and find it when=
 the next merge was done. Now svn does that record keeping for us.


> Thank you for your valuable comments,
> Andrey Paramonov

Hope it helps,
BOb