Stefan Küng wrote:
> Valik wrote:
>> I've noticed that whenever I kill TSVNCache.exe or update TSVN,
>> everything will work fine for awhile. Working copies which normally
>> do not show the correct overlay until drilled into are suddenly
>> working just fine. However, after some time, these working copies
>> revert to their old behavior of not showing the correct status after a
>> commit operation. It seems to me like whenever I do something which
>> stops then starts the cache (Such as a reboot), after that, things
>> start acting up again. On the other hand, doing something such as
>> killing TSVNCache will cause it to work correctly for awhile.
>> Presumably, on shutdown, TSVNCache writes its cache information to
>> disk which is reloaded the next time it starts where-as when forcibly
>> terminated, it doesn't get this opportunity so it has to re-build from
>> scratch, correct? Maybe the cache is /too good/ and caching some
>> stale information?
>> Stefan, If you wish to provide a copy of TSVNCache with some form of
>> logging to try to determine where the incorrect behavior is coming
>> from, I would be willing to help by testing it.
> Did you use rev4858 or later for this testing? Because before, the cache
> could sometimes "forget" to watch the directories for changes.
Sorry about not replying sooner.
I've used 4858 for the last couple days. It seems (so far) that the
problem where committing on a top-level directory and then that
directory still showing as modified after the commit is gone. Hopefully
you have gotten that fixed as its been around for awhile. The cache
seems much better in this version.
However, as Peter has been reporting, I had a directory showing "no
modifications" even though files inside that directory were modified.
No amount of drilling into the directory and then backing out or hitting
refresh would fix the problem. Finally, when I committed the working
copy, the "no modification" icon switched to the "modified" icon after
the commit, despite the fact that there were no files in the entire
working copy which were modified.
The structure of the working copy is simple. Inside the project root
are 6 files and 1 sub-directory. Inside the sub-directory there are 6
more files. It was this sub-directory that was showing the "no
modification" icon even though there was 1 file inside it that was
modified. I committed from the root directory so all my changes in the
working copy were committed. Then the sub-directory switched to the
modified icon but all the files showed the correct icon.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Nov 6 17:54:53 2005