RE: Why is --reintegrate neccessary?
From: Piers Haken <Piers.Haken_at_4delite.com>
Date: Thu, 23 Sep 2010 15:45:12 -0700
> On 9/23/2010 4:53 PM, Piers Haken wrote:
I'm not sure why cherry-picking is necessary here (apart from technical reasons). We always want all the changes not already in branch B to go back into trunk.
> Fixing something in release, then propagating to qa seems like the wrong
Well, our 'release' branch is really a QA branch, it's just the one that most closely reflects the currently released code. Fixes to go live immediately are checked into release, QA'd and pushed. Those fixes need to make it back into the dev branches and eventually back through QA into release. It's that loop that causes the most pain.
> Why not just cut new qa branches from the trunk with all the current
The problem is that making new branches is expensive in terms of time spent re-configuring development environments, build machines, etc... In fact, the time saved NOT doing this multiplied by the machines affected would pay for Perforce - we push several times a month. It's much cheaper for us to have one guy merge the changes through a (mostly) static set of branches and have those changes appear in everyone's trees without requiring any reconfiguration.
> > I'd like to use a free, centralized vcs that can handle merge tracking well,
Certainly, in a perfect world we'd never need to re-integrate bug fixes...
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.