Re: why does tortoise, wcng and cygwin break from icon caching?

On 06.07.2012 14:41, Johan Corveleyn wrote:

> Ok, but I suppose that's mainly because of eol-style=native issues:
> your cygwin client may have a different idea about what the native
> eol-style is ... I don't think locking of the working copy (or working
> copy database) has been considered when this faq entry was written ...
>
> BTW: I have also recently recommended my users to make sure icon
> caching is disabled if they have TSVN installed. My users are mainly
> using IntelliJ IDEA with svnkit, and they also sometimes experience an
> E200030 error ("svn: E200030: BUSY" [1] in this case). Though I'm
> really shooting in the dark with this recommendation: I don't know if
> TSVNCache is involved at all (it's just a guess: trying to reduce the
> components on the system that may potentially be messing with the
> working copy at the same time) -- it may just as well be an internal
> svnkit or IntelliJ IDEA problem (some kind of multithreaded access
> inside IDEA that's not properly synchronized ... I don't know at this
> point).
>
> Anyway, just wanted to point that out. I have actually no idea what
> TSVNCache does with the working copy: does it query the database, what
> kind of locking effect it has, what if querying the wc.db takes a long
> time ... ? Can TSVNCache block out other clients from accessing or
> modifying the working copy?
>
> [1] http://youtrack.jetbrains.com/issue/IDEA-85496

Here's a quick overview of what the TSVNCache.exe process does:

It answers the shell extension of TSVN when it asks for the status of
individual files to show the overlay icons.
So when the shell asks for a status, the cache process first checks if
it already knows that status and if it does, that status is returned.
If it doesn't know the status yet, it returns 'unversioned' immediately
so the shell isn't blocked. But the path for which the status isn't
known yet is then passed to another thread that calls
'svn_client_status5' for the parent directory of that path. While doing
that, it also finds out where the working copy root is of that path: the
wc root paths are then added to a monitor list. The cache process
monitors all wc roots it finds for changes. If the system reports a
change in a file below a wc root, those paths are then added to the same
crawling thread that calls 'svn_client_status5' to fetch/refresh the status.

The status cache process uses only a few svn API's, mainly
'svn_client_status5' and 'svn_client_proplist' and 'svn_client_propget'.
Property reading is required since 'svn_client_status5' does not return
information about the svn:needs-lock property.

In 1.6, all these API's didn't lock the working copy. But in 1.7 I think
svn_client_status5 does for a short time.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net