From owner-freebsd-chat  Mon Dec  9 16:54:42 1996
Return-Path: <owner-chat>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id QAA20351
          for chat-outgoing; Mon, 9 Dec 1996 16:54:42 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id QAA20342
          for <chat@freebsd.org>; Mon, 9 Dec 1996 16:54:40 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA02380; Mon, 9 Dec 1996 17:33:04 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199612100033.RAA02380@phaeton.artisoft.com>
Subject: Re: siguing into current from a random version
To: jsigmon@www.hsc.wvu.edu (Jeremy Sigmon)
Date: Mon, 9 Dec 1996 17:33:04 -0700 (MST)
Cc: terry@lambert.org, j@uriah.heep.sax.de, chat@freebsd.org
In-Reply-To: <Pine.BSF.3.91.961209190821.29867C-100000@www.hsc.wvu.edu> from "Jeremy Sigmon" at Dec 9, 96 07:11:14 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-chat@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> > Voila, we have destroyed all of the rocks behind which tree-breakers
> > can hide.  If person A breaks the tree, it will be obvious that it
> > is person A's fault, and the breakage can always be trivially undone
> > by backing up one write-lock-label.
> 
> As an aside.
> At work we would use RCS to check in and out web pages so we would not 
> step on each other.  This worked until someone checked out a bunch of
> pages that they were "working on" and a few typos needed to be fixed.
> This locking feature quickly became annoying.  :(
> I can definately see why the "volunteers" don't want to enable this.

The locks do not need to be held during checkout or modification, only
from the time that you start an update following edits until it compiles
correctly:


        begin
        lock r
        cvs update
        ulock <------------------------.
        local edits <------. <-------. |
        local test --fail--'         | |
        local test success           | |
        lock r                       | |
        cvs update                   | |
        ulock                        | |
        update changed files? --yes--' |
        update did not change files    |
        lock w                         |
        cvs update                     |
        update changed files? --yes----'
        update did not change files
        cvs ci
        ulock
        <enter global comment(s) into lock log>
        end

The problem you had with RCS was that multiple reader/single writer
locks are not what RCS does.

Alternately, you could hold off on the middle lock r/update loop, and
let the writer hold the lock until it tests ok.

Typically, you will only have collisions if people are modifying the
same files, and then only if they are the same files in the same
regions (ie: cvs update results in a "C" -- collision).


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