RE: Merge strategies?
From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Fri, 21 Oct 2011 09:32:12 -0400
> On 21.10.2011 1:56, Bob Archer wrote:
I'm not sure I would call it huge. Here is the mergeinfo on our newest in dev version path root:
/Product/branches/B_01490:39129-39612
(of course product isn't actually the product name)
Keep in mind... whenever you merge the merge info is updated. The high number of the range is changed rather than a new line being added. So each merge line there from say 7.1.0 represents multiple merges (I think three at this 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
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 conflict 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
No, our merge policy is to prevent cyclic merges not the mergeinfo. The mergeinfo 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,
Hope it helps,
|
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.