Karl Fogel <kfogel@newton.ch.collab.net> writes:
> Philip Martin <philip@codematters.co.uk> writes:
> > I tried passing SVN_ERR_REPOS_POST_COMMIT_FAILURE and the error
> > passing works. However, that doesn't really solve the problem, if the
> > client is going to carry out its post-commit proccessing it needs to
> > get the normal successful commit response, with the new revision
> > number, etc. Simply having the client recognize a post-commit hook
> > error, print it and continue, is not sufficient.
>
> I didn't understand why your last sentence above is true (?).
>
> Granted that non-fatal errors are difficult to implement in the
> current scheme of things, but let's assume for the moment that that
> bit of architectural lossage were solved: in that case, it should be
> sufficient to have the client recognize a post-commit hook error,
> print the error as an informational warning, and continue with the
> normal post-commit processing. What would be bad about that?
Nothing is bad, it's what I suggested. However it is not sufficient.
The client's post-commit processing depends on the DAV merge-response
message returned after a successful commit. If the repos library's
svn_repos_fs_commit_txn returns the post-commit hook error then
ra_dav's dav_svn_merge will pass that error back to the client instead
of the merge-response. Although the client can recognize the error it
won't have the merge-response that is required to carry on and do
post-commit processing. So, it is not sufficient for the client to
recognize a post-commit hook error. We need a something more, either
the ability to return an error independently from the merge-response,
or the ability to combine the error with the merge-response.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 6 20:32:19 2002