Migración de git-svn fatal: no es una actualización SHA1 válida refs/heads/master refs/remotes/trunk: el comando devolvió el error: 128

Intentando migrar un repositorio svn grande pero lineal a git. El repositorio svn no tiene el diseño estándar (troncal, sucursales, etiquetas)... solo un directorio con el troncal.

Ubuntu 12.4 LTS, Git 1.7.9.5.

$ git svn clone https://coawstmodel.sourcerepo.com/coawstmodel/COAWST --authors-file=../users.txt COAWST

...

    D   WPS/metgrid/storage_module.F
    D   WPS/metgrid/process_domain_module.F
W: -empty_dir: WPS/metgrid/gridinfo_module.F
W: -empty_dir: WPS/metgrid/input_module.F
W: -empty_dir: WPS/metgrid/interp_option_module.F
W: -empty_dir: WPS/metgrid/module_date_pack.F
W: -empty_dir: WPS/metgrid/process_domain_module.F
W: -empty_dir: WPS/metgrid/storage_module.F
r635 = c19181c9718e701788b540ed0cc559e4fbddf413 (refs/remotes/git-svn)
    M   Tools/Docs/COAWST_User_Manual.doc
r636 = 1b7849c3e5a20856c9ddb909a5f53ddf8501ad33 (refs/remotes/git-svn)
Auto packing the repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
Counting objects: 14143, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14039/14039), done.
Writing objects: 100% (14143/14143), done.
Total 14143 (delta 8350), reused 0 (delta 0)
fatal: refs/remotes/trunk: not a valid SHA1
update-ref refs/heads/master refs/remotes/trunk: command returned error: 128

He probado variantes con combinaciones de -s, -t Trunk, -t COAWST, --preserve-empty-dirs (que me gustaría hacer), --no-meta-data (según Pro Git)... siempre el mismo error final.

Gracias por cualquier sugerencia!

preguntado el 27 de julio de 12 a las 19:07

Un directorio con el tronco sigue siendo el diseño estándar. ¿Tiene acceso al servidor con repositorio SVN? -

Sí. Para aclarar, no hay nada en el repositorio svn llamado "tronco" -

Pero, ¿hay algún directorio que desempeñe el papel de troncal (tal vez llamado "Trunk" o "Proyecto" o COASWST o lo que sea; quiero decir: le gustaría que Git confirme para contener solo el contenido de ese directorio o para contener ese directorio también) o todos los datos se concentran en la raíz del repositorio SVN? Y otra pregunta: ¿es cierto que su repositorio SVN contiene 636 revisiones (es la última revisión que puedo ver en la salida)? -

El directorio COAWST desempeña el papel de troncal. -

Sí... hay 636 revisiones, y algunas son bastante grandes. Esto toma alrededor de una hora para llegar al error. -

5 Respuestas

Creo que ejecutas el comando correcto. Alternativamente, podría ejecutar

$ git svn clone https://coawstmodel.sourcerepo.com/coawstmodel --trunk=COAWST --authors-file=../users.txt COAWST

git-svn casi termina su trabajo en cada caso. Lo único que intenta hacer es configurar 'maestro' para que apunte a su baúl. Debido a algún error, intenta establecerlo en el valor incorrecto, pero puede hacerlo manualmente con

$ git update-ref refs/heads/master refs/remotes/git-svn

Si aún tiene problemas, puede intentar convertir el repositorio con SubGit en 3 pasos:

$ subgit configure path/to/svn/repository
#edit path/to/svn/repository/conf/subgit.conf to set trunk = COAWST:refs/heads/master and authorsFile = path/to/users.txt
$ subgit install path/to/svn/repository

El repositorio convertido estará en ruta/a/svn/repository/conf/.git

Respondido 27 Jul 12, 20:07

Tuve el mismo problema, y ​​hacer una importación única de SubGit hizo el trabajo por mí: subgit.com/book-remote/index.html#import - jon onstott

Tuve el mismo error, ejecuté el comando con éxito. Pero realmente no sé una forma clara de cómo verificar si funcionó. - lvthillo

Cada vez que esto me sucedió, Git simplemente no pudo obtener una confirmación de trunk en Subversión:

fatal: refs/remotes/trunk: not a valid SHA1

Razones:

  • No especificó el diseño de Subversion cuando no era estándar (tronco-etiquetas-sucursales). Específicamente por el error - no tienes /trunk.
  • No obtuviste de la revisión lo suficientemente antigua como para abarcar al menos una confirmación en el tronco (por ejemplo, usando -r opción).
  • Combinación de los anteriores.

