[p4] Guidelines for codelines?

[Chuck Karish]

As several people have hinted the question here is the
design of the development process.  Source control is an
implementation mechanism.  I think of this as a data flow
problem: how does a change get from the developer's
workspace to the finished product with the least effort and
the fewest surprises?

What source control strategy works for your team depends
on their development style.

Here are three examples I've worked with:

1) Large team, six-month development cycle:

  The rate of change was fast enough that working on main
  produced frequent conflicts and build breaks.  Solution:
  Move all non-trivial changes onto development branches.
  Use main only to receive integrates from development
  branches. Allocate each team a two-day window every three
  weeks to integrate their changes back to main.  Fail to
  re-stabilize main after your integrate and you have to revert
  and wait for your next slot.

  Pluses: The main code line  never got too far from being
  stable.

  Minuses: Each team's tech lead had to spend several hours
  every other morning integrating other teams' changes to their
  team's development branch.  Integrates to main were difficult
  and stressful because they were so large; the integration
  schedule was called the "Wheel of Death".

2) Small team, one-month development cycle:

  All development was done on a development branch shared
  by all developers. A tracking bug was assigned for each feature.
  When it was time to release management chose which features
  should be delivered and the developers integrated the changes
  for those features to main, using the per-feature bug numbers that
  were burned into the change descriptions.

  Pluses: Simple branch model.  Forward development rarely
  interfered with releases.  Developers found and resolved conflicts
  early.

  Minuses: Some fiddlin was required on the release branch when
  a file was modified for multiple features.

3) Large team, short release cycles:

  This team used what they called an agile model in which everyone
  worked on main.  It was expected that main was always buildable
  and always releasable.  Breakage was flagged early by elaborate
  pre-submit test servers and by continuous build-and-test daemons.

  When it was time to begin a release cycle the source for the product
  to be released was integrated to a release branch along with all of
  the code on which it depended.  If build, test, and QA on the branch
  revealed any problems individual changes to repair the problems
  were integrated from main to the branch.

  Pluses: Developers don't have to maintain development branches.
  Developers see and resolve conflicts early, which eliminates
  painful large integrates at release time.

  Minuses:  Heroic measures are needed to keep the main code line
  stable.   This strategy worked only because the developers were
  very smart and very responsible.

-- 
Chuck Karish   karish at well.com   (415) 317-0182