On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----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)
>
I completely agree with Bert that having error is very important for
GUI clients. The source of error code doesn't matter actually. It just
some stable identifier of particular error and reason. GUI client may
suggest solution based on this error code. Or ignore it in some cases.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-07-10 00:53:12 CEST