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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2397147
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-20 22:21:34 CEST