On 31.10.2011 11:15, Wolf Peuker wrote:
> Hi Stefan,
>
> On 31.10.2011 10:17, Stefan Küng wrote:
>> On 31.10.2011 09:21, Wolf Peuker wrote:
>>>
>>> If I understand it correctly, it seems that blocking a folder from being
>>> crawled may last for a maximum of 2 minutes. If I add the maximum
>>> crawling time (depending on the size of my working copy), I get the
>>> maximum time I've to wait shortly after my last edit (if it caused an
>>> error, which I cannot exclude nor surely detect)? ...and I don't know
>>> how long a full crawl takes... this does not feel so good. :-(
>>>
>>> Is there a way to explicitly re-trigger the crawling?
>>
>> When a path is unblocked, it is crawled immediately again.
> That's fine. But how can I, as a user, find out about it?
>
> Imagine, you're ready for a commit or update after your last edit. You
> have to wait (for how long?), then you proceed with update, commit...
>
> What is the great advance of background crawling, if I have to try a lot
> of things - even "wait some minutes" - as to be sure to be in sync with
> that magic? Sorry, I'm don't getting it right now.
>
> Don't misunderstand me: the *background magic is a good thing* if you
> have something better to do than waiting, *but sometimes* (if all your
> work is done, and you're waiting on it without any clue when it is
> ready) it's simply bad. So, what is the problem with a refresh button?
A cleanup also unblocks the path - after the cleanup has finished.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2869371
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-10-31 16:07:29 CET