Los argumentos vuelven a registrar los archivos binarios en SCM

Trabajo para una empresa que construye principalmente aplicaciones Java y estoy tratando de convencer a todos de que dejen de registrar archivos binarios (dependencias y productos finales) en SCM.

Saben que es una mala práctica, pero piensan que "funciona" y que en realidad no es un problema, incluso cuando muchas personas saben sobre Maven y otras herramientas para construir además de Ant. Tanto los PM como los programadores (alrededor de 50 personas) están listos para escuchar cualquier argumento en contra e incluso reconocer que es una pérdida de espacio de respaldo, pero quiero ser realmente convincente porque el cambio de hábito implicaría mucho esfuerzo. ¿Qué argumentos utilizas para apoyar un cambio?

Editar: De acuerdo, tiene sentido hacer una distinción entre archivos que casi no cambian, como las dependencias, y los archivos generados. Aun así, estoy interesado en razones en contra de este último.

El espacio de almacenamiento es barato, por lo que no es un argumento muy convincente de por qué debería o no registrar archivos.

En cambio, puede apelar al propósito de SCM. Cada archivo que SCM rastrea representa cierta necesidad de administrar los cambios paralelos y distribuidos que realiza su equipo. Nada de eso es realmente aparente hasta que dos miembros del equipo intentan cambiar el mismo archivo. Para resolver esos cambios es para lo que SCM es realmente, evitar la sobrescritura accidental del trabajo de otro desarrollador y, con suerte, automatizar el proceso de fusión de esos cambios.

La fusión de archivos binarios suele ser un verdadero desafío, porque no hay una forma sensata para que una herramienta de fusión genérica adivine cómo debería funcionar un archivo binario fusionado. No puede saber lo suficiente sobre cómo funcionan los índices o los punteros de desplazamiento en el archivo a menos que esté especialmente diseñado para reconocer ese tipo de archivo en particular.

Eso significa que depende del desarrollador fusionar el archivo binario a mano, y luego decirle a SCM que el archivo ha sido tan fusionado. Dado que es un desarrollador que lo hace, la fusión puede no cubrir todos los cambios de ambos registros anteriores, y dado que el archivo es binario, no hay una forma automática de verificar la fusión.

Para los formatos binarios que realmente representan fuentes de proyectos, como los activos artísticos, este es un paso desafortunado pero necesario. Sin embargo, las salidas de compilación no son fuentes. No es necesario fusionarlos, ya que las fuentes se pueden fusionar y se puede regenerar un resultado de compilación resultante. El seguimiento y la gestión de estos cambios es un 100% de desperdicio. Malgasta los recursos de SCM, aunque no mucho, pero también desperdicia el tiempo del desarrollador al superar las fallas de fusión espurias. El tiempo de desarrollo es muy costoso, y cualquier cosa que lo desperdicie es un cáncer.

Por otro lado, hay un caso particular en el que las salidas de compilación deben archivarse. Cualquier versión del proyecto que se haya enviado o implementado probablemente debería conservarse de forma indefinida. Tener una copia exacta, byte por byte de la compilación real con la que un cliente está teniendo problemas puede facilitar mucho más el soporte de ese cliente, ya que tendrá la versión exacta que tiene.

Esa copia de seguridad probablemente no debería estar en el mismo repositorio que el código fuente, ya que generalmente seguirán horarios diferentes y tendrán estructuras básicamente diferentes.

Las dependencias, incluso en forma binaria, deben verificarse de modo que cuando alguien más detenga el proyecto, simplemente funcione. La principal preocupación no es el tipo de archivo, sino cómo se crea el archivo. La regla general que uso es que si puede generarse usando otro archivo, no se registrará, esto significa documentación generada automáticamente, archivos binarios que creo, etc.

Una de las principales ventajas de usar SCM es que puede reconstruir su sistema desde cualquier momento en el pasado. Por lo tanto, no tiene sentido almacenar su compilación final en su SCM porque puede verificar el número de revisión y compilarlo.

Menciona las dependencias ... Su SCM debe configurarse para que pueda realizar un pago limpio en una nueva máquina (con entorno de desarrollo), presione construir y debería poder construir su sistema sin necesidad de instalar nada más. Por lo tanto, mantener dependencias binarias en su SCM es una buena idea. Las bibliotecas rara vez cambian, por lo que no ocuparán mucho espacio.

Casi nadie hace esto.

Parece redundante incluir archivos de origen y de objeto (obviamente, se requieren archivos de origen). Además de ser innecesarios, los archivos de objetos pueden ocupar mucho espacio. Si su empresa está utilizando un SCM distribuido (Git, Hg, Bzr), esos archivos binarios deben copiarse y almacenarse entre todos los desarrolladores.