svn_fs_lock multiple paths

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*