[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Large file actual performance report; cvs use of ,v header issometim

From: Todd Denniston
Subject: Re: Large file actual performance report; cvs use of ,v header issometimes non-optimal.
Date: Thu, 17 Jan 2008 19:01:59 -0500
User-agent: Thunderbird (X11/20071031)

Arthur Barrett wrote, On 01/17/2008 05:51 PM:

There was a separate off newsgroup discussion which I wont go into here.

CVS-NT not on distribution, no auto-security updates for 5 years.

As opposed to the 3 year old copy of CVS 1.11 (1.11.19) that your
auto-security updates have gotten you?

I think for anyone reading this newsgroup for some time that my thoughts
on replacing software for no-good-business-reason are well known.  If
you don't need the features of CVS 1.12 or CVSNT 2.5.04 or PVCS or
ClearCase or any other tool then I am the last person that is going to
advocate that you should change.
However your post referred to specific problems that do not exist when
using the latest versions with best-practice and I wanted to make it
clear to other readers that there was no cause for alarm.

Your post also expressed what to me seems a complex and error prone way
of dealing with UTF16 files that obviously you are comfortable with but
others may be interested to know there are other ways / tools /
extensions that may suit them better.

Since your post did not actually contain a question and it appears as
though you've taken offence at me answering what I considered implied
questions it was probably more appropriate for you to post your test
results to gnu.cvs.bug

Even though not big by your standards, the CVS
server cannot handle a couple of small branches and less than 30 revisions without consuming hours and hours of server time.

For the benefit of others reading or finding this thread in future
searches: if you use the latest server and best practice this problem
does not occur.


Arthur Barrett

Also considering the age of his copy of CVS, I would have to wonder what kind of specs does the machine have?

He does give some of them...
"* Server is old (Dell PowerEdge 2300; Dual Pentium II 400 MHz; 1 GB RAM,
    disks are SCSI RAID) but server idles with very little CPU usage."

3+ year old machine, working for a big contractor...
Data on a RAID array capable of sustained 20MB/s
/tmp on the boot drive, capable of ~10MB/s, and with very little space to spare (i.e., less than 150% the size of the WHOLE repository) Possibly working across a 100Mb/s (12MB/s theoretical) network, using NFS as the sandbox directory.

The purpose of this Guess was not to denigrate, it was to point out OTHER things that can affect the speed at which CVS accomplishes it's work.
Connection method can make a difference too.

And a bit about the troubling file
"the repository size of the file is on the order of 315 MB."

which means that there is less than 650MB of ram left (assuming nothing else like X is running on the machine, and tmp is not a ram file system) to process the file (and IIRC CVS copies the file to tmp first so a bit more is gone). How much swap was being used before, during and after the operation???

Does this server serve anything else
It might not be eating the processors, but each of these requires RAM.

Then there is the troubling bit about
{so the next commit was destined to fail since the working directory
CVS/Entries file is now erroneous and marks the working directory file as
a new deleted revision 1.25.  See the prior post "FYI: cvs can break a
checked out working directory" for details.  }
Along with:
{The commit of the new 1.23 should have been quite fast (on the order of
minutes) because it is took place at the top of HEAD, but instead it takes
perhaps 8-12 hours, and, in fact, fails with an error saying 1.25 can not
be found.  This is the situation where the title "cvs use of ,v header is
sometimes non-optimal" comes to play.}

1) I suspect this could be solved with either an sandbox update or new checkout. The manual should probably indicate something along the lines of "If you are dangerous enough to mess with the dragons in the `cvs admin` command, then (before and) afterwards you need to tell all users 'Hey! You out of the pool! do a new checkout before attempting any new work.'"....
OH wait!! Quoth the book of cederqvist
last paragraph:
"Make sure that no-one has checked out a copy of the revision you outdate. Strange things will happen if he starts to edit it and tries to check it back in. For this reason, this option is not a good way to take back a bogus commit".

2) I tend to agree that CVS should have at least checked the repository for 'is 1.25 still the head/does it still exist?' on commit before working on anything else, because it always checks to see if you need to do an update before commit. Is this already the case in newer CVS's? And before someone says 'but he messed up the repo', which I agree... it should be trivial while checking 'if [current repo HEAD rev > current Entries rev]' also check 'if [current repo HEAD rev < current Entries rev]; {throw error/check to see if Entries rev still exists}'... at least for someone who knows where the first test is taking place now in the code. [Arthur, if you look this up in CVSNT, please drop a note to what file it is in for CVSNT, and the 10 lines around it... If I have to make a patch that would maybe help me find it in CVS.]

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter
Even when this disclaimer is not here, 
the opinions expressed by me are not necessarily sanctioned by and 
do not necessarily represent those of my employer. 
Also even when this disclaimer is not here, I DO NOT have authority to 
direct you in any way to alter your contractual obligation 
and my email can NOT be used as direction to modify a contract.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]