File di grandi dimensioni nel controllo del codice sorgente (TFS)

Question

Recentemente in ufficio abbiamo parlato di inserire file di grandi dimensioni nel nostro repository TFS. I file stessi sono XML, di solito con dimensioni di 100-200 MB e talvolta grandi come 1 GB. Li usiamo come dati per i test automatici e sono per lo più statici (si ottiene un piccolo aggiustamento ogni anno o giù di lì). Ad ogni modo, c'è la nozione che mettere file come questo nel repository è un no-no perché sono "grandi" e questo renderà le cose "lente" (al di fuori dell'originale check-in/out) ma non lo facciamo avere qualche prova per sostenere questo.

Quindi la mia domanda è: quali sono i vantaggi/le implicazioni di inserire file statici di grandi dimensioni in un repository di codice sorgente come TFS (o SVN, Git, ecc.). È corretto? Riempirà il server o avrà altre conseguenze disastrose?

Answer 1

tl; dr: TFS è progettato per gestire file di grandi dimensioni con garbo. L'ostacolo più grande che dovrai affrontare è la larghezza di banda della rete per caricare/scaricare i file. Il secondo problema è quello dello spazio di archiviazione sul server. Supponendo che tu abbia preso in considerazione questi due problemi, non dovresti avere altri problemi.

Larghezza di banda di rete: C'è poco overhead nel check-in o nel recupero dei file, dovrebbe essere veloce come un tipico upload o download HTTP. Se i tuoi client sono remoti dal server, in termini di rete, possono trarre vantaggio dall'avere un proxy di controllo del codice sorgente TFS sulla rete locale per accelerare i download.

Nota che a differenza di alcuni sistemi di controllo versione, TFS non calcola e trasmette delta durante il caricamento o il download di nuovi contenuti. Vale a dire, se un client aveva la revisione 4 di un file di testo di grandi dimensioni e la revisione 5 aveva aggiunto alcune righe alla fine, alcuni strumenti di controllo della versione ottimizzano questa esperienza per inviare solo le linee modificate. TFS non esegue questa ottimizzazione, quindi se i tuoi file cambiano di frequente, i client dovranno scaricare l'intero file ogni volta.

stoccaggio Server: spazio sul disco del server è abbastanza semplice - è necessario uno spazio sufficiente per contenere i file, c'è poco overhead di là di questo. TFS non rallenta solo perché il repository contiene file di grandi dimensioni.

Se questi file vengono modificati di frequente, sarà necessario tenere conto anche dello spazio su disco utilizzato dalle revisioni. TFS memorizza i "delta" tra le revisioni dei file, ovvero una differenza binaria tra due versioni. Quindi, se il contenuto del file cambia in minima parte tra le revisioni come nel tipico caso d'uso con file di testo, il costo di archiviazione dovrebbe essere poco costoso. Tuttavia, se l'interezza dei contenuti cambia come sarebbe tipico con file binari come immagini o DLL, allora avrete bisogno di abbastanza spazio su disco per memorizzare ogni revisione. (Naturalmente, è possibile destroy revisioni precedenti al fine di recuperare quello spazio.)

Una nota sul delta in TFS: per ridurre il sovraccarico al momento del check-in, i delta tra le revisioni non vengono calcolate subito, c'è un fondo " deltafication "lavoro che viene eseguito di notte per calcolare i delta per ridurre lo spazio.Fino a quel momento, ogni revisione è memorizzata nella sua interezza nel database. Pertanto, se si dispone di un file di testo molto grande con molte revisioni che si verificano quotidianamente, i requisiti di spazio su disco dovranno tenerne conto.

stoccaggio Cliente: I clienti avranno bisogno di avere spazio sufficiente per contenere questi file anche (anche se solo alla revisione che hanno scaricato). Questo può essere mitigato nelle mappature delle aree di lavoro in modo tale che i file di grandi dimensioni sono ammantate (o altrimenti non incluso nel tuo spazio di lavoro) se non sono necessari.

avvertimento: Ottenere Versioni storici: Se vi trovate a richiesta delle versioni storiche di file di grandi dimensioni di frequente (per esempio: voglio un'immagine ISO sette gruppi di modifiche fa), allora si sta andando a rendere il server applica la catena delta per tornare a quella revisione. Se più client lo fanno contemporaneamente, questo potrebbe imporre un limite alla tua memoria.

Answer 2

Se quei file cambiano costantemente & i loro delta erano grandi, alla fine mi aspetterei una penalità nelle prestazioni TFS complessive.

Si dichiara chiaramente che questo non è il caso, quindi, a condizione che il server SQL abbia la capacità di ospitare l'archivio, credo che si dovrebbe essere in grado di procedere senza alcuna conseguenza.

Un inconveniente minore che si può verificare è quando si costruiscono nuovi spazi di lavoro, in cui si devono estrarre quei file dal proprio repository. Sfortunatamente ciò accade anche durante la compilazione TFS, quindi è possibile che le tue build impieghino molto più tempo. La gravità di questo angolo dipende molto dalla costellazione/stabilità della rete.

Answer 3

Il problema più grande (l'inconveniente) che si avrà è scaricare questi file di grandi dimensioni in tutte le aree di lavoro o mapparli. Considera di metterli in un progetto di squadra separato per semplificare la procedura (a meno che tu non voglia includerli nelle filiali, nel qual caso abuserei di tenere tutto in un progetto di squadra)

Se hai il controllo del formato xml allora anche prendere in considerazione alcuni ritocchi per renderli più piccoli. Ciò migliorerà le prestazioni delle operazioni store/get e anche la velocità di caricamento ... Abbrevia i nomi degli elementi e degli attributi, riduci il numero di cifre decimali che stai emettendo per i numeri in virgola mobile, ecc. Scoprirai che semplici schemi di minaccia come questo danneggeranno molti megabyte la dimensione dei file di dimensioni Gb, ed è facile battere una veloce trasformazione o codice xslt per convertire rapidamente i file nel nuovo formato.