[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: Branko Čibej <brane_at_xbc.nu>
Date: Tue, 15 Apr 2008 22:40:18 +0200

Peter Harris wrote:
> On Tue, Apr 15, 2008 at 11:00 AM, Branko Čibej wrote:
>> Harvey, Edward wrote:
>>> I challenge the idea that scanning the whole tree could possibly ever be "fast."
>> There is vast room for improvement here, but it implies a radical change in
>> WC design; not only centralizing metadata, but also turning the whole
>> scanning concept upside down. We'll have to give control of the scan to the
>> code that knows about the underlying organization (i.e., stop doing it in
>> editor drives), and likely have to stop trying to be streamy (i.e., trade
>> memory footprint for performance).
> If you're already turning everything upside-down, and willing to trade
> memory for performance, it might be worth thinking about an optional
> svn-client-daemon that uses
> inotify/FSEvents/FindFirstChangeNotification/etc. Then you'd only have
> to do a full scan once per boot; the OS would tell you about any
> further modifications.

Ouch. This introduces a long-living daemon that all other bits depend
on, that has to be stable and never make a mistake. Not a good way to
design robust software, IMHO. This falls under the "unnecessary
complexity" and "premature optimization" headings. I'm convinced that a
disk scan can be made orders of magnitude faster than ours is now, even
without FS-specific tricks (like, e.g., walking the $MFT on NTFS)

> Given that all OSs seem to have something inotify-like, and they are
> all slightly different, this seems like the sort of thing that APR
> should cover. My APR-fu is weak, however. I can't find anything like
> this in the APR docs.

It's not there.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-15 22:40: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.