Journal Mercurial, un autre SCM qui se cherche une place

Posté par  (site web personnel) .
Étiquettes :
0
5
juil.
2005
Hello journal,

Même si j'ai été obligé de me vendre dans les forums pour gagner des XP et pouvoir poster ce journal... je t'en veux pas trop de m'avoir bouder en m'empêchant de te parler.

Bref tout cela pour dire que j'ai continué à tester des SCM depuis mon dernier journal. La victime suivante a été Mercurial (http://www.selenic.com/mercurial).(...)

C'est un sympathique projet en Python qui basé sur les mêmes idées que GIT (de linus torvalds) tente de réparer des erreurs de design fondamentales
- c'est pas un modèle de portabilité (il y auraient de flagrant linuxismes)
- les objets du backend nommés par le sha1 de leur contenu tend à pourrir les perfs lors des tree traversing de source. Cette baisse de perfs est due au fait que le backend en deux niveaux (un niveau de répertoire qui donne le début du hash sha1 et le nom complet de l'objet sha1 ensuite) tend à éloigner physiquement sur le disque des fichiers proches par leur localité dans l'arborescence logique.
- n'est pas un SCM en soi, pour espérer pouvoir s'en sortir, il faut cogito, un sur-ensemble à GIT qui permet de s'en servir de façon conviviale.
- consomme trop d'espace disque pour la taille d'un projet comme linux (3.6GB pour l'historique de linux depuis le 2.4.0). Ceci rend impossible l'import de l'historique global par tout le monde sans plomber kernel.org. Linus a décidé de ne publier l'historique que depuis le 2.6.12-rc2 pour remédier à ça. Mais même comme ça kernel.org a du mal à supporter la charge imposée par des synchros rsync.
- et d'autres dont je suis moins sûr, donc autant éviter l'impression de linchage qui n'est absolument pas mon but.

Donc mercurial a corrigé tout ça. Certains algos trop coûteux de GIT ont été écartés dans le design, et Mercurial a favorisé deux choses:
- le cross indexing entre les revisions de fichiers et les changesets, ce qui rend extrêmement efficace la navigation dans les versions (pratique pour les opérations d'annotations, de diff entre 2 versions arbitraires, et de recherche d'ancêtre lors de merges)
- backend qui respecte l'arborescence logique et qui enregistre les modifs de façon incrémentale et non pas sous la forme d'objets complets.
- protocole assez efficace pour synchroniser deux repositories (basé sur HTTP).

Avec ça on arrive à:
- historique de linux depuis le 2.4.0: 309MB
- clone d'un repo linux comprenant l'historique complet: ~130MB transférés.
- et pleins d'autres trucs impressionnants comme des diffs super rapides, des imports de patch rapides, des annotations peu coûteuses etc... (pour des chiffres sur l'importation de patchs voir http://www.selenic.com/pipermail/mercurial/2005-June/001498.html(...) )

Pour le coup j'ai amélioré mon script d'export arch vers "autre SCM" maison (sans prétention, y a un projet Python qui ferait beaucoup mieux d'apres ce j'ai cru en lire mais manque de bol, il supporte pas arch. Ca s'appelle tailor). Le repository obtenu est dispo la: http://ed.gomez.free.fr/vrac/xvidcore-mercurial.tar.bz2(...) , le script dont je me suis servi est la: http://ed.gomez.free.fr/vrac/convert-xvid-baz-repo-to-mercurial.sh(...) .

Bon je m'arrête là, je vous laisse découvrir l'outil par vous même.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.