both the source of change and reuse) and that the collaboration for a change is not finished ("closed") until it is built+tested (intregrated) so as to be releasable (ready for reuse).
Principles of Branching & Merging
| Principles of Branching & Merging | |||
|---|---|---|---|
|
The Codeline Nesting Principle (CLNP) |
Child codelines should merge and converge back to (and be shorter-lived than) their base/parent codeline. |
||
|
The Progressive-Synchronization Principle (PSP) |
Synchronizing change 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; more progressive codelines should sync-up with more conservative codelines. |
||
|
The Codeline Branching Principle (CLBP) |
Create child branches for value-streams that cannot "go with the flow" of the parent. |
||
|
The Stable Promotion Principle (SPP) |
Changes and configurations should be promoted in the direction of increasing stability. |
||
|
The Stable History Principle (SHIP) |
A codeline should be as stable as it is "historical": The less evolved it is (and hence more mature/conservative), the more stable it must be. |
||
For our interpretation of the LSP, another form of "derivation" in version control is when a new branch or codeline is "branched" from a particular point off of it's "parent" codeline. The branchpoint is the baseline (or foundation) configuration for the new branch. The new branch "inherits" all content from its parent codeline while being allowed to evolve separately, and (unless it is a permanent variant) usually diverges from its "parent" or "base" codeline for a limited period of time and either promotes or else propagates changes back to its parent at periodic intervals.
At the time it merges back into its parent, then the CLIP mandates that the integrity of the base/parent codeline must once again be maintained. So regardless of whether the child branch is for maintenance purposes or for new development, the parent codeline should be longer-lived than the child, and the child should merge back to its parent (possibly multiple times as well as at completion):
- The Codeline Nesting Principle (CLNP):
- Child codelines should merge and converge back to (and be shorter-lived than) their base/parent codelines
The CLNP actually conveys fundamental advice about the branching structure of a component or product. It says to use a simple, recursive hierarchical structure, similar to the preferred control-flow structure (and identation format) of statements in a computer program. The CLNP suggests avoiding the continual cascading/staircase style of branching and instead points us in the direction of the Mainline pattern for organizing our branching structures using nested synchronization ("mainlining") [2][10].
The CLNP also seems to share much in common with the portion of Laura Wingerd's Base-Codeline Protocol which says that changes should always flow from child codelines to their base/parent codelines. The other half of the base-codeline protocol addresses the main difference between the two scenarios above: changes flow from parent to child only when the child is for new development (and not when it is for legacy maintenance). This is necessary to maintain the integrity of both codelines while also preserving the relationship between them. The CLNP doesn't go quite this far, but perhaps one of our later principles will.
So if changes should always flow from child-codelines to their parent-codelines (CLNP), then when, if ever, should changes flow in the reverse direction (from parent to child)? In general, we have three basic kinds of codelines and change-flow:
- New Development & Change Promotion : Development lines are used to create new functionality (value-adding changes). Such changes are promoted when they are merged (committed) from a workspace (or another branch) are committed to a codeline.
- Legacy Maintenance & Change
About the author
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 bookSoftware Configuration Management Patterns, a columnist in The CM Journal and The Agile Journal at CMCrossroads.com, and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.
About the author
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.
