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

RE: Re: cache crawler refactor thougths

From: Gunnar Dalsnes <hardon_at_online.no>
Date: Tue, 22 Sep 2009 04:36:58 -0700 (PDT)

> On 20.09.2009 22:44, Gunnar Dalsnes wrote:
> >>
> >> 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.
> >
> > I see.
> >
> >>
> >> Think about a local property modification: if you revert that
> >> modification, neither .svn\entries nor .svn\dir-prop-base will change...
> >
> > True... But if we in addition process changes inside .svn\props, then we should have all changes of interest?
>
> That would work, but unfortunately it doesn't :)
> The problem here is that the file .svn\props doesn't always exist. It
> isn't created automatically, only if there actually are properties. And
> if the properties get removed, the file can vanish again.
> So how would you compare the file dates if the file doesn't exist?

I don't say we should. If a file in .svn\props folder is added, removed or changed, we should, as today, invalidate (and then ask for) status of parent folder (self).

With "process changes" I mean added to the crawler queue(s) in the first place. How the crawler deals with the changes would be much like today, but the improvement would be to have much less changed queued.

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=2397748

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-22 14:45:29 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.