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

Re: permissions (and other) problems

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-09-13 00:41:17 CEST

Branko ─Œibej <brane@xbc.nu> writes:

> > i'm leaning towards having the client call svn_async_clear, since
> > otherwise, you could get in the situation where SVN_ERR reset the
> > flag, but the error that was returned was ignored by something
> > further up the call chain (but still inside an svn function). i
> > believe there are places where we do ignore errors explicitly, so it
> > could theoretically happen...
> If SVN_ERR detects a cancelation, it must return an ERR_CANCELED error
> (perhaps wrapping the original error in that, but maybe not). That
> implies that SVN_ERR should check if the incomng error code is already
> ERR_CANCELED. It also implies that all places where we migh ignore
> errors have to be checked; cancellation shouldn't be ignored.

Well, using svn_async_cancel/svn_async_clear once the client calls
cancel it doesn't make much sense to call clear until all the
Subversion functions (that's in all threads) have returned. So if an
ERR_CANCELED error gets dropped, the next SVN_ERR will generate

There is some code that doesn't return an svn_error_t* at all, the
notify callback for example, where there is no option but to drop any

> Sure, that's a bit more work than just adding the cancellation error...

Almost everywhere that ignores an error should use svn_error_clear_all,
some places don't but that's usually a bug. We could change

   if (err)
     svn_error_clear_all (err);


   if (err)
     SVN_ERR (svn_error_clear_all (err));

and have svn_error_clear_all return an input ERR_CANCELED instead of
clearing it.

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 13 00:41:56 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.