> 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
Received on 2011-10-21 19:06:15 CEST