Migración de svn2git: análisis de la estructura del tree de código

Estoy tratando de convertir un repository SVN a git . El repository consta de una pelea de 17000 commits, por lo que estoy usando svn2git de KDE (también conocido como svn-all-fast-export ).

Mi problema es que el repository se ha reestructurado varias veces (primero se ha convertido desde CVS, se han cambiado los nombres de vendor sucursales de vendor , …)

Pasó un time hasta que el proyecto cambió a un layout /trunk , /branches & /tag , pero luego el proyecto tiene una gran cantidad de submodules y están organizados, por ejemplo

 /trunk/plugins/foo /trunk/plugins/bar /branches/plugins/foo/1.0 /branches/plugins/foo/1.1 /branches/plugins/bar/1.0 /tags/plugins/pizzapack/3.14/foo /tags/plugins/pizzapack/3.14/foo 

De coro todos esos submodules contienen también treees subdirectorys.

La estructura de directorys en / tags y / branches podría haber cambiado con el time, y ciertamente no es muy consistente.

Ahora la buena noticia es que svn2git me permite manejar todo esto.

La mala noticia es que necesito una visión general sobre la evolución de la estructura del directory / ramificación, antes de que pueda comenzar a dar instrucciones sobre svn2git .

Así que estoy buscando una forma de analizar los cambios estructurales del layout del sistema de files a lo largo del time: adición, eliminación, copy y movimiento de directorys .

Actualmente estoy pensando en crear una pequeña herramienta de ayuda que me permita hacerlo, pero ya estoy bloqueado en el seguimiento adecuado de los cambios solo en el directory . No hablar sobre una representación adecuada de los cambios, eso me permitiría entender fácilmente lo que sucedió.

¿Qué se te ocurrió, qué estás usando al abordar un proyecto de este tipo?

Puede probar SubGit de la versión 3.0.0 o posterior para detectar su estructura de repository.

 $ subgit configure --svn-url <projectURL> --layout auto --trunk trunk repo.git 

donde --trunk option especifica la ruta relativa desde al directory que desempeña un rol de trunk en la última revisión (sin barras diagonales --trunk path/to/trunk o posteriores, p. ej. --trunk path/to/trunk o --trunk trunk ; si está en la última revisión su repository tiene la estructura clásica de tronco / twigs / tags, debe ser simplemente --trunk trunk ). Este command escaneará su historial de repositorys, rastreará todos los movimientos, copys y renombrados del directory troncal especificado y generará el directory subgit/config con el file subgit/config reflejando su estructura de repository en las opciones trunk / branches / tags / shelves. Tenga en count que el command no detecta automáticamente las twigs que se agregaron incorrectamente con solo "svn add" pero no con "svn cp" / "svn mv".

Luego puede comenzar la traducción con SubGit:

 $ subgit install repo.git 

O puede intentar copyr y pegar las opciones de tronco / twigs / tags generadas en su file de configuration de git-svn / svn2git. No estoy seguro de que el segundo enfoque funcione para el 100% de los casos, pero para las estructuras de repository más o less simples esto funcionará, ya que las opciones generadas tienen el mismo formatting que las correspondientes opciones de git-svn.

Descargo de responsabilidad: soy uno de los desarrolladores de SubGit. SubGit es una herramienta comercial, pero es gratuita para una conversión única (import).

    Intereting Posts