> http://www.pbs.org/wgbh/evolution/library/01/6/l_016_08.html
*Do not do this* with write access repositories, is my advice from knowledge of NFS filesystems. Writes, and partial writes, can occur from one host for the next "commit" but not actually be seen on the next "round robin" server until a fairly arbitrary amount of time later, due to propagation delays inherent in NFS. There's a lot tht NFS can do well, but this is not one of those tasks. I'd really encourage you, for commercial graide high availability or load distribution, to look at WanDisco's "Multi-Site" or to use a failover load balancer setup. If server 1 goes toes up, serer 2 is available, and handles all the traffic. But mixing and matching back and forth randomly as can happen with round-robin? That sounds like a dangerous idea likely to bite you at really, really bad moments due to simultaneous commits through two different NFS enabled front ends. On Wed, Sep 4, 2013 at 10:49 PM, Cheyenne Wills <cheyenne.wi...@gmail.com>wrote: > I've done several searches, and have found old and conflicting responses > to the question of sharing a repository via NFS. So what is the current set > of concerns with sharing repositories using NFS among several web servers? > > Here is the scenario, several hundred repositories shared via NFS to a > couple of webdav (Apache mod-svn) servers. The Apache servers set up via a > round-robin DNS server (thus they are all sharing a common virtualhost > name). All user access is via webdav (authentication and access controlled > by an Apache authentication handler). The users will see a common hostname > for all repositories. All the servers are "network close" to each other. > > Assuming that the NFS is current (NFS 4) with subtree checking disabled > (as per the FAQ), are there any gotcha's or other concerns. > > I currently have a solution using some custom Apache proxying that is > working, but I'm looking at trying to simplify my solution. >