Mercurial : version 1.7 et petit tour d'horizon

Posté par . Modéré par patrick_g.
Tags :
27
12
nov.
2010
Python
Mercurial est un système de gestion de version décentralisé, multiplateforme et écrit en python. La première version publique est sortie le 19 avril 2005.

Mercurial fait partie des VCS (Logiciel de gestion de versions) libres reconnus à côté entre autres de Subversion et de Git dont il est assez proche. Le projet est sponsorisé majoritairement par les sociétés ou organisations suivantes : Google, Fog Creek (Stack Overflow), Microsoft, Jane Street Capital, Allston Trading, Mozilla, Symbian, Python, Atlassian.

La version 1.7 de mercurial est sortie le 1er novembre 2010. La majorité des changements est détaillée dans la suite de la dépêche. Les projets suivants utilisent mercurial (liste arbitraire) : Adium, Bitbucket, Dillo, Dovecot, Gajim, LibSDL, Mozilla, mutt, NetBeans, OpenJDK, OpenOffice, OpenSolaris, Python, SAGE, Symbian Platform, TortoiseHg, Vim, Wget, wmii, Xen, Xine.
On peut noter la présence de plusieurs projets bien plus anciens que 2005 et qui ont donc fait le choix de mercurial lorsqu'ils ont voulu améliorer l'efficacité de la gestion de leurs sources.

Pour ce qui est de ses outils, mercurial n'a rien à envier à ses concurrents. L'outil officiel en ligne de commande 'hg' est très abouti et agréable à utiliser.
Tortoisehg permet une intégration complète de mercurial de manière graphique dans Microsoft Windows en tant qu'extension shell. Il a été porté sur Gnome/Nautilus, est utilisable via pygtk, et est en cours de portage vers Mac OS X.
Le greffon Eclipse HGE permet l'intégration de mercurial dans l'IDE Eclipse alors que l'IDE Netbean prend en charge nativement mercurial.
Bien d'autres encore sont listés sur le wiki mercurial (oui oui ça peut aussi s'intégrer dans vim/emacs).

Quelques sites permettant l'hébergement gratuit de projets libres avec mercurial :

Du 8 au 10 octobre a eu lieu un long week-end de '1.7 Sprint' regroupant pas moins de 13 développeurs (dont 6 européens et 1 australien) dans les locaux de Google Chicago [14][15][16]. Au-delà du travail accompli sur la version 1.7, ce fut l'occasion pour les participants de partager leurs réflexions sur l'avenir de mercurial et les prochaines évolutions majeures.

Changelog de la version 1.7 (traduit partiellement) :

1/ Cœur

  • Évolution du format des dépôts 'dotencode' : amélioration de la gestion des noms des fichiers qui contiennent des espaces et des points.
    Également ajouté : une option expérimentale 'parentdelta' lors de la création d'un dépôt qui améliore l'efficacité de la compression des dépôts comprenant des branches dans leur historique. Voir [5] pour plus d'informations.

2/ Commandes

  • Ajout de la possibilité d'utiliser des commandes shell dans les alias.
  • Backout (Retour en arrière sur un lot de changement) : ajout de l'argument '--tool' pour spécifier l'outil de merge utilisé et choix du mode linéaire par défaut.
  • Merge : Ajout de l'argument '--tool' afin de spécifier directement l'outil que l'on souhaite utiliser.
  • templater : nouveau filtre 'hex' et mot clef 'children' pour les templates d'affichage.

3/ Sous-dépôts

Note : les sous-dépôts [6] sont une fonctionnalité qui permet de gérer un ensemble de dépôt comme un groupe. Le support de cette fonctionnalité est étendue à de plus en plus de commandes au fil des versions de mercurial.
  • Ajout de la possibilité de faire de la réécriture d'url sur les chemins des sous dépôts.
  • Ajout de la récursion dans les sous-dépôts pour les commandes add, diff, incoming, outgoing et status.
  • Ajout du support de la commande archive.

4/ Revsets

