2

I'm not a sys-admin but I apparently have to play one on TV. I did however convince my workplace to start using version control and therefore get to be the one to administer it. The catch is I have to do it on their existing systems. So, I'm running visual SVN on a Windows Server 2003 Web Edition, which is 32 bit. I didn't get cute with anything, since I don't know what I'm doing. This is our development webserver which I just did a standard install of visualSVN on to. The repository is hosted on this machine, and the clients working copy is on a mapped network drive which points to a location on this same machine.

My users on 32 bit versions of Windows 7 have no problems with either tortoise or Smart SVN clients. However my 64 bit users periodically get a

"connection refused by the server OPTIONS request failed"

message and can't connect to the SVN server, this persists until they restart their machine and occurs with both the clients mentioned above. For what it's worth there is a small 64bit patch for Smart SVN, dealing with the shell integration and that has been applied.

So What does this message mean and how do I resolve it? Please keep in mind that while I'm decently experienced as a user of computers, I am over my head when it comes to administering them and condescend to me accordingly please. Also note that if there was an option to run SVN on a Linux box, it would have already been done. I have no choice but to work in this environment.

EDIT 2012/3/15

I had a user experience the problem again and as per Lazy Badger's advice ran over and used slikSVN to attempt an update. The error also occurred with the CLI but the wording was slightly different as:

"svn: OPTIONS of 'http://[our server]:8080/svn/[repo]/trunk/[toplevelfolder]': could not connect to server (http://[our server]:8080)"

EDIT 2012/3/19

I have found a possible workaround. I had as user experience the error again today. Just to check if the network was OK I had him browse to the repo in his web browser, just going to 'http://[our server]:8080/svn' and logging in. This seemed to allow his SVN client(s) to then access the server again without error and without the interruption of a reboot. Will update again if this workaround has repeated success.

invertedSpear
  • 153
  • 1
  • 6

2 Answers2

2

Are you sure that 32 bits or 64 bits windows is at fault? Unless there is a specific bug in the 64 bits version of your svn client I doubt that the bits here are the problem.

One of the reasons you can get the error you found is because the OPTIONS HTTP method is being filtered by a firewall, or the svn server itself. Turn off the firewall (less secure) that may be running on the user's windows machine (or, more secure, specifically allow such traffic).

If the user gets "OPTIONS request failed" are you able to get an "svn status", can you reach the svn server at all? The svn client should have a way to get the status.

aseq
  • 4,610
  • 1
  • 24
  • 48
  • Am I sure its 32 vs 64 bits? Not in the slightest, but it's the common difference between users with the problem, and users without. If it's firewall then shouldn't it always throw the error? in our case it will connect fine for a period of time (sometimes hours, sometimes days) before throwing this error and not working anymore until a reboot. I will try to check status next time the error is thrown and report back on that. – invertedSpear Mar 14 '12 at 23:09
  • Just checked with the users reporting the problem. Had a 50/50 mix of them having windows firewall on or off, all of the users on 32bit hardware (no problems) had windows firewall off. So it doesn't seem like its windows firewall, will check with our network guys if we're doing anything on the routers. – invertedSpear Mar 14 '12 at 23:30
  • Well, the windows firewall is quite notorious for causing intermittent problems. Also don't forget to try and get svn status when the problem happens and to try to reach the svn server. Check for other things that 64 bits machines have in common that 32 bits don't. – aseq Mar 15 '12 at 00:01
2

When you say "visualSVN" you mean "VisualSVN Server", yes?!

  1. "OPTIONS request failed" does not correlate with client (and client architecture) at all - it's pure server-side error
  2. Without Apache's log we can nothig
  3. Logging is totally disabled in VisualSVN Server, you have enable it i httpd.conf by hand
  4. For testing I'll recommend to use CLI svn-clients - in case of errors they report more details (64bit SVN CLI client is SlikSVN, 32bit may be used any)

BTW, sidenote

the clients working copy is on a mapped network

is very, very bad idea

Update

Clarification and details

Can you link to, or include instructions for editing the logging you mention in point 3?

VisualSVN Server Standard Edition have

ErrorLog nul
LogLevel error

in Apache config, thus - log almost nothing in Event Log (in separate section). Access and Operational Logging (to event log) can enabled from a box in GUI only in Enterprise Edition. You can enable standard logging by defining usual ErrorLog&AccessLog and see actions and errors in extended version, comare to frontend (reason for "OPTIONS request failed"). But SVN Book also have a tip about Apache extra logging in CustomLog, which allow "translate" WebDAV command to SVN commands

Care to clarify why the working copy being on a mapped network drive is a bad Idea?

we need it to be on the web server for the server side language to be processed

WHAT?! Server-per-developer or one shared copy for all developers? You (or manager or...) have to re-think about workflow after implementing VCS - you can't use common heap as before, just versioned on top. This post will (may) be usable for understanding my reaction and this answer in Subversion FAQ will help to build updated workflow. Post-commit hook solution have some sharp corners (parallel operations), but when and if it'll become problem you can move to production-quality Build-CI-Deploy tools

Community
  • 1
Lazy Badger
  • 3,137
  • 15
  • 13
  • Yes VSVN server, sorry about not clarifying that. Will try out silk and see if that gives us a more robust error. Can you link to, or include instructions for editing the logging you mention in point 3? Care to clarify why the working copy being on a mapped network drive is a bad Idea? we need it to be on the web server for the server side language to be processed. – invertedSpear Mar 14 '12 at 23:47
  • @invertedSpear - I extended answer – Lazy Badger Mar 15 '12 at 07:15
  • Thanks, and thanks for clarifying the reasoning behind not using the network drive. I can see why it would be a concern for using compiled languages. While I can understand the assumption that we would use visual studio, we only use visualSVN as it seemed the best fit for using SVN on a windows server, and our code is actually in ColdFusion. Sorry for asking for so much hand-holding, but when you say "You can enable standard logging by defining usual ErrorLog&AccessLog" I have to ask you to tell me how. A huge Thank you for your help so far. – invertedSpear Mar 15 '12 at 17:24
  • Also just had a user get the error again, ran slikSVN on their machine and posted the result in the question. – invertedSpear Mar 15 '12 at 18:27
  • @invertedSpear - when my team uses PHP in web-development, we anyway have **personal local Working Copy**, test-server and deploy to common webspace for testing and debug. Can't see reasons for big change in case of CF. Apache logging use directives ErrorLog AccessLog for defining files, there log of work will be stored ([ErrorLog](http://httpd.apache.org/docs/2.2/logs.html#errorlog) is related to [ErrorLogFormat](http://httpd.apache.org/docs/current/mod/core.html#errorlogformat), [AccessLog](http://httpd.apache.org/docs/2.2/logs.html#accesslog) with CustomLog and LogFormat) – Lazy Badger Mar 15 '12 at 19:19
  • @invertedSpear - "could not connect to server", as written: can't get **any** answer from remote side; "connection refused by the server" - connection to Apache was established, but dropped by Apache. You have to find reasons of this errors in pure Network infrastructure - they are unrelated to SVN b 64bit. It's just "strange unstable work" - and connection to Apache and repo you can test (with VisualSVN Server) using only any ordinary browser with URL of repo – Lazy Badger Mar 15 '12 at 19:28