sussman@tigris.org 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 11 22:10:15 2004