Clarifications: CVS Import Bug Detected

[Oproescu Bogdan (KTXA 3)]

   Hi Todd, 

   Thanks for your message below. A short clarification to your 
   comments below: we don't have 500 users doing cvs imports each 
   day on the same code. Instead, this large project is running 
   parallel Build Servers, which run in a largely automatized way, 
   and these Build Servers may encounter time clashes when importing 
   their build results to the same Modules in their Repositories. 
   
   I said "may" because this error does not occur every time. However, 
   when they will go productive, they intend to increase the number 
   of these parallel Build Servers, thereby considerably increasing 
   the chance of these parallell cvs imports, and therefore also 
   of this File Corruption Issue as a result of this current CVS Bug. 

   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: tdennist@ssa.crane.navy.mil [mailto:tdennist@ssa.crane.navy.mil] On 
Behalf Of Todd Denniston
Sent: Thursday, August 11, 2005 6:18 PM
To: Oproescu Bogdan (KTXA 3)
Cc: 'bug-cvs@nongnu.org'
Subject: Re: CVS Import Bug Detected: - Please Respond

"Oproescu Bogdan (KTXA 3)" wrote:
> 
>    Hi Derek,
> 
<SNIP>
>    I know you have no obligations to us or the CVS Open Source Community
>    to implement the patch you described to solve this, but I would like
>    to ask you to try to implement this for us at your earliest convenience,
>    or eventually ask one of your colleagues who is authorized to make changes
>    to the CVS Source Code to implement this for us.
> 

There are companies out there who do work on CVS and you may be able to
retain one of them to work on this problem if you want it really fast, you
might even be able to put an individual under contract if they are willing.

http://www.google.com/search?hl=en&lr=&q=cvs+contract+version.control&btnG=Search

For example looking at http://ximbiot.com/ there is a link to "CVS Technical
Support Contracts", I am not sure if the contracts listed would cover the
kind of trouble you are having, but it is an example of what is available.

Note: I know Derek Price is highly associated with ximbiot.com (IIRC he owns
it), and I hope I am not stepping on toes by suggesting to look at his
company among others. I have no affiliation with ximbiot.com other than
having exchanged some cvs-info e-mails with Derek, and now that it is
hosting the cvs manual pages (if I understand what happened 02 Aug 2005
09:44:01), I am and will be linking to their site.

<SNIP>
>    I am surprised that no one observed this non-locking behaviour
>    for CVS until now, as a lot of people use CVS, but I hope that
>    with your cooperation we will quickly fix this issue.
> 
<SNIP>
Question, Why are 500 users doing IMPORTs each day on the same code? 

The impression I have always had was that import was used generally for
getting an existing project into cvs the first time, and/or to bring in new
versions of "third party" sources[1]. If your users are modifying the source
(independent of a "third party"), why are they not working in cvs sandboxes
where they do commits and if there is a new "third party" release then only
one person does the import.

I think the reason people have not "observed this non-locking behavior for
CVS until now" is because your use case (multiple imports of the same code
by multiple people at the same time) is unusual. (This all assumes I have
understood your use case, which it is highly probable I have not.)

[1] http://ximbiot.com/cvs/manual/cvs-1.11.20/cvs_13.html#SEC103
http://ximbiot.com/cvs/manual/cvs-1.11.20/cvs_3.html#SEC40
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter