Re: svn commit: r11814 - branches/locking/subversion/libsvn_fs_base/notes

[email protected] wrote:

>+In addition to creating a lock in the `locks' table, a series of nodes
>+is created in a `lock-nodes' table.  The `lock-nodes' table reflects a
>+tree of nodes which are either locked, or are parent directories of
>+nodes that are locked.
>+
>+If the filesystem wants to know whether a certain path is locked or
>+not, it merely needs to test whether that path exists in the virtual
>+lock tree.  In the same way, the mere existence of a directory in the
>+lock tree implies that some child is locked, and thus the directory
>+cannot be deleted without further investigation.
>+
>+When a lock is destroyed, the appropriate row is removed from the
>+`locks' table.  (Locks are epheremal things, not historied in any way.
>+They are potentially created and deleted quite often.)  Additionally,
>+the locked-path is removed frome `lock-nodes' table.  The cleaning of
>+the `lock-nodes' table begins by removing the locked file-node, then
>+its immediate parent, repeating all the way up to the root directory.
>+If, at any point during the bubble-up, a directory either has more
>+than one child or has a lock attached, then the node-removal process
>+stops.
>  
>
And the price of adding, removing or checking a lock is proportional to 
its depth in the tree. If instead you use a simple path-uuid BTree 
table, lock operations are O(1).

(This solution isn't useful for SQL backends, but it should work like a 
charm in BDB).

-- Brane