Front page | perl.bootstrap |
Postings from July 2000
Re: Perforce vs CVS
From: Adam Turoff
July 26, 2000 00:02
Re: Perforce vs CVS
Message ID: 20000726030157.B13068@panix.com
On Wed, Jul 26, 2000 at 01:03:08PM +1000, email@example.com wrote:
> I'd hate to see us create a barrier to entry which discourages people
> from reading or contributing to the perl source.
> I'd like to hear some discussion on the following points:
> - what Perforce offers that CVS doesn't
> - how important or beneficial these features are to Perl
> - what a developer needs to do/learn/etc to move to Perforce from CVS
> and how much of a barrier to entry it would be
> - what are the social/PR implications of choosing Perforce and what will
> their impact be?
Talking to Sarathy tonight, I've heard him mention the following points
in favor of Perforce:
http://www.perforce.com/perforce/cvs.html contains a fairly
accurate comparison to CVS (Simon mentioned this as well)
Perforce is very flexable and customizeable. (This comment was
prompted by asking about customizeable RCS tags in CVS; Perforce
keeps the metadata separate from the actual source files which
Sarathy considers to be a benefit.)
Perl already has an open source license for Perforce, which allows
20 users to access the repository. There are currently ~9 users,
of which only ~4 are active. Creating an anonymous user is not a
Anonymous read-only access to the repository *is* available, or at
least it is easily configured.
perforce clients are available for most major platforms. This is
detailed in http://www.perforce.com/perforce/loadprog.html#plats
rsync access to the source repository is available, useful and
The CVS gateway is a doable option. There are many ways to
accomplish this, such as Barrie Salymaker's Safari project,
Simon's Perforce replacement as well as writing a few scripts to
rsync a CVS directory to Perforce and committing changes once an
day (or more frequently if desired).
perforce is a *good* tool. It would be a shame to jettison the
best tool for the job because of political issues or lack of
Three-way merges are a technical requirement to merge two branches.
Perforce is better because it allows merges on a change-by-change
basis rather than an all-or-nothing merge between two brances (as
Perforce uses RCS's delta format internally.
Perforce is amazingly fast and can track a stupendous amount of
source files in one project: ~100,000 or more.
Perforce has no native network security model. Security is handled
through ssh and other such tricks.
Perforce requires server storage for every *client* that has
checked out the sources. CVS keeps this metadata locally on the
client side, whiel Perforce keeps track of what each client
checkout has checked out most recently. This can impose a large
storage requirement on a public access Perforce server; using rsync
provides the same functionality without the overhead or performance
As usual, these are the issues as I understand Sarathy's explanations. Any
errors are my own. Any misstatements or misrepresentations are my own.