* Mark D. Baushke ([EMAIL PROTECTED]) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Paul Sander <[EMAIL PROTECTED]> writes: > > Actually, if you look closely, I believe that CVS will not do read-only > RCS operations if a CVS write-lock exists for the directory. Of course, > ViewCVS and CVSweb do it all the time as do many of the other add-ons.
I'm getting more worried about this one for 2 seperate reasons: 1) There is talk of cvs -n for diff and the like which seems to suggest it ignores locks. 2) I could do with a better under standing of the directory locks; pointers? I've read the top of lock.c but it still doesn't tell me enough; for example there seem to be multiple lock files used - but then surely the creation of them isn't atomic? Or is there one lock file used for both reading and writing? > > There's also the interrupt issue: Killing an update before it > > completes leaves the RCS file corrupt. You'd have to build in some > > kind of crash recovery. But RCS already has that by way of the comma > > file, which can simply be deleted. Other crash recovery algorithms > > usually involve transaction logs that can be reversed and replayed, or > > the creation of backup copies. None of these are more efficient than > > the existing RCS update protocol. > > Agreed. This is a very big deal. Actually I'm becoming less worried by this; I'm failing to see any way that a single system call write() to a block not crossing a block boundary could partially fail; but I'm up for suggestions. Dave -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex / \ _________________________|_____ http://www.treblig.org |_______/ _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
