Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Mon, 29 Sep 2003 17:27:42 -0400, "Williams, Tim" <WilliamsTim at PRAIntl.com> wrote: >"Do not use the CVS server machine for any purpose besides a CVS server." >Can someone give me some strong reasons as to why this is the case? I >assume restricted access is one key reason. Yes, you should also put the CVS repository data on a separate disk in the server and *not* create any shares at all on this volume. This is to force all users of CVS to go through the CVSNT service instead of trying to muck around with the repository files directly. >Our existing server meets that >criteria, but it is often in heavy production use and I don't want to take >it down for reboots as I expand our CVS utilities into such things as >ViewCVS, etc. (nor do I want a webserver running on that server, either). I would think that the IT people also don't want their production server bogged down with IIS running... >The server is also a validated system that I don't want to muck around on. A valid opinion... If you are serious on the value of your sourcecode then you should be able to convince the IT people of the advantages of having a dedicated server (doesn't have to be a server class machine, a Workstation is also possible). What they need to do is the following: 1) Include the repository drive into the daily backup scheme you have running. 2) Help you out setting up CVS usergroups to use for controlling access 3) Refrain from installing AntiVirus firewalls etc on this machine as this is likely to interfere with proper CVS operations. 4) Let you keep the CVS server under lock in the server room. 5) Open up Terminal Services for you, this way you can log on to the server and manage it, including installing things like CVSNT and ViewCvs from your own PC. /Bo (Bo Berglund, developer in Sweden)