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.
>> -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.
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.
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.
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)......
Tsvn does not recognize the wc at all (bug).
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.
>> BTW: does someone have svn 1.7 binaries for windows? Then I can test if
>> svn cleanup works and will make WC recognizable by TSVN again.
> svn.exe, svnadmin.exe and svnserve.exe are uploaded to the nightly build
> folders too. Just copy them to the TSVN\bin folder and run them from there.
>
Thanks!
Gunnar.
> Stefan
>
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2707766
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-02-26 13:42:37 CET