> On 20.10.2011 17:55, Bob Archer wrote: > >> On 19.10.2011 14:00, Stefan Sperling wrote: > >>> On Wed, Oct 19, 2011 at 12:22:05PM +0400, Andrey Paramonov wrote: > >>>> What about my other fears, bloated svn:mergeinfo > >>> > >>> The entire svn:mergeinfo property is stored in RAM and parsed from > >>> string form into a data structure (nested hash table) before it is used. > >>> With modern hardware, you'd have to hit svn:mergeinfo sizes that go > >>> into hundreds of megabytes before you'll notice any slowdown. > >>> > >> > >> Hm, but this parsing occurs on every invocation of "svn.exe", or I'm > >> missing something? > >> > >>>> and svn:mergeinfo conflicts? > >>> > >>> Have you ever seen a mergeinfo conflict? I haven't. > >>> > >> > >> I haven't, too, because everyone uses --ignore-ancestry here ;-) > > > > We've moved away from using trunk to simplify our merging and eliminate > cyclic merges. > > > > We have something like: > > > > Project > > /Version1 > > /Version2 > > /Branches > > /Feature1 > > /Feature2 > > /Tags > > /Release1 > > /Release2 > > > > We release from the VersionX path. When we start on a new release a new > VersionX path is created by copying (branching) from the previous version. > Feature branches are created from a VersionX path then reintegrated when > the features is complete. We only use feature branches for stuff that will > take more than on sprint. > > > > The above has really helped the organization of our build server since we > don't have to constantly wonder what version is in progress on trunk. > > > > If we fix an issue in a specific version those changes are merged up into > each version as needed. We generally don't deal with more than 3 versions > at a time so the "up merging" is rarely need beyond 2 merges. > > > > It's not perfect but it works much better for us than stable trunk, branch > > for > release was working. And all the devs easily understand what it is what path > when they browse the repo. > > > > BOb > > Thank you for your answer. A couple of questions: > > 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 version 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
