-git svn clon o svn2git inesperadamente detener

Question

que estoy tratando de migrar de git svn con el siguiente comando:

git svn clone --stdlayout https://my_sourcecontrol 

o con git2svn

svn2git --notags https://sourcecontrol -v 

Durante la migración, sólo se detiene con la siguiente declaración:

W: -empty_dir: directory 

Cuando hago una rama git -a

Veo que importó las etiquetas y una serie de ramas que se eliminaron hace algún tiempo. Además, no ha importado ninguna de las ramas existentes solo las que se eliminaron hace algún tiempo.

¿Alguien puede arrojar algo de luz sobre lo que está pasando?

Answer 1

Puede experimentar un poco con un clon más pequeño, solo haciendo una rama al principio para ver si eso funciona, por ejemplo.

He visto un problema similar: después de correr durante un par de minutos, git-svn fetch (que se ejecuta bajo el capó de git svn clone) halts with "signal 13".

No veo ningún mensaje de error en su salida, pero tal vez sea diferente en Windows o algo así. No obstante, ejecutar git svn fetch debería continuar donde lo dejó. Hice un pequeño bucle de shell-script para ejecutar traes hasta que se hace (se necesita cygwin/* nix para ejecutar este):

while ! git svn fetch; do echo "git-svn halted. Restarting...i"; done 

Answer 2

Esta versión de PowerShell del * guión nix anteriormente trabajó para mí:

$i = 1 
do 
{ 
    git svn fetch 
    if(!$?) 
    { 
     Write-Host "git-svn halted. Restarting... $i++" 
    } 
    else 
    { 
     Write-Host "git-svn completed successfully" 
    } 
} 
while(!$?) 
Write-Host "git-svn fetch required $i iteration(s)" 

Answer 3

Tuve un problema similar.

En los primeros días del repositorio SVN, estaba usando la estructura de archivos predeterminada de una carpeta trunk/ y tags/ en el nivel superior. En una fecha posterior, cambié a una estructura <project name>/trunk, <project name>/tags con múltiples proyectos.

El uso del conmutador --stdlayout solo dio como resultado la migración del código anterior (porque se ignoraron los archivos <project name>/*).

El uso de -t <project name>/tags y -T <project name>/trunk resolvió el problema.

Answer 4

Podría ser un caso de SIGPIPE.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526989

git Promueve a algo así como 1.8 o superior. Estaba obteniendo este error con 1.7 (ya que Debian tiene paquetes realmente antiguos) y tuve que instalar el último git de la fuente, que es 2.1.0.