Codeline Management for Evolutionary Development

Anders JohnsonWIS Technologies

Evolutionary Development

Traditional (“big-bang”) Evolutionary100%

Time →

Co

mp

leti

on

→

0%

100%

Time →C

om

ple

tio

n →

0%

Features

Features

Quality

Quality

So What?

“The literature” says that it leads to:• Increased productivity• Decreased risk• Higher quality

SimultaneouslyBut be realistic

• Unlikely to halve the schedule on first try

Automated Regression

Yes, you need it!Near-production test after every

mainline change• No way you’re going to do that manually!• Test at various levels of integration

Don’t need to worry about breaking anything that the tests cover

Who Farted?

Sync’ing-in broken changes is extremely counterproductive

Impossible to test unrelated changes

But, you still need to share some changes before they’re functional

Branches or Labels?

Branches (a.k.a. “codelines”) are better for evolutionary development

Labels often fail to converge:

Time →

OK (?)Feature A Broken

OK (?)Feature B Broken

Feature C Broken

L “OK” Label

Development Codelines

Contain changes that aren’t expected to work

Multiple contributors can exchange early changes

Use the mainline instead if you require something that actually works

Integrate into mainline when it works

Distinguishing Codelines Each codeline has its own regression (or lack

thereof)• May or may not be driven by a submit trigger

Each codeline has its own default view• Client generation is scripted, such that the view is

set automatically• Codeline-name@change describes a source

configuration definitively

Reining in the Chaos

Each workspace is based on exactly one codeline

Each codeline (except the mainline) has exactly one parent codeline

Workspace location corresponds exactly to depot location (relative to codeline root)

//depot

top branch1

file1

dir

file2

top

branch2

top

file1 file1

dir dir

file2file2

Depot Structure

TRUNK

branch1/ branch2/

Extension Fields

Extra fields (such as client’s codeline and branch’s parent codeline) piggy-back onto the “Description” field:Client: anders_a4

Description: Created by anders.

----- Please do not delete these lines from the Descripti on field ----- %Branch: a4/ %Location: //depot/a4/top

Root: /home1/anders/anders_a4

Codeline ConfigurationEach codeline’s regression and default

view is stored in a designated location in the file tree• CFG/codeline-name/top/• Changes propagate automatically

Regression changes should be reviewed• “The regression failed, so I disabled it.”

Sequential Regression

If there is a regression, then every submission must be strictly sequential

Submitter’s workspace (including unchanged files) must be up-to-date

Otherwise, the regression might pass even if the depot would be broken

Doing this reliably requires locking

Symbolic link in each workspace directory pointing to workspace root

Portable among workspacesCan often be used where an absolute

path would normally be required

.p4top

% cd anders_a4/foo/bar; ls –Alolrwxrwxrwx 1 anders 5 .p4top -> ../..

Staying in SyncFiles can differ even if Perforce thinks

that there’s nothing left to mergeFor fully-merging codelines:

• Integrate only between parent and child• Child must contain all of parent’s changes• Then, p4 integrate -dft and p4 resolve –at into parent

Not for vendor & release codelines

Switching Codelines

Changes sometimes wind up in the wrong workspace

To avoid stranding them, need to create and apply patch files

Hierarchical Regression Every codeline can be regressing

simultaneously

TRUNK(4 hr)

Feature A/(3 min)

Feature B/(3 min)

Feature C/(3 min)

Development A1/(no regression)

Development A2/(no regression)

Development C1/(no regression)

Reference Builds

We “cheat” by running regressions inside the submitting workspace

This occasionally causes a false positive or false negative:• Environmental dependencies• Build system deficiencies• Failure to p4 add

Reference Builds (contd.)

Periodically clean-build as a pseudo-user with a baseline environment

Regression should be deterministicResults can be cloned into new

workspaces (in conjunction withp4 flush) to bypass clean-building• It’s practical to have tools under Perforce

Concurrent Related Projects

SURPRISE: Inter-file branching is not a good general solution for this• Relies on merge-at-destination, which is

bad because the originator is usually better equipped to merge

• Results in duplicated merging effort, especially if there are more than 2 projects

Concurrent Projects (contd.)Instead, make all the projects visible in

the same tree, and share as much as you can:• Symbolic links• #ifdef• Design patterns• Etc.

Works whether or not you branch

Concurrent Projects (contd.)

Copy-and-paste is bad code economy, and it’s essentially irreversible

Indiscriminant inter-file branching is only somewhat better

Try sharing first• You’ll like it• If not, it’s relatively easy to branch later

Concurrent Projects (contd.) Conceptually, you now have a single

hierarchically regressed “super-project”

TRUNK

Project I/ Project II/ Project III/ Feature X/

Feature A/ Feature B/ Feature C/

Development A1/ Development C1/

Interoperability Testing

Requires multiple versions in viewAvoid “mixed” views

• Difficult to reproduce

Instead, p4 integrate proj/...@1234 \ proj/1234/...

Forward Integration Failures

In case of conflicting assumptions, determine which codeline is “at fault” (WARNING: may involve politics), and fix it

In case of complex merging, submit extra merging changes to a grandchild codeline, and integrate back to child

A4 – Codeline Automation

Perl, mostly object orientedReusable modules

• P4 form manipulation• P4 command result parsing

~5 person-months, ~22,000 lines• 55% Documentation and test code

http://a-4.sourceforge.net

Conclusions

Evolutionary development is goodUse hierarchically regressed codelines

to sustain incremental progressUse a shared code base for concurrent

related projectsUse A4 to automate codeline

management