Philip Martin <philip.martin_at_wandisco.com> writes:
> 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.
post-lock failures are a mess at present. Create a repository with 2
files and arrange for the post-lock to fail. Then lock the two files
from a working copy. Over http:// and svn:// locks get created in the
repository but the lock tokens do not get stored in the working copy.
Over http:// a trunk client pipelines two LOCK requests and gets back
one 500 response saying "Failed to create lock". One lock, corresponding
to the first LOCK request, has been created in the repository but the
500 doesn't contain the lock token.
Over svn:// the client sends a lock-many with both paths and gets back a
response with two errors "Lock succeeded, but post-lock hook failed".
Both locks have been created in the repository but neither lock token is
included in the response.
The current behaviour is not very good. Since the low level svn_fs_lock
only handles one path there is currently a post-lock for each path, so
we need to return both the post-lock error and the lock token for each
path.
How should it work when we have an svn_fs_lock that locks multiple
paths? Should we run the post-lock once per lock, or once per call?
It's designed to be run once per call which is why the paths are
supplied on stdin. If we run it once per call do we return any
post-lock error repeatedly with each lock token?
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-02-06 20:32:06 CET