Date: Mon, 9 Dec 1996 17:33:04 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jsigmon@www.hsc.wvu.edu (Jeremy Sigmon) Cc: terry@lambert.org, j@uriah.heep.sax.de, chat@freebsd.org Subject: Re: siguing into current from a random version Message-ID: <199612100033.RAA02380@phaeton.artisoft.com> 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
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612100033.RAA02380>