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

Re: [PATCH] (alternate fix for issue 900)

From: mark benedetto king <bking_at_inquira.com>
Date: 2002-09-15 21:41:54 CEST

On Sun, Sep 15, 2002 at 08:15:22PM +0100, Philip Martin wrote:
> mark benedetto king <bking@Inquira.Com> writes:
> > What I'm getting at is that svn_repos_open can't tell when
> > to return that error, either, without peeking inside the
> > error in *exactly the same way* that we're describing as
> > inappriate for svn_ra_local__split_URL to do.
> >
> > Am I missing something?
> It's not exactly the same, svn_repos_open would not need to follow the
> error chain. It could just check err->apr_err, which is how all the
> other error checks work. Doing things differently inevitably raises
> questions. That doesn't mean your patch is wrong :)

I guess my concern is that one of the several layers between
apr_file_open() and svn_repos_open() might someday decide to wrap
up the error from apr_file_open (just like svn_repos_open itself
does, causing trouble in __split_URL).

What if we made the following change? Then, it is the reponsibility
of every error to know what apr_err, if any, triggered it. That
would allay my concerns.

Note that, IMO, this code merely memoizes the results of the
while(cause->child) loops in my previous patches, but maybe everyone
will find this approach more palatable. :-)

ndex: subversion/libsvn_subr/svn_error.c
--- subversion/libsvn_subr/svn_error.c
+++ subversion/libsvn_subr/svn_error.c Sun Sep 15 15:37:31 2002
@@ -102,6 +102,8 @@
   new_error->apr_err = apr_err;
   new_error->src_err = src_err;
   new_error->child = child;
+ if (child && !apr_err)
+ new_error->apr_err = child->apr_err;
   new_error->pool = this_pool;
 #ifdef SVN_DEBUG
   new_error->file = error_file;

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 15 21:49:07 2002

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.