Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com From: "Mark Allan Young" To: "Charles S. Wilson" Cc: "Cygwin" Subject: RE: CVS (v1.11) performance on Cygwin 1.1.8 Date: Fri, 16 Mar 2001 14:25:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <3AB21B2F.A4A198CF@ece.gatech.edu> > > Running cvs as 'cvs -t update' should give you a better feel for > > what cvs is up to. It's pretty verbose, but it makes it a little > > easier to figure out cvs is doing. First off, thanks to the few people who have responded. Second, a couple of additional pieces of information: We are not running any Virus Scan software. I've found something interesting in running the two different versions of cvs that I have (1.10.8 vs 1.11). Switching back and forth between the two commands seems to slow them both down pretty significantly... running the same command two times in a row, the second invocation is usually significantly faster than the first. using the trace command, I found that the first time I run a command, it sends many of my (unmodified) files up to the server: ============================================================================ = rune> time cvs -t update cvs.exe update: notice: main loop with CVSROOT=myoung AT cvs DOT intrinsic DOT com:/d1/cvs-db -> Sending file `PackageMaker' to server -> Sending file `alchemyrelease.pl' to server -> Sending file `cadd' to server -> Sending file `cbeauty' to server -> Sending file `ccDocBuilder' to server -> Sending file `ccvs' to server -> Sending file `change_sed' to server -> Sending file `cin' to server -> Sending file `cinstall' to server -> Sending file `cjointci' to server -> Sending file `crRemover.dat' to server -> Sending file `crename-experimental' to server -> Sending file `crnl.txt' to server -> Sending file `cstrain' to server -> Sending file `ctree' to server -> Sending file `dspgen' to server -> Sending file `exedspgen' to server -> Sending file `fglgen' to server -> Sending file `nascheck' to server -> Sending file `newgapbuild' to server -> Sending file `subsPSX2forPsx2' to server ? update.out cvs server: Updating . S-> checkout (/d1/cvs-db/newgap/tools/ctools/PackageMaker,v, 1.31, , (function)) S-> server_register(PackageMaker, 1.31, Fri Mar 16 22:04:01 2001, , , , ) S-> Register(PackageMaker, 1.31, Fri Mar 16 22:04:01 2001, , ) -> Register(PackageMaker, 1.31, Fri Feb 02 19:52:14 2001, , ) S-> checkout (/d1/cvs-db/newgap/tools/ctools/alchemyrelease.pl,v, 1.2, , (function)) ============================================================================ ======== the next run doesn't (I run it two more times below): ============================================================================ ======== rune> time cvs -t update cvs.exe update: notice: main loop with CVSROOT=myoung AT cvs DOT intrinsic DOT com:/d1/cvs-db ? update.out cvs server: Updating . S-> rename(CVS/Entries.Backup,CVS/Entries) S-> unlink(CVS/Entries.Log) real 0m0.250s user 0m0.020s sys 0m0.010s rune> time cvs -t update cvs.exe update: notice: main loop with CVSROOT=myoung AT cvs DOT intrinsic DOT com:/d1/cvs-db ? update.out cvs server: Updating . S-> rename(CVS/Entries.Backup,CVS/Entries) S-> unlink(CVS/Entries.Log) real 0m0.300s user 0m0.010s sys 0m0.010s rune> ============================================================================ ======== but if I switch back to the cygwin version (the version above was the 1.10.8 version), it sends the files again: rune> time cvs.cygwin -t update cvs.cygwin update: notice: main loop with CVSROOT=myoung AT cvs DOT intrinsic DOT com:/d1/cvs-db -> Starting server: rsh cvs.intrinsic.com -l myoung cvs server -> Sending file `PackageMaker' to server -> Sending file `alchemyrelease.pl' to server -> Sending file `cadd' to server -> Sending file `cbeauty' to server -> Sending file `ccDocBuilder' to server -> Sending file `ccvs' to server -> Sending file `change_sed' to server -> Sending file `cin' to server -> Sending file `cinstall' to server -> Sending file `cjointci' to server -> Sending file `crRemover.dat' to server -> Sending file `crename-experimental' to server -> Sending file `crnl.txt' to server -> Sending file `cstrain' to server -> Sending file `ctree' to server -> Sending file `dspgen' to server -> Sending file `exedspgen' to server -> Sending file `fglgen' to server -> Sending file `nascheck' to server -> Sending file `newgapbuild' to server -> Sending file `subsPSX2forPsx2' to server ? update.out cvs server: Updating . S-> checkout (/d1/cvs-db/newgap/tools/ctools/PackageMaker,v, 1.31, , (function)) S-> server_register(PackageMaker, 1.31, Fri Mar 16 22:08:56 2001, , , , ) S-> Register(PackageMaker, 1.31, Fri Mar 16 22:08:56 2001, , ) -> Register(PackageMaker, 1.31, Fri Feb 2 19:52:14 2001, , ) S-> checkout (/d1/cvs-db/newgap/tools/ctools/alchemyrelease.pl,v, 1.2, , (function)) ============================================================================ ======== and, as above, subsequent runs do not send the file. when I checked the CVS/Entries file between the two runs, I found the following difference: rune> diff e.1 e.2 1c1 < /PackageMaker/1.31/Fri Feb 2 19:52:14 2001// --- > /PackageMaker/1.31/Fri Feb 02 19:52:14 2001// Notice that the date format is different...one uses a zero padded number for the day of the month, and the other does not...this might explain why switching between commands insists upon sending the files to the server. anyone know why the format changed? the old cvs, 1.10.8 uses the zero padding. since we're running an older version of the cvs server (1.10.7), I wonder if this change in date format may be responsible for some confusion when running the 1.11 version. may be a total red herring, but I though I'd point it out. assuming that this isn't the case, is anyone familiar with the logic that the local cvs uses to do date checks when deciding whether or not to send a file back to the server? Why are the files sent back? is there any way to turn on more verbose messages from the trace command? -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple