Public Access to Perforce?

Robert Watson rwatson at
Wed Aug 18 08:33:08 PDT 2004

On Wed, 18 Aug 2004, Richard Coleman wrote:

> Very well said.  And very useful since reading this helps me to
> understand better what is going on behind the scenes. 
> At some point in the future, it would be nice if this type of local
> experimentation and the mainline were brought under the same
> infrastructure (subversion/whatever).  But I don't think there is any
> hurry since the current setup doesn't appear to be an obstacle. 

Yeah, the trick is finding the right tool.  The FreeBSD CVS repository is
imported in full (pretty much), and updated in the Perforce repository
every couple of minutes.  Exporting to CVS is a bit harder because CVS has
trouble representing many of the more complex branching notions
efficiently (the cvsup export of for TrustedBSD is
much larger than the storage for the Perforce version of the same).  A
first test for any open source replacement for CVS in the FreeBSD project
is that it be able to import our current history and workload efficiently. 
I believe last time this was attempted with Subversion, the importer ran
at least a month before the person trying it gave up :-).  Once a piece of
software has been found that can have the complete history imported and
handle our iterative workload from CVS commits, then the question becomes
whether our development strategies can be mapped effectively into its
capabilities: i.e., use of tags and branches for release engineering, etc. 

We need to periodically reevaluate the choices; the next logical point to
do that is probably the next Subversion release, since it seems to be a
popular suggestion for an alternative.  It's worth noting that the Linux
community has run into much the same problem: currently, they're using
BitKeeper, a similar commercial product, for much the same reasons.  svk
is another promising looking alternative, but no doubt there are many
others.  The limitations of CVS are well known, and fairly well
understood, but revision control software (especially supporting highly
parallel, high volume development) is up there with OS programming in
complexity :-).  And as with OS programming, you put your source history
in your most stable version, not your development head with the latest
experimental changes.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at      Principal Research Scientist, McAfee Research

> Richard Coleman
> rcoleman at
> Robert Watson wrote:
> > On Tue, 17 Aug 2004, David Rhodus wrote:
> > 
> > 
> >> With the perforce trees being hidden away without public access to
> >> the changes, this makes the FreeBSD project no longer an open
> >> source project.
> > 
> > 
> > That comment seems to be in stark contrast to reality.  One of the
> > most important goals in using Perforce to supplement CVS has been to
> > get developers to stop keeping weeks or months of "in progress"
> > changes solely on their notebook or workstation, and to increase
> > collaboration opportunities among developers.  Previously, developers
> > would maintain large oustanding change sets on local machines as they
> > developed features that were too "in progress" to merge to the main
> > tree.  This presented a risk to the project: by not maintaining this
> > source on backed up systems, the chances of accidental deletion or
> > loss, theft, crash, etc, were unsettlingly high.  By providing access
> > to a Perforce repository for personal or small project use, we've
> > allowed developers to move personal development off of local and
> > potentially unreliable systems onto a centrally manged "work in
> > progress" server with revision control.  If this weren't enough, the
> > benefits of having three-way merging to better maintain and update
> > "in progress" work with local revision control have improved
> > efficiency and collaboration.
> > 
> > As already pointed out, most if not all of the interesting "in
> > progress" work in Perforce is regularly and mechanically exported as
> > patch sets or via cvsup by the developers, something they can now do
> > much more easily now than they could before.  Most of the major group
> > work going on in Perforce is exported via cvsup10 (TrustedBSD, etc).
> > In addition, many developers post regular patch sets of the remaining
> > work (SMPng, ...) to mailing lists or personal/project web sites.
> > For example, instead of hosting the TrustedBSD work on an independent
> > CVS server and having to maintain separate infrastructure, the
> > TrustedBSD work is hosted on the FreeBSD Perforce server, making its
> > source trees accessible via FreeBSD's cvsup infrastructure.  When you
> > subscribe to the TrustedBSD CVS list, you actually get a feed of the
> > Perforce change sets from the TrustedBSD section of the FreeBSD
> > Perforce repository.
> > 
> > I think you'd have to work fairly hard to find open source projects
> > that have no ouststanding local patch sets of as-yet uncommitted and 
> > experimental changes; by providing a central infrastructure to manage
> >  this, we're helping developers to avoid loss and collaborate
> > better/more. Local and experimental changes are a necessary part of
> > the development process for any reasonably large project, as the
> > software mainline requires greater stability than the stability of
> > every work in progress. CVS is notoriously poor at providing for this
> > sort of branched development capability; while I know there's
> > interest in other open source revision control systems to play the
> > role Perforce is currently playing, attempts to import the FreeBSD
> > revision history into other open source systems have generally failed
> > due to the volume of changes and history present in the FreeBSD
> > project.  Undoubtably, people will keep trying until an open source
> > revision control product is up to it.
> > 
> > The unavailability of the web site is due to
> > bugs in the older version of the Perforce web server, and that the
> > software has not yet been upgraded.  Hopefully that will be fixed
> > soon, as that site was beneficial to everyone.  However, I'm having
> > trouble thinking of much or any on-going work in Perforce that
> > doesn't get merged rapidly or made available via other means.  If
> > there's specific work you are interested in that isn't exported, I
> > can make it available to you easily.  I believe the general purpose
> > submit list is also subscribable, although the volume of local
> > changes is extremely high due to their "in progress"  nature.
> > 
> > Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects 
> > robert at      Principal Research Scientist, McAfee
> > Research

More information about the freebsd-current mailing list