Streamed Lines: Branching Patterns for Parallel Software Development

Copyright © 1998 by Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein.
Permission is granted to copy for the PLoP '98 conference.

Table of Contents
[printing/downloading instructions]
Send us your comments!

Appendix A - Streamed Lines: The Patterns

Extremely brief descriptions of the patterns are provided below. Full descriptions may be found by following the hyperlink on the name of the pattern to reach its detailed description.

Basic Branch/Line Elements

E1. Activity Branch
A branch used for working on an individual change task or activity.

E2. Functional Branch
A branch used for work on an individual feature or function.

E3. Component Branch
A branch used for work on a specific component or subsystem.

E4. Project Branch
A branch use for work on a separate line of development for a particular (sub)project.

E5. Development Line
A branch used for new development efforts and which might not include maintenance efforts.

E6. Maintenance Line
A branch used primarily for maintenance changes (fixes and minor enhancements).

E7. Integration Line
A branch used primarily for integrating changes from other branches.

E8. Release Line
A branch used for work on a specific-release or for the release-engineering and integration efforts for a specific release.

Branching Policy Patterns

P1. Codeline Policy
Define a policy for each codeline which specifies if/when and how changes may be checked-out, checked-in, and merged, and propagated.

P1.1 Self-Documenting Codeline
Take advantage of various features of your version control tool to define codelines in a way that self-documents the codeline's policy.

P1.2 Codeline Conventions
Create a project-wide policy document that lays out strategies and conventions that apply to all codelines.

P2. Codeline Ownership
Assign a responsible owner for each codeline to settle policy disputes and ensure the integrity and consistency of the codeline.

P2.1 Codeline Dictatorship
No one may perform any checkins, checkouts, or branches off a codeline without approval from the codeline-owner; or else no one at a remote site may do anything to a codeline at the master-site, without approval from the master-site.

P3. Relaxed-Access Line
Permit any developer who might have the need, to perform checkouts, checkins, or branches for a codeline.

P3.1 Guarded Merge Access
Let developers checkin to the codeline as they see fit, contingent upon an automated check ensuring there will be no merge conflicts upon checkin.

P4. Restricted-Access Line
Apply a "lock" to a branch or codeline, or otherwise limit the set of users that may make changes to it to a small set of trusted developers.

P4.1 Codeline Freeze/Retirement
Lock (freeze) a codeline against all further development while it is being prepared for a release. Then, either decommission the codeline (leaving it locked), or else unlock the codeline after release efforts have completed to resume development.

P4.2 Export Lock
Briefly lock a codeline against all other checkins while a particular developer is merging a change into the codeline.

P4.3 Private Branch
Lock a codeline or branch against use by all but the codeline owner.

P4.4 Role-based Line Access
Rather than restricting a codeline to certain users, restrict it to certain development roles.

P5. Merge Early and Often
Merge changes from a branch to its codeline as soon as the changes on the branch are completed and tested.

P5.1 Propagate Early and Often
Propagate merged changes to target codelines as soon as the original change has been successfully integrated into its original codeline.

P5.2 Multi-Merge Early and Often
Rather than merging a single change-task at a time, merge a handful of change-tasks at once and do it at regular intervals.

P6. MYOC (Merge Your Own Code)
Developers are responsible for merging their own code into the codeline.

P6.1 PYOC (Propagate Your Own Code)
Developers are responsible for propagating their own code into other codelines.

P7. Early Branching
Spawn a new release or development codeline as soon as work for the new release or subproject begins.

P8. Deferred Branching
Wait to spawn a new release or development codeline until it starts to conflict with parallel work for its successor.

Branch Creation Patterns

C1. Policy Branch
Create a new branch when some users of an existing codeline need to work according to a different policy from the rest of the codeline's developers.

C2. Branch per Task
Perform each change-task on its own activity-branch.

C2.1 Branch per Major Task
Create an activity-branch only for sufficiently long or complex/risky activities. Perform minor tasks directly on the codeline.

