Subcarpeta SVN a GIT Migración con carpetas movidas

El caso

Tenemos un enorme repository SVN, con 80 subcarpetas, estamos tratando de dividirnos en varios repositorys GIT y mover BitBucked.

He utilizado lo siguiente para migrar la subcarpeta en SVN a GIT: git svn clone "https://localhost:40/svn/repo" --trunk="/Customers/[folder]" --prefix="" --authors-file="authors.txt" "[folder]"

Funciona bien

El problema

La "/ Clientes / [carpeta]" contiene la subcarpeta de carpetas previamente movidas desde otra subcarpeta "/ Aplicaciones / [carpeta]" en el repository SVN.

Estructura antigua:

 repo --Apps ----Customer1App1 ----Customer1App2 ----Customer2App1 --Customers ----Customer1 ----Customer2 

Nueva estructura:

 repo --Customers ----Customer1 ------Customer1App1 ------Customer1App2 ----Customer2 ------Customer2App1 

El problema es que las carpetas de aplicaciones migradas en el nuevo repository de GIT no contienen ningún historial antes de este movimiento, como lo hace el SVN. ¿Hay alguna forma de arreglar esto?

Información extra

He visto esto Obteniendo el historial completo de un repository SVN que ha sido renombrado usando git-svn, pero no puedo encontrar la manera de convertirlo para trabajar con una subcarpeta desde fuera de los nuevos repositorys.

Para una migration de una sola vez, git-svn no es la herramienta adecuada para conversiones de repositorys o partes de repositorys. Es una gran herramienta si quieres usar Git como frontend para un server SVN existente, pero para las conversiones svn2git no debes usar git-svn , pero svn2git es mucho más adecuado para este caso de uso.

Hay muchas herramientas llamadas svn2git , la mejor probablemente sea la de KDE de https://github.com/svn-all-fast-export/svn2git . Recomiendo usar esa herramienta svn2git . Es lo mejor que sé disponible por ahí y es muy flexible en lo que puedes hacer con sus files de reglas.

Podrá configurar svn2git el file de reglas de svn2git para producir el resultado que desee a partir de su layout de SVN actual, incluido cualquier historial complejo.

Si no está al 100% sobre el historial de su repository, svneverever de http://blog.hartwork.org/?p=763 es una gran herramienta para investigar el historial de un repository SVN al migrarlo a Git.


Aunque es más fácil comenzar con git-svn , aquí hay algunas razones más por las que el uso de KDE svn2git lugar de git-svn es superior, además de su flexibilidad:

  • la historia es reconstruida mucho mejor y más limpia por svn2git (si se usa la correcta), este es especialmente el caso para historias más complejas con twigs y fusiones, etc.
  • las tags son tags reales y no sucursales en Git
  • con git-svn las tags contienen un compromiso vacío adicional que también hace que no --tags parte de las twigs, por lo que una fetch normal no las obtendrá hasta que proporciones --tags al command, ya que de manera pnetworkingeterminada solo se --tags las tags que apuntan a las twigs obtenidas . Con las tags adecuadas svn2git es donde pertenecen
  • si cambiaste el layout en SVN puedes configurarlo fácilmente con svn2git , con git-svn svn2git historia eventualmente
  • con svn2git también puede dividir un repository SVN en múltiples repositorys Git fácilmente
  • o combine múltiples repositorys SVN en la misma raíz SVN en un repository Git fácilmente
  • la conversión es un billón de veces más rápida con el svn2git correcto que con git-svn

Verá, hay muchas razones por las cuales git-svn es peor y el KDE svn2git es superior. 🙂

Terminé escribiendo mi propia aplicación de conversión en C # usando SharpSVN y SharpGit.

En esencia lo hace:

  • Encuentra todos los movimientos y cambia el nombre
  • Encuentra toda la revisión que implicó alguna de las acciones anteriores
  • Y luego para cada revisión:
    • Checkout principal dir
    • Copie los cambios en el directory principal
    • Agregar todos los files al repository de Git
    • Repositorio de Commit Git
    • Revertir copy para poder crear una nueva (aún necesito optimizar esta parte, para hacerlo más rápido)
    • Ir a nueva revisión