Hello Mark,
Thanks for your message below. We've encountered these stale CVS locks in the past quite frequently on our CVS Central Server, and we are used to regularly cleaning these CVS Locks as a result. If the situation gets very messy for many Modules and Repositories, we can delete all these involved CVS Lock Files, and then we have our own script to regenerate them all back again ( repository list traversal ) in only a few seconds. Cheers, Bogdan Bogdan Oproescu CREDIT SUISSE FINANCIAL SERVICES Technology & Services Advanced Middleware & Development Environments KTXA 3 Postfach 600 CH-8070 Zürich Tel.: +41 1 334 6846 Fax.:+41 1 332 8024 E-Mail: [EMAIL PROTECTED] Internet: http://www.credit-suisse.ch/de/index.html -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: Thursday, August 11, 2005 7:07 PM To: Derek Price Cc: Oproescu Bogdan (KTXA 3); '[email protected]'; 'Bernd Jendrissek'; Larry Jones Subject: Re: Clarifications: CVS Import Bug - Please Respond -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Derek Price <[EMAIL PROTECTED]> writes: > Bogdan, > > The problem is that neither lock is working. If CVS's directory-level > locks were in place, you would see no problems at all. If only the RCS > locks were in place, you might occassionally see change sets get > overwritten, but you should see no file corruption. > > As for why the RCS locks are not working with your NFS implementation, I > cannot really tell you, except to say that NFS file locking is > notoriously unreliable, which is why CVS uses its own style of directory > level locks in the first place, and we generally recommend that CVS > repositories not be stored on NFS servers. IIRC, many of the problems > stem from using non-homogenous sytems, e.g. a Solaris NFS Server and a > Linux NFS client, or a NetApp accessed from a client it was not tested > thoroughly with. I do know of several companies out there that do store > their CVS repositories on NFS servers without problems, but as I > understand it, they are using high-end NetApps fully tested with their > NFS clients. Even in this case, you are asking for trouble unless you are still using client/server access to focus transactions between the NetApp and a single cvs server. > > Other problems that have been reported stemming from non-homogenous NFS > setups include random NUL bytes inserted in files on commit. Don't know > if there are others. To be fair, most of the NUL bytes problems have been tracked down to not having UDP checksums properly enabled throughout the network. There have been occaions where the checked-out user trees on NFS have seen NUL bytes for this reason as well. Other NFS problems have included an excessive number of 'stale' CVS locks when clients terminate and some odd race conditions with more than one user trying to create write locks in the same directory at the same time both believing they have obtained their exclusive lock. Users that must use a SAN or NFS data store for the repository are urged to use a client/server model with only one server acting on the data store. -- Mark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFC+4WYCg7APGsDnFERAp7mAJ4kIckQ1vvLELXw/N1ZzTzXofk8tQCdGdvk euUWX+mmBm1l6a5tY9vldrQ= =lqrk -----END PGP SIGNATURE----- _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
