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

do we decide which patterns and strategies to use that work for us (rather than Fred, Barney, and Betty). We need to look at our context and our needs and match them to the applicable context of the patterns and strategies. And we need to look at the tradeoffs between the competing forces or concerns that result from applying a particular solution. Some guidelines follow:

Workspace Update should be used at a minimum immediately prior to committing your changes to the codeline. In this context it is actually part of the commit-preparation activities that also include Private System Build .

Continuous Workspace Update should be used to minimize commit-preparation 'cycle time' when you want your workspace to always be as 'up-to-date' as feasible (even when you are in the middle of a change). If your codeline is not particularly volatile or if build and test cycle times are already fast enough so that you rarely (if ever) have to try and hit a 'moving target' when integrating your changes to the codeline, then it may make sense to update your workspace less frequently.

Post-Commit Notification should be used as a tooling mechanism to facilitate Continuous Workspace Update or if needed to improve communication about committed changes within the team. Note that Integration Token communicates both the start and finish of a commit.

Private Checkpoint/Versions should be used when you want to be able to capture the known state of a change-task in your private workspace. The known state should be one that is not suitable for committing to the codeline based on its Codeline Policy (otherwise you should commit your changes instead of checkpointing them). Usually this will be immediately prior to a Workspace Update when you want to be able to rollback your workspace if the update 'goes sour' and/or use the checkpoint as a basis for file comparison/differencing/merging.

Our experience is that unless your version-control tool does this automatically (or can be configured to do so without adding any development "friction") then people usually don't feel it is necessary - right up until the first time they get burned by it (after which they may tend to do it religiously (wink). It can be handy from time-to-time however.

There are several possible strategies for implementing Private Checkpoint/Versions , each with their own set of trade-offs:

Private Archive is appropriate when your change-task is already in progress and you didn't have sufficient reason to believe you would likely need to checkpoint your changes when you started this particular task. It is also suitable when the set of files modified is very small and/or all in one central location within the source-tree (typically all in one subdirectory).

Private Branch is appropriate when you are just starting your change-task and you believe there is sufficient reason to believe that you will likely want to checkpoint your changes at least once before committing them to the codeline. (And you expect to be modifying more than just a handful of co-located files in the source-tree.)

Task Branch is appropriate when working on a change-task that is experimental, or which must not have any 'partial functionality' committed to the codeline (only the full and complete functionality). It is also useful if your version-control tool has no built-in mechanism for identifying Change-Sets or Change-Packages and you want to be able to group together and easily identify the set of changes made for your change-task.

Checkpoint Label is appropriate when you want to checkpoint the state of your workspace (not just the files you changed, but all the files that are updated) and you aren't using