Como você corrige um erro de conflito SVN 409

Question

Eu costumava usar o SVN 1.4 no OS X Leopard e tudo estava bem. Há algumas semanas, instalei uma nova cópia do OS X 10.6. A versão do SVN que vem com o Snow Leopard é 1.6.5. Fui em frente e construí minha própria cópia com 1.6.6. Estou usando o servidor Apache embutido e apenas hospedando repositórios localmente.

Tudo parecia funcionar bem até que eu realmente tentei cometer algo. Toda vez que tento cometer uma mudança, recebo a seguinte mensagem:

Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/svn/svn2': 409 Conflict (http://localhost)

Isso acontece com meus antigos repositórios, então eu criei alguns novos. Mesmo negócio. Eu também tentei usar a versão 1.6.5 que vem com o sistema ... o mesmo. Por fim, tentei atualizar para o mais recente SVN estável (1.6.9) e ainda tive o mesmo problema.

O erro do Apache registra o seguinte para cada comprometimento falhado:

[Mon Mar 29 19:53:10 2010] [error] [client ::1] Could not MERGE resource "/svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1" into "/svn/svn2".  [409, #0]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] An error occurred while committing the transaction.  [409, #2]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] Can't open directory '/usr/local/svn/svn2/db/transactions/5-6.txn/\xeb\xa9\x0f\x1f': No such file or directory  [409, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Could not DELETE /svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1.  [500, #0]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] could not open transaction.  [500, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Can't open file '/usr/local/svn/svn2/db/transactions/5-6.txn/props': No such file or directory  [500, #2]

E do log de acesso:

::1 - - [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 401 401
::1 - user [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 200 188
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/vcc/default HTTP/1.1" 207 398
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/bln/6 HTTP/1.1" 207 449
::1 - user [30/Mar/2010:13:02:20 -0400] "REPORT /svn/svn2/!svn/vcc/default HTTP/1.1" 200 1172

Curiosamente, o compromisso realmente compromete as alterações, mas a cópia de trabalho não vê isso e tudo fica ferreiro.

Eu tentei pesquisar no Google todas as variações que consigo pensar para esse problema, mas os resultados da pesquisa são praticamente inúteis. Não estou usando o Tortoisesvn ou qualquer coisa especial e os compromissos falham em um novo repositório, então sei que não é um problema com meus repositórios antigos.

Qualquer ajuda seria muito apreciada.

Atualizar
Tentei adicionar autoversão ao meu arquivo svn.conf. Aqui está o que meus arquivos dizem:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNAutoversioning on

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /usr/local/etc/svn-auth-file

  # only authenticated users may access the repository
  Require valid-user
</Location>    

Atualização (solução)

Eu só queria atualizar isso com a solução real, caso qualquer outra pessoa esteja tendo o mesmo problema com as mensagens de erro completamente inúteis. O problema estava nas peças APR e APR-Util (como Scherand sugeriu). Eu estava construindo uma cópia de ambos usando o pacote de dependências de subversão. OS X 10.6 também tem sua própria versão. Ambas as versões foram 1.3.8. Aparentemente, porém, eu precisava usar as versões que a instalação do Apache padrão estava usando.

Então, eu apaguei as pastas APR e APR-Util da minha construção de subversão, para garantir que eu não estivesse construindo minha própria cópia delas novamente. Eu construí SVN da fonte novamente, desta vez usando a seguinte configuração:

./configure --with-apr=/usr/bin/ --with-apr-util=/usr/bin/ --with-ssl

Depois de construir novamente, reiniciei o Apache e criei um novo repo SVN. Consegui conferir, fazer alterações e cometer sem problemas. Tentei então meus repositórios antigos e os que funcionaram também.

Obrigado a todos pela ajuda!

Answer 1

Estou em gelo muito fino aqui (409 não é muito específico), mas sou capaz de formular duas perguntas:

1. Existem ganchos pré ou pós-comprometimento?
2. É "Autoversão" ativado?

Se houver ganchos, tem certeza de que eles não contêm erros? Você poderia desativá -los para um teste? Se a autoversão não estiver ativada, você poderia tentar ativá -lo para um teste? Isso deve funcionar na linha de

<Location /repos>
  DAV svn
  SVNPath /var/svn/repository
  SVNAutoversioning on
</Location>

Ao usar mod_dav_svn (Veja o link para a autoversão acima).

Talvez isso ajudasse a esclarecer seu problema e nós (e/ou Google :)) poderíamos levá -lo a partir daí.

BTW: Os logs que você postou não são da mesma confirmação, certo? A diferença horária seria enorme?!?

Editar:Desculpas se você encontrou isso há muito tempo, mas vou tentar: Não foi possível mesclar o recurso no Commit (Apache 2.0.55) é algo que o Google encontrou para mim :)

O OP lá escreve que "Apache dita a versão de Apr Para usar ". Isso significa que você deve fazer referência à versão correta do APR ao compilar SVN. Eu instalei SVN (v1.6.9) a Macports no meu sistema (OS X 10.6). Não uso o WebDav ou o Apache localmente, mas tenho 1º de abril. O OP sugere usar --with-apxs=/path/to/bin/apxs Ao compilar o SVN, embora eu não tenha certeza se isso se aplica à sua situação (comecei a adivinhar há muito tempo, você pode notar :)).

Qualquer chance de você verificar o APACH APACHE APACH espera vs. o usado para construir SVN (por exemplo, você pode usar sudo port installed apr Para ver o que a APR-versões vivem no seu sistema, se você estiver usando o Macports)?

Apenas para referência a um trecho de Construindo Apache da maneira que você quer:

