We had this problem on a BSD box here. Turns out there were some restrictions in place on how much swap space a user program could use, and cvs was exceeding it. Our IS guy made some changes on the machine and it solved the problem. Dave on 1/9/01 2:54 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > > One of my users complained she got this message whenever she checked out or > updated in her module. I found that she had committed two of her binaries; > one was 11Mb, the other was 7Mb. When I removed those files, the > checkout/update worked. > > I am running cvs 1.11 pserver with "-T /tmpcvs", where /tmpcvs is a 3Gb > filesystem. There is 2Gb of RAM on the server, which is HP 10.20. /tmp is > 1.1Mb (but I hope it isn't being used). The "xxx bytes" that can not be > reallocated seems to be fixed depending on what file I am trying to checkout. > For the file of size 11,456,355, xxx is 21968. For the file of size > 7094501, xxx is 14262. > > Funny thing is, there are larger files that I *CAN* check out without a > problem. What appears to be a distinguishing feature is that they only have > a single revision in the tree (1.1). In fact, I can checkout 1.1 of the 2 > files that gave me trouble above. > > So I'm guessing that CVS is running out of something while trying to > reconstruct revision 1.4 (in the above example). Is it really memory, or > could it be temp disk space (which I was hoping would be /tmpcvs, as > specified on the inetd.conf command line, and not /tmp)? This might sound > like a stupid question, but I thought I remember a problem with the size of > the history file that also caused this message to appear. Wait. I seem to > remember something about the maximum amount of memory an application is > allowed to request..... _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
