-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dr. David Alan Gilbert <[EMAIL PROTECTED]> writes:
> * Paul Sander ([EMAIL PROTECTED]) 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 cvshome.org will not read a foo.c,v
file while the CVS read-lock or a CVS write-lock is owned by another
process.
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQFCPnPk3x41pRYZE/gRAi8hAJkBOVbkrD8oSF7/tn4BzFl6JWY5yQCfSKop
72vIMJsvjAoBlQA0NRhf25E=
=dWOz
-----END PGP SIGNATURE-----
_______________________________________________
Info-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/info-cvs
