lockdir details

[Martin Pool]

The current LockDir implementation uses the existence of a non-empty  
directory called "foo" to indicate that the lock "foo" is held.   
Typically there will be just one lock per protected object/directory  
-- e.g. repository/branch/checkout within a bzrdir -- and typically  
called something like "branch-lock".

The LockDir is actually managed by the LockableFiles object which  
manages the directory.  The name of that class perhaps overemphasises  
locking; the point of it really is that they are a group of files  
which together make up a single small-d-database, and that are  
versioned and locked together.

I'm just changing this so that the top-level LockDir itself exists,  
and the presence of a subdirectory called "held" indicates that it is  
held.  There is a file called "info" inside this which serves the  
dual purpose of making the "held" directory non-empty (and so not  
implicitly overwritten on any transport), and giving some information  
about who holds the lock.

This leads me to expect that the LockDir will be explicitly created  
when the object it protects is created, and so attempting to acquire  
the lock should not automatically create it.

-- 
Martin Pool