[MUD-Dev] Version Control (was: DBs and Events)

[coder at ibm.net]

On 20/02/98 at 01:47 PM, Vadim Tkachenko <vadimt at 4cs.com> said:
>coder at ibm.net wrote:

>CVS announces itself as a wrapper for RCS, as it goes from the docs I
>managed to read so far, you can keep the repository as a single entity
>instead of multiple RCS files.

The following is a commentary on CVS vs PRCS from Stig, one of the Xemacs
programmers (off-topic I'll admit, except for the fervent hope that we all
have our source trees under some form of version control):

--<cut>--

Date: 28 Feb 1998 02:35:25 -0000
Message-ID: <19980228023525.12103.qmail at hackvan.com>
To: "Larry M. Augustin" <lma at varesearch.com>
Cc: svlug at svlug.org, prcs-list at scam.xcf.berkeley.edu
Subject: [svlug] Re: CVS vs PRCS (the "really bad" vs. the "not done yet")
From: "Stig HackV n" <stig at devlinux.com>

Larry M. Augustin wrote:
> 
> PRCS doesn't understand NIS.

What's involved?
Isn't that just a problem of building against the wrong library? 

> PRCS doesn't understand client/server.

Not yet, but it's planned for "real soon now."  Not all applications
require client/server, even though it is the hot buzzword.

CVS doesn't understand file name changes and file removals.

CVS has a really bone-headed "vendor branch" mechanism that causes a
perpetual hell of unnecessary merges once

CVS is really incredibly SLOW.  If you tag a version of a big source tree
(like XEmacs, for instance), CVS will have to rewrite every single file in
the whole repository in it's entirety.  Does such a conceptually simple
operation really warrant the pushing-around of 120 megabytes?

CVS is a DOG.

http://www.XCF.Berkeley.EDU/~jmacd/cvs-vs-prcs.html
http://www.XCF.Berkeley.EDU/~jmacd/kingdon.html

> Maybe someday PRCS will be able to replace CVS, but not today.

Problems with the broken meta-data in CVS repositories are enough reason
to use PRCS right now, so long as you can wait a while for client/server.

Also, PRCS handles meta-data more efficiently than CVS and claims 2X-6X
performance gains for most common operations.  It does have one
pathetically slow operation that can probably be more accurately be
described as a lingering bug than a design problem, but that's just the
initial checkin.

http://www.XCF.Berkeley.EDU/~jmacd/speed-comparison.html

> 
> Larry
> 
> stig at hackvan.com writes:
>  > mfw at datamain.com wrote:
>  > > 
>  > > cvs    - 44,000 files in the web content tree with known versions and
>  > > 	 dependencies, automatic html/gif "promotion"
>  > 
>  > CVS does a very poor job of handling binary files.  And it's really slow on
>  > large repositories (like XEmacs, for instance) for conceptually simple
>  > things (like adding a tag)...all because it's indecently and shamefully tied
>  > to RCS file formats.
>  > 
>  > Take a look at PRCS:  http://www.XCF.Berkeley.EDU/~jmacd/prcs.html
>  > It has some rough edges, still, but it's in many ways superior to CVS.
>  > I recommend avoiding CVS unless you're absolutely stuck with it already.
>  > 

--<cut>--

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...