Questa è una domanda interessante. Prima dell'analisi, dirò che il risparmio di larghezza di banda non dovrebbe essere il motivo per cui si passa a un DVCS. Tuttavia, un punto correlato è il carico sul server e questo naturalmente andrà giù con un DVCS: le persone semplicemente non usano il server come spesso. Quando lo usano, lo usano per cose "semplici" come push / pull. Operazioni pesanti come annotate e grep vengono eseguite sul client.
Possiamo esaminare l'utilizzo della larghezza di banda guardando un esempio in cui un DVCS funziona in modo particolarmente scadente: un esempio con un file immagine. Il setup è così:
-
aggiungi un'immagine da 10 MB al tuo progetto. Poiché si tratta di un formato di file compresso, non è possibile comprimerlo ulteriormente e la versione iniziale occupa 10 MB nel repository.
-
Apporta 9 modifiche all'immagine. La compressione delta è spesso inutile per i formati compressi, quindi ogni nuova revisione occupa altri 10 MB nel repository.
-
La dimensione del repository è ora di 100 MB.
Ora possiamo confrontare la larghezza di banda utilizzata con un sistema centralizzato e un sistema decentralizzato. Sono uno sviluppatore Mercurial quindi userò Mercurial come esempio di DVCS (ma Git funziona allo stesso modo). Userò Subversion come sistema di controllo della versione centralizzato (CVCS):
-
Invio di una nuova revisione al server: hg commit; hg push rispetto a svn commit .
La larghezza di banda è la stessa poiché è necessario inviare un delta da 10 MB al server in entrambi i casi.
-
Nuova versione dal server: hg pull --update rispetto a svn update .
Un CVCS ti consente di scaricare i 10 MB necessari mentre un DVCS ti chiederà di scaricare le revisioni intermedie che ti mancano. Quindi il fabbisogno di larghezza di banda dipende dalla frequenza di aggiornamento:
-
Se si esegue una collaborazione stretta e quindi si aggiornano spesso, si finisce con il requisito stessa larghezza di banda .
-
Se aggiorni meno spesso, un DVCS utilizzerà più larghezza di banda .
-
Pagamento fresco : hg clone rispetto a svn checkout .t
Simile al caso precedente, ma con aggiornamenti molto rari. Quindi un DVCS scarica più dati di un sistema centralizzato.
-
Aggiornamento alla versione precedente: hg update vs svn update
Un DVCS richiede nessuna larghezza di banda qui, ma uno strumento centralizzato scaricherà 10 MB . A seconda del tuo flusso di lavoro, potresti farlo parecchio durante la ricerca di bug e quindi puoi avere notevoli risparmi qui.
Penso che i requisiti possano essere riassunti come segue: paghi un costo iniziale più ampio con un DVCS poiché scarichi tutto. Quando viene pagato quel costo, gli aggiornamenti alle vecchie revisioni sono gratuiti . Gli aggiornamenti alle nuove revisioni costano all'incirca come con uno strumento centralizzato, supponendo che si aggiorni frequentemente in entrambi i casi. L'invio di commit al server è uguale nei due sistemi.
Questo esempio mostra che esiste un sovraccarico associato a un DVCS. Tuttavia, in pratica il overhead è gestibile . Per il codice sorgente, la compressione delta si attiva e fa miracoli a mantenere basse le dimensioni del tuo repository.
Un esempio di Mercurial:
-
Il nostro file sorgente più grande ( mercurial/commands.py ) è un file Python da 200 KB. Dal momento che è un testo semplice, la versione iniziale può essere compressa a circa 50 KB all'interno del repository.
-
Abbiamo modificato il file circa 2200 volte nei prossimi cinque anni. La compressione delta indica che ogni modifica occupa circa 630 byte nel repository.
-
La dimensione totale nel repository è 1,4 MB.
Poiché per quel file (probabilmente il nostro file più usato) ha senso semplicemente scaricare tutte le revisioni 2200 in anticipo - è solo un altro 1,4 MB da scaricare! Quindi il sovraccarico è estremamente basso per i file di testo e questo è fondamentalmente il motivo per cui DVCS può anche essere considerato in primo luogo.
Ho anche guardato a OpenOffice. La copia di lavoro per un checkout di tip è 2.0 GB. Hanno 276.000 changeset nel loro repository e l'intera storia occupa 2.3 GB. Questo è un overhead 15% grazie all'eccellente compressione delta. L'overhead per un checkout iniziale sarà maggiore poiché un CVCS potrebbe comprimere i 2.0 GB fino a circa 500 MB. Ma risparmiano la larghezza di banda ogni volta che qualcuno deve eseguire il checkout di una vecchia revisione per correggere un bug - con un DVCS hai già i dati esattamente dove ne hai bisogno.
Infine, vorrei menzionare che Mercurial ha una estensione largefiles per la gestione di file che occupano troppo spazio nel repository . Funziona esternalizzandoli in modo che vengano scaricati solo quando necessario. Ciò trasforma efficacemente Mercurial in un CVCS rispetto a quei file.