[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge tracking: will SQLite make NFS sad?

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-03-05 15:00:44 CET

On 3/5/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
>
>
> I notice that SQLite currently recommends [1] that you don't use it over a
> network filesystem. People are currently happily using FSFS repositories
> stored on NAS boxes (over CIFS and NFS), because we've been careful to
> make sure it works.
>
> How do we reconcile these two statements?
>
> I'm also wondering how SQLite would work out with multiple clients:
> conceivably you could deploy a farm of mod_dav_svn servers for
> load-balancing purposes, and they could share a single backend FS on a
> NAS.
>
> In my (albeit limited) experience of SQLite, it doesn't seem to attempt a
> great deal of concurrency (until recently, you could deadlock by deleting
> rows that you were currently iterating through with a SELECT).

Doesn't fsfs itself use similar locking mechanisms to what is described in
those docs? I thought this was discussed once and that was the answer as to
why using SQLite was not making things any worse. Of course I suppose it is
possible that SQLite could be more dependent on them than the fsfs
implementation.

At some point, doesn't the question come down to "what is the alternative"?
We appear to need something like what SQLite offers to implement the
feature, and we all agree the merge tracking feature is high priority, so
what is the alternative?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on Mon Mar 5 15:01:13 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.