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

to first see what he can do about going faster before looking into ways of slowing others down (e.g., locking).

Conquering Codeline Commit Contention

So what can Barney do to go faster and minimize the time spent doing commit-preparation? What are the major contenders for the main bottlenecks in the commit-preparation process? They seem to be the following:

• Time spent merging and reconciling any conflicts as a result of doing a Workspace Update

• Time spent doing the Private System Build to rebuild/retest changes after the Workspace Update

Barney talks with his local build-gurus and testing gurus to see what can be done about improving build-time and testing time. They do what they can to help him automate as much as possible of the build & test activities. He also consults some IT hardware/network experts and build-file gurus to see if any hardware or software can be thrown at the problem to make builds go faster, and has the build scripts optimized.

Barney also considers using an incremental build (instead of a full build) in most Private System Builds . This could reduce rebuild times considerably, at the expense of decreasing the thoroughness of build-feedback. To compensate, full builds could be automated to occur at least daily (or more frequently).

Barney's efforts thus far have helped not only Barney - they helped the entire team too! (Thanks Barney!) Unfortunately for Barney, this also helped make Betty go faster too and she still beats Barney to the punch.

So Barney decides that if he can reduce the likelihood that his workspace's Repository View becomes 'stale' (out-of-date with the codeline), that will 'nip the problem in the bud': if his workspace is already 'fresh' with the latest changes from the codeline, then the Workspace Update he performs at the beginning of commit-preparation will simply be a 'sanity check' and will have no effect because most of the time he is already up-to-date.

If there are no new codeline changes to update his workspace, then not only does he avoid having to spend his time merging, he also avoids having to spend time rebuilding and retesting the updated workspace.

Continuous Workspace Update

Barney decides to do everything in his power to keep his workspace up-to-date as often as possible. He will update his workspace 'continuously:' immediately after anyone commits a change to the codeline, Barney will update his workspace. At least that's the theory. In reality, Barney sometimes needs a few extra minutes to finish what he was in the middle of before updating his workspace.

As he starts adopting this habit, Barney finds it would be exceedingly convenient to know whenever a new change is committed to the codeline, and to be able to checkpoint his changes before updating his workspace (for the sake of posterity, and his own posterior):

Post-Commit Notification : Barney needs some kind of indicator or notification whenever a new change is committed to the codeline. Otherwise he would need to continually poll for this information. He also would like to see which files were modified by the newly committed change (either as part of the commit notice, or as part of some codeline 'commit-query' mechanism).

Many version-control tools provide event-based notifications out-of-the-box. Unfortunately for Barney, his tool isn't one of them. But this is easy to implement with a simple 'commit-wrapper' script, or using a post-commit 'hook' (or ''trigger') that executes the script he specifies. So Barney implements a simple subscription mechanism that tracks a list of email addresses to notify for commits to the codeline. (Barney subscribes himself using his 'Instant Messaging' email address.)

Right after Barney