Mover un repositorio SVN de varios GB a Git

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.

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.

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.

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.

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!