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

RE: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 9 Jul 2013 23:51:09 +0200

> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: dinsdag 9 juli 2013 23:12
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1501371 -
> /subversion/trunk/subversion/libsvn_ra_serf/util_error.c
>
> On 09.07.2013 23:00, Bert Huijben wrote:
> > I would welcome a patch to svn_strerror that improves the default
> > error for serf specific error codes,
>
> That would effectively make our make implementation details of
> libsvn_ra_serf part of the public API. That's a non-strarter IMO.
>
> > or a patch that translates all serf error codes to something within a
> > subversion error range.
>
> If we go down that road, we may as well make Serf part of the Subversion
> project. Which I don't believe is going to happen.
>
> By all means wrap the error messages inside libsvn_ra_serf; I wouldn't
> object to extracting the Serf error message and adding a "caused-by:
> serf error NNNN" in the same error chain.

Which requires tools to start message scraping?

My Chinese error parser is not so good, and perhaps somebody changes the .po file with the next patch release?

TortoiseSVN, VisualSVN, AnkhSVN and probably most other GUI clients prefer error values over texts.
(I don't know about our JavaHL users, but I know more than a few SharpSvn users that have checks for specific error codes in their products)

The texts are for our users and should tell them enough without them ever looking at the error values.

So: What are we talking about here?

An 'svn'-only user wants to see different error codes?

(Perhaps he added patch over patch to make the numbers more visible in MAINTAINER mode?)

100% agree on: The message should be set before the user sees the error.

But I fail to see why wrapping every error in generic subversion errors is going to help anybody.

Should I handle these error messages by pointing them to specific e-mail addresses?
With errors as WSAECONNFAILED I can at least point users to suggestions on how they should connect to their repository, but with error codes as SVN_ERR_RA_SERF_WRAPPED_ERROR I can only point users to dev{_AT_}subversion.apache.org.

These codes add value to our bindings... It allows more advanced bindings to use this knowledge.

        Bert
Received on 2013-07-09 23:52:16 CEST

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