You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by jc...@apache.org on 2013/06/20 03:09:20 UTC

svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Author: jcorvel
Date: Thu Jun 20 01:09:20 2013
New Revision: 1494829

URL: http://svn.apache.org/r1494829
Log:
Add information about serf skelta mode and the configuration knobs involved
to the 1.8 release notes.

Patch by: lgo
          (tweaked by me)

Modified:
    subversion/site/publish/docs/release-notes/1.8.html

Modified: subversion/site/publish/docs/release-notes/1.8.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.8.html?rev=1494829&r1=1494828&r2=1494829&view=diff
==============================================================================
--- subversion/site/publish/docs/release-notes/1.8.html (original)
+++ subversion/site/publish/docs/release-notes/1.8.html Thu Jun 20 01:09:20 2013
@@ -401,24 +401,124 @@ TCP connections to the server.
 Clients using neon will also work fine with this configuration.</p>
 </div>
 
-<div class="h4" id="serf-server-log">
-<h4>Server logs larger with serf clients
-  <a class="sectionlink" href="#serf-server-log"
+<div class="h4" id="serf-skelta-default">
+<h4>Skelta style updates are now the default
+  <a class="sectionlink" href="#serf-skelta-default"
     title="Link to this section">&para;</a>
 </h4>
 
-<p><em>This affects any server version, when accessed with a 1.8
-client.</em></p>
+<p>The svn 1.8 client with serf defaults to skelta mode for update
+operations (checkout, update, merge and export) instead of the bulk update mode
+used by previous versions. Skelta mode was introduced in Subversion 1.6.0 and
+improved in 1.8.0. It uses one HTTP request and response per resource that needs
+to be fetched from the server, whereas bulk update mode fetches all resources in
+one massive reponse.</p>
+
+<p>The main benefit of skelta mode is that it allows a correctly set up Apache
+server or intermediate proxy server to cache <tt>mod_dav_svn</tt>’s responses to
+handle later requests from the cache. This results in improved performance of
+svn client operations and reduced CPU usage on the server side. It also allows
+a more detailed audit of clients accessing resources in a Subversion
+repository.</p>
 
-<p>Because serf clients issue a larger number of HTTP GET requests
-than neon clients it is possible that serf clients cause quicker
-growth of httpd server logs than neon clients do. As of 1.7.3, 
-the httpd error logs may also grow more rapidly with serf clients
-than with neon clients; see
+<p>Skelta mode has some disadvantages:</p>
+<ul>
+<li>Apache server access log files will grow more quickly due to the larger
+number of requests and responses. As of 1.7.3, the httpd error logs may also
+grow more rapidly with serf clients than with neon clients; see
 <a href="http://svn.apache.org/viewvc?rev=1239697&amp;view=rev"
->r1239697</a>.</p>
+>r1239697</a>.</li>
+<li>Network traffic can increase drastically when Kerberos or NTLM
+authentication is used, as these add a 2 - 4 KB header per HTTP request and
+response.</li>
+</ul>
+
+<p>This release introduces two options to control if the svn client will use
+skelta or bulk update mode.</p>
+<p>
+<ul>
+<li> For the server administrator: The <tt>SVNAllowBulkUpdates</tt> directive for
+<tt>mod_dav_svn</tt> now accepts <tt>Prefer</tt>. This will advise the svn
+client to always use bulk update mode. All svn client versions with a default
+configuration (see table) will respect this preference.</li>
+
+<li>For the user: Set the new option <tt>http-bulk-updates</tt> in the servers
+runtime configuration file to <em>yes</em> to force the use of bulk updates,
+<em>no</em> to never use bulk updates. The default option <em>auto</em> makes
+svn use skelta mode with a 1.8 server (unless it has <tt>SVNAllowBulkUpdates</tt>
+set to <tt>Prefer</tt>), and bulk updates mode with
+older servers and 1.8 servers which prefer bulk updates.</li>
+</ul>
+</p>
+
+<div class="notice">
+<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
+<strong>Prefer</strong> if your server configuration does not allow an
+intermediate caching server - on your side or on the client's side - to
+successfully cache server responses.</p>
+</div>
+
+<p>Table explaining the mode used between each combination of svn client and
+server version and relevant configuration directives:</p>
+
+<table border="1">
+  <tr>
+    <th></th>
+    <th colspan="3">1.8 Server<br/>with SVNAllowBulkUpdates:</th>
+    <th colspan="2">1.7 and older Server<br/>with SVNAllowBulkUpdates:</th>
+  </tr>
+  <tr>
+    <th>Subversion Client</th>
+    <th>Off</th>
+    <th>On<sup>*</sup></th>
+    <th>Prefer</th>
+    <th>Off</th>
+    <th>On<sup>*</sup></th>
+  </tr>
+  <tr>
+    <td>1.8, <tt>http-bulk-updates: auto</tt><sup>*</sup></td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Bulk mode</td>
+    <td>Skelta mode</td>
+    <td>Bulk mode</td>
+  </tr>
+  <tr>
+    <td>1.8, <tt>http-bulk-updates: yes</tt></td>
+    <td>Skelta mode</td>
+    <td>Bulk mode</td>
+    <td>Bulk mode</td>
+    <td>Skelta mode</td>
+    <td>Bulk mode</td>
+  </tr>
+  <tr>
+    <td>1.8, <tt>http-bulk-updates: no</tt></td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+  </tr>
+  <tr>
+    <td>1.7 and older with neon<sup>*</sup></td>
+    <td>Skelta mode</td>
+    <td>Bulk mode</td>
+    <td>Bulk mode</td>
+    <td>Skelta mode</td>
+    <td>Bulk mode</td>
+  </tr>
+  <tr>
+    <td>1.7 and older with serf</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+    <td>Skelta mode</td>
+  </tr>
+</table>
+<p><sup>*</sup>Default configuration</p>
 
