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

Re: cache crawler refactor thougths

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Sun, 20 Sep 2009 22:21:29 +0200

On 20.09.2009 22:05, Gunnar Dalsnes wrote:
>>> -All paths inside admindirs are crawled except \tmp\ \tmp and
>>> \log. This seems weird since GetStatusForMember only care about
>>> changes to .svn\dir-prop-base and .svn\entries, so I don't see
>>> the point in crawling anything but changes to these two. I will
>>> change this if no objections.
>> GetStatusForMembers uses those two files to determine whether it
>> has to fetch the status again (i.e., whether an file/folder has
>> changed). Paths inside admindirs are never crawled, but they're
>> added to the queue. Because those are added to the queue by the
>> directory watcher, and we have to catch changes to more than just
>> the two files to catch all changes: don't forget about revert and
>> commit. When reverting, neither entries nor dir-prop-base will
>> change.
> Yes, but then files outside the .svn folder will change, and we will
> off course process those. I'm only talking about changes inside .svn
> folders.
>> And with a commit, the file itself won't change.
> Yes, but then .svn\entries or .svn\dir-prop-base will change, and I
> suggest, If the change is inside a .svn dir, we process only those
> two.
> So, if we process changes to all files\folders outside .svn dirs, and
> dir-prop-base|entries in .svn dirs, we should in total have caught
> all changes of interest (unless I'm missing something).

I remember now how the two queues differ: the one filled by the
directory watcher is used to fetch the status in a forced way, while the
other queue is used to crawl less extensive.

Think about a local property modification: if you revert that
modification, neither .svn\entries nor .svn\dir-prop-base will change...

>>> One other thing: The cached flags in CTSVNPath are scary! Got
>>> several random assert\errors because of this. Caching of these
>>> flags, at least in TSVNCache, maybe should have been disabled?
>>> Any idea what positive impact this caching had on performance?
>> I doubt you got the assers because of the caching but due to race
>> conditions. You see, it's perfectly possible to get a 'true'
>> returned when checking whether a file exists, but then even one
>> statement later the file has been deleted by another process.
> But if we didn't cache existence, the second call would return the
> correct value, because you never know when the user (or some other
> process) can delete the file.

Yes, but then the second call would have to again access the disk! And
since we use a lot of those calls, caching really improves performance.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-20 22:21:34 CEST

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

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