O svn não manipula redirecionamentos HTTP (é o que o erro 301 é), olhe para onde os redirecionamentos apontam (wget, wireshark), confira a partir daí.
Também é um problema específico do apache, a configuração do host virtual pode estar quebrando-o.
Temos um servidor nginx que faz proxy para uma configuração padrão do Apache + SVN. A configuração do nginx é um proxy muito simples:
server {
server_name svn.ourdomain.tld;
location / {
proxy_pass http://localhost:8080;
}
}
O Apache é configurado da seguinte forma:
<Location />
DAV svn
SVNParentPath /var/svn
AuthType Basic
AuthName "Authentication Required"
AuthUserFile /var/svn/.auth
Require valid-user
</Location>
... o que nos permite acessar repositórios usando algo como http://svn.ourdomain.tld/repo . Estamos executando essa configuração há cerca de dois anos sem problemas.
Recentemente, descobrimos que precisamos verificar um dos repositórios no próprio servidor, no entanto, sempre que o fazemos, parece que ele quebra o repositório. A partir desse momento, ele só responderá com um erro 301 Moved Permanently .
Nós tentamos:
svn co file:///path/to/repo svn co svn://localhost/repo svn co svn://svn.ourdomain.tld/repo svn co svn+ssh://localhost/repo svn co svn+ssh://svn.ourdomain.tld/repo svn co http://localhost/repo svn co http://svn.ourdomain.tld/repo Também tentei ignorar o nginx e obter o mesmo erro:
svn co http://localhost:8080/repo svn co http://svn.ourdomain.tld:8080/repo Fazer check-out de uma máquina diferente funciona conforme o esperado até que tentemos fazer o check-out no servidor, depois ele se recusa com o mesmo erro 301 .
O que é mais confuso é que esse servidor de repositório também hospeda nosso servidor de IC Hudson , que pode puxar e construir nossos projetos a cada hora . Isso nos leva a suspeitar que é o cliente svn que está causando um erro na comunicação.
Também é muito confuso que a remoção da re-criação do repo usando svnadmin não redefina o erro - o repo ainda está indisponível , apesar de ser "novo"! Reiniciar o apache e o subversion (svnserve) não tem efeito sobre isso, ou o erro original.
Informação da versão:
ATUALIZAÇÃO:
Isso também acontece com svn export quando executado no servidor repo. Corrido de qualquer outra caixa / cliente, não há problema. Aqui está o fluxo de trabalho, para ajudar a esclarecer o erro:
[~repo-server~]# svnadmin create {repo}; chown -Rf www:www {repo} [remote-client]# svn checkout http://svn.ourdomain.tld/repo [remote-client]# svn add file; svn ci -m '' [~repo-server~]# cd /var/www; svn export file:///path/to/repo/trunk ourproject [remote-client]# svn update falha com o erro 301
Eu também posso confirmar que o nome do host da caixa não tem um efeito aqui, o que é muito estranho: se svn.ourdomain.tld é adicionado ou não a /etc/hosts ele ainda quebra - nós pensamos que poderia ser um problema com roteamento localhost, mas isso não parece ser o caso.
Estamos omitindo alguma coisa na documentação que indica que você não pode fazer check-out de um repositório quando o servidor está na mesma caixa? Como podemos impedir que os repositórios se corrompam quando fazemos o check-out localmente?
O svn não manipula redirecionamentos HTTP (é o que o erro 301 é), olhe para onde os redirecionamentos apontam (wget, wireshark), confira a partir daí.
Também é um problema específico do apache, a configuração do host virtual pode estar quebrando-o.
Tags nginx svn apache-2.2 httpd