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

there" (both functionally and physically). We must have a way of detecting and identifying its presence, content, and behavior:

The Change Auditability Principle (CHAP):

A change should be made auditably visible within its resulting configuration.

The CHAP goes a step further than the CHIP. The CHIP simply says a change needs to reveal its intent; The CHAP says a change needs to "prove" its existence in form, fit, and function! CHIP is a promise that the change is authorized and planned; CHAP verifies that the promise was fulfilled! Taken together, the CHIP and CHAP are about establishing trustworthy transparency for a change/task. We do this by being able to repeatably and reproducibly demonstrate and report the request, status, and results of a change, as well as the "who+what+when+where" of a change: the former is often stored and managed in the tracking system, and the latter is typically captured within the version-control repository when the changes are checked-out and in.

The principles of package cohesion (REP, CRP, and CCP) all seem to point to the notion of a change as a single, atomic unit:

The Change Transaction Principle (CHTP):

The granule of work is the transaction of change.

The CHTP is suggestive of patterns like Task-level atomic commits. And last but not least we have the ISP translating into the ever important (and almost too fundamental to mention) principle of incremental development, even for tasks:

The Incremental/Evolutionary Development Principle :

Develop changes in fine-grained increments that are client-valued.

In order to be client-valued, the increments need only to add some portion of requested functionality that can be successfully built and tested. The presumption here is that the increments may be within a task. But this principle doesnt make that very clear, nor does it make it clear if change-increments should be separately integrated or not. For this reason, we feel that while the above is certainly important, it's not quite specific enough to claim it is a version-control principle, much less a TBD-specific one!

Principles of Baseline Management

One of the first priniciples we considered here was some sort of "Single Configuration Principle" that would be an application of the SRP to baselines: a baselien should correspond to one and only one configuration. The single configuration might include other configurations, but the its intent is to represent a single configuration for a single purpose. This just didnt seem to be significant enough to warrant having as a principle. If you disagree, please email us and tell us why (we are eager for your feedback).

For baselined versions, identity preservation (our translation of OCP) means that if I "baseline" a version and label/tag the result, then that resulting version name should always correspond to that same set of file versions! It's not okay if it refers to version 10 of file helloworld.c one day, but refers to version 11 of the same file a week later. If I "baseline" a version, it means I'm planning on handing it over to some consumer using that version name, and making a promise that the version name will forever correspond to that very same content every day thereafter for as long as the project & product is still in use. This gives us ...

The Baseline Integrity