¿Cómo puedo solucionar el error de finalización de línea de importación de SVN?

Question

Tengo que importar un enorme repositorio SVN que tengo que transferir de un servidor a otro. Así que he exportado desde el servidor antiguo:

svnadmin dump . > archive.svn 

e importados en el nuevo:

svnadmin load . < archive.svn 

En medio del proceso de importación Tengo este error:

Cannot accept non-LF line endings in 'svn:ignore' property 

¿Cómo puedo arreglar esto? Tengo control total de ambos servidores.

Answer 1

¿Ha cambiado la versión del servidor? Este es un problema conocido en 1.6 y causa problemas cuando se pasa de 1.4 o 1.5.

Subversion 1.6 ya no acepta devoluciones de carro (^ M) en los archivos de propiedades. Tendrá que corregir los saltos de línea en su svn: ignorar archivo (s), o volver a crear si es más fácil.

Alternativamente, podría ir por Subversion 1.7, o usar uberSVN.

Answer 2

Tiene 2 opciones, repara la fuente o deshabilita la validación de la utilería.

Reparación de la fuente (svn: log y svn: ignore):

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' archive.svn > repaired-archive.svn 

svnadmin load . < repaired-archive.svn 

Dónde ^M es un carácter de control, que significa 0D en hexadecimal. Para conseguirlo utilizar^V^M (control de control V M) en lugar^M (circunfleja M o control M)

Desactivación de validación prop:

svnadmin load --bypass-prop-validation . < archive.svn 

Answer 3

me encontré con este error al actualizar un 1.6 repo a 1.8. Encontré una cantidad de "Soluciones" en la red.

El --bypass-validación-validación no me atrajo porque pospone el problema, la próxima vez que necesite restaurar el repositorio, ejecutará el mismo problema.

Encontré un script bash para recorrer las revisiones obteniendo los comentarios y configurándolos nuevamente, pero esto no funcionó.

Una mejora en la solución de ventura10 hizo el trabajo. Debido al tamaño del vertedero Terminé usando el comando único para eliminar los caracteres no deseados mientras se restaura el vertedero

sed -e '/^svn:log$/,/^K/s/^M/ /' -e '/^svn:ignore$/,/^PROPS-END$/ s/^M/\n/' /path/to/svn.dump | svnadmin load /path/to/repo 

NOTA:

Where ^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

Answer 4

La primera opción de la respuesta de @ ventura10 sonaba bien pero no funcionó para mí. El comando sed cambió algo del contenido versionado fuera de la sección de propiedades, lo que provoca que md5 no coincida al cargar el volcado.

Como mi repositorio no tiene propiedades con contenido binario, modifiqué el comando sed para corregir todas las propiedades y no solo svn:log y svn:ignore. También estaba seguro de que ningún archivo versionado contenía una línea que comienza con Prop-content-length:. De lo contrario, habría recibido un error al cargar el volcado.

sed -e '/^Prop-content-length: /,/^PROPS-END$/ s/^M/ /' svn.dump > svn.dump.repaired 

Es importante reemplazar ^M con [blank], debido a que el tamaño del valor de la propiedad no debe cambiar.

La nota de @ ventura10 sigue siendo válida:

^M is a control character, that means 0D in hex. To get it use ^V^M (control V control M) instead ^M (circumflex M or control M)

Es difícil de creer que la actualización de un repositorio existente desde SVN 1.4 a SVN 1.7 hace que este paso nessecary, pero he encontrado ninguna otra manera deshacerse de los retornos de carro que ya no se aceptan desde svn 1.6.

Answer 5

Uso svndumptool:

svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired 

solución @tangens también funciona para mí, pero no es perfecto, ya que me estoy poniendo un carácter de espacio adicional como la sustitución de los caracteres de retorno de carro. Sin embargo, probé que svn: ignore todavía funciona con ese espacio extra, pero no probé las otras propiedades de SVN.

La desventaja de usar el svndumptool es que solo puede funcionar en una propiedad svn a la vez, lo que consume mucho tiempo si sus archivos de volcado son grandes.

---

Algunos hallazgos

Usted puede ser curioso acerca de por qué @tangens no sustituir el^M con carácter vacío. Si intenta reemplazarlo con carácter vacío, que va a obtener este error:

archivos

svnadmin: E140001: Dumpstream data appears to be malformed 

El volcado de tiendas Prop-content-length de propiedad que se compara con el contenido del contenido real de la propiedad. Sustituir^M por un carácter vacío reducirá la longitud del contenido de la propiedad, de ahí el error.

svndumptool cambiará Prop-content-length y Content-length respectivamente.

Answer 6

Con un poco de gimnasia puede solucionar esto usando svnsync, que tiene la capacidad de reparar los EOL. Digamos que su repositorio está abandonado en archive.svn.

En primer lugar crear el repositorio para cargar el repositorio de vuelta, haciendo caso omiso de los problemas EOL:

svnadmin create repo 
svnadmin load repo < archive.svn --bypass-prop-validation 

Ahora crea un nuevo repositorio para copiarlo en:

svnadmin create repo-fixed 

svnsync requiere un poco de gancho pre-commit, incluso si no lo usa, solo use su editor para crear uno vacío en repo-fixed/hooks/pre-revprop-change:

#!/bin/sh 
exit 0 

inicializar el repositorio de destino para svnsync:

svnsync init file:///path/to/repo-fixed file:///path/to/repo 

Ahora copia todo el repositorio sobre: ​​

svnsync sync file:///path/to/repo-fixed 

Uf! svnsync incluso le dará una buena noticia: (. ¿Por qué el equipo de Subversion no se actualizaba svnadmin a hacer lo mismo normalización es un misterio para mí) NOTE: Normalized svn:* properties to LF line endings

Una vez hecho esto, volcar el nuevo repositorio:

svnadmin dump repo-fixed > archive-fixed.svn 

Ahora tiene archive-fixed.svn, que debe ser idéntico a archive.svn, excepto que los EOL se han corregido según sea necesario.

(Opcional) Ahora puede retirar el depósito temporal que utilizó para svnsync:

rm -rf repo-fixed 

actualización Resulta que si se carga este nuevo vertedero, su cliente de Subversion obtiene un error: Repository UUID does not match expected UUID . Tendrá que usar svnadmin setuuid ... a change the UUID ID to what it used to be.

(Este mensaje es la culminación de una multitud de fragmentos y soluciones parciales que encontré en la web Gracias a todas las personas que sabían más que yo;. Acabo de poner todo junto.)

Véase también :

• Copying subversion repositories with history using svnsync
• https://stackoverflow.com/a/28472420/421049
• https://svn.apache.org/repos/asf/subversion/trunk/notes/svnsync.txt

Answer 7

Acabo de reparar un archivo svn dump con éxito. También tenía un CRLF en las propiedades, lo que provocó una excepción en la importación de volcado SVN Edge (tienen una rutina de importación realmente mala). Entonces "instalado" svnserve para la prueba, que era mucho más fácil de lo esperado (instrucciones para el sistema operativo Windows):

1. descargar e instalar TortoiseSVN u otro software que incluye SVN herramientas de línea de comandos. Ya lo tenía instalado
2. start cmd.exe, ejecuta svnserve -d.Esta ventana de cmd está ocupada ahora.
3. empezar otra cmd.exe crear un acuerdo de recompra: svnadmin create d:\svn_repos\test12
4. de carga del vertedero en el repositorio: svnadmin load d:\svn_repos\test12 < d:\temp\svn\backup_test.dump

svnserve le dará información detallada lo que falló.

Y esto es lo que tiene que reparar (original a la izquierda, reparado en el lado derecho):