Re: [Monotone-devel] Commit without working copy

[Grzegorz Jakacki]

Nathaniel Smith wrote:
> On Mon, Dec 06, 2004 at 12:23:07AM +0800, Grzegorz Jakacki wrote:
>
> > Nathaniel Smith wrote:
> >
> > > Also, note that you need some locking to make sure that only one
> > > 'monotone' subprocesses runs at the same time to access the same
> > > database; Monotone won't corrupt your data in any case, but will error
> > > out rather than blocking and waiting for the DB to become available.
> >
> > Is this monotone's or SQLLite's problem?
[...]
>
> It's Monotone's problem. 
[...]
> But Monotone is a single-user single-threaded app,
> and 1) the way we use SQLite, we basically lock the database the whole
> time we're running, and it would take work to figure out the correct
> dance to make this not happen,  and 2) having done this, you'd have to
> carefully audit the Monotone code to make sure that concurrent access
> wouldn't break anything.  Probably a lot of things would work fine,
> but no-one really knows for sure.  I don't think we're really
> interested in doing this kind of careful checking either, because we
> get a _lot_ of benefits in simplicity (= speed, maintainability,
> robustness, ...) from side-stepping the whole concurrency issue.  (The
> worst part isn't doing the checking, it's redoing it every time we
> ever make a change in the future...)

Some systems (e.g. CVS) wait for the lock instead of aborting. Why did 
you choose to abort on lock? What would I break if I make monotone wait 
for the lock release? As I understand the only reason why database can 
be locked for indefinite time is soliciting log entry from the user. Right?

BR
Grzegorz