b...@qqmail.nl wrote on Mon, Sep 19, 2016 at 09:37:35 +0200:
> -1 on just returning non errors from the commit info callback and
> making callers suffer. I added that comment after finding that all
> callers suffer and there is no way to see the difference, causing all
> kinds of problems. You can only return errors there to fail fast.
Veto duly noted, but:
1. I think those restrictions should be stated not in a comment in
svn.c, but in the documentation of svn_commit_callback2_t.
2. The commit callback can fail even when the commit succeeded, for
example, when stdout is redirected to a file on a full partition the
printf in svn/util.c will fail, or when a SIGINT occurs while the commit
callback is running. The client/wc layer needs to cope with these
> That api was designed (around 1.5/1.6) to just store the result and
> then handling it post commit. In later versions we thought up that it
> was easier to just print from there…
> … but that turns post commit errors in normal commit errors. which
> then behave different for every RA layer.
I assume we agree that differences between RA layers should be minimal.
> These warnings on the fs layer were designed to be logged server side
> (e.g. in the apache error log); not to be transferred to the client.
As I said, this is not only about post-commit FS processing errors but
also about post-commit hook errors.
% svnadmin create r
% ln -s /usr/bin/false r/hooks/post-commit
% svnmucc mkdir -U file://$PWD/r -mm $RANDOM
r1 committed by daniel at 2016-09-20T09:04:13.915123Z
% echo $?
svn reports post-commit hook errors. svnmucc doesn't. Does either of
them need to be changed?