> 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
Received on 2011-10-20 23:56:45 CEST