Re: working copy on NFS
Andreas Schmid <[email protected]> Tue, 13 Dec 2005 15:32:03 +0100
| Newsgroups | gmane.comp.version-control.subversion.devel,gmane.mail.eyebrowse.user |
|---|---|
| Message-ID | <439EDB63.2070609__43807.2892874063$1134505266$gmane$org@ira.uka.de> |
> On Wed, 2005-11-23 at 17:13 +0100, Vincent Lefevre wrote: > >>On 2005-11-23 15:30:19 +0100, Daniel Drotos wrote: >> >>>The book mentions that the repository should be created on a local >>>filesystem. >> >>Is it also true for FSFS? >> >> >>>What about the working copy? >> >>No problem, except for the well-known problems of NFS. >> > > > > Actually, we explicitly say it work in the FAQ: > " > Working copies can be stored on NFS (one common scenario is when your > home directory is on a NFS server). On Linux NFS servers, due to the > volume of renames used internally in Subversion when checking out files, > some users have reported that 'subtree checking' should be disabled > (it's enabled by default). Please see NFS Howto Server Guide and > exports(5) for more information on how to disable subtree checking. > " > > And on IRC, it has been used as a reason why we do locking the way we > do. > So if it doesn't actually work to store a working copy on NFS, we > should either > > 1. Fix it > > or > > 2. Use real locks, and stop claiming storing working copy works on NFS > on nfs implementations where locking doesn't work. > > (I actually think #2 is the better solution, because i think that we > shouldn't work around everybody elses bugs, particularly when it causes > large performance loss for us) > It doesn't work for me either, a checkout fails with the comment: svn: Stale NFS file handle svn: svn_io_set_file_read_only: failed to set file 'doc/.svn/entries' read-only Andreas