On 26-Feb-1998, Jason Gunthorpe <[EMAIL PROTECTED]> wrote:
>
> On Fri, 27 Feb 1998, Tyson Dowd wrote:
>
> > A CVS server is a single entity. If you're looking for ways to reduce
> > load on a CVS server, I have some ideas for that, but I believe multiple
>
> Please share, CVS serving on va is not exactly as lightweight as I would
> hope.
Sure.
1. I'm pretty sure the load of an ftp is a lot lower than a "cvs checkout".
So include CVS directories in distributed source tarballs. This way,
developers can just download the source tarball (or unpack it in a
new directory) rather than doing a "cvs checkout". This is much
faster for developers, and will no doubt reduce the load on the
server. It might be good to build daily tarballs if there is a
lot of activity.
Even relatively "out-of-date" tarballs can just be "cvs updated",
which should be a little less strain on the server.
2. Make sure all developers use -z9 to compress all files. Putting
cvs -z9
in your .cvsrc should do this trick ok. (Unless network traffic is
ok, but CPU load is too high, in which case perhaps this does more
harm than good!).
3. Keep modules from growing too large. Developers have a tendency to
check out entire systems to fix a small bug in just the documentation
or other modules.
4. Reduce commit log mail traffic - either batch the mail (one per
day?), or reduce number of mails sent.
There might be other things that can be done - I'm not sure what's
causing load problems with the server on va, but these are some of
the things I'd try. I've never seen remote CVS used on a very large scale
(e.g. hundreds of modules) so I'm not sure how well it scales yet.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
