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.
Hello all: I've been tasked by my company to convert an existing linux-based CVS 1.11.1p1 repository to a windows 2003-based CVSNT repository (CVSNT 2.5.03 Build 2382). However, I've run into a problem where a checkout is taking two and a half times as long with CVSNT as it is with CVS. Our repository size is a bit over 5GB, with about 175 modules in it - though probably only about half of the modules are active. The old server is a RedHat 7.1 (kernel 2.4.2) system on a first-generation Compaq ML370 with dual P-III 933MHz processors, 1.1GB of RAM, and CVS on a dedicated mirrored pair of 10k-RPM SCSI drives. The new server is a Windows 2003 SP1 system on an IBM x335 with dual Xeon 3.06GHz processors, 4GB of RAM, and the entire system on a pair of mirrored 15k-RPM Ultra-320 SCSI drives. If I run the command "tar -cf - [large_module] > /dev/null" and "tar -cf - [large_module] > nul" on the Linux and Windows system, respectively, I find that the command runs more quickly on the Windows machine, as I would expect. The CVS conversion that I've done is based off the mail list archive message at http://www.cvsnt.org/pipermail/cvsnt/2003-June/007066.html - I TARred up the CVS repository, copied that TAR over to the Windows system, and extracted everything but the CVSROOT into the CVSNT repository. I made sure to remove the LF -> CR/LF translation within WinZip. The system is using pserver authentication, at least until I get this performance problem settled. There are a couple of perl scripts that run, but they're called via the CVSROOT\verifymsg and CVSROOT\commitinfo files, which should both be triggered only upon a commit. The active modules also have a large number of tags associated with them, as our company runs nightly builds. Also, the checkout and active development happens on a branch, as we've abandoned HEAD/trunk for historical reasons. I appreciate any help that people can offer. If you need any more information in order to make a suggestion, then I'll be happy to supply it. Thanks, --Mark Donnelly