On 9/15/05, Gaspar Jens-Uwe <gaspar@cm-tm.uka.de> wrote:
> we have a annoying problem here with TortoiseSVN, it appears when using the
> Repo-Browser (it's reproducable).
> It's not clear to me, if that's the right forum to post this, but let's see
> ...
>
> Our environment:
> SVN-Server:
> hostname i71pc35 (for the tcpdumps)
> PC/OS Linux i71pc35 2.6.11.4-21.9-default, i586 i386 GNU/Linux, Suse
> 9.3
> subversion 1.1.3-10 (upgrade not possible at this time)
> server runs as svnserve-daemon
> anon-access = none
>
> client-PC:
> hostname i71pc90d
> OS Windows XP, 2002, SP2
> no firewall, no proxy, Virus-checker activated
>
> TortoiseSVN 1.2.2:
> "recursive overlays on"
> "fetch status context menu on"
Those two settings have nothing to do with networking operations.
They're only for the overlay/status fetching/context menus.
> It is a test-repository containing approx. 64 files in 12 directories
> of overall size of 270 MB. We have two repositories: one with fsfs
> version-filesystem and one with bdb-type (both with same content).
>
> If you need further data or information, please let me know.
>
> I've performed the following steps (the prefixed numbers refers to
> the according tcpdump-file i attached in the zip-file, I hope this
> is of some help, e.g. "1." refers to file:
>
> 'Ethereal-TortoiseSVN-RepoBrowser-OpenURL-1-problem.txt'
>
> I've restarted the svn-server before starting.
>
> 1. Call "Repository Browser" ->
> >> "OpenURL svn://i71pc35.cm-tm.uka.de/fsfs": tcpdump-entry #1-27
> >> "open main-folder (+)": entry - #59
> >> "refresh": entry - #105
> >> close Repository Browser
>
> no error so far; for entries have a look in:
>
> 'Ethereal-TortoiseSVN-RepoBrowser-OpenURL-1-problem.txt'
>
> 2. Do the same as for (1.):
Before you do that, check how many instances of svnserve are running
on your linux box. Maybe the previous instance is still running?
> Call "Repository Browser" ->
> >> "OpenURL svn://i71pc35.cm-tm.uka.de/fsfs": tcpdump-entry #1-32
> >> "open main-folder (+)": entry - #59, but hangs and blocks
> TortoiseSVN,
> and other subversion-clients (tested with subclipse 0.9.34 and
> svn-1.2.3 in a shell) are considerably slower and also hanging.
>
> After 560 seconds, a response comes: tcpdump-entry - #72
So the *server* didn't respond which makes the client wait.
> lookup tcpdump-entries in:
>
> 'Ethereal-TortoiseSVN-RepoBrowser-OpenURL-2-problem.txt'
>
> Here i restarted the SVN-server.
> Now i wanted to try the same with the bdb-repository, if that makes
> a difference. Firstly i tried to reproduce the problem with the
> bdb-repository, but i was not able to.
>
> 3. Re-open "Repository Browser" ->
> >> "OpenURL svn://i71pc35.cm-tm.uka.de/bdb": tcpdump-entry #1-26,
> >> "open main-folder (+)": entry - #58
> >> "refresh": entry - #104,
>
> no error:
>
> 'Ethereal-TortoiseSVN-RepoBrowser-OpenURL-3-problem.txt'
>
> retried that 3 times without error,
>
> Then i realized that the according svnserve.conf contained
> 'anon-access = read'.
>
> After setting this to 'none' and restart the server, the same
> hanging-behaviour showed up for the bdb-repository:
That's a good hint. Remember this well (see below)
> 4. Open "Repository Browser" ->
> >> "OpenURL svn://i71pc35.cm-tm.uka.de/bdb": tcpdump-entry #1-9,
> now TortoiseSVN hanged for 437 secs, then got an answer: entry - #34
Again, the *server* didn't respond immediately and made the client wait.
> 5. Re-opened "Repository Browser" ->
> >> "OpenURL svn://i71pc35.cm-tm.uka.de/bdb": tcpdump-entry #1-9,
> now TortoiseSVN hanged for 400 secs, then got an answer: entry - #36
>
> >> "open main-folder (+)": entry - #47,
> now TortoiseSVN hanged for 300 secs, then got an answer: entry - #78
>
> >> "refresh": entry - #130
> >> close Repository Browser
>
> lookup tcpdump-entries in:
>
> 'Ethereal-TortoiseSVN-RepoBrowser-OpenURL-5-problem.txt'
>
> The FAQ-webpage for TortoiseSVN was off the whole day.
> But i found some hints about making the client faster,
> so i deactivated the Virus-Scanner, and deactivated:
>
> "recursive overlays"
> "fetch status context menu"
All these settings don't affect the network connections in TSVN at
all. Those options are to make the client faster when dealing with
working copy status (e.g. for the overlays, the context menu, ...)
> but the same effect show up, only that the "hanging"-timeouts
> were shorter (200 sec or so)
I think that's just a coincidence.
> I've absolutely no idea, what the cause for this, but makes it
> rather different for the average user to use TortoiseSVN.
> Maybe there is a inconsistency of TortoiseSVN 1.2.2 and a
> subversion-server v1.1.3 !?
>
> I was not able to get a "hanging" behaviour with svn-client 1.2.3
> or with Eclipse-plugin subclipse 0.9.34.
Please do your tests again, but this time observe the running
instances on the server side. I know there was a problem in the
Subversion library which made it not close network connections after
some client API function calls which lead to multiple open instances.
But AFAIK that should be fixed in 1.2.3??
Then, you should report this problem on the Subversion mailing list,
because the *server* doesn't respond and makes the client wait too
long. Sure TSVN will hang if it wait's for the server, but the server
just doesn't deliver the data TSVN waits for.
Also report the fact that this only happens when you set
'anon-access = none'
That will give the Subversion devs a hint where they have to look for
the problem.
> As a matter of fact, we cannot update the subversion-server to a more
> recent version until an official Suse-update is released.
I know, SuSE really sucks in that area - current rpms are hard if not
impossible to find.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Sep 15 10:50:29 2005