-</div>  <!-- serf-server-log -->
+</div>  <!-- serf-skelta-default -->
 
 </div>  <!-- neon-deleted -->
 



Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jun 20, 2013 at 9:18 AM, Johan Corveleyn <jc...@gmail.com> wrote:

>> Big +1. HTTP protocol options added mostly for debugging purpose, not
>> for regular users.
>
> Of course. I agree.
>
> Note that I didn't ask for adding http-max-connections to the release
> notes. But the skelta-mode and bulk updates behavior are not debugging
> options IMO, they have important user-visible (or admin-visible)
> effects. So I don't think these are just "every single feature or
> toggle".
>
> Remember all the discussions we had during 1.7 and 1.8 development
> about serf increasing the amount of requests and subsequent increase
> of access logs (which was by some considered quite important that we
> at least point admins' attention to it). If this skelta/bulk behavior
> isn't important enough to mention it in the release notes, why did we
> have all those discussions then?

I think it is worth documenting.  However, to answer your question,
all of those discussions led to the defaults which are very sane, IMO.
 A 1.8 client behaves like a 1.7 client when talking to an older
server.  It uses bulk-update mode as the table shows.  So that removes
all of those issues and surprises for those server admins.  A server
admin that installs 1.8 does "enable" this new behavior unless they
take advantage of the directive that can somewhat turn it off.

BTW, in our new Subversion Edge release we added some new features to
our logging configuration which allows the admin to decide not to log
many of those additional requests.  That idea and implementation also
came out of those discussions.

> Until now, I hadn't seen any good overview of the possible config
> knobs and their interactions (also with older servers) regarding the
> skelta/bulk update stuff. Okay, perhaps it's now documented in the svn
> book, but a lot of admins looking to upgrade from 1.7 to 1.8 will
> mainly look at the release notes to find out the important changes. I
> consider this an important change (mainly for the network traffic and
> logging effects that we discussed at length before).
>
> But, as I said: if others consider this too much clutter, or too
> confusing, feel free to revert. I won't lose sleep over it (I already
> have :-).
>
> (though: I think that table that lays out the possible combinations of
> client-side and server-side is great :-). So if this is yanked from
> the release notes, please put it somewhere else where it's
> discoverable by users.)

The only thing I did not like about the documentation is I thought it
was overly negative.  You kind of read it and think "why the hell did
they add this feature and why is it on by default?".  I really did not
like the strong recommendation about the proxy cache either.  I think
that is still unproven.  Justin did some tests that I think showed the
cache is used but no one, to my knowledge has done any real testing
and we do not even know how much or how little having one helps or
hurts.  One thing is certain, the number of existing customers already
using a proxy cache is 0, since it would not have worked.  So to say
those are the only users to use this new feature that is on by default
is crazy.

