Agile SCM - Relating Patterns to OOD, TBD and POB Principles

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: [1]

    • 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 ([5]) 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 [6] 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 [7] [8]. 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" [9], finding the right balance between the time taken to perform local builds and tests and the benefits

About the author

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.