Hi Larry,
Thanks for your message below. Our CVS Clients are configured to access the Repositories using Client/Server Mode through our CVS Central Server, and all our Lock Files are in /tmp/cvslocks/<rep_name> on this server, so they are shared by all CVS Clients using this machine. I think, actually am quite sure, that Derek Price found the actual problem in the CVS Source Code in his earlier emails. We would greatly appreciate a CVS Patch to solve this! 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] Sent: Wednesday, August 10, 2005 9:48 PM To: Oproescu Bogdan (KTXA 3) Cc: [EMAIL PROTECTED]; Oproescu Bogdan (KTXA 3); [email protected] Subject: Re: Next Steps: CVS Import Bug - Please Respond "Oproescu Bogdan (KTXA 3)" writes: > > since "import" is not atomic, there is no lock > created for some Module when imported, so another parallel "cvs import" > on the SAME Module & Repository pair would conceivably corrupt the .jar > file. No, atomicity and locking are disjoint concepts. Import, like most CVS commands, locks each directory in turn as it is processed, so two simultaneous imports should not be able to manipulate files in the same directory at the same time. > Our data on our CVS Central Server at Credit Suisse is on our SAN > ( Storage Area Network ), and our CVS Lock Files are stored in > /tmp/cvslocks, which greatly improves performance, but I'm not sure > if this is relevant to these CVS Bugs. It looks to me like you have your clients configured to access the repository directly rather than using client/server mode to access it through the server. If so, each client would have its own lock directory and thus not notice other clients' locks. If you're not going to keep the locks in the repository, then it is vital that you configure your SAN so that only the CVS server is able to access the repository to prevent that kind of misconfiguration from corrupting it. It's also worth noting that we strongly advise keeping the repository on locally mounted storage rather than any kind of network storage. Nearly every report of repository corruption we've received has been tracked down to network file system interoperability bugs. That said, SANs -- like other dedicated file servers -- are much less likely to exhibit such bugs, particularly if you limit your access to a single system (or at least a single type of system), so you're just barely across the line of advisability. -Larry Jones I don't like these stories with morals. -- Calvin _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
