[P4] Using P4 to help control build breakage

[Richard Geiger]

> Has anyone had a similar problem?  If so, how was it resolved?  Did anyone
> try a code promotion model to solve this?  I've heard source control systems
> like ClearCase can track build dependencies and supply users with derived
> files (such as OBJs, PDBs, EXEs, etc.) when a user wants to sync to a
> verified set of source.  Has anyone explored getting a similar
> implementation in Perforce?

We have a system built (by Robert English, who deserves kudos for it),
around Perforce, that helps with these problems.

To attempt to put it into a nutshell:

  A "build daemon" process, the owner of a client workspace for the
  codeline in question, wakes up every ten minutes or so and checks to
  see if any new changes have been checked in (via "p4 sync")

  If files have changed, it runs an incremental make

  If the build fails, it files a bug with the defect tracking system,
  andq sends mail to the submitters of all the changes it just synced
  into the client workspace

    ... which helps us to know sooner rather than later when breakage
    has happened (of course, we, uh "encourage" developers to self
    check thier changes with private builds before submitting them,
    but Stuff Happens.

  Now, the really cool stuff:

  The build daemon, in effect, maintains caches of the sources and
  "derived objects" (notably, the .o's) for every change level that it
  has done a build for; it implements a "lazy copy" sort of thing
  using Unix hard links, to prevent vast diskspace inefficiencies.

  Now, there are other commands that developers can use to rapidly
  create a new client workspaces at any build-daemon-built change
  level, **** pre-populated, via hard links to the cached sources and
  .o's ***.  (One limitation is that the developer workspaces have to
  be in the same filesystem as the build daemons, but that's a
  managable requirement for us).

  This allows a developer to very quickly get a new workspace synced
  to one of these change levels, which is, in effect "pre-built".
  They can then make an incremental change, and only recompile sources
  that have changed, relink, and then test. This reduces a operations
  that would otherwise take well over an hour (last I looked), to
  something like 5 minutes.

This glosses over some complications, but describes a very real and
useful approach that, I think, addresses the kinds of problems you
describe.

I think of it as providing 95% of the benefit of ClearCase Derived
Objects, but using Perforce, at 5% of the cost (in processing
horsepower, "ClearCase server fingers in the pie", etc. - not just
licensing costs!)