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


A codeline basically represents an effort to either maintain the past, coordinate the present, or develop the future. Change-flows either propagate stabilizing change, synchronize shared progress, or promote new value. Note also that both propagation and synchronization are basically updating previous context while promotion is creating new content.

More progressive codelines should be synchronized from their more conservative parents, but the opposite is not true.  More conservative (e.g., maintenance) codelines should not be synchronized from the more progressive parents. Given our earlier translation of abstractness to conservative, this would seem to be a valid interpretation of dependency inversion as applied to codelines and change-flow.

The Progressive Synchronization Principle (PSP)

Synchronization should flow in the direction of historical progress, from past to present, or from present to future. More conservative codelines should not sync-up with more progressive codelines and more progressive codelines should sync-up with more conservative codelines.

As we might have expected, this is almost the exact equivalent of the second half of Laura Wingerd's Base-Codeline Protocol [8]: changes flow from parent to child only when the child needs to be more stable than the parent. The PSP uses the term "more conservative” instead of more "stable" or "safe."

Are stability and conservativism the same thing? Not according to our domain translations from before. We previously equated stability with safety and abstractness with conservativism.

Similarly, for codelines, there may be many different temptations to branch off a new codeline, but the ones that are significant enough to truly warrant a separate codeline are when the new branch either adds or preserves value for its customers, and/orimproves or preserves the flow of its parent codeline.

A prime example of adding/preserving value would be a maintenance branch to support a legacy release. Here it is assumed there is either additional support revenue to be gained, or significant business-loss to be avoided (enough to make it worthwhile to support and maintain the new codeline).

An example of preserving flow would be the Release-Line and Active Development-Line patterns. Ideally, one could get away with using only the release-line, but the difference in audience and criteria for the active-line is enough that it would significantly disrupt the flow of the parent release-line.  The parent's collaboration requirements would impose too much development friction against the flow of the child development-line.

For codelines, the ISP gives us some rules for when it is appropriate to create a new branch off of the "current" codeline.

The Codeline Branching Principle (CLBP)

Create child branches for value-streams that cannot "go with the flow" of the parent.

Here, go with flow simply means that the existing codeline invariant (its required levels of correctness, consistency, completeness, and its cadence) can't meet the needs of both sets of prospective codeline users. Because of this, it needs to split by branching off a separate stream of change-flow for the two competing/conflicting sets of users. This would seem to be a restatement of the branch on incompatible policy rule.

About the author

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.