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-11 19:16:25 CET