Should I merge from the same branch or from a merge?

Question

Kind of a best practices question: is it better to merge directly from the source to other branches or is it OK to merge from a merge?

Using Subversion for source control.

Scenario:

• Branch A has changes made and committed.
• Branch B and the Trunk both need updates.

Case 1
Merge from A to B and again from A to Trunk.

or

Case 2
Merge from A to B and then merge from B to Trunk.

I may also be missing a Case 3 where you merge to B and Trunk Simultaneously (not sure if that is dependent on the source control being used?).

Note that there could be any number of branches that need merging to, such that you could "cascade" the merge (A to B to C to D...).

Answer 1

As a preface, I strongly recommend reading Advanced SCM Branching Strategies by Stephen Vance. Much of this answer is based upon the model set up in that paper.

A key feature to branching and merging correctly in a version control system is keeping the roles of the branches consistent and separate. Do not let your maintenance merge into your mainline, nor your feature flow into the maintenance.

The basic roles of branches are mainline, development, maintenance, accumulation, and packaging. While sometimes these can be combined (for example, the simple 'everything in trunk one developer setup'), when working in groups and more complex environments, a clear separation of roles is often needed.

You've got two feature branches... A and B. Each feature branch should be branched from the mainline. Likewise, each bug fix should be branched from the mainline.

The main programming (reason for the branch) isn't done, but a bug fix needs to be copied across multiple branches and trunk

In this case, feature branch A also contains a bug fix, and part of branch A needs to get merged through the system.

The best practice would have been to branch from mainline, do the maintenance (bug fix) and merge that into the mainline, and then pick up the changes from mainline into the various branches that need it as necessary.

I'm going to assume that the mainline as a policy of "only working code." One shouldn't break the build from the mainline. Likewise, non-working code in mainline means that any branches from that point start out broken.

To resolve what is the case here, the best approach would be to create another branch - an accumulation branch. This keeps any branches done from mainline while the verification of the bug fix in the accumulation branch from being broken. To do this:

1. branch mainline to an accumulation branch
2. merge the bug fix from branch A into the accumulation branch
3. merge the accumulation branch back into main
4. propagate the fixes in mainline back to the other branches

The key for a separate branch is to in effect make a maintenance branch that only contains the bug fix, and go from there. This lets you make sure that the branch is done correctly without breaking the mainline and make any additional tweaks for making sure that the bug fix doesn't break anything else.

Answer 2

I think it all depends on how the branches are structured.

1. Branch A and branch B are independent

branch A      +---------+-------------
             /           \ merge 1
trunk ------+--+----------+--+--------
                \             \ merge 2
branch B         +-------------+------

As you can see here, I would merge from branch A to trunk, then merge from trunk to branch B.

2. Branch A is a branch of branch B

trunk ------+------------------+-----
             \                / merge 2
branch B      +--+--------+--+-------
                  \      / merge 1
branch A           +----+------------

In this case, I would merge from branch A to branch B, then merge branch B to trunk.

3. Branch B is a branch of branch A

trunk ------+------------------+-----
             \                / merge 2
branch A      +--+--------+--+-------
                  \        \ merge 1
branch B           +--------+--------

In this final case, I would merge from branch A to branch B, then merge branch A to trunk. Note: order doesn't matter for this case, a merge from branch A to trunk then branch A to branch B would have the same effect.

---

I guess the key to my thinking is always merge up to parent or merge down to child and avoid merging unrelated or indirect ancestral/descendent branches.