[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Info on CVS server best practices
From: |
Zieg, Mark |
Subject: |
RE: Info on CVS server best practices |
Date: |
Mon, 13 Jan 2003 18:20:36 -0500 |
> - 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 :-)