Return-Path: 
 <commits-return-31259-apmail-subversion-commits-archive=subversion.apache.org@subversion.apache.org>
X-Original-To: apmail-subversion-commits-archive@minotaur.apache.org
Delivered-To: apmail-subversion-commits-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 4C8D4109D8
	for <apmail-subversion-commits-archive@minotaur.apache.org>;
 Fri, 12 Jul 2013 01:42:35 +0000 (UTC)
Received: (qmail 56372 invoked by uid 500); 12 Jul 2013 01:42:35 -0000
Delivered-To: apmail-subversion-commits-archive@subversion.apache.org
Received: (qmail 56320 invoked by uid 500); 12 Jul 2013 01:42:35 -0000
Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@subversion.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@subversion.apache.org>
List-Post: <mailto:commits@subversion.apache.org>
List-Id: <commits.subversion.apache.org>
Reply-To: dev@subversion.apache.org
Delivered-To: mailing list commits@subversion.apache.org
Received: (qmail 56306 invoked by uid 99); 12 Jul 2013 01:42:34 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2013 01:42:34 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of gstein@gmail.com designates
 74.125.82.44 as permitted sender)
Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2013 01:42:29 +0000
Received: by mail-wg0-f44.google.com with SMTP id m15so7650520wgh.35
        for <multiple recipients>; Thu, 11 Jul 2013 18:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        bh=4SYGE5Mq4mLAKhfbTMCz2KEXCQuUqPcZjLicKkKPxV0=;
        b=UejUOhNRKgD4UBAjW9VRYI4BwQn/coxrb2jwR8t+2/0N68KvLC3lup6ZvNbzjKTd74
         9PzKP3bwtr6i1Pn7/ZBkwR0w2ZaA65ZFHV/8Y8by+sBzmxSydfJP/eY6iehkLAhHC+Ja
         EF9ACI79zeYrjlgOWr9tSq6daFoqut4LFOokSVPFpE2aHl+PkEnIJnXtzyldx5uoLq6n
         VjgTdaXZwtytNH9ndQmLQN3j9sEz/Y7/Tq/Rv+5S2wu2oQ3yejZWWdAtxGo2Nje6gUNd
         amGECI2jMkHNDRJbGyGPGUnKNL0pOfk5Dses3Ujm3CnXp41k83jZxxTxZCmmV9oPGC3C
         qg4A==
MIME-Version: 1.0
X-Received: by 10.194.243.101 with SMTP id wx5mr22588229wjc.49.1373593328579;
 Thu, 11 Jul 2013 18:42:08 -0700 (PDT)
Received: by 10.194.89.103 with HTTP; Thu, 11 Jul 2013 18:42:08 -0700 (PDT)
In-Reply-To: <20130712001149.1F3C3238888A@eris.apache.org>
References: <20130712001149.1F3C3238888A@eris.apache.org>
Date: Thu, 11 Jul 2013 21:42:08 -0400
Message-ID: 
 <CABD8fLWkt6Ugj_fwLRaERoAy8eOC9Q812h3G0ieU-0FAXtYfYQ@mail.gmail.com>
Subject: Re: svn commit: r1502401 - in
 /subversion/branches/tristate-chunked-request/subversion:
 include/svn_config.h libsvn_ra_serf/serf.c libsvn_ra_serf/util.c
 libsvn_subr/config_file.c
From: Greg Stein <gstein@gmail.com>
To: dev@subversion.apache.org
Cc: "commits@subversion.apache.org" <commits@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org

On Thu, Jul 11, 2013 at 8:11 PM,  <breser@apache.org> wrote:
> Author: breser
> Date: Fri Jul 12 00:11:48 2013
> New Revision: 1502401
>
> URL: http://svn.apache.org/r1502401
> Log:
> Reimplement the tristate http-chunked-requests config option on top of the
> latest trunk implementation of boolean http-detect-chunking.

Ugh. Why the rename? I spent a bunch of effort bringing the name in
line with dev@ thinking. This option primarily controls if/when we
detect for chunked request capability on the connection.

>...
> * subversion/libsvn_ra_serf/serf.c
>   (load_config): Switch to using the tristate option.

If keeping a tristate, then yeah. I think this is the right
implementation. Very clean, and we have the ability to spread the
detection across ra_serf rather than a spurious/additional OPTIONS
request.

>...

Much of this revision deals with changing the option name. I'm tending
to disagree with that change.

On the tri-state itself... I'll start a new thread.

Cheers,
-g