[cvsnt] Can cvsnt go faster?

[Dan]

Hi, I figured it out, I found the files that were being written to by 
doing a find / -cmin 1   During an update. Turns out cvs writes a copy 
of every file to /tmp/

So I made a tmpfs ramdrive for cvs with:
mount -t ramfs none /cvstmp


And an update went from 5 minutes to less then 30 seconds. I'm pretty 
happy now, but does cvs really have to write a copy of every file being 
updated to /tmp/ ?

Thanks!
Dan



Flávio Etrusco wrote:
> Hi Dan,
> 
> I'd doubt Cvs is really doing all that write io. Did you already
> investigate bad usage of 'historyinfo' or 'notify' scripts? Or some
> other software doing mirror based on atime?
> 
> For a really large number of files I would only suggest splitting the
> project across several (Cvs) modules and disabling atime update on the
> filesystem, but your repository numbers don't seem so extreme. (unless
> all the files are in the same directory and your filesystem isn't
> reiser3)
> 
> 
> 
>>As our repository grows, it's getting slower. The main complaint is
>>doing an update takes about 4-5 minutes, even when there are no files
>>updated.
>>
>>The project is about 15,100 files, 818 megs on the server.
> 
> 
> Cvs design doesn't scale well for huge repositories since you have to
> "poke" all and every file in your module to know whether you're
> up-to-date.
> But again, I've seem larger repositories running fine even on Windows...
> 
> 
> 
>>Pentium 2.8ghz
>>harddrives 2 Ultra160 SCSI 15K rpm, software raid mirrored.
>>1 gig of ram
> 
> 
> Looks like a nice server :-)
> 
> 
>>If it's any help when we switched from cvs to cvsnt about a year ago we
>>noticed an immediate drop in speed, that has slowly been getting worse.
> 
> 
> Do you have tons of 'cvs removed' files? Do you have tons of files in
> the .Attic folders?
> BTW, in this case deleting obsolete files will help performance too ;-)
> Did you change Cvs protocols at the time?
> 
> Regards,
> Flávio