Re: Clarifications: CVS Import Bug Detected

[Todd Denniston]

"Oproescu Bogdan (KTXA 3)" wrote:
> 
> 
> 
>    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
> 

Although what Derek has found is obviously a bug, what I was trying to get
at is:
Importing is usually a rare thing to do. And I was trying to understand why
you were repeatedly using import instead of having your users/"build
servers" use commit.

A work around for this bug while waiting for it to be fixed could be the
"normal" way import is worked around, that is:
put the data (and/or directory trees) you want imported into a directory
controlled by cvs and issue:
find . -name CVS -prune -o -exec cvs add {} \; 
cvs commit

see one of Derek's messages to cvs-info yesterday for more info.

Sorry, now I am digging to see if your process might be modified using the
tools you have to give better results.

I don't usually deal with Java (you had .jar files causing problems in
previous emails), so I am trying to recall: Is not .jar the output of a java
compile run? Normally source code is kept under CVS and, unless all you got
from a vendor was the binary, released/delivered output binaries are
normally kept in separate (but process managed) repositories because 1) you
_should_ be capable of regenerating the binaries from the version controlled
source and build tools, and 2) no version control tool _really_ does a GOOD
job of keeping non-diffable binaries.


> -----Original Message-----
> From:  Todd Denniston
> Sent: Thursday, August 11, 2005 6:18 PM
> Subject: Re: CVS Import Bug Detected: - Please Respond
> 
> "Oproescu Bogdan (KTXA 3)" wrote:
> >
> >    Hi Derek,
> >
> <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