Journal Matt Mackall, l'auteur de Mercurial, passe la main

Posté par  . Licence CC By‑SA.
Étiquettes :
32
26
jan.
2016

Après 11 ans sur le projet, l'auteur indique être à temps plein dessus y compris certaines nuits et week-end et qu'il est donc temps de passer à autre chose.

Mais conscient de l'importance du projet il va prendre le temps nécessaire à la transition, jusqu'au 1er novembre.

https://www.mercurial-scm.org/wiki/mpm/transition

Évidement il va être difficile de ne pas relier cette décision à la perte de popularité de Mercurial par rapport à Git.

Personnellement ça me touche beaucoup, j'utilise Mercurial tous les jours sans regret mais je me retrouve de plus en plus souvent obligé d'utiliser Github et jongler sur deux dvcs n'est pas une gymnastique qui me plaît beaucoup.

  • # Développement centralisé

    Posté par  . Évalué à 10.

    En fait, le développement de Mercurial est très centralisé : la liste donnée sur le wiki montre bien que Matt Mackall est actuellement l'unique responsable pour beaucoup d'infrastructures et d'opérations vitales pour le projet. Cette déconcentration du développement est bienvenue.

    Quant à l'implication de Matt, à lire cette page (certes succincte), je n'ai pas l'impression qu'il cessera de développer Mercurial (il est d'ailleurs payé pour ça, à ma connaissance).

    • [^] # Re: Développement centralisé

      Posté par  . Évalué à 2.

      Quant à l'implication de Matt, à lire cette page (certes succincte), je n'ai pas l'impression qu'il cessera de développer Mercurial (il est d'ailleurs payé pour ça, à ma connaissance).

      Je crois bien que si, le but pour lui est d'arreter que Mercurial soit son boulot. Ce qui ne veut pas dire que les boites qui financent actuellement le developpement vont arreter, l'employeur actuel de Matt devrait continuer de contribuer au developpement.

    • [^] # Re: Développement centralisé

      Posté par  . Évalué à 6.

      Cela ne serait-il pas lié à python3. D'après ce que j'ai compris mercurial à un peu de mal à faire la transition.

  • # Popularité

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

    Le départ de Matt n'a aucun impact sur la popularité de Mercurial. Mercurial a toujours été largement moins répandu que Git déjà parce que Git a eu un succès populaire avec GitHub et parce que son système de branche est efficace. Qu'il soit fait par Linus Torvalds lui donne probablement une étiquette supplémentaire.

    Je suis fan de Mercurial, je m'en sers depuis environ 2008 et je m'en sers toujours, c'est mon DVCS au quotidien. Mercurial a des défauts mais il a aussi tellement d'avantages.

    • TortoiseHg, le workbench, juste magnifique et exactement la même interface sur chaque plateforme !
    • La portabilité est importante,
    • Simplicité, les commandes sont courtes avec une documentation claire net et précise,
    • Mise en place d'un serveur de dépôts, avec hgweb.cgi environ 5 lignes de configuration,
    • Léger, le core fait la plupart des choses, les extensions fournies avec peuvent compléter,
    • KISS, hg revert | update | branch vs git checkout,
    • Un seul langage, Python. Git : bash, perl, C, …
    • hg incoming | outgoing,
    • hg serve,
    • hg heads,
    • hg summary.

    Malgré tout, j'avoue que GitHub est particulièrement pratique pour collaborer.

    git is great because linus did it, mercurial is better because he didn't

    • [^] # Re: Popularité

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

      incoming et outgoing avec ou sans fetch

      in = !git fetch && git log --pretty=oneline --abbrev-commit --graph ..@{u}
lin = log --pretty=oneline --abbrev-commit --graph ..@{u}
lout = log --pretty=oneline --abbrev-commit --stat --graph @{u}..
out = !git fetch && git lout

      serve

      serve = daemon --reuseaddr --verbose  --base-path=. --export-all ./.git

      • [^] # Re: Popularité

        Posté par  . Évalué à 3.

        Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.

        hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
        De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.

        Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
        Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
        Ce que je comprends c'ets qu'avec hg cette posdibilité est indispensable car dès que l'on pull en récupère inmmanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark).
        Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.

        J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.

        • [^] # Re: Popularité

          Posté par  . Évalué à 3.

          Je reposte puisque je ne peux pas "passer":

          Je passe sur le coté abscons de cette commande mais sauf erreur de ma part ce n'est pas équivalent au hg incoming.

          hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.
          De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.

          Après il est vrai qu'au final ça revient au même. Il faudra bien fetcher les commits à un moment ou à un autre.
          Peut-être qu'un afficionados de Hg pourrait nous expliquer ce que ça apporte vraiment ?
          Ce que je comprends c'est qu'avec hg cette possibilité est indispensable car dès que l'on pull en récupère immanquablement des "heads" qui vont polluer notre branche (hg heads) car on ne différencie pas les branches locales et de suivi (sauf à utiliser des plugins type bbookmark). Une branche hg est plutôt un "flux" de développement qui à un moment donné, fait qu'on a plusieurs version concurrentes (plusieurs têtes en même temps) du même flux. un dépôt git, n'a qu'une référence pour une branche à tout moment (d'où les précautions avec le -force qui peut déplacer une tête et perdre de l'historique).

          Avec Git on peut soit puller soit fetcher et comparer avant de merger ou rebaser.
          J'ai comme l'impression que ce qu'on nous vend comme une "feature" est plutôt lié à un choix d'architecture du fait que les branches locales n'existent pas et que l'on différencie.

          • [^] # Re: Popularité

            Posté par  . Évalué à 2.

            Ca montre le problème qu'il y a à utiliser les deux systèmes. Ca n'est pas tant qu'il y en ait un mieux que l'autre mais on essaye de retrouver des équivalences de commandes là où il y a une différence de conception…
            J'utilise hg incoming pour le côté centralisé, pour voir si mon collègue à fait quelque chose ou pas. Si j'ai besoin de savoir exactement ce qu'il a fait je fais hg incoming -patch, ça me permet de voir exactement ce qu'il a fait, visuellement, sans rien récupérer. Je m'en sert également pour voir si mes librairies (en subrepos) sont à jour ou pas.
            Inversement j'utilise push pour mettre à jour des applis en ligne. Avec outgo je peux savoir où j'en suis.

            • [^] # Re: Popularité

              Posté par  . Évalué à 6.

              Ca montre bien les limites du modèle.

              Avec git, tu fetches sa branche et tu utilises tous les outils à ta disposition pour faire ta comparaison, checkout y compris (build, …). et tu n'intègres que si tu le souhaites avant de pusher sur le "serveur". Tu peux laisser le soin de l'intégration à un autre et tu peux vérifier et communiquer sur vos changements respectifs (CI) sans pollution.

              Avec hg, soit tu en passes par ta technique, comme un palliatif pour communiquer. Soit tu pulles et tu te retrouves avec 2 heads à résoudre, forcé à intégrer, si le serveur oblige à n'avoir qu'une seule head pour pouvoir lancer la CI.

              C'est pour ça que beaucoup finissent par utiliser les plugins qui adoptent le comportement à la git, je pense.

        • [^] # Re: Popularité

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

          hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.

          Étant donné que sous Git il faut fetcher pour récupérer ces commits, même si ce n'est pas exactement la même chose que sous mercurial ça fait le job.

          De tes 2 alias le premier fait un fetch et le second considère que tu as tout en local sans checker le dépôt distant.

          Oui, le l est pour local dans chacun des alias

          Après ces alias sont quand même très simple.
          Si je prend lout qui est celui que j'utilise le plus souvent dans cette liste :

          lout = log --pretty=oneline --abbrev-commit --stat --graph @{u}..

          --pretty=oneline --abbrev-commit --stat --graph ne sont que des commandes de mise en forme mon log. En gros ça permet d'avoir un arbre (et donc de visualiser les branches), de n'avoir que la première ligne du message de commit et d'avoir les stats sur les changements.
          La seule chose vraiment intéressante est @{u} qui correspond à la branche d'upstream.
          La commande demande donc le log (avec mise en forme) de la différence entre la branche upstream (depuis le dernier fetch) et la version qui est dans ma copie de travail.

          Genre :

          ❯ git lout
* b48c7f0 Plop
* 42144f6 Update mk
|  iOS.mk | 51 +--------------------------------------------------
|  1 file changed, 1 insertion(+), 50 deletions(-)
* 60ea549 Update readme
   Makefile | 1 +
   1 file changed, 1 insertion(+)

          Où je vois que je peux pousser sur mon upstream une branche contenant deux commit qui a été mergée.

        • [^] # Re: Popularité

          Posté par  . Évalué à 2. Dernière modification le 28 janvier 2016 à 00:08.

          hg incoming permet de récupérer la liste des commits entrant SANS les fetcher vraiment et communique avec le dépôt distant.

          C'est pas parce que ça se voit pas qu'il ne le fait pas. hg incoming fait exactement la même requête au serveur que hg pull: getbundle. Le code python de mercurial est capable de demander les heads sans faire un getbundle, mais je sais pas s'il y a une commande pour le faire. hg -R repourl heads se plaint quand repourl est pas un répertoire local, ce qui est plutôt ballot. En python, on peut faire hg.peer(repourl).heads() ou un truc comme ça.

          Avec git, git remote show et git ls-remote donnent des informations sur le repo distant sans fetcher.

          • [^] # Re: Popularité

            Posté par  . Évalué à 3.

            Merci pour ces éclaircissements.

            Ma réflexion ne portait pas sur le fait que git communique ou non avec les autres dépôts qu'au travers des synchronisations. Je sais que les commandes dont tu parles existent mais elles n'ont pas la même finalité.
            Ma remarque portait plutôt sur le fait que certains pensent que le hg incoming est un plus par rapport à Git alors qu'en fait cette commande vient juste pour rendre cohérente la conception de Hg.

            Hg n'intègre pas de part sa conception, le fait de séparer la synchronisation des dépôts de l'intégration avec son code (merge).
            Ceci à l'avantage de la simplicité dans certains cas mais peut s'avérer plus contraignants dans d'autres. Du coup cette commande pour inspecter les commits du dépôt distant est indispensable pour le bon fonctionnement de hg alors qu'elle ne l'est pas pour Git.

            A l'inverse, le modèle de git est plus complexe à maîtriser. Combien de nouveaux venus sur Git qui ne comprennent pas la différence entre un git pull et un git fetch merge|rebase réclament cette commande ou sont rassurés de pouvoir browser le serveur avant de se synchroniser.

            Une partie de la complexité de Git provient aussi du fait que ce qui est implicite pour Hg a dû faire l'objet de
            beaucoup de contorsions et de balbutiements pour automatiser de manière acceptable le pull et faire le match entre l'upstream et le local alors que pour Hg … c'est juste la même branche.
            En témoigne par exemple les évolutions successives sur les set-upstream, la config des refspecs et plein d'autres paramètres qu'il faut bien souvent tuner. Ou comment les git users se transforment en bookmarkeurs de Stackoverflow compulsifs:
            http://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-upstream-all-the-time
            http://stackoverflow.com/questions/10002239/difference-between-git-checkout-track-origin-branch-and-git-checkout-b-branch
            …

Suivre le flux des commentaires

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