contestado el 07 de mayo de 14 a las 19:05

+1: Intenté buscar con el -r opción y ocurrió el error. Cuando busqué todas las revisiones, el problema desapareció. - pesche

Gracias. Probé con un poco más viejo -r revisión (en lugar de la última) y funcionó - kajmagnus

Entonces, ¿cuál es la solución si su repositorio svn no tiene una carpeta troncal? - d512

Tuve el mismo problema hoy.

El problema es probablemente que el repositorio SVN no tiene un directorio troncal. Los directorios estándar de troncales, etiquetas y sucursales parecen ser opcionales en SVN. Pero git-svn necesita saber esto al migrar.

También es posible que algunos de los directorios estén ahí pero con nombres diferentes. (por ejemplo, el tronco podría llamarse "proyecto" en lugar de "troncal", las ramas podrían llamarse "sucursales" como de costumbre y podrían faltar etiquetas. O "troncal" podría llamarse "Trunk").

  • Si no hay ninguno de estos directorios estándar en el repositorio SVN, y todo se coloca en la raíz del repositorio, la solución es simplemente no intentar clonar los directorios svn estándar. Solo clona la raíz.

  • Si existen (o algunos de ellos existen), pero con nombres diferentes, se debe informar a git-svn sobre estos nombres.

solía Tortuga Git para migrar de SVN a GIT. En TortoiseGit, se realiza clonando desde el repositorio svn (¡sí!) y marcando la casilla de verificación "Desde el repositorio SVN".

  • Si no hay directorios de troncales, etiquetas o sucursales en el repositorio de SVN, simplemente desmarque las casillas de verificación "troncal", "etiquetas" y "sucursales" en la sección "Desde el repositorio de SVN" del cuadro de diálogo de clonación.

  • Si los directorios estándar están allí, pero tienen un nombre diferente al normal, manténgalos marcados pero escriba los nombres usados ​​en el cuadro de texto junto a ellos.

    (Desde la línea de comandos, esto se puede hacer con los modificadores -T, -t y -b. Consulte http://www.sailmaker.co.uk/blog/2013/05/05/migrating-from-svn-to-git-preserving-branches-and-tags-3/ en "diseño SVN no estándar").

(Esos fueron los dos casos que encontré; pueden existir casos más complejos. Tenía varios repositorios SVN sin directorios troncales, etiquetas o sucursales y al desmarcar estas 3 casillas de verificación funcionó. También tuve un caso en el que el directorio troncal se llamaba "proyecto " en lugar de "troncal", pero el directorio de sucursales se nombró normalmente y no había directorio de etiquetas. Al desmarcar la casilla de verificación de etiquetas e ingresar el nombre del directorio troncal, ese caso funcionó).

Respondido 22 Jul 17, 21:07

Creo que tengo dos conjuntos de archivos binarios de git instalados en mi máquina con Windows:

una. Git (cualquiera que sea la instalación típica de Windows, olvidé dónde la obtuve). Este instala la opción "Git Bash Here" en el menú contextual del explorador de archivos del botón derecho.

b. Tortuga Git.

Recibí el error al clonar un repositorio svn no estándar usando "Git Bash" (es decir, Git).

Luego intenté usar TortoiseGit (como lo sugiere un cartel aquí), y funcionó sin errores.

Sin embargo, TortoiseGit muestra la línea de comando real que está usando, y sospeché porque esa línea de comando es la misma que usé sin éxito con Git.

Luego probé "Git Bash" nuevamente y proporcioné la ruta completa a lo que creo que es el binario TortoiseGit git, es decir:

"C:/Program Files/Git/bin/git.exe" svn clone svn://localhost/dtapublic tempgitrepo

y eso funcionó bien.

Sin embargo,

git svn clone svn://localhost/dtapublic tempgitrepo

causa el error.

Creo que posiblemente haya dos binarios de git en juego, y es por eso que TortoiseGit solucionó el problema para un póster. El binario git enviado con "Git" no funciona para repositorios svn no estándar, y el binario git enviado con "TortoiseGit" sí funciona.

respondido 15 nov., 18:03

También tenía el problema. Descubrí que el comando git distingue entre mayúsculas y minúsculas y que estaba especificando --trunk=trunk/MyLib en lugar de --trunk=trunk.Mylib

Logré resolverlo de esa manera.

Espero que esto ayude a alguien...

Respondido 18 Jul 18, 15:07

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.