I think swallowing (and logging) the post lock error is the best thing we can do for the old api. I think anything else would require extending the Ra layer api (or moving further away from using multiple path at the same time), The callback handles any error as 'the lock failed’.
Given all this it might be better to just deprecate post-lock for most things and focus on improving pre-lock. As you noted earlier it is probably only useful for simple notification scenarios. I don't know of any cases where client users are really interested in the lock token. The lock owner and comment are on most cases the only thing users are really interested in. The token itself doesn't give you any privileges… Bert Sent from Windows Mail From: Philip Martin Sent: Thursday, February 6, 2014 8:41 PM To: 'Subversion Development' Philip Martin <philip.mar...@wandisco.com> writes: > 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? Perhaps the servers should swallow/ignore any post-lock errors and not return them to the client? Perhaps logging them on the server is sufficient? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
