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.
# Le premier lien est:
Posté par Edouard Gomez (site web personnel) . Évalué à 3.
--
Templeet m'a tuer le lien
# ...
Posté par M . Évalué à 2.
Souvent les SCM que j'ai pu utiliser on tedance a ne pas apprecier...
[^] # Re: ...
Posté par Edouard Gomez (site web personnel) . Évalué à 1.
Lorsque tu commite, tout se passe en local, je pensais que ce détail était connu, puisque Mercurial est un SCM distribué, c'est à dire que ton checkout est equivalent à un repository. Donc tu n'as pas besoin de te connecter pour commiter.
>ou un kill lorsqu'il est entrain de commiter les modifications
Ah bonne question, celui je testerai ce soir. Ceci dit, mercurial a une tendance folle a n'opérer qu'en append et ecrire les index qu'en fin de transaction, donc ca devrait pas casser trop souvent.
[^] # Re: ...
Posté par M . Évalué à 2.
Effectivement, j'avais pas fait gaffe, c'est le basé sur HTTP qui m'a induit en erreur. Justement, la synchro entre 2 repos (lorsque tu recupere le commit des autres), ne peut elle pas souffrir d'incoherence en cas de coupure reseau ?
# Lorsque les SCM fleurissent...
Posté par TNorth . Évalué à 2.
Je cherche toujours une solution simple et efficace pour un projet, mais entre Bazaar-ng ( http://www.bazaar-ng.org(...) ) qui n'est pas encore trop avancé, Darcs ( http://www.darcs.net(...) ) qui est un peu lent à mon avis, et développé en Haskell, ce qui n'aide pas (peu de développeurs) et maintenant ce nouveau projet qui semble avoir tout pour plaire (Python, rapide et utilise une interface Web pratique ) .....
Il va falloir ce décider un jour, mais sur lequel ? Je serai ravi d'avoir vos avis, bien qu'un comparatif fort complet soit disponible ici ( http://better-scm.berlios.de/comparison/comparison.html(...) ) A noter qu'il n'est pas complet.
[^] # Re: Lorsque les SCM fleurissent...
Posté par HSimpson . Évalué à 3.
> [...]
> A noter qu'il n'est pas complet.
P'tet bien que oui, p'tet bien que non
[^] # Re: Lorsque les SCM fleurissent...
Posté par TNorth . Évalué à 1.
Je voulais dire assez rempli, mais malheureusement pas avec toutes les nouveautés de ces derniers temps, Git, bzr, les évolutions de monotone et arch ...
Le dossier est donc complet mais un peu dépassé pour être convaincant.
Je lis beaucoup les mailing-listes de bzr, arch etc, et c'st fou à quelle vitesse les patches se succèdent !
En tout cas très bon signe que la communautés a d'énormes capacités quand il le faut ! (et quand c'est intéressant, hein ça le fait quand même d'avoir son SCM utilisé pour le noyau linux !)
Pour finir du coté de Bazaar-ng, un plugin semble prêt pour le pull/push via le net, par rsynch en particulier (pas encore testé). Un comparatif/benchmark serait agréable afin de souspeser les avantages et inconvéniants de chacun ...
[^] # Re: Lorsque les SCM fleurissent...
Posté par golum . Évalué à 2.
Les voici et par ordre chronologique SVP
http://linuxfr.org/2005/05/26/18996.html(...)
http://linuxfr.org/2005/05/11/18915.html(...)
http://linuxfr.org/~mammique/17910.html(...)
http://linuxfr.org/~patrick_g/16411.html(...)
http://linuxfr.org/~Funix/15903.html(...)
http://linuxfr.org/~moy/15924.html(...)
http://linuxfr.org/forums/10/2935.html(...)
http://linuxfr.org/~ehoebadoag/14603.html(...)
http://linuxfr.org/2004/04/21/16054.html(...)
http://linuxfr.org/2004/03/07/15605.html(...)
http://linuxfr.org/2004/02/29/15563.html(...)
http://linuxfr.org/2004/02/24/15522.html(...)
http://linuxfr.org/2004/02/10/15391.html(...)
http://linuxfr.org/~haleakala/9121.html(...)
http://linuxfr.org/2004/02/04/15330.html(...)
http://linuxfr.org/2003/07/09/13201.html(...)
http://linuxfr.org/2002/12/20/10759.html(...)
http://linuxfr.org/~GomGom/705.html(...)
http://linuxfr.org/2002/07/24/9062.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.