[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: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-10-17 09:11:04 CEST

On Mon, 2005-10-17 at 07:48 +0200, Peter N. Lundblad wrote:
> I didn't say that. My main argument was that if a client reparents, it wil
> want to make the connection point to that new FS path, and if the reparent
> fails, it will have to reconnect anyway. Why not take that complexity out
> of all callers and put it into the only RA layer that needs it?

It just feels inelegant, and therefore error-prone. In my mind,
libsvn_ra_svn sessions are pretty tightly bound to network connections.
The code doesn't try to reconnect on a transient network failure, for
instance, because it sees the collapse of the network connection as the
collapse of the session. (Also because it's a stateful protocol and you
can't always get back to where you are.) And there's plenty of
precedent for returning "unsupported" from libsvn_ra functions, while
thre isn't much precedent for emulating unsupported operations in terms
of other operations.

I guess we can try it this way (you're fixing or have fixed the issue of
the lifetime of the config hash, right?) and see if it causes any

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 17 09:12:40 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.