[Python-Dev] alternate pserver access for python CVS?

Christopher Blunck blunck@gst.com
Mon, 14 Jul 2003 10:07:18 -0400

On Sun, Jul 06, 2003 at 12:45:49PM +0200, M.-A. Lemburg wrote:
> Anthony Baxter wrote:
> >>>>"M.-A. Lemburg" wrote
> Hmm, but how is CVS read-only access different from downloading
> a tarball ? (except maybe for the different bandwidth they require
> in case of updates)

In terms of bandwidth, a CVS update is probably more efficient than a snapshot
tarball downloaded over http.  In terms of computational intensity, the tarball
downloaded over http is more simplistic than a CVS update.  A CVS update is
also chattier than a snapshot tarball.  And lastly, a CVS update is more I/O
instensive (lots of file open and closes).

If I were to guess, I'd say that the SF folks are experiencing CPU, I/O, and
bandwidth problems.  If they tell us all to use snapshot tarballs, it
eliminates two of their problems (CPU and I/O), allowing them to focus on 
pure bandwidth issues.  As a parallel activity, they can re-vamp their CVS
infrastructure (which they've mentioned doing) and distribute the CPU and I/O
over multiple resources.

Disregard the rest of this if you're not interested in my personal opinion.

It is my personal opinion that the sooner py is off sf.net's cvs server the
better.  Right now, Python co-habitates with other heavy projects on SF.  Our
CVS performance is negatively impacted by the success of other projects.  The
degradation is so severe in some cases that you can't even pull a CVS update
via pserver (or you have to work with a copy 24 hours old).  The cost in
efficiency might be more than the dollar cost of hosting the repository 


 10:00:00  up 58 days, 23:35,  8 users,  load average: 0.11, 0.20, 0.20