Re: permissions (and other) problems

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
another.

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
ERR_CANCELED.

> 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);

into

   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