vague for our taste won't be listed as general principles (but will still be applied to derive more specific ones).
| General Principles of Container-Based Versioning | |||
|---|---|---|---|
|
The Content Encapsulation Principle (CEP) |
All version-control knowledge should have a single authoritative, unambiguous representation within the system that is its " container. In all other contexts, the container should be referenced instead of duplicating or referencing its content. |
||
|
The Container-Based Dependency Principle (CBDP) |
Depend upon named containers, not upon their specific contents or context. More specifically, the contents of changes and workspaces should depend upon named configurations/codelines. |
||
|
The Identification Insulation Principle (IDIP) |
A unique name should not identify any parts of its context nor or of its related containers (parent, child or sibling) that are subject to evolutionary change. |
||
|
The Acyclic Dependencies Principle (ADP) |
The dependency graph of changes, configurations, and codelines should have no cycles. |
||
Note that the CEP is simply the DRY Principle being used to create the version-control equivalent of a "class." The "container" is the unit of encapsulation for our purposes. This is what allows us to apply all the other OOD principles to the domain of version-control.
The CBDP is the equivalent of dependency-inversion. The container, as the unit of encapsulation, is the thing that we should be depending 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/instantiatess; 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 darn 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 likes workspaces, codelines & branches, version labels/tags, and change-sets/change-tasks. We usually try to provide descriptive names for this types of containers that will mnemonically suggest their intended meaning and purpose. When any of these names are used iin any long-lived queries, metrics, or reports and are used to represent unique keys (in a database) of data that is used when generating such queries, metrics or reports, then it can wreak havoc when one of these names needs to be changed for some unforeseen reason.
Certainly any queries, metrics and reports should "program to an interface, not to an implementation" when making use of our containers and their data; And in order to avoid similar types of problems, the names of the containers they do use to acces 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 it identifies only the following kinds of significant information: its intended purpose, its controlling inputs, or its immediate content. A name should not identify any parts
About the author
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.
About the author
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.
