RE: Merge strategies?

> 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
Received on 2011-10-20 15:55:57 CEST