On Thu, Oct 28, 2010 at 9:54 AM, Christer Edvartsen <c...@starzinger.net> wrote: > Here is our setup: > > We have the repository stored locally on one machine. We have several > other machines that has an active read+write mount to our SAN. We have a > symlink to this mount in /srv/library on all machines. > > In /srv/library we have a working copy of our repos. When doing svn up > /srv/library on any of our machines we are able to update the working copy > used by all machines at once. Usually this works like a charm.
> Some weeks ago we switched from https (webdav) to svn+ssh when talking to > our repos. Along with this switch came a locking issue. Sometimes when > running svn up we get an error that some of the directories in the working > copy we are trying to update is locked. They are not locked in Subversion > so I'm guessing it's NFS that is causing these problems. These problems > seems to occur randomly. NFS changes do not propagate simultaneously to all NFS clients. This makes various components of the commit asynchronous, as far as other NFS clients are concerned, and can lead to some fascinating interactions unless the authors of subversion thought really hard about such issues and handled locking *very* carefully. > 1: Why did this never happen when we used webdav? > 2: Is there an easy way to make the locking issues disappear? Only perform, or allow, direct commits on one server: the host that used to provide HTTPS or svn access might be a good candidate.