To me, the main thing an admin needs to be aware of is that a 1.8
client, talking to a 1.8 server will send significantly more requests
to the server.  The increased log files is something to be aware of,
but the main concern is probably for some authentication systems.  For
example, an LDAP or AD authentication that does not cache the
credentials lookup could really see a change in behavior.  If the
admin cannot "fix" those aspects of their configuration, then we have
a directive they can use to mitigate it.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jun 20, 2013 at 2:44 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Thu, Jun 20, 2013 at 4:40 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 06/20/2013 06:55 AM, Johan Corveleyn wrote:
>>> Fine for me. I actually don't care about this personally (at our
>>> workplace we're still lightyears away from upgrading, both client and
>>> server side). I just found it to be an important omission from our
>>> release notes (that actually should have been included way before
>>> release), and thought the information good enough, and at least better
>>> than nothing. But if people object, no problem.
>>
>> Note that there is often some benefit to *not* pointing out every single
>> feature or toggle we add.  In this case (as in the case of the
>> http-max-connections configuration option), I intentionally left these out
>> of the release notes.  Why?  Because I don't want folks reading those notes
>> to feel as if they *have* to fiddle with every knob simply because it
>> exists, and the default behaviors here should be sufficient.
>>
>> Remember, the release notes aren't *the documentation*, and as such, they
>> needn't be exhaustive.  They exist to advertise the benefits and (where
>> applicable) "gotchas" of the release, primarily for the benefit of people
>> who are existing Subversion users looking to upgrade to the new version.
>>
> Big +1. HTTP protocol options added mostly for debugging purpose, not
> for regular users.

Of course. I agree.

Note that I didn't ask for adding http-max-connections to the release
notes. But the skelta-mode and bulk updates behavior are not debugging
options IMO, they have important user-visible (or admin-visible)
effects. So I don't think these are just "every single feature or
toggle".

Remember all the discussions we had during 1.7 and 1.8 development
about serf increasing the amount of requests and subsequent increase
of access logs (which was by some considered quite important that we
at least point admins' attention to it). If this skelta/bulk behavior
isn't important enough to mention it in the release notes, why did we
have all those discussions then?

Until now, I hadn't seen any good overview of the possible config
knobs and their interactions (also with older servers) regarding the
skelta/bulk update stuff. Okay, perhaps it's now documented in the svn
book, but a lot of admins looking to upgrade from 1.7 to 1.8 will
mainly look at the release notes to find out the important changes. I
consider this an important change (mainly for the network traffic and
logging effects that we discussed at length before).

But, as I said: if others consider this too much clutter, or too
confusing, feel free to revert. I won't lose sleep over it (I already
have :-).

(though: I think that table that lays out the possible combinations of
client-side and server-side is great :-). So if this is yanked from
the release notes, please put it somewhere else where it's
discoverable by users.)

--
Johan

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Jun 20, 2013 at 4:40 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 06/20/2013 06:55 AM, Johan Corveleyn wrote:
>> Fine for me. I actually don't care about this personally (at our
>> workplace we're still lightyears away from upgrading, both client and
>> server side). I just found it to be an important omission from our
>> release notes (that actually should have been included way before
>> release), and thought the information good enough, and at least better
>> than nothing. But if people object, no problem.
>
> Note that there is often some benefit to *not* pointing out every single
> feature or toggle we add.  In this case (as in the case of the
> http-max-connections configuration option), I intentionally left these out
> of the release notes.  Why?  Because I don't want folks reading those notes
> to feel as if they *have* to fiddle with every knob simply because it
> exists, and the default behaviors here should be sufficient.
>
> Remember, the release notes aren't *the documentation*, and as such, they
> needn't be exhaustive.  They exist to advertise the benefits and (where
> applicable) "gotchas" of the release, primarily for the benefit of people
> who are existing Subversion users looking to upgrade to the new version.
>
Big +1. HTTP protocol options added mostly for debugging purpose, not
for regular users.


-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by "C. Michael Pilato" <cm...@collab.net>.
On 06/20/2013 06:55 AM, Johan Corveleyn wrote:
> Fine for me. I actually don't care about this personally (at our
> workplace we're still lightyears away from upgrading, both client and
> server side). I just found it to be an important omission from our
> release notes (that actually should have been included way before
> release), and thought the information good enough, and at least better
> than nothing. But if people object, no problem.

Note that there is often some benefit to *not* pointing out every single
feature or toggle we add.  In this case (as in the case of the
http-max-connections configuration option), I intentionally left these out
of the release notes.  Why?  Because I don't want folks reading those notes
to feel as if they *have* to fiddle with every knob simply because it
exists, and the default behaviors here should be sufficient.

