Editar: a diferencia de algunas preguntas similares, como Mover un repositorio SVN de varios GB a Git o /programming/540535/managing-large-binary-files-with-git Mi escenario no involucra varios subproyectos que se puede convertir fácilmente en submuelles de git, ni en algunos archivos binarios muy grandes que sean adecuados para git-annex. Es un repositorio único donde los archivos binarios son el conjunto de pruebas que se acoplan estrechamente al código fuente principal de la misma revisión, al igual que si fueran activos de tiempo de compilación como gráficos.
Estoy investigando el cambio de un antiguo repositorio de código de tamaño medio / grande (50 usuarios, 60k revisiones, 80Gb de historial, 2Gb de copia de trabajo) de svn. A medida que el número de usuarios ha crecido, hay una gran rotación en el tronco, y las características a menudo se extienden en múltiples confirmaciones, lo que dificulta la revisión del código. Además, sin ramificación no hay forma de "bloquear" el código incorrecto, las revisiones solo se pueden hacer después de que se haya comprometido con el enlace troncal. Estoy investigando alternativas. Esperaba que pudiéramos pasar a git, pero tengo algunos problemas.
El problema con el repositorio actual en cuanto a git es el tamaño. Hay una gran cantidad de residuos viejos allí, y limpiarlos con una rama de filtro cuando se convierte en git puede reducir su tamaño en un orden de magnitud, alrededor de 5-10 GB. Esto todavía es demasiado grande. La razón principal del gran tamaño del repositorio es que hay muchos documentos binarios que son entradas para las pruebas. Estos archivos varían entre .5mb y 30mb, y hay cientos. También tienen bastantes cambios. He visto submódulos, git-annex, etc., pero tener las pruebas en un submódulo se siente mal, al igual que tener un anexo para muchos archivos para los que desea un historial completo.
Entonces, la naturaleza distribuida de git es realmente lo que me impide adoptarlo. Realmente no me importa la distribución, solo quiero la ramificación barata y las potentes funciones de fusión. Como supongo que el 99.9% de los usuarios de git lo hacen, utilizaremos un repositorio central bendecido y desnudo.
No estoy seguro de entender por qué cada usuario debe tener un historial local completo al usar git. Si el flujo de trabajo no está descentralizado, ¿qué están haciendo esos datos en los discos de los usuarios? Sé que en versiones recientes de git puedes usar un clon superficial con solo historial reciente. Mi pregunta es: ¿es viable hacer esto como el modo de operación estándar para todo un equipo? ¿Se puede configurar git para que sea siempre superficial para que pueda tener un historial completo solo centralmente, pero los usuarios por defecto solo tienen 1000 revoluciones de historial? La opción para eso, por supuesto, sería convertir 1000 revoluciones a git y mantener el repositorio svn para arqueología. En ese escenario, sin embargo, nos encontraríamos con el mismo problema nuevamente después de los próximos miles de revisiones a los documentos de prueba.
- ¿Qué es un buen mejores prácticas para el uso de git con grandes repositorios que contienen muchos archivos binarios que no quieren que la historia de? La mayoría de las mejores prácticas y tutoriales parecen evitar este caso. Resuelven el problema de unos pocos binarios enormes, o proponen descartarlos por completo.
- ¿Se puede usar la clonación superficial como un modo normal de operación o es un "hack"?
- ¿Podrían usarse los submódulos para el código donde tiene una dependencia estrecha entre la revisión de la fuente principal y la revisión del submódulo (como en dependencias binarias en tiempo de compilación o un conjunto de pruebas unitarias)?
- ¿Qué tan grande es "demasiado grande" para un repositorio git (local)? ¿Deberíamos evitar el cambio si podemos reducirlo a 4GB? 2GB?