Brandon Ehle wrote:
>> BTW - I find the WC performance to not be that bad relative to the benefit
>> of the "svn diff" and "svn status" performance win due to the text base.
>> Now, I do not use Windows much so I do not suffer from the filesystem
>> performance issues that come up there.
>>
>
> I typically run into problems when the working copy contents are over
> 20GB (40GB with text base). My assumption is that if you have a working
> copy that large, your project should be able to afford a fast server and
> Gigabit Ethernet to it. For large files like movie clips, a "svn diff"
> is not all that useful anyway. Mostly you just want to find out if the
> file is modified.
Ahh, maybe the right answer here is that certain files can be marked as
"no text base" due to the fact that it is of less use. Those files would,
however, need some hash match feature (MD5/SHA1/etc) such that "svn status"
would be fast.
Even more interesting is how to handle the commit process. A large file, even
MPEG video, that has been changed is still a lot of data to send. It would be
good if the server did not need to do the diff operation but then doing the
diff operation on the client would mean significant network traffic.
I wonder where the best trade-off is here. In one case there is more local
disk space used but less server resources, in the other the server resources
are larger and the network usage is larger but significant savings in local
disk.
Generally I would say that costs in items that scale "naturally" is better
than in central systems, but there is a valid argument to be made that for
some content, the text base really is a significant cost and of minimal
benefit.
The real question now is what the cost of the complexity in the WC handling
would be to implement something to address this...
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 16 00:35:45 2006