apxs é uma utilidade independente para compilar módulos dinamicamente sem a necessidade de usar o configure Script ou tenha o código -fonte do Apache disponível. No entanto, ele precisa de arquivos de cabeçalho do Apache, que são copiados para o local definido por --includedir Quando o Apache é instalado. No entanto, é importante usar um apxsque foi construído com as mesmas opções de configuração que o Apache; Caso contrário, ele fará suposições errôneas sobre onde estão os vários locais de instalação do Apache.

Answer 2

Eu tenho duas idéias de onde o problema pode estar escondido, que são obviamente suposições selvagens, então seja avisado.

Por um lado, pode ser apenas um problema de permissões de arquivo. Eu sei, parece bobo, mas talvez exista algum arquivo de configuração, ou um gancho como Scherand sugeriu, ou mesmo alguma pasta dentro da estrutura do repositório que foi deixada ilegível pela atualização para 10.6 ou ao criar a nova versão SVN, então eu 'D verifique isso.

A segunda idéia é verificar a compatibilidade das versões SVN Working Copy-Client-Server-Repository. Os caras da subversão juram que ambos 1.5 e 1.6 Não quebre a compatibilidade no nível do repositório com 1.4 (embora eles façam isso em cópias de trabalho). Mas não faria mal verificar se o formato de toda a pilha é consistente. E enquanto estiver nisso, verifique se as bibliotecas do Apache que você construíram são compatíveis com o Apache 2.2.11 que vem com 10.6 (novamente, eles deveriam, mas você nunca sabe)

E, finalmente, boa sorte.

Answer 3

Primeiro estabeleça uma linha de base. Em uma instalação de estoque de Snow Leopard (10.6.3), aqui está exatamente o que eu fiz.

Criou "/etc/apache2/other/svn.conf" com conteúdo:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
    DAV svn
    SVNParentPath /usr/local/svn
    AuthType Basic
    AuthName "Subversion repository"
    AuthUserFile /usr/local/svn/htpasswd
    Require valid-user
</Location>

Criada pasta de subversão e repositório "teste":

sudo mkdir /usr/local/svn
sudo svnadmin create /usr/local/svn/test
sudo chown -R _www:_www /usr/local/svn
sudo htpasswd -cb /usr/local/svn/htpasswd testuser testpass

Do usuário normal, diretório doméstico:

macmini:~ jclark$ mkdir Checkout && cd Checkout
macmini:Checkout jclark$ svn --username testuser checkout http://localhost/svn/test
Authentication realm: <http://localhost:80> Subversion repository
Password for 'testuser':
Checked out revision 0.
macmini:Checkout jclark$ cd test && touch test.txt && svn add test.txt && svn commit -m 'test' test.txt
A         test.txt
Adding         test.txt
Transmitting file data .
Commited revision 1.
macmini:test jclark$

Agora, se tudo isso funcionou como deveria, você terá um repositório de subversão em estoque de trabalho 1.6.5 servido pelo Apache. Caso contrário, você provavelmente está misturando binários/libs SVN fornecidos pela Apple com o seu próprio (Macports etc.) ou Existem problemas de permissões. Faço claro Você está usando os binários fornecidos pela Apple. A Apple modifica a fonte um pouco e eu encontrei problemas de compatibilidade ao misturar 'portas' com 'estoque' no passado. Quanto às permissões, o Apache é executado como usuário _www, grupo _www. Certifique -se de que todos os arquivos e diretórios pertencem a tal e não se esqueça de atualizá -los sempre que usar o svnadmin ou algo mais para manipular diretamente o repositório SVN.

Como isso está funcionando, mova seu repositório 'svn2' de volta para/usr/local/svn (se você ainda não o fez), faça uma compra limpa em algum lugar e tente uma confirmação de teste.

Se você ainda está enfrentando problemas, tente atualizar o repositório.

sudo svnadmin upgrade /usr/local/svn/svn2
sudo chown -R _www:_www /usr/local/svn/svn2

Repita o teste de checkout / comprometimento.

Como último recurso, despeje e carregue o repositório novamente.

sudo svnadmin dump /usr/local/svn/svn2 > /tmp/svn2.dump
sudo svnadmin create /usr/local/svn/svn3
sudo svnadmin load /usr/local/svn/svn3 < /tmp/svn2.dump
sudo chown -R _www:_www /usr/local/svn/svn3

Repita o teste de checkout /comprometimento, desta vez com /svn /svn3.

Aproveite seu repositório fixo ... espero :)

atualizar

Pode haver um incomodar no cliente da linha de comando de subversão. Depois de fazer:

mkdir \!vcc && touch \!vcc/default
svn add \!vcc && svn commit -m 'test'
svn log

Observe que a saída do log SVN (pelo menos para mim) não é nada. O log do SVN da Tortoise está bem, o que indica que o servidor (conforme a configuração acima) está funcionando corretamente.

Outra coisa a tentar é acessar o repositório via 'arquivo' em vez de 'http'. Copie o repositório inteiro para o seu diretório inicial ou em algum lugar do seu usuário é o proprietário e confira (por exemplo, svn checkout/usuários/shared/svn/svn2) e tente se comprometer.

Answer 4

Você tentou Versões o cliente SVN para OSX? Não é uma solução para o seu problema, mas talvez uma alternativa. Eu e minha equipe tivemos alguns problemas para que o SVN e o OSX conversassem um com o outro corretamente, então procuramos clientes e versões alternativas funcionaram muito bem para nós.

Answer 5

chown -R apache:apache svn

chmod -R 770 svn

Answer 6

Isso resolveu o conflito para mim: fiz um backup dos meus arquivos locais, então puxou tudo do servidor. Então, quando eu inseri e empurrei meus arquivos de backup, o erro de conflito 409 não apareceu novamente.

Atenciosamente, Kevin