Remote CVS access.

[Tyson Dowd]

1. Previously, using remote CVS using mercury.cs.mu.oz.au as the server
   didn't work very well - it would put "nobody" as the author and mess up
   the ownership on the files (making them owned by "nobody").

   Most of these problems seemed to be due to an old version of CVS
   (1.8.1). I've installed CVS 1.9 instead (not the latest version, but
   the latest `release' version at the local gnu mirror), which seems to
   have fixed this problem.  I also tweaked the settings so that the
   owners get fixed.

   (PS installing things on mercury is a right royal pain).

2. There is a fairly bad performance bug with CVS servers.  If a
   connection dies at the remote end, the server can grow to many
   megabytes.  This is a result of the architecture of the client/server
   design, and isn't going to be fixed for a while.

   This is affecting mercury - here are two processes that might be
   stuck at the moment:
nobody   19738  0.0 13.5  8992  8536  ?  S    22:07   0:00 cvs -b /usr/local/bin
nobody   19847  0.0 24.9 16276 15776  ?  S    22:11   0:01 cvs -b /usr/local/bin
   Too many of these will run mercury out of virtual memory, so please
   be aware of this problem if performance is starting to degrade on
   mercury. 

   These connections had a very large number of outstanding packets when I 
   checked with `netstat', so I assumed they were dead on the other end.
   If they are still there tomorrow I will kill them.