SVN a Git usando una secuencia rápida de import / export

He estado trabajando en la conversión de un repository SVN de ~ 32,000 confirmaciones para cualquier DVCS (Git, Bazaar, Mercurial, Plastic SCM). Después de una semana o dos, me di count de que la mejor opción es convertir el repository SVN a Git, get un flujo rápido de export e importar la transmisión .fe a cualquier DVCS, ya que todos admiten el método de import / export rápida de git.

He intentado todo en Internet: tanto en Windows 7 como en Ubuntu Linux. Debido al tamaño del repository, he tenido más éxito usando reposurgeon y git-svn. Pero, de nuevo, debido al tamaño, ambas herramientas no logran encubrir el repository completo de una vez. También probé SubGit, y aunque funciona, es extremadamente lento (~ 24h para procesar 1060 commits).

Así que pensé que podría convertir cada carpeta dentro del repository (troncales, twigs, tags, carpetas personalizadas) por separado y combinarlas más adelante en Git. Entonces me di count de que esto no sería posible, ya que la estructura de repo de git es significativamente diferente a SVN.

Mi pregunta es, ¿es posible utilizar mi método anterior y con un poco de magia, combinar las conversiones por separado en un solo repository Git?

Básicamente, necesito get un flujo rápido de export / import para mi repository SVN para convertirlo a otro DVCS, y pensé que un paso intermedio de Git sería más fácil. ¿Qué otras opciones están disponibles para una conversión exitosa?

Gracias por adelantado.

Convertir las carpetas por separado y combinar los repositorys de git debería funcionar en principio, pero sería muy complicado acertar, así que desaconsejaría.

En cualquier caso, 32,000 commits no es mucho, y git-svn debería ser capaz de manejarlo, aunque podría tomar un día más o less. Sin embargo, si es demasiado lento, tendrás que experimentar un poco.

Cosas que pueden ralentizar la operación de clonación de git-svn

Velocidad del repository SVN

Primero, por supuesto, está la velocidad del repository SVN. Intenta crear un reflection local del repository SVN (usando svnadmin dump/load o svnsync ) y clona eso.

Subdirectory / twigs / tags

Las twigs o tags (que git trata de forma idéntica) pueden convertirse en un problema. Siempre que el git-svn clone encuentre una twig SVN que no sea una copy del tronco, sino de un subdirectory, volverá a leer toda la historia SVN del subdirectory ramificado desde su creación (puede ver esto en la salida de git svn clone , y aquí hay una explicación del autor ). Esto significa que la velocidad de un clon no solo es proporcional al número de revisiones SVN n , sino también al número de "subdirectory branches" b , es decir, si b = 10 , el clon puede tardar hasta 10 veces más.

No hay una solución fácil para este problema. En primer lugar, podría tratar de clonar sin tags: normalmente una label solo cambia a una ID de revisión SVN, por lo que tener una list de tags debería ser suficiente (a less que tenga tags que contengan cambios … ugh). Si eso no es suficiente, tal vez también salte algunas twigs … aunque tendrías que decidir si hay alguna que puedas prescindir.

La solución extrema sería usar la opción --no-follow-parent . Esto evitará que git svn vuelva a leer una twig desde el principio. Las twigs seguirán siendo leídas, sin embargo, no estarán conectadas al rest de la historia. Eso todavía muestra lo que se hizo allí, pero hace que sea muy difícil fusionar de nuevo.


Finalmente, tenga en count que puede interrumpir y reanudar el process de clonación. Para reanudar, ejecuta git svn fetch . Es posible que necesite varios reinicios, pero con un poco de paciencia el clon debería pasar.