"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
