Re: [HS] SCM distribu??s
On Tue, Apr 11, 2006 at 09:55:54PM +0200, J??r??me Marant wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
>
> > On Tue, 11 Apr 2006, J??r??me Marant wrote:
> >> git/cogito: efficace, partage efficace par HTTP via "packed objects",
> >> r??f??rentiel tr??s compact
> >
> > C'est vrai "r??f??rentiel tr??s compact" ? De ce que j'avais compris, git a
> > commenc?? comme un simple archivage historique de r??pertoire/fichiers (via
> > une empreinte SHA1 identifiant implicitement la version) ...
> > ce qui fait qu'il dupliquait ??norm??ment d'informations.
> >
> > Ca a chang?? ? J'ai mal compris ?
>
> Oui, ??a a chang??. En fait, c'est le plus compact qui soit, actuellement.
> Ce ne sont plus que des delta qui sont stock??s, plus certaines
> optimisations.
Pas exactement. En fait sous git il y a 2 représentations des mêmes
données:
- un objet= une signature SHA1=un fichier dans .git/objects/xx/$SHA1
ou xx sont les deux premiers caractères de la signature SHA1 dudit
objet en hexadécimal.
- toute une série d'objets compactés dans un ensemble de deux fichiers
(pack-$SHA1.pack et pack- $SHA1.idx) dans .git/objects/pack; dans
ces fichiers, on stocke une version puis les différences avec
d'autres versions (pas forcément la plus récente ou la plus
vieille, voir les heuristiques). Il y a une limite sur le longueur
des chaînes de différences pour des raisons de performance.
Le format des pack est expliqué plus ou moins dans le source de git
dans Documentation/technical/, le fichier pack-heuristiscs.txt
est, disons, intéressant.
Franchement depuis que je me suis habitué à git, je trouve
que tous les autres systèmes ont des limites. En particulier
l'un des développeurs du noyau fait des git-rebase pour
éviter que l'arborescence devienne inextricable:
http://www.ussg.iu.edu/hypermail/linux/kernel/0601.1/0172.html
aucun autre SCM n'offre, que je sache, cette possibilité. Elle
est un peu dangereuse (c'est en un certain sens réécrire
l'histoire) mais c'est une liberté de plus.
git est un peu délicat à manipuler par certains côtés, mais
son traitement des branches, le fait de pouvoir partager
partiellement les référentiels (alternate), qui sauve pas mal
d'espace disque, et d'autres caractéristiques en font mon
SCM préféré. Par certains côtés, il a largement dépassé
bitkeeper et les interfaces graphiques arrivent (qgit semble
progresser assez vite mais je ne le suis pas de près): j'aime
bien gitk pour regarder l'historique, les commandes de base
de git et vi me suffisent pour le reste.
En plus la vitesse de git est assez phénoménale, il est
tout à fait utilisable sur une machine de 5 ans si la
mémoire est suffisante. Bien sûr, un disque rapide ne fait
pas de mal.
Ceci dit, quand j'ai commencé sous git en Juin dernier
(conversion d'un référentiel BitKeeper en essayant de
préserver l'histoire), ce n'était pas encore vraiment
au point. Je crois que ça ne fait que 2 ou 3 mois que
git marche vraiment bien (par exemple que les tags des
versions sont transmis automatiquement par «git pull»)
et que la doc est devenue compréhensible.
Gabriel
Reply to: