som wrote:
>> Your settings are for the *overlays*. The context menu *has* to fetch
>> the status (that's why you see SMB traffic: it's fetching the svn
>> status) of the item you right-clicked on. Without the status, we'd have
>> to show *all* items all the time, even those which don't make any sense
>> according to the svn status (e.g., 'commit' for an unversioned folder).
>>
>
> I understand, what You mean, but would it not be possible, not to show
> the Tortoise context menu at all or just the settings sub menu, if
> Tortoise knows, that there can be no workspaces in this folder? I tell
> Tortoise exactly, what directory contains my working directories, by
> the include path or at least by restricting overlays to fixed drives.
> At least this was always my intention and I always thought that this
> would help to keep Explorer from unnecessary status checking.
You misunderstand the overlay settings. You only tell TSVN where it
should show the overlays, not where your working copies are. That's not
the same. Some people don't want the overlays shown on their working
copies because the constant status fetching required for this slows down
their machine too much. But they still want the context menu and the
TSVN commands to work.
> I tried to check the "Show overlays and context menu only in Explorer"
> box in the Icon Overlays settings and right clicked a directory in the
> problematic share within a "save as" dialog box. If the check box is
> checked, there is no problem at all. If it is not checked, the dialog
> freezes too. So in some case the settings in the Icons Overlay menu
> controls the display of the context menu too, in other cases not. Why
> not just change the whole group of settings to "Icon Overlays and
> Context Menu" and let the user select to only show the context menu
> and overlays in fixed drives or the include paths for example? This
> would be much more consistent behavior and improve performance for
> many users, independent of the existence of any freeze problem.
You make a wrong assumption here when you say "improve performance for
many users". In fact, you're the very first one ever to report this.
Which indicates that the chances that the problem is with your network
setup are much higher than that the problem is with TSVN.
After all: to fetch the status, all TSVN does is open a few files and
read them - if your network can't handle *that* properly, I don't think
you should blame TSVN.
> By the way I do not understand, why so many requests are necessary to
> check the status at all. Why try it over and over again for the same
> directory, if access is denied?
You can thank all the virus scanners out there for this. Subversion
*has* to retry after "access denied" errors because those errors happen
way too often due to those stupid applications: they open files
immediately after they've been created in exclusive mode (to check them
for viruses or whatever), which made Subversion fail constantly because
it couldn't access its own files anymore. So now there's a retry-loop
for all svn file accesses to work around those scanners.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-07-18 16:16:03 CEST