Subversion: Merging subtrees vs. merge-tracking

Question

Brought forward from Subversion feature branch requires changes from another feature branch

I have two feature branches: "FeatureA" and "FeatureB". FeatureA is complete, but not merged to trunk because it's not been confirmed whether it should go in the next release or not.

FeatureB is in progress, and it turns out requires some changes to dbml that have actually been applied to FeatureA.

I have a few options, one of which is to merge only the dbml and associated files. I am aware that it is best practice to merge/update/commit etc from the working copy root, but what problems could it cause if I was to go ahead?

Answer 1

You can merge all the revisions from FeatureB to FeatureA branch that you want (good idea to note the merged revisions as subversion would not do that for you -- svnmerge.py tool does that, but I'd rather keep a record myself). Then undo/remove the changes that you don't want (such as, as you remarked in the earlier question, are part of revisions).

I wanted to say this: "Later, during the merge of FeatureA and FeatureB with trunk, there should would not be conflicts if the changes that you undid were independent of the other changes in the FeatureB branch." But I am not sure whether this is true. That is, is there a conflict/double change if there is a common change in FeatureA and FeatureB, when these changes are merged into trunk?

A workaround is to take a safe approach and do the difficult accounting yourself, so that any change is not repeated at all when later merge is performed on trunk.

One way to simplify is to use a flag in the code to turn on or off FeatureA. That way, FeatureA can already be merged with trunk.