[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: performance enhancement by working copy svn server

From: Harvey, Edward <Edward.Harvey_at_patni.com>
Date: Tue, 15 Apr 2008 09:16:10 -0400

> I agree wholeheartedly with what John wrote in his reply. Scanning a
> disk can be done a lot faster than we're currently doing; centralized
> metadata helps, but there are obviously other tricks, too -- just as an
> example, look at how quickly Google Picasa can scan your whole disk for
> images!

I challenge the idea that scanning the whole tree could possibly ever be "fast." Yes, if you do it once and repeat it, then you're benefitting from the cache on the 2nd run - For my users that makes the difference between 10 minutes and 30 seconds. But they're only going to svn up (or whatever) ... once, twice, three times a day ... And the system is doing actual work in parallel. So they never benefit from the cache. Every time they scan the tree, it takes 10 minutes.

I considered seriously, writing a cron script to tar all the .svn dirs into /dev/null, and stat the whole working copy of every user, ever 5 minutes. Just to keep that info in cache. But I finally decided that was stupid enough to abandon it.

This e-mail message may contain proprietary, confidential or legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify us immediately at netadmin_at_patni.com and delete this mail.
Received on 2008-04-15 15:16:47 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.