The authors look at SCM patterns and consider the relationships between those patterns and object-oriented design principles of version-control for task-based development (TBD). They then move on to explore SCM principles for codelines, branching and promotion—project-oriented branching (POB).
We go back to SCM patterns and consider the relationships between them and the principles we have have expanded on in our previous two articles. Those articles considered how the principles of object-oriented design (OOD) applied principles of version-control for task-based development (TBD) with workspaces, changes, and baselines, and then moved on to derive principles for codelines, branching and promotion - project-oriented branching (POB).
Having proposed the principles, we would like to look at refactoring them where appropriate. First let us summarise the initial list of the relevant principles: 
ADP - Acyclic Dependencies Principle
BLIP - Baseline Integrity Principle
CBDP - Container-Based Dependency Principle
CEP - Content Encapsulation Principle
CFLIP - Collaboration/Flow Integration Principle
CHAP - Change Auditability Principle
CHIP - Change Identification Principle
CHTP - Change Transaction Principle
CLBP - Codeline Branching Principle
CLFP - Codeline Flow Principle
CLIP - Codeline Integrity Principle
CLNP - Codeline Nesting Principle
IDIP - Identification Insulation Principle
IDIP - Identification Insulation Principle
IIP - Incremental Integration Principle
IPP - Integration/Promotion Principle
PLP - Promotion Leveling Principle
PSP - Progressive-Synchronization Principle
SCP - Serial Commit Principle
SHIP - Stable History Principle
SPP - Stable Promotion Principle
STWP - Single-Threaded Workspace Principle
Private Workspace - STWP Developer's work in their own workspace where they are in control of what is changing - their local check outs etc. Experienced developers tend to seek to stick to the Single-Threaded Workspace Principle (of course real life intervenes occasionally, and yet they tend to be more resistant to unnecessary interruptions or re-prioritisations). Multi-tasking seems to offer benefits and improved efficiency, and yet particularly with knowledge work, context switching rapidly uses up any gains.
Workspace Update - IIP How frequently should be update our workspace with changes from the repository? IIP suggests it be incrementally, and yet offers no more guidance than that in its current form. Laura Wingerd () makes a good case for bringing in changes one by one to make it easier to perform merges and to resolve conflicts. In addition, Christopher Berarducci  offers experience of how incremental changes brings benefits via automatic merging which exposes the problem in a similar way.
Task-Level Commit - SCP, IPP, CHIP, CHAP, CHTP Task-Level Commit and the principles of CHIP, CHAP and CHTP are easily satisfied when using tools offering atomic change sets or the equivalent (the subject of a future article!). If you aren't using such a tool then you are missing out and should seek to rectify it quickly. The availability of Subversion covers those with limite budget...
Private Checkpoint - IIP, PLP The willingness to take frequent checkpoints is often the sign of an experienced developer. It enables practices such as Delta Debugging  . If you have saved 20 checkpoints in a several hour session then it is easy to find the bug you might have introduced in amongst the 19 good changes. If you took no private checkpoints, you sometimes spend as long finding the bug as you did making good changes with which it was mixed up. PLP seems to have some relevance here, and yet it is perhaps more related to branching patterns.
Private Build - CLIP, PLP, IPP Integrity as defined in CLIP is the most important principle behind Private Build. Far better usually (depending of course on the tools in use and how long such builds take) to discover problems early before checking in when the rest of the team to be affected. As discussed in "The Illusion of Control" , finding the right balance between the time taken to perform local builds and tests and the benefits
Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.
Robert Cowham has long been interested in software configuration management while retaining the attitude of a generalist with experience and skills in many aspects of software development. A regular presenter at conferences, he authored the Agile SCM column within the CM Journal together with Brad Appleton and Steve Berczuk. His day job is as Services Director for Square Mile Systems whose main focus is on skills and techniques for infrastructure configuration management and DCIM (Data Center Infrastructure Management) - applying configuration management principles to hardware documentation and implementation as well as mapping ITIL services to the underlying layers.