Principles of Agile Version Control: From Object-oriented Design to Project-oriented Branching


The CBDP is the equivalent of dependency-inversion. The container, as the unit of encapsulation, is the thing that we should depend upon, instead of directly referencing the content or context of the container. The ADP is practically unchanged from its OOD incarnation, and almost not worth repeating, except that dependency management plays an important role in CM. IDIP is a rather interesting translation of the Law of Demeter (LOD) and bears some further explanation.

Evolution Insulation for Unique Identification

The more specific form of the Law of Demeter states that an object method should invoke the methods of only the following kinds of objects:  a) itself, b) its parameters, c) any objects it creates, or d) its direct component objects. In particular, an object should avoid invoking methods of a member object returned by another method.


In version-control, the containers we use don't really have methods beyond the operations provided by the version control tool. However, there are a couple of things that we end up doing with the tool that come pretty close to being methods or services provided to the rest of the CM system and its users: identification and status-accounting.

Identification of a container is the unique name that we give it in the version repository. These would be the names of things such workspaces, codelines and branches, version labels/tags, and change-sets/change-tasks. We usually try to provide descriptive names for these types of containers that will mnemonically suggest their intended meaning and purpose. When any of these names are used in long-lived queries, metrics, or reports and are used to represent unique keys of data that are used when generating such queries, metrics or reports, it can wreak havoc when a name needs to be changed.

Certainly any queries, metrics and reports should program to an interface, not to an implementation when making use of our containers and their data.  In order to avoid similar types of problems, the names of the containers they do use to access that data need to be treated in a similar fashion. This gives rise to an equivalent of the Law of Demeter for configuration identification.

The Identification Insulation Principle (IDIP)

The name of a container should be insulated against change by ensuring that it identifies only the following kinds of significant information: its intended purpose, controlling inputs, or immediate content. A name should not identify any parts of its context nor or of its parent/child/sibling containers that are subject to evolutionary change. What this means is that the names of things like workspaces, changes/tasks, codelines, etc., should be named after their content and/or their intent. The identifier used should not attempt to describe any context information or association that might change during the lifetime of the object.


About the author

Brad Appleton's picture Brad Appleton

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 book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at,  and a former section editor for The C++ Report. You can read Brad's blog at

About the author

Robert Cowham's picture Robert Cowham

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.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!