On Thu, Jun 20, 2013 at 9:18 AM, Johan Corveleyn <jcor...@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/