Mover un repositorio SVN de varios GB a Git

13

Actualmente, mi empresa tiene una solución de Visual Studio en un repositorio SVN que se organiza de la siguiente manera:

SolutionFolder (~3.5 GB)
|-> SolutionName.sln
|-> .. Some source code folders... (~250 MB)
|-> ThirdParty (~3 GB)
|-> Tools
    | -> Tool1
    | -> Tool2

Tool1 y Tool2 se compilan de forma independiente (tienen sus propias soluciones), pero producen ejecutables que se utilizan en la compilación principal. La carpeta ThirdParty contiene todas las dependencias para el proyecto, incluidos algunos archivos .lib precompilados de más de 100 MB y grandes bibliotecas como boost.

Es conveniente tenerlo todo en un repositorio SVN para que (1) el desarrollador tenga que hacer solo un check-out, y (2) no necesitemos hacer un seguimiento de las versiones de dependencias que necesitamos para cada versión de la compilación. Por otro lado, lleva un tiempo revisar este repositorio.

¿Cuál sería la mejor manera de mover esta estructura de proyecto a git? Presumiblemente, es mejor excluir ThirdParty y posiblemente Tools del repositorio principal, pero nos gustaría mantener ThirdParty fácilmente descargable en un solo paso, y nos gusta que esté versionado (y los desajustes de versión entre el repositorio principal y ThirdParty / Tools serían malos).

En este momento no estoy interesado en preservar la historia, solo en descubrir cómo organizar dicho proyecto.

ikh
fuente
¿Están esos tamaños por encima de los tamaños dentro de los repositorios, incluido el historial, o esos son los tamaños de la copia de trabajo local?
Doc Brown
1
@DocBrown solo la copia de trabajo local, no incluye el historial.
ikh

Respuestas:

10

Use la herramienta adecuada para el trabajo. En Windows, eso significa

Use NuGet para dependencias de terceros

De esa manera, mantiene las dependencias de terceros de forma versionada, pero no hinchará su repositorio con cosas innecesarias. Los pagos son mucho más rápidos y el proyecto está organizado como debería ser. Puede habilitar una opción en Visual Studio para que siempre descargue todas las dependencias automáticamente.

Por supuesto, puede usar una solución que solo use git (otro repositorio, submódulos, etc.), pero eso es solo piratería. Hacerlo de la manera correcta dará sus frutos rápidamente y te dejará con un sistema a prueba de futuro.

Editar después de los comentarios: la mejor manera de usar NuGet es configurar una fuente NuGet local, ya sea en una unidad compartida o en un servidor nuget completo. La configuración no debería tomar más de unos minutos en ambos sentidos. De esa manera, puede garantizar que todos los paquetes que necesita estén siempre disponibles, sin importar dónde se originaron.

Wilbert
fuente
¿NuGet admite compilaciones de línea de comandos? Siempre estoy buscando una compilación portátil que pueda hacer que Jenkins construya y pruebe por mí. ¿NuGet admite servidores CI como Jenkins?
Desbloquear
Un pensamiento más, ¿cuánto tiempo necesita para respaldar su producto? Si necesita brindar soporte durante mucho tiempo, no contaría con que la versión correcta de sus bibliotecas de terceros esté disponible en NuGet. Es posible que tenga problemas muy grandes al confiar en herramientas como NuGet para obtener la combinación correcta de herramientas de terceros, incluso en 2-3 años a partir de ahora.
Desbloquear
3
@uncletall: sí, NuGet tiene una interfaz de línea de comando completa. Y la idea es configurar un repositorio NuGet local, que puede ser una carpeta en un recurso compartido de red (llamado "feed", docs.nuget.org/docs/creating-packages/… )
Doc Brown
Sí, supuse, por supuesto, que usa un espejo local. Actualizaré la respuesta.
Wilbert
2
@ikh es bastante simple y directo crear paquetes nuget para dependencias externas. Necesitaba aproximadamente medio día para empaquetar 9 dependencias con 50 dlls, nunca antes lo había hecho.
Wilbert
5

Puede usar submódulos para las herramientas. De esa manera, puede mantenerlos en un subdirectorio como lo hace ahora, y usar un repositorio separado para versionarlos. Eso también significa que podría clonar (pagar) las herramientas y desarrollarlas por separado, y que otros proyectos podrían confiar en esos repositorios, y también en versiones específicas y desagradables de ellos.

También puede usar submódulos para las bibliotecas de terceros, pero si es posible, recomendaría usar un administrador de dependencias para ellos.

Idan Arye
fuente
4

