¿Se puede usar Git-svn en repositorios grandes y ramificados?

Question

estoy tratando de usar Git como interfaz a un repositorio SVN con el fin de poder utilizar buenas características de Git como ramificación simple, stashing etc.

El problema es que el repositorio SVN es bastante grande (8.000 rpm) y contiene muchas ramas y etiquetas (antiguas y nuevas).

Es un diseño casi estándar, con una configuración que contiene directivas fetch, branches y tags.

Dado que la rama y la etiqueta más antiguas se refieren a la revisión 10, significa que cada svn fetch lee todo el historial del repositorio de la revisión 10 y reenvía, lo que puede demorar horas en la conexión lenta.

Si solo hago un seguimiento de la cajuela, está bien, pero aún quiero que git esté al tanto de las nuevas ramas y etiquetas.

Normalmente miro git log -1 en la rama en la que estoy y obtengo la revisión SVN del comentario, así que puedo hacer git svn fetch -r7915:HEAD o similar. Supongo que eso es lo que hace git svn fetch --parent. Pero, ¿por qué tengo que hacer esto?

Estoy en Windows, y uso TortoiseGit, que tiene bastante buen soporte para git-svn, pero como TortoiseGit solo ejecuta git svn fetch, estoy atascado.

¿Estoy haciendo algo mal? Espero que svn fetch sea una operación rápida cuando se completa el primer svn clone -s.

Answer 1

Lo está usando correctamente: la importación inicial de un repositorio de Subversion con mucho historial será muy lenta.

La mala noticia es que las ramas y etiquetas de Subversion son solo directorios, git-svn se ve obligado a tomar la ruta pesimista de leer cada rama desde su cabeza hasta la primera revisión. Sí, si ha sido disciplinado en el uso de Subversion, esto generará muchas búsquedas de los mismos datos, pero los patrones de uso en el mundo real lo hacen improbable.

¡Enciende el clon por la tarde y regresa a un buen repositorio de git la mañana siguiente!

Una vez que haya clonado, git svn fetch incluso le advierte:

This may take a while on large repositories

Subversion es simple y estúpida, por lo Git tiene que tomar las cosas con calma.

Answer 2

Si no necesita tener un historial completo en el repositorio de git, le recomiendo que eche un vistazo al enfoque "git + svn", detallado en el siguiente enlace, en lugar de la integración estándar de git-svn. Su importación inicial en git debe ser muy rápida, ya que no importará el historial.

Asegúrese de leer la sección titulada "Beneficios, inconvenientes y lecciones aprendidas".

http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx

Answer 3

Gracias por las respuestas. Sin embargo, realmente no me ayudaron.

Este comando es la mejor solución hasta el momento:

git svn log --all -1 | \ 
    sed -n '2s/r\\([0-9]*\\).*/\\1/p' | \ 
    xargs --replace=from git svn fetch -r from:HEAD

Se utiliza git svn log --all para encontrar el número más alto de SVN revisión fue a buscar hasta el momento y se captan todo, desde ese punto en adelante.

Ojalá git svn fetch tendría una opción para comportarse así. A menos que se modifiquen las revisiones de SVN, no hay ninguna razón para que git svn busque las mismas revisiones una y otra vez.

Answer 4

¿Tiene enlaces simbólicos en el repositorio SVN? Si no es así, ¿ha intentado este ajuste:

svn.brokenSymlinkWorkaround

Esto desactiva los controles potencialmente costosos para solucionar rotos enlaces simbólicos controladas en SVN por rotas clientes. Establezca esta opción en "falso" si rastrea un repositorio SVN con muchos blobs vacíos que no son enlaces simbólicos. Esta opción puede cambiarse mientras git svn se está ejecutando y entra en vigor en la próxima revisión . Si no está configurado, git svn asume que esta opción es "verdadera".