Todd Denniston writes:
>
> Telling CVS on each machine that it accessing the repository on
> a physical (local) drive so that all lock files are being cached
> in the local machines File System cache. However the case is
> that the lock files are being cached locally, network latency
> added, and finally being put in the actually distributing
> computer's cache to be checked by other cvs clients. This
> allows a race condition to exist where one client may not know
> another has a lock and so it can (insert bad thing) which
> corrupts or causes other problems with the repository.
As far as I know, this is not a problem. CVS uses the existence of
files and directories for locking, it is not concerned with their actual
contents. The problem is simply that network file systems are very
complex and thus subject to lots of bugs. Particularly interoperability
bugs where the client and the server are from completely different
implementations. A client and server from the same implementation
almost always work perfectly together. Clients and servers from
different implementations frequently have problems.
-Larry Jones
Pitiful. Just pitiful. -- Calvin
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs