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

differencing/comparison, and even 'rollback' his workspace if necessary).

Ready-to-commit: Finally, Fred will be ready to perform a Task-Level Commit to checkin 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 checkin 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.

Phase 2 - Commit : This is the actual committing (atomic checkin) of all modified files to the codeline. The Task-Level Commit operation commences when the first file in the change-set is about to be checked-in to the codeline; it successfully completes after the last file in the change-set has been checked-in to the codeline.

As we noted above however, it is still possible that another developer may commit their changes during the time that Fred was performing his commit-preparation activities. A Task-Level Commit ensures that all files modified for a change-task are committed together all at once as a single operation - it does not prevent a change from being committed while others are committing or preparing to commit their changes.

Concurrent Codeline Commit Contention

This is what happens when more than one developer wishes to merge their changes to the codeline during the same period of time. The "window of opportunity" doesn't just refer to the time when the actual codeline "commit" operation starts and ends. It refers to the period of time in between when a developer first knows their changes are good/stable enough to commit to the codeline (and is about to begin commit-preparation activities), up until the time they finish merging those changes to the codeline.

Suppose our 'Fantastic Fred' has finished making all his changes and has successfully committed them to the codeline. We neglected to mention Fred's other teammates: Barney and Betty. Both Barney and Betty have also been busy with their own change-tasks. When Fred finished committing his changes, they both tried to be next to commit their changes. Both tried to execute their commit-preparation activities as quickly as possible. Betty beat Barney and committed her changes first!

So now poor Barney needs to keep re-checking and re-updating his workspace because the codeline he is trying to commit to is a moving target. Barney hates trying to hit a moving target and wants to devise some tactics to prevent this situation. He has two ideas about how to do this:

1. Perhaps some rule or 'locking' mechanism can help ensure that both phases of the codeline-commit process are treated as part of a single atomic transaction.
2. Or maybe Barney just needs to find a way to decrease the amount of time consumed by his commit-preparation activities.

Barney feels inclined to investigate both of these alternatives. He decides