From owner-freebsd-stable  Fri Jun  7 16:49:16 1996
Return-Path: owner-stable
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA05202
          for stable-outgoing; Fri, 7 Jun 1996 16:49:16 -0700 (PDT)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA05182;
          Fri, 7 Jun 1996 16:49:12 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA04537; Fri, 7 Jun 1996 16:42:54 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199606072342.QAA04537@phaeton.artisoft.com>
Subject: Re: The -stable problem: my view
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Fri, 7 Jun 1996 16:42:54 -0700 (MST)
Cc: terry@lambert.org, grog@lemis.de, hackers@freebsd.org,
        freebsd-stable@freebsd.org, FreeBSD-current@freebsd.org
In-Reply-To: <17086.834190855@time.cdrom.com> from "Jordan K. Hubbard" at Jun 7, 96 04:40:55 pm
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-stable@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > The problem with CVS is access protocol.  I've suggested (many times)
> > that the way to resolve this is to establish reader/writer locks and
> > a shell script interface for use by committers or other programs, and
> 
> Oh, did I also forget to mention that CVS's locking code is totally
> bogus and slow? :-)
> 
> It takes *two hours* to check out a copy of /usr/src, not to mention
> all the time wasted in locking down the tree during commits (CVS
> crawls through the area you're committing and slaps down lock files
> everywhere, very very slowly).

Gee, if only you had top level reader/writer locks so you could
turn off the per file locking if a global lock was present and
spend about 16,000 less lock/unlock calls.  8-).

> Then there's the wonderful feeling when you've done a whole set of cleanups
> to /usr/src and have to do a "commit from the top" - you wait 45 minutes
> for it to crawl its way through, only to be informed at the end that
> somebody changed a file in some _completely unrelated_ section of the
> tree and now, rather than simply merging it in for you (e.g. this is NOT
> a conflict situation!) CVS aborts and says "I can't go on!".  You need
> to update in the change then start your commit all over again.

Gee, if only you had top level reader/writeer locks that were multiple
reader/single writer to serialize groups of changes over a set of 'n'
files.  8-).


> Sorry, CVS is not my favorite utility.

The problem isn't CVS, it's what you put on top of it.  You might as
well blame RCS for you CVS problems as CVS for your protocol/policy
enforcement problems.  8-).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.