Mercurial 1.0

Posté par Edouard Gomez (site web personnel) le 25 mars 2008 à 11:00. Modéré par Bruno Michel.

Étiquettes :

mar.

2008

Après plus de trois ans de développement, Matt Mackall, développeur principal de Mercurial, annonce sur la liste de développement du projet que la version 1.0 est enfin prête. Mercurial est un gestionnaire de source décentralisé écrit en Python dont les objectifs principaux sont :

Facile à maîtriser et utiliser ;
Léger ;
Bonne tenue en charge (« scalabilité ») ;
Facile à personnaliser.

Il est livré avec une excellente documentation qui permet bien sûr de découvrir l'ensemble des commandes du programme mais aussi de mieux appréhender la gestion de source décentralisée avec ses nombreux avantages. Ce gestionnaire fonctionne à la fois sous nos Unix préférés et sous Windows. Il intègre de plus un convertisseur de dépôt de source permettant de reprendre l'historique de ses anciens projets CVS, SVN, Git, Darcs, Monotone, et GNU Arch/Bazaar 1.x.

Laissez-vous tenter par cet excellent outil qui ne pêche que par le manque de publicité qu'il génère face à Bazaar ou Git. Voici un peu plus de détail concernant les fonctionnalités de Mercurial.
Rapide

Grande rapidité grâce à son format de stockage orienté delta-compression ;
Optimisé pour des accès rapides ;
Indexation croisée des changesets et fichiers ;
Protocoles HTTP et SSH optimisés en terme de bande passante et charge processeur.

Tenue en charge (« Scalable »)

Le modèle de développement distribué supporte un nombre illimité de développeurs ;
Permet la fusion arbitraire du travail de plusieurs développeurs ;
Son niveau de performance ne se dégrade pas avec un grand nombre de fichiers ou changesets ;
Pas d'attente sur verrou posé.

Robuste

Garantie d'intégrité des données du dépôt de source grâce à l'utilisation de sommes de contrôle SHA1 ;
Modèle de stockage « Append-only » avec un journal de transaction ;
Vérification du dépôt de source rapide ;
Format de stockage facilitant les sauvegardes.

Facile à utiliser

Ceux maîtrisant déjà CVS ou un autre gestionnaire de source, connaissent sûrement déjà la plupart des commandes ;
Aide en ligne intégrée ;
Fournit une interface web indépendante ;
Fonctionne avec plusieurs interfaces graphiques (TortoiseHG sous Windows par exemple).

Facile à mettre en place

Compatible UNIX, Mac OS X, et Windows ;
Plugin de conversion pour les gestionnaires de sources les plus communs ;
Permet des modèles d'usage variés ;
Supports de « hooks » et extensions définis par l'utilisateur.

Libre

Source disponible sous la GPL v2 ;
Soutenu et développé par une communauté active.

Mais rien n'est plus parlant que la liste grandissante de projets qui n'hésitent pas à basculer sous ce gestionnaire de sources :

La plupart des projets de chez Sun : OpenJDK, OpenSolaris, etc. ;
Mozilla ;
Des sous-projets du noyau: ALSA (pilotes son), LinuxTV (pilotes TV).

Alors oui, Mercurial n'est pas aussi exposé médiatiquement que Git ou Bazaar mais avec cette dépêche, j'espère que certains d'entre vous prendront le temps de découvrir Mercurial, de le comparer et donc de l'adopter :-).

N'oubliez pas de faire un tour sur le Wiki pour en savoir plus.

Aller plus loin

L'annonce de la 1.0 (3 clics)
Homepage (10 clics)
Téléchargement (3 clics)
La documentation (3 clics)
La naissance du projet (1 clic)

# Freehg : Hébergement gratuit

Posté par Ririsoft le 25 mars 2008 à 11:50. Évalué à 5.

Je me permet de rajouter que http://freehg.org a vu le jour récemment.
C'est une platforme d'hébergement gratuite (et libre) permettant à n'importe qui d'héberger n'importe quel(s) projet(s) mercurial.

Le tout avec la simplicité et le design qu'on aime chez mercurial.

