At 22:32 31/01/2005 +0100, you wrote:
>However, it still takes a very long time until all the folder icons show
>the correct status. When looking with filemon.exe I see that TSVN does a
>full-text file compare on all files in my working copy. I will post more
>info in a separate mail.
That suggests that you are suffering from a known problem with SVN, which
occurs if its 'entries' file date doesn't match the file date. When this
happens, it tests whether files are unmodified by comparing MD5 hashes
rather than dates. This can be incredibly expensive! The 'problem' is not
that this MD5 technique is used, but that there's no simple or automatic
way of getting the dates corrected again, without doing another
checkout. (Presumably doing a delete and then update of the files also
fixes this, but I don't know.)
Simon has been asking questions about this issue on the SVN list, and I
understand that it will be dealt with in 1.2.
>Sorry but what is a POV?
Point of view. You've clearly never worked on joystick development!
>And I had no chance following "The Longest Thread Ever"(tm) on the mailing
>list because I had some other work to do. And you can not expect every
>user in the world to follow the mailing list.
No, but nor every (!) developer to *re*write lengthy techical stuff which
they've just recently done.
>I am reading the list with a news reader on gmane.org and only read the
>mails/threads that I am interested in. If I have lost my permission to
>post about the status cache by not reading that thread then I apologize
>and wait until the feature has been officially released.
Don't overreact. I did actually do you the courtesy of including a brief
summary of how it worked in my reply.
>I have a different opinion here. When I set TSVN to recurse into folders
>to get the status then I am tempted rely on TSVN showing a modified status
>when the folder contains modified items. I have a quick look at the status
>and "know" there is nothing to commit. THat's the whole point of this new
>cache, isn't it?
Well, the whole point of the cache is to improve performance for users of
the shell, and potentially make recursive directory status useable. Which
in general it isn't at the moment. I don't believe that the current
'synchronous' approach to getting recursive status will ever be fast-enough
to be widely adopted. I find that the 'lazy asynchronous' approach in the
new cache leaves the shell useable, but provides the recursive data soon
enough to be useful. I suspect that your impression of this is being
coloured by the 'file date' issue in SVN, which is making the recursive
fetch very slow on your WC.
There is another problem at the moment that it's hard to tell when the
cache has finished the recursive update, so one never quite knows when to
trust the overlays. The only suggestions which have been made so far
involve having a new icon overlay which means 'not yet updated', but we
don't really feel that we can spare this very scarce resource.
>Ok, I stop this here, since it has all been discussed already...
Unlike all the previous discussors (with the exception of me), you're
actually discussing experience of running it, which is very useful. If you
can deal with the slow-status issue on your WC, I would be interest to know
if it improved the performance.
Cheers,
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jan 31 22:55:42 2005