Subversion: Merging subtrees vs. merge-tracking

Question

Brought forward from http://stackoverflow.com/questions/1525027/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.

Answer 2

Since version 1.6 Subversion traces a merges, thus you won't have any further problems.

Answer 3

I find it useful to remember that merges in svn are described with three parameters. You take the changes that convert rev X into rev Y, and apply those changes to rev Z. I think this conflicts with what you said about using the working copy.

So one approach would be to find the changes you made to the dbml in the Feature A branch (identified by a start revision and a finish revision), and apply those changes to the Feature B branch.

Answer 4

I think you're getting at the question of "subtree mergeinfo". The experts say this is best avoided. But performance is also an issue, as running a merge at the root of a large branch can take a long time. In order to avoid those performance issues, I have done subtree merges, and can confirm that the resulting subtree mergeinfo does cause some issues. So you should avoid it when possible.