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

Re: Bug with the 1.4 icons?

From: Simon Large <simon_at_skirridsystems.co.uk>
Date: 2006-09-29 23:47:28 CEST

Stefan Küng wrote:
> Simon Large wrote:
>> Stefan Küng wrote:
>>> Andy Peters wrote:
>>>> 3) The icon update problem I'm seeing happens in any directory, both
>>>> on the local disk and on network shares, and in directories not
>>>> called temp.
>>> * kill TSVNCache.exe
>>> * check out a fresh working copy
>>> Do the overlays now still not show correctly?
>> I had an icon problem with 1.4.0 yesterday. In my case *every* file
>> and folder (including the .svn folder) got an InSubversion overlay
>> whether versioned, modified, unversioned or whatever. The only fix in
>> that case too was to kill the cache.
>> Would it be worth adding a mechanism to ask the cache to exit from
>> within TortoiseProc (preferably with the cache confirming that it is
>> exiting and not locked up)? This may look a bit lie we don't have
>> confidence in the cache, but it is not too dissimilar from the ability
>> to start and stop a service.
> As I mentioned before:
> If every item (files/folders, including the .svn folder) got a "normal"
> overlay then that means that the working copy is locked (e.g. due to
> another operation running on it, like update/commit/...). If that
> happens, the cache can't read the status, and the shell then just shows
> the overlay "normal" to indicate that it's a working copy. But once the
> working copy isn't locked anymore, the cache will re-crawl it and the
> overlays will be ok again. But, the cache will wait at least 10 seconds
> before trying to crawl that working copy again to avoid too many failed
> recrawls due to a longer operation in progress.

Strange. I'm not aware that any other svn operation was locking the WC,
although I don't remember the sequence of events that triggered it. I
did leave it for a while and jumped around other folders to see if they
were affected too (they weren't), before killing the cache. Strange too
that killing the cache should fix it if the lock was held by another
process. Sounds like the lock was held by the cache itself.

Does the shell put a normal overlay even on the .svn folder if the cache
cannot return status?


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Fri Sep 29 23:46:58 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.