Parallel Development Strategies

A recent post in a public CM forum requested feedback regarding a certain branch and integration process. The posting was as follows:

Our process begins with a stable trunk. When getting ready for a new release we create a branch based off the trunk. This new branch becomes our integration branch/release candidate branch. Once all the integration onto this branch is completed, the final snapshot is merged back to our trunk.

Off the integration branch, we create Change Request (CR) branches - each one responsible for fixing a defect or implementing a new feature. Once a CR is completed and tested, it is merged onto the integration branch and retested if it is not the first CR to be merged back.

By not re-baselining from the integration branch (if some CR has been integrated onto the integration branch) up to a CR branch, we keep the CR branch only as a CR branch where you're able to keep track of where you started your development. The other reasoning behind this is that you don't complicate the environment you've already been working in with someone else's code.

We've had some opposition to this practice. The opposition being that some would rather re-baseline their CR branch whenever changes are available since it's got to be integrated at some point anyway.

Before addressing the main question, let's address another problem with the process described in paragraph 2, which is the merge into the integration branch. No mention is made of syncing the CR branch before merging to the integration branch. In fact, the discussion is keeping such changes out of the CR branches. However, syncing the CR branch before merging is critical. Otherwise, the integration branch will be broken or in an unknown state until the merge and testing are completed. Also, the integration branch is owned by many folks, and breaking it because you didn't sync and test it yourself, wastes the time of many users.

Back to the main question, which stated more succinctly, is whether it is better to do fewer, larger merges, or more frequent, smaller merges.

Frequent Merging

Frequent merging has several advantages. First, if you merge frequently, the merges will be small and easy to comprehend. In addition, since your own changes will still be fresh in mind, you'll be able to quickly understand and resolve any conflicts that do arise.

Frequent merging also reduces the likelihood of merge conflicts. This is true because the more current your baseline, the more likely you will build upon other completed changes rather than make your changes in parallel and thus need to merge.

By contrast, waiting until the end for a large CR results in a huge merge and significant time between making some of the changes and the merge. The result: Larger merges with more conflicts in code you haven't been into in weeks. All of which is a recipe for trouble.

Infrequent Merging

Infrequent merging allows one to focus on the CR while avoiding the distractions of what everyone else is doing. Every merge is a distraction from the CR task and has associated overhead such as the break in focus itself, the need to rebuild, the need to adjust to any changes others have made, or defects they've introduced, etc. In short, every merge makes the CR branch less stable.

Finally, frequent merging assumes adequate tool support. Nearly any version control tool can support infrequent merging, even if it isn't something you want to do very often. In contrast, it takes solid tool support to be able to reduce merge overhead to the point that frequent merging becomes a reasonable choice.

Best Practices

Assuming your environment supports low-overhead merging (as does SnapshotCM), the accepted wisdom is to merge frequently, perhaps several times per week. This is especially true if you experience significant problems with the infrequent merges. More really are simpler and less risky.

However, it also makes sense to merge at times in your work where you can verify the merge. For example, if your changes don't build or run, then merging will complicate, rather than help, the situation.

Branching and merging can be used effectively. We trust this paper has given you a greater appreciation for the issues involved in doing so in your team.

To see SnapshotCM branching and merging in operation, download a free SnapshotCM evaluation at http://www.truebluesoftware.com/.