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

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 which might change during the lifetime of the object.

Sometimes it is easy to go overboard with identifying more information than is absolutely necessary in the name of a thing. If the name we give it somehow implies an association with some other object, then it creates an undesirable form of dependency if that association does not last. It creates, at the very least, and inconsistency between what the name suggests, and the actual relationship. And if that object and its name is frequently referenced by others, or in other databases, repositories, queries/reports, or scripts, then such an inconsistency can actually break things in the SCM environment.

For example, if a task-branch is used, and if the task is intended to be targeted to a particular release, many may include that release-name in the task branch. But if there is any real possibility that the change might go into a different release instead, then the name would no longer be accurate; Changing the name at that point could wreak havoc if the name was used as a unique identifier of the change in other repositories, databases, reports, etc.

Similar problems often arise in an organization's document naming conventions, especially if document names contain organizational identifiers and the organixation frequently undergoes renaming or restructuring.

Principles of Task-Based Development

The first two of the above principles (STWP and CHIP) are derived from the Single Responsibility Principle (SRP). Here's how ....

The Single-Threaded Workspace Principle (STWP):

A private Workspace should be used for one and only one development change/task at a time.

The STWP is basically a statement about multi-tasking. It says a worker in a dedicated workspace should work on only one thing at a time within that space (to avoid the overhead, complexity, and interruption of flow that results from frequent context-switching between multiple tasks).

The Change Identification Principle (CHIP):

A development change should clearly correspond to an intended development task (e.g., for a fix, feature, or enhancement).

The CHIP is basically saying that development changes should be transparent to the extent that they are intention-revealing. A change is transparent if:

• its "container" is visible and can be readily used to reveal its contents, and ...
• its container or content clearly identifies the corresponding task that is the reason for performing the change.

This might be accomplished by associating the change with a record in a tracking "system", such as a feature ("story"), fix or enhancement. There might be other ways to accomplish the purpose of change-transparency as well.

Last month, we concluded that the OCP translated to the concept of preserving the identify or essence of its container. What does it mean to "preserve the essence" of a change? Preserving the "essence" of change means that if we say a change is in the codeline, we have a way of knowing and showing that its "in