Listman wrote:
> if rep-sharing is a performance drain then please make it optional.
>
> Actually anything that is going to slow us should be optional (begin
> "svn is slow" rant yet again..)
So, does this mean that we shouldn't be storing deltas *at all* on the server,
but rather always storing the full text for every revision? One of the benefits
of Subversion over CVS in the bad ol' days was that we treated every file as
just a binary blob, and did deltification on every object. I doubt many people
want to sacrifice deltificiation for lower server CPU.
This leads me to a more general question that seems to be coming to a head: what
use cases should Subversion be optimized for? Please pardon the jumbled
collection of thoughts that follows as I attempt to explore this question.
Subversion is used in so many more places than we ever dreamed it would, and
each has their own needs. Some prefer economy of disk over CPU performance,
while others don't care about CPU, but require small network turnaround times.
Other users trust us to ship with reasonable defaults, and will just use those
whatever they be. Subversion can not, and should not, be all things to all people.
Adding new features usually requires a performance hit. Generally though, the
capability of the hardware increases to more than make up for whatever features
we add. We've traditionally been pretty conservative, and running 1.0 on
hardware of that time is definitely slower than running 1.5 on today's hardware.
I doubt the same can be said of many other projects.
Moore's "Law" is not a panacea for bad software, and I'm not suggesting we be
lazy in our coding practices, but I think that we can reasonably make
compromises when advancing the state of Subversion. No one is forcing anybody
to upgrade, and users are free to build customized versions of the software
which make different compromises than the one we ship.
(The one caution I *would* make, though, is that we don't want to be too
customizable. Doing so adds can easily lead to spaghetti-ified code, and user
confusion. As much as users enjoy tweaking knobs, at the end of the day, most
just want something that works out-of-the-box, and our default experience should
be a positive one.)
Anyway, if people want to rip the rep-sharing stuff out, go ahead. If
fsfs-packing should disappear, so be it. However, there is a substantial
segment of our userbase who wants (and arguably needs) these types of features,
just as there others who care about massive concurrency and server CPU usage.
Let's not leave them hanging high-and-dry.
-Hyrum
Received on 2008-10-23 04:21:34 CEST