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

Re: patch: directory watcher always ignored the first file notify entry

From: monster <gdalsnes_at_gmail.com>
Date: Wed, 26 Aug 2009 16:48:23 -0700 (PDT)

I did some more testing and found something weird:

I commented _all_ calls to CSVNStatusCache::Instance
().AddFolderForCrawling, then I added one call when creating the
dirEntry in GetDirectoryCacheEntry:

                    if (!path.IsEmpty() && path.HasAdminDir())
                                        {
                                                CSVNStatusCache::Instance().AddFolderForCrawling(path);
// watcher.AddPath(path); //the crawler does this too
                                        }

I also had to comment if (SetHoldoff()) in FolderCrawler.cpp, this
logic doesn't hold anymore with only one crawl request per dirEntry.

Now it matches my logic with a dirEntry should be crawled just once
(except until we get a file change notification), and it seems to work
well too, fastest tsvncache I ever seen. It would require more testing
thou, to discover if the functionality is 100% equivalent with the old
code.

Gunnar.

On Aug 26, 8:18 pm, Stefan Küng <tortoise..._at_gmail.com> wrote:
> On 26.08.2009 14:46, monster wrote:
>
>
>
>
>
>
>
> >> This is actually needed. You might not have noticed anything wrong if
> >> you don't have modifications in a subfolder
> > I have\had when testing (still running with this code commented).
>
> >> and/or not killed the cache
> >> process so the cache is not used.
> > Sorry, don't understand.
>
> >> Without this crawling, only those folders that are asked for their
> >> status from explorer have their status actually read. But we want the
> >> recursive status, so we have to crawl the subfolders of those folders
> >> explorer asks the status for too.
> > Yes, (I think) I understand the logic behind the code. But I have been
> > running for 2 days now with that code commented and I have been unable
> > to see any difference (except for less crawling). My theory is that
> > the recursive status for the dirEntry is already fetched by a
> > recursive crawl earlier, possibly here:
>
> >            if ((!bFetch)&&(m_entriesFileTime))
> >            {
> >                    CSVNStatusCache::Instance().AddFolderForCrawling
> > (m_directoryPath.GetDirectory());
> >                    return CStatusCacheEntry();
> >            }
>
> > And when the recursive status for a dirEntry have been retrieved by
> > (an initial) crawl _once_, there should be no need to crawl again
> > (until we get a file change notification). Possibly this crawl is\was
> > a workaround for the file notify changes not working correctly?
>
> > It would be nice if you (or someone else) tried commenting this code
> > too, to (un)verify that my observations are correct.
>
> I'll do some more testing. Seems I can make this work by fixing another
> small issue in the crawler (crawler not waking up from sleep).
> If this works, I'll commit the changes tomorrow.
>
> 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&dsMessa...
>
> To unsubscribe from this discussion, e-mail: [dev-unsubscr..._at_tortoisesvn.tigris.org].

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2387744

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-08-27 07:03:52 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.