On Wed, Oct 22, 2008 at 11:12 AM, Listman <listman_at_burble.net> wrote:
>
> On Oct 22, 2008, at 12:42 AM- Oct 22, 2008, Ivan Zhakov wrote:
>
>> On Wed, Oct 22, 2008 at 10:29 AM, David Glasser
>> <glasser_at_davidglasser.net> wrote:
>>>
>>> On Tue, Oct 21, 2008 at 9:39 PM, Listman <listman_at_burble.net> wrote:
>>>>
>>>> On Oct 21, 2008, at 8:05 PM- Oct 21, 2008, Greg Stein wrote:
>>>>
>>>>> After you've changed the editor API, the wc_entry_t structure,
>>>>> migrated all old clients over to svn_checksum_t, and then switched the
>>>>> storage defaults over to sh1, *then* we can talk about "an easy
>>>>> switch".
>>>>>
>>>>> The simple fact is that we're going to be running around with md5
>>>>> checksums in hand for a long while. OR we double-compute, and I'm not
>>>>> willing to burn that much CPU to satisfy somebody's misguided
>>>>> preconception about md5 collisions. And double-compute generally means
>>>>> that we *carry around* both checkums. You wanna update all the APIs
>>>>> for that, too?
>>>>>
>>>>
>>>> +1 (on gregs position for this issue)
>>>>
>>>> lets not introduce more performance overheads based on a corner case.
>>>>
>>>> svn as it stands is way toooo slooow folks... please don't get
>>>> distracted
>>>> from
>>>> that fact. i'm dealing with 20 minutes commits, 15 minute status checks
>>>> etc
>>>> and my
>>>> users want to know why...
>>>>
>>>> also, svn already does way too many checksums from what i've been able
>>>> to
>>>> decipher.
>>>
>>> Well, if all you care about is speed, then revert the fsfs rep-sharing
>>> code entirely... it makes FSFS strictly less correct and presumably
>>> strictly slower, bringing only a space benefit which (for FSFS)
>>> appears to not be that large.
>>>
>> I agree with David: Subversion reliability is much more important than
>> speed. Also I do not understand why we so care about disk space for
>> repository: disk space is very cheap and become cheaper every day.
>> Think that priority list should be:
>> - Reliability
>> - Speed (CPU/memory usage)
>> - Disk space
>
>
>
> with todays SVN performance anyone with a need for centralized DM and large
> data-sets would be better off using P4.
>
> If SVN isn't reliable we lose, but if SVN is so slow that users aren't
> efficient and
> get frustrated we still lose.
We acknowledge speed problems on the client side. Do we have speed
problems on the server, though, is the question: some of the speed
problems on the client are being addressed.
Bye,
Erik.
---------------------------------------------------------------------
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-22 12:13:39 CEST