Practical Perforce

Channeling the Flow of Change in Software Development Collaboration
Laura Wingerd
O'Reilly, First edition, 2005

Chapter 7. How Software Evolves

p 167
[T]here's more to SCM than knowing how to use an SCM tool.

The Story of Ace Engineering

p 168

The Ace Engineering story illustrates typical problems of the software life cycle [...]

The Mainline Model

p 169
In the Perforce view of software configuration management, one model, the mainline model, is most effective. [...] It's not a Perforce-specific discussion, by the way the mainline model is a concept, not a Perforce feature. But it is the concept on which much of the design of Perforce is based.

From Ideal World to Real World

In the ideal world, there are no bugs, no schedule crunches, no personnel changes, no market shifts, and no technology revolutions. Software in the ideal world is simply developed and released [...]
If there were such an ideal world, we probably wouldn't need an SCM system.
A sad fact of the real world is that the software we develop isn't perfect.

p 170

Development projects are delivered to the mainline as they're completed [...]

p 171

The mainline model is a necessary deviation from the ideal world.

Why We Don't Drive Through Hedges

One has only to look at traffic on a freeway to see why entrances and exits are controlled. Clearly driving would be inefficient and unpredictable if they weren't. [...] Think of the mainline model as the freeway system of parallel development.

The Flow of Change

p 172
The closer we are to the ideal world, the simpler our SCM is.
Release Codelines
This doesn't compromise the mainline, because every change coming from a release codeline has already been reviewed and tested. Moreover, release codeline changes are changes that fix broken things. Thus, merging release codeline changes to the mainline is bound to have a stabilizing effect. It brings the mainline closer to perfection [...]

p 173

[...] the mainline is changing constantly—it will never be perfect.
If we're in the unfortunate position of having to support several releases concurrently, a bug fix in one release may have to be applied to another. That is, we'll have to cherry-pick a change from either a release codeline or from the mainline and integrate it into another release codeline.
Development Codelines
There's also a constant flow of change from the mainline to the development codelines branched from it [...]
[...] the mainline is guaranteed to be stable [...]

Containerizing

p 186
A truck driver doesn't know he s delivering 19 sofas, 400 chairs, and 80 tables to outfit a hotel in New York. All he knows is that he s delivering one shipping container from the factory to the shipyard. And when he arrives at the shipyard, he doesn t throw open the back of the truck and start counting out sofas. He merely checks that the container is intact.

It s the same with branching and merging. The software we re working on involves far too many files for us to have to branch and merge them individually.

Modules

At face value, a module is simply a set files organized in a directory tree.

Chapter 7,
Software
Marc Girod