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

implements this, Betty mentions something to him: 'Since we're all sitting within earshot of each other, why not simply make a verbal announcement when we commit a change!'

This is even simpler than the solution Barney just implemented! Barney decides to stick with his implementation anyway. He thinks to himself: 'It's still convenient to see the list of files committed; and occasionally some team-members work from home or from a remote office location.'

Private Checkpoint : Before he updates his workspace, Barney would like to make a snapshot of the current state of his workspace to use as a basis for comparison and 'rollback' of the to-be-updated file versions. He considers three possible methods for implementing Private Versions in order to create a Private Checkpoint :

Private Archive : He could simply create a 'checkpoints' subdirectory in his private workspace. Whenever he needs to checkpoint his changes, he can copy the files he wants to checkpoint. He could use the 'query' flag of his tool's update command to obtain the list of to-be-updated files and automatically copy them, along with the files he has changed, to a named/numbered subdirectory in his private archive.

As simple and clever as the private archive seems, Barney can't help feeling that it 'reinvents the wheel' to do versioning capabilities outside of the version-control tool when the tool itself already knows how to do this (and exists for this very purpose). Plus, the codebase will have no record of the private versions he created: if any 'accidents' happen in his private workspace, or if he wants to compare against checkpointed private versions for historical purposes (after his task is complete), his checkpointed changes will be lost or unavailable for use.

Private Branch : He could create a branch upon which to do his development work: He can checkout files to his Private Branch , and when he wants to checkpoint his changes, he can checkin to his branch. The resulting versions will be written to his branch instead of the codeline, thus making the versions 'private.' When he is ready, the Task-Level Commit will checkin the Private Versions to the codeline.

This approach has the advantage of using the version-control tool to do the private versioning. Though the versions on the Private Branch aren't in the codeline, they are in the codebase. Using this branch does not increase the amount of time between when his files are checked-out from the codeline and then committed back into the codeline; what it does is provide a 'safe haven' for him to create intermediate versions that are useful to him, but which would otherwise break the codeline if checked-in before his change was 'safe' to commit.

Task Branch : This approach is essentially a special case of a Private Branch . Whereas a Private Branch may continue to be used for successive development change-tasks, a Task Branch is used only for the duration of a single development task (and is typically 'locked' against further changes once the task is completed). In addition to providing Private Versions , the Task Branch also serves as a Change Package that bundles together all the versions and modifications for a particular change-task.

Barney thinks this is 'nifty' but he doesn't require the additional 'change packaging' capability. (Several version-control tools already provide their own mechanism for this.) In his case, he doesn't feel the additional overhead of creating a new branch for every task 'buys him' anything new that he doesn't already get with a single Private Branch instead of multiple Task Branches .

Some of you reading this may have noticed an