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
scenarios.

> 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 $?
0
% 

svn reports post-commit hook errors.  svnmucc doesn't.  Does either of
them need to be changed?

Daniel

Reply via email to