Re: Perforce vs CVS

Front page | perl.bootstrap | Postings from July 2000

Thread Previous | Thread Next

From:

Adam Turoff

Date:

July 26, 2000 00:02

Subject:

Re: Perforce vs CVS

Message ID:

20000726030157.B13068@panix.com

On Wed, Jul 26, 2000 at 01:03:08PM +1000, skud@netizen.com.au 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 
	problem.

	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
	efficient.

	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
	awareness.

	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
	CVS does).

	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.

Downsides:

	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
	penalty.

As usual, these are the issues as I understand Sarathy's explanations.  Any
errors are my own.  Any misstatements or misrepresentations are my own.

Z.

Thread Previous | Thread Next