[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea for reducing disk IO on tagging operations

From: Mark D. Baushke
Subject: Re: Idea for reducing disk IO on tagging operations
Date: Sun, 20 Mar 2005 23:12:36 -0800

Hash: SHA1

Dr. David Alan Gilbert <address@hidden> writes:

> * Paul Sander (address@hidden) wrote:
> Hi Paul,
>   Thanks for the reply,
> > Everything that Mark says is true.  I'll add that some shops optimize 
> > their read operations under certain conditions, and such optimizations 
> > would break if the RCS files are updated in-place.
> > 
> > What happens is that, if the version of every file can be identified in 
> > advance (using version number, tag, or branch/timestamp pair) then they 
> > can invoke RCS directly to fetch file versions, read metadata, and so 
> > on.  This sidesteps CVS' overhead and can increase performance by as 
> So are these tricks *never* performed by cvs itself? 

Never? Hmmm... well, the CVS from will not read a foo.c,v
file while the CVS read-lock or a CVS write-lock is owned by another

The real problem is dealing with filesystem errors while RCS is updating
the ,v file. I would not trust that the RCS write manipulations will
always fail in a safe manner.

> i.e. would my trick (if I can solve the interrupted write case) be
> completely safe with any use of cvs as long as you didn't access the
> files externally?

I am not able to say that it would ever be 'completely safe' to do as
you suggest. You would need to greatly harden the failure paths of CVS
to ensure that the file being modified is not just discarded in the
event of a filesystem error by CVS itself. I would not wish to attempt
to do it myself.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]