On Mon, 25 Sep 2006, Garrett Rooney wrote:
> On 9/25/06, Daniel Rall <firstname.lastname@example.org> wrote:
> >On Mon, 25 Sep 2006, Garrett Rooney wrote:
> >> On 9/25/06, Daniel Rall <email@example.com> 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?
> I can see situations where both would be meaningful questions to ask.
We'll start with an svn_error_root_cause_is(), then (r21645).
Received on Tue Sep 26 00:50:55 2006
- application/pgp-signature attachment: stored