[Linuxtrent] Tecniche di versionamento
- From: Lele Gaifax <lelegaifax@xxxxxxxxx>
- To: linuxtrent@xxxxxxxxxxxxx
- Date: Fri, 7 Dec 2012 10:03:15 +0100
Il giorno Thu, 6 Dec 2012 19:52:45 +0100
Marco Ciampa <ciampix@xxxxxxxxx> ha scritto:
> In git gli stati sono "snapshot", non so con Mercurial ma darcs
> (e la sua teoria delle patch) come svn, i passaggi sono basati su
> differenze tra l'uno e l'altro. In git le differenze vengono usate
> sono come sistema di ottimizzazione interno dello spazio ma ogni
> stato è un "congelamento" di una situazione nel tempo indipendente
> dagli altri.
Credo sia opportuno chiarire svariate inesattezze... :-)
Praticamente tutti i sistemi di versionamento [moderni], tranne darcs,
lavorano sul concetto di snapshot, dove ogni "stato" è una fotografia
statica dei contenuti tracciati. Al fine di "minimizzare" lo spazio
occupato, ogni sistema implementa uno sistema che consente di
memorizzare su disco anziché integralmente tutti i successivi
fotogrammi della storia, le differenze tra ogni singola foto e la
successiva, in maniera molto simile a quello che fanno i vari
"compressori" di filmati, tipo MPEG, con la sostanziale differenza di
essere "loss-less".
Queste tecniche di compressione (detta "delta compression") risalgono a
tempi in cui era fondamentale farlo, perché sia la dimensione dei dischi
disponibili sia la banda passante sul "filo" erano di vari ordini di
misura inferiori a quelli odierni. Pioniere è stato SCCS, proprietario,
seguito da RCS, poco più giovani di me...
Alcuni sistemi utilizzano questa "ottimizzazione" anche per trasferire
gli stati da un repository all'altro (svn in primis, ma anche hg, o
bzr) per ridurre in maniera significativa anche la mole di informazioni
che devono passare "sul filo". Altri sistemi (git ad esempio) si
affidano invece alla qualità dei tradizionali compressori lossless
(gzip nello specifico), trasferendo cioè integralmente le singole
fotografie, ma compresse.
Darcs, da quanto ne so, è l'unico che invece considera i "cambiamenti"
come "unità di base", e al contrario degli altri sistemi mantiene sul
disco una "cache" formata dalle "fotografie" dei singoli
contenuti tracciati composti dalle singole patch applicate per
ottimizzare il suo lavoro.
Quello usato da darcs è senza dubbio un approccio molto più
ambizioso e potente, basato peraltro su una teoria non ancora
dimostrata (e difficilmente dimostrabile, a quanto pare), ma che per
sua natura non è adatto in quei contesti dove si vuole una "certezza
matematica" (in senso crittografico) del contenuto di un certo "stato"
nel tempo. È stata questa la considerazione fondamentale che ha
determinato una scelta diversa fatta a suo tempo da Linus quando ha
valutato le varie opzioni disponibili per uscire dall'empasse in cui si
era cacciato tempo prima lasciandosi abbindolare da Larry McVoy col suo
BitKeeper, spostandosi quindi sul modello implementato al meglio (a
quel tempo) da Monotone, dove ogni stato è una fotografia
"firmata" (sempre in gergo crittografico, chiaramente) in modo tale che
si ha la garanzia che ogni singolo fotogramma è "figlio" di un ben
determinato set di fotogrammi precedenti, ugualmente "firmati", quindi
definitivamente *dipendenti* dagli stati precedenti[1].
La leggenda racconta che proprio nei giorni in cui Linus ha considerato
Monotone e il suo modello, lo strumento soffrisse di un bug che ne
degradava pesantemente le prestazioni: nonostante il problema sia stato
riconosciuto e risolto a breve, ormai l'attenzione di Linus si era
spostata altrove, portandolo alla decisione di arrangiarsi e
ricostruire qualcosa di simile partendo da zero, cioè Git.
Ciao, lele.
[1] Per la cronaca, una ulteriore "estremizzazione" del concetto viene
applicato da Vesta, che non solo garantisce queste caratteristiche,
ma si spinge oltre includendo nel versionamento la totalità degli
strumenti usati per "manipolare" i contenuti tracciati (in poche
parole, prendendo ad esempio il kernel Linux, come se nel suo
repository venissero tracciati non solo tutti i sorgenti, ma anche
le esatte versioni di tutti gli strumenti usati, da tutta la
toolchain del compilatore gcc, all'awk, al perl, al sed, alla
bash...) di modo che anche tra un'era geologica sarebbe possibile
ottenere effettivamente una copia esattamente uguale, a livello
binario, di una qualsiasi versione del kernel.
--
nickname: Lele Gaifax | Se non si ha voglia di far conoscere a
real: Emanuele Gaifas | qualcuno quello che si è fatto, forse
lelegaifax@xxxxxxxxx | non si doveva farlo affatto. -- Google's CEO
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