C'est un projet indépendant de HG initié par Matthew Marshall.
- [^] # Re: Freehg : Hébergement gratuit
  
  Posté par -mat le 25 mars 2008 à 12:20. Évalué à 4.
  
  À noter aussi l'hébergement de dépôts mercurial sur : http://sharesource.org/
  - [^] # Re: Freehg : Hébergement gratuit
    
    Posté par Nÿco (site web personnel) le 25 mars 2008 à 13:00. Évalué à 8.
    
    Pas très futé comme nom, ça ressemble au programme « Shared Source » de Mircosfot, qui je le rappelle n'a pas pour vocation de faire du libre, de près ou de loin.
    - [^] # Re: Freehg : Hébergement gratuit
      
      Posté par gnu_castor le 25 mars 2008 à 15:30. Évalué à 2.
      
      Pas très futé comme nom
      
      Sisi ! les avocats de Microsoft vont égayer leur vie :)
# Autre "clients"

Posté par bidule le 25 mars 2008 à 12:10. Évalué à 4.

- xen est également développé sous mercurial.

- Coté kernel linux, il me semble qu'un dépot mercurial était synchronisé avec le dépot git principal: quelqu'un pour confirmer ?
- [^] # Re: Autre "clients"
  
  Posté par ribwund le 25 mars 2008 à 12:22. Évalué à 4.
  
  Oui, le mirroir est à jour sur http://www.kernel.org/hg/linux-2.6/
- [^] # Re: Autre "clients"
  
  Posté par Éric (site web personnel) le 25 mars 2008 à 13:37. Évalué à 1.
  
  Mozilla est aussi passé à Mercurial d'après les annonces qu'ils ont faites
# deux questions .....

Posté par totof2000 le 25 mars 2008 à 12:54. Évalué à 4.

La gestion des versions se fait-elle "à la CVS" avec versionning sur le fichier, et non pas sur l'ensemble du projet, ou à la "subversion", avec versionning sur le projet complet ?

Est-il prévu pour gérer efficacement les fichiers binaires (style images, fichiers issus d'un tableur, etc ....) ?
- [^] # Re: deux questions .....
  
  Posté par ribwund le 25 mars 2008 à 13:37. Évalué à 5.
  
  Sur l'ensemble du projet (comme tout les VCS distribués).
  
  Pour les fichiers binaires, la seule contrainte est qu'ils tiennent en mémoire. Après l'algorithme de diff ne trouvera des ressemblances qui si on peut en trouver (par exemple c'est peu probable pour un .tar.gz).
  Pour certains types de fichiers on peut avoir des performances excellentes à l'aide des filtres d'encodage/décodage.
  
  Par exemple si le format d'un fichier est du texte compressé avec gzip, il suffit de le décompresser dans le filtre d'encodage et de le recompresser dans le filtre de décodage pour avoir de bonnes propriétés sur le diff.
# plugins ODT ?

Posté par ploum (site web personnel, Mastodon) le 25 mars 2008 à 12:58. Évalué à 3.

Existe-t-il des gestionnaires de version qui supportent l'ODT ?

De manière générale, ce serait cool d'avoir des gestionnaires avec des plugins en fonction des type de fichier. Cela permettrait par exemple de gérer les diffs entre des images et ce genre de choses.
Mes livres CC By-SA : https://ploum.net/livres.html
- [^] # Commentaire supprimé
  
  Posté par Anonyme le 25 mars 2008 à 13:19. Évalué à 2.
  
  Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: plugins ODT ?
    
    Posté par Moonz le 25 mars 2008 à 14:20. Évalué à 5.
    
    Non, c'est du xml compressé en zip. Ce n'est pas la même chose.
    - [^] # Re: plugins ODT ?
      
      Posté par Matthieu Moy (site web personnel) le 25 mars 2008 à 15:02. Évalué à 2.
      
      Et c'est du XML "tout-sur-une-ligne", donc un diff bête et méchant dessus ne fait pas grand chose d'intéressant.
      - [^] # Re: plugins ODT ?
        
        Posté par .O. le 25 mars 2008 à 15:14. Évalué à 2.
        
        Il est possible d'enregistrer les fichiers ODT/XML avec des retour-chariots.
        Il suffit d'aller dans :
        menu Outils > Options > Chargement/Enregistrement > Général
        Décoche ensuite :
        Optimisation de la taille pour le format XML.
        
        [^] # Re: plugins ODT ?
        
        Posté par ribwund le 25 mars 2008 à 15:25. Évalué à 4.
        
        Ca change vraiment la taille leur truc ? Surtout si ils compressent le fichier apres...
        
        [^] # Re: plugins ODT ?
        
        Posté par .O. le 25 mars 2008 à 15:45. Évalué à 2.
        
        Personnellement, je ne sauvegarde jamais avec l'optimisation et je n'ai constaté aucune augmentation significative de la taille des fichiers.
        Effectivement, la compression atténue grandement une augmentation déjà peu importante en elle-même.
      - [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 mars 2008 à 15:31. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: plugins ODT ?
        
        Posté par Bozo_le_clown le 25 mars 2008 à 15:57. Évalué à 4.
        
        La bonne question est cela vaut-il vraiment la peine de se crever à créer un utilitaire diff pour chaque type de fichier existant ? Traitons-les juste comme du binaire ou utilisons des formats adaptés.
        
        La réponse est ... oui.
        Chaque format de fichier dispose de sa propre sémantique et ce n'est pas parce que tu disposes de comparateur/merger de fichiers XML que tu es en mesures d'apprécier un même changement qui apparait en plusieurs endroits d'un même fichier.Il y a de réels risques de corruption de fichiers.
        
        Clearcase implémente ca depuis toujours en permetttant d'associer à chaque type de fichier de se voir associer un outil de comparaison/fusion adapté. Malgré tous ses défauts, la façon dont il aborde cette problématique reste un de ses principaux attraits par rapport à la concurrence.
        Ainsi tu peux comparer des fichiers Word graphiquement (en attendant ODT) mais aussi des fichiers Rose ou même des arborescence complètes.
        
        Des initiatives émergent pour proposer des comparateurs pour les types de formats qui soient indépendantes du gestionnaire de version (cf. EMF Compare par exemple http://www.eclipse.org/modeling/emft/?project=compare#compar(...) Il serait donc dommage que les VCS ou les outils clients le négligent.
        ODT ne devrait donc pas déroger à la règle et proposer lui-même cette fonctionnalité (plugin OpenOffice par exemple).
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 25 mars 2008 à 16:15. Évalué à 4.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: plugins ODT ?
        
        Posté par Bozo_le_clown le 25 mars 2008 à 16:42. Évalué à 3.
        
        Et ma réponse est donc.
        Qui connait le mieux la sémantique de son fichier que l'outil qui l'exploite ?
        
        L'outil doit fournir son propre comparateur/mergeur qui accepte en paramètre 2 (comparaison) ou 4 (merge 3 contributeurs) versions de fichiers selon que tu souhaites comparer ou merger.
        Dans ton cas, il présente graphiquement la différence, te propose de choisir la combinaison et il assure la cohérence du changement. Le cas du merge des fichiers texte à plat (sources) qui ne présument pas de la sémantique n'est qu'un cas particulier. Pourquoi vouloir le généraliser à tous types de fichiers.
        Ainsi même un fichier java a une sémantique différente d'un fichier python et si un outil VCS les traite de façon identique on peut très bien imaginer qu'il passe la main à un IDE qui connait mieux la structure de ce fichier et est capable d'apporter plus d'intégration tout en n'étant pas trop intrusif (par exemple l'ajout d'une accolade ouvrante dans un merge de .java s'accompagne forcément de l'ajout d'une accolade fermante pour marquer la mise en bloc). L'IDE en est capable. encore faut il que le VCS lui passe la main dans de bonnes conditions.
        
        Ainsi on reste indépendant de l'outil VCS pour peu qu'il respecte le protocole.
        A chacun ses responsabilités.
        
        C'est ce que j'attends d'ODF (mais peut-être qu'OpenOffice le propose déjà)
  - [^] # Re: plugins ODT ?
    
    Posté par Raphaël SurcouF (site web personnel) le 25 mars 2008 à 15:27. Évalué à 7.
    
    Non seulement c'est du XML compressé en ZIP, mais si tu lis couramment le XML des documents OpenOffice.org, moi pas. Je ne me vois pas faire un diff entre deux versions d'un même document pour savoir ce que j'ai pu modifier.
    Ce qui manque dans tous les VCS, c'est un outil de diff pour les ODT, point.
    - [^] # Re: plugins ODT ?
      
      Posté par abramov_MS le 25 mars 2008 à 18:59. Évalué à 1.
      
      un truc comme ca?
      
      http://extensions.services.openoffice.org/project/OOoSVN
      
      (par contre on dirait que cela n'est plus trop developpe...)
      - [^] # Re: plugins ODT ?
        
        Posté par Thomas Douillard le 25 mars 2008 à 19:53. Évalué à 2.
        
        En suivant quelques liens il semble que le projet soit devenu : http://odfsvn.sourceforge.net/
- [^] # Re: plugins ODT ?
  
  Posté par Clément David (site web personnel) le 25 mars 2008 à 14:23. Évalué à 4.
  
  D'après ce qui est dit juste au dessus, il est apparemment possible d'utiliser des filtres avant et après le diff.
  
  Utilise alors un filtre ZIP/UNZIP pour le type ODT et le tour est joué.
- [^] # Re: plugins ODT ?
  
  Posté par Ririsoft le 25 mars 2008 à 14:33. Évalué à 5.
  
  Mercurial (Hg) supporte l'ODT, et donne ici une astuce pour afficher les diffs :
  
  http://www.selenic.com/mercurial/wiki/index.cgi/HandlingOpen(...)
- [^] # Re: plugins ODT ?
  
  Posté par Matthieu Moy (site web personnel) le 25 mars 2008 à 14:59. Évalué à 3.
  
  http://www-verimag.imag.fr/~moy/opendocument/
  
  (même texte que celui cité plus bas sur le Wiki de Mercurial)
  
  En fait, à partir du moment où on a un truc un peu flexible, et qu'on connait odt2txt, c'est assez facile de générer des diffs sur ces fichiers.
  
  Par contre, c'est un diff visuel, mais hors de question de l'appliquer avec patch. Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.
  - [^] # Re: plugins ODT ?
    
    Posté par -mat le 25 mars 2008 à 15:22. Évalué à 2.
    
    Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.
    
    Il y a http://tdm.berlios.de/3dm/doc/index.html
    C'est un peu rugueux... Mais j'espère bien l'utiliser ou m'en inspirer à court ou moyen terme (comprendre, dans longtemps ou jamais.... vu l'état d'avancement de mes projets perso)
# Netbeans est aussi developpe sous mercurial.

Posté par guignome (site web personnel) le 25 mars 2008 à 15:51. Évalué à 4.

A noter le suport de Hg integre dans netbeans: http://wiki.netbeans.org/MercurialVersionControlScreenshots (screenshots :-))
# Mercurial, c'est bon, mangez-en

Posté par Philippe F (site web personnel) le 25 mars 2008 à 20:46. Évalué à 5.

J'ai toujours du mal à comprendre pourquoi ce gestionnaire de version ne reçoit pas plus de publicité.

Quand on parle de développement distribué, on mentionne en général tout de suite git mais vraiment mercurial devrait venir en premier. Pour moi, une fonctionnalité fondamentale, c'est qu'il est extrêmement bien documenté et facile à prendre en main.

En quelques secondes, il est possible de faire une interface web pour un repository mercurial, laquelle interface permet à la volée de :
- télécharger un snapshot en tar gz ou zip
- s'abonner à un flux RSS

Par exemple :
http://sources.freehackers.org/hg.cgi

Bien qu'il soit en python, mercurial est presqu'aussi rapide que git; Le secret ? Eviter les "disk seek". Python n'est pas une cause de lenteur dans ce cas...

Dans la maintenant célèbre video de Linus où il vante les mérites de git, il glisse aussi une petite phrase en disant que le fonctionnement de fond de mercurial est exactement le même que git et qu'on peut choisir l'un ou l'autre.

La video côté google présentant mercurial :
http://video.google.com/videoplay?docid=-7724296011317502612(...)

Elle génère moins de buzz que celle de Linus, mais tel est le sort de Mercurial : moins de buzz mais des trucs qui marchent !
- [^] # Re: Mercurial, c'est bon, mangez-en
  
  Posté par alexissoft le 26 mars 2008 à 00:21. Évalué à -1.
  
  Perso, j'ai pas mal utilisé Mercurial. J'ai jamais pu piger le système de branchages et de merges, alors que git fait ça comme un charme.
  
  Le problème de Mercurial c'est que c'est un fouilli monstre, il y a 3600 commandes et de plugins dans tous les sens qui se tapent dessus. Suffit de faire un hg help pour voir le désastre.
  
  Du coup, je suis passé à git. Même si j'adorais Mercurial.
  - [^] # Re: Mercurial, c'est bon, mangez-en
    
    Posté par ribwund le 26 mars 2008 à 00:46. Évalué à 4.
    
    Les commandes ca depend de la distro, par défaut aucun plugin n'est activé, après si debian active tous les plugins c'est normal qu'il y ait beaucoup de commandes.
    
    Si l'on lance hg sans argument, uniquement les commandes importantes sont listés (une vingtaine alors que j'ai quelques extensions d'activés).
    
    Je pense que la meilleure chose à faire est de n'activer les plugins que si l'on en a besoin (et que ceux dont on a besoin).
    
    (git a quand meme plus de 130 sous-commandes, bien plus que mercurial, avec tous les plugins il y a 75 commandes max)
  - [^] # Re: Mercurial, c'est bon, mangez-en
    
    Posté par Thomas Capricelli (site web personnel) le 27 mars 2008 à 20:52. Évalué à 7.
    
    fouilli ? des millons de commandes ? On ne dois pas parler de la meme chose. C'est exactement le contraire qui m'a seduit avec mercurial.
    
    Apres avoir essaye git pendant plusieurs jours sans jamais rencontrer un truc simple ou intuitif, j'ai ete operationnel avec mercurial en 5 minutes. Vraiment 5 minutes, ce n'est pas juste une expression
    Avec git, j'ai du ouvrir des tas de docs/tutoriaux sur internet. Avec mercurial, meme pas. "hg help", et tout etait evident... J'ai utilise beaucoup d'outils de ce genre, proprietaires ou libres, et franchement, mercurial est le top du top, tres largement en avance sur tous les autres. git est pas mal, assez puissant, mais rien a voir en terme de facilite d'acces (et il ne marche pas sous windows.. oui, je sais bientot, presque, etc...mais pas maintenant.)
    
    Franchement, quand je tape "git<tab>" sur mon pc, j'suis trop content d'utiliser mercurial. La seule raison pour laquelle j'utilise encore un peu git, c'est pour avoir des branches locales de repository svn, sur mon portable.
    
    En plus de mes projets persos et professionnels, j'utilise les mirroirs mercurial pour le noyau linux, gcc et django. Ils prennent peu de place, malgre l'historique. (taille du 'repository' .hg inferieure a la taille d'un 'checkout'), et sont tres rapides.
- [^] # Re: Mercurial, c'est bon, mangez-en
  
  Posté par Mildred (site web personnel) le 26 mars 2008 à 13:33. Évalué à 2.
  
  Dans la vidéo (qui date un peu maintenant) ils disent que la possibilité de cloner une partie seulement du repository allait bientôt arriver ... mais il semble que non en fait:
  
  http://www.selenic.com/mercurial/bts/issue105
  
  Pourtant, je pense que c'est quelque chose d'imortant. Je pense par exemple a KDE qui maintient des logiciels similaires ensemble. J'imagine que tout le monde n'a pas forcément envie de tout télécharger pour travailler juste sur une partie.
  
  Et il y a aussi la possibilité de ne récupérer que les dernières révisions qui me semble pratique (lorsque le projet se développe):
  
  http://www.selenic.com/mercurial/wiki/index.cgi/TrimmingHist(...)
  
  mais je n'ai pas réussi a savoir si c'était implémenté ou non.
  - [^] # Google Summer of Code
    
    Posté par ribwund le 26 mars 2008 à 15:33. Évalué à 2.
    
    L'historique partielle et le clonage partielle sont potentiellement des projets Google Summer of Code.
    Donc pour les étudiants volontaires...
    
    http://www.selenic.com/mercurial/wiki/index.cgi/SummerOfCode
# Projets qui l'utilisent

Posté par Olivier Faurax (site web personnel) le 26 mars 2008 à 20:17. Évalué à 2.

Une rapide recherche m'a montré que Hg est notamment utilisé par Mozilla (pour FF4 et xulrunner 2) ainsi que par Sun pour la version Open Source de Java.
Il parait qu'OpenSolaris l'utilise aussi....
- [^] # Re: Projets qui l'utilisent
  
  Posté par Mildred (site web personnel) le 26 mars 2008 à 20:24. Évalué à 4.
  
  La news indiquait pourtant:
  
  Mais rien n'est plus parlant que la liste grandissante de projets qui n'hésitent pas à basculer sous ce gestionnaire de sources :
  
  * La plupart des projets de chez Sun : OpenJDK, OpenSolaris, etc. ;
  * Mozilla ;
  * Des sous-projets du noyau: ALSA (pilotes son), LinuxTV (pilotes TV).

Suivre le flux des commentaires

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