On 09.10.2015 18:16, Branko Čibej wrote:
> On 09.10.2015 17:16, Julian Foad wrote:
>> This FAQ seems rather out of date / lacking in correctness:
>>
>> http://subversion.apache.org/faq#nfs
>>
>> Since 1.7, the SQLite DB in the WC needs 'file locking' to work
>> properly, which (as I understand it) sometimes needs to be enabled in
>> the NFS server config, and on some NFS implementations (and other
>> networked file systems?) doesn't work properly. Is that roughly
>> correct?
>>
>> So the simple message "Working copies can be stored on NFS" needs to
>> be amended to say something about the need for locking to work?
>>
>> What about the "server" parts of the answer? (First, we should move
>> the FSFS part to come first, as that's more widely used.) But does
>> FSFS with rep-cache just "work fine on modern NFS" as stated? If so,
>> is the same true for the WC?
>
>
> Nothing that relies on atomic renames or locking works reliably with
> *any* NFS server. AFAIK, while there are solutions for the locking
> problems, there are no solutions for making renames atomic.
>
> That's disregarding the problem of simultaneous remote and local access
> to the NFS server's filesystem. That's somewhat less problematic in the
> working copy, which is usually accessed only from one client at a time.
> But having the repository on NFS and the actual server on possibly
> several other machines is a disaster waiting to happen.
>
>
>> Anyone want to take a shot at revising this FAQ answer?
>
> Rumour and reading a few bits of spec doesn't make me an NFS expert, I'm
> afraid.
Maybe link to the SQLite FAQ about this:
https://www.sqlite.org/faq.html#q5
See the second paragraph under that FAQ entry.
I'd say if SQLite does not recommend storing the db file on NFS,
Subversion should do the same and not recommend storing working copies
on NFS.
Stefan
Received on 2015-10-09 22:03:17 CEST