Re: Next Steps: CVS Import Bug - Please Respond

[Larry Jones]

"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