Perché i repository Git / Mercurial usano meno spazio?

Ho letto su diverse discussioni qui e su SO che i repository DVCS utilizzano lo stesso o meno spazio delle loro controparti centralizzate. Potrei averlo perso, ma non ho trovato una buona spiegazione del perché. Qualcuno sa?

— Alex Florescu
fonte

I post di followinfg sono quelli che hai letto? stackoverflow.com/questions/7727791/... o stackoverflow.com/questions/8657710/... o stackoverflow.com/questions/456336/...

— VonC

Non ho grazie! Quindi capisco da quelle che ci sono due risposte: compressione usando zlib e salvataggio di oggetti come file pack quando possibile. Anche gli esempi di Mozilla sono fantastici!

— Alex Florescu,

@Alex No, manca il motivo principale. SVN salva istantanee complete, Git e Mercurial salvano solo la revisione HEAD e le differenze. L'uso della compressione convenzionale consente di ottenere tassi ottimali di compressione del 60–80% circa. L'uso di diff potrebbe darti fino al 99%. Questi numeri mi vengono estratti dal culo - i numeri reali potrebbero differire; la tendenza sarà la stessa però.

— Konrad Rudolph,

@KonradRudolph, non sono questi i pacchetti?

— Alex Florescu,

@Alex Non proprio. Per quanto ne so il packfile è inoltre preparando più file in uno. Questo non è necessariamente correlato.

— Konrad Rudolph,

Dalla mia esperienza, le seguenti affermazioni sono tutte vere:

Git è molto efficiente nella memorizzazione di file di testo e nella memorizzazione solo di questi file che sono stati modificati. quindi quando si fa un confronto tra SVN e Git per confrontare le dimensioni del repository, potrebbero essere simili o potrebbe esserci anche un piccolo vantaggio per Git.
Questo è completamente sbagliato se si confronta la dimensione dei repository in cui una quantità significativa di file sono file di Office (come MS Word, Excel, Powerpoint, ...). Qui Git memorizza anche copie complete, il che significa che 10 piccole modifiche su una pila di diapositive powerpoint danno come risultato 10 copie complete, in cui Subversion memorizza solo un diff binario, che può essere un fattore 100 più piccolo.

Se si confronta la posizione di pagamento (che è un repository in sé con Git), la storia è completamente diversa:

Subversion memorizza per ogni file una copia completa, quindi la dimensione della posizione di pagamento è normalmente 2 volte la dimensione dei file stessi.
Git memorizza localmente la cronologia completa del repository, quindi a seconda delle dimensioni della cronologia, questa può essere più piccola o molto più grande di quella della copia di verifica di Subversion.

Se si confronta la quantità di byte da scaricare o caricare, è di nuovo diverso.

Subversion deve normalmente inviare o ricevere meno byte, perché invia solo differenze. Deve farlo ad ogni commit e aggiornamento.
Git deve ottenere l'intero repository (inizialmente), quindi inviare file completi (compressi?) Che non sono così diversi per i file di testo, ma possono essere diversi per i file binari. E sì, Git lo fa solo quando si spinge o si trascina qualcosa nel repository remoto.

Quindi, alla fine, confronti le mele con le arance e, a seconda di cosa vuoi fare con Subversion o Git, il risultato potrebbe essere diverso.

@jk ha chiesto informazioni su copie complete o differenze binarie e non ho potuto rispondere a questa domanda. Ho chiesto a Matthew McCullough che ha tenuto un workshop Git di recente a Jax 2012 (che ho visitato). Si è preso il tempo (grazie mille a lui) per spiegare con una sintesi dettagliata il funzionamento interiore di Git. Quindi sì, c'è una compressione che funziona lì (e farò anche un esperimento con un file di Microsoft Office e lo confronterò con il suo significato), ma no, la compressione viene eseguita sull'intero file. Citando dal suo succo:

Gli oggetti sciolti sono scritti in formato compresso, ma non delta al momento di ogni commit.

— mliebelt
fonte

sei sicuro che git memorizzi copie complete dei file di Office? Penso che memorizzi anche differenze binarie. ovviamente il vero problema con questo tipo di file è che spesso sono già compressi, quindi una piccola modifica può causare la modifica dell'intero file

— jk.

Chiesto a qualcuno (via e-mail) che conosca molto più di me e includerà la sua risposta nella mia risposta.

— mliebelt,

Git tratta i file di testo e binari esattamente allo stesso modo in tutti gli aspetti relativi all'archiviazione. Gli oggetti sfusi vs. impacchettati non sono correlati al testo rispetto al binario. Il motivo per cui i file binari si traducono spesso in differenze molto maggiori rispetto ai file di testo è che molti formati binari (inclusi tutti i nuovi formati di Office) sono già compressi e quindi anche un piccolo cambiamento nel contenuto spesso causa grandi cambiamenti nel BLOB binario risultante. Questo è ugualmente preoccupante per git e sovversione, ma la sovversione prende solo la penalità sul server, mentre git ovunque.

— Jan Hudec,

Gli oggetti sfusi vs. impacchettati non hanno nulla a che fare con il testo rispetto al binario. È l'ammortamento del difficile lavoro di ricerca dei differenziali binari. La velocità è una caratteristica importante di git, quindi durante il normale funzionamento, git comprime solo i nuovi dati e li schiaffeggia nel repository. Questo è oggetti sciolti. Rispetto a quando lo chiedi chiamando git gco si accumulano troppi oggetti sfusi, trova buoni candidati per delta-comprimerli (git può differire rispetto alla versione precedente), memorizza i delta in un "pacchetto" e rimuove gli oggetti sfusi.

— Jan Hudec,

Per coloro che sono interessati ai numeri del mondo reale: ho appena confrontato due copie funzionanti dallo stesso identico repository. La copia di lavoro SVN è di circa 2,9 GB, la copia di lavoro GIT di circa 0,8 GB.

— JensG,