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 of the resulting avoidance of error is not always obvious.

Continuous Workspace Update  - PSP, IIP
This pattern [2] works well together with private checkpoint, hence the same principles applying. "Little and often" seems like more work but it beats the alternatives!

Integration Build    - CLIP, PLP, IPP, BLIP, CLFP, CFLIP, IIP
This pattern is a superset of Private Build. Collaboration/Flow Integration Principle is a dynamic expression of CLIP. Integration is all about collaboration, so CFLIP also applies,

Continuous Integration, Pre-Commit Validation and Post-Commit Notification  - CLIP, PLP, IPP, BLIP, CLFP, CFLIP, IIP
Continuous integration is the combination of Integration Build to ensure integrity with regular feedback to users which improves the flow of changes and evolution. These principles [2] are part and parcel of ensuring integrity (CLIP), and the net result is an increase in "rhythm" or frequency of correct checkins, thus an increase in flow.

Unit/Smoke/Regression Tests - CLIP, BLIP
A pattern of principles occurring here! CLIP implies a number of patterns working together to ensure integrity - see the others where this occurs.

Codeline Policy - CEP, CLFP, CLIP, CFLIP
This is a pattern of applying principles! Specifying the attributes of your codelines, and which principles apply to which level, defines the policy. Content Encapsulation

Active Development Line, Release Line and Mainline - PLP, CLFP, CLIP, CLNP, CLBP, SPP, SHIP
Promoting changes between codelines in consistent chunks (PLP) keeps codelines as stable as possible, and yet provides for changes and evolution of those codelines as appropriate.

Conclusion
How well are the principles we derived holding up? Where are there overlaps with patterns? Where do principles add value, and where do they not? As you can see this is a work in progress and we look forward to feedback and suggestions!

We intend to revisit this article to consider some other commonly used patterns as well.

References

[1] Software Configuration Management Patterns: Effective Teamwork, Practical Integration; by Stephen Berczuk and Brad Appleton; Addison-Wesley, November 2002.

[2]  Codeline Merging and Locking: Continuous Update and Two-Phased Commits; by Brad Appleton, Steve Berczuk, Steve Konieczka, CM Journal, November 2003

[3] Agile Build Promotion: Navigating the Ocean of Promotion Notions; by Brad Appleton. Steve Berczuk; CM Journal, September 2004

[4] Continuous Staging: Scaling Continuous Integration to Multiple Component Teams; by Brad Appleton, Steve Berczuk, Steve Konieczka; CM Journal, March 2004

[5] Practical Perforce: Channeling the Flow of Change in Software Development Collaboration; by Laura Wingerd; O'Reilly & Associates, 2005

[6] "Merge as You Go", Christopher Berarducci - Software Engineer, Handspring, Perforce User Conference 2003

[7] "Yesterday, my program worked. Today, it does not. Why?" Andreas Zeller

[8] Delta Debugging

[9] The Illusion of Control; by Brad Appleton, Steve Berczuk, Steve Konieczka, CM Journal, December 2005