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