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

Re: [trunk/merge tracking] Merge test #17

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-09-25 23:20:01 CEST

On 9/25/06, Daniel Rall <dlr@collab.net> wrote:
> 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?

I can see situations where both would be meaningful questions to ask.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 25 23:20:16 2006

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.