Mark, Thank you for your clarified and comments. Yes, cvs the lock file is clear up after some seconds. I don't know how long. Maybe 10s or maybe 30s, but my trouble is: the old CVS server from Redhat7.1 with cvs version: cvs-1.11-3 came with Redhat does not cause this lock files problems. Meaning that I do have about 40 developers and 120 Engineers are doing builds, updates, checkin, checkout, but I have not heard complaining for last 4 years about cvs lock. So now, I just migrated to newer Hardware with faster CPU and Disk drive and then cvs lock just pop up. The only thing that trouble me is: to find out does this cause because a newer cvs version cvs-1.11.2-13 has been changed some thing from the last cvs-1.11-3.
I will send out the summary if we find the solution for this. If not I will wait for a newer cvs release. Thank you for your time Mark. C- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Courier <[EMAIL PROTECTED]> writes: > >> I need some help on cvs acting up on my cvs server. Here is what >> happening: >> >> My users are just doing cvs diff or cvs log or cvs update, then they got >> back cvs error: waiting for builder's lock and cvs server tell exactly >> where is cvs PATH file that cause problems. The file name like: >> #cvs.wfl.stein.29903, stein is cvs server name, 29903 is the process id. >> >> One of my developer did ps -ef on cvs server and found this: >> >> #ps -ef | grep cvs >> 29903 ? D 3:33 cvs -f --allow-root=/cvs/cvsroot/Repository >> pserver >> >> So we are looking into D on ps and thinking that may be I/O problems? >> or even network cause cvs system slow down? > > A wfl lock is a write lock such as is used when a user is committing a > change to a file or files in a particular directory of the repository. > It is temporary and is released when the operation has completed. As > long as a process matching the pid on the lock file is present, you are > probably okay. > >> But what I need from you is: does cvs cause problem or some thing else? > > Read http://www.cvshome.org/docs/manual/current/cvs_10.html#SEC88 > >> My cvs server is Redhat9.0 with cvs version from redhat: cvs-1.11.2-13. > > This is valuable. Thank you for including it. > > Your users doing read-only operations like 'cvs diff' may find that > using 'cvs -n diff' will have better performance for them. > > You may find that your users are taking a long time to manually write > the log messages when they do a commit. Suggesting to them that they > write their log message before issuing the cvs commit command and then > pasting the log message into the cvs template or bypassing the template > using the > > cvs commit -F logmsg > > form of the cvs commit command may let you see less time being spent in a > cvs lock state. > >> Also all other build servers we have is P4 1.2 GHZ, but cvs server is : >> dual Xeon P4. Not sure that help, but i throw it out there just in case >> some one may ask. >> >> I did search older archive and found some responded back from Larry >> about >> LockDir may be some where else. We do not have LockDir. Cvs server does >> lock by itself. >> >> Can some one help? > > The problem of write locks gets easier in the development branch of cvs > with promotable locks. You may wish to wait for cvs-1.12.6 as I believe > that there is a case where a core dump occurs with cvs 1.12.5 right now > (it is fixed in the CVS TRUNK). > > Good luck, > -- Mark _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
