> On 21.10.2011 17:32, Bob Archer wrote: > >> Hm, it looks like you should have really huge svn:mergeinfo in your > >> latest VersionX. Did you notice any slowdown? > > > > 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 > > /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 > 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 > >> 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 conflict at commit time if two people tried to commit the same merge. > > Yes, I'd like to avoid this "conflict at commit time". Such things tend to > confuse users big time.
This strikes me as a training issue. Even on an update there is a possibility that a merge conflict will occur. Your users need to understand them and know how to deal with them for them to effectively use the system. BOb > > >> 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 the mergeinfo about upstream merges could be really > useful. > > > > 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. > > > > Ah, I now see that you basically merge everything, not cherry-pick. It makes > sense for your setup. I now see that we could also do this (in rather rare > cases when we merge upstream) if we have mergeinfo filled for our release > branches. > > Thank you for sharing your experience, > Andrey Paramonov
