"Paul Burba" <pburba@collab.net> writes:
> Here is the behavior of svn_ra_get_locations() for each RA method:
>
> --------------------------------------------
>
> RA_LOCAL/RA_SVN:
>
> Returns SVN_ERR_FS_NOT_FOUND,
>
> - err
> apr_err 160013 int
> + message 0x00fba5c8 "File not found: revision 4, path
> '/A/D/G/rho_copy'" const char *
> + child 0x00000000 {apr_err=??? message=??? child=???
> ...} svn_error_t *
> pool 0x00fba568 apr_pool_t *
> + file 0x00708c5c
> "..\..\..\subversion\libsvn_fs_fs\tree.c" const char *
> line 669 long
>
> --------------------------------------------
>
> RA_SERF:
>
> Returns SVN_NO_ERROR, sets *LOCATIONS to an empty hash.
> svn_client__repos_locations() then returns a
> SVN_ERR_CLIENT_UNRELATED_RESOURCES error.
>
> --------------------------------------------
>
> RA_NEON:
>
> Returns two SVN_ERR_RA_DAV_PATH_NOT_FOUND errors,
>
> [...]
>
> --------------------------------------------
>
> How much of a problem is this inconsistency considered?
It's a problem, because it's even visible at the API level.
> *If* it is a problem...where is typically the best place to fix it:
>
> A) At the client level in ra.c:svn_client__repos_locations()?
>
> B) In the particular RA implementation, e.g.
> libsvn_ra_neon/get_locations.c:svn_ra_neon__get_locations()?
>
> C) Or possibly even on the server side, e.g.
> mod_dav_svn/reports/dav_svn__get_locations_report()?
The fix(es) should happen as close to the original (server-side)
source of the error as possible, IMHO.
> D) Simply account for the different errors in the callers of
> svn_client__repos_locations()?
(C) is best, then (B), then (A), then (D), would you agree?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 09:51:27 2007