RE: Info on CVS server best practices

[Zieg, Mark]

>  - CVS repository be installed on a dedicated server
>    rather than on a box contending with developers and
>    other applications for memory, swap space and disk
>    space
>
> - CVS repository be on a server where users don't have
>   direct login access

I've never felt a need to enforce either of these.  It depends on the scope
of your project, of course, but even with a half-dozen active developers on
a common dev box (Linux or FreeBSD), running periodic builds of
moderate-sized source trees (say 100K SLOC), I've never had problems such as
would significantly deteriorate CVS's relatively low I/O & resource
requirements.

> - shadowing of CVS repository in the event of a calamity
>   for instant switchover to the other repository rather than
>   wait for the lengthy restore process

We just ran an hourly rsync script to keep our hot-swap /usr/local/cvsroot
current, then switched over the DNS hostname of the old repository to the
backup box when the prime went down for some reason (as happened twice, I
believe).  Worked like a charm, and very lightweight to implement.

Also, by not being a stickler about the "nologin/dedicated" rule, we were
able to use another development box (db server, webserver, whatever) as the
hot-swap, avoiding the expense of an unused standby host.  In the
post-Bubble world, cost-cutting is once again recognized as an admirable
business trait :-)