Frederic Brehm writes: > > The technical reason for the failure has to do with locking in the > repository. Locking is a tricky thing to do in a distributed system. > Implementations often have subtle bugs.
A number of people have now said that and, while it may be true, it doesn't apply to CVS. CVS's locking scheme ensures that only one process is writing to a repository directory at a time, even across network filesystems. The only known potential failure mode, which has never been reported as actually occurring, results in *eveyone* being locked out of a directory, not allowing two servers to write at the same time. No, the problem is just that network filesystems, particularly those that run over unreliable connections like NFS traditionally does, are extremely tricky to get right. They're even trickier when you don't control both ends of the connection, as when the client software is supplied by a different vendor than the server software. All the problems I've seen seem to be either handshaking bugs -- where the client and the server don't communicate reliably -- or simple housekeeping bugs in the server -- where data intended for the disk never actually gets there. Why CVS should be so good at triggering these problems, I don't know. I do know that the commercial CAD/CAM/CAE system my employer produces is also good at triggering them, though. -Larry Jones These pictures will remind us of more than we want to remember. -- Calvin's Mom _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
