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?
Best wishes,
Andrey Paramonov
