On Wed, Oct 22, 2008 at 12:32 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>>>
>>> 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
>
> I agree, but only to the extent that this is not outrageous: I've got
> a repository of 27MB (CVS) which explodes to around 500MB (disk use)
> in Subversion. When you're trying to sell a system to die hard CVS
> users, this becomes a loosing argument: Subversion will probably be
> another resource hog, while CVS is really "simple".
>
> BTW: Do we have that many CPU speed problems? I thought our speed
> issues are with I/O (at least client side).
>
Yes, we have problems with CPU on server side. Especially on with
commiting large files to FSFS repository.
One of our user reported that he cannot even login to server while
Subversion performing commit:
http://groups.google.com/group/visualsvn/browse_thread/thread/bf67c6adf3a6e6cf
I tested and had the same results, but that was with Subversion 1.4.x.
--
Ivan Zhakov
VisualSVN Team
---------------------------------------------------------------------
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 19:03:35 CEST