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

Re: svn commit: r16694 - in trunk/subversion: libsvn_client libsvn_ra libsvn_ra_dav libsvn_ra_local libsvn_ra_svn svnserve

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-10-16 21:50:28 CEST

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


> 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,

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

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.