SteveKing wrote:
> Felix Brack wrote:
>> When i list the shares (not the folders) of a network computer
>> from a client machine where TSVN 1.1.0 build 1769 is istalled, the
>> listing of the shares is very slow. To prevent any side effects, I
>> disabled overlay icons; this did not change the browsing speed. Browsing
>> from the same client machine without TSVN installed works fine.
>> I made the same test on two other machines (W2k, XP) with exactly the
>> same results.
>> The server, from which I am listing the shares, is a linux box with samba
>> 3.0.7 installed. Examining the log of the smb daemon reveals the
>> following (sorry for the long lines, but it's simpler to read):
> [snip]
>>
>> The interesting lines are those stating "could't find service .svn".
>> This is the reason for the delay, when browsing with TSVN installed.
>> Now my question: why does the TSVN explorer extension try to
>> connect to a SERVICE '.svn'? I understand that TSVN is looking for a
>> directory '.svn' (when browsing below a share) but why does it try to
>> connect to service '.svn'?
>> To be very clear, listing shares is slow, listing directories (and
>> files) is fast.
> To be honest: I have no idea what's happening here. TSVN never does
> something like calling/connecting to a service. Really!
It always has to, when the resource it is accessing is located somewhere
else then on a local drive or a network mapped drive. It's done
'transparently' by the OS.
> I also never noticed that with a normal windows share (not Samba). So
> maybe this is specific to Samba?
A share on a samba server is a 'normal windows share'. I also created some
shares on an XP-Pro machine: same result. This is absolutly not surprising,
since the request for the share comes from the client (TSVN) and is answerd
by the server (I checked that by tracing the networktraffic with ethereal).
The reason you might not have noticed this behaviour is perhaps the
bandwidth: if I browse the server from a VPN connected notbook with a
56k analog modem, I will have to wait about 3.5 minutes to get the 10
shares listed. Without TSVN installed the same operation takes 8
seconds. On the LAN, the timeouts are negligible.
> Stefan
I checked out a copy of TSVN's source code; just to see if this would
help; of course I can not look at the code (even if it's wirtten as
clean as yours) and then after some hours say: 'there is the
problem!'.
I just noticed that the code often uses 'PathIsDirectory' and never uses
'PathIsUNC' or 'PathIsUNCServer' or 'PathIsUNCServerShare'. According
to microsoft, 'PathIsDirectory' returns TRUE if it's argument is a
directory, else it returns FALSE. In fact 'PathIsDirectory'
returns 0x10 if it's argument is a directory and 0x1 if it's argument
is a share. I do not know why the return values differ and I admit,
that 0x1 as well 0x10 are TRUE (to tell the truth, they are both not
FALSE). This is why we use the 'PathIsUNC...' functions to get a clear
distinction between 'directory' and 'share'.
I think, that omitting the request for the '.svn' directory at the
correct place (???) in TSVN's code would solve my problem.
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Oct 22 12:33:20 2004