We are using VisualSVN Server v3.5.3 "Standard Edition." This server only supports and access, not svn://. Using Wireshark, I am able to see traffic between svn on my client computer and our public IP address in any of these modes, however, I am unsure where to locate the point where the conversation goes wrong (especially when the protocol is https!). A firweall can't selectively block http verbs on traffic that's not to the http port, or where the verbs are encrypted. To rule out "http verb blocking" by an external firewall as an explanation, I tried changing the access method to http on port 81, and https on port 443, relocating the working copy each time I changed the access method on the server. For working copies with the server's network name on the intranet for the repository root, all commands continue to work fine.
All the foregoing applies to commands executed on a working copy whose repository root is the public IP address (or, relocating the repository root to our public IP address, in the special case of svn relocate). Svn log prints the log, i.e., behaves as normal. When I svn relocated my working copy to our public IP address, I was correctly challenged for my svn credentials and the command succeeded. Specifically, svn st -u prints no output and hangs until I kill it with ^C. The horrible thing I've now discovered, is that svn st -u does not work, but other subcommands do work, e.g., svn relocate and svn log. And obviously until we get the immediate problem solved there will be nothing to secure.) https, that will be a separate question if ever. (We do not require high security for our svn even if made public on the internet, so please do not change the subject to http vs. At this time, we've realized that it's in our interest to be able to access our svn server from offsite. So my boss is a nice guy who's open to trying new ideas, and I talked him into letting me start new projects on svn (instead of an older version control system).
0 kommentar(er)
