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

a reserved (exclusive) checkout from the codeline of each file in the change-task. If any of the files cannot be checked-out than the lock attempt fails and any checked-out files must be unchecked-out.

Those are the two most commonly used approaches. Betty also noticed some less frequently used (but not uncommon) approaches that were basically some mixture of these two:

Double-Checked Codeline Locking employs a full codeline-lock solely for the duration of time necessary to obtain a partial lock. The full lock is released once the partial lock is acquired.

Phased Codeline Locking employs both full and partial codeline locking across the different phases of the two-phased commit cycle.

• First it obtains a full lock (just before the Workspace Update ), and if no updates were needed, or if there were no file collisions (and hence no merges), then the full lock is held until the codeline-commit is completed.

• If there were any collisions (or, alternatively, any conflicts) then the full codeline-lock is automatically released (or else automatically downgraded to a partial lock).

At any time during a Phased Codeline-Lock , the lock-holder may explicitly 'promote' or 'demote' the lock (from full to partial, or partial to full), or explicitly relinquish the lock altogether. This lets the lock-holder decide what they feel is the appropriate balance of 'safety' and 'productivity' for the nature of the changes and conflicts encountered.

Some version-control tools automatically provide Codeline Write-Lock capabilities, and/or allow it to be automatically configured. (For example, ClearCase UCM employs partial codeline locking for it's deliver operation). Others provide pre-commit 'hooks' or 'trigger' to let their users 'tool them up' on their own for their own projects.

Betty carefully evaluates the benefits and consequences of each of these approaches, both formal and informal:

• She feels the Double-Checked and Phased Codeline Locking approaches are 'overkill' for the needs of her small project and (mostly) co-located team. They might make more sense for a much bigger project with more people or more geographically dispersed team members where codeline contention is much higher and the codeline is very volatile.

• Betty appreciates the simplicity of the Single Release Point , but feels it is a tad too crude for her taste. She thinks it just a little 'primeval' to restrict all integration to take place in a single physical location away from where everyone normally sits. (Plus it won't work very well for the occasionally remote team-member.)

• Betty likes the simplicity and informality of the Integration Token approach and feels it might work well for her particular small team and project. If they turn out to not be disciplined enough in its use, she figures she can easily 'escalate' the formality to use a Full Codeline-Lock . And if allowing only one commit at a time ends up being too much of a bottleneck, then the Partial Codeline-Lock still seems relatively simple and straightforward enough for her needs.

After considering all of these factors, Betty opts for using an Integration Token , with Full Codeline Locking and Partial Codeline Locking as her contingency-plans if the token-based approach doesn't pan out.

Conclusion: Selecting Patterns and Strategies to Use (Its All About Context!)

Some of you may have disagreed with some of the choices made by Betty and Barney. They did what they thought was most appropriate for their project's corresponding complexity and risk-tolerance and their team's size, people, and organizational culture. You will need to do the same for yourself! And your choices may differ based upon important differences in the context of your project's team, architecture, and organization.

So how do we do that? How