monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] fatal: database schema has changed


From: Nathaniel Smith
Subject: Re: [Monotone-devel] fatal: database schema has changed
Date: Mon, 14 Mar 2005 23:03:51 -0800
User-agent: Mutt/1.5.6+20040907i

On Mon, Mar 14, 2005 at 03:55:48PM -0500, Jeremy Cowgar wrote:
> Found:
> http://lists.gnu.org/archive/html/monotone-devel/2004-11/msg00083.html
> 
> > Conclusion: monotone needs to always keep the database locked 
> > explicitly, in 
> > some way that persists even over transaction boundaries.
> >
> > Bad part: there is no such mechanism in sqlite, at least as far as I can 
> > see.  
> > maybe we should whine at upstream/submit a patch/both until they add one?  
> > we 
> > could in theory create our own locking around the database, but that's a 
> > tremendous pain, and sqlite already has all the right locking stuff, just 
> > not 
> > exposed correctly for us to use.
> 
> Why not open the database only when needed from the serve command? You

This might be possible now with graydon's merkle tree speedups, but
would still require some mussing around with the netsync code; I think
we still assume that no revisions will appear inside the database
behind "serve"'s back, for instance.

> could easily add a lock mechanism using a table/field to disallow any
> writes from taking place.

I thought about this, but I can't come up with any mechanism that
simultaneously provides safe locking, and avoids problems with stale
locks.  I don't think it's possible just at the SQL level.

> Just an idea, but maybe there is a better way
> to serve and use a repo from the same computer.

Your best bet for now, and maybe in the future, is definitely to just
use two databases.  They can be on the same computer; have one running
all the time, push to it whenever you want to share things...

We do feel like _usually_, people will just set up a central shared
server for swapping their data?  It has lots of advantages over
swapping directly, and no disadvantages that I know of.  (You can
still fall back to swapping directly if the central server crashes or
something, of course.)

-- Nathaniel

-- 
"The problem...is that sets have a very limited range of
activities -- they can't carry pianos, for example, nor drink
beer."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]