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.
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)"
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.