> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: vrijdag 12 december 2008 1:16
> To: Hyrum K. Wright
> Cc: dev_at_subversion.tigris.org
> Subject: Re: Subversion Configurablility
>
> 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?
Every extra (2 state) knob gives twice as many configurations to test, so +1
to just optimize for speed, optimize for size and maybe some default state
in between.
> And knobs on the client should be *real* minimal.
+1 on that too. Especially when users use different svn clients next to each
other (as all my users do that)
Bert
>
> Cheers,
> -g
>
> 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&dsMessageI
> d=982966
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageI
> d=983139
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=983284
Received on 2008-12-12 11:43:00 CET