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

important difference between Private Archive and Private/Task Branch . The set of checkpointed files is different between the two approaches:

• As described above, using a Private Archive checkpoints all files in the Private Workspace that are to be updated by Workspace Update .

• Using a Private/Task Branch checkpoints only those files that Barney modified in his workspace on his branch. Any files that he did not modify, but which will be updated from the codeline, are not checkpointed.

This difference is often not very significant, but sometimes it can be. If it is going to be an issue in your environment, the checkpoint mechanism requires a bit more implementation effort:

Checkpoint Label : The two different file-sets can be computed (perhaps as an automatic part of the Workspace Update ) and their union can be tagged as the complete checkpoint-set. This may use the version-control tool's built-in label/tag operation, or it may simply capture the file names and their versions in another file, or in a named attribute/property associated with the workspace or branch (or even in the comment-text for the checkin).

In the end, Barney decides to supplement his practice of Continuous Workspace Update with Post-Commit Notification (implemented via a hook that emails a local mailing-list) and with Private Checkpoints (implemented via a Private Branch to enable the use of Private Versions , but without creating a Private Label ).

Using the Continuous Update pattern helped Barney drastically reduce the amount of time it takes for commit-preparation activities. It also reduced the amount of time it takes Barney to do the Workspace Update itself (since he does them incrementally, instead of all at once at the end in 'big bang' fashion).Continuous Update Complements Continuous Integration!

Now that Barney has instituted the use of Continuous Updates within his team, it seems his teammates are committing their changes faster and more frequently than before! This appears to be due to two things that he expected, and one thing that he didn't expect:

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

• Less time spent rebuilding/retesting changes after the Workspace Update

• Less time spent during the interval between when his files are checked-out from the codeline and then committed back into the codeline

That last one surprises him! Usually people are concerned that using Private Branches or Private Versions will make folks less likely to commit their changes to the codeline as frequently as they should. But Barney observed the opposite effect!

Barney thinks this is because the real problem was that folks were 'afraid to commit' before. They were sometimes wary of committing their changes earlier for fear of breaking the consistency of the codeline. Because of this, they would do more work than they really should have in a single change-task before committing their changes.

Instead of encouraging fear-laden 'bad practice,' the use of Private Versions/Branches with Continuous Update encouraged them to 'sync up' with the codeline more frequently and to checkin files when they previously wouldn't have checked-in anything at all:

Rather than preferring checkpoints to committing changes, they instead created checkpoints where they would have otherwise done nothing. More frequent merging of smaller changes within a safe, privately versioned environment made them more comfortable with merging. They were no longer 'afraid to commit' and began committing their changes with greater frequency and confidence.

The result was that change-tasks were 'right sized' to be more compact and more cohesive sets of modifications. The smaller and simpler change-tasks were integrated more frequently back into the codeline! Workspace Updates became smaller and easier