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


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, an inconsistency between what the name suggests and the actual relationship. Also, if that object and its name is frequently referenced by others, in other databases, repositories, queries/reports, or in other 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. If there is any real possibility that the change might go into a different release instead, though, 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 organization frequently undergoes renaming or restructuring.

Principles of Task-Based Development

Principles of Task-Based Development

The Single-Threaded Workspace Principle (STWP)

A private workspace should be used for one and only one development change at a time.



The Change Identification Principle (CHIP)

A change should clearly correspond to one, and only one, development task.



The Change Auditability Principle (CHAP)

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



The Change Transaction Principle (CHTP)

The granule of work is the transaction of change.




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!