Listman wrote:
>
>
> 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..
Patches welcome.
>> 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...
No one is forcing anything down anybody's throat. Just because users choose to
upgrade to a newer version of a piece of software they receive for free does
*not* mean new features are being forced upon them.
> 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.
Again, patches welcome.
-Hyrum
Received on 2008-10-23 04:51:57 CEST