[email protected] 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