Las entidades que convierte en repositorios de git son necesariamente las entidades que versiona y ramifica; si SolutionFolder/Tools/Tool1corresponde a una de esas cosas, ese es el nivel de entidad. Esto se debe a que git considera que todo el estado del árbol de directorios es la entidad versionable, mientras que con svn es posible (aunque no sea una buena idea) tener un trunk, branchesy en tagscualquier lugar dentro del árbol.

Los artefactos derivados no deben mantenerse en el repositorio, ni tampoco las bibliotecas externas. Hay mejores formas de manejarlos. (Si está trabajando con Java, considere usar un repositorio privado de Maven; son relativamente fáciles de trabajar y se integran muy bien con muchas otras cosas).

Si está acostumbrado a un flujo de trabajo que tiene todo en un repositorio para facilitar el pago, considere tener un script que configure las cosas en su lugar.

Compañeros de Donal
fuente
¿Cuáles son las opciones para administrar bibliotecas externas? Trabajamos en Visual Studio con C ++ y C #, por lo que Maven no parece una buena opción. El problema principal aquí es que tener la ThirdPartycarpeta en el repositorio es muy conveniente, y es difícil encontrar una buena alternativa.
ikh
2
@ikh: en un entorno de Visual Studio, normalmente usaría Nuget para esto, docs.nuget.org , que ya está incluido en VS 2012 y versiones más recientes.
Doc Brown
2

Para ser sincero, no cambiaría nada en su configuración. Es exactamente lo que estamos haciendo ahora. Estaba jugando con la configuración de un repositorio git separado para manejar la biblioteca de terceros que usamos, pero no creo que pese el costo de la portabilidad. Ahora cualquier desarrollador puede simplemente pagar y comenzar sin tener que hacer ningún paso de configuración manual. Y cualquier servidor / esclavo de compilación puede construir el proyecto. A menos que tenga múltiples repos compartiendo las herramientas de terceros, me quedaría con su configuración actual.

Lo que sí jugué fue configurar las herramientas de terceros en un repositorio separado. Luego hice que un simple script por lotes leyera un archivo de texto con una referencia sha1 y revisara la versión correcta. Esto me permitiría tener diferentes versiones de terceros para diferentes proyectos. Tengo esta idea de la herramienta de construcción Facebook Buck. Pero al final, a muchos desarrolladores no les gusta usar herramientas de línea de comandos (MS VC comprar aquí), así que renuncié a la idea.

Una de las principales razones por las que no debe descargar sus librerías de terceros cuando las necesite (usando NuGet) es si necesita mantener su producto durante mucho tiempo. En mi industria, en algún momento debemos proporcionar actualizaciones para versiones antiguas que se basan en antiguas bibliotecas de terceros. No queremos pasar mucho tiempo clasificando qué bibliotecas podemos actualizar o no y simplemente usar las bibliotecas como se usa en esa versión. Ahora imagine que usa NuGet, vaya ... la última versión de la biblioteca que necesita es 3.98 pero necesita 2.04 ..... cómo explicarle a su jefe que necesita pasar 2 meses para actualizar la versión anterior para poder usar las últimas librerías cuando esperaba un pequeño cambio!

descifrar
fuente
3
Aunque le di un +1, ya que "dejar todo como está" es una solución pragmática, creo que "repositorios múltiples" puede no ser el único problema. DVCS como Git alienta a tener múltiples sucursales locales, y en cada sucursal una copia local completa de todo. Por lo tanto, esto puede llevar a tener la misma gran biblioteca de terceros (¡típicamente la misma versión!) Varias veces como una copia local. Esto puede ser factible en algunas situaciones, en otras me imagino que tendrá un impacto negativo en el rendimiento de la ramificación y la fusión.
Doc Brown
Hasta donde sé, una rama es una operación muy barata en Git que solo creará un puntero y ocupará casi cero espacio.
Desbloquear el
A menos que me falte algo, las ramas son "gratuitas" en Git. Acabo de comprobar mi .git / refs / heads y todas las ramas son archivos de texto de 1KB, el .git / logs / refs / head contiene los registros donde el mayor es 11KB para el maestro. Mi estructura de proyecto normal es de alrededor de 500MB en código, librerías de terceros y otras herramientas. Estoy muy contento de tomar el éxito de 1
KB
1
@MichaelT: la ramificación en sí es gratuita, por supuesto, pero estoy hablando de la situación en la que tiene varias copias de trabajo de diferentes ramas en su estación de trabajo local en paralelo. Y si revisa los comentarios debajo de la pregunta original, el OP se refería a 3GB de herramientas de terceros como el tamaño de la copia de trabajo.
Doc Brown