Principles of Agile Version Control: From OOD to TBD

Encapsulation

The DRY Principle would seem to translate pretty directly to version control terminology:

Each pieve of version-control information should have a single unambiguous authoritative representation within the version-control system.

Interface Segregation ~ Promotion Leveling & Codeline Branching

The Interface Segregration Principle for OOD says “make fine-grained interfaces that are client-specific.” All the consumers of a class should be partitioned into one or more “client types” and a separate abstract interface should be defined for each type of client the class must serve.

Interfaces are a form of abstraction/abstractness, and for version control we believe that translates into acceptance criteria (for the "users" of a container) and level of visibility of a container. For version control, "interface segregation" can be applied to changes, baselines, and codelines:

• For changes, there are the times when they are "private" and still in-progress, and then they are subsequently ready to be promoted in visibility and use to progressively more "public" scopes of the enterprise.
• For baselines, their contents do not change. What changes is the level of assurance we have as to their overall quality and readiness for production release/deployment. And an "in progress change" is just an initial, private (not yet promoted) state of a configuration that may eventually be baselined and further promoted.
• For codelines, their contents do change and evolve, sometimes to the point where we need to consider whether or not to brance a new codeline to support a parallel path of evolution.

All of these are really just forms of Visible Incremental Evolution when restating the general form of ISP in terms of version-control containers:

Make fine grained acceptance-criteria that are client-specific.

Reuse, Release and Evolution Granularity

The OOD principles of Reuse-Release Equivalence, Common Closure, and Common Reuse are all about the appropriate granularity of "packages" of classes. We wish to investigate the corresponding granularity of "packages" of evolution within a version control environment. We can consider the "scope" and granularity of a change, a baseline, a codeline, and beyond. In either case, both (re)use and release imply reuse by some consumer, and releasing to some target consumer. Once again the notion of "abstractness" in OOD translating to the level of visibility of versioned content will play a key role.

In version control, reuse of changes and versions occurs when we view or update (merge/modify) a version of one or more files in our workspace in order to develop, build, test and release our changes. The releasing of changes and versions occurs when we commit changes to a codeline, transfer changes between codelines, baseline a configuration, or promote a configuration to a new promotion-level. based on this we already know a few things about change granularity:

• The granule of change is not an individual file/checkout, but is rather a single development task whose changes we then commit to the codeline.
• The granule of baselining and promotion is not an individual change, but is instead the unit of integration for building & testing the component or product undergoing change on the codeline: the configuration.
• The granule of progressive collaboration and evolution is the codeline

Not all of the above require "principles" (the last one in particular seems tautological). Furthermore its not apparent that each of these three OOD principles will translate into individual version control principles. So we instead seek to see if we can apply these three principles together as a group for each of changes, baselines, and codelines.

Package Coupling ~ Change-Flow

The package coupling principles of OOD translate almost directly to version-control with only slight modification (sometimes "dependency" translates into "flow", but note that change-flow does not