Convierta svn a git en la reestructuración del repository usando SubGit

Estoy trabajando en la migration de un repository de Subversion a Git usando SubGit 2.0.3 mientras trato de mantener el historial completo en una reestructuración. Tengo una configuration que parece mantener el historial a lo largo de la reestructuración de las sucursales, pero no del tronco.

La reestructuración en sí fue un poco … inusual … e involucró un layout intermedio.

Diseño inicial:

  • tronco: / ProjectOldName
  • branches: / ProjectOldName / Releases
  • tags: N / A

Diseño intermedio:

  • tronco: / trunk / ProjectNewName
  • branches: / releases / ProjectNewName
  • tags: N / A

Diseño final:

  • tronco: / ProjectNewName / trunk
  • branches: / ProjectNewName / branches / releases
  • tags: / ProjectNewName / tags

Entonces las asignaciones de subgit que utilicé para la conversión fueron:

trunk = ProjectNewName/trunk:refs/heads/master branches = trunk/ProjectNewName:refs/heads/old-master-interim branches = ProjectOldName:refs/heads/old-master branches = ProjectNewName/branches/releases/*:refs/heads/releases/* branches = releases/ProjectNewName/*:refs/heads/old-releases-interim/* branches = ProjectOldName/Releases/*:refs/heads/old-releases/* tags = ProjectNewName/tags/*:refs/tags/* shelves = ProjectNewName/shelves/*:refs/shelves/* 

Este historial mantenido para las sucursales de publicación, el logging de un file iría más allá de la reestructuración … aunque pareció detenerse en la creación de la sucursal (que ocurrió antes de la reestructuración). Sin embargo, el historial para el mismo file en el maestro se detuvo en la creación del paso final de la reestructuración y las twigs esperadas 'antiguo-maestro-intermedio' y 'antiguo maestro' no existían en el repository de git.

Parece que la reestructuración se realizó utilizando copys svn (es decir, no copyron los files manualmente y los volvieron a enviar) y el historial en el layout final se guardó correctamente. Sin embargo, el layout intermedio se creó dos veces, el primer bash se eliminó con un comentario que indicaba que no se había conservado el historial. Así que lo mejor que puedo decir es que la cadena de compromisos de reestructuración fue (para el tronco):

  • Comience con / ProjectOldName
  • Agregar directory / trunk / ProjectNewName
  • Agregue varios directorys (la mayoría, pero no todos) a / trunk / ProjectNewName / from / ProjectOldName /, con eliminaciones para esos directorys no agregados (cómo sucedió esto, no estoy seguro ya que los directorys no existían en esa twig)
  • Reemplace varios directorys (el mismo set que se agregó anteriormente) en / trunk / ProejctNewName / from / ProjectOldName / (con revisiones ligeramente diferentes, tal vez un bash de volver a hacer el complemento anterior?)
  • Eliminar directory / trunk / ProjectNewName (con un comentario sobre el historial no guardado)
  • Agregar directory / trunk / ProjectNewName (por segunda vez)
  • Agregue varios directorys a / trunk / ProjectNewName / from / ProjectOldName /, el mismo set de directorys nuevamente, pero esta vez las eliminaciones no estaban presentes
  • Agregar directory / ProjectNewName / trunk
  • Agregue varios directorys a / ProjectNewName / trunk / from / trunk / ProjectNewName /
  • Eliminar el directory / trunk / ProjectNewName

Es similar, pero ligeramente diferente para las twigs de lanzamiento:

  • Comience con / ProjectOldName / Releases
  • Agregar directory / lanzamientos
  • Agregue varios directorys (uno para cada twig) a / releases / from / ProjectOldName / Releases /
  • Eliminar directory / lanzamientos
  • Agregar directory / releases / ProjectNewName
  • Agregue varios directorys (uno para cada twig) a / releases / ProjectNewName / from / ProjectOldName / Releases /
  • Agregar directory / ProjectNewName / branches / releases
  • Agregue varios directorys (uno para cada twig) a / ProjectNewName / branches / releases / from / releases / ProjectNewName /
  • Eliminar el directory / releases / ProjectNewName

La única diferencia real parece ser el paso 'Reemplazar múltiples directorys' que sucedió para el enlace troncal pero no para las twigs.

Entonces después de todo eso:

  • ¿Hay alguna manera de hacer que SubGit convierta lo anterior mientras se mantiene el historial en la reestructuración de trunk?
  • ¿Puede SubGit manejar tener twigs debajo del tronco como en el layout del repository original (es decir, trunk at / OldProjectName, branches at / OldProjectName / Releases)?
  • ¿Hay algo especial sobre el mapeo 'troncal'? ¿O en realidad no es diferente al mapeo de 'twigs'? AFAIK para svn y git no hay nada especial sobre el directory 'trunk' y la twig 'master' respectivamente.
  • A pesar de que la historia en las twigs parece que cruza bien la reestructuración, se detienen en la creación de la twig en lugar de continuar desde donde se ramificó. ¿Qué podría causar esto y cómo puede solucionarse (si puede)?

¿Hay alguna manera de hacer que SubGit convierta lo anterior mientras se mantiene el historial en la reestructuración de trunk?

SubGit puede rastrear el historial de sucursales cuando todo el directory de sucursales se copy de una location a otra:

 $ svn cp ^/trunk ^/branches/foo 

Sin embargo, es imposible hacer un seguimiento del historial cuando se copyron algunos subdirectorys de sucursales:

 $ svn add ^/branches/foo $ svn cp ^/trunk/dir1 ^/branches/foo/dir1 $ svn cp ^/trunk/dir2 ^/branches/foo/dir2 ... $ svn cp ^/trunk/dirN ^/branches/foo/dirN 

Desafortunadamente, así es como se realizó la reestructuración para ProjectOldName , / trunk / ProjectNewName y / ProjectNewName / trunk directories. Como resultado, SubGit no puede conservar el historial para ellos.

Una solución posible en su caso es importar esos directorys en twigs separadas y luego injertar piezas importadas en un solo historial con git-replace .

Esta solución alternativa, sin embargo, lleva a la siguiente pregunta:

¿Puede SubGit manejar tener twigs debajo del tronco como en el layout del repository original (es decir, trunk at / OldProjectName, branches at / OldProjectName / Releases)?

No, SubGit ignora el directory OldProjectName en este caso.

Lo hicimos intencionalmente: si SubGit intentara importar el directory OldProjectName , cualquier revisión que agregue una twig a OldProjectName / Releases tomaría mucho time ya que SubGit lo trata como un nuevo directory.

Para injertar el historial de OldProjectName en otras twigs, recomiendo importar esa twig por separado:

 $ subgit configure --svn-url URL REPO $ git config -f REPO/subgit/config svn.trunk OldProjectName:refs/heads/master $ subgit import REPO 

Después de eso, puede recuperar los cambios importados al repository de Git importado con la configuration que ya mencionó y luego usar git replace para unir los historiales de ProjectOldName , / trunk / ProjectNewName y / ProjectNewName / trunk .

A pesar de que la historia en las twigs parece que cruza bien la reestructuración, se detienen en la creación de la twig en lugar de continuar desde donde se ramificó. ¿Qué podría causar esto y cómo puede solucionarse (si puede)?

Creo que esto es causado por el problema anterior: dado que se ignora el directory ProjectOldName , SubGit no puede conservar el historial de las twigs copydas de la siguiente manera:

 $ svn cp ^/ProjectOldName ^/ProjectOldName/Releases/BRANCH 

Desafortunadamente, eso significa que puede elegir importar ProjectOldName o ProjectOldName / Releases / * pero no ambos. De nuevo, usar git replace puede ayudar aquí al injertar la historia de las sucursales.

¿Hay algo especial sobre el mapeo 'troncal'? ¿O en realidad no es diferente al mapeo de 'twigs'? AFAIK para svn y git no hay nada especial sobre el directory 'trunk' y la twig 'master' respectivamente.

La diferencia entre las opciones de configuration de troncales y twigs es efectiva solo durante la import de Git a SVN. Al importar el historial de Git a SVN, SubGit se asegura de que la twig especificada como troncal se cree desde las primeras revisiones y nunca se elimine ni reemplace. Las twigs especificadas como sucursales tienden a tener una vida útil más corta en el historial de SVN importado.

No hay diferencia entre el tronco y las twigs si importa el historial de SVN a Git.

Advertencia :
Nunca debe usar el command git replace en caso de que vaya a mantener sincronizados los repositorys Git y SVN en lugar de realizar una import única.

Gracias por proporcionar todos los detalles necesarios en su pregunta. Con suerte, mi respuesta es bastante útil.