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.
nick.minutello at uk.bnpparibas.com wrote: > >>>cvsnt is doing more work - cvs does not have access control, > > What access control are we talking about? Per-file and per-directory inheritable ACLs. >>>or directory/file rename mapping, > > What is that? Is this to do with handling renames? Yes. Every file is mapped from logical-physical on the fly (because of the way it's built on old cvs code it's a bit messy at the moment but then next stable release will make this much cleaner). >>>or file-level locking, > > Where does file-level locking come in? cvs just locks the entire directory (in fact most of the time the entire repository) so you get very little concurrency. cvsnt allows multiple concurrent updates by handling the locking per-file. >>>I get a peak of about 15% for a full update - > > As I mentioned, we are getting a much higher peak than that - 75%. Thats on > a single-cpu PIII Xeon.... > > >>>as long as there's unused >>>CPU that's fine... it's there to be used. > > :-) > Thats fine for one user.... but when you want 200+ developers using the > same server... the cpu is there not to be used, but to be shared... :-) That's the job of the OS, not the application. A perfectly efficient application would run 100% CPU very quickly. The reason apps don't use 100% CPU is they have to wait for various resources - disk, devices, etc. This slows them down - an app peaking at 5% CPU could theoretically run 20* faster if its bottlnecks could be removed. I you ran 5 perfectly efficient apps on a perfect OS they would each use 20% CPU. This is only theoretical though - in reality it never happens like that. > Our continuous integration servers also count as quite a large number of > normal users - given the check frequency I still don't understand why you're doing this... Just keep an updated sandbox updated by postcommit - takes almost no time to setup and maintain. > But sadly its *significantly* slower than regular cvs and older versions of > cvsnt. > When we are talking about 3-4 minute updates.... it becomes a little > unusable.. Not really.. there's a few % difference but nothing like what you're seeing - there must be something else going on. I regularly use both cvs and cvsnt servers all the time and there really isn't a noticable difference in normal use. I'm always looking at ways to speed it up (still far too much going back to the disk etc.) which is why cvsnt has had a tencency to get faster with each release these days. Tony