windows - La comprobación de SVN grande falla esporádicamente
apache xampp (4)
Este parece ser un problema de codificación de los archivos según esta publicación en la lista de subversion mailling. Puede buscar las AddEncoding x-gzip .gz en su configuración de apache y eliminarlas o agregarlas a su entrada <Location /svn>…</Location> :
RemoveEncoding .gz
RemoveEncoding .Z
Esto se mencionó en la lista de changelog , pero tampoco me importó leer esto y lo aprendí de la manera más difícil ...
Actualmente estoy experimentando problemas durante un proceso de pago en el repositorio SVN completo (20 GB +), donde el proceso de pago se detendrá de forma aleatoria. El repositorio está compuesto por muchos archivos de texto pequeños y algunos archivos CSV grandes.
Ha sido difícil reducir el problema, ya que el error solo aparece unas pocas horas después del pago. Por lo que he visto, no es un archivo específico que detenga el proceso y la verificación con svnadmin no arrojó errores.
Errores:
Registro de errores típico de Apache:
Unable to deliver content. [500, #0]
Unable to deliver content. [500, #0]
Could not write data to filter. [500, #175002]
Could not write data to filter. [500, #175002]
Provider encountered an error while streaming a REPORT response. [500, #0]
A failure occurred while driving the update report editor [500, #730053]
Especificaciones:
Servidor: Windows Server 2003 ejecutando XAMPP v1.8.2-5, Apache v2.4 y SVN v1.8.9. Recientemente se actualizó desde Apache v2.2 y SVN v1.5.3, que estaba experimentando problemas similares.
Clientes: Windows 7 ejecutando TortoiseSVN v1.8.8 x64, actualizado recientemente desde v1.8.3 x64 que estaba experimentando problemas similares. Línea de comandos SVN v1.8.9.
Estoy usando el protocolo HTTP para realizar el pago.
Cosas que he probado:
Establecer la directiva "TimeOut" en Apache a un valor más alto (hasta 30000 segundos).
Desactivando la directiva "SVNAdvertiseV2Protocol".
Desactivando la directiva "SVNPathAuthz".
Poniendo la directiva "SVNCompressionLevel" a "0".
Hemos estado corriendo en este mismo problema recientemente. Hasta ahora creo que se ha relacionado con nuevos clientes de subversión.
Directiva Apache dav_svn_module
SVNAllowBulkUpdates Prefer
Parece que ayuda. Después de agregar eso en apache conf, no se han encontrado problemas. Antes de eso la mayoría de los grandes chequeos fallaron
Encontré un hilo de discusión que explica los problemas relacionados con los clientes de Subversion que son más nuevos que la versión 1.8.x. Ver el hilo de la lista de correo.
Me encontré con el mismo problema al intentar realizar un pago SNV en un repositorio de tamaño moderado (500 MB) usando un servidor que consta de clientes Centos 7.4.1708, Apache 2.4.6, Subversion 1.9.15 y Windows 10 usando TortoiseSVN 1.9.7 desde atrás un Apache Reverse Proxy.
La solución para mí fue agregar SVNAllowBulkUpdates Off similar a la respuesta de teori. Intenté usar " Prefiero SVNAllowBulkUpdates ", pero cuando reinicié httpd, se produjo un error que decía " SVNAllowBulkUpdates debe estar activado o desactivado ". Mi archivo de configuración final de SVN / Apache es:
<Location /svn > DAV svn SVNParentPath /svn SVNAllowBulkUpdates Off AuthType Basic AuthName "SVN Repo" AuthUserFile /var/svn/svn-auth-user Require valid-user </Location>
Otros pensamientos: No creo que las configuraciones de Timeout y AuthDigestNonceLifetime estén directamente relacionadas con el problema. Intenté usarlos pero ninguno tuvo ningún efecto. Experimenté específicamente las configuraciones de timeout , keepalive y keepalivetimeout tanto en el host SVN como en el host proxy inverso.
El problema puede estar relacionado con "desinflar", pero también lo deshabilité como sugirió Tim S. y tampoco tuvo efecto. La razón por la que sigo pensando que puede estar relacionado es que, después de eliminar el error, noté que la cantidad de bytes transferidos era sustancialmente mayor que antes.
Tuve los siguientes errores:
Unable to deliver content. [500, #0]
Could not write data to filter. [500, #175002]
Ni siquiera mod_deflate el mod_deflate para que no pudiera ser. En mi caso resultó ser la autenticación ( auth_digest_module ) causando el error. Si un proceso de checkout dura más de 300 segundos, tendría el error anterior registrado en mi registro del servidor Apache.
El problema es la directiva predeterminada AuthDigestNonceLifetime 300 . Ver here Mi solución fue establecer esta directiva en infinito: AuthDigestNonceLifetime -1