This is just a shot in the dark (I am fairly new to CVS). I believe you mentioned in an earlier email that you are moving a large number of binary files. Is it possible that CVS is somehow examining the contents of these files (say, to determine end of line?). In a binary file this would be a very time-consuming task, and might generate a significant amount of traffic between the client and the server. When you turn on compression, regardless of the level of compression, CVS "knows" that you are moving a binary file, and turns off all file internal checks? If this is the case, I believe you can use the -kb commandline modifier to tell CVS the file you are committing is binary. I hope this helps --- Steve "Scott Willy" <[EMAIL PROTECTED]> on 07/03/2001 06:31:12 AM To: [EMAIL PROTECTED] cc: (bcc: Steven Rosenstein/FTCI) Subject: RE: CVS slow and TCP Compression We have re-done the FTP tests. Uploads and downloads work fine. Both to/from the PC (the cvs client) and to/from the cobalt cube (cvs server). The speed was fine over 100KBytes/sec. Still could be a duplex problem, but the evidence is not clear. We are still trying to figure out how to configure the cube's Ethernet driver to force it into half-duplex mode (it is easy to do so on the PC). Any case, we can leave it here. I think the most important thing to note is that by changing the TCP compression level (e.g. -z3 )some network problems might be solved (or at least worked around). csw _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