Note : Revsets est le nom donné au langage fonctionnel permettant de spécifier un ensemble de révision. Voir « hg help revsets ».
  • Ajout des opérateurs id et rev pour permettre des références explicites aux changements.
  • Ajout de la fonction min pour sélectionner le lot de changement avec le plus petit identificateur de révision.
  • Ajout de la fonction present pour éviter les erreurs de recherche.
  • Renommage de la fonction tagged en tag.
  • Ajout du support des revsets dans les commandes suivantes : strip, bisect, update.
  • bookmarks : ajout d'un revset bookmark pour référencer les bookmarks.
  • transplant : ajout d'un revset transplant pour avoir les révisions provenant d'un transplant.

5/ hgweb

    Ajout d'un lien vers la documentation intégrée.
  • Le mode HTTPS utilise maintenant une méthode de chiffrement permettant plus de compatibilité mais moins sécurisée.
  • Ajout d'un champ ETag dans les en-têtes HTTP pour améliorer la gestion du cache des pages.

6/ Extensions

  • color : meilleur support des branches et des mq guards.
  • convert : corrections de bugs, dépréciation de --authors pour --authormap.
  • graphlog : support des templates header/footer dans les styles.
  • keyword : support des commandes copy et rename. Ne s'étend plus durant les diff.
  • mq : extension du support de l'argument --mq pour les extensions de commande.
  • mq/qqueue : gestion du renommage des files d'attentes actives. Ajout de l'option --purge pour effacer une file et ses patchs.
  • pager : ajout de l'option globale --pager=.
  • patchbomb : ajout de l'option --confirm. diffstat n'affiche plus qu'une seule fois le résumé complet.
  • progress : support de rebase et patchbomb.
  • strip : ajout de l'option --keep pour éviter de modifier la copie de travail. Renommage de l'option --nobackup en --no-backup. Supporte maintenant plusieurs révisions.

