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

Private Archive ; or when you want to be able to 'remember' more than just the most recent checkpoint for the purpose of rollback or as a basis for file differencing/merging.

Two-Phased Codeline-Commit is really an emergent pattern . Its use automatically emerges as a result of appropriate use of Workspace Update and Private System Build . These two patterns in succession (along with pre-update Private Checkpoints , other pre-commit activities) simply become a natural part of Codeline-Commit Preparation that defines the window of opportunity in which codeline commit-contention may occur.

Pre-Commit Validation should be used whenever you need to impose a more formal (and automatic) team-discipline of following the two-phased commit protocol and ensuring that 'stale' workspaces never have their changes committed to the codeline. It can also be used to ensure that tests have been run to ensure the committed change won't 'break' the codeline.

Codeline Locking of some form another (even if it's not a true/formal lock) should be used whenever codeline-commit contention is a legitimate issue, or if there is good reason to believe that it will be an issue. To determine this will require examining the following factors:

• Team size: The larger and/or more geographically dispersed the team, the more rigor and formality is required to keep integration coordinated

• Build/Test time: The longer it takes to build and test, the greater the likelihood of commit contention

• Parallel tasks: The greater the number of parallel tasks, the greater the likelihood of commit contention

• Likelihood and cost of non-collision conflict (when two independent changes don't touch the same files but cause a build failure when checked-in together)

• Contention time-window: The typical expected time-span (duration) for performing Codeline-Commit Preparation and Task-Level Commit activities

• Completion overlap: The likelihood of multiple tasks being completed within the contention-time-window ( especially near the end of an iteration or a release)

Another driving factor becomes minimizing the duration of the contention time-window. This can be accomplished by automating tests, and by utilizing incremental builds to a large extent. Then frequent (continuous) workspace updates reduce the likelihood of the workspace being out-of-sync with the codeline.

If you decide locking is called for, then the locking strategy should ideally be part of the Codeline Policy . When determining the right locking strategy for your project, the heart of the issue is the level of formality of the locking. Ask yourself: Is it merely by social convention? Is it a little bit stronger than that (like a "token")? Does it need to be more formally enforced and communicated?

If you decide to use an informal locking strategy, then choose between Single Release Point and Integration Token as follows:

Single Release Point is good for small co-located teams when codeline contention common but not very frequent. A single release area and/or single integration machine effectively locks the entire codeline against checkin by serializing the use of the sole resource with which codeline checkins are made. The scope of the lock is the entire codeline, so if change-set overlap is rare but completion-overlap is common, this may not be the best approach.

Integration Token works well if more explicit team-wide communication of commits is desired, or if the team is not co-located. An informal 'verbal' or 'visual' token can work well for co-located teams. The Integration Token can be used with or without a Single Release Point . When it is infeasible or inconvenient to restrict integration activities to a single physical location or resource, then use an Integration Token without mandating a Single Release Point .

Codeline Write-Lock is appropriate for formally enforced codeline locking. If you