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

Re: Subversion Configurablility

From: Greg Stein <gstein_at_gmail.com>
Date: Thu, 11 Dec 2008 16:16:03 -0800

Short answer due to iPhone: I disagree. More knobs can create
confusion. Each knob has to be evaluated by the user/admin to
determine use and applicability. The knob better have some damned good
value before being offered.

All these knobs for the backend? I bet you could simplify with a
simple tristate: default, optimize for size, optimize for speed. Why
provide anything else? What other axises are actually relevant?

And knobs on the client should be *real* minimal.


On Dec 11, 2008, at 10:16, "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu
> wrote:

> I've been thinking a lot the past few weeks about the
> configurability of
> Subversion. Here are some thoughts.
> As Subversion has grown, we've seen it penetrate a lot of places
> where we didn't
> initially think it would go. One of the reasons for this, and a
> guiding
> principle of Subversion development, as been that it's relatively
> easy to
> install and get running, right out of the box. This has served us
> well, and we
> should continue to support this type of use.
> However, as the project continues to grow, it may be useful to look
> at giving
> our users a bit more control over some of the internals of
> Subversion. In 1.6,
> we're introducing fsfs.conf, which allows administrators to start
> tuning the
> performances of FSFS-based filesystems (rep-sharing, memcaching,
> etc.). When
> WC-NG rolls out, we will probably have a number of configurable
> options
> regarding pristine text-base storage. Smaller installations may not
> care about
> such things, but large deployments already have people dedicated to
> improving
> the performance of Subversion, and giving these users more knobs to
> tweak, if
> done correctly, can be a good thing.
> One example is the storage mechanisms on the server. I've seen FSFS-
> based
> installations which are CPU-bound, largely due to delta calculation
> and
> compression. Such users may want to increase disk usage to decrease
> CPU load by
> disable storing revisions as deltas. We'd still leave the current
> reasonable
> default, but give the "power users" a chance to change it if they
> wish.
> This is a specific example, but what do folks generally think about
> exposing
> more of the tunable parameters of Subversion to the outside world?
> -Hyrum
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=982966

Received on 2008-12-12 01:16:33 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.