> On 20.09.2009 13:19, Gunnar Dalsnes wrote:
> > Hi,
> >
> > Saw some strange things in the crawler: -one queue for "paths" (that
> > can be file or folder) and one queue for folders. This seems
> > unnecessary. Any special reason for this? If not, I will re-factor to
> > one queue.
>
> While those look almost the same, they're not. I tried once to use just
> one of those but failed - the cache didn't work anymore.
> Can't remember exactly why but I remember that I thought it was too much
> work to make it work with just one queue. I didn't even commit that change.
Since you had the same idea, it sounds like something worth trying.
>
> > -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).
>
> > 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.
> And caching is really necessary, otherwise the disk access would
> increase a *lot* (try it and you'll see).
If it is a good reason, no problem. I was just wondering.
Gunnar.
>
> 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=2397137
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-20 22:06:49 CEST