From owner-freebsd-hackers  Fri Jun  7 11:28:58 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id LAA08352
          for hackers-outgoing; Fri, 7 Jun 1996 11:28:58 -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 LAA08311;
          Fri, 7 Jun 1996 11:28:48 -0700 (PDT)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA03612; Fri, 7 Jun 1996 11:22:35 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199606071822.LAA03612@phaeton.artisoft.com>
Subject: Re: The -stable problem: my view
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Fri, 7 Jun 1996 11:22:35 -0700 (MST)
Cc: grog@lemis.de, hackers@freebsd.org, freebsd-stable@freebsd.org,
        FreeBSD-current@freebsd.org
In-Reply-To: <15552.834154175@time.cdrom.com> from "Jordan K. Hubbard" at Jun 7, 96 06:29:35 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > I buy most of Jordan's arguments about getting rid of -stable (though
> > I'm not sure why CVS should be the problem.  Sure, I don't like it
> > either, but the way I see it, that's mainly a problem of
> > documentation), and so I'm not going to argue against killing -stable,
> 
> Try using it _seriously_ someday and no explanation will be necessary.
> Suffice it to say that it has absolutely nothing to do with the
> documentation.

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
to require a successful build as part of the commit protocol:

Checkout/merge:

	begin
	cvs lock read
	[ ... checkout ... ]
	cvs unlock
	end

Checkin:

	begin
	cvs lock write
	[ ... checkout/merge ... ]
	[ ... successful build (including any necessary changes) ... ]
	[ ... checking ... ]
	cvs unlock
	<global commit log message required>
	end

Locking protocol (locks are per repository, not global):

	cvs lock read	<--	multiple read locks may be held;
				their effect is to allow other
				read locks and prevent any write
				locks.

	cvs lock write	<---	one write lock can be held; there
				must be no read locks, or the write
				lock will fail.

Yes, this serializes writes to a given repository.  Reads will
*always* return a *buildable* source tree.  Tree copy for SUP/CTM
delta building must be done with a read lock asserted.

The global log message will give the character of a change spanning
multiple files.


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