È possibile che GIT, Mercurial, SVN o altri strumenti di controllo versione funzionino correttamente quando l'albero del progetto contiene file binari?

Question

A volte l'albero del progetto può avere file binari, come jpg, png, doc, xls o pdf. GIT, Mercurial, SVN o altri strumenti possono fare un buon lavoro quando viene modificata solo una parte di un file binario?

Ad esempio, se la specifica è scritta in .doc e fa parte del repository, quindi se è 4 MB, ed è stata modificata 100 volte ma solo per 1 o 2 righe e verificata 100 volte durante l'anno, allora è 400MB.

Se si tratta di 100 diversi file .doc e .xls, quindi è 40 GB ... non una dimensione che è facile da gestire.

Ho provato GIT e Mercurial e vedo che entrambi sembrano aggiungere una grande dimensione di dati anche quando una riga viene modificata in un file .doc o .pdf. C'è altro modo all'interno di GIT o Mercurial o SVN che possono fare il lavoro?

Answer 1

In generale, sistemi di controllo versione funzionano meglio con i file di testo. L'intero concetto di unione/conflitto è basato sul codice sorgente. Tuttavia, SVN funziona piuttosto bene per i file binari. (Lo usiamo per i disegni CAD versione.)

Sottolineerò che il blocco dei file (svn: needs-lock) è praticamente indispensabile quando ci sono più persone che lavorano su un file binario comune. Senza il blocco dei file, è possibile che 2 persone lavorino contemporaneamente su un file binario. Qualcuno prima impegna le sue modifiche. Indovina cosa succede alla persona che non ha commesso. Tutto il lavoro binario/immutabile che hanno fatto è effettivamente perso. Le serializzazioni con blocco dei file funzionano sul file. Si perde la capacità di accesso "concorrenti" di un sistema di controllo di versione, ma avete ancora i benefici di un registro di commit, rollback ad una versione precedente, ecc

Il cliente TortoieSVN è abbastanza intelligente per utilizzare MS Word incorporato in unire lo strumento per diffare un file doc/docx. Ha anche opzioni di configurazione per consentire di specificare strumenti di diff alternativi basati sull'estensione del file, il che è piuttosto interessante. (È un peccato che nessuno abbia realizzato uno strumento diff per il nostro pacchetto CAD).

I DVC di generazione corrente come Git o Hg tendono a succhiare con i file binari. Non hanno alcun tipo di meccanismo per il blocco dei file.

Answer 2

Vedere mercurial wiki page about Binary files. Il tuo problema principale è che anche piccoli cambiamenti nei file come doc e altri trigerano grandi cambiamenti nella struttura del file (in parte perché sono compressi).

Pertanto, non credo che troverete un modo piacevole per gestire questi file in un sistema di controllo della versione.

Answer 3

Esistono strumenti diff binari, tuttavia non aiutano molto, poiché la modifica di un pixel di un'immagine o di un cambiamento di un carattere in un documento di Word non corrisponde al cambiamento di un byte nel file , a causa della compressione. Quindi una gestione "carina" di tali dati binari è impossibile.

Se si desidera eseguire il commit di tali documenti, prendere in considerazione l'inserimento di varianti non compresse: RTF anziché DOC, TeX anziché PDF, ecc. Se il sistema di controllo versione utilizza la compressione per comprimere il repository interno, questo metodo dovrebbe funzionare piuttosto bene. Ad esempio, in Git,

Gli oggetti aggiunti di recente vengono memorizzati nella loro interezza utilizzando la compressione zlib.

EDIT: Volevo solo notare che anche RTF è orribile, ma non è così orribile come DOC. Se puoi passare a TXT o TeX per i tuoi documenti, sarebbe meglio.

Answer 4

Ho usato git per sincronizzare i miei documenti tra macchine Mac, Linux e Windows. Ho dovuto fare una riprogettazione per eludere un limite di file di 2 GB su Windows. In totale è di circa 7 GB in 3 repository che vengono regolarmente sincronizzati. Ad un certo punto ho avuto anche una copia remota su un server ospitato su internet da qualche parte.

Ora non ho quasi mai bisogno di clonare questi repository così le grandi dimensioni non ostacolano molto. Vedo anche che il simbolo .git non aumenta in modo significativo e rimane a circa il 40-60% delle dimensioni dei documenti estratti, dei pdf, dei fogli excel.

Cambiare una riga in un file doc in pdf, cambia molto nel file mentre gli effetti di formattazione si propagano. Allo stesso modo cambiare una cella in un file XLS può cambiare molte altre celle.

Tuttavia, rispetto all'alternativa di non avere i documenti sotto il controllo di versione, sono felice di vivere con meno di rapporti di compressione stellari

Answer 5

IMHO, è necessario interrompere l'utilizzo di un SCM per gestire documenti come questi. Dovresti usare strumenti dedicati come Alfresco (sono sicuro che ci sono molti altri strumenti per la gestione dei documenti).