Daniel Shahaf wrote on Sat, Sep 17, 2016 at 06:52:44 +0000:
> What concerns me at the moment is that the patch makes deltify_etc()
> return an error in situations where previously it did not. I think
> there are three possible solutions to this: revv the API deltify_etc()
> implements; make the change in 1.10 as an API erratum; or move the new
> logic from deltify_etc() to the libsvn_client consumers (svn and
> svnmucc). Haven't yet chosen among them.
Looking into this, there are two warning comments in the cmdline
client's commit callback, svn_cl__print_commit_info().
One of them is from r857282 (r17208), almost 11 years old now, saying
that scripts may interpret having stderr as implying "commit failed".
The other, 18 months young, is similar:
/* Be very careful with returning errors from this callback as those
will be returned as errors from editor->close_edit(...), which may
cause callers to assume that the commit itself failed.
⋮
*/
It seems to me that:
- If there is a post-commit error, its error chain should be printed to
stderr. We can signal to scripts that the commit succeeded by setting
the exit code to EXIT_SUCCESS or by using "W160013" rather than
"E160013" for the error messages ("W" for "warning").
- svn_cl__print_commit_info() should just return an error if there was
a post-commit error. If that confuses some libsvn_client caller into
wrongly thinking the commit failed, then that caller has a bug. (The
commit callback can already return an error even if the commit
succeeded, for example, whenever writing to stdout fails.)
Cheers,
Daniel
