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

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 9 Jul 2013 10:25:30 +0200

On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote:
> The option doesn't seem like a big barrier when you're applying it to
> a handful of machines for yourself. Scale that effort up to a user
> base of 20,000 users and the option stops looking like a reasonable
> response. Resolving the proxy may not be possible in those cases as
> well because the developers and the people running the Subversion
> servers may have absolutely no control over the proxies. They may be
> proprietary and not even have a way to resolve this. If you're a
> large enterprise this solution just flat out doesn't help you much.

I think this is a very important point.

How many people use auto-props? Not many. Still, having auto-props
configured at the client side made configuring this feature correctly
in large deployments very inconvenient. Until 1.8 it requried central
control over every client configuration. This was a concern in several
companies I've visited.

How many people are using proxies that don't support chunked requests?
Probably not many. But the same argument applies.

> I agree that chunked requests are very good for us. But I want to do
> it in a way that is maximally compatible without making our users jump
> through hoops.


With so many other performance issues being fixed all the time,
I don't think we should be worried about one extra request.
We should be able to get the time spent on this extra request back
somewhere else.

'svn merge' in 1.8 opens more connections that 1.7 did, and that is
a performance hit but it didn't prevent the 1.8 release either.
Received on 2013-07-09 10:26:19 CEST

This is an archived mail posted to the Subversion Dev mailing list.