[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r34088 - trunk/subversion/libsvn_fs_fs

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 24 Nov 2008 16:15:16 -0800

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.


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.
>> --
>> Ivan Zhakov
>> VisualSVN Team
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

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 01:15:29 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.