I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.
So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.
I tried forcing the svn client to 'basic' auth with configuration option http-auth-types (http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.
The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/
When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.
I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?
---- edit ----
I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !
If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.
Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (i.e. Certificate Revocation List). With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.
If it's not your case, then I suggest contacting VisualSVN's support team for investigation.
In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).
After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.
It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.
The initial delay I had was 11-13 seconds. Now next to none.
And I am not using ssh client.
Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).
For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).
Related
After successfully running subversion for years on a Windows 2008 server, I recently moved to Windows 8.1, mainly because the machine does also serve videos to my home network (works fine) and because Windows 8 provides better energy saving on my platform than Windows 2008 server did. So far, so good.
Then I tried to re-install Subversion. I intend to use the built-in server application svnserve.exe. I downloaded the latest windows package, installed it (success), and configured a service (svnserve --service ...) which I can successfully start using the Windows Service Management Console. Port 80 is already taken by a different application, so I let subversion pick 3690, which is fine for me. I used netstat to confirm that svnserve.exe is bound to port TCP:3690, which is listed OK. Just to clear one potential roadblock I also disabled the Windows firewall.
Then I created a sample repository named "test" using svnadmin locally, success as well, a subversion file structure appeared on the harddisk.
Problems arise when I try to access the repository using my local browser (Firefox), an attempt to connect to URLs
http://127.0.0.1:3690[/svn|/svn/test]
all three give me the same cryptical response:
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )
Somehow I have expected a subversion GUI instead.
Connecting from a remote machine via browser reveals the same useless line of text.
Connecting from a remote machine using my usual Tortoise client gives the message:
Unable to connect to a repository at URL 'http://xxx.xxx.xxx.xxx:3690/svn/test
Error running context: The server unexpectedly closed the connection
I tried to add the --log-file option to svnserve, and indeed a log file appears once I start the service, but it is empty and it remains empty.
Trying to use svnserve -X instead of running it as a service reveals the exact same behavior.
Seems I am stuck. Anyone who has an idea what I can do to get that thing working?
Just to help out another beginner running into the same problem ... I finally found the problem: I simply used the wrong client, svnserve does not support web browsers. Using the Tortoise client, and providing the correct prefix (svn:127.0.0.1/...) was all I had to do.
The long version:
If one wants to work with the simple, reliable, fast, but plain-text and proprietary protocol based) svnserve service, he needs to use a proprietary client, like Tortoise, and the svn: prefix instead of http/https:, and no port, like
svn://mysvnserver/testrepo
If needed, one may even reconfigure svnservice to use authentication and encryption later. svnserve isn't supporting web browsers, if one tries to access svnserve using a web browser like I did he gehts the internals of the svn protocol dumped to the screen.
If one wants to use his web browser, http/https protocol, and niceties, like a user friendly browser based interface and some remote administration capabilities, he must not use svnserve, but install a web server service (like apache) and configure if for use with subversion.
So in the end my problem had nothing to do with Windows 8. It just has slipped from my mind that years ago I went the apache path, while now I decided that the built-in svnserve service was good enough for my needs.
Armin.
I am writing a webdav server for embedded system. Everything goes normal until I tested it with windows client, the miniredir.
It became extremely slow when accessing the data with miniredir. I captured the network traffic and found that everytime I made a move, the miniredir tried to connect to the server via SMB first. (SYN package sent to 137,138,139,445) and the expolrer view would not show until the SMB request failed a few times, which takes more than 20s.
I also tried miniredir with Apache+mod_dav, same delay was observed (make sure the server machine disabled SMB service).
Is there anyone solved this problem? or if there's any work around solution for XP?
BTW: After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client. A lot of bugs and shorting comings were reported, but MS didn't do much improvement. http://www.greenbytes.de/tech/webdav/webdav-redirector-list.html
Significant delays can be encountered when accessing WebDAV resources if Internet Explorer is configured to auto-detect proxy servers. Try following these instructions for disabling proxy auto-detection and see if that helps.
After a few days' debugging, now I believe MS Miniredir is not a qualified WebDAV client.
I think this is an overstatement. The only documented issue in XP/SP3 is a by-default lack of support for basic auth, and there is a workaround for this. "When you hear hoofbeats, look for horses, not zebras."
I have successfully configured TortoiseSVN to access a local Apache-served Subversion repository over https. My initial problem in configuring this scenario from my Windows client was discovered to be the proxy server I had established in the TortoiseSVN settings, which were unnecessary in our local environment.
However, for external repositories, the web proxy is necessary. As a result, I was hoping to find an option in TortoiseSVN equivalent to "Bypass proxy for local intranet sites" or a means to establish a proxy bypass list, but I've found neither, and I've not found a workaround in the research I've done so far. Came across a few posts here on SO that sounded promising, but amounted to manually disabling/enabling the web proxy as needed.
Am I missing something obvious, or will I simply need to enable/disable the proxy from TortoiseSVN depending on where the archive is located? This isn't insurmountable, of course, just a bit of a nuisance.
Many thanks.
You should try downloading frozen Way, this worked for me, you just need to start it when you want to commit/upload and it's free .
I know it is not strictly a programmer question, on the other hand, I would really like to be able to do a simple svn up on the production servers, which would save us a lot of hassle.
Or production servers are within a corporate network, and access is only allowed through a gateway server. From that we can access the actual servers via Remote Desktop. Because of this maintenance unfriendly setup we use a sftp server to get our files to the production server (where the ftp server alwys resets last modified date), so it is complicated to determine which files have changed.
So if it would be possible to setup a ssh tunnel from the actual server through the citrix connection, it would ease the whole update process.
(On further option which I consider is to use bazaar to push our updates to the sftp server and then pull the updates from there, but unfortunately there is no working svn plugin for bazaar available [on windows])
Okay, not wanting this to remain unsolved, I posted the following on the usenet in alt.os.citrix:
G'day everyone
Someone asked me this question. I haven't a clue. Any ideas?
"the connection I have is PC -> Citrix Access Gateway -> actual Server. My question is, if it is possible to establish a ssh connection from my PC to the actual Server."
The response I got from a Catherine Jefferson was:
Should be. I do this all the time using an Access Gateway VPN, then ssh to servers inside the company LAN.
What version of the Access Gateway is this user running? I work for Citrix, might be able to get a more specific answer for him or her.
So may I suggest you hook into alt.os.citrix (probably via Google Groups if you don't have an NNTP tool) and buy into the conversation.
--Bruce
I do this a lot. The tunnel is like:
ssh -nvCXAN -L 1494:10.0.2.39:1494 www.starshipping.com &
Then, you need an ICA file that points to localhost.
[WFClient]
Version=2
[ApplicationServers]
Connection To Citrix Server=
[Connection To Citrix Server]
WinStationDriver=ICA 3.0
TransportDriver=TCP/IP
ClientAudio=Off
DesiredColor=8
Username=yourusername
Domain=yourdomain
Password=xxxxxxxxx ; has to be encrypted. I pulled from another ICA file generated internally
ScreenPercent=97
TWIMode=OFF
Address=localhost
This all worked very fine on OSX until Citrix gave out a new version of the Citrix client which is now called the Citrix Online Plugin. Haven't been able to get it to work since then. Meanwhile, our VPN has been working fine, so haven't worried too much about it.
Citrix over SSH, How to Create a Key Pair for SSH Authentication Using PuTTYgen, Terminals. It seems that the answers are "out there" but not readily found. That was just five minutes in Google. HTH.
I've installed TFS 2008, but I can't seem to access the server. When I try to connect to it in Visual Studio, I can't. If I try by browser on a remote PC, I get a generic page cannot be displayed. On the server, I get a 403. Nothing was touched in IIS and the service is running as a Network Service. Any ideas?
try:
http://localhost:8080/Services/V1.0/ServerStatus.asmx. This will tell you if TFS is up and running. If you are getting anything else you need to look into IIS issues.
I wrote a blog post on diagnosing these types of TFS connections.
http://blogs.msdn.com/granth/archive/2008/06/26/troubleshooting-connections-to-tfs.aspx
The very first thing I do is confirm that it works for a known-good configuration – usually my workstation.
Providing that works and the server appears to be functioning, the next thing I do is ask the user to call the CheckAuthentication web service using Internet Explorer.
The URL for this is: http://TFSSERVER:8080/services/v1.0/ServerStatus.asmx?op=CheckAuthentication
By doing this check, I am doing four things:
Eliminating Team Explorer from the picture
Eliminating the .NET networking stack from the picture
Ensuring that Windows Authentication is working correctly (that’s why I say IE)
Ensuring that proxy settings are set correctly
In most cases I’ve seen, the TFS connection issues are because the proxy settings have changed or are incorrect. Because .NET and Visual Studio use the proxy settings from Internet Explorer, it’s important to have them set correctly.
In rare cases it’s beyond this. That’s when I start looking at things like:
Can you resolve the server name?
Can you connect using the IP address?
Are there HOSTS file entries? (see: c:\windows\system32\drivers\etc\hosts)
Can you ping the server?
Can you telnet to port 8080?
Does the user actually have access? Run TfsSecurity.exe /server:servername /im n:DOMAIN\User to check their group memberships
Have you changed your domain password lately? In some cases they’ll need to logoff the workstation and log back on again to get a new security token.
Is the computer's domain certificate valid? update the certificate: gpupdate /force
Hope this helps.
Turns out the time and date on my computer was not "close enough" to the time and date on the tfs server. Changed my system clock setting and problem went away.
What happens if you send a simple HTTP request to the server directly?
ie:
telnet 8080 [enter]
GET / HTTP/1.1[enter]
[enter]
[enter]
That might give a hint about whether IIS is actually serving anything. If you can do that on the server, what about from a different machine? If the results are different a good guess is there are some security/firewall issues somewhere. HTH a little.
I went through everything on a similar problem.
I logged onto my tfs server and connected directly there.
I also used a TFS admin tool I downloaded some time ago from Microsoft, and made sure I was in all the right groups and projects.
I then went back to the client PC with the problem, tried the services/1.0/serverstatus.asmx?op=CheckAuthentication Url again, and it worked this time.
AFter that full service was restored to my PC.
So I don't have the exact answer, but I would go through the checklists presented by Grant Holliday in his answer.
Add this to the cases for future users, as i had this issue on server 2016...
if your firewall allow only Domain and Private Network, it may not work on client. make sure you give public permission, if server network is set to public...
The error you may face:
ERR_CONNECTION_TIMED_OUT
for
http://fserver:8080/tfs