Codeline Merging and Locking: Continuous Updates and Two-Phased Commits

This month we will discuss the subject of merging our changes with the codeline. First we will outline the basic process to use. Next, we'll mention some of the obstacles that arise, and strategies to overcome them. We will conclude with a discussion of how to decide which strategies are right for you!

Working on a Change-Task

'Fantastic Fred' has been working on an enhancement to add the new 'Whiz bang' functionality into his team's software product. He thinks he has it all working now and feels it is ready to be integrated together with the rest of the team's changes on the codeline. To get to this point, Fred already applied the following SCM patterns [1]:

1. Fred created a Private Workspace in which to implement and test his changes. This isolates Fred's work from the team-wide codeline, and insulates the team from the effects of Fred's in-progress changes before they are working properly.

2. Once the Private Workspace was created, Fred populated the workspace with a Repository View of the latest stable state of the codeline. This gave him a 'snapshot' of the most recent working state of the codebase in which to begin making his changes.

3. Fred checked-out the files he needed to implement the functionality for his assigned development task and went through a few cycles of edit-compile-build-test before he finally seemed to have everything in working order. He performed a Private System Build to execute the requisite Unit Tests , Smoke Tests , and Regression Tests to verify that it all seemed to work.

You'll note that Fred and his team are using the classic copy-modify-merge paradigm for making their changes to the codeline (see [2], [3], and [4]): First, copy the latest state of the codeline into your private workspace; then make your changes; finally, merge the changed result back to the codeline.

Codeline Commit Preparation

At this point Fred has completed the 'copy' and 'modify' portions of his overall change-task. Now Fred thinks he is ready for the last part, the 'merge' step. This is the 'beginning of the end' of the change-task and is where things start to get interesting. Here is what Fred still needs to do before actually merging the files into the codeline:

Rebase: Ensure that the code in his private workspace is 'up to date' with the latest state of the codeline. If it isn't, Fred must perform a Workspace Update to populate his workspace with the latest versions of any new files on the codeline (also known as 'rebase' or 'rebaseline'.)

Reconcile: If there were any checkout collisions (where the same file was changed both in Fred's change-task and on the codeline) then Fred will need to merge those files into his workspace. If there were any merge conflicts (overlapping changes to the same region of code by more than one change-task) then the merge may be non-trivial.

Rebuild & Retest : If any new file versions resulted from the Workspace Update (even if they didn't need to be merged), Fred probably needs to perform another Private System Build to ensure that he didn't 'break' anything and his changes still work with the latest state of the codeline.

Resolve: If the re-build or re-test failed, then Fred must fix the problem and then restart the cycle all over again. If the problem is hard to fix, Fred may wish he'd created a Private Checkpoint to capture the state of his previously working changes immediately prior to the Workspace Update (that way he can use the checkpoint as a basis for file