Bitbucket, qui est une forge de dépôts Git et Mercurial, a annoncé en août dernier la suppression des dépôts Mercurial de ses utilisateurs dès le premier juin 2020.
C'est une annonce qui n'a pas été très bien accueillie, mais bitbucket prétend vouloir se concentrer sur Git, car selon une étude américaine, il y a 90% des développeurs qui utilisent Git, contre 3% qui utilisent Mercurial. De plus, les nouveaux dépôts Mercurial créés sur Bitbucket ne concernent plus que 1% des projets. Ce qu'ils ne disent pas en revanche, c'est quel est le pourcentage de dépôts Mercurial au total hébergés chez eux, en effet, historiquement Bitbucket ne proposait que Mercurial, et c'est face à la montée de Github et de Git qu'ils ont rajouté le support de ce dernier. Ainsi, on peut imaginer que cette fermeture impactera une part non négligeable de leurs utilisateurs actuels.
On peut également imaginer qu'en supprimant simplement ces dépôts (au lieu de juste les figer), quelques projets open source qui ne sont plus maintenus vont ainsi totalement disparaître. Ce sont des milliers de ligne de code libre qui vont cesser d'exister.
Si vous avez des dépôts mercurial chez eux, il faudra donc envisager une migration, soit vers une autre forge, soit vers git et rester chez bitbucket. Je ne crois pas qu'ils aient développé d'outils spécifique pour migrer facilement un dépôt chez eux (ce qui énerve d'autant plus quantité de développeurs, surtout ceux qui payent et qui se sentent encore plus lésés).
Pour ma part, j'ai quelques dépôts en Git, et quelques autres utilisant Mercurial. Je n'ai rien contre Git, et pour mon utilisation assez basique, je ne trouve pas vraiment beaucoup de différence entre les deux, il y a des commandes assez similaires (clone, commit, push, pull…).
J'aime bien chez Mercurial la possibilité de monter avec juste une commande ("hg serve") un serveur mercurial fonctionnel, en local, qui permet de voir graphiquement les commit depuis un navigateur web, et de faire des push et pull depuis un autre ordinateur. Rien que pour ça, et pour la pluralité des solutions, je veux rester avec Mercurial.
Je trouve github plus pratique au niveau des interactions envers les autres utilisateurs (fork, pull request etc), et surtout vu qu'ils y a peut-être 90% des développeurs sur github ou gitlab, et 3% chez Bitbucket, en utilisant la même logique qu'eux, je pense que cela ne vaut plus la peine de rester chez eux, je suis donc en train de déplacer mes dépôts ailleurs.
Chez github il y a un outil d'import, je viens de le tester, ça fonctionne bien (mais ne garde pas le bugtracker) : https://github.com/new/import
Gitlab propose également des outils d'importation, mais je n'ai pas testé.
Pour ma part je suis parti chez le mal-aimé Sourceforge, et pour garder tout mon historique des commits mercurial, j'ai simplement :
- créé un projet chez SF
- récupéré l'adresse du dépôt, et remplacé dans le .hg/hgrc du projet sur mon disque dur, la ligne
default = https://login@bitbucket.org/login/projet
par
default = ssh://login@hg.code.sf.net/p/projet/code
Ensuite il suffit de taper "hg push", et ça recréera tout dans le nouveau dépôt !
# .
Posté par Sufflope (site web personnel) . Évalué à 5.
Y compris les tickets / le wiki / … ou c'est comme les outils d'import de gitlab/hub c'est très incomplet ? (question rhétorique)
[^] # Re: .
Posté par zurvan . Évalué à 4.
non, c'est juste la partie gestionnaire de version, donc seulement l'historique des commits, le reste est perdu. Il y a peut-être d'autres possibilités pour les récupérer, mais cela ne me concerne pas trop donc je n'ai pas cherché plus loin.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: .
Posté par claudex . Évalué à 4.
En même temps, Atlassian vend Confluence et Jira pour le wiki et les tickets.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: .
Posté par zurvan . Évalué à 4.
Justement, c'est bizarre parce que les utilisateurs de mercurial qui payent vont devoir tout migrer sur git ou partir ailleurs.
Ce n'est pas impossible que d'ici quelques mois ils sortent un message façon "on vous a entendu, on garde finalement mercurial". Mais d'ici là pas mal de monde sera parti. Je ne comprends pas leur logique…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: .
Posté par claudex . Évalué à 5.
Ou alors, il n'y a pas assez d'utilisateurs mercurial qui payent pour ce que ça leur coûte.
Ensuite, tu peux très bien avoir tes sources hébergées ailleurs et avoir Confluence et Jira.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: .
Posté par Eh_Dis_Mwan . Évalué à 4.
Le message le dit bien au dessus, l'important n'est pas d'avoir beaucoup de client, mais d'avoir une "EBITDA positive" et des marges élevées.
Ce pré requis est valide tant pour les entreprise qui ont levé des quantité de fonds , que des entreprises ayant tenté une IPO.
Il faut rassurer les investisseurs, et donc eur présenter des chiffres rassurant (marge de 40% etc…)
Hypothèse:
Mercurial neccessitait des moyens humains et materiel assez onéreux (salaires etc…) par rapport à e que ça rapportait, et du coup ils se concentrent sur git qui doit être moins cher et leur rappporter plus de marges
Hypothèse 2:
Tu es un boulanger, tu vends tous type de viennoiserie, avec 2 chef boulangers, l'un fabriquant des croissantss t des pains au chocolat, et l'autres des viennoiseries exotique (Baklava, Struddle).
LEs viennoiserie exotique representent 1% de to CA mais représente 50% des ta masse salariale :
Que fais tu ?
[^] # Re: .
Posté par zurvan . Évalué à 8.
Certes, mais ça peut être dangereux de raisonner simplement ainsi. Imaginons que je sois un gros client de la boulangerie, j'achète chez eux pour 99 € de viennoiserie traditionnelle chaque semaine, mais mon petit plaisir c'est d'acheter de temps à autre des baklava (pour 1 € par semaine). Lorsqu'ils vireront le chef qui les fabrique, et bien je n'aurais plus spécialement l'intérêt d'aller dépenser mes 99 € chez eux et je pourrais aller dans une autre boutique à la place…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: .
Posté par Anthony Jaguenaud . Évalué à 0.
Si tu es le seul qui fait ça, 99€ * 4 = 386€… Ça ne fait ni un salaire net, encore moins brut et surtout pas avec les charges patronales.
Si tu es seul à faire ça, tant pis. Si vous êtes 10, alors ça annule le tout. Et encore on a pas parlé du coup de la matière première…
Donc tu feras comme les utilisateurs de mercurial, tu changeras de
crémerieboulangerie.[^] # Re: .
Posté par Anonyme . Évalué à 10.
Les cotisations sociales.
[^] # Re: .
Posté par Eh_Dis_Mwan . Évalué à 4.
Peu importe s'ils ont beaucoup de client par ailleurs et que tu ne représente q'un faible pourcentage du C.A. (d'où l'interêt des contrats dit "premium")
Je demande non de se mettre à la place du client , mais du boulanger.
C'et aussi ça que des corporation font reorg sur reorg: non qu'elles vont mal, mais les investisseurs veulent que le retour sur investissement se fasse plus rapidement.
Ce point de vue peut être imaginé:
Tu as un pote chomeur de longue durée qui a un projet en tête , et qui te demande de la thune (hstoire vécu: un pote qui n'a pas bossé deouis 2012 m'a demandé des fonds pour acheter un moulin à eau pour faire tourner des mineurs de bitcoin) : crois tu que tu aura la patience d'attendre 15 ans qu'il te rende tes 2 k€ ?
(C'est aussi pour ça que je crois moyennement au modèle start up: une personne qui s'endette en debut de vie est vraiment mal partie dans la vie)
[^] # Re: .
Posté par Anonyme . Évalué à 0.
Qui n’a pas été employé depuis 2012.
[^] # Re: .
Posté par Tonton Th (Mastodon) . Évalué à 4.
Là, vite, la nimage qui va bien :
[^] # Re: .
Posté par groumly . Évalué à 3.
On peut aussi donner au mecs de bitbucket le benefice du doute, partir du principe qu'ils ont analysé la liste des clients payants impactés par le changement avant de supprimer leur produit historique.
A priori j'ai envie de dire que la plupart des clients payants sont des entreprises, et que le nombre d'entreprises utilisant a la fois git et mercurial est assez bas, et que celles qui le font sont probablement au milieu d'une migration de mercurial a git.
et que donc ya assez peu de chances que mercurial soit un "petit plaisir du samedi", qui est un concept qui se transpose plutot mal au produit que bitbucket vend en premier lieu.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: .
Posté par zurvan . Évalué à -1. Dernière modification le 14 janvier 2020 à 08:10.
oui mais bon, c'était une remarque d'ordre général, on associe souvent à une activité le seul rapport brut des "revenus" visibles, alors qu'elle peut également être génératrice de bénéfices associés que ne voit pas forcément de prime abord.
Et puis, il ne faut pas déconner, si les clients montent des projets chez bitbucket, ce qui "coûte" surtout, ça va être de l'espace disque, si ce n'est pas utilisé par mercurial, ça le sera par git. On ne peut d'ailleurs pas dire que "ça coûte le double" de devoir supporter à la fois git et mercurial. Au pire ça prendra un peu de ressources CPU en plus de supporter un gestionnaire de version supplémentaire, et un peu de temps pour les mises à jour. Je pense que les grandes têtes pensantes de Bitbucket ont juste voulu bêtement rationaliser les ressources, et vu qu'ils sont loin de github en matière de popularité, ça va juste éroder un peu plus la confiance de leurs clients dans leurs services.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: .
Posté par claudex . Évalué à 7.
Non, l'espace disque (surtout pour des dépôts de code), ça ne coûte "rien". Ce qui coûte, ce sont les développements. Et actuellement, à chaque fonctionnalité, ils doivent vérifier que ça fonctionne avec git et hg et trouver un workaround pour hg si ça ne marche pas (pour git aussi, mais actuellement, ils ne peuvent pas vraiment s'en passer). Il y a aussi toute la partie sécurité. Je pense que côté git, il y a pas mal de gens qui y regarde (ailleurs que chez bitbucker). Alors que côté hg, ils doivent prendre un risque plus élevé (ou avoir beaucoup de personne en interne sur le sujet.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: .
Posté par zurvan . Évalué à -3.
bah, dans ce cas-là, ils n'avaient qu'à rester avec mercurial, et ne pas inclure git quelques années plus tard, histoire de "singer" github.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: .
Posté par Psychofox (Mastodon) . Évalué à 2.
La question n'est pas de singer qui que ce soit mais de proposer un produit qui convient au plus grand nombre.
Qu'on le veuille ou non git bat mercurial en popularité et à moins qu'un autre projet révolutionne totalement le monde des outils de versionnement il va rester le leader dans ce domaine et celui qui sera connu par le plus grand nombre comme l'a été cvs à une époque pas si lointaine.
# Possibilité de contournement
Posté par Claude SIMON (site web personnel) . Évalué à 8.
Il est possible de continuer à utiliser mercurial et de rester sous Bitbucket. Il existe en effet un plugin mercurial qui permet de répercuter de manière transparente les push/pull sur un dépôt mercurial vers un dépôt git.
Je l'utilise tous les jours, certes dans un seul sens (mercurial vers git), mais je n'ai jamais rencontré de problèmes…
Le plugin en question : https://hg-git.github.io/
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Possibilité de contournement
Posté par zurvan . Évalué à 5. Dernière modification le 12 janvier 2020 à 10:51.
alors c'est ce que j'ai essayé en premier, mais j'ai eu pas mal de bugs (certains sont listés là https://dev.heptapod.net/mercurial/hg-git/issues) et du coup je me suis dit que j'allais passer trop de temps à trouver des contournements. C'est dommage parce que j'aime bien l'idée.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# software heritage
Posté par Jarvis . Évalué à 5.
Peut-être que le projet software heritage sauvegarde le code bitbucket :
https://www.softwareheritage.org/
[^] # Re: software heritage
Posté par gasche . Évalué à 7. Dernière modification le 12 janvier 2020 à 10:30.
Oui, il semble que Software Heritage archive bien Bitbucket. Pour avoir cet information, je suis allé sur leur page de démonstration https://archive.softwareheritage.org/browse/origin/https://github.com/torvalds/linux/visits/, et j'ai remplacé l'URL par celle d'un projet Bitbucket, https://archive.softwareheritage.org/browse/origin/https://bitbucket.org/genericcontainer/goblin-camp/, et "ça marche", ça semble bien avoir été archivé (Snapshot date: October 13, 2019).
[^] # Re: software heritage
Posté par zurvan . Évalué à 3.
Ah oui, c'est génial ce truc. On peut faire une recherche plain text ici : https://archive.softwareheritage.org/browse/
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
# Migration
Posté par Obsidian . Évalué à 8.
C'est bien ça le pire, je crois.
J'ai moi-même encore un dépôt Mercurial là-bas, après être moi-même passé à Git pour tous mes autres projets pour et mes versionings en local de mes documents, parce que c'est une collaboration de longue date avec une personne qui est encore sous Mercurial et parce que je l'utilisais aussi au moment où j'ai ouvert le dépôt. C'est même ça qui m'a conduit vers BitBucket.
Quand ils en ont annoncé la fin, j'en ai simplement pris acte à titre personnel. Comme dit plus haut, ça faisait longtemps que je ne l'utilisais plus ailleurs. Par contre, je m'attendais à avoir la même chose qu'ailleurs, à savoir un gros bouton « je migre mon dépôt vers Git », que ce soit fait en une fois et que l'on n'en parle plus.
J'ai été assez surpris de ne pas trouver immédiatement de référence vers la procédure à suivre, et assez agacé de me rendre compte, au bout de quelques pages de lecture, que leurs recommandations se résumaient en gros à « bah démerdez vous, je crois qu'il existe un truc par là pour le faire mais pas sûr… ». Du coup, s'il faut se débrouiller soi-même pour tout migrer et qu'il faut rouvrir un nouveau dépôt à la main, aucun intérêt en particulier de rester chez eux plutôt qu'ailleurs.
Seule exception à ce dernier point : la possibilité d'avoir un dépôt privé. C'est utile quand on collabore à développer des choses qui s'appuient sur des ressources non libres. Mais la politique des autres hébergeurs a évolué également depuis cette époque et même Github propose des dépôts privés gratuits jusqu'à trois collaborateurs.
# Serveur git?
Posté par gnumdk (site web personnel) . Évalué à -4.
Moi j'aime bien avec git le fait de ne pas avoir besoin de serveur, c'est ce qui fait toute la souplesse et la puissance de git. Au final, tout peut être un serveur git même si seul https/ssh sont implémentés.
Pour la partie exploration graphique, j'utilise gitg mais je suis sûr qu'il existe des outils graphiques moins GNOME et plus puissants que ce dernier.
[^] # Re: Serveur git?
Posté par David Demelier (site web personnel) . Évalué à 7.
C'est aussi le cas, Mercurial est aussi un SCM distribué. Chaque dépôt est identique, il n'y a pas de « dépôt serveur » ou « dépôt client ».
La commande
hg servepermet simplement de parcourir ce dépôt avec une interface web et pouvoir tirer/pousser dessus depuis une autre machine.git is great because linus did it, mercurial is better because he didn't
[^] # Re: Serveur git?
Posté par GaMa (site web personnel) . Évalué à 2.
Il existe aussi
git instaweb(un script simplifiant le lancement de gitweb).Par contre le paquet correspondant n'est pas obligatoirement installé par défaut par les distrib (je suppose à cause des dépendance à perl).
Et ça offre une vue qu'en lecture seule.
Matthieu Gautier|irc:starmad
[^] # Re: Serveur git?
Posté par Psychofox (Mastodon) . Évalué à 2.
Je ne suis pas fondamentalement certains que ces trucs sont d'une grandes utilités en local. La plupart des ide fournissent une visualisation assez facilité de ton repo de toute manière.
Les interfaces web c'est surtout intéressant en ligne pour découvrir des projets auxquelles on voudrait contribuer ou quand on reçoit un lien pour valider une merge-request.
[^] # Re: Serveur git?
Posté par Obsidian . Évalué à 2.
Moi j'utilise tig, en ligne de commande. C'est utilisable dans un terminal et c'est plus pratique qu'un simple
git log --graph. Et je confirme qu'il faut au minimum un outil de ce genre pour être efficace avec un SCM… surtout quand on apprend !L'avantage de celui-ci est qu'il agit comme un front-end pour Git et qu'on peut lui passer toutes les options que l'on utiliserait avec l'outil original, par exemple
--first-parent.# Sourcehut
Posté par -mat . Évalué à 10.
Pour ceux qui veulent garder mercurial, SourceHut accueille les réfugiés de Bitbucket. Je n'ai pas encore fais le pas, mais pour l'instant c'est là que je pense héberger mes dépôts mercurial.
# Au revoir mercurial
Posté par Philippe F (site web personnel) . Évalué à 7.
C'est quand même un sacré pas coup pour mercurial. Pour rappel, bitbucket ne gérait que mercurial aux origines.
C'est dommage, j'ai toujours trouvé mercurial mieux foutu que git à l'utilisation. Mais année après année, on sent bien qu'il se fait écraser…
[^] # Re: Au revoir mercurial
Posté par David Demelier (site web personnel) . Évalué à 4.
Je suis assez d'accord.
BitBucket était un temple de Mercurial. Notre part de marché a largement réduit mais contrairement à ce qu'on pourrait penser Mercurial n'est pas en reste et nous avons une bonne centaines de contributions par jour y compris de Mozilla et Facebook.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Au revoir mercurial
Posté par zurvan . Évalué à 3.
Longue vie à Mercurial :)
Très intéressant ton article ici à ce propos : http://markand.fr/pourquoi-je-prefere-mercurial.html
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Au revoir mercurial
Posté par Philippe F (site web personnel) . Évalué à 5.
Je connaissais pas cet article mais c'est tout à fait ce que j'en pense. On peut aussi citer le nombre incalculable de commandes de git, ou le fait que le nommage est "à chier" au sens où les commandes ne font pas forcément ce qu'indique le nom de la commande.
Après, Git a gagné, GitHub a gagné aussi en terme de popularité, c'est irratrappable. Mais quand je vois à quel point on pleure dans ma société pour réussir à utiliser Git, j'ai de la peine. Comme disaient les vieux barbus "worse is better" a gagné.
[^] # Re: Au revoir mercurial
Posté par Anonyme . Évalué à 3.
Vu que tu ne donnes pas d’exemple, je reprends l’article de David Demelier :
git branch <branch>(pour la créer seulement)git switch -c <branch>(pour la créer et changer la branche courante automatiquement)git restore <file>git switch <branch>[^] # Re: Au revoir mercurial
Posté par barmic 🦦 . Évalué à 2.
Tout ça n'est apparu qu'il y a quelques mois et n'est pas encore intégré partout (notamment pour l'auto complétion par exemple). À tel point que si on regarde la doc on peut lire :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Au revoir mercurial
Posté par Sufflope (site web personnel) . Évalué à 5.
En réalité il y a une certaine logique dans les commandes historiques git selon qu'elles ne touchent que les refs, ou le working tree, etc. D'ailleurs c'est assez parlant, ta citation est "fausse" : créer une branche a toujours été git branch, git checkout -b est un raccourci pour changer le working tree vers une nouvelle branche que l'on crée à la volée.
Je reconnais que c'est pas forcément évident, mais bon d'expérience la plupart des problèmes que j'ai vu les gens avoir avec git étaient liés au fait qu'ils ne voulaient pas lire la sortie standard qui expliquait en long et en large sur dix lignes comment continuer leur tache en cours. J'espère que la "simplification" ne viendra pas au prix de perte de puissance ou de cohérence (que l'on peut voir si on veut bien se donner la peine de se former 1h sur son nouvel outil).
[^] # Re: Au revoir mercurial
Posté par Anonyme . Évalué à 5.
Complètement d’accord avec ça.
[^] # Re: Au revoir mercurial
Posté par Philippe F (site web personnel) . Évalué à 6.
Tu me rassures.
Un autre exemple, c'est que sur pas mal de SCM, la commande "revert" permet d'annuler les modifs en cours. Sauf que Git a choisi cette commande pour un usage légitime mais différent. Ca crée de la confusion, en plus du reste. On récemment ajouté la commande "restore" qui est arrivé pour pallier au fait que revert se faisant avec "checkout --" mais même là, il va falloir du temps avec que tout le monde se l'approprie.
Une autre difficulté avec Git, c'est la présence de l'index. Du coup, toute la documentation est assez complexe à lire puisque chaque commande peut avoir un effet soit sur l'index, soit sur le working tree, soit parfois directement sur le stockage. Perso, je me penche très régulièrement sur la doc et au bout de deux minutes, je suis perdu entre les 3 zones d'effet. Quand je vois mes collègues qui connaissent très peu git lire la doc, ils sont encore plus perdus que moi. Bien que celle-ci se veille complète et précise, elle est hyper difficile d'accès.
J'ai plusieurs fois perdu des changements, et aidé des collègues à récupérer des changements presque perdus tellement Git est complexe à utiliser.
Le plus ironique, c'est que une grande partie de la complexité provient de l'aspect décentralisé alors qu'en entreprise, le développement est hyper centralisé et hyper hierarchique. Bref, perso, SVN ça m'allait très bien.
Il n'y a que les tracking branches que je trouve sympa comme concept, et manquant dans mercurial.
[^] # Re: Au revoir mercurial
Posté par Sufflope (site web personnel) . Évalué à 3. Dernière modification le 16 janvier 2020 à 22:49.
Bah voilà encore un exemple, revert (en tout cas sa version SVN si mes souvenirs sont bons) ne se fait pas avec ckeckout -- (au passage le "--" n'est vraiment utile que pour des fichiers que tu n'as même plus dans ton tree) mais avec reset. Enfin, en fait, les deux si on veut. Parce que revert n'a pas d'équivalent exact puisque git a une staging area et selon que tu veux "finalement ne plus commit mais garder le changement" ou "remettre comme sur l'index"…
Alors oui c'est de la complexité en plus mais pour quoi ? Bah pour éviter le merdier infâme de SVN de "si tu veux commit ton travail en cours tu ne dois avoir en diff que ce que tu veux commit et tout sera commit". L'un dans l'autre, je préfère devoir apprendre git que garder svn.
Ah oui ça c'est ma spécialité en entreprise depuis 10 ans. 99% du temps parce que Monsieur Dame la Diva Dév. n'a pas daigné lire la sortie standard puis a lancé au pif une vingtaine de commandes trouvées au hasard sur internet (je le sais, je dois remonter dans l'historique shell pour comprendre comment ils ont bien pu merder autant).
On pourra arguer qu'un outil doit être "utilisable". Oui, et on peut arguer qu'un dev pas capable de lire la sortie standard de son outil (je ne parle pas de la comprendre ; je dis bien pas capable de la lire) n'est pas un dev.
J'ai utilisé anecdotiquement hg. Bah j'ai eu du mal, j'ai pesté parce que je n'arrivais pas si bien qu'avec git (et j'ai rigolé quand j'ai lu le man ; y a genre 2 fois plus de commandes haut-niveau que dans git, et chacune (à première lecture en tout cas) redondante avec 1 ou 2 autres, alors quand après on me parle des commandes absconses de git…) mais je me suis pas dit que c'était un outil naze, juste que je le maitrise pas.
[^] # Re: Au revoir mercurial
Posté par El Titi . Évalué à 2.
Je te propose de faire la combinatoire des commandes Hg … avec leurs options et son équivalent pour les commandes git de haut niveau. Parce qu'une commande avec le même nom qui fait 10 trucs différents, tu vois quoi. Heureusement qu'il existe git alias
[^] # Re: Au revoir mercurial
Posté par Anonyme . Évalué à 3.
La plupart du temps je m’embête pas : je sors
git refloget jegit reset --hardau moment où le code était valide selon le dev.[^] # Re: Au revoir mercurial
Posté par AnthonyRabine (site web personnel) . Évalué à 2.
Attend on a failli avoir subversion en grand gagnant, on s'en sort bien.
[^] # Re: Au revoir mercurial
Posté par David Demelier (site web personnel) . Évalué à 3.
Merci beaucoup :)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Au revoir mercurial
Posté par Albert_ . Évalué à 3.
Un des problèmes majeurs de mercurial c'est qu'ils ont trainés des pieds pour passer a python 3 et aujourd'hui python 2 est ou va bientot etre obsolète…
La décision peut aussi etre une decision technique!
PS: à une époque j'ai hésité entre git et mercurial et à l'usage la facon de faire de git me convenait mieux que celle de mercurial et pourtant faisant plus du python je penchais au depart plus pour mercurial.
PPS: récemment j'ai vu que calibre est en train de passer à Python 3 et pourtant le dev disait pendant longtemps qu'il préfererait maintenir lui meme une version de python 2 plutot que de faire la conversion…
[^] # Re: Au revoir mercurial
Posté par Anonyme . Évalué à 5.
Ça fait des années que Python 2 est obsolète. Par contre ça fait 15j que c’est officiellement plus maintenu.
[^] # Re: Au revoir mercurial
Posté par barmic 🦦 . Évalué à 2.
Par la communauté python upstream. RedHat continue de maintenir les paquets de ses distributions quelques années encore ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Au revoir mercurial
Posté par El Titi . Évalué à 3.
Peti REX du mainteneur: https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.