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

Re: [TSVN] Very long time to crawl WC.

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2005-11-30 10:47:32 CET

On 11/30/05, Joseph Galbraith <galb@vandyke.com> wrote:

> Do I understand correctly that when the cache gets a file
> change notification, it re-crawls that section of the file
> hierarchy? Or does it only re-get status on files that
> are reported as having been changed?

It recrawls the folder where the modified file is in. That's because
svn_client_status() always gets the status of all files in a folder,
no matter if you specify the folder of a file within in the parameters
(it just will filter out the status info of all other files if you
don't specify the folder).

> If it re-crawls for a change notification, what if we used
> a simple named mutex to serialize activities?
>
> So the cache would grab the mutex before it starts a crawl,
> and TSVN proper would grab the mutex before it started an
> update/checkout or other command that would trigger a-lot
> of changes.

I thought of that too. But it's risky and not quite as easy to
implement as you might think right now:
- the cache is shared between *all* users on the computer the cache runs
- you can have multiple svn operations running at the same time and
working copy (i.e. several instances of TortoiseProc). So a mutex
wouldn't be enough, you'd have to *count*, or one TortoiseProc could
release a mutex which another instance created. (semaphores are
needed)
- what happens if TortoiseProc crashes without releasing the
semaphore? The cache would be prevented from crawling forever?
- a simple semaphore/mutex/whatever wouldn't be enough: stopping the
cache globally isn't a good idea, we should only stop it for certain
paths. So we'd have to assing a path somehow to the "lock".

> It wouldn't be perfect as it wouldn't handle the command line
> client and the locking granularity is pretty big... but it
> would pretty well eliminate the cache and TSVN competing
> with each other.

Oh yeah, other svn clients exist too ;)

> Another possibility (if the svn apis let you) would be to have
> check to see if the working copy is locked before starting a
> crawl.

In such a case, the crawler would simply return immediately because
svn_client_status() would return with an error.

Stefan

--
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Nov 30 10:59:59 2005

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