Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Did as you suggested and on the WinCvs where the update is being done nothing happens, it just hangs there. If I look at the server in Task Manager I can see a cvs.exe that is stuck. Clicking the red stop button brings WinCvs back, but the cvs.exe process is still there on the server. And in the repository there is now a file named #cvs.rfl.antares(bosse).576 that was not there before. I could delete the file, but the process is still there. So I did this: C:\Programs\Reskit>kill cvs.exe process #576 [cvs.exe] killed Sure enough the cvs.exe that hung is process Id 576... Next test, do the update from command prompt with the -t flag: F:\Engineering\Antares\PC\ModuleXX>cvs -t up -> Tracelevel set to 1. PID is 2560 -> Session ID is a003e457fca3aa5 -> main loop with CVSROOT=:sspi:antares:/pc ? ChangeLog S -> Checking admin file C:/cvsrepo/pc/CVSROOT/admin for user bosse cvs server: Updating . S -> rename(CVS/Entries.Backup,CVS/Entries) S -> rename(CVS/Entries.Extra,CVS/Entries.Extra) S -> unlink(CVS/Entries.Log) S -> unlink(CVS/Entries.Extra.Log) S -> unlink(CVS/,,FourthFile.txt) S -> checkout (/pc/ModuleXX/FourthFile.txt,v, 1.1, , (function)) S -> unlink(CVS/,,FourthFile.txt) S -> unlink(CVS/,,FourthFile.txt-1) S -> unlink(CVS/,,FourthFile.txt-2) S -> checkout (/pc/ModuleXX/FourthFile.txt,v, 1.2, , (function)) Here it stays forever until I kill the server process: cvs [update aborted]: end of file from server (consult above messages if any) So it for sure looks like a bug. When did it appear? (From which cvsnt revision?) And will increasing the buffer size to 16 times the original size not just push the file size up by 16 but still leave us with this problem on large files?? /Bo On Sat, 8 Feb 2003 06:37:16 -0500, "John Goehringer" <john.goehringer at agilisys.net> wrote: >Bo - make a change to one of the 9k sandbox files, commit >then try to update in the other sandbox to get the change. > >Thanks, >John Goehringer > >"Bo Berglund" <bo.berglund at telia.com> wrote in message >news:skc94v837nh7rgceg6cn54g3202kvcsrri at 4ax.com... >> On Fri, 7 Feb 2003 20:14:32 -0500, "John Goehringer" >> <john.goehringer at agilisys.net> wrote: >> >> >Found that trying to update a sandbox with a changed file from >> >the repository that is 8170 (or so) bytes or larger fails, either >> >with cvs crashing, or the server returning the message >> >unexpected '\\xn' reading revision number in RCS file ... >> > >> >Changing RCSBUF_BUFSIZE from (in rcs.c) >> >(8192) to (8192*16) seems to make the 8k test >> >work. >> > >> >To reproduce >> > >> >create new text file >9k bytes long >> >add to repository >> >checkout into dir1 and dir2 >> >change in dir2 directory and commit >> >try to update from dir1 >> > >> >Thanks, >> >John Goehringer >> > >> Not reproducible here... >> -I have the very latest release 69 on the server. >> -I have two sandboxes checked out from the very same module >> -I added a 9k file from one sandbox and committed >> -I updated on the other and got the file OK >> >> Here is output from cvs ver in WinCvs: >> >> cvs ver >> ***** CVS exited normally with code 0 ***** >> Concurrent Versions System (CVSNT) 1.11.1.3 Prerelease (Build 69) >> (client/server) >> Client: Concurrent Versions System (CVSNT) 1.11.1.3 Prerelease (Daily >> Snapshot Build 68) (client/server) >> Server: >> >> And here the same from command prompt: >> F:\Engineering\Antares\KalleKula\ModuleXX>cvs ver >> Client: Concurrent Versions System (CVSNT) 1.11.1.3 Prerelease (Daily >> Snapshot Build 68) (client/server) >> Server: Concurrent Versions System (CVSNT) 1.11.1.3 Prerelease (Build >> 69) (client/server) >> >> Note the mangled output for the Server: item in the WinCvs window... >> It gets the data switched somehow. >> >> >> /Bo >> (Bo Berglund, developer in Sweden) > /Bo (Bo Berglund, developer in Sweden)