On Tue, Nov 25, 2008 at 8:02 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> David Glasser wrote:
>> I'm not clear on what was resolved here (I still think this should
>> default to off, since the space savings is only noticeable on very
>> large repositories, and it is an extra unnecessary moving part if
>> you're not really pressed for space, and slows down commits), but the
>> current status of trunk is confusing. The svn_config_get_bool calls
>> give FALSE as the default value, which would imply to me that it's off
>> by default, but the generated config file seems to have an uncommented
>> (!) line setting it to true. I don't think this is how we ever
>> generate our config files: we should only be generating commented
>> lines. This means that newly-created and newly-upgraded repositories
>> have the same default values; generating lines that disagree with the
>> code's defaults doesn't really make much sense to me.
>
> Good point. The initial reason for leaving it as default was so that older
> repositories didn't start using rep sharing. Now that we're protecting the rep
> sharing functionality with a conditional on the format number, I think we can
> safely switch the default for svn_config_get_bool() to TRUE. I've done so in
> r34413.
OK. But I think the comment should be reworded and the commented-out
line made to be "= false"... I think that's our usual pattern (ie,
"uncomment this to do something", not "commented thing describes the
default").
> On the larger topic of enabling rep-sharing by default: I still think it makes
> sense to do so. We say that it "slows down commits," but I think the amount of
> slowdown is less than the potential variation in network latencies, in other
> words, negligible. The real place where it could hurt is high-concurrency
> shops, which can choose to disable it as part of their tuning process. Our repo
> isn't very high concurrency, yet the space savings are over 10%, which is about
> about the same as the ASF repo.
>
> The out-of-the-box default should work for our simplest users, and I think this
> is the best choice for them. The Berkeley DB backend doesn't even *have* the
> option to turn off rep sharing, yet I haven't heard any concerns about it.
Well, sure, but adding rep-sharing to the BDB backend didn't involve
adding an entirely new piece of database technology with its own
non-trivial concurrency and consistency concerns. (And BDB wasn't
explicitly designed as "the simple backend with minimal prereqs that
works on the largest variety of filesystems, including NFS, AFS,
etc".)
--dave
>> On Fri, Nov 7, 2008 at 7:47 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>>> I'd like to keep it off by default until I see a solid case made with
>>> benchmarks etc that the space gain is more noticeable than the speed
>>> loss.
>>>
>>> (And I still want it reverted before 1.6 if the concurrency bugs aren't fixed.)
>>>
>>> --dave
>>>
>>> On Fri, Nov 7, 2008 at 1:16 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>>> On Fri, Nov 7, 2008 at 12:48 AM, Hyrum K. Wright
>>>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>>>> hwright_at_tigris.org wrote:
>>>>>> Author: hwright
>>>>>> Date: Thu Nov 6 13:43:15 2008
>>>>>> New Revision: 34088
>>>>>>
>>>>>> Log:
>>>>>> Allow FSFS rep-caching to be configurable.
>>>>> The question now becomes what's the default. Currently, it's set to "off"
>>>>> mostly due to status quo bias. However, I think there's a strong case for "on".
>>>>> The ones who want the better runtime performance are the ones who will probably
>>>>> feel more comfortable configuring their FS. These are the large,
>>>>> high-concurrency users, and there probably aren't too many of them.
>>>>>
>>>>> On the other hand, the small teams are ones who will just stick with whatever
>>>>> the default is, and are probably on more limited disk and hardware systems. It
>>>>> makes sense to enable rep-sharing by default for these users.
>>>>>
>>>> I'd like to keep this feature off by default. It will be regression if
>>>> we enable rep-sharing by default:
>>>> performance slowdown and possible colision and hacking. On other hand
>>>> is some kind of improvement for some groups of customers.
>>>>
>>>> So it's better prevent regression than introduce some improvement.
>
>
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-25 17:35:29 CET