Mover un repositorio SVN de varios GB a Git

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

Use NuGet para dependencias de terceros

De esa manera, mantienes las dependencias de terceros en una versión versionada, pero no inflarás tu repositorio con cosas innecesarias. Las salidas son mucho más rápidas, 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, puedes usar una solución que solo use git (otro repositorio, submódulos, etc.), pero eso es solo piratear. Si lo hace de la manera correcta, se amortizará rápidamente y le dejará un sistema a prueba de futuro.

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

Puede usar submodules para las herramientas. De esa manera, puede mantenerlos en un subdirectorio como lo hace ahora, y usar un repositorio separado para la versión de ellos. Eso también significa que podría clonar (retirar) las herramientas y desarrollarlas por separado, y que otros proyectos podrían basarse en esos repositorios, y también en versiones específicas y ubicables de ellos.

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

Las entidades que conviertes en repositorios de git son necesariamente las entidades que versionas y ramificas; Si SolutionFolder/Tools/Tool1 corresponde a una de esas cosas, ese es el nivel de la 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 (incluso si no es una buena idea) tener un trunk , branches y tags en cualquier lugar dentro del árbol .

Los artefactos derivados no se deben guardar en el repositorio, ni tampoco las bibliotecas externas. Hay mejores maneras de manejar eso. (Si está trabajando con Java, considere usar un repositorio privado de Maven; es relativamente fácil trabajar con ellos y se integra muy bien con muchas otras cosas).

Si estás acostumbrado a un flujo de trabajo que tiene todo en un repositorio para facilitar la extracción, considera tener un script que configure las cosas en su lugar.

Para ser honesto, no cambiaría nada en tu configuración. Es exactamente lo que estamos haciendo ahora. Estaba jugando con la configuración de un repositorio de git separado para manejar la biblioteca de terceros que utilizamos, pero no creo que sea tan importante como el costo de la portabilidad. Ahora, cualquier desarrollador puede simplemente finalizar la compra y comenzar sin tener que realizar ningún paso de configuración manual. Y cualquier servidor / esclavo de compilación puede construir el proyecto. A menos que tenga varios repositorios compartiendo las herramientas de thridparty, me quedaría con su configuración actual.

Con lo que jugué un poco 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 verificara 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 de Facebook Buck. Pero al final, a muchos desarrolladores no les gusta usar las herramientas de la línea de comandos (MS VC compra aquí), así que me di por vencido con la idea.

Una de las principales razones por las que no puede descargar sus bibliotecas de terceros cuando las necesita (usando NuGet) es que si necesita respaldar su producto durante mucho tiempo. En mi sector, en algún momento debemos proporcionar actualizaciones para versiones antiguas que se basan en las antiguas librerías de terceros. No queremos perder mucho tiempo clasificando qué libs podemos actualizar o no y simplemente usar las libs que se usan en esa versión. Ahora imagine que usa NuGet, oops ... 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 ¡para usar las últimas librerías cuando esperaba un pequeño cambio!