I'm working on a new svn_fs_lock that allows multiple paths to be locked. This is to avoid the inefficiency of writing the large digest files multiple times when locking multiple paths one at a time. I have the low level file handling written but the plumbing to connect it all up is a bit tricky.
The RA layer already has multiple path support in svn_ra_lock and it has a calback API to return the lock/error for each path. I decided to follow that pattern and have svn_repos_fs_lock and svn_fs_lock use callbacks as well but there are problems at both layers. At the FS layer we don't want to invoke the calbacks while holding the FSFS write lock as we don't know what the callback will do; the RA layer might attempt to write to the network say. That means the FSFS layer has to accumulate the locks/errors while holding the write lock and invoke all the callbacks after releasing the lock. Since we have to accumulate the results there seems little point in using a callback rather than simply returning the block of results. At the REPOS layer we have to invoke the pre-lock and post-lock hooks and here the post-lock is a problem. The post-lock is already designed to handle multiple paths, it receives the paths on stdin rather than as parameters. We can't invoke the post hook until we have the FS results for all the paths so a callback FS API isn't useful. The REPOS layer could be a callback API, but since it needs to accumulate the results before calling the post-hook it seems sensible just to return the block of results. It's also not clear how the single post-hook error should be handled when using a callback API, unless it is returned separately. I have an implementation using callbacks but it's crazy, as each layer accumulates the results and splits them up to invoke the callbacks, and the layer above accumulates again. I can't see any advantage in using the callbacks rather then simply returning some block of results. On a related note, the post-lock is weird. It gets the username as a parameter and multiple paths on stdin. The comments in the hook template refer to using svnlook to examine the lock, but that won't work reliably since the post-lock is asynchronous. So the only thing the post-lock can rely on is that at some point in the past the given user locked the given paths, the post-lock cannot reliably obtain the lock tokens, it cannot assume the paths are locked or even exist in HEAD. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
