"Arthur Barrett" <arthur.barrett@march-hare.com> wrote in message news:mailman.723.1179284152.32220.info-cvs@nongnu.org... Quin An, > My client is Concurrent Versions System > (CVS) 1.11.5.1 (client) on WinXP. > Most people on XP use CVSNT (Free/GPL just like CVS). > TortoiseCVS and WinCVS both include it as the default client. Well, I get the exact same error when trying to commit large numbers of files in a single commit (like when I want to add/commit the latest version of Boost to my repository). I use CVS 1.11.22 (the latest stable branch) on both server (FreeBSD) and client (Win32). I don't use WinCVS (yuck) but TortoiseCVS also has the same problem. At least now I can see that I am not the only one experiencing it. I worked around the problem by writing a script (batch file) that recursively processes the folders and invokes a command (such as 'cvs ci -m "my commit message"'). This keeps the commits small enough to avoid the problem. My batch file looks like this: @echo off if "%1" == "" ( echo Missing command. echo Syntax: recurse_do [command] goto :eof ) setlocal for /D %%D in (*) do ( if not "%%D" == "CVS" ( REM echo Entering %%D... pushd %%D call recurse_do.bat %* %* REM echo Leaving %%D... popd ) ) %* ..which I invoke like this (from the top level folder) recurse_do cvs ci -m "my commit message" - Dennis

"Arthur Barrett" <arthur.barrett@march-hare.com> wrote in message news:mailman.757.1179374371.32220.info-cvs@nongnu.org... Dennis, >> ...which I invoke like this (from the top level folder) >> >> recurse_do cvs ci -m "my commit message" >> >Inventive workaround, but the problem just shouldn't be occurring - >millions use this software and I've never heard of this problem. If it >occurs with both the CVSNT client and the CVS client then it's most >likely the server. However before making that leap of logic, check that >choosing TortoiseCVS->About shows CVSNT as the client. If not - upgrade >TortoiseCVS to the latest release (and find and remove that old version >of CVS from the PATH). > >You can trace any operation using -ttt, eg: cvs -ttt ci -m "" > >Hopefully the trace will give you some clues, if not you can set >CVS_CLIENT_LOG on the client to get a trace of the actual protocol >(google for the exact syntax). Arthur, I agree, it should not be happening at all. I have the latest stable release of CVS [version 1.11.22 as both client (Windows) and server (FreeBSD)], and I have the latest TortoiseCVS (version 1.8.31). When I check the About box for TortoiseCVS, it says it is using CVSNT, but whether or not it is _actually_ using CVSNT, I have no idea. Does it need to be in the path, or does Tortoise know how to retrieve it apart from the system path? My non-CVSNT client is the one that is in my path. I have been using CVS for about 12 years and managed my own server for 7, and this is the first time (that I can recall) that I have ever experienced this error. It only happened when I tried to add and commit the Boost 1.34.0 library. Interestingly, I had added Boost 1.33.1 some time ago with no problem whatsoever. I do not believe that I have updated the version of CVS (either client or server, since I always upgrade both together) since that time, so the fact that the error is occurring only now, and only with the Boost 1.34.0 library, is very strange indeed. The only thing that was different this time was that I was attempting to perform my commit via my development machine over a Remote Desktop connection (because I was away from home at the time). However, since my development machine has direct access to the CVS server on the local network, I doubt the problem is between the two machines. I don't think the error is in the router or the switch (my external connection is only 2Mb, while the local connection is 100Mb), so I don't think collisions are the cause, especially since the error occurred in the same folder every time. I am still stumped, but at the moment I am not particularly concerned. Unless it happens again, or (more importantly) unless my clients who also use the server start complaining, I am not going to worry about it. - Dennis

"Miller Dale C Ctr AFWA/SEMS RM 11-34" <millerd@afwa.af.mil> wrote in message news:mailman.980.1179840508.32220.info-cvs@nongnu.org... Are you using a CVSROOT/taginfo_filter? It will have a problem if using a client against a large number of files. Look at this archive message http://lists.gnu.org/archive/html/info-cvs/2002-02/msg00265.html No, my taginfo file is empty. - Dennis

"Arthur Barrett" <arthur.barrett@march-hare.com> wrote in message news:mailman.970.1179833352.32220.info-cvs@nongnu.org... >> I agree, it should not be happening at all. I have the latest stable >> release of CVS [version 1.11.22 as both client (Windows) and server >> (FreeBSD)], and I have the latest TortoiseCVS (version >> 1.8.31). When I > > TortoiseCVS only works with CVSNT and includes it - if you want to keep > your server and client versions in sync as you suggest then you should > upgrade the server to CVSNT (yes it does run on linux). I'm not going to convert the server to CVSNT -- it's too big of a risk, and converting doesn't buy me anything. >As I indicated before - sounds like a server issue, but without a trace >it is impossible to tell. It could be, but since it has never happened before (never in 7 years) and since it seems to be a relatively unusual case, I'm not going to worry about it. - Dennis