Remember, the release notes aren't *the documentation*, and as such, they
needn't be exhaustive.  They exist to advertise the benefits and (where
applicable) "gotchas" of the release, primarily for the benefit of people
who are existing Subversion users looking to upgrade to the new version.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development


Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jun 20, 2013 at 11:50 AM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Thu, Jun 20, 2013 at 5:41 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Thu, Jun 20, 2013 at 3:27 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Thu, Jun 20, 2013 at 3:23 AM, Mark Phippard <ma...@gmail.com> wrote:
>>>> On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:
>>>>
>>>>> Author: jcorvel
>>>>> Date: Thu Jun 20 01:09:20 2013
>>>>> New Revision: 1494829
>>>>>
>>>>> URL: http://svn.apache.org/r1494829
>>>>> Log:
>>>>> Add information about serf skelta mode and the configuration knobs involved
>>>>> to the 1.8 release notes.
>>>>>
>>>>> Patch by: lgo
>>>>>          (tweaked by me)
>>>>>
>>>>> Modified:
>>>>>    subversion/site/publish/docs/release-notes/1.8.html
>>>>>
>>>>>
>>>>>
>>>>> +<div class="notice">
>>>>> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
>>>>> +<strong>Prefer</strong> if your server configuration does not allow an
>>>>> +intermediate caching server - on your side or on the client's side - to
>>>>> +successfully cache server responses.</p>
>>>>> +</div>
>>>>>
>>>>
>>>> I do not understand why we would make this recommendation. It seems overly strong.
>>>>
>>>> This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.
>>>>
>>>
>>> Agreed, let's yank that notice. As I said in my other reply (which I
>>> just sent before reading yours :-), this ignores the client-side
>>> optimization of not requesting pristines that are already at the
>>> client side.
>>
>> Okay, I removed it.
>>
>> As I said, I'll leave it to someone else to advertise the
>> pristine-fetching benefit.
>>
> I don't like such big last minute changes to release notes and will be
> glad if all change will be reverted until we find best wording for
> this details.

Fine for me. I actually don't care about this personally (at our
workplace we're still lightyears away from upgrading, both client and
server side). I just found it to be an important omission from our
release notes (that actually should have been included way before
release), and thought the information good enough, and at least better
than nothing. But if people object, no problem.

Feel free to revert (and drive the effort to find the best wording).

BTW: apparently the pristine-fetching optimization is actually present
in the release notes, in the Enhancements and Bugfixes section:
http://subversion.apache.org/docs/release-notes/1.8.html#pristines
(though that section doesn't say it's dependent on serf's
skelta-mode). But I think we should advertise this a bit in the "serf"
section as an important benefit (perhaps referencing the other
section).

--
Johan

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Jun 20, 2013 at 5:41 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, Jun 20, 2013 at 3:27 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Thu, Jun 20, 2013 at 3:23 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:
>>>
>>>> Author: jcorvel
>>>> Date: Thu Jun 20 01:09:20 2013
>>>> New Revision: 1494829
>>>>
>>>> URL: http://svn.apache.org/r1494829
>>>> Log:
>>>> Add information about serf skelta mode and the configuration knobs involved
>>>> to the 1.8 release notes.
>>>>
>>>> Patch by: lgo
>>>>          (tweaked by me)
>>>>
>>>> Modified:
>>>>    subversion/site/publish/docs/release-notes/1.8.html
>>>>
>>>>
>>>>
>>>> +<div class="notice">
>>>> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
>>>> +<strong>Prefer</strong> if your server configuration does not allow an
>>>> +intermediate caching server - on your side or on the client's side - to
>>>> +successfully cache server responses.</p>
>>>> +</div>
>>>>
>>>
>>> I do not understand why we would make this recommendation. It seems overly strong.
>>>
>>> This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.
>>>
>>
>> Agreed, let's yank that notice. As I said in my other reply (which I
>> just sent before reading yours :-), this ignores the client-side
>> optimization of not requesting pristines that are already at the
>> client side.
>
> Okay, I removed it.
>
> As I said, I'll leave it to someone else to advertise the
> pristine-fetching benefit.
>
I don't like such big last minute changes to release notes and will be
glad if all change will be reverted until we find best wording for
this details.

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jun 20, 2013 at 3:27 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, Jun 20, 2013 at 3:23 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:
>>
>>> Author: jcorvel
>>> Date: Thu Jun 20 01:09:20 2013
>>> New Revision: 1494829
>>>
>>> URL: http://svn.apache.org/r1494829
>>> Log:
>>> Add information about serf skelta mode and the configuration knobs involved
>>> to the 1.8 release notes.
>>>
>>> Patch by: lgo
>>>          (tweaked by me)
>>>
>>> Modified:
>>>    subversion/site/publish/docs/release-notes/1.8.html
>>>
>>>
>>>
>>> +<div class="notice">
>>> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
>>> +<strong>Prefer</strong> if your server configuration does not allow an
>>> +intermediate caching server - on your side or on the client's side - to
>>> +successfully cache server responses.</p>
>>> +</div>
>>>
>>
>> I do not understand why we would make this recommendation. It seems overly strong.
>>
>> This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.
>>
>
> Agreed, let's yank that notice. As I said in my other reply (which I
> just sent before reading yours :-), this ignores the client-side
> optimization of not requesting pristines that are already at the
> client side.

