On Oct 22, 2008, at 7:21 PM- Oct 22, 2008, Hyrum K. Wright wrote:
> 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.
actually i don't care about the delta's to be honest. i'd like to see
that an option too.
that would actually be awesome..
>
>
> 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.
i'm sure some folks find it useful, so why not just make it an option.
why force these
performance draining features down the throats of users that are
already struggling
with slowness issues...
please do a google for "slow svn" and see what the users are saying on
this issue
(word of warning, its a little ugly). features are great and svn
certainly has some
good ones, but the main issue with svn today is performance.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-23 04:37:16 CEST