he recuperado repositorio SVN desde el PC estrellado y ahora puede comprobación de archivos desde algunos directorios, pero en un solo lugar durante la compra que dice:No se pudo leer el tamaño del fragmento. Error en el SVN
Error: REPORT of '/svn/RepTest/!svn/vcc/default': Could not read chunk size:
Secure connection truncated (https://mypc:8443)
Podría alguien ayudarme, cómo solucionar ese repositorio? Gracias!
tuve el mismo problema, uso TortoiseSVN y VisualSVN, el problema está en uno de sus commits, pero es difícil saber cuál es, la solución para mí fue eliminar y crear el repositorio en VisualSVN luego hacer el lo mismo que en la "carpeta de pago" en mi pc, después de esto, copie el proyecto en la carpeta y haga el "segundo compromiso inicial" :) pero perderá todas las confirmaciones anteriores.
¡Uf, eso es terrible! –
seguro, pero es mejor que obtener el error todos los días y no puede agregar una nueva confirmación, han pasado 8 meses desde la pregunta, y todavía no hay una respuesta mejor, al menos podrá trabajar, no en las mejores condiciones Lo sé. –
Al momento de pagar recibí el mismo error. El problema fue de hecho con revisiones específicas, así que hice una solución. Parecía que las revisiones que planteaban el error tenían un largo camino. Otro vistazo a las revisiones específicas me hizo pensar que podría no necesitar estar bajo el control de la fuente. Estos archivos se generaron automáticamente en cada compilación. Acabo de guardar otra copia del directorio completo en una carpeta 'Deprecated' y borré los archivos/carpetas problemáticos. Después de la eliminación, la comprobación fue correcta.
Acabo de tener el mismo error al intentar actualizar un pago y envío a la última revisión. Un poco de violín reveló que era un archivo particular el que causaba el problema. Por ejemplo:
root
- A
- AFileInFolderA.h
- AnotherFileInFolderA.h
- B
- AFileInFolderB.h
- C
- AFileInFolderC.h
Con la estructura anterior de recompra, AFileInFolderA.h fue el archivo del problema. Llegué a esta conclusión porque podría hacerlo y svn update en las carpetas B y C pero no en root o en la carpeta A. Profundizando más, podría actualizar AnotherFileInFolderA.h pero no el problema.
De todos modos, con esa información en la mano he copiado mi copia cambios de trabajo de la carpeta A, entonces (utilizando Tortoise SVN) hice un selectiva Actualizar a la revisión en la carpeta raíz, excluyendo carpeta A de mi salida. Luego hice lo contrario, volviendo a agregar la carpeta al proceso de pago. Finalmente, agregué mis cambios locales y me comprometí con el repositorio. Todo ahora está funcionando bien.
¿Alguna explicación para el downvote? – sjwarner
que tenían el mismo error recientemente:
Informe '/svn/.../!svn/vcc/default': No se pudo leer tamaño del fragmento: Conexión segura truncado.
Estamos usando Tortoise SVN y yo era el único en el equipo que tenía el problema. Como el problema no me impidió comprometer mis cambios, lo hice. A continuación, eliminé la carpeta con el proyecto de mi disco duro. Luego lo creé de nuevo y realicé un "checkout de SVN".
Esto es lo que me solucionó.
Para nosotros, el problema era que faltaban archivos en el historial SVN (probablemente daños en el disco). Cualquier operación que incluyera un archivo cuyo cambio más reciente fuera de la sección faltante del historial fallaría con el error "no se pudo leer el tamaño del fragmento" o un error XML no válido (dependiendo de la operación). Afortunadamente, tuvimos una copia de seguridad que incluía los archivos faltantes. Restaurarlos solucionó el problema.
Tuve problemas similares, por lo que 'svnadmin recover' realmente solucionó cosas mágicamente.
En otro repositorio, no sería ... Utilizando el cliente Versions SVN (MacOSX) pude ver que el nombre de usuario de algunos archivos en directorios que funcionaban mal era '### ERROR ###' - estos directorios eran dándome el problema "Conexión segura truncada" en la actualización. Simplemente "mover" los archivos que tenían este marcador a otro directorio y volver (en el servidor, a través del cliente Versions SVN), fue suficiente para eliminar el marcador ### ERROR ### y habilitar la actualización exitosa.
Sin embargo, otra respuesta por alguien con el mismo problema, sin embargo, con una solución que aún no se ha mencionado:
En mi caso, el problema no se ha podido establecer claramente en un solo archivo. Sin embargo, estaba claramente conectado a una única revisión svn.
La solución en tal caso es omitir la obtención de la mala revisión. Esto se puede lograr llamando al git svn fetch con la opción -r. Por ejemplo, si r42 es la mala revisión, y ya se han recuperado todas las revisiones hasta r41, acaba de hacer
git svn fetch -r43
seguido por
git svn fetch
traer su repositorio git hasta la fecha. Por supuesto, la desventaja obvia de este enfoque es el agujero en la historia que obtienes, pero creo que es mejor tener un pequeño agujero en la historia que prescindir de un clon que funcione git svn.
¿Cómo se identifica a qué revisión está atascado? –
@JaySullivan Esa es la parte engañosa: la salida de 'git svn fetch' no muestra la revisión en la que se produjo el error, por lo que debe confiar en' git svn fetch' para obtener las revisiones en orden. Creo que, a menos que tengas el registro del primer 'git svn fetch' alrededor, que contiene el último número de revisión que fue obtenido con éxito, solo hay dos maneras de averiguarlo: 1. revisa las revisiones svn de todas las ramas extraídas a través de 'git svn find-rev', o 2. reinicie todo el proceso de clonación' git svn' para recuperar ese registro. Lo siento, no sé una mejor manera. – cmaster
¿ejecutó "svnadmin recover" en el repositorio? – Stefan
Sí, lo hice, dice: svnadmin: Recuperación completa. Pero al pagar el mismo error. – ihorko
Compruebe los registros del servidor de VisualSVN. Se encuentran en el Visor de eventos -> Aplicaciones y servicios -> Servidor VisualSVN –