Re: [Monotone-devel] Commit without working copy

[Nathaniel Smith]

On Tue, Dec 07, 2004 at 06:39:59PM +0800, Grzegorz Jakacki wrote:
> 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?

I believe the answer is that we currently have no care whatsoever put
into locking, relying on sqlite to take care of it, and the current
behavior is just an accident.  It's certainly not user friendly (in
that the error message when hitting the lock is pretty weird), and
it's a little bit buggy; see:
  http://lists.gnu.org/archive/html/monotone-devel/2004-11/msg00083.html
If you want to clean this stuff up, great, we really need someone to :-).

It's not obvious to me, though, that simply blocking indefinitely is
the right strategy.  There are a number of times when the database can
be blocked: when merging, when running a netsync server, when a
monotone process is stopped by C-z, etc.  CVS is a multi-user system
with a shared repository where locks are only held for very short
periods; Monotone is a single-user system with an unshared repository
and locks that can be held indefinitely.  Pretty different situations.
I'm not sure what would be preferred.  At the very least, if Monotone
does block, it should warn the user immediately that it is doing so,
so they can hit C-c or the like if they want.

-- Nathaniel

-- 
"Lull'd in the countless chambers of the brain,
Our thoughts are link'd by many a hidden chain:
Awake but one, and lo! what myriads rise!
Each stamps its image as the other flies"
  -- Ann Ward Radcliffe, The Mysteries of Udolpho