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

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

About the author

Steve Berczuk's picture Steve Berczuk

Steve Berczuk is a Principal Engineer and Scrum Master at Fitbit. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a certified, practicing ScrumMaster. Contact Steve at steve@berczuk.com or visit berczuk.com and follow his blog at blog.berczuk.com.

About the author

Steve Konieczka's picture Steve Konieczka

Steve Konieczka is President and Chief Operating Officer of SCM Labs, a leading Software Configuration Management solutions provider. An IT consultant for fourteen years, Steve understands the challenges IT organizations face in change management. He has helped shape companies’ methodologies for creating and implementing effective SCM solutions for local and national clients. Steve is a member of Young Entrepreneurs Organization and serves on the board of the Association for Configuration and Data Management (ACDM). He holds a Bachelor of Science in Computer Information Systems from Colorado State University. You can reach Steve at steve@scmlabs.com.

AgileConnection 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!