[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Re: ra_local doesn't report post-commit errors

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 20 Sep 2016 09:10:35 +0000

bert_at_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
Received on 2016-09-20 11:11:50 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.