C2.2 Branch per Change-Request
Perform each change-task resulting from a formal change-trequest on its own activity-branch.

C2.3 Personal Activity Branch
Create an activity branch for use by one and only one developer.

C3. Codeline per Release
Use a separate codeline for each major and minor release (and patches).

C3.1 Codeline per Major Release
Use a separate codeline for each major release.

C4. Subproject Line
Rather than having change-tasks depend on activity branches that haven't been merged into the codeline, create a subproject codeline for the related set of dependent tasks.

C4.1 Personal Codeline
Create a new codeline for related changes that will be performed by a single developer.

C4.2 Experimental Codeline
Create a new codeline for experimental development/prototyping which might not get merged back into anything.

C4.3 Multi-Project Lines
Multiple project-lines or product-lines are used and releases are configured by selecting the appropriate stable baselevel of each project/product-line and integrating the result.

C5. Virtual Codeline
Simulate a codeline using a floating label, and just-in-time element-branching.

C6. Remote Development Line
Create a new codeline specifically for development and integration to be performed at a remote-site.

C7. Component Line
Create a new codeline reserved exclusively for development and maintenance of a component-owner's source code.

C7.1 Multi-Product Lines
Same as Multi-Project Lines configured by selecting the appropriate stable baselevel of each project/product-line and integrating the result.

C8. Platform Line
A permanent development codeline for an operational variant of the system that must build/run on a different platform.

Branch Structuring Patterns

S1. Mainline
Have all other codelines eventually join back into a single primary codeline.

S1.1 Stable Receiving Line
Reserve the primary codeline exclusively for integration of stable bases from other codelines.

S1.2 LAG Line
Reserve a primary codeline for the latest and greatest development efforts.

S1.3 Multiple Mainlines
Sometime multiple platform lines will necessitate a mainline for each major platform, especially when the different platforms cannot be meaningfully integrated into a single codeline. Similarly, if multiple integration lines are used for a major release-line, component-line, or subproject-line, then a mainline may be used for each such major release, component, or subproject (perhaps feeding back up to a system-wide integration line).

S2. Parallel Maintenance/Development Lines
When line maintenance and development must occur simultaneously, split maintenance of into a separate codeline that regularly merges back into the development line.

S2.1 Parallel Releasing/Development Lines
Instead of freezing the codeline during release engineering activities, a separate line is created for release integration and engineering while allowing other development to continue taking place on the development line.

S3. Overlapping Releases
When developing for multiple releases at the same time, split the earlier release into a separate codeline that regularly merges back into the other release development line.

S4. Docking Line
Instead of merging changes directly into the codeline, merge them to a separate "docking" line where they are integrated and tested and then merged back to the codeline.

S5. Staged Integration Lines
Cascading branches are used to represent a hierarchy of promotion levels that correspond to points of integration and/or transfer of responsibility in the development lifecycle.

S5.1 Cyclic Promotion Lines
Cyclic promotion lines are staged integration lines where changes must progress from the development line through the entire promotion cycle before being merged back into the development line. Thus changes take a cyclic path to end up back in the codeline from which they were originally checked-out.

S5.2 Escalating Promotion Lines
Escalating promotion lines are staged integration lines where changes are merged back into the development first and then continue through the remainder of the promotion "stairway" or "ladder."

S6. Change Propagation Queues
Define change migration relationships between codelines (e.g. fixes from release 1.1 need to migrate to release 2.0) and ensure that changes originating from the same codeline are propagated in the same order in which they were originally completed and merged.

S6.1 Auto-Propagation and Queuing
When possible, propagations are performed automatically, otherwise they are queued-up for manual propagation.

S7. Third Party Codeline
When version controlling local changes to third party code, user separate codeline to represent the vendor's development and your own local development and merge updates from the vendor-line into the local-line.

S8. Inside/Outside Lines
Internal users of a centralized repository perform changes and integration on a restricted-access line reserved for internal-use only. Geographically dispersed users perform development on a separate external-line that is periodically synchronized with the internal-line.

[back to the table of contents]

Send us your comments!