> - 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 :-) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
