On 26.02.2011 14:59, Stefan Küng wrote:
> On 26.02.2011 13:41, Gunnar Dalsnes wrote:
>> On 26.02.2011 09:43, Stefan Küng wrote:
>>> On 26.02.2011 00:50, Gunnar Dalsnes wrote:
>>>
>>>> -closing the log dialog is very slow, 3-4 seconds (annoying)
>>> When the log dialog is closed, it writes all data to the log cache file.
>>> But that should be fast.
>>> Do you have your %APPDATA% directory maybe not on the local drive? Or
>>> some app that scans everything that's written to disk?
>>>
>> APPDATA is on local drive. But TSVN 1.6 closes instantly. Since and all
>> my logs are cached, it should only write them the first time fetched.
>> After opening the log (pretty fast since cached, 2 seconds) TortoiseProc
>> continue to use approx 100% cpu in approx one minute, while apparently
>> not doing anything useful (bug). If I wait until TortoiseProc is done
>> using 100% cpu, the dialog closes instantly.
> You mean it uses all CPU after you start the log dialog?
Yes. This goes on for approx 1 minute or more.
> Try clearing the log cache. I've never seen such a behavior on all
> machines I use TSVN...
>
Clearing log cache did not help.
I can try to debug it, if you can't reproduce.
>>
>> This is not very different from tsvn/svn crashing and leaving the wd.db
>> in an inconsistent state (this is doomed to happen). I know it will
>> eventually happen, so I just provoked it to see how svn/tsvn would
>> handle it.
> This is *very* different. I've never got the wc.db into such a corrupted
> state, and I often interrupt/close the app during a command when I'm
> debugging.
>
> What you did is to mess around with internal data which broke svn
> commands. Which then lead to a database that's really corrupted. But a
> simple interruption/crash/whatever of a command would not lead to such a
> corruption.
>
> You wouldn't expect e.g., an xml-reader to be able to recover if you
> removed all closing tags in an xml file and then told it to open and
> process that file? Or maybe even 'cleanup' that corrupted file?
>
>
>> E:\svn\fishtalk tru4nk 1.7 test2>E:\svn\svn.exe stat
>> svn: E155037: Previous operation was interrupted; run 'svn cleanup'
>> E:\svn\fishtalk tru4nk 1.7 test2>svn cleanup
>> svn: '.' is not a working copy directory
>>
>> So, there is a bug both in svn and in tsvn in this case. svn recognice
>> the wc and says wc.db is corrupt, but svn cleanup does not recognize the
>> wc (bug)......
> Where does it say that the wc.db is corrupt?
>
With corrupt i mean that wd.db is in a invalid state because svn was
aborted/crashed, meaning there are "ghosted" locks or work items in the
database. sqlite is transactional and can't get currupt (unless a bug in
sqlite oe disk error). Problem is, svn is using several transactions,
probably because of performance or locking issues. That's ok with me, as
long as svn can "uncorrupt" the database by running cleanup (specs says
cleanup should delete ghosted lock and work items entries from the
wc.db, but this does not work).
> Because svn doesn't recognize it either.
It must be, since it's telling me the wc needs cleanup.
>> There is a similar bug registered for this as well:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=3585
>> Seems its very easy to corrupt the svn 1.7 wc/wc.db.
> I wouldn't say "very easy". Sure, if you mess around with internal data
> and remove files that svn requires to work or if you 'crash' the command
> at a very specific state, then the working copy can get corrupted.
I'm not arguing with that. I know wc.db can and will get "corrupted" at
times. The problem is tsvn not showing the Cleanup command, and svn
cleanup not working. But this may be all svn's fault. I will report the
cleanup bug to svn, and when/if fixed, tsvn may just work correctly too
(recognizing the WC, but "corrupt" and in need of cleanup).
Gunnar.
> Stefan
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2707795
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-02-26 16:43:10 CET