Erro de conexão do Subversion para clientes de 64 bits

Question

Eu não sou um administrador de sistemas, mas aparentemente tenho que jogar um na TV. No entanto, convenci meu local de trabalho a começar a usar o controle de versão e, portanto, ser o único a administrá-lo. O problema é que tenho que fazer isso em seus sistemas existentes. Então, estou executando o SVN visual em um Windows Server 2003 Web Edition, que é de 32 bits. Eu não fiquei fofa com nada, já que não sei o que estou fazendo. Este é o nosso servidor de desenvolvimento que eu acabei de fazer uma instalação padrão do visualSVN para. O repositório está hospedado nesta máquina e a cópia de trabalho do cliente está em uma unidade de rede mapeada que aponta para um local nessa mesma máquina.

Meus usuários em versões de 32 bits do Windows 7 não têm problemas com os clientes do Tortoise ou do Smart SVN. No entanto, meus usuários de 64 bits recebem periodicamente um

"connection refused by the server OPTIONS request failed"

mensagem e não pode se conectar ao servidor SVN, isso persiste até que reinicie sua máquina e ocorre com os clientes mencionados acima. Para que vale a pena, há um pequeno patch de 64 bits para o Smart SVN, lidando com a integração do shell e que foi aplicado.

Então, o que esta mensagem significa e como resolvo isso? Por favor, tenha em mente que enquanto eu sou decentemente experiente como um usuário de computadores, eu estou sobre a minha cabeça quando se trata de administrá-los e condescender a mim nesse sentido por favor. Observe também que, se houvesse uma opção para executar o SVN em uma caixa do Linux, isso já teria sido feito. Eu não tenho escolha a não ser trabalhar neste ambiente.

EDIT 2012/3/15

Eu tive uma experiência com o usuário novamente e, conforme o conselho do Lazy Badger, usei o slikSVN para tentar uma atualização. O erro também ocorreu com o CLI, mas o texto foi ligeiramente diferente como:

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

EDIT 2012/3/19

Encontrei uma possível solução alternativa. Eu tive como experiência do usuário o erro novamente hoje. Apenas para verificar se a rede estava OK, pedi para ele navegar até o repositório em seu navegador, indo até o servidor link ]: 8080 / svn 'e Isso pareceu permitir que seus clientes SVN acessassem o servidor novamente sem erros e sem a interrupção de uma reinicialização. Será atualizado novamente se essa solução alternativa tiver sucesso repetido.

    

Answer 1

Quando você diz "visualSVN" você quer dizer "VisualSVN Server", sim?!

1. "A solicitação OPTIONS falhou" não é não correlacionada com o cliente (e a arquitetura do cliente) - é um erro puro do lado do servidor
2. Sem o log do Apache, não podemos usar
3. O log está totalmente desativado no servidor VisualSVN, você o habilitou i httpd.conf manualmente
4. Para testes, recomendo usar CLN svn-clients - em caso de erros, eles relatam mais detalhes (o cliente CLI de 64 bits SVN é SlikSVN , 32bit pode ser usado qualquer)

BTW, sidenote

the clients working copy is on a mapped network

é uma ideia muito, muito ruim

Atualizar

Esclarecimento e detalhes

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

VisualSVN Server Standard Edition tem

ErrorLog nul
LogLevel error

na configuração do Apache, assim - log quase nada no log de eventos (em seção separada). O Access and Operational Logging (para o log de eventos) pode ser habilitado em uma caixa na GUI somente no Enterprise Edition. Você pode habilitar o registro padrão definindo o ErrorLog & AccessLog comum e ver as ações e erros na versão estendida, incluindo o frontend ( razão para "OPTIONS request failed"). Mas SVN Book também tem uma dica sobre Apache extra logging em CustomLog, que permite o comando "translate" do WebDAV para comandos SVN

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

• Visual Studio + svn: cópias de trabalho na unidade de rede ou local tópico aqui
• Responda em FAQ do TortoiseSVN
• Cópias de trabalho do SVN sobre compartilhamento de rede topic
• Aviso ligeiramente desatualizado sobre o BDB-repo (use FSFS mesmo assim) "Não crie ou aceda um repositório Berkeley DB em um compartilhamento de rede.Ele não pode existir em um sistema de arquivos remoto.Nem mesmo se você tiver a unidade de rede mapeada para uma letra de unidade.Se você tentar usar Berkeley DB em um compartilhamento de rede, os resultados são imprevisíveis - você pode ver erros misteriosos imediatamente, ou pode levar meses até você descobrir que seu banco de dados de repositório está sutilmente corrompido "

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

O QUE?! Servidor por desenvolvedor ou uma cópia compartilhada para todos os desenvolvedores? Você (ou gerente ou ...) tem para repensar o fluxo de trabalho depois de implementar o VCS - você não pode usar o heap comum como antes, apenas na versão no topo. Este post será (pode) ser utilizável para entender minha reação e esta resposta no FAQ do Subversion ajudará a construir fluxo de trabalho atualizado. A solução de gancho de pós-consolidação tem alguns cantos agudos (operações paralelas), mas quando e se houver algum problema, você poderá passar para as ferramentas Build-CI-Deploy de qualidade de produção

    

Answer 2

Tem certeza de que a janela de 32 ou 64 bits está com defeito? A menos que haja um bug específico na versão de 64 bits do seu cliente svn, duvido que os bits aqui sejam o problema.

Uma das razões pelas quais você pode obter o erro encontrado é porque o método HTTP OPTIONS está sendo filtrado por um firewall ou pelo próprio servidor svn. Desligue o firewall (menos seguro) que pode estar sendo executado na máquina do Windows do usuário (ou, mais seguro, permita especificamente esse tráfego).

Se o usuário receber "Falha na solicitação OPTIONS" você conseguir obter um "status svn", poderá acessar o servidor svn? O cliente svn deve ter uma maneira de obter o status.