I have two feature branches: featureA and featureB.
FeatureA is complete, but not merged into trunk because it's untested and we're not ready to test it yet.
I'm working on featureB, and have realised that a change implemented in featureA is required for me to continue.
What's the best approach? I think I have a couple of options:
Option 1
Merge featureA to featureB branch (or maybe just specific revisions if I'm careful to get all the ones I want), then revert all but the changes I need.
Option 2
Re-implement the changes in featureB (they're not too complex this time) and sort out the conflicts when featureA and featureB are merged into the same place.
Either way, the features will be merged into a release candidate branch ready for testing and deployment. Once that RC branch is confirmed as tested, it'll be merged into trunk in one go.
There's a third option:
You can cherry-pick what you want to merge, and merge just that. Perform a merge from featureA to featureB, but only merge the revisions that you are interested in. Then optionally fix any remaining problems.
In Eclipse e.g. this can be done quite conveniently, because the merge dialog will let you select which revision (or which range) you want to merge. Just repeat that for all the revision ranges you need.
I tackle these kinds of problems by having the following structure in svn:
/prod
/release_20090801
/release_20090901
/staging
/trunk
/sandbox
Developers develop in their sandbox and then merge into trunk as features are added. Once a iteration's features are airly complete and ready for final QA, trunk is copied to staging.
So in your scenario, Feature A could be merged to trunk, then copied to sandbox for feature b development.
Well, if the two features don't involve changes to the same source files, the easiest way to keep them separate while continuing development would be to create a mixed working copy. Check out featureB, and just switch individual source files to featureA as necessary. (Look up svn switch if you need more info.) You could continue to make changes in featureB and check them in without actually merging any of the featureA code. (This would allow for local development, but would break the build on the server if you're using continuous integration because the necessary featureA change wouldn't be present.)
Of course, if B depends on A, that means A will eventually need to be tested and ready for release before B can be completed. To me, that means you should merge featureA changes into featureB now and start dev on featureB. You'll just need to make sure that as any fixes are applied to featureA that they're merged into featureB.
