On Wed, Mar 24, 2010 at 8:14 PM, Trent W. Buck <[email protected]>wrote:
> Jason Dagit <[email protected]> writes: > > > [...] I've heard that sqlite has a much better track record in this > > regard. I don't know enough about hashed-storage to say whether it > > could be used to store the inventory/patch metadata. > > The sqlite people claim (claimed?) that it's too dangerous to use on > NFS, due to poor mutex locking support on that filesystem (and other > network filesystems, including CIFS, AFS and SSHFS). > > And there's that case where the idiots at MoCo and GNOME are calling > fsync all the time because their databases can't cope with the long > (default) commit intervals of ext4 and btrfs. > > I'm not saying it can't be done right. I'd just like some confidence > that Darcs *will* do it right. > With the current repository locking mechanism, I think this isn't an issue. According the SQLite FAQ, you only run into the mutex locking issues if multiple processes are trying to write to the database concurrently on some filesystems (eg., NFS). Instead, we create a lock file and then take exclusive access to the repo and remove the lock file when done. Darcs clients that ignore the lock file are misbehaving and we currently do not try to defensively handle that case. I think the concern of how to transfer (or partition) sqlite dbs the way we do with the current inventory is a more compelling reason to rethink the idea than the file locking issue(s). I don't like the idea of darcs growing it's own network protocols. In fact, I think it's worse than growing our own static protocols (ie., file formats) due to the hassle of testing it throughly. Jason
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
