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

[article]
Summary:
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

Fred has been working on an enhancement to add 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

  • 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.
  • 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.
  • 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 and 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 differencing/comparison, and even rollback his workspace if necessary).
  • Ready-to-commit:  Finally, Fred will be ready to perform a task-level commit to check in his changes to the codeline (which hopefully no one else has attempted while Fred was going through all of this commit-preparation work). The task-level commit ensures that the set of changes (change-set) for a change-task are checked-in to the codeline as a single atomic transaction: either the check in succeeds for all of the files in the change-set, or it succeeds for none of them.

Two-Phased Codeline-Commit

It is no coincidence that the above appears similar to the two-phased commit protocol used by databases to ensure the ACID properties for a database transaction (ACID is an acronym for atomicity-consistency-isolation-durability). Many version control tools employ 'transaction-based CM' mechanisms [5]. The standard Two-Phase Commit protocol consists of:

Phase 1 - Preparation

For Fred, this is what he was doing in order to ensure his workspace was up-to-date and working properly with the latest state of the codeline. He started with a Workspace-Update (which perhaps really should have been preceded by a Private Checkpoint) to synchronize with the codeline, then followed-up with a Private System Build to make sure it still worked properly.

Pages

About the author

About the author

About the author

CMCrossroads is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!