On Thu, 13 Oct 2005, Greg Hudson wrote:
> On Thu, 2005-10-13 at 07:10 -0500, lundblad@tigris.org wrote:
> > +static svn_error_t *open_session(ra_svn_session_baton_t **sess_p,
> > + const char *url,
> > + apr_hash_t *config,
> > + svn_auth_baton_t *auth_baton,
> > + apr_pool_t *pool)
>
> > + sess->config = config;
>
> You're storing the config hash which was provided by the caller of
> svn_ra_open() and using it later. svn_ra_open() does not require that
> the config hash's lifetime last as long as the session, or that it not
> be changed after the svn_ra_open() call.
>
That's true and there is a simple way to get rid of this, since we don't
change the tunnel in the reparent call.
> In my vision of svn_ra_reparent(), the caller was made responsible for
> dealing with the case where the server does not support reparent
If you read your original comment in the issue, you'll see yourself
presenting two alternatives, so maybe your vision has changed over time:-)
Anyway...
> operations. I don't much like the idea of svn_ra operations
> "transparently" opening new connections when they have to, since opening
> a connection is often a user-visible operation.
It is true that opening a new connection might be visible to the user, but
what else should a client do if it asks for a reparent operation and it
fails? I can't imagine a reasonable situation where the client wouldn't
need to reopen in that case.
The problem with just failing in this case is that we spread the handling
of this case out to all callers instead of keeping it inside libsvn_ra_svn
(which is the only RA layer that doesn't support this function for old
"servers"). We have introduced other RA calls that might fail with "not
supported" errors, but that's when there is no workaround that's cheap.
For example, get_file_revs could be emulated, but to return all
information would be costly and some callers don't need all properties.
I think the situation is different for svn_ra_reparent.
Thanks for the review,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 16 21:53:10 2005