Argomenti contro il check-in di file binari in SCM

Lo spazio di archiviazione è economico e quindi non è un argomento molto convincente per il motivo per cui dovresti o non dovresti controllare i file.

Invece, puoi fare appello allo scopo di SCM. Ogni file tracciato da SCM rappresenta la necessità di gestire le modifiche parallele e distribuite che sta facendo il tuo team. Nulla di ciò è veramente evidente fino a quando due membri del team non provano a cambiare lo stesso file. La risoluzione di tali modifiche è ciò che realmente fa SCM, evitando la sovrascrittura accidentale di un altro lavoro di sviluppo e, auspicabilmente, automatizzando il processo di fusione di tali modifiche.

L'unione di file binari di solito è una vera sfida, perché non esiste un modo corretto per uno strumento di unione generico per indovinare come dovrebbe funzionare un file binario unito. Non può sapere abbastanza su come funzionano gli indici o i puntatori di offset nel file, a meno che non siano appositamente progettati per riconoscere quel particolare tipo di file.

Ciò significa che spetta al dev di unire manualmente il file binario, e quindi dire al SCM che il file è stato così unito. Dal momento che è un dev che lo fa, l'unione potrebbe non coprire realmente tutte le modifiche di entrambi i check-in precedenti, e poiché il file è binario, non esiste un modo automatico per verificare l'unione.

Per i formati binari che rappresentano in realtà le risorse del progetto, come le risorse artistiche, questo è un passo sfortunato, ma necessario. Tuttavia, gli output di build non sono fonti. Non è necessario unirli, poiché è possibile unire i sorgenti e rigenerare un risultato di generazione risultante. Monitorare e gestire questi cambiamenti è uno spreco del 100%. Spreca le risorse SCM, anche se non molto, ma spreca anche il tempo degli sviluppatori a superare i fallimenti di fusione spuria. Il tempo degli sviluppatori è molto costoso e qualsiasi cosa lo sprechi è un cancro.

D'altra parte, c'è un caso particolare in cui gli output di build dovrebbero essere archiviati. Qualunque versione del progetto che sia mai stata spedita o implementata dovrebbe probabilmente essere conservata, a tempo indeterminato. Avere una copia esatta di byte per byte della build effettiva con cui un cliente ha problemi può rendere il supporto di quel cliente molto più facile, dal momento che si avrà la versione esatta che ha.

Probabilmente questo backup non dovrebbe essere nello stesso repository del codice sorgente, poiché generalmente seguiranno pianificazioni differenti e hanno fondamentalmente strutture differenti.

Le dipendenze, anche in forma binaria, dovrebbero essere controllate in modo che quando qualcun altro abbassa il progetto, funziona. Il problema principale non è il tipo di file, ma come viene creato il file. La regola empirica che uso è che se può essere generata utilizzando un altro file, non viene archiviato - questo significa documentazione generata automaticamente, file binari che creo e così via.

Uno dei principali vantaggi dell'utilizzo di SCM è la possibilità di ricostruire il sistema da qualsiasi momento nel passato. Quindi non ha senso memorizzare la build finale nel tuo SCM perché puoi semplicemente controllare il numero di revisione e crearlo.

Hai menzionato le dipendenze ... Il tuo SCM dovrebbe essere configurato in modo da poter eseguire un checkout pulito su una nuova macchina (con l'ambiente dev), premere build e dovresti essere in grado di creare il tuo sistema senza dover installare altro. Quindi mantenere le dipendenze binarie nel tuo SCM è una buona idea. Le librerie cambiano raramente, quindi non occupano molto spazio.

Quasi nessuno lo fa.

Sembra ridondante includere sia i file di origine che quelli di oggetto (i file di origine sono ovviamente richiesti). Oltre a essere inutili, i file oggetto possono occupare molto spazio. Se la tua azienda utilizza un SCM distribuito (Git, Hg, Bzr), allora quei file binari devono essere copiati e archiviati tra tutti gli sviluppatori.