Então meu chefe é um cara legal que está aberto para tentar novas idéias, e eu falei com ele para me deixar começar novos projetos no svn (ao invés de um sistema de controle de versão mais antigo). Neste momento, percebemos que é do nosso interesse poder acessar nosso servidor svn de fora do local. Eu disse que era fácil, basta abrir a porta 80. (Nós não exigem alta segurança para o nosso svn mesmo se tornada pública na internet, então por favor não mude de assunto para http vs. https, que será uma questão separada se alguma vez E, obviamente, até resolvermos o problema imediato, não haverá nada para proteger.
A coisa horrível que eu descobri agora é que o svn st -u não funciona, mas outros subcomandos funcionam, por exemplo, svn relocate e svn log. Especificamente, svn st -u não imprime nenhuma saída e trava até que eu a mate com ^ C. Quando eu svn realocou minha cópia de trabalho para o nosso endereço IP público, fui desafiado corretamente para minhas credenciais de svn e o comando foi bem-sucedido. Svn log imprime o log, ou seja, comporta-se como normal. Tudo o que precede se aplica a comandos executados em uma cópia de trabalho cuja raiz do repositório é o endereço IP público (ou, realocando a raiz do repositório para o nosso endereço IP público, no caso especial de svn relocate). Para cópias de trabalho com o nome de rede do servidor na intranet para a raiz do repositório, todos os comandos continuam a funcionar bem.
Para descartar o "bloqueio de verbo http" por um firewall externo como explicação, tentei alterar o método de acesso para http na porta 81 e https na porta 443, realocando a cópia de trabalho toda vez que alterei o método de acesso no servidor. Um firweall não pode bloquear seletivamente verbos http no tráfego que não é para a porta http, ou onde os verbos são criptografados. Mas esses movimentos não resolveram nada. Usando o Wireshark, consigo ver o tráfego entre o svn no meu computador cliente e nosso endereço IP público em qualquer um desses modos, no entanto, não tenho certeza de onde localizar o ponto em que a conversa está errada (especialmente quando o protocolo é https!) .
Estamos usando o VisualSVN Server v3.5.3 "Standard Edition". Este servidor suporta apenas http: // e https: // access, não svn: //. O cliente é o TortiseSVN v1.9.3. O sistema operacional é o Windows 7 para cliente e servidor (eles são dois computadores diferentes na mesma intranet).