I'm using a system where the working copy is on a nfs share. It works
like a breeze, but I think the nfs locking feature (I think, I'm not a
NFS expert) must be enabled. The repository (fsfs) is accessed through
Apache which again reads the database through a nfs share. Same
requirement to the nfs and locking stuff.
What I'm saying is that it can work with both working copy and
repository on nfs shares, you just have to configure it right.
Kjell
Andreas Schmid wrote:
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 15 13:22:53 2005