2

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...).

  • 2
    Which version control system are you using? What you can and should do would likely depend on the vcs. – Ryan Taylor Dec 30 '13 at 20:42
  • Added in the post that I'm using Subversion. – Aaron Dec 30 '13 at 21:01
  • 1
    I'll work at writing a good answer in a bit (few hours) - if someone else doesn't get one in first, in the meantime, I strongly recommend reading Advanced SCM Branching Strategies which should answer your question... and it is the best of the best practices for branching that I've found. Any answer that I give will be based strongly on its material. – user40980 Dec 30 '13 at 21:07
  • 1
    Missing case that I think makes more sense: Merge from A to Trunk, then Trunk to B (since you should be merging from Trunk to B regularly anyway, to ensure your changes don't have a massive conflict when you're done with branch B) – Izkata Dec 30 '13 at 21:24
  • 1
    @MichaelT The main programming (reason for the branch) isn't done, but a bug fix needs to be copied across multiple branches and trunk. – Aaron Dec 31 '13 at 14:46
3

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.

8

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.