From owner-freebsd-hackers  Fri Jun  7 19:26:48 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id TAA21163
          for hackers-outgoing; Fri, 7 Jun 1996 19:26:48 -0700 (PDT)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id TAA21106;
          Fri, 7 Jun 1996 19:26:26 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id LAA15013; Sat, 8 Jun 1996 11:25:24 +0900 (JST)
Date: Sat, 8 Jun 1996 11:25:24 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: Terry Lambert <terry@lambert.org>
cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, grog@lemis.de,
        hackers@FreeBSD.org, freebsd-stable@FreeBSD.org,
        FreeBSD-current@FreeBSD.org
Subject: Re: The -stable problem: my view
In-Reply-To: <199606072342.QAA04537@phaeton.artisoft.com>
Message-ID: <Pine.SV4.3.93.960608111806.14546B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

On Fri, 7 Jun 1996, Terry Lambert wrote:

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

Maybe you should provide an example of how multiple reader/single writer
locks can parrallelize a section of kernel code while keeping things
consistent.  The developers can then maybe extrapolate the idea to
improving the CVS commit process in a very *cheap* yet effective way. 

Geeks hate words like (enforce|policy) when it comes to areas that affect
their working style.  But a cool technical idea.....

-mh