Re: Idea for reducing disk IO on tagging operations

[Dr. David Alan Gilbert]

* Mark D. Baushke (address@hidden) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Paul Sander <address@hidden> 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   |_______/