[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: TSVN 1.7 test drive

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Sat, 26 Feb 2011 14:59:44 +0100

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?
Try clearing the log cache. I've never seen such a behavior on all
machines I use TSVN...

>>> -icon overlays did not always show (the first time entering a folder).
>>> had to navigate out/in of the folder to trigger it (F5 did not help).
>> Sure: the first time you enter a folder the overlays are not shown
>> because their state isn't known yet, i.e. the status cache doesn't have
>> that data yet. Only after the status cache got notified of a working
>> copy it will scan it and have the overlay data ready.
>> But once that's done, the overlays should show up just fine.
>>
> Yup. But in TSVN 1.6 the overlays show automatically when the
> (recursive) status was available, without having to navigate out/in of
> folder.

That's the same in 1.7. As I said: if the status info is *not* available
then the overlays are not shown.

> Also, TSVN 1.6 would show green icons (no-changes) until the (recursive)
> status was ready. TSVN 1.7 not showing overlays in this case is an
> improvement me thinks. TSVN 1.6 showing green-icons while the
> (recursive) status was pending is not the right think to do. Further
> improvement would be to use its own overlay icon for showing status pending.

No more overlay icons are available. Sorry.

> But all this overlay stuff is nit picking:-) Works good enough.
>>> Other problem that may be TortoiseSVN specific (also sent to svn users
>>> list):
>>> For fun, I tried deleting all files in the pristine.
>> [snip]
>>
>> I'm sorry, but if you mess with internal data, anything can happen. You
>> can't expect everything to still work or assume that at least something
>> has still to work. You must not mess around inside the .svn folder at all.
>>
> 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?

> Tsvn does not recognize the wc at all (bug).

Because svn doesn't recognize it either.

> 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.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2707776
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-02-26 14:59:59 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.