subversion - tortoise svn server
La actualización desde el repositorio svn devuelve el error "No se pudo leer el tamaño del fragmento" (13)
Al actualizar desde el repositorio de subversión usando el cliente svn tortuga me sale un error que se ve así:
Could not read chunk size: An existing connection was forcibly closed by the remote host.
No me impide actualizar, simplemente interrumpe el proceso de actualización, por lo que tengo que repetir la actualización varias veces antes de que se complete.
¿Qué puede causar tal comportamiento y cómo solucionarlo?
Acabo de recibir el error "No se pudo leer el tamaño del fragmento" Y ENCONTRÉ UNA SOLUCIÓN , al menos para un escenario.
Primero, mi configuración ...
SERVIDOR: CollabNet Subversion Edge Server 2.0.0-2190.74 (binarios de Subversion 1.6.17-2190.74) se ejecuta en Windows Server 2003 de 32 bits.
CLIENTE: TortoiseSVN 1.6.16, Build 21511 - 32-Bit (Subversion 1.6.17) ejecutándose en Windows XP Pro 32-bit con SP3.
Pasos para reproducir...
Obtuve este error después de hacer clic derecho y arrastrar una subcarpeta versionada a otra subcarpeta versionada dentro de mi carpeta de copia de trabajo local y luego elegir ''SVN Copiar los elementos versionados aquí'' (este es un comando de menú contextual de TortoiseSVN en Windows Explorer cuando está justo arrastrando carpetas). La subcarpeta contenía un archivo de texto codificado en ANSI, MANIFEST.MF, que creo que no modifiqué (mi configuración de Subversion no incluye un tipo de mime para archivos .MF). Posteriormente cometí la subcarpeta recién copiada. Más tarde, cada vez que intenté actualizar mis carpetas de copia de trabajo local de Subversion en esta PC, obtuve el error de tamaño de fragmento.
Work-around ...
Resolví esto reiniciando mi servicio Subversion / Apache (que en sí mismo no me ayudó y podría no haber sido necesario), y luego borré la subcarpeta recién agregada de mi carpeta local de copia de trabajo (ya había llegado al repositorio, por lo No iba a perder nada), Y ENTONCES al realizar una actualización , que tuvo éxito sin el error de tamaño de fragmento y recargó la subcarpeta que acabo de eliminar.
En mi caso, había copiado DOS subcarpetas versionadas de esta manera, y no pude actualizar correctamente la raíz de mi carpeta local de copia de trabajo hasta que eliminé AMBAS de estas nuevas subcarpetas.
Seguir...
Supongo que esto es un error en el servidor de Subversion y / o en el cliente de TortoiseSVN, pero no tengo las habilidades de depuración para tomar esa determinación. Informaré mis hallazgos en TortoiseSVN Issue Tracker y veré a dónde va eso.
Cambié a un servidor Ubuntu y tuvimos el mismo error: en varias PC de cliente, SO y versiones de cliente.
Después de asegurarse de que tanto la configuración del límite de archivos como la configuración del tiempo de espera de Apache fueran las sugeridas.
(Ver http://posidev.com/blog/2009/06/04/set-ulimit-parameters-on-ubuntu/ )
Eventualmente resolví el problema usando el paquete apache2-mpm-prefork en lugar del paquete apache2-mpm-worker.
El problema y (algunos otros) desaparecieron después de desactivar el antivirus del lado del cliente.
Estoy usando Ubuntu Server con subversion 1.7.4 a través de Apache.
Estaba recibiendo este mismo mensaje de error en las actualizaciones después de renombrar una carpeta y me comprometí. Creé un nuevo directorio de trabajo y no recibí el error. Entonces, acabo de mover mis cambios al nuevo directorio de trabajo, comprometí y destruí el directorio anterior.
Por lo tanto, este error parece ser causado por mi directorio local corrompido.
Esto claramente tiene muchas causas, pero para mí esto se solucionó reiniciando mi servidor SVN (VisualSVNServer 2.5.1). Esto ocurre con frecuencia cuando se realiza un proceso completo de repo en un volcado nuevo.
Hay otra causa molesta para este mensaje de error. Podría ser su enrutador o el firmware de su enrutador.
Recientemente, actualicé el firmware de mi Linksys WRT110 de la versión 1.0.02 a la 1.0.07 y luego de eso, la subversión ya no pudo agregar nuevos archivos al repositorio. Solo podría actualizar los archivos existentes. Volviendo a 1.0.02 corrigió el problema.
Fuentes:
- http://blog.wouldbetheologian.com/2008/12/warning-on-linksys-wrt110-firmware.html
- http://homecommunity.cisco.com/t5/Wireless-Routers/Upgraded-WRT-110N-to-1-0-07-and-now-Subversion-won-t-work/td-p/321812
Básicamente, cada vez que se interrumpe abruptamente la conexión, obtendrá este error. Podría ser un error de configuración en Apache, como muchos de ustedes indicaron. También podría deberse a un servidor lento o una conexión sobrecargada, o podría deberse a un enrutador barato, como en mi caso.
Obtuve el mensaje "No se pudo leer el tamaño del fragmento" de los clientes en varias máquinas.
La clave para descubrirlo fue este error en el registro de errores de Apache:
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Provider encountered an error while streaming a REPORT response. [500, #0]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Problem replaying revision [500, #24]
[Fri May 07 14:26:26 2010] [error] [client 155.35.175.50] Can''t open file ''/usr/site/svnrep/impc/db/revs/16122'': Too many open files [500, #24]
El proceso de Apache que manejaba la operación svn se estaba quedando sin descriptores de archivos. En mi servidor Ubuntu, lo arreglé editando /etc/security/limits.conf y agregando esto en la parte inferior:
* hard nofile 5000
* soft nofile 5000
Lo que aumenta el límite del descriptor de archivos de 1024 a 5000. Luego, inicié sesión en un nuevo intérprete de comandos y confirmó que el límite aumentó a través de ulimit -n . Luego reinició Apache.
Para nosotros, el problema fue un tiempo de espera en Apache. La actualización tardaba unos 15 minutos, pero Apache agotó el tiempo de espera después de 10 minutos, lo que provocó que nuestro servidor SVN emitiera el error que ves. La solución final fue aumentar la configuración de tiempo de espera para Apache. Utilizamos el servidor VisualSVN: para obtener instrucciones detalladas sobre cómo cambiar esta configuración, consulte aquí: http://adventuresindotnet.blogspot.com/2010/09/svn-trouble.html
Para nosotros, la solución fue rebajar el cliente SVN de 1.8 a 1.7 (cliente de línea de comandos incluido con TortoiseSVN).
Simplemente me sucedió esto, y no fue un problema de servidor; mi copia de trabajo se corrompió (por mi parte, por cierto).
Verifique el registro de errores de Apache, debe haber un error registrado con un número de error. Ese número ayudará a descubrir por qué se eliminó la conexión.
Si no hay nada en el registro de errores, verifique la configuración de su antivirus / cortafuegos: algunas de esas herramientas desconectarán una conexión si creen que los datos transferidos son peligrosos.
Yo también lo entiendo Nuestro servidor es Apache corriendo en Windows. Mi cliente está conectado con una latencia de alta velocidad pero algo alta (200 ms). La otra parte del rompecabezas es que estoy ejecutando Windows Vista. Al girar el autoescalado y rss parece mejorar la situación, pero no se soluciona.
VisualSVN 2.5.8: Tenía el mismo error, los siguientes pasos me ayudaron a corregir este error:
En el servidor:
- Eliminado en la carpeta problemática del servidor;
- Reinicie el servidor de VisualSVN.
En la estación de trabajo:
- Actualizar la carpeta principal;
- Agrega carpetas y archivos de nuevo;
- Agregar a SVN;
- Cometer.