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

too (and also more frequent).

Codeline Locking Strategies

After seeing what great success Barney had improving the commit-preparation 'cycle time', Betty decided to try her hand at improving the safety and reliability of the Two-Phased Codeline-Commit protocol. This implied implementing or enforcing some kind of formal or informal codeline-locking strategy. The first thing she did was investigate how to make sure that the whole team follows the protocol:

Pre-Commit Validation : Before anyone attempts to commit, a query is made to see if Betty's workspace is already up-to-date with the latest state of the codeline. If it isn't, then the commit either fails, or else her workspace is automatically updated. The validation might also automatically rebuild/retest to check for any failures before allowing the commit to proceed (in which case the validation step essentially performs all the commit-preparation activities). Many version-control tools provide event-based validation 'hooks' out-of-the-box to script this (otherwise a commit-wrapper script may be used).

A Pre-Commit Validation can also initiate a locking protocol of some kind either before or after the commit-preparation activities.

Betty decides to implement Pre-Commit Validation so that it checks for and performs a Workspace Update (if needed) and initiates a locking protocol. She conducts her own research and found that the following Codeline Locking mechanisms commonly recurred in practice (listed in order of increasing formality and complexity):

Single Release Point : There is a single dedicated codeline integration work-area with a single monitor and keyboard (e.g., an integration machine/workspace). This lone integration resource is time-shared (used for only one person and change at a time), thereby ensuring commits are serialized.

Integration Token : Developers might be allowed to integrate their changes from any machine or workspace, but must first obtain a "token" to do so (and only one such token is available). The token might simply be a purely symbolic or physical artifact (e.g., a coin, a key, a rubber chicken or a purple barney-doll), or even something as informal as a verbal "catch phrase" like: "I've got the integration token!" being yelled out to the rest of the team. Or it might be as formal as implementing an exclusive lock on a specific file or object outside the codebase.

Codeline Write-Lock : Formally "lock" all or part of the codeline by having the version control tool prevent checkin to the codeline by anyone but the lock-holder (the person who "acquired" the codeline-lock for exclusive write-access). The lock-holder automatically relinquishes the lock after they are done committing their changes. They may also voluntarily release the lock anytime before then if they feel they need more time to reconcile any conflicts or failures since their last update.

Any implementation of a Codeline Write-Lock should include a mechanism for querying the lock to see who holds it, and a 'backdoor' mechanism for a codeline 'owner' or 'administrator' to release the lock in urgent circumstances. Sometimes an automatic or default 'timeout' is used to ensure the lock is never held for more than a predetermined maximum period of time.

A Codeline Write-Lock is typically implemented in one of two ways:

Full Codeline-Lock prevents the entire codeline (all files) from being written (checked-in) by anyone but the lock-holder. It is often implemented via a pre-checkout 'trigger' or 'hook' that looks for a 'locked' attribute/property that is somehow associated with the codeline.

Partial Codeline-Lock prevents codeline-checkin for only those files that are checked-out (were modified) by the lock-holder. This allows concurrent committing of non-overlapping changes at the expense of increasing the risk of an undetected conflict between change-tasks that had no files in common.

The implementation typically uses