Gestion de configuration distribuée avec Mercurial

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
12
6
déc.
2008
Python
Mercurial est un système de gestion de version distribué léger écrit en Python. Il est multiplateforme (merci Python), rapide, facile à utiliser, propose des outils de migration/conversion des autres systèmes de gestion de configuration et est proposé sous licence GPL.

La version 1.1 sortie le 2 décembre apporte de nouvelles fonctionnalités, des améliorations et des corrections de bugs. Voici les points principaux des changements apportés par la version 1.1 :
  • resolve : nouvelle commande pour garder une trace des fusions
  • nouvelles extensions
    • rebase : nouvelle extension gérant le portage de changesets d'une branche à l'autre
    • bookmarks : nouvelle extension fournissant (en local seulement) des branches à la manière de git
  • nouveaux thèmes graphiques (interface web)
  • amélioration de la gestion des chemins (sous Windows)
Pour le détail complet des changements, se reporter aux liens ci-dessus. Un effort de traduction a été apporté, donc cette liste est disponible en français.

PS : pour changer l'apparence de l'interface web, il suffit de remplacer le nom du style par l'un des trois suivants : paper, coat, monoblue

Aller plus loin

  • # Configuration

    Posté par  (site web personnel) . Évalué à 10.

    s/configuration/version/ non ?

    • [^] # Re: Configuration

      Posté par  (site web personnel) . Évalué à 2.

      Oui, j'y ai cru moi aussi.

    • [^] # Re: Configuration

      Posté par  (site web personnel) . Évalué à 2.

      oui àmha aussi, mais j'ai gardé le terme initial de l'auteur et pas retenu le lien vers
      http://fr.wikipedia.org/wiki/Gestion_de_configuration_logici(...) à la lecture du § "différences"

    • [^] # Re: Configuration

      Posté par  . Évalué à 3.

      C'est un terme bizarre, mais qui est utilisé partout dans l'industrie. J'ai l'impression que c'est une "erreur" qui s'est tellement banalisée que tout le monde dit ça maintenant. Si quelqu'un avait une explication ...

      • [^] # Re: Configuration

        Posté par  . Évalué à 4.

        Ben c'est sûr que configuration est un mot plus Enterprise-ready:
        - plus de lettres
        - moins de sens (vu qu'il est utilisé pour tout)

        • [^] # Re: Configuration

          Posté par  (site web personnel) . Évalué à 2.

          hmmm pas tout à fait ;-)
          La gestion de version des sources n'est que le coeur de l'oignon de gestion des développements, il y a la gestion des demandes et le suivi des déploiements dans les différents environnements (dév', recette, intégration, préproduction, production...) qui fait toute la gestion de configuration. (Tout cela pour être en mesure de répondre rapidement "telle fonctionnalité est-elle présente en production ?" :D).

          Donc bon, quand tu es aux études et qu'on te parle de gestion de configuration, ça répond principalement en terme de gestion de version des sources et des livraisons, de fait j'identifie le glissement sémantique à ce niveau...

          • [^] # Re: Configuration

            Posté par  . Évalué à 2.

            Oui mais moi c'est le terme "configuration" qui fait bizarre : généralement, on parle d'un ensemble de paramètres qui désignent une "configuration". Et là je ne vois pas le rapport. Ou alors ce mot a un autre sens que je ne connais pas ?

            • [^] # Re: Configuration

              Posté par  . Évalué à 3.

              En fait quand tu désignes un version de ton produit (la 1.5 par exemple) tu fais référence à une configuration qui identifie une version au plus de chacun des éléments soumis au contrôle de versions de ton projet.

              C'est un peu une snapshot

          • [^] # Re: Configuration

            Posté par  . Évalué à 3.

            La GCL est une discipline qui vise à à identifier les états d'un système et à pouvoir identifier les changements entre chaque état.

            On parle d'article de configuration pour chaque élément qui obéit aux processus de GCL. C'est en quelque sorte l'atome de la GCL dont chacune des version peuvent être identifiés. C'est en général les fichiers soumis au contrôle de version

            Une configuration permet d'identifier tout ce qui permet de reconstituer un état le système dans sa globalité Elle permet d'identifier une version pour chacun des articles de configuration.

            Historiquement le outils de gestion de version (RCS) ne permettaient pas d'identifier des configurations (basaeline)et traitaient chaque fichier indépendamment.C'est pourquoi on faisait la différent entre outil de contrôle de version et outil de gestion de configuration

            Avec un outil comme SVN, à chaque fois que tu commites un fichier ou un changeset tu crées une nouvelle configuration.

            Chaque outil apporte des fonctionnalités différentes et se réclame outil de GCL ce qui apporte un peu de confusion
            Ainsi Clearcase apport des fonctionnalités au niveau du build (audit de fabrication) qui permettent de garantir qu'un système sera reconstruit à l'identique à partir des mêmes version des sources.

            Vesta (outil libre va encore plus loin dans cette direction http://www.vestasys.org/)

            Perforce apporte des fonctionnalité pour géré les changeset et s'en réclame aussi, ...

            Attention la gestion des changement est différente de la GCL
            http://fr.wikipedia.org/wiki/ITIL.

  • # Les thèmes hgweb

    Posté par  . Évalué à 7.

    Pour ceux qui veulent voir les thèmes hgweb (le 4eme lien est pas très clair sur ce qu'il est censé montrer):

    monoblue: http://hg.xavamedia.nl/mercurial/crew/?style=monoblue
    paper (nouveau thème par défaut): http://hg.xavamedia.nl/mercurial/crew/
    coal: http://hg.xavamedia.nl/mercurial/crew/?style=coal
    spartan (l'ancien thème par défaut, plutot moche): http://hg.xavamedia.nl/mercurial/crew/?style=spartan
    gitweb: http://hg.xavamedia.nl/mercurial/crew/?style=gitweb

    L'autre nouveauté c'est le graphe:
    http://hg.xavamedia.nl/mercurial/crew-stable/graph/8625504f5(...)

  • # Mercurial 2.0

    Posté par  . Évalué à 2.

    La prochaine version devrait utiliser Python 3.0.

    • [^] # Re: Mercurial 2.0

      Posté par  . Évalué à 1.

      Où est disponible cette information ? Il ne me semble pas l'avoir lue sur le site où d'ailleurs la feuille de route n'est plus maintenue à jour.

    • [^] # Re: Mercurial 2.0

      Posté par  . Évalué à 2.

      C'est un troll ? Si oui il est joli :)

      Disons que le passage à unicode pour la gestion des noms de fichiers ne fait pas que des heureux pour un logiciel comme mercurial.

      • [^] # Re: Mercurial 2.0

        Posté par  (Mastodon) . Évalué à 2.

        Pourquoi ça ?

        Yth...

        • [^] # Re: Mercurial 2.0

          Posté par  . Évalué à 2.

          En gros tu veux que LANG=C mercurial, marche avec des noms de fichiers en utf-8, ça demande pas mal de changements avec python3 (où les noms de fichiers sont convertis en unicode).

          • [^] # Re: Mercurial 2.0

            Posté par  (Mastodon) . Évalué à 3.

            Sérieux, faut vraiment que tu m'expliques, avec un exemple et tout, parce que je ne vois pas le problème en fait...
            Les noms de fichier sont majoritairement ascii, donc quel que soit l'encodage, UTF-8, iso-8859-1, ou que sais-je, ils sont codés de la même manière, et fonctionnent pareil.

            Décider que tout sera en UTF-8 ressemble quand même à une bonne idée pour éviter des tas d'emmerdes : les divers encodages de caractères sont depuis toujours une inépuisable source d'emmerdes et de complexités.

            Donc quel peut bien être le problème des noms de fichiers UTF-8 utilisés avec Mercurial ?

            Yth, vraiment perplexe.

            • [^] # Re: Mercurial 2.0

              Posté par  . Évalué à 1.

              C'est comme pour les outils de backup, si un nom fichier n'est pas décodable depuis la locale utilisée vers unicode, on ne peut pas l'ignorer non plus, donc on considère les noms de fichiers comme des bytes.

              Par exemple, si les noms de fichiers sont en UTF-8, mais que pour une raison ou pour une autre (par exemple ton programme est lancé depuis cron), mercurial est lancé avec la locale "C", alors si on considérait les noms de fichiers comme autre chose que des bytes, alors ça planterait (on ne peut pas ouvrir certains fichiers par exemple).

              Maintenant le problème pour nous en dehors de transformer tous les open/listdir/etc en version bytes (bon a priori on est déjà en binary mode à cause de windows donc les open ça doit être bon) c'est que l'API bytes n'est pas complete, par exemple au niveau de sys.argv et os.environ.

              Et à mon avis il y encore d'autres problèmes qui n'ont pas été résolus par exemple je n'ai aucune idée de comment on peut écrire des bytes dans sys.stdout.

              • [^] # Re: Mercurial 2.0

                Posté par  . Évalué à 2.

                je n'ai aucune idée de comment on peut écrire des bytes dans sys.stdout.

                >>> import sys
                >>> f = open(sys.stdout.fileno(), "wb", buffering=0)
                >>> f.write(b"abc")
                abc3

                (le "3" étant la valeur de retour de f.write(), affichée par l'interpréteur interactif)

                • [^] # Re: Mercurial 2.0

                  Posté par  . Évalué à 2.

                  Et c'est quoi la raison fondamentale pour que ce ne soit pas possible de mélanger les bytes et l'unicode à l'écriture ? C'est parce que ça empeche de faire un aller-retour (si on écrit des bytes mélangés à l'unicode, on ne peut pas le relire en garantissant le même résultat) ?

                  • [^] # Re: Mercurial 2.0

                    Posté par  . Évalué à 3.

                    Et c'est quoi la raison fondamentale pour que ce ne soit pas possible de mélanger les bytes et l'unicode à l'écriture ?

                    La même raison pour laquelle on n'a pas le droit de concaténer bytes et unicode : parce que sémantiquement ça ne veut rien dire. Si vraiment tu veux le faire, tu dois gérer l'encodage à la main et ça te force à réfléchir à ce que tu fais : explicit is better than implicit.

                    Une autre raison plus pragmatique est que lors du portage d'un programme de Python 2.x à Python 3.x, il y a forcément des endroits où l'on passe des bytes par erreur plutôt que de l'unicode. Du coup, avoir une API standard relativement stricte vis-à-vis de cela permet de détecter les erreurs plus tôt.

                    (dans le cas de Mercurial, j'imagine que vous ferez presque tout en bytes de toute façon)

                    ---

                    Note : la solution que je t'ai donnée est sous-optimale car elle recrée un objet fichier. On peut plus simplement faire :

                    >>> f = sys.stdout.buffer
                    >>> f
                    <io.BufferedWriter object at 0xb7c78fec>
                    >>> f.write(b"abc")
                    abc3

      • [^] # Re: Mercurial 2.0

        Posté par  . Évalué à 2.

        Ce n'est pas un troll, j'ai envoyé un courriel à Matt Mackall le créateur de Mercurial
        et il m'a assuré que la futur version majeur utilisera Python 3.0.

        • [^] # Re: Mercurial 2.0

          Posté par  . Évalué à 4.

          J'aimerais bien voir le mail, c'est sur une mailing-list ?

          Perso j'ai plutot entendu Matt troller pour dire que il préférait encore Ruby à python3.

          A moins qu'une version majeure soit un redesign important (un futur hypothétique hg-ng), je ne pense pas que python3 sera supporté (même si des efforts sont fait pour faciliter la conversion avec 2to3.py), la compatibilité avec les anciennes versions python (2.3 à 2.6) restant prioritaire.

          • [^] # Re: Mercurial 2.0

            Posté par  . Évalué à 1.

            J'ai mal lu ce que Matt m'a écrit. En fait, il dit que normalement la prochaine version majeur DEVRAIT utiliser Python 3.0 mais que l'équipe réfléchit à utiliser d'autres langages.

            On peut lui écrire à cette adresse : mpm@selenic.com

            • [^] # Re: Mercurial 2.0

              Posté par  . Évalué à 1.

              On ne peut présumer ici de l'avenir, je pense qu'il serait dommage d'abandonner Python au profit d'un autre langage. Lorsque mon choix s'est porté sur Mercurial c'est justement que je ne souhaitais pas devoir prendre des tonnes d'outils tierces alors que je travaille déjà avec Python (qui est très riche avec sa bibliothèque standard).

              Même si Mercurial m'a au début un peu dérouté je m'y suis habitué rapidement. Je suis aussi utilisateur de SVN et Clearcase (pro). Ce que j'aime est le stockage des informations de configuration dans le répertoire .hg avec l'absence de serveur (même local) car sous certaines contraines (utilisation/accès/environnement) il me permet de faire de la micro-gestion de mes sources.

              • [^] # Re: Mercurial 2.0

                Posté par  . Évalué à 2.

                Rassure toi, je pense que la plupart des developpeurs principaux n'envisagent pas du tout de quitter Python :)

                Je n'ai entendu que Matt dire ça, et c'était sous forme de boutade.

            • [^] # Re: Mercurial 2.0

              Posté par  (site web personnel) . Évalué à 4.

              il va être content en tout cas à la réception de tous les spams que lui aura valu ton simple commentaire avec son mail en clair :/

              • [^] # Re: Mercurial 2.0

                Posté par  . Évalué à 4.

                Results 1 - 10 of about 779 for mpm@selenic.com. (0.37 seconds)

  • # Conversion transparente depuis et vers git ?

    Posté par  (site web personnel) . Évalué à 2.

    Je profite de cette dépêche pour demander aux spécialistes si mercurial intègre maintenant (je crois que c'était vaguement en projet) la possibilité d'exporter vers un dépôt git facilement.

    L'histoire c'est que j'aimerais bien pouvoir utiliser mercurial (que j'adore) à la place de git pour les projets utilisant git. Je sais que l'utilisation est très similaire, mais il y a quand même des différences ...

    • [^] # Re: Conversion transparente depuis et vers git ?

      Posté par  . Évalué à 2.

      A ma connaissance non, il y a beaucoup de travail sur le 2-way avec subversion (avec hgsubversion qui commence à être bien avancé). Sur git il y a quelques efforts pour incorporer fast-import/fast-export mais pas beaucoup plus. Mais c'est vrai que c'est certainement beaucoup plus facile que le bidirectionnel svn.

      Ah si, aussi pendant le Google Summer of Code mentor summit à l'automne, il y a eu pas mal de discussions pour voir si on pourrait rapprocher le protocole réseau des deux projets.

    • [^] # Re: Conversion transparente depuis et vers git ?

      Posté par  (site web personnel) . Évalué à 1.

      Peux-tu me donner tes arguments (même subjectifs) qui te font préférer mercurial à git ?
      J'hésite à choisir l'un ou l'autre.

      • [^] # Re: Conversion transparente depuis et vers git ?

        Posté par  . Évalué à 3.

        de mon point de vue :
        la simplicité
        le nombre de dépendance si tu est pas connecté à internet (python pour mercurial, plein d'extension perl pour l'autre…)
        le tortoisehg pour les windosiens

        Un comparatif amusant : http://importantshock.wordpress.com/2008/08/07/git-vs-mercur(...)

        • [^] # Re: Conversion transparente depuis et vers git ?

          Posté par  (site web personnel) . Évalué à 2.

          C'est quoi cette histoire d'extensions Perl ? J'utilise Git sans jamais avoir installé ou téléchargé la moindre extension Perl. Et vu qu'il est pour l'essentiel écrit en C avec quelques scripts en bash (et peut-être un ou deux scripts en Perl basique), c'est pas étonnant.

          • [^] # Re: Conversion transparente depuis et vers git ?

            Posté par  . Évalué à 2.

            ici sous debian :

            Depends: libc6 (>= 2.7-1), libcurl3-gnutls (>= 7.16.2-1), libexpat1 (>= 1.95.8), zlib1g (>= 1:1.2.0), perl-modules, liberror-perl, libdigest-sha1-perl
            Recommends: patch, less, rsync, ssh-client
            Suggests: git-doc, git-arch, git-cvs, git-svn, git-email, git-daemon-run, git-gui, gitk, gitweb

            • [^] # Re: Conversion transparente depuis et vers git ?

              Posté par  (site web personnel) . Évalué à 1.

              T'as besoin de perl pour git-svn et quelques autres commandes. Le coeur de Git est en C, et il y a encore quelques scripts shell (mais la tendance est à les ré-écrire en C).

            • [^] # Re: Conversion transparente depuis et vers git ?

              Posté par  (site web personnel) . Évalué à 1.

              ici en vrai :

              3 binaires dans /usr/bin
              107 binaires dans /usr/libexec/git-core

              Ils ont tous les mêmes dépendances (bien réelles celles-là) :

              - linux-gate.so.1
              - /lib/libsafe.so.2
              - libcurl.so.4
              - libz.so.1
              - libcrypto.so.0
              - libc.so.6
              - libdl.so.2
              - libidn.so.11
              - libldap-2.3.so.0
              - librt.so.1
              - libssl.so.0
              - /lib/ld-linux.so.2
              - libpthread.so.0

              C'est à dire : glibc, zlib, openssl, curl, libidn, openldap, et c'est tout.

              Par ailleurs, il y a effectivement 21 scripts shell Bourne dans /usr/libexec/git-core, dont la plupart est rarement utilisée. Seuls 2 ou 3 sont utiles à un grand nombre.

              Il y a aussi 8 scripts Perl dans /usr/libexec/git-core, essentiellement des importeurs et des exporteurs vers d'autres systèmes de gestion de conf (cvs, svn, etc.)

              Il y a par ailleurs 2 programmes en TCL, mais ce sont des interfaces graphiques, Git est bien sûr utilisable sans.

              Enfin, il y a bien un Git.pm, mais c'est une interface pour utiliser Git à partir de Perl, et non l'inverse.

              Bref, pour une distribution qui adore tout découper en pitit packages, je suis surpris que Debian ait laissé traîner des dépendances vers Perl dans le package de base. Faudrait envoyer un patch.

      • [^] # Re: Conversion transparente depuis et vers git ?

        Posté par  (site web personnel) . Évalué à 1.

        Je trouve hg plus propre que git, c'est assez subjectif mais ...

        Déjà, savoir que git est fait en partie de script bash me fait peur (comprendre, est-ce que ça va bien marcher avec des noms de fichiers compliqués, contenant des espaces et caractères unicode ?).

        Ensuite, c'est d'avantage multiplateforme. Même si j'utilise exclusivement gnu/linux, je n'aime pas forcer le choix d'une plateforme (les OS libres peuvent aussi être autre chose qu'unix).

        Et puis, j'ai fait l'efort de lire complètement le manuel mercurial (parce que je voulais l'utiliser) et je comprend bien comment ça fonctionne. Il me semble que sur certains points de détail, git est différent, et ça peut être perturbant.

        Un repository git peut devenir très gros si on ne fait pas de git repack de temps en temps. Cela oblige à faire des opérations de maintenance régulièrement (et le repack peut prendre du temps). Par contre, un repository git repaqueté sera plus léger qu'un repository mercurial (l'avantage de l'inconvénient).

        • [^] # Re: Conversion transparente depuis et vers git ?

          Posté par  (site web personnel) . Évalué à 1.

          Déjà, savoir que git est fait en partie de script bash me fait peur (comprendre, est-ce que ça va bien marcher avec des noms de fichiers compliqués, contenant des espaces et caractères unicode ?).

          Je crois qu'il ne reste que git-pull comme commande régulièrement utilisée et écrite en script shell. En dehors de ça, il y a plus d'une centaine de commandes binaires, pour une vingtaine de scripts shell, la plupart étant anecdotiques. Et je ne vois pas en quoi il y aurait un problème avec des caractères Unicode, ou en quoi Python en aurait moins.

          Ensuite, c'est d'avantage multiplateforme.

          À peine.

          Un repository git peut devenir très gros si on ne fait pas de git repack de temps en temps.

          À préciser. C'est quoi très gros ? C'est quoi de temps en temps ?

          Beaucoup de peurs, d'incertitudes, et de doutes.

      • [^] # Re: Conversion transparente depuis et vers git ?

        Posté par  . Évalué à -1.

        http://whygitisbetterthanx.com/

        Voilà pourquoi, pour moi, Git est meilleur que Mercurial.

        • [^] # Re: Conversion transparente depuis et vers git ?

          Posté par  . Évalué à 2.

          Ça détaille pas pourquoi Mercurial est meilleur que Git (windows, taille du code, plugins, pas besoin de repack, protocole réseau firewall-friendly via http).

          • [^] # Re: Conversion transparente depuis et vers git ?

            Posté par  . Évalué à 2.

            Git fonctionne aussi bien que hg sous win. Il manque une interface graphique par contre, c'est ça le vrai problème.

            D'autre part, les pull fonctionnent par http.

            Tes autres arguments sont tout à fait valable (a part peut-etre le repack qui n'est pas très important)

Suivre le flux des commentaires

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