Regardless of whether we decide to show lock-null children to svn
clients, we *definitely* have to show them to generic DAV clients.
When mod_dav_svn receives a depth-1 PROPFIND on a directory, it's
currently doing what you expect: it runs svn_fs_dir_entries() and
returns the list of children.
Now, it needs to call svn_fs_get_locks() and somehow "detect"
lock-null resources to return as well. In a perfect world, we'd fetch
just a depth-1 list of locks, and then have two depth-1 lists to
compare against each other. A no-brainer. Unfortunately,
svn_fs_get_locks() has no 'depth' argument. It runs in 'depth
infinity' mode all the time.
Here are three possible routes we can take:
* Call svn_fs_get_locks(), and assemble the overly-large list of
locks into an in-memory linked-list tree structure. Now we can
quickly find all locked children within a single directory, and
look up each child in the dirents hash. If a locked child isn't in
the dirents hash, poof, we've discovered a lock-null resource. The
lousy thing about this, of course, is the idea of assembling a
potentially large list of locks into an in-memory tree. Yuck.
* Add a depth argument to svn_fs_get_locks(). FSFS's locking
implementation would be fine with this, because it already arranges
locks in a tree structure. But BDB's locking tables would croak.
It wouldn't just be doing partial-key matches as it does now; it
would running svn_path_is_child() on each match, and also filtering
out grandchildren. It would be really slow.
* Radical idea: add a depth argument to svn_fs_get_locks(). Then
trash the BDB locking implementation and transplant (steal) the
FSFS locking implementation. Make the BDB locks table emulate what
FSFS does: the keys are md5's of the pathnames, the values are
linked-list pointers to other rows in the table. The disadvantage
here is, well, how long would that take? We want to finish locking
this year, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 16 20:31:52 2005