Next Steps: CVS Import Bug & Patch

[Oproescu Bogdan (KTXA 3)]

   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: bogdan.oproescu@credit-suisse.ch
   Internet: http://www.credit-suisse.ch/de/index.html

-----Original Message-----
From: lawrence.jones@ugs.com [mailto:lawrence.jones@ugs.com] 
Sent: Wednesday, August 10, 2005 9:48 PM
To: Oproescu Bogdan (KTXA 3)
Cc: berndj@prism.co.za; Oproescu Bogdan (KTXA 3); bug-cvs@nongnu.org
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