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.
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.
> 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.
Received on 2008-11-25 17:02:51 CET