Okay, I removed it.

As I said, I'll leave it to someone else to advertise the
pristine-fetching benefit.

--
Johan

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jun 20, 2013 at 3:23 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:
>
>> Author: jcorvel
>> Date: Thu Jun 20 01:09:20 2013
>> New Revision: 1494829
>>
>> URL: http://svn.apache.org/r1494829
>> Log:
>> Add information about serf skelta mode and the configuration knobs involved
>> to the 1.8 release notes.
>>
>> Patch by: lgo
>>          (tweaked by me)
>>
>> Modified:
>>    subversion/site/publish/docs/release-notes/1.8.html
>>
>>
>>
>> +<div class="notice">
>> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
>> +<strong>Prefer</strong> if your server configuration does not allow an
>> +intermediate caching server - on your side or on the client's side - to
>> +successfully cache server responses.</p>
>> +</div>
>>
>
> I do not understand why we would make this recommendation. It seems overly strong.
>
> This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.
>

Agreed, let's yank that notice. As I said in my other reply (which I
just sent before reading yours :-), this ignores the client-side
optimization of not requesting pristines that are already at the
client side.

--
Johan

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jun 19, 2013 at 9:23 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:
>...
>> +<div class="notice">
>> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
>> +<strong>Prefer</strong> if your server configuration does not allow an
>> +intermediate caching server - on your side or on the client's side - to
>> +successfully cache server responses.</p>
>> +</div>
>
> I do not understand why we would make this recommendation. It seems overly strong.
>
> This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.

Exactly. Our defaults *should* be the optimum solution for the
majority of deployments. We should not advise *any* changes away from
those defaults.

If that is somehow untrue, then we have chosen the wrong defaults.

-g

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Mark Phippard <ma...@gmail.com>.
On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:

> Author: jcorvel
> Date: Thu Jun 20 01:09:20 2013
> New Revision: 1494829
> 
> URL: http://svn.apache.org/r1494829
> Log:
> Add information about serf skelta mode and the configuration knobs involved
> to the 1.8 release notes.
> 
> Patch by: lgo
>          (tweaked by me)
> 
> Modified:
>    subversion/site/publish/docs/release-notes/1.8.html
> 
> 
> 
> +<div class="notice">
> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
> +<strong>Prefer</strong> if your server configuration does not allow an
> +intermediate caching server - on your side or on the client's side - to
> +successfully cache server responses.</p>
> +</div>
> 

I do not understand why we would make this recommendation. It seems overly strong. 

This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.

Mark

Re: svn commit: r1494829 - /subversion/site/publish/docs/release-notes/1.8.html

Posted by Mark Phippard <ma...@gmail.com>.
On Jun 19, 2013, at 9:09 PM, jcorvel@apache.org wrote:

> Author: jcorvel
> Date: Thu Jun 20 01:09:20 2013
> New Revision: 1494829
> 
> URL: http://svn.apache.org/r1494829
> Log:
> Add information about serf skelta mode and the configuration knobs involved
> to the 1.8 release notes.
> 
> Patch by: lgo
>          (tweaked by me)
> 
> Modified:
>    subversion/site/publish/docs/release-notes/1.8.html
> 
> 
> 
> +<div class="notice">
> +<p>For 1.8 servers, set <strong>SVNAllowBulkUpdates</strong> to
> +<strong>Prefer</strong> if your server configuration does not allow an
> +intermediate caching server - on your side or on the client's side - to
> +successfully cache server responses.</p>
> +</div>
> 

I do not understand why we would make this recommendation. It seems overly strong. 

This whole section paints Serf in a really negative way as it makes it sound like skelta mode has little value.

Mark