RE: Re-use connection for svn:externals

> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: woensdag 10 februari 2010 0:06
> To: Stefan Sperling
> Cc: Bert Huijben; Ivan Zhakov; C. Michael Pilato; Phillip Hellewell;
> dev_at_subversion.apache.org
> Subject: Re: Re-use connection for svn:externals
>
> On Tue, 2010-02-09, Stefan Sperling wrote:
> > On Tue, Feb 09, 2010 at 08:19:07PM +0100, Bert Huijben wrote:
> > > > Van: Ivan Zhakov
> > > > The only problem I see is RA session root relative paths [1],
> since we
> > > > end up with pool of connection for one repository but with
> different
> > > > session root. We may workaround it using convention that
> svn_client_*
> > > > RA sessions always rooted to repository root [2].
> > > Opening at repository root reintroduces issue #3242 (Authorization
> fails at repository root)
>
> Bert, please see the thread that Ivan linked: in particular this email
> and its replies: <http://svn.haxx.se/dev/archive-2009-10/0315.shtml>.
> They describe a way to manage this so that it isn't a problem.

This thread suggests using full urls everywhere. And the thread closes with the reasoning that this will cause all kinds of new security issues as we have to do the url encoding everywhere. (Encoding one time more than required or one time less than required introduces security bugs).

Always opening at the repository root and using repos_relpaths for further communication wouldn't have this issues, but has the potential of creating more issue #3242 like issues.

Looking at the rest of the thread:
Can't we just fix mod_dav_svn to allow opening an ra_session to the repository root in all cases?
(It looks like this would be simply allowing that initial OPTIONS request to succeed even if you don't have access to the root).

The '3 seconds delay' is most likely caused by the slow opening of HTTP sessions which walk up the repository to find the repository root. This case is already fixed in HTTPv2. (svn:// is much faster than this. And svn+ssh:// depends on other things).

(a svn_ra_session_dup() could help the dav ra layers here too)

I'm not sure if keeping ra_sessions open for really long times in svn_client_ctx_t is a good idea in all cases as in some clients svn_client_ctx_t lives for days. (E.g. AnkhSVN does that in Visual Studio).

We would have to start checking for broken connections in svn*:// sessions +- everywhere. (http and https are stateless, so these wouldn't have these problems.. They would only fail if the repository is moved; or upgraded to another major subversion version).

As I don't think we can do a real test for these conditions in our testsuite, keeping the sessions open will move the issue identification to the other subversion clients, which have to wait at least weeks for us to incorporate a fix.

+1 on keeping them open below a single svn_client_updateX() operation though as we can test that in our testsuite without any issues.

        Bert
Received on 2010-02-10 11:08:16 CET