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

How best to handle errors that differ depending on RA method

From: Paul Burba <pburba_at_collab.net>
Date: 2007-12-14 20:40:38 CET

In r28440, the fix for Issue #2877, I noticed
svn_client__repos_locations() returns different errors in the same
situation (passing in a URL which doesn't exist at the given peg
revision) depending on the RA access method used. Ultimately this is
due to the call to svn_ra_get_locations(),

/**
 * Set @a *locations to the locations (at the repository revisions
 * @a location_revisions) of the file identified by @a path in
 * @a peg_revision. @a path is relative to the URL to which
 * @a session was opened. @a location_revisions is an array of
 * @c svn_revnum_t's. @a *locations will be a mapping from the
revisions to
 * their appropriate absolute paths. If the file doesn't exist in a
 * location_revision, that revision will be ignored.
 *
 * Use @a pool for all allocations.
 *
 * @since New in 1.2.
 */
svn_error_t *svn_ra_get_locations(svn_ra_session_t *session,
                                  apr_hash_t **locations,
                                  const char *path,
                                  svn_revnum_t peg_revision,
                                  apr_array_header_t
*location_revisions,
                                  apr_pool_t *pool);

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,

- err 0x00f941b8
                apr_err 175007 int
+ message 0x00f941d0 "REPORT request failed on
'/svn-test-work/repositories/merge_tests-48/!svn/bc/4/A/D/G/rho_copy'"
const char *
- child 0x00f94138
                apr_err 175007 int
+ message 0x00f94160
"'/svn-test-work/repositories/merge_tests-48/!svn/bc/4/A/D/G/rho_copy'
path not found" const char *
+ child 0x00000000 {apr_err=??? message=??? child=???
...} svn_error_t *
                pool 0x00f94100 apr_pool_t *
+ file 0x0063f508
"..\..\..\subversion\libsvn_ra_neon\util.c" const char *
                line 543 long

--------------------------------------------

How much of a problem is this inconsistency considered?

*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()?

D) Simply account for the different errors in the callers of
svn_client__repos_locations()?

Any insights appreciated, thanks,

Paul

P.S. I fixed the specific problem I encountered in
libsvn_client/merge.c:get_mergeinfo_walk_cb() in r28487 using approach
"D". I understand that this "fix" is quite possibly addressing only the
symptom and not the cause, but having trunk not choke in some
circumstances seemed prudent considering all the folks working on 1.5
right now.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 14 20:48:22 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.