On Mon, 25 Sep 2006, Garrett Rooney wrote:
> On 9/25/06, Daniel Rall <dlr@collab.net> wrote:
>
> >Does this seem unreasonable to anyone?
> >
> >Index: subversion/include/svn_error.h
> >===================================================================
> >--- subversion/include/svn_error.h (revision 21630)
> >+++ subversion/include/svn_error.h (working copy)
> >@@ -148,6 +148,13 @@
> > */
> > void svn_error_compose(svn_error_t *chain, svn_error_t *new_err);
> >
> >+/** Return whether @a apr_err exists as a cause of an error in @a
> >+ * err's chain (e.g. it or its children).
> >+ *
> >+ * @since New in 1.5.
> >+ */
> >+svn_boolean_t svn_error_chain_contains(svn_error_t *err, apr_status_t
> >apr_err);
>
> I'd rather see something like
>
> svn_boolean_t svn_error_root_cause_is(svn_error_t *err,
> apr_status_t apr_err);
>
> It seems like it more closely matches what you're really looking for.
That's what I originally called it, but the implementation would be
slightly different: you'd walk down the error chain until you hit the
last error in the chain, then compare against its code against your
APR_ERR parameter.
In practice, either implementations would work for the merge-tracking
branch -- the svn_wc_adm_retrieve() API is documented to return only
the SVN_ERR_WC_NOT_LOCKED error. The "real" error is somewhere
underneath that. Whether or not SVN_ERR_WC_PATH_NOT_FOUND needs to be
the final root cause for svn_client__get_prop_from_wc() to squelch the
error and keep on chugging is a matter of opinion.
Maybe we want both? Any other opinions on which version I should use
on the merge-tracking branch?
- application/pgp-signature attachment: stored
Received on Mon Sep 25 23:17:16 2006