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.
For example, when a bug is fixed in the release branch, we need the change to be propagated back to the various QA and dev branches. The only way to do this is to cherry-pick those changes, otherwise SVN will attempt to merge the previous forward-merges back into those branches. Heaven forbid you have some renames in there! It gets more complicated when you have changes going in two directions sometimes it seems like SVN wants to apply the same change twice to the same tree. As far as I can tell this is all expected behavior.
Fixing something in release, then propagating to qa seems like the wrong direction to me.
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?
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).
-- Les Mikesell lesmikes...@gmail.com
