[P4] Using P4 to help control build breakage
rmg at netapp.com
Fri Jul 21 11:16:35 PDT 2000
> 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
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
More information about the perforce-user