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.
Tony Hoyle wrote: > There are lots of reasons... I'm sure this has been discussed to death, so I apologise but ... > 1. Repository integrity. Network filesystems are *not* safe enough to put > something as important as a source code repository on. If you don't care > about your data then sure, go ahead. Otherwise find another way. Isn't this somewhat subjective? In our case the network filesystem is a Netapp and so from a data management perspective it's *much* safer for us to store it on a network filesystem then on a local drive. It's also convenient for us because we can dynamically resize the cvs partition when it runs out of space, we already have a disaster recovery plan, it has multiple levels of backups already in place etc. If you mean safe from a network security point of view, then doesn't most of that go out the window as soon as you enable pserver anyway (which we have to because we have some Unix clients)? A network share seems like the least of our worries. > 2. Speed. Everything will go over the network at least twice so performance > will suck. Right but you can enginner for this. We moved our Unix CVS repositories from local hard drives to our Netapp (accessible via NFS) and actually experienced a performance increase because we were able to spread the load over more spindles and network latency over a Gb (or even switched full duplex 100Mb) is negligible. > 3. OS restrictions. Impersonation explicitly excludes the ability to access > network shares. This is a security measure so that if one machine is > breached then your network remains secure. Active Directory actually has > way to allow this with a special privilege & sspi does request its use but > most admins don't allow it just for security reasons (it has to be enabled > on the active directory, the user account and I believe the machine to be > effective). So we do use Active Directory and we could use sspi (if Unix clients can still connect). However I assuming that from the tone of the message this isn't something that you are keen to add, so I'll let it drop and look for other alternatives. Thanks, Adam.