svn: ocorreu um erro ao confirmar a transação

0

Alguém pode me ajudar a depurar esse problema? Tudo funciona (ou seja, posso confirmar, check-out, etc.), mas este commit sempre falha conforme descrito abaixo. Eu tentei verificar em um novo repositório e cometer, mas mesmo problema. Note também que este é um repositório muito grande (500GB), e um commit muito grande (36k arquivos totalizando 10GB).

Este é o log de erro apache2 :

[Sat Feb 10 03:25:16.262765 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Could not DELETE /svn/repo/!svn/txn/463-e8.  [500, #0]
[Sat Feb 10 03:25:16.265881 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] could not abort transaction.  [500, #2]
[Sat Feb 10 03:25:16.265905 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Transaction '463-e8' cleanup failed  [500, #2]
[Sat Feb 10 03:25:16.265923 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0'  [500, #2]
[Sat Feb 10 03:25:16.265940 2018] [dav:error] [pid 3339] [client X.X.X.X:61908] Can't remove file '/mnt/vc/svn/repo/db/transactions/463-e8.txn/node._ji.0': No such file or directory  [500, #2]
[Sat Feb 10 03:25:30.640591 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] Could not MERGE resource "/svn/repo/!svn/txn/463-e8" into "/svn/repo/repofolder".  [500, #0]
[Sat Feb 10 03:25:30.642889 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] An error occurred while committing the transaction.  [500, #160014]
[Sat Feb 10 03:25:30.643003 2018] [dav:error] [pid 2966] [client X.X.X.X:61712] Reference to non-existent node '_1bqk.0.t463-e8' in filesystem '/mnt/vc/svn/repo/db'  [500, #160014]

O lado do cliente dá:

done
Committing transaction...
svn: E175012: Commit failed (details follow):
svn: E175012: Connection timed out
svn: E200042: Additional errors:
svn: E175002: Unexpected server error 500 'Internal Server Error' on '/svn/repo/!svn/txn/463-e8'

Primeiro, achei que isso era um problema de permissão. Então eu fiz isso no servidor:

su - www-data -s /bin/bash -c "svnadmin rmtxns /mnt/vc/svn/repo/ 463-e8"
Transaction '463-e8' removed.

Nenhum erro. O Apache é executado como www-data . As seguintes permissões são definidas:

chown www-data:www-data /mnt/vc -R
chmod 0774 /mnt/vc -R

Eu executei svnadmin verify e não encontrei problemas. dmesg não mostra nada novo.

O svn config do apache é praticamente padrão.

KeepAlive On
MaxKeepAliveRequests 0
# Set to 10h.
Timeout 36000

SVNCompressionLevel 5
SVNInMemoryCacheSize 16384
SVNCacheTextDeltas On
SVNCacheFullTexts On
SVNAllowBulkUpdates Prefer

<Location /svn>
    DAV svn
    SVNParentPath /mnt/vc/svn
    SVNListParentPath On

    # Allow large request
    LimitXMLRequestBody 0
</Location>

Informação extra:

Server: Debian 9.3
apache2/stable,stable,now 2.4.25-3+deb9u3 amd64 [installed]
libapache2-mod-svn/stable,stable,now 1.9.5-1+deb9u1 amd64 [installed]
Server svn client: 1.9.5-1+deb9u1 
Client: svn 1.9.7

EDITAR: copiei a cópia de trabalho para o servidor de repositório. Então tentei commitar, mas tive o mesmo erro. Em seguida, reposicionei a cópia de trabalho para direcionar o local do repositório: svn relocate file:///mnt/vc/svn/repo . Commit trabalhou desta vez. Então tem que fazer alguma coisa com dav_svn ?

A mesma pergunta foi feita em lista de discussão de usuários do subversion .

    
por Davor Josipovic 10.02.2018 / 11:16

1 resposta

0

Este parece ser um problema do lado do cliente que resulta em erros estranhos no servidor.

Depois que o cliente transfere todos os arquivos para o servidor, o servidor começa a enviá-los para o repositório. Durante esse tempo, o cliente não obtém resposta e, se demorar mais do que o tempo limite padrão, o cliente fecha a conexão, resultando no erro acima no lado do servidor.

One change in 1.8 is that serf is used to handle HTTP on the client-side rather than neon. The default client-side HTTP timeout when using neon is 60 minutes but when using serf it is 10 minutes. A client can change its default timeout by setting servers:global:http-timeout.1

E aqui é a documentação do arquivo servers

A configuração de http-timeout = 3600 na tag [global] corrige o problema de maneira eficaz.

    
por 20.05.2018 / 20:59