Acelerando la búsqueda inicial de git-svn

Tengo un gran repositorio, más de 100 000 revisiones con un factor de ramificación muy alto. La recuperación inicial del repositorio SVN completo usando git-svn se ha estado ejecutando durante aproximadamente 2 meses y solo está hasta la revisión 60,000. ¿Hay alguna manera de acelerar esto?

Ya estoy matando y reiniciando regularmente la búsqueda debido a que git-svn pierde memoria como un colador. La transferencia se realiza a través de la LAN local, por lo que la velocidad del enlace no debería ser un problema. El repositorio está en una máquina dedicada respaldada por arreglos de canales de fibra dedicados, por lo que el servidor debería tener mucho empuje. Lo único que se me ocurre es hacer la clonación desde una copia local del repositorio SVN.

¿Qué han hecho otras personas en circunstancias similares?

En el trabajo, uso git-svn contra un repositorio SVN de revisión ~170000. lo que hice fue usar git-svn init + git-svn fetch -r... para limitar mi recuperación inicial a un número razonable de revisiones. Debe tener cuidado de elegir una revisión que esté realmente en la rama que desea. Todo es completamente funcional incluso con el historial truncado. excepto git-blameque obviamente atribuye todas las líneas anteriores a su rev ​​inicial a la primera rev.

Puede acelerar aún más esto con ignorar rutas para eliminar los subárboles que no desea.

Puede agregar más revisiones más tarde, pero será doloroso. Tendrá que restablecer el mapa de revoluciones (lamentablemente, incluso escribí git-svn reset y no puedo decir de improviso si eliminará todos revisiones, por lo que puede ser a mano). Después git-svn fetch más revisiones y git-filter-branch para volver a vincular su antigua raíz con el nuevo árbol. Eso reescribirá cada confirmación, pero no afectará a los blobs de origen. Tienes que hacer una cirugía similar cuando las personas emprenden grandes reorganizaciones del repositorio svn.

Si realmente necesitas todos de las revisiones (por ejemplo, para una migración), entonces debería buscar algún tipo de svn-fast-export + git-fast-import. Puede haber uno que agregue etiquetas rev para que coincida con git-svn, en cuyo caso podría importar rápidamente y luego simplemente injertar en el control remoto svn. Incluso si las opciones svn-fast-export existentes no tienen esa función, ¡probablemente pueda agregarla antes de que se complete su clon original!

Aparentemente no hay una buena respuesta. Se está trabajando en git-fast-import pero aún no está listo para el horario de máxima audiencia. Todavía están tratando de descubrir cómo detectar y representar acciones ‘svn cp’. El único punto positivo es que alguien en la lista ideó una optimización para git-svn que parece haber tenido un gran impacto.

http://permalink.gmane.org/gmane.comp.version-control.git/168718

Si puede encontrar un servidor con suficiente RAM, realice toda la operación de clonación en un ramdisk. En los sistemas Linux, puede usar /dev/shm, que está respaldado por RAM.

> svnadmin hotcopy /path/to/svn/repo /dev/shm/svn-repo

> git svn clone file:///dev/shm/svn-repo /dev/shm/git-repo

Una vez hecho esto, puede apuntar el repositorio git de nuevo a su repositorio svn real, como se describe aquí: https://git.wiki.kernel.org/index.php/GitSvnSwitch

• Edite la URL de url de svn-remote en .git/config para apuntar al nuevo nombre de dominio
• Ejecute git svn fetch: ¡esto necesita obtener al menos una nueva revisión de svn!
• Cambie la URL de svn-remote a la URL original
• Ejecute git svn rebase -l para hacer una reorganización local (con los cambios que se produjeron con la última operación de recuperación)
• Cambie la URL de svn-remote a la nueva URL
• ¡Ejecute git svn rebase ahora debería funcionar de nuevo!

¡Esto solo funcionará si el paso de búsqueda de git svn realmente obtiene algo! (Me tomó un tiempo descubrir que… ¡Tuve que hacer una revisión ficticia de nuestro repositorio svn para que esto sucediera!)

Acabo de hacer esto y pude clonar un repositorio svn de revisión 4.7G 12000 para git en aproximadamente 3 horas.

En un repositorio con 20k confirmaciones tuve problemas similares. En mi caso, resultó que había algunas etiquetas extrañas en subversion que causaron problemas. Había etiquetas que copiaban / en lugar de /trunk. Eso hace que git svn fetch entre en un bucle infinito. Lo arreglé convirtiendo en trozos.

git svn fetch -r0:1000
git svn fetch -r0:2000
git svn fetch -r0:3000

Mire la salida y si no ve nuevos r… de vez en cuando, entonces algo anda mal. Usar git log --all para ver hasta dónde llegó la conversión. Digamos que llegaste a 1565. Luego continúa la búsqueda de esta manera.

git svn fetch -r1567:2000

Fue muy tedioso pero hizo el trabajo.

Tengo un repositorio con más de 8k reseñas y alrededor de 240 etiquetas. Traté de ejecutar y calculé que mi clon inicial de git svn en Windows habría tomado meses, simplemente haciendo

git svn clone --stdlayout --no-metadata --authors-file=users.txt https://link.to.repo

El clon tardaba 5 segundos en importar 1 revisión en promedio. Tenga en cuenta que cada vez que se encuentra una etiqueta, el clon se reinicia desde la versión 1, por lo que potencialmente hay 8k * 240 operaciones = 111 días

Resumen de todos los pasos que tomé para acelerar el proceso:

1. La implementación de linux y osx es mucho más rápida que cygwin en windows. Usé una máquina virtual Linux. Consulte https://stackoverflow.com/a/21599759/1448276

2. Copié todo el repositorio svn en mi máquina con svnrdump

svnrdump dump https://link.to.repo > repos.dump

3. Creé un repositorio svn local

   svnadmin create svnrepo

   svnadmin load svnrepo < repos.dump

como en https://stackoverflow.com/a/10407464/1448276

4. Creé y monté un disco basado en ram

   svnadmin hotcopy svnrepo/ /dev/shm/svnrepo

como arriba, https://stackoverflow.com/a/39030862/1448276

5. Y finalmente ejecutó el clon.

   git svn clone --stdlayout --no-metadata --prefix=origin/ --authors-file=users.txt file:///dev/shm/svnrepo

Aquí, el clon está procesando un promedio de 12,5 revisiones por segundo, por lo que espero que tarde menos de 2 días. Publicaré una actualización una vez que se complete la clonación.

creo que estas en el camino correcto

El acceso a archivos locales podría darle una aceleración de 1 a 2 pedidos.

No estoy seguro si ejecutar git svn contra un bdb o un backend svn basado en archivos sería más rápido.

He descargado un repositorio SVN de cerca de 100,000 revisiones usando git-svn antes. Tomó alrededor de 48 horas y fue no a través de una LAN local. Es cierto que dijiste que tu repositorio tiene un alto factor de ramificación, mientras que el repositorio que descargué no (aunque tenía varias docenas de sucursales)

Sugeriría trabajar para averiguar dónde se encuentra el cuello de botella. ¿Están git-svn y sus subprocesos usando 100% CPU? ¿Están constantemente encendidas las luces del disco en el cliente o en el servidor SVN? ¿Cuánto ancho de banda se está utilizando? Una vez que sepa cuál es el factor limitante, puede trabajar para descubrir cómo solucionarlo.