Daniel Shahaf <danie...@elego.de> writes: > Just got a report of a problem with 1.8.0-rc2: > > svn: E120104: ra_serf: An error occurred during decompression > > The error code is unrecognised; that's because it's not an SVN_ERR_* code: > > % ./tools/dev/which-error.py E120104 > 00120104 *** UNKNOWN ERROR CODE *** > % ./tools/dev/which-error.py E120000 > 00120000 APR_OS_START_USERERR > % grep -B 1 -w 4 -h /usr/local/serf-1.2.0/serf-1/include/* > #define SERF_ERROR_DECOMPRESSION_FAILED (APR_OS_START_USERERR + \ > SERF_ERROR_RANGE + 4) > > The problem is that svn_ra_serf__wrap_err() passes a serf error code to > svn_error_create(). That's a problem, as API consumers won't be able to > make sense of the code: it's not in any SVN_ERROR_*_CATEGORY_START > category, svn_strerror() and svn_error_symbolic_name() will reject it, > etc. > > I am not sure what to do instead. Maybe we define an > SVN_ERROR_SERF_ERROR error number and map all serf error numbers to it. > Maybe we define a few more of those for specific common serf errors, too > (like we do for sqlite). Maybe we just reserve [APR_OS_START_USERERR > + 100, APR_OS_START_USERERR + 199] to serf error codes. > > Thoughts?
See http://subversion.tigris.org/issues/show_bug.cgi?id=4368 for another example. Trunk gives: svn: warning: W120190: Error running context: An error occurred during authentication with 1.7/neon the error was: svn: E175002: Server sent unexpected return value (401 Authorization Required) in response to LOCK request for '/obj/repo/A/f' -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
