> On 9/23/2010 4:53 PM, Piers Haken wrote: > > The problem is that we have concurrent work going on in all the different > branches, and those changes need to be merged freely between the > branches. > > Yes, but a lot of work can be done by implementing the change on the trunk, > then merging to any active branches that need it. You are still > cherry-picking, > but it makes sense to cherry pick when going that direction.
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 > direction to me. 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 > changes periodically instead of merging anything there? Do you have to > support a lot of different concurrent qa tracks? 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, > but I guess I'll have to wait... > > It's a lot simpler if you can just drive things one direction (trunk > ->qa branch->release branch). Certainly, in a perfect world we'd never need to re-integrate bug fixes...