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
