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

Re: svn commit: r1415864 - /subversion/trunk/subversion/libsvn_ra_serf/update.c

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: Sat, 1 Dec 2012 13:48:08 -0500

On Sat, Dec 1, 2012 at 12:00 PM, Mark Phippard <markphip_at_gmail.com> wrote:

> I feel pretty strongly that we should at minimum use the send-all
> approach when talking to pre-1.8 servers. Even though in some
> situations it could still offer good performance. I just think it
> would be more respectful to our users (server admins in this case) to
> not change this behavior in a way that could surprise them. Maybe we
> could come up with exceptions, such as older servers that are using
> the SVNAllowBulkUpdates off directive. In that situation we should
> use the new behavior since that is basically what that directive is
> asking for.
>

Without a lot of concrete feedback that parallel updates should be removed
by default, I strongly believe that we should not be conservative on this
issue. The issue here is not one of compatibility - ra_serf has been
around for years and can talk just fine to older servers (way back to prior
to 1.0 servers actually). The only argument against altering the default
behavior is that there might be an admin of a high-traffic site somewhere
that might suddenly be shocked by more HTTP requests coming in. I honestly
have little to no sympathy for such an admin who doesn't properly
understand how to manage a large installation - they likely have other
issues that they are not paying attention to. Until we have hoards of
users coming in and complaining about this, I think it's silly to be
conservative here.

I'm definitely not against giving knobs to the client or to the admin in
weird corner cases (provided someone cares enough to write that up), but I
strongly believe that for now we should do the right thing out of the box
in 1.8 - which is to utilize parallel updates. -- justin
Received on 2012-12-01 19:48:44 CET

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.