7/ contrib

  • Ajout de vimdiff dans le script mergetools (script d'amélioration de la configuration pour certains outils de merge).
  • Amélioration de la complétion zsh

Et également diverses corrections de bogues, ajout et amélioration de performance.

Références :

1. http://mercurial.selenic.com/wiki/WhatsNew#A1.7_.282010-11-0(...)
2. http://fr.wikipedia.org/wiki/Mercurial
3. http://stackoverflow.com/about/management
4. http://hg-scm.org/sponsors/
5. http://mercurial.selenic.com/wiki/UpgradeNotes
6. http://mercurial.selenic.com/wiki/Subrepository
7. http://www.consortiuminfo.org/standardsblog/article.php?stor(...)
8. http://blog.bitbucket.org/2010/09/29/bitbucket-joins-atlassi(...)
9. http://tortoisehg.bitbucket.org/
10. http://tortoisehg.bitbucket.org/
11. http://javaforge.com/project/HGE
12. http://netbeans.org/features/ide/collaboration.html
13. http://mercurial.selenic.com/wiki/OtherTools
14. http://mercurial.selenic.com/wiki/1.7sprint
15. http://blog.bitbucket.org/2010/10/09/mercurial-1-7-sprint-in(...)
16. http://www.selenic.com/blog/?p=681
17. http://linuxfr.org/2010/06/17/27003.html
18. Mercurial chez TuxFamily.org
  • # Sismotherapie

    Posté par . Évalué à 5.

    Tutoriel et introduction à Mercurial (avec une rééducation pour les utilisateurs de SVN)
    La rééducation est à base d’électrochocs?

    Depending on the time of day, the French go either way.

    • [^] # Re: Sismotherapie

      Posté par (page perso) . Évalué à 3.

      On va dire que je commence ma ré-éducation...

      - Comment se comporte Mercurial avec les fichiers binaires ?

      - Au niveau de la gestion des droits du dépôt central, ça marche a peu près comme SVN ?

      Oui, je sais, c'est un gestionnaire dé-centralisé mais si on veut une référence, comment se passe la gestion des droits ?
      • [^] # Re: Sismotherapie

        Posté par . Évalué à 4.

        > Comment se comporte Mercurial avec les fichiers binaires ?

        Deux possibilités:
        - 'nativement' : les fichiers binaires sont détectés, et stockés 'comme ca'.
        - avec une extension (bfiles),

        J'ai pas essayé bfiles. Par contre, j'ai un fichier binaire conséquent (et qui évolue peu) dans mon repository, et Mercurial se démerde plutôt OK.

        > Au niveau de la gestion des droits du dépôt central, ça marche a peu près comme SVN ?

        Plusieurs solutions aussi :
        - authentification par le serveur http/https, si tu veux pousser par http/https
        - authentification par ssh, si tu veux pouser par ssh

        Pour ma part, http/https sont en lecture seule, et je pousse uniquement par ssh.
        • [^] # Re: Sismotherapie

          Posté par (page perso) . Évalué à 2.

          Avec SVN, je passe tout en https via deux filtrages :

          - via la configuration du serveur apache -> identification de la personne sur le serveur

          - via le fichier svnaccess -> autorisation de la personne pour un projet donné

          Les deux choses sont bien séparé et en pratique, c'est plutôt bien et facile à maintenir.

          J'avais éliminé le ssh pour ne pas avoir à gérer la problématique de l'accès physique au serveur.
      • [^] # Re: Sismotherapie

        Posté par (page perso) . Évalué à 2.

        Tu peux avoir une authentification par :

        * ssh
        * http

        Regarde par exemple les choix possibles sur bitbucket, tu comprendras.

        Pour information, il y a une application web nommée "RhodeCode" ( http://packages.python.org/RhodeCode/index.html ) qui permet créer / administrer un centre de dépôts avec gestion des utilisateurs / droits / dépôts privés / création / suppression… c'est pas mal. Dans ce projet, l'authentification se fait uniquement par http (pas de ssh).
  • # Très interessant

    Posté par . Évalué à 2.

    Merci pour la dépêche, très interessante et complète :).
    Je commence à me documenter un peu dessus car c'est ce que je souhaiterais utiliser chez moi pour mon dev, cette actualité tombe au meilleur moment.
    • [^] # Re: Très interessant

      Posté par . Évalué à -7.

      Un conseil : renseigne toi aussi sur Git ;)
      C'est à peu près pareil que Mercurial, sauf que ça marche. Bon ok je troll un peu :D

      J'utilise les deux au boulot, et pour moi ya pas photo :) je trouve Git plus agréable et plus fiable que HG.

      Donc je te conseille de comparer les deux avant d'en choisir un.
      • [^] # Re: Très interessant

        Posté par . Évalué à 1.

        Oui j'ai déjà commencé à me renseigner aussi sur git, il faut que je regarde bien les 2, mais à première vue hg me tenterait plus au premier abord.
      • [^] # Re: Très interessant

        Posté par (page perso) . Évalué à 0.

        > C'est à peu près pareil que Mercurial, sauf que ça marche. Bon ok je troll un peu :D

        Chez Mercurial marche très très bien.
        Idem pour Bazaar.
      • [^] # Re: Très interessant

        Posté par . Évalué à 7.

        > Un conseil : renseigne toi aussi sur Git ;)
        > C'est à peu près pareil que Mercurial, sauf que ça marche.

        De mon expérience, les différences entre Git et Mercurial, d'un point de vue pratique, sont :
        - pour un contributeur occasionel : la CLI de Hg est plus rapide à maitriser
        - pour un contributeur régulier : la CLI de Hg est plus simple à utiliser
        - pour le mainteneur : la paradigme Hg est plus rapide a comprendre, et maintenir le projet est plus simple.

        Alors bien sûr, ce n'est qu'un retour de mon expérience personelle à moi. YMMV, comme ils disent.

        Enfin, tout de même un trés gros bonus pour Mercurial : les MQ. Avec les MQ, le développeur maintient une serie de patchs par dessus le repository, et se ballade facilement avec des empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière, de recommencer, etc... sans avoir fait le moindre commit.

        Alors bien sur, on peut aussi faire ça avec Git, mais c'est plus compliqué. Il y a bien un utilitaire, stgit, mais il semble n'être plus maintenu, et n'est pas intégré 'de base' à Git, quand les MQ sont natives dans Mercurial.
        • [^] # Re: Très interessant

          Posté par . Évalué à 3.

          Je rajouterais que MQ permet également une fonctionnalité très populaire parmi les utilisateurs de Git: l'édition de l'historique (rebaser, modifier, supprimer, ajouter combiner des changesets, etc ...) et ce de manière beaucoup plus simple et sûre !
          • [^] # Question MQ

            Posté par . Évalué à 2.

            À propos de MQ et de son utilisation pour éditer l'historique, j'ai essayé récemment de modifier des commits très anciens (plusieurs heads créés depuis), et MQ refuse de toucher à l'historique sous prétexte qu'il comporte plusieurs branches filles. De mémoire, git rebase ne souffrait pas de ce genre de contraintes. J'ai également essayé avec l'extension histedit, mais elle bloque aussi. Est-ce normal ?
            • [^] # Re: Question MQ

              Posté par . Évalué à 2.

              Je ne sais pas de quoi tu parles exactement. MQ permet de modifier l'historique des patches gérés par lui, pas de n'importe quel morceau de l'historique du dépôt.
              (après, il se peut qu'il y ait des bugs)

              Ceci dit, il y aussi une extension "rebase" qui permet de faire la même chose que git rebase, sans l'aide de MQ.
              • [^] # Re: Question MQ

                Posté par . Évalué à 3.

                > MQ permet de modifier l'historique des patches gérés par lui, pas de n'importe quel morceau de l'historique du dépôt.

                Pardon, pardon, mais c'est (en partie du moins) possible :
                ---8<---
                # LC_ALL=fr_FR.UTF8 hg help qimport
                [...]
                Un "changeset" existant peut-être placé sous le contrôle de mq à l'aide de -r/--rev (par
                exemple qimport --rev tip -n patch placera la révision tip sous le contrôle de mq).
                [...]
                ---8<---

                Mais MQ travaillant sur une série de patches, je comprend qu'il ne soit pas possible de transformer un embranchement de l'arbre (merge ou branche) en patch. Il n'est pas possible de stocker dans un patch ce genre d'info.
            • [^] # Re: Question MQ

              Posté par . Évalué à 3.

              Comme son nom l'indique MQ ne gère qu'une file de patchs donc c'est le comportement normal.
              git rebase -i ne peut modifier l'historique que d'une seule branche, si tu touches à un commit partagés par plusieurs branches, ça revient à changer le parent de ta branche et à créer un nouveau commit en cas de modification. C'est toujours possible avec à l'aide de plusieurs files (hg help qqueue) ou des extensions rebase et transplant mais dans ce cas-là, c'est plus fastidieux qu'avec git.
              En même temps, ça reste cohérent avec la philosophie de mercurial qui déconseille l'édition de l'historique, comme on it: "there's no such thing as one size fits all".

              Quant à histedit, j'ai peu utilisé donc je ne peux pas dire grand chose à ce sujet.
        • [^] # Re: Très interessant

          Posté par . Évalué à 3.

          > Enfin, tout de même un trés gros bonus pour Mercurial : les MQ. Avec les MQ, le développeur > maintient une serie de patchs par dessus le repository, et se ballade facilement avec des
          > empilements/depilements (qpush/qpop). C'est très utile lorsqu'une modification est découpée
          > en plusieurs étapes : ca permet de tester un ensemble de changements de revenir en arrière,
          > de recommencer, etc... sans avoir fait le moindre commit.

          J'ai utilisé Hg pendant 2 ans au taff (maintenant c'est git) , ou on employé tous MQ massivement (on a du produire des centaines de patchs) donc je connais assez bien. MQ n'existe pas dans git... car c'est totalement inutile. La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.

          De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.

          Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper. Il est donc parfaitement conscient de ce type d'outil et ce n'est pas un hasard si cela n'existe pas.
          • [^] # Re: Très interessant

            Posté par . Évalué à 4.

            > MQ n'existe pas dans git... car c'est totalement inutile
            Tellement inutile qu'on a recréé des surcouches de Git pour gérer les patchs: stGit, Guilt (qui s'inspire directement des MQ) et bien d'autres.

            > La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
            Tu parles des branches légères ? hg help heads (si tu veux les nommer comme dans Git ==> extension standard bookmarks). Pour le reste, ça se vaut.
            Néanmoins, même si les branches légères permettent partiellement de pallier à l'absence d'un outil de gestion de patchs, ça ne les remplacent pas complétement.

            > De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
            MQ permet de versionner le dépôt de patchs (hg init --mq) pour permet de travailler en mode collaboratif.

            > Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper
            Linus a commencé à utiliser bitkeeper en 2002, quilt remonte à 2003 (les scripts d'Andrew Morton ont été publiés qui ont servi de base à quilt ont été publié en 2002). Chronologiquement, ça ne colle pas ton histoire.
            De plus, MQ c'est un quilt survitaminée et très bien intégré à hg, ça permet de réaliser des opérations avancés qui vont bien au-delà de la simple gestion de patchs comme la réécriture de l'historique (et ce bien mieux que Git !). Les extensions de Mercurial permettent d'offrir un noyau simple à appréhender sans pour autant brider les utilisateurs avancés qui activent uniquement ce dont ils ont besoin.

            > Il est donc parfaitement conscient de ce type d'outil et ce n'est pas un hasard si cela n'existe pas.
            La demande d'un outil de gestion des patchs intégré à Git revient régulièrement dans les Git Surveys, donc ça contredit ton affirmation "Nan, on n'a pas besoin de ça".
            • [^] # Re: Très interessant

              Posté par . Évalué à 5.

              Si ça peut vous aider à vous mettre d'accord :
              Vous voulez faire des trucs patch-oriented ? Tournez-vous vers darcs !
              • [^] # Re: Très interessant

                Posté par . Évalué à 2.

                Je l'ai étudié un peu et effectivement le concept général est intéressant, notamment le "cherrry pecking naturel".
            • [^] # Re: Très interessant

              Posté par . Évalué à 0.

              >> MQ n'existe pas dans git... car c'est totalement inutile
              > Tellement inutile qu'on a recréé des surcouches de Git pour gérer les patchs: stGit, Guilt
              > (qui s'inspire directement des MQ) et bien d'autres.

              Qui "on" ? Pas les développeurs de Git.

              > La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
              >> Tu parles des branches légères ?

              Je ne vois pas que c'est une "branche légère" dans Git. Ca c'est une formulation Hg.

              >> Note: MQ est une copie de Quilt, l'outil utilisé par... Linus torvalds avant de passer à BitKeeper
              > Linus a commencé à utiliser bitkeeper en 2002, quilt remonte à 2003 (les scripts d'Andrew
              > Morton ont été publiés qui ont servi de base à quilt ont été publié en 2002).
              > Chronologiquement, ça ne colle pas ton histoire.

              Quilt n'est qu'une évolution des scripts utilisés par les développeurs du noyau (avant BitKeeper, ils avaient bien un outil et ce n'était pas CVS).

              > La demande d'un outil de gestion des patchs intégré à Git revient régulièrement dans les
              > Git Surveys, donc ça contredit ton affirmation "Nan, on n'a pas besoin de ça".

              Les gens demandent aussi des poneys roses.


              Perso j'arrête la la discussion, le prosélytisme aveugle, ca me gonfle rapidement. Hg a des avantages intéressants sur Git, mais surement pas dans la capacité de gérer un DAG ou de revoir un historique. Mais pour cela, il faut connaitre les 2 outils.
              • [^] # Re: Très interessant

                Posté par . Évalué à 2.

                ce qui est amusant c'est qu'il va devoir s'y mettre a git vu que Fedora passe dessus...
                • [^] # Re: Très interessant

                  Posté par . Évalué à 2.

                  ça fait déjà quelques années que je m'y suis mis, et j'ai même été un des béta-testeurs de dist-git.
                  Pour info, mon Git-fu est aussi bon que mon hg do.
              • [^] # Re: Très interessant

                Posté par . Évalué à 1.

                Vu que tu as l'air de bien connaître les deux, je serais intéressé de savoir pourquoi vous êtes passé de Hg à Git.

                Merci.
              • [^] # Re: Très interessant

                Posté par . Évalué à 3.

                > Qui "on" ? Pas les développeurs de Git.
                Shawn Pearce (2ème commiter dans Git devant Linus) avait écrit un quilt-like (abandonné depuis) et récemment Petr Baudis (TopGit). StGit et Guilt sont maintenus par des contributeurs de moindre importance.

                > Je ne vois pas que c'est une "branche légère" dans Git. Ca c'est une formulation Hg.
                Même pas, on parle de heads dans le jargon mercurial, les branches "légères" est un terme générique pour désigner les branches au sein d'un même clone, les branches "lourdes" désignant eux les clones.

                > Quilt n'est qu'une évolution des scripts utilisés par les développeurs du noyau (avant BitKeeper, ils avaient bien un outil et ce n'était pas CVS).

                Andrew Morton a publié ces scripts en 2002 - à l'époque où Linus a décidé d'utiliser BitKeeper - et c'était très rudimentaire.
                http://lwn.net/Articles/13518/

                > Les gens demandent aussi des poneys roses.
                Si deux développeurs majeurs de Git ont proposés des surcouches pour gérer cette fonctionnalités, c'est peut-être pas si stupide que ça.

                > Perso j'arrête la la discussion, le prosélytisme aveugle, ca me gonfle rapidement
                >> La gestion des branches est tellement plus avancée que cette fonctionnalité n'est pas utile.
                >> De plus, MQ est utile quand on est seul, mais devient intenable pour du travail collaboratif.
                C'est très bien de reconnaitre ses erreurs.

                > Mais pour cela, il faut connaitre les 2 outils.
                Je plusse.
      • [^] # Re: Très interessant

        Posté par (page perso) . Évalué à 5.

        plus fiable ? quels sont les problemes de fiabilité de mercurial ? je n'en ai jamais rencontré mais si il y en a j'aimerais les connaitre, ça serait sympa que tu partages tes connaissances..
        • [^] # Re: Très interessant

          Posté par . Évalué à 3.

          Par expérience, je dirais qu'il est beaucoup plus facile de se tirer une balle dans le pied avec Git qu'avec Mercurial ne serait-ce qu'à cause de l'interface utilisateur complexe du premier.
      • [^] # Re: Très interessant

        Posté par . Évalué à 1.

        Je pense que en realite on peut resumer:

        Ancien utilisateur de SVN utilisait hg
        Neophyte faites vos tests mais je soupconne que pour une utilisation "premier abord" les deux se valent.

        Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
        • [^] # Re: Très interessant

          Posté par . Évalué à 3.

          > Neophyte faites vos tests mais je soupconne que pour une utilisation "premier abord" les deux se valent.
          Rien que le fait de pouvoir travailler hors-ligne (et par conséquent de meilleures performances), la gestion des branches, et un merge fonctionnel, on peut oublier les antiquités tels que CVS ou même SVN.

          > Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
          idem pour mercurial ...
        • [^] # Re: Très interessant

          Posté par . Évalué à 3.

          Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
          J'ai failli te plusser, mais quand j'ai lu cette phrase que j'interprète comme "git ne se traîne pas le passif de SVN, alors que hg se le traine", et bien j'ai eu très envie de t'inutiler car c'est complétement faux. J'ai réussit a résister malgré tout.
          Hg, tout comme Git, est basé sur des concepts totalement différents de CVS et SVN et ne se traîne aucun passif.

          Par ailleurs, SVN ne traîne aucun passif de CVS. Ils ont juste choisit de faire un VCS centralisé (comme CVS), mais ils ont fait table rase de tout le reste et n'hésitent pas a remettre en cause des choix faits dans les versions précédentes de SVN. Maintenant le modèle centralise ne correspond peut être pas a ton workflow ou a celui du libre, mais ca correspond encore a celui de beaucoup de personnes.
    • [^] # Re: Très interessant

      Posté par . Évalué à 4.

      Sinon, un bon tutoriel (en anglais) : http://hginit.com/
      Je le trouve plus clair que le hg book, il introduit assez bien les notions.
      • [^] # Re: Très interessant

        Posté par . Évalué à 2.

        J'approuve, c'est ce site qui m'a permis de sauter le pas et de quitter SVN !

        Yth.
  • # Extension maison

    Posté par . Évalué à 3.

    Un gros plus de Hg est la possibilité de développer des plugins maison, et cela *trés* simplement (merci Python). C'est quelque chose que j'ai perdu en passant à Git (faut wrapper la sortie, pas top) et cela me manque.
  • # Sites d'hébergement mercurial : lesquels sont libres ?

    Posté par . Évalué à 3.

    C'est bien de lister des services d'hébergement en ligne de répertoires, mais j'aimerais savoir lesquels sont libres : je cherche un service dont les sources sont disponibles, et qui permette la création d'instances locales si je le souhaite.

    Côté git, j'utilise gitorious plutôt que github pour cette raison. J'ai regardé rapidement BitBucket, et je n'ai vu nulle part d'indication sur un éventuel code source disponible (donc j'imagine que ce n'est pas libre).

    Ce n'est pas du tout basé sur des raisons pragmatiques (en local j'utilise de simple repos darcs/git/whatever, la plus value de l'hébergement en ligne c'est l'accès facile en lecture par tout le monde), mais je trouve absurde de dépendre d'un logiciel propriétaire pour diffuser ses projets libres...
  • # Directory rename et merge

    Posté par . Évalué à 2.

    Est ce que vous connaissez un outil qui permette la chose suivante:
    - Dans trunk (ou main), j'ai un répertoire "dir"
    - Je crée la branche A a partir de trunk
    - Dans trunk, je renomme le répertoire "dir" en "rep"
    - Dans la branche A, j'ajoute un fichier "file" au répertoire "dir". Le numéro de révision est 10378.
    - Quand je merge la révision 10378 de la branche A vers trunk, voici ce que je veux obtenir: le fichier "file" est ajouté au répertoire "rep" de trunk.


    Aucun des VCS que j'ai testé ne permet ca automatiquement:
    - SVN refuse cela et me repond "tree conflict"
    - Git l'accepte, mais me crée un fichier "file" dans le répertoire "dir" sur trunk (alors que je voulais ce fichier dans le répertoire "rep")
    - D'après ce que j'ai lu sur Mercurial, qui ne se rappelle pas des répertoires, je ne pense pas que ca marcherait. Mais je ne sais pas ce que ca fait.
    - Avez vous d'autres idées d'outils?
    • [^] # Re: Directory rename et merge

      Posté par . Évalué à 2.

      Ca marche avec Clearcase !

      Désolé :O)
      • [^] # Re: Directory rename et merge

        Posté par . Évalué à 2.

        Ah ben bravo!! C'était même pas vendredi!

        Ici, je parle seulement d'utiliser des gestionnaires de code source qui n'ont pas besoin d'un bataillon d'administrateurs pour les gérer.
    • [^] # Re: Directory rename et merge

      Posté par . Évalué à 3.

      Plus sérieusement, ce workflow fonctionne très bien avec hg.
      Je viens de tester.
      • [^] # Re: Directory rename et merge

        Posté par . Évalué à 3.


        Since Mercurial's rename is implemented as copy-and-remove, the same propagation of changes happens when you merge after a rename as after a copy.

        If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to "simply work", but not all revision control systems actually do this.)

        Whereas having changes follow a copy is a feature where you can perhaps nod and say "yes, that might be useful," it should be clear that having them follow a rename is definitely important. Without this facility, it would simply be too easy for changes to become orphaned when files are renamed.


        http://hgbook.red-bean.com/read/mercurial-in-daily-use.html

        Ceci s'applique aussi aux répertoires.

        En revanche, j'ignorais que git ne savait pas le gérer correctement.
        • [^] # Re: Directory rename et merge

          Posté par . Évalué à 3.

          Ce que tu cites au dessus, je l'avais lu et a aucun moment ca ne parle de répertoires renommés. C'est pour ca que j'ai posé la question.

          En revanche, j'ignorais que git ne savait pas le gérer correctement.
          Je te raconte pas la déception par rapport aux fameuses heuristiques tant vantées par Linus Torvalds. J'avais vraiment envie de dire bullshit!
          M'enfin j'avais teste avec msysGit (ou un truc dans le genre) sous Windows, alors peut être que ca a été corrige depuis, mais ca a été tellement la galère pour l'installer. Ajout d'un patch pour le faire marcher etc.
          • [^] # Re: Directory rename et merge

            Posté par . Évalué à 2.

            Je suis en train d'étudier une migration depuis Clearcase vers un autre vcs en ce moment et Hg marque des points.
            Mais si ce que tu affirmes est vrai, le choix sera vite fait.
            • [^] # Re: Directory rename et merge

              Posté par . Évalué à 2.

              Je ne sais pas qui sont tes utilisateurs, mais avec Hg tu n'as pas besoin d'apprendre a tes utilisateurs comment fonctionne le stockage de Git. Changer le paradigme me semble déjà assez difficile a assimiler. Ça dépend de tes utilisateurs encore une fois.

              Je décline toute responsabilité quand a l'interprétation de mes résultats car ca remonte a quelques temps, et je pourrais avoir loupé un détail important. Moralité, fait ton propre test, et n'hésite surtout pas a me donner tes conclusions.
          • [^] # Re: Directory rename et merge

            Posté par . Évalué à 2.

            Au fait, je testerai avec JGit à l'occasion et je te ferai un petit compte-rendu si tu es intéressé.
          • [^] # Re: Directory rename et merge

            Posté par (page perso) . Évalué à 3.

            > peut être que ca a été corrige depuis
            non, j'ai fait le test avec un git 1.7.3 et le workflow du dessus (renomer dir en rep dans le tronc puis merge après ajout d'un fichier au répertoire dans une autre branche) ne fonctionne pas avec git.
            Rien que pour ce point git tombe pas mal par rapport à mercurial (même s'il faut avouer que c'est pas non plus un cas hyper fréquent).
            Entre ça, l'intégration dans eclipse, dans windows mercurial va devenir mon choix de scm, du moment qu'on comprend comment mercurial gère les heads (sans ça c'est compliquer mercurial...)
            • [^] # Re: Directory rename et merge

              Posté par . Évalué à 2.

              Que reproche tu à EGit par rapport à HGE ?

              Il me semble que le développement est très actif en ce moment et que ca évolue vite.
              • [^] # Re: Directory rename et merge

                Posté par . Évalué à 2.

                Il me semble que le développement est très actif en ce moment et que ca évolue vite.
                J'avais cru voir que la fondation Eclipse passait a Git, et donc le travail sur EGit est très prioritaire pour eux.
            • [^] # Re: Directory rename et merge

              Posté par . Évalué à 2.

              même s'il faut avouer que c'est pas non plus un cas hyper fréquent
              Pour nous c'en est un: passage d'une base de code monolithique a des sous projets avec déplacement de répertoire a la clé. Et c'est même plutôt chiant quand les vieilles branches vivent des lustres. C'est increvable ces trucs la!
      • [^] # Re: Directory rename et merge

        Posté par . Évalué à 2.

        Excellent, je n'avais pas eu l'occasion d'essayer.

        Il ne me reste plus qu'a trouver comment lier Mercurial a svn comme Git sait le faire.
    • [^] # Re: Directory rename et merge

      Posté par (page perso) . Évalué à 1.

      Ça ne marche pas avec Git parce que jusqu'à il y a peu, personne n'avait pris la peine de coder la détection des renommages de répertoires (et c'est très dommage). La détection automatique des renommages, ça a l'avantage de pouvoir améliorer l'outil sans toucher au format de stockage, mais ça a l'inconvénient que les cas non codés dans l'outil ne sont pas gérés ;-).

      Bonne nouvelle : il y a une série de patchs en préparation pour ajouter ça :

      * yd/dir-rename (2010-10-29) 5 commits
      - Allow hiding renames of individual files involved in a directory rename.
      - Unified diff output format for bulk moves.
      - Add testcases for the --detect-bulk-moves diffcore flag.
      - Raw diff output format for bulk moves.
      - Introduce bulk-move detection in diffcore.
      • [^] # Re: Directory rename et merge

        Posté par . Évalué à 3.

        Moi ca me laisse surtout une impression d'usine à gaz comme tout le reste qui vient avec git (melting pot de langage, CLI complexe et brouillonnes, customs en shell, ...)

Suivre le flux des commentaires

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