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). At this time, we've realized that it's in our interest to be able to access our svn server from offsite. I said that was easy, just open port 80. (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. https, that will be a separate question if ever. And obviously until we get the immediate problem solved there will be nothing to secure.)
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. Specifically, svn st -u prints no output and hangs until I kill it with ^C. When I svn relocated my working copy to our public IP address, I was correctly challenged for my svn credentials and the command succeeded. Svn log prints the log, i.e., behaves as normal. 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). For working copies with the server's network name on the intranet for the repository root, all commands continue to work fine.
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. A firweall can't selectively block http verbs on traffic that's not to the http port, or where the verbs are encrypted. But these moves did not solve anything. 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!).
We are using VisualSVN Server v3.5.3 "Standard Edition." This server only supports http:// and https:// access, not svn://. The client is TortiseSVN v1.9.3. The operating system is Windows 7 for both client and server (they are two different computers on the same intranet).