On 9/23/2010 5:45 PM, Piers Haken wrote:
>> 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.
Yes, but if you did the work that you want on the trunk on the trunk,
you'd expect to cherry pick into branches, since the reason you branched
is that you don't want all the subsequent trunk changes.
>> 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.
Not quite sure I understand. Shouldn't 'svn switch new_url' be all it
takes to make everything in the working copy adjust transparently? So
you just need to track the 'human-friendly' branch version names you've
used for the branch cuts instead of the svn revision numbers on a fixed
path. I am sort-of struggling to wrap hudson around this concept
though, so I can see how it affects build automation where you'd have to
supply parameters.
>>> 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...
But it's your choice of where to make the first change - which controls
the direction of the merges. And if you really only support the most
current release, you should always be able to work with fresh cuts of
the trunk into qa and production.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-09-24 01:16:06 CEST