Sous ce titre, écrit dans la langue de la perfide Albion Shakespeare, se cache le récit d'une migration de Git vers Mercurial accompagnée d'une amélioration, assez impressionnante dois-je dire, des performances de Mercurial.
Il semblerait, en effet anéfé, que le dépôt contenant le code-source de Facebook soit plusieurs fois plus volumineux que celui du noyau Linux (déjà, rien que ça, ça m'a fait lever un sourcil qui n'est toujours pas redescendu…). Et qui dit "projet volumineux" dit "importance de la scalabilité (c'est quoi la bonne traduction française ?) des outils".
C'est pourquoi les développeurs de Facebook se sont demandés s'il valait mieux améliorer les performances de Git (qu'ils utilisaient à ce moment-là) ou migrer vers Mercurial et améliorer ses performances.
Le choix retenu est bien évidemment le second (si vous ne l'aviez pas deviné, relisez le titre de ce journal…) et le récit, long et détaillé, est lisible sur ce billet sur ce blog : https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
N'ayant jamais utilisé Mercurial et n'étant pas un Guru de Git, je ne me permettrai pas de commenter ce qui y est dit, mais je suis curieux d'avoir l'avis des uns et des autres sur les choix faits (dont l'usage de Watchman et remotefilelog ) et si quelqu'un se sent d'en faire un journal, qu'il ne se gène pas !
# Mercurial vu par Facebook
Posté par Carl Chenet (site web personnel) . Évalué à 9.
Je réagis car, étant utilisateur de Mercurial par exemple dans le projet Brebis, j'ai été véritablement passionné par cet article qui va un peu à l'encontre de l'engouement actuel autour de Git. Ceci étant dit, on comprend très bien que, ayant eu dès le départ l'idée d'étendre Mercurial pour couvrir leur besoin, Facebook ait privilégié Mercurial codé en Python qui peut être ressenti plus "accessible" que Git quand on veut entrer dans le code, leur but n'étant pas de développer un business-model autour mais juste de faire converger Mercurial vers leurs besoins.
Dans tous les cas je recommande chaudement la lecture de l'article. C'est un bel exemple de comportement gagnant-gagnant entre un projet libre et une entreprise. Et juste une petite phrase extraite de cet article pour l'illustrer :
"To narrow this performance gap, we've contributed over 500 patches to Mercurial over the last year and a half."
Quand même.
[^] # Re: Mercurial vu par Facebook
Posté par cosmocat . Évalué à 9.
Lorsque j'ai lu l'article il y a quelques jours, j'en suis en fait sorti moins passionné que toi ;)
Le (presque) seul point positif que je tire de cet article c'est que du fait que Mercurial soit écrit en Python et qu'il est bien architecturé, il est facilement extensible.
Pour ce qui est de la solution mise en place par facebook, je pense qu'elle n'apportera RIEN à presque tous les utilisateurs de Mercurial. Outre le fait que cela s'applique à des dépots dont la taille est rencontré que très peu souvant, la solution adopté a été de couper avec la spécificité des DVCS d'être, justement, distribués et d'utiliser des serveurs memcache . Une architecture que presque personne n'utilisera…car s'il faut maintenant installer des serveurs memcache pour pouvoir avoir des meilleurs perfs avec mercurial, on est pas sorti de l'auberge.
Donc j'ai vine peur que la plupart des utilisateurs ne voient aucune amélioration en ce que le concerne…
L'idée derrière Watchman pour détecter les changements est par contre plutôt bonne mais pourrait aussi être utilisé par git…
[^] # Re: Mercurial vu par Facebook
Posté par Albert_ . Évalué à 2.
L'idée derrière Watchman pour détecter les changements est par contre plutôt bonne mais pourrait aussi être utilisé par git…
Beau defi a git, je me demande dans combien de temps ils vont rattraper mercurial sur les quelques points ou celui ci le bat.
[^] # Re: Mercurial vu par Facebook
Posté par Lutin . Évalué à 5.
Mercurial bat Git à plate couture sur la facilité d'utilisation, tu penses que Git vas le rattraper la dessus ?
[^] # Re: Mercurial vu par Facebook
Posté par Albert_ . Évalué à 10.
Si l'on regarde la popularite de git il est en effet clair que c'est tres difficile d'utilisation surtout pour des developpeurs.
[^] # Re: Mercurial vu par Facebook
Posté par Lutin . Évalué à 6.
Disons que la courbe d'apprentissage est plus rude que pour Mercurial (c'est un avis personnel).
(Et ça doit être comme vim/emacs, une fois qu'on maitrise il doit être bien dur de s'en passer).
[^] # Re: Mercurial vu par Facebook
Posté par Anonyme . Évalué à -1.
Moi je ne trouve pas, j'ai eu beaucoup plus de mal à apprendre à utiliser Mercurial que git.
Peu etre que pour une utilisation très limitée, Mercurial est plus simple, mais c'est tout.
Je pense que la difference, c'est que dans git le fonctionnement interne est visible, alors que dans Mercurial c'est un peu plus caché. Et pour bien utiliser un gestionnaire de version, il faut à mon avis savoir comment il fonctionne.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 9. Dernière modification le 10 janvier 2014 à 16:55.
J'utilse Git au quotidien et je l'enseigne à des …novices.
Je peux te dire qu'il est tout sauf intuitif.
Hg est beaucoup plus simple à comprendre car dispose d'un ensemble de commandes plus restreint, d'une interface en ligne de commande plus consistante et d'un ensemble de concepts plus restreint et moins complexe.
Pas besoin de comprendre les références locales et distantes avec Hg, pas de remote à comprendre hormis la branche active et la commande hg path. Pas besoin d'explique les detached head et le GC, pas besoin d'expliquer que les références sont comme les spaghettis de la belle et la bête que pour connaitre l'historique ou cloner une branche il suffit de tirer une nouille et tout vient avec.
Pas besoin d'expliquer la différence entre pull et fetch, entre pull avec merge ou rebase.
Pas besoin d'expliquer le fast-forward
Pas besoin d'expliquer les différence entre les options du reset.
…
Attention je ne dis pas que Git est moins bien je l'utilise (et je l'ai choisi par raison plutôt que par coeur pour toute ma boîte …), mais il n'est pas plus simple non.
[^] # Re: Mercurial vu par Facebook
Posté par Sufflope (site web personnel) . Évalué à 2.
Je comprends pas trop.
Si tu veux voir ce que devient ton remote (genre git log origin/master), hg devine tout seul que tu parles de la branche master remote, et pas de ton dépôt local ?
On peut pas « explorer » les remote hormis la branche active ?
Gnééé pourquoi expliquer le GC à des débutants ?
Sous hg pas moyen de voir l'historique remote à moins de pull ??
hg choisit magiquement pour toi ? ou le rebase n'existe pas, peut-être.
Je vois même pas ce qu'il y a à expliquer (à part le principe basique d'un outil de versionning, quoi)
Là encore, hg comprend magiquement ce que tu veux faire ?
J'hésite quoi penser : soit hg est vraiment très fort à tout deviner à ma place, soit on peut rien faire avec hg.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 4.
Non, mais tu ne vois 200 références dans ton historique graphique.
Tous les commits portent la même reference de branche et le tien c'est le commit courant checkouté.
Si tu veux les distinguer avec plusieur remote "hg path"
Pas besoin d'expliquer que le pull enchaîne automatiquement fetch+merge (au sens git merge ou git rebase).
Pas de rebase par défaut (c'est un plugin) et pas de config sur la branche pour pull (merge ou rebase).
Après, je ne sais pas comment est supporté le rebase aujourd'hui pour Hg
Déjà y'a pas d'index par défaut avec Hg. Je l'avais oublié celle-là (Pas facile de convaincre de l'intérêt à des codeurs Java qui utilisent une vue Synchronise ou qui clique droit dans le projet et voientt les fichiers à commiter s'afficher déjà cochés et pas les autres.
Pis c'est tellement logique de rajouter à l'index pour marquer des conflit comme résolus pour des gens qui ont l'habitude d'utiliser un commande svn resolve, pour "resoudre" un conflit
Et après,
-- mixed, en fait ma bonne dame ca empile les commits intermédiaires et ca vous met ca dans le workspace
et --soft dans l'index, Logique.
Allez savoir pourquoi:
Ben parce que en plus --mixed, en plus il écrase l'index donc faut bien mettre ca queqpart.
[^] # Re: Mercurial vu par Facebook
Posté par marmoute (site web personnel) . Évalué à 6.
hg incoming # command vielle de 8 ans
Rebase fait parti de la distribution standard. Il à la même niveau de support que le reste de Mercurial. Il est ajouté 10 lettre dans ta config pour y avoir accéés.
Rebase a un bon support dans Mercurial et s'en sort même mieux que git dans des cas tordus ou tu veux préserver des merges et ne pendre qu'une partie de l'historique (rare, certes)
Jamais comprit l’intérêt d'avoir un concept supplémentaire pour l'index quand on peut faire exactement là même chose avec de bon outils pour amend le changeset en cours.
Mercurial à interface utilisateur simple et claire pour ça. Rien particulièrement différent chez tout le monde.
Faux, il est possible de spécifier une branche particulière dans tes path (équivalent de git remote)
Bref: ce qui est bien avec de débat c'est que chacun à une connaissance superficiel de l'autre outil mais est quand même persuadé qu'il est inférieur.
[^] # Re: Mercurial vu par Facebook
Posté par Anonyme . Évalué à -1. Dernière modification le 10 janvier 2014 à 18:23.
Ca depend pour qui. Pour des novices qui veulent en faire une utilisation basique, peu etre. Pour les gens qui veulent comprendre comment fonctionne leur gestionnaire de version, git me semble plus simple à comprendre.
Par exemple un "git cat-file -p <commit>" permet de voir exactement et comprendre ce que represente un commit. L'equivalent dans hg m'a l'air difficilement accessible.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 4.
Petite question entre nous.
Ca intéresse qui, novice ou pas, de savoir comment est foutu un commit à part pour être sûr de passer pour celui qui y est à un dîner le mercredi soir ?
Un dev il a autre chose à faire qu'à comprendre ce qu'est un blob, un tree ou un commit.
Heureusement, on leur a épargné ça à nos devs.
J'avais oublié la plomberie et la porcelaine.
[^] # Re: Mercurial vu par Facebook
Posté par Anonyme . Évalué à -1.
Ca permet de comprendre les concepts utilisés par git, et voir qu'ils sont finalement très simples. Une fois qu'on a vu ca, on comprend beaucoup mieux le principe des differentes commandes.
Sauf à vouloir se contenter de fonctionnalités très basiques, c'est utile de savoir comment ca fonctionne pour mieux l'utiliser.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 8.
Et à mon avis la popularité de Git vient avant tout de son gourou.
Lorsqu'on a fait le choix pour ma boité il y a 2 ans maintenant, c'était un pari.
Je trouvais Hg mieux foutu (surtout sous Windows, plugin Eclipse excellent) mais avec l'adoption du projet Eclipse nous savions que Git finirait par l'emporter.
En bons moutons de Panurge, on a suivi mais tous les soirs je me gave de cachetons pour oublier que j'ai fait Hg cocu avec une plus moche mais mais plus riche.
Bon! On aurait pu passer sous SVN aussi … Ouf
[^] # Re: Mercurial vu par Facebook
Posté par Philippe F (site web personnel) . Évalué à 6.
Bon, nos expériences sont différentes.
D'une part, j'utilise mercurial et subversion depuis des années dans avoir jamais eu besoin de comprendre comment ils fonctionnent en interne.
D'autre part, je viens de perder 2h de ma vie à vouloir faire l'équivalent de la commande "svn revert" sous git pour contribuer à un projet Open Source. Sous mercurial, c'est "hg revert". Au final, n'ayant toujours rien compris aux histoires de tambouille, interne, j'ai installé un client git graphique propriétaire (SmartGit) et j'ai finalement réussi à accomplir le miracle.
Git a gagné la guerre des SCM distribués, mais c'est pas pour le meilleur des mondes. "Worse is better", ca rappelle quelque chose aux vieux barbus ?
[^] # Re: Mercurial vu par Facebook
Posté par Sufflope (site web personnel) . Évalué à -2.
C'est vrai que git revert c'est compliqué.
[^] # Re: Mercurial vu par Facebook
Posté par Sufflope (site web personnel) . Évalué à 0.
Je me suis gouré ça ne fait pas la même chose. Vous pouvez moinsser.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 2. Dernière modification le 10 janvier 2014 à 17:53.
C'est pas toi le gars qui m'a refait la leçon un peu plus haut sur Hg que ca fait tout n'importe comment.
Allez je ne t'en veux pas. Tu connais pas Hg et t'as oublié SVN.
Pense aux autres qui souffrent en silence, aussi.
[^] # Re: Mercurial vu par Facebook
Posté par Sufflope (site web personnel) . Évalué à 0.
Quel rapport entre les limitations d'hg (pas de rebase par exemple) et le fait que je me sois gouré de commande ?
[^] # Re: Mercurial vu par Facebook
Posté par Antoine . Évalué à 1.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 1.
C'est de base dans Hg maintenant.
J'ignorais.
[^] # Re: Mercurial vu par Facebook
Posté par Albert_ . Évalué à 0.
Lorsque je lis les commentaires des utilisateurs de Mercurial c'est generalement:
Hg le fiat comme SVN, hg le fait … maintenant sous entendu que ca fait des annees que cela est present dans Git.
En gros, si j'ai bien suivi Mercurial a implemente la grande majorite des idees de Git (et inversement) mais cela a pris beaucoup de temps et pour quelqu'un comme moi qui utilise Git depuis des annees je ne vois vraiment pas l'interet de changer. Lorsque j'ai decide d'utiliser Git plutot que Mercurial c'est en raison des branches que je trouvais beaucoup plus dans ma philosophie cela n'existait pas dans Mercurial a l'epoque.
C'est super Mercurial, meme Torvalds le dit mais bon chacun ses choix et globalement c'est techniquement la meme chose de facon un peu differente. Et si l'un prefere conduire une voiture verte et l'autre une voiture bleu pourquoi tenter de convaincre que une couleur et mieux que l'autre?
[^] # Re: Mercurial vu par Facebook
Posté par barmic . Évalué à 3.
Je ne suis pas un spécialiste de mercurial, mais j'ai l'impression que toutes les « limitations » (entre guillemets parce que souvent c'est juste que ce n'est pas fait de la même façon et que du coup ça ne plaît pas) date d'il y a tout de même quelques années. Je présume que les gens les plus suivi on fait le switch vers du DCVS libres à ce même moment et que leur critiques perdures encore.
Mais j'ai l'impression que la grande différence entre git et mercurial c'est que le premier et vraiment conçu pour la vitesse, demande très peu de configuration, il arrive avec tout de base et peut devenir vraiment très compliqué (certains arrivent dans des situations où ils ne s'en sortent pas et perdent un bout de leur travail, d'autres n'utilisent plus que
rebaseparce que la plupart des autres commandes ne servent à rien). mercurial me semble demander un peu plus de configuration (il faut activer des plugins), mais c'est une modularité appréciable quand on voit qu'il y a des plugins originaux qui viennent se gréfer (cf : le journal ou les phases).Après à mon avis il est surtout bon de voir de la diversité. SVN laisse doucement place à une foule d'alternatives (git, mercurial, darc, monotone ou celui dont j'ai plus le nom que devnewton apprécie particulièrement). C'est positif.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mercurial vu par Facebook
Posté par Albert_ . Évalué à 2.
C'est un peu ce que je dis mais cela semble "impertinent" de dire que les deux projets sont plus ou moins similaire avec une philosphie d'utilisation legerement differente.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 4.
Que l'embarras du choix tue le choix parfois.
Hg se focalise sur la simplicité et propose des extensions pou ce qui est avancé là où Git en fait trop.
Et pour le rebase:
http://mercurial.selenic.com/wiki/MqExtension
http://mercurial.selenic.com/wiki/RebaseExtension
Je connais des développeurs qui ne supportent pas le rebase.
Tu gagne en lisibilité de l'historique certes, mais parfois le rebase fait un merge qui peut interférer avec ce que tu développais. Si tu corriges un conflit de merge sans maitriser ce que tu as réimporté ou si un conflit sémantique est introduit (http://martinfowler.com/bliki/SemanticConflict.html) tu n'as plus de traces de ton code initial.
Donc l'intétêt n'est pas évident pour tout le monde?
Si on était pas Vendredi, je dirais que Git est au VCS ce que Perl est aux langages
[^] # Re: Mercurial vu par Facebook
Posté par marmoute (site web personnel) . Évalué à 3.
Mercurial n'est pas plus limité que git. Ton exemple Rebase est fournit avec Mercurial depuis 2008…
La quantité de méconnaissance dans ce débat l'aide beaucoup à virer au troll. (J'ai entendu mon coussin à entendu chef le coiffeur deux personnes qui disait que Emacs n'avait pas de coloration syntaxique. C'est sûrement vrai!)
[^] # Re: Mercurial vu par Facebook
Posté par claudex . Évalué à 4.
Ça c'est quand même de la mauvaise foi, Google est rempli de réponse pour ça, ça ne prend pas 2h mais 2 minutes (c'est git checkout ou git reset --hard en fonction de si on veut s'attaquer à un seul fichier ou à tout le projet).
« 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: Mercurial vu par Facebook
Posté par Troy McClure (site web personnel) . Évalué à 4.
bel exemple de la cohérence de git en tout cas, avec la réponse de sufflope ça fait trois solutions différentes pour accomplir un truc qui est quand même basique de chez basique.
[^] # Re: Mercurial vu par Facebook
Posté par Philippe F (site web personnel) . Évalué à 7.
J'avais pas Internet au moment où j'ai fait ce truc, mais j'avais quand même la page de man de git et le tutorial de git… qui ne m'ont pas du tout éclairé.
Au final, je sais comment:
- committer l'inverse d'un commit précédent: ok mais je m'en fous
- supprimer des fichiers de staging que j'aurai ajouté: ok mais je m'en fous, mon fichier n'est pas encore ajouté
- supprimer tous mes changements locaux: on s'en rapproche mais en fait, tous mes changements m'intéressent sauf un sur un fichier que je veux annuler. En fait, c'est plutôt la moitié des changements que je veux annuler (le truc qui prend 10 secondes avec TortoiseHG où tu peux sélectionner dans un fichier ce que tu veux, ou 30 secondes avec TortoiseHG diff + WinMerge).
Toutes les explications sur la comment reset contiennent de très gros warning de attention, vous pouvez tout niquer, vous pouvez tout perdre, faites gaffe. Comme j'y comprends rien, c'est pas encourageant.
Apparemment, pour faire ce que je veux, c'est git checkout avec je sais plus quelle option.
Et donc:
- je suis passé par trois commandes git différentes sans trouver la bonne
- certaines de ces commandes ont 3 cas d'utilisation distincts mais communs (git-reset ).
- c'est blindé de warning "attention danger faite gaffe vous allez tout nicker"
Je sais pas comment on peut être sain d'esprit et prétendre que git est simple à utiliser.
J'utilise Vim tous les jours et je programme en C mais jamais je ne prétendrai que ces deux outils sont simples à utiliser. C'est complexe, c'est long, ça fait mal mais on arrive à en tirer quelque chose. Git, c'est pareil, sauf pour le dernier point.
Ca m'a rappelé l'époque où je lisais les man de sed pour l'utiliser autrement que pour faire des remplacement de lignes…
[^] # Re: Mercurial vu par Facebook
Posté par saimn . Évalué à 8.
Même pas besoin de google, il suffit de lire la sortie de git status (en français en plus):
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . Évalué à 7.
git reset --hard HEAD.
Amigo, t'embrouilles pas avec ceux qui te disent d'autres méthodes.
git reset --hard te sort d'un merge que t'as carabistouillé et même d'un rebase en cours (oublie l'abort).
Mais ATTENTION, ATTENTION jamais après avoir pushé. sinon FUYEZ !!! PAUVRES FOUS !!
Sauf lorsque tes admins sont prévoyants et veulent te protéger des représailles de tes petits camarades.
Pourquoi reset. Ben parce que ca te permet de remonter (ou descendre n'importe odans l'historique) et --hard parce que ca clean tout l'index et le workspace.
Puisqu'on vous dit que Git c'est une évidence.
Je le ferai un jour ce petit journal retour d'expérience d'un migration de 400 développeurs dans une DSI.
Promis
[^] # Re: Mercurial vu par Facebook
Posté par devnewton 🍺 (site web personnel) . Évalué à -5.
Si tu aimes la facilité d'utilisation, tu ne fais pas dev…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mercurial vu par Facebook
Posté par Blackknight (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 09 janvier 2014 à 15:37.
Mouarf !!!
Tu n'arrive pas configurer Sendmail sans utiliser M4 ?
Si tu aimes la facilité d'utilisation, tu ne fais pas admin sys…
La gestion de versions, ce n'est censé qu'être un outil pas une fin en soi.
[^] # Re: Mercurial vu par Facebook
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Je suis 100% d'accord, mais apparemment ce n'est pas la clef du succès :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mercurial vu par Facebook
Posté par Albert_ . Évalué à -3.
C'est un peu ce que je suggere…
[^] # Re: Mercurial vu par Facebook
Posté par fravashyo (site web personnel) . Évalué à 7.
Par contre ça semble difficile de configurer un clavier pour écrire correctement les caractères accentués…
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Mercurial vu par Facebook
Posté par Albert_ . Évalué à -10.
Probablement parceque je n'en ai pas envie…
éáèàçÉÁǴ…
[^] # Re: Mercurial vu par Facebook
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est pour faire vaincre ascii!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Mercurial vu par Facebook
Posté par fravashyo (site web personnel) . Évalué à 4.
Je trouve ça asciié d'omettre les accents.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Mercurial vu par Facebook
Posté par windu.2b . Évalué à 10.
Avec un jeu de mots pareil, tu devrais fuir. Loin. À pied, en traineau ou ASCII, comme tu veux…
[^] # Re: Mercurial vu par Facebook
Posté par fravashyo (site web personnel) . Évalué à 10.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
[^] # Re: Mercurial vu par Facebook
Posté par CrEv (site web personnel) . Évalué à 10.
Pour avoir bossé avec les deux, je dois dire que j'ai jamais bien compris où était la facilité d'utilisation de mercurial. Je veux dire en comparaison avec Git. Ok les deux n'ont pas exactement les mêmes termes mais franchement le plus gros de l'apprentissage dans les deux cas c'est les principes des DCVS. Le reste c'est pas mal des idées reçues je trouve, Git et Mercurial étant à mon avis du même niveau.
[^] # Re: Mercurial vu par Facebook
Posté par marmoute (site web personnel) . Évalué à 3.
Le temps dans le développement des DVCS passent étonnement lentement. Par exemple Mercurial a mis un certain temps à rattraper git rebase, mais une fonctionnalité rendant plus sûre cette réécriture introduite il y a 2 ans par Mercurial est toujours absente de git. Malgré que les développeurs de git s'y intéressent
Bref, les deux outils se réapproprient les bonnes idées lentement mais sûrement depuis 8 ans et j'espère que bien que cela continue.
[^] # Re: Mercurial vu par Facebook
Posté par cosmocat . Évalué à 8.
L'article sur InfoQ sur le sujet apporte un peu plus d'infos :
http://www.infoq.com/news/2014/01/facebook-scaling-hg
…ainsi qu'une petite blague:
Facebook a choisi Mercurial car c'est écrit en Python et donc plus facilement extensible et au moins un des patch conséquent fourni a consisté a réécrire en C la fonction de détection du statut des fichiers. Encore quelques patch et Mercurial sera entièrement en C…comme git ;)
[^] # Re: Mercurial vu par Facebook
Posté par marmoute (site web personnel) . Évalué à 9.
Les opérations bas niveau (accéés disque) ou assez intensives sont codés en C parce que cpython n'est pas bon pour ça. Ce qui donne 5% du code C avec 95% de logique en python facile à étendre et à réécrire quand besoin. C'est plutôt une cas d'école de bonne utilisation de python qu'une lente réécriture intégrale en C.
[^] # Re: Mercurial vu par Facebook
Posté par marmoute (site web personnel) . Évalué à 4.
En regardant un peu plus loin il y à moyen d'être un peu plus enthousiaste.
Certes l'extension remotefilellog tel quel vise une petit niche, mais elle est aussi un premier pas vers des applications plus accessible. Une étape supplémentaire serait de remplacé le serveur memcache par un server mercurial classique. Un peu moins performance mais mise en place transparente pour l'utilisateur final. On peu pousser là logique encore un peu plus loin en faisant des clones paresseux: Du clone le minimum et tu peux utiliser ton dépôt immédiatement pendant qu'un processus continue de le remplir en tâche de fond. Bref cette extension est à la fois un pas important dans la bonne direction et un exemple assez impressionnant de l'extensibilité de Mercurial.
L'extension watchman est interessante pour plus d'utilisateurs. Par exemples les dépots de Mozilla sont suffisamment gros pour y voir une amélioration sensible.
[^] # Re: Mercurial vu par Facebook
Posté par Marotte ⛧ . Évalué à -1.
Tes fautes d'orthographe (d'accord, grammaticales, OSEF moi je range ça dans orthographe…) sont… surprenantes.
« accessible » n'est pas accordé au pluriel, bon, ça ça ne choque pas trop, peut-être une étourderie. Le participe passé à la place de l'infinitif pour « remplacer », OK, c'est moche mais c'est un classique. Par contre l'accent sur le verbe avoir (à) là je dis non ! Mes yeux saignent, je ne te remercie pas.
[^] # Re: Mercurial vu par Facebook
Posté par Guillaum (site web personnel) . Évalué à 4.
Malgré son orthographe dramatique, je peux t'assurer que dans cette discussion c'est surement le type qui est le plus objectif car il connait très bien git et encore plus mercurial.
# TL;DR
Posté par davandg . Évalué à 10.
Pour ceux qui ne veulent pas lire le pavé :
- Ils utilisaient Subversion avec un mirroir Git
- Ils ont choisi Mercurial à la place de Git car Mercurial est écrit proprement en Python.
- Ils ont contribué un certain nombres de patchs, dont :
- Watchman qui permet de mieux traquer les modifications de fichiers
- remotefilelog qui remplace l'historique complet local pour un méta-historique local avec une récupération automatique des fichiers en cas de besoin
Je comprend tout à fait leur choix. A l'époque où j'avais regardé le code source de Git il y avait des bouts en différents langages (C, perl, bash, bash windows, tcl/tk, python) et en plus c'était très mal rangé, (ça l'est toujours pas trop, voir https://github.com/git/git).
[^] # Re: TL;DR
Posté par Misc (site web personnel) . Évalué à 3.
Et facebook emploie 2 commiteurs de mercurial, et sans doute plus pour les taches tout aussi importantes comme la QA, etc.
# traduction de scalabilité
Posté par ChickenKiller . Évalué à 5.
"Capacité à absorber la montée en charge" ? … punaise ça fait un peu long
[^] # Re: traduction de scalabilité
Posté par goeb . Évalué à 2.
Je propose :
scalability = "possibilité de déploiement à grande échelle"
[^] # Re: traduction de scalabilité
Posté par mickabouille . Évalué à 2.
Non, parce que "scalabity" marche dans les deux sens, petite et grande échelle.
[^] # Re: traduction de scalabilité
Posté par goeb . Évalué à 1.
Je ne crois pas que le sens vers la petite échelle soit concerné.
Aurais-tu un exemple ou ça serait employé dans le sens petite échelle ?
J'ai trouvé ceci :
http://dictionary.cambridge.org/dictionary/british/scalability?q=scalability
Donc uniquement dans le sens vers la grande échelle.
D'ailleurs en français, "passage à l'échelle", sans spécifier "grande" ni "petite", ça n'a pas de sens.
[^] # Re: traduction de scalabilité
Posté par shiva668 . Évalué à 4.
Capacité de passage à l'échelle ?
[^] # Re: traduction de scalabilité
Posté par MarbolanGos (site web personnel) . Évalué à 7.
J'ai souvent lu « passage à l'échelle » comme traduction de scalability.
[^] # Re: traduction de scalabilité
Posté par Thomas Debesse (site web personnel) . Évalué à 3.
Peut-être forger des mots à partir de « (s')échelonner » ?
échelonnement ? échelonnable ? échelonnabilité ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: traduction de scalabilité
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 6.
Tant qu’on ne passe pas sous l’échelle…
[^] # Re: traduction de scalabilité
Posté par jardiland . Évalué à 4.
Moi, j'avais plutôt vu « mise à l'échelle ». C'est pareil, mais avec moins de lettres.
[^] # Re: traduction de scalabilité
Posté par Jiehong (site web personnel) . Évalué à 9.
Le dictionnaire dit : extensibilité.
Bon, c'était simple ^
# c'est une question de philosophie
Posté par Albert_ . Évalué à 6.
entre mercurial et git. Je developpe beaucoup en python mais la philosophie derriere Mercurial je ne l'ai jamais comprise alors que celle de git me parait naturelle.
Pour moi, et c'est tres subjectif, le systeme de branche de git est logique et j'apprecie tout particulierement sa legerete. Je n'ai rien compris a celle de Mercurial et je n'ai pas trouve de moyen autre que un clone pour aller d'une branche a une autre (c'etait il y a quelques annees) et sur certains projets avec plusieurs copies c'est bien lourd. Maintenant je suis tout a fait conscient que c'est probablement un probleme de l'interface chaise clavier… mais comme ca fonctionne de facon tres simple avec un et pas avec l'autre je suis reste sous git.
De tout de facon vu que les deux projets sont open-source, il est tout a fait possible d'utiliser l'un et l'autre suivant les preferences du developpeur cela ne pose pas un veritable probleme pour qui que ce soit sauf le management du projet.
[^] # Re: c'est une question de philosophie
Posté par Adrien . Évalué à 3.
Perso c'est l'inverse : mon esprit n'arrive pas à entrer dans git, c'est obscur, compliqué pour rien. Tiens, un exemple : monter un serveur HTTP git ou mercurial, avec une authentification basique. Dans un cas apache + hgweb + htpasswd et c'est bon, dans l'autre… ssh ? gerrit ?
Concernant les branches, peut-être que les bookmarks te conviendrais mieux ?
[^] # Re: c'est une question de philosophie
Posté par Anonyme . Évalué à 3.
Si tu veux que ca soit en http, tu peux utiliser apache + mod_dav:
https://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.html
En utilisant ssh c'est encore plus simple, il suffit de créer ton dépot sur ton serveur, et ensuite tu utilises l'url ssh://login@serveur/repertoire.git
[^] # Re: c'est une question de philosophie
Posté par Antoine . Évalué à 1.
Oui, enfin il demandait un serveur HTTP. Je signale en passant que l'interface HTTP de Mercurial sert également une IHM de navigation dans le dépôt.
(parce que Mercurial sait fonctionner sur SSH aussi, hein)
[^] # Re: c'est une question de philosophie
Posté par windu.2b . Évalué à 2.
Git fournit gitweb : un script CGI qui permet de naviguer dans le dépôt.
[^] # Re: c'est une question de philosophie
Posté par Albert_ . Évalué à 3.
Pour avoir fait les deux, pour mettre en place une interface web c'est hyper simple avec mercurial car integre directement:
hg serve
pour git meme avec gitweb c'est beaucoup plus chiant.
[^] # Re: c'est une question de philosophie
Posté par Antoine . Évalué à 2.
C'est moderne et performant, ça, un script CGI…
[^] # Re: c'est une question de philosophie
Posté par Albert_ . Évalué à 1.
En meme temps puisque tu abordes le sujet de moderne ca sent mal barre le passage a python3 ce qui va un jour ou l'autre risque de poser probleme.
[^] # Re: c'est une question de philosophie
Posté par Antoine . Évalué à 3.
Je ne sais pas si "ça sent mal barre", je dirais que ça dépend surtout de la volonté des devs Mercurial (Matt Mackall principalement) d'admettre qu'unicode est une meilleure solution pour représenter du texte que de trimbaler des chaînes d'octets aveuglément.
Sinon, Python 2.7 va continuer à être maintenu pendant au moins deux ans ;)
[^] # Re: c'est une question de philosophie
Posté par Albert_ . Évalué à 2.
Lorsque tu vois la FAQ de Mercurial ca sent pas bon tout de meme…
http://mercurial.selenic.com/wiki/SupportedPythonVersions
[^] # Re: c'est une question de philosophie
Posté par ribwund . Évalué à 1.
Ou alors les dev python comprendront que si Matt et d'autres gens veulent des bytes qui marchent c'est pas pour des mauvaises raisons (le VCS il s'en fout de l'encoding) ;)
(ou alors quelqu'un se bougera et forkera un 2.8)
Honnetement pour l'instant y'a plus de chances que mercurial soit porté sur du non python que sur 3.x.
[^] # Re: c'est une question de philosophie
Posté par Antoine . Évalué à 4.
Les bytes marchent. S'ils ne marchent pas comme Matt et d'autres gens le veulent, alors ce serait bien que les gens en question prennent le temps de participer aux discussions, par exemple sur https://mail.python.org/pipermail/python-dev/2014-January/130923.html
Se plaindre sur Linuxfr ou sur Reddit ne fera pas avancer les choses, ni faire du chantage au fork ou au changement de langage.
Voici le résultat de cette merveilleuse approche :
http://mercurial.selenic.com/wiki/WindowsUTF8Plan
http://mercurial.selenic.com/wiki/FixUtf8Extension
(résumé : Mercurial marche mal avec les noms de fichiers non-ASCII sous Windows, parce que Mercurial refuse de comprendre que différentes machines ont différents jeux de caractères par défaut, et qu'il faut donc transcoder pour conserver l'information)
D'ailleurs tous les développeurs Mercurial ne sont pas d'accord avec "le VCS il s'en fout de l'encoding", il me semble par exemple que Martin Geisler est d'avis que l'approche actuelle est mauvaise.
[^] # Re: c'est une question de philosophie
Posté par ribwund . Évalué à 2.
Au dernières nouvelles, Martin était minoritaire sur ces points là.
Le reste pense qu'un nom de fichier c'est juste des bytes sans \0 et ou . et / ont une signification particulière (approche unix).
[^] # Re: c'est une question de philosophie
Posté par flan (site web personnel) . Évalué à 2.
Ce n'est pas le cas sur tous les OS, et heureusement !
[^] # Re: c'est une question de philosophie
Posté par Antoine . Évalué à 4.
Sauf que l'utilisateur pense différemment : pour l'utilisateur, le nom de fichier est une information textuelle, et ça le fait chier si tu affiches de l'utf-8 comme si c'était du latin1 ou du cp1252. D'où l'existence des contournements à la con que j'ai mentionnés pour Windows…
[^] # Re: c'est une question de philosophie
Posté par marmoute (site web personnel) . Évalué à 2.
Il y a en fait deux sujets unicode. L'un d'eux est concernent les noms de fichier, il est patrouillé par des trolls et chaque faction à de bon argument.
Le second sujet est le stockage de fichier commité. Et j'ai vraiment du mal à voir quelqu'un argumenté que le contenu d'un fichier est autre chose qu'un énorme blob de bytes du point de vu du DVCS ;-)
La PEP460 est un grand pas en avant sur ce front là. Et les gens qui s'intéressent à ces questions dans la communauté Mercurial s'en forte déjà les mains.
[^] # Re: c'est une question de philosophie
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
http://darcs.net/manual/Darcs_commands.html#SECTION00654000000000000000 ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est une question de philosophie
Posté par Guillaum (site web personnel) . Évalué à 2.
Un jour j'utiliserais Darcs rien que pour cela.
J'aimerais vraiment que on arrête la notion de diff et que on passe à des changeset sémantiques en gardant le diff en dernier recours.
Quand je déplace un bout de code, renomme un ensemble de fonctions, ajoute un test autour d'un bloc de code et indente celui-ci, j'aimerais vraiment que les merges futurs continuent d'avoir cette information pour merger mon code.
Typiquement, après un merge entre une branche refactorée (où on a changé le nom de la fonction haha en hihi) et une autre branche qui a ajouté un appel à cette fonction, le merge peut bien se passer, en laissant tout fois un code invalide car il reste l'appel qui n'a pas été renommé. (d'ailleurs, vous reglez cela dans le merge ou dans un commit suivant ?)
Je ne sais pas à quel point il serait possible de faire des commit qui décrivent non pas le changement, mais la recette du changement (Cela pourrait bêtement être un script).
[^] # Re: c'est une question de philosophie
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca ressemble à la façon dont django south gère les migrations de bases: une série de méthodes python pour passer de version en version ou revenir en arrière.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: c'est une question de philosophie
Posté par marmoute (site web personnel) . Évalué à 1.
Il y a des gens chez Google qui s'intéressent à Mercurial sur python trois. Donc ça devrait arrivé dans les années qui viennent.
[^] # Re: c'est une question de philosophie
Posté par Albert_ . Évalué à 2.
En effet le serveur web de mercurial est tres facile a mettre en place mais bon en meme temps je me sers beaucoup plus des branches que du serveur web donc ma priorite a ete vers cette utilisation mais comme je l'ai bien precise j'ai vraiment l'impression que c'est une question de philosphie.
[^] # Re: c'est une question de philosophie
Posté par rakoo (site web personnel) . Évalué à 3.
Ah ouais mais ça, ça n'a rien a voir avec un gestionnaire de version, je conçois tout a fait que git ne soit pas optimise pour ça.
[^] # Intégré
Posté par Arthur Accroc . Évalué à 7.
Sinon, il y a Fossil : il fait gestionnaire de versions, serveur HTTP et même le wiki du projet… avec un seul exécutable !
Il n’est peut-être pas aussi complet que Git ou Mercurial, mais du point de vue de l’exercice de style, je le trouve assez impressionnant.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: c'est une question de philosophie
Posté par CrEv (site web personnel) . Évalué à 9.
Pour avoir utilisé les deux, j'ai eu pas mal de difficulté au début. Par ce que je voulais utiliser les branches dans mercurial exactement comme dans git. Alors qu'en fait non.
En général lorsque je fais du git je branche avant de coder. Genre je prépare, je prévois mon dev en commençant par nommer ma branche (ou mes) et ensuite je rentre dedans. Sous mercurial, souvent, je vais brancher plus tard, au besoin.
Quelques liens qui peuvent aider
Et sinon, preuve que c'est pas si loin, kiln permet par exemple d'avoir un fontend git ou mercurial du même projet. Et ça je trouve que c'est vraiment cool pour supprimer tous les problèmes du genre j'aime pas/j'arrive pas git/mercurial.
[^] # Re: c'est une question de philosophie
Posté par Albert_ . Évalué à 6.
J'ai bien dit des le titre que a mon avis la gueguerre git/Mercurial venait d'un pobleme philosophique et de comment tu as l'habitude de travailler ou de comment ton cerveau bosse (moi le miens comme vous le savez c'est pas beaucoup). Apres c'est une guerre de religion et elle n'a pas vraiment lieu d'etre car un developpeur utilisant git peut tout a fait bosser sur un depot mercurial et inversement. Donc la facon dont chacun fait sa tambouille c'est son probleme et tant mieux il y a le choix entre deux systemes qui arrivent aux meme buts par des voix differentes TANT MIEUX.
[^] # Re: c'est une question de philosophie
Posté par cosmocat . Évalué à 5.
Pareil! Au moment de choisir un DVCS, j'ai regardé un peu Mercurial et git pour au final opter pour git (car l'ecosystème est plus florissant).
Mais lire çà : http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
me fait un peu tiquer (il faut réfléchir à quoi choisir avant de faire une branche :( et le "branching with clone" me parait une aberration alors que c'était ce qui était plutôt conseillé à l'époque il me semble ), là où la notion de branches de git me semble limpide…
Ce qui me dérange également avec Mercurial est, paradoxalement, le système de plugins : tout le monde n'a pas le même set de fonctionnalités, il faut bucher la liste des plugins pour pouvoir faire des trucs qui me semblent devrait être disponible par defaut, …
[^] # Re: c'est une question de philosophie
Posté par François (site web personnel) . Évalué à 3.
C'est parce que mercurial n'as pas besoin de branche nommée, tout simplement.
hg headsdonc. Ce qui le rend intrinsèquement plus simple que git.Ensuite tu peux les nommer ala git avec les bookmarks. Enfin tu peux ajouter les branches ala mercurial qui sont des tags exclusifs attachés aux commits.
[^] # Re: c'est une question de philosophie
Posté par marmoute (site web personnel) . Évalué à 2.
Mercurial a un système de branche depuis 2005 soit la première année. Je ne sais pas trop d'où te viens ce souvenir d'un besoin de branche par clone obligatoire. Il me semble que ce comportement est plutôt du domaine de Bazaar.
[^] # Re: c'est une question de philosophie
Posté par El Titi . Évalué à 4. Dernière modification le 10 janvier 2014 à 16:35.
C'est pourtant simple et quelqu'un t'a répondu.
Par défaut avec Hg, tu peux avoir plusieurs commit issus d'un commit initial sur un dépôt: les heads.
avec Git ce n'est pas possible. Tu as toujours des branches explicite et une branche référence toujours un commit (je ne parle pas des detached head on est dan un bare). Si tu pushes et qu'il y a 1 autre commit concurrent tu dois merger ou forcer à déplacer la référence de branche (lorsqu'on t'y autorise).
Si tu as plusieurs heads, ca signifie que tu as un conflit que quelqu'un d'autre peut prendre en charge en par un fetch dans son dépôt local.
Donc si tu bosses sur une seule branche et que tu veux laisser l'accès en écriture à ton dépôt ou au dépôt central c'est très pratique et simple mais ca montre ses limites même avec plusieurs clones locaux.
Si tu as besoin de plusieurs branches, elles existent. Comme avec Git ce sont des références (étiquettes) à un commit qui montrent dans quelle branche a été effectué le commit.
A la différence de Git, chaque commit de la branche porte cette étiquette alors qu'elle est unique et se déplace avec Git.
Je trouve ca assez intéressant car Git récupère l'historique d'une branche en extrayant le sous-graphe connexe mais il n'y a pas de moyen (hormis commentaire) de savoir si un commit intermédiaire avait été créé dans une
branche ou une autre.
Si tu pulles et que tu as 2 commits tu as plusieurs heads et donc un merge à résoudre. Pas de notion de référence locale et distante donc plus simple à appréhender, je pense (surtout pour ceux qui rebasent à l'envers, suivez mon regard dans le fond à droite).
Lorsque tu pushes le commit de ta branche rien ne change par rapport au explications du début. 2 commits concurrents de la même branche porte l'étiquette de branche (elle n'est pas déplacée) et un conflit est à résoudre (plusieurs heads).
Evidemment tu peux résoudre les conflits avant de pusher comme
Est-ce un problème d'avoir plusieurs heads:
Non pour les version importantes puisqu'elle portent un tag ?
Pour les outils tels que la CI (Jenkins) ca peut être gênant puisqu'ils ont besoin de se référer à une unique version.
Les spécialistes Hg nous diront peut-être comment on procède dans ce cas (un hook ?).
Ce que je regrette par contre c'est le fait que l'on ne puisse pas crée de branche locale avec Git. Ca devait être implémenté mais je crois que ca n'a jamais abouti, me trompe-je ?
Je ne sais pas non plus comment fonctionne le checkout partiel aujourd'hui.
[^] # Re: c'est une question de philosophie
Posté par Anonyme . Évalué à 5.
Git permet d'avoir plusieurs commits issus d'un commit initial. C'est juste que les branches ne sont pas gerées pareil. Dans git, une branche c'est un pointeur vers un commit. Dans mercurial c'est un identifiant present dans chaque commit.
On peut très bien créer des branches locales avec Git. En fait tant qu'on a pas décidé de les pusher sur un serveur, toutes les branches sont locales.
[^] # Re: c'est une question de philosophie
Posté par El Titi . Évalué à 1.
C'est pour Hg que je le regrette pardon.
Même si une extension existe.
Sinon je pense que je me suis mal exprimé.
Git n'accepte pas plusieurs commits concurrents pour une même branche (feuilles d'un graphe). Il y a une seule référence de branche qui pointe sur un unique commit.
Avec Hg plusieurs commits concurrents peuvent appartenir à la même branche. D'où la commande hg heads. Chaque commit porte et persiste le nom de la branche associée.
Résoudre des conflits ne nécessite que de connaitre le nom des branches.
Avec Git les évolutions concurrentes sont gérées en assignant une référence de branche à chaque remote (branches de suivi) et à la référence locale: la branche de travail, et en les mergeant. Cette association n'est qu'une pure convention (dépend des refspecs). Ceci est plus souple et ça permet de réallouer des synchronisations, mais c'est plus complexe à appréhender.
C'est d'ailleurs assez déconcertant pour les devs novices d'intégrer qu'il faille créer une branche locale (hormis clonage de branche) avant de pouvoir travailler dedans.
En revanche le fait de ne pas persister les références de branches dans les commits simplifie la gestion des branche locales (Juste une réference à supprimer).
[^] # Re: c'est une question de philosophie
Posté par windu.2b . Évalué à 2.
Oui et non.
Oui, car tu peux avoir plusieurs commits-frères sur une même branche, sans pour autant avoir créé une branche pour chacun : si j'ai bien compris, c'est typiquement ce qu'il se passe quand tu fais un
commit --amend. Cette commande sert à corriger le dernier commit (quand on a oublié d'y joindre un fichier ou que le message n'est pas clair/complet), et crée en fait un nouveau commit, frère du commit corrigé (et le pointeur de branche pointe maintenant sur lui).Du coup, le commit corrigé existe toujours, mais n'est plus pointé par personne (un peu comme un objet en mémoire qui ne serait plus référencé par aucune variable).
Mais non car, sauf autre cas qui ne me vient pas à l'esprit, tu ne peux pas facilement continuer à travailler à partir de ce commit abandonné, si c'est ça que tu souhaites faire. Il te faudrait par exemple créer une branche à partir de lui, j'imagine…
[^] # Re: c'est une question de philosophie
Posté par El Titi . Évalué à 2.
Le --amend réécrit le dernier commit en repartant du père.
La référence de branche locale est déplacée sur le nouveau commit. Il y a toujours une unique feuille dans la branche.
L'ancien commit est oublié et n'appartient plus à la branche. Il est dans le reflog.
Les branches sont des pointeurs … uniques.
Cette histoire de commit oublié (par un co, reset ou amend est le plus difficile à intégrer pour les novices avec git. C'est ingénieux mais déconcertant.
Pour travailler dans un même effort de développement: une branche ou plutôt un faisceau ou sous-graphe, il faut en fait travailler avec plusieurs références de branches (une locale et n de suivi). Leur association est purement formelle.
Hg fonctionne différemment. Tous les commits d'une même branche portent le même nom (fichier versionné dans le commit qui enregistre ces références). On peut donc se retrouver avec plusieurs commit feuilles qui portent le même nom (heads) qu'ils faut réconcilier. Le résultat est le même mais le concept est plus simple à appréhender.
# Mercurial
Posté par David Demelier (site web personnel) . Évalué à 4.
Je suis un utilisateur inconditionnel de Mercurial est fan depuis mes premières heures en développement. Cependant, j'ai du mal à croire qu'on puisse rendre Mercurial plus performant que Git. Mercurial est développé en Python ce qui soulève de base une certaine lenteur.
Quand on voit le temps de clonage de la libsdl, on voit très vite les difficultés de Python.
Par contre, je suis content de voir un peu plus de support envers Mercurial, le pauvre il se fait marcher dessus avec l'engouement de Git et GitHub.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Mercurial
Posté par Alex . Évalué à 5.
Je pense que ton analyse est un peu basique
Que python soit plus lent que du C, soit, néanmoins il y a d'autres paramètres à prendre en compte: l'acrhi de l'application et algos utilisés, est-ce que les accès disques sont nombreux ou réduit au possible, comment est structuré la base de donnée, etc…
[^] # Re: Mercurial
Posté par windu.2b . Évalué à 3.
À noter qu'il y a des parties de Mercurial qui sont écrites en C( au moins le diff, peut-être d'autres encore ?).
[^] # Re: Mercurial
Posté par ribwund . Évalué à 4.
Tout le coeur de mercurial est écrit en C, le reste de de l'assemblage en python (ce qui permet d'être performant et de faire du dev rapide).
[^] # Re: Mercurial
Posté par Gof (site web personnel) . Évalué à 3.
Pour ça, il y a C++ ;-)
[^] # Re: Mercurial
Posté par David Demelier (site web personnel) . Évalué à 3.
Exagère pas, il y a 11 fichiers C (dont 1 en contrib et 1 pour linux) qui totalisent 4800 lignes de code contre 66000 en python.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Mercurial
Posté par flan (site web personnel) . Évalué à 1.
Ça ne veut rien dire, ce qui est important c'est que ce qui est très utilisé soit bien codé. Pour ça, il faudrait faire un peu de profiling (ou connaître le code).
[^] # Re: Mercurial
Posté par karteum59 . Évalué à 2.
Si >80% du temps est dépensé dans <20% du code, ce n'est pas déconnant…
[^] # Re: Mercurial
Posté par ribwund . Évalué à 1.
Oui c'est ce que je dis le coeur est en C (tout le parsing depuis les formats binaries, diff, patch, toutes les opérations de file system) le reste c'est de la logique plus haut niveau pour composer ça.
# git ou mercurial, le choix n'est pas important...
Posté par StreakyCobra . Évalué à 5.
… car darcs VAINCRA! Mouhahahaha
(ou pas).
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par zebra3 . Évalué à 10.
Ça ne pourra jamais battre l'universel cpold.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par totof2000 . Évalué à 4.
anefe !!! solution universelle que j'ai adoptée depuis des années, et que l'on rencontre un peu partout dans le monde professionnel (c'est pas comme ces stupidités de logiciel libre qui ne sont utiles qu'à la maison).
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par cosmocat . Évalué à 2.
Tu as raison, il faut faire des cpold des répertoires .git et .hg…
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par claudex . Évalué à 10.
Je lui préfère largement cpmail, c'est à dire qu'on envoie un zip avec ses sources à toute l'équipe, à charge à chacun de faire ses merges. C'est beaucoup plus sain parce chacun fait un merge en fonction de l'état actuel de son dépôt. En plus, il y a un historique aussi grand que la boîte mail (entre les oublis de pièces jointes et les « ah zut, ce n'était pas le bon zip, voilà le bon). Et comme c'est décentralisé, chacun a son compteur de version personnel, ça évite les tensions pour décider d'un compteur commun.
« 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: git ou mercurial, le choix n'est pas important...
Posté par rakoo (site web personnel) . Évalué à -4.
Dans la mesure ou c'est comme ça que se développent les Grands Logiciels du Libre (sauf qu'ils n'envoient pas les sources, mais les patchs), ça me fait rire un peu jaune …
# Investissement de facebook dans mercurial
Posté par Nahuel . Évalué à 5.
À la PyConFR à strasbourg, j'ai eu l'occasion de rencontrer 2 personnes qui travaillaient pour facebook, très intéressant.
L'un d'entre eux, a été embauché par facebook pour travailler sur mercurial, car il était déjà développeur mercurial.
Si j'ai bien compris la problématique de facebook, ils ont des "millions" de commits sur des branches, et git est très très mauvais en performance de ce côté là, faire un checkout d'une branche prendrait 20mn. Ce serait pourquoi facebook est passé à mercurial, ça n'est pas vraiment une question de philosophie, apparemment ils continuent toujours d'utiliser git pour certains projets.
[^] # Re: Investissement de facebook dans mercurial
Posté par cosmocat . Évalué à 7.
Dans git, et c'est cela qui est bien pensé, avoir des "millions" de commits dans un branche n'influe pas sur le temps de checkout. Ce qui influe c'est le nombre de différences entre la version actuelle et celle que tu vas "checkouter".
Et là, je ne comprends pas ce que Mercurial peut faire de mieux. Je souhaiterais une explication…
Si c'est juste qu'ils gèrent leurs branches avec Mercurial en faisant des clones (une des méthode proposé par Mercurial au lieu de faire des branches), tu peux aussi bien le faire avec git. C'est juste que c'est pas conseillé car tu dois alors bosser dans un autre répertoire, ce qui n'est pas pratique (surtout si tu dois relancer un IDE)
[^] # Re: Investissement de facebook dans mercurial
Posté par ribwund . Évalué à 2.
Nope ils utilisent les branches à la git (bookmarks).
Sinon le genre de truc ou git est lent c'est blame. Je sais pas si c'est fixé mais y'a un moment avec un repo avec beaucoup de fichiers (genre beaucoup plus que le kernel) checkout, status, commit, etc étaient trop lent pour facebook.
[^] # Re: Investissement de facebook dans mercurial
Posté par marmoute (site web personnel) . Évalué à 3.
L'article explique que les problèmes de performance sont lié à deux choses:
- La quantité des changesets (C'est moins gros que plusieurs millions mais plein quand même)
- La quantité de fichiers versionnés
Chacune de ses dimensions va ralentir un aspect de l'outil.
<hg|git> statusne va pas être affecté par le nombre de changesets mais par le nombre de fichiers. À l'inverse<git|hg> pullne va pas vraiment être affecté par le nombre de fichier total mais par le nombre de changesets/changement à synchroniser.Chacune des deux extensions présentées améliorent fortement une dimension dans ce sens.
hgwatchmanaccélère la supervision des fichiers de Facebook.remotefilellogaméliore le transfert des changesets créés toute les jours.Un certain nombre d'autre modifications ont également été faite upstream. Par exemple depuis 4 versions
hg update(équivalent degit checkout) est parallélisé, le calcul du contenu et l'écriture sur disque de plusieurs fichiers sont réalisés en même temps. Cela peut donner des améliorations de performance assez drastique quand on utilise des machines à plusieurs dizaines de cœurs pour des mises à jours de plusieurs milliers de fichiers.Par ailleurs un certain nombre d'opération dans git prennent en compte l'intégralité du dépôt, comme le "packing" ou la "garbage collection". C'est opération sont donc de plus en plus lentes au fur et à mesure que le dépôt grossi. Si on prend en compte le fait que ces opérations ont des races conditions entre elle et avec un certain nombre de command de base (ceci n'est pas une blague) ça ne donne pas très envie de les voir s'étaler dans la durée. Mercurial à un format de stockage "en ajout uniquement" qui ne souffre pas de ce genre de problème tout en garantissant un stockage efficace en place et en temps de restauration.
Pour finir, je rappel que Mercurial n'a pas besoin de plusieurs clone pour utiliser plusieurs branches. Il me semble que c'est bazaar qui suit ce modèle.
[^] # Re: Investissement de facebook dans mercurial
Posté par Atem18 (site web personnel) . Évalué à 3.
Oui, je me souviens bien d'eux. D'ailleurs, la présentation d'un des admin-sys de facebook sur les clusters était très intéressante.
# Mensongeries
Posté par El Titi . Évalué à 3. Dernière modification le 10 janvier 2014 à 10:56.
En fait Facebook n'a pas migré de Git vers Hg mais de SVN vers Hg.
Au départ leurs code est hébergé sous SVN et ils souhaitaient continuer à fonctionner avec les caractéristiques de cet outil, tout en adoptant les avantages des DVCS. Ils ont donc toujours un dépôt central SVN mais clonent sous Git en local.
Le souci qu'ils rencontrent est un grand classique des équipes qui bossent sous SVN et qui ne veulent pas se prendre la tête à recréer un dépôt pour chaque nouveau projet. On se crée un sous-répertoire avec ses branches et tag ou alors un sous-répertoire sous trunk, branches et tags.
Quand on bosse avec SVN on fait juste un checkout du bon sous-répertoire et c'est marre.
Lorsqu'on utilise un dvcs, soit en clonant, soit en migrant l'historique à plat on rencontre plein de soucis.
Déjà, cloner un dépôt entier pour ne travailler que sur une sous-partie négligeable ça prend des plombes.
Ensuite on se retrouve à extraire tout à plat une arbo avec tous les projets qui servent à rien y compris le contenu des tags et branches.
Enfin, chaque commit fait un hash de tout le contenu alors que l'on travaille sur une portion disjointe.
Petit retour d'expérience
Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.
La première solution a pour avantage d’alléger le clone. Mais elle présente l'inconvénient de travailler à la mode SVN avec les même contraintes que cet outil (pas d'historique local) et en venant de SVN, on se retrouve toujours avec l'arborescence à plat des projets et toutes les branches , tags , …
A chaque fois qu'un dev d'un projet commite et push il pollue les devs des autres projet qui doivent faire des rebase/merge fast forward pour du code qui ne les concernent pas.
La 3ème solution ne convient pas car elle ne fait que masquer les répertoires inutiles.
Déjà, elle n'est possible qu'en ligne de commande. (Les IDEs ne l'implémentent pas). ensuite ça ne résout aucun des problèmes de performances (les clones sont toujours complets, les commit sur tout le contenu, …)
Pour s'en sortir, lorsqu'on a rencontré ce pb sur un projet voici les solutions envisageables.
1- Créer un dépôt par projet et remonter l'historique.
Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).
La démarche:
2 - Utiliser le clone par branche (point 2)
D'abord Migrer l'historique SVN tel quel dans Git dans un dépôt legacy. Créer un autre dépôt propre puis créer une branche par branche active de projet dans laquelle on recopie la dernière révision de la branche active du projet. On expurge tous les répertoires des autres projets. On commit et on pushe sur le dépôt central.
Ensuite il suffit de cloner les bonnes branches pour ses besoins.
Ceci reste tout de même contraignant par rapport à la façon de travailler avec SVN puisqu’il faut manipuler les branches avec des conventions de nommage. Ce n'est pas dans les habitudes des développeurs venant de SVN.
Cette solution est à appliquer lorsque le code est trop imbriqué (comme décrit plus haut). Pour les modules biens disjoints, on peut appliquer la première solution pour les isoler dans un dépôt (et utiliser submodule si besoin)
Voilà.
Encore une fois une bonne architecture et une bonne gestion de conf peuvent aider à sauver des BB phoques.
Nos petits amis de FB, n'ont visiblement pas envie de se prendre la tête avec cette migration (ou ont une archi toute pourite ???). Ils préfèrent filer un coup de main au projet Hg (parce que c'est plus simple pour eux AMHA, pas parce qu'il préfèrent Hg à l'usage, j'imagine que c'est plus facile de déployer un plugin en interne que de convaincre une communauté) en optimisant le point 3. Notamment ils font en sorte que les commits ne s'applique sur des hash des fichiers modifiés et non sur tout le contenu et ensuite ils optimisent le cache pour ne travailler que sur le sous-graphe connexe plutôt que sur tout l'historique.
Tant mieux pour ce projet libre. Mais pas sûr qu'ils échappent à terme à ne plus travailler comme des gorets (un vendredi on peut se permettre un petit troll) et à migrer.
[^] # Re: Mensongeries
Posté par cosmocat . Évalué à 1.
Le point 1 n'est pas possible avec Git car on obtient un sha1 différent car le sha1 est dépendant du commit parent (qui ici n'est pas présent). Apparement, c'est juste pour la consultation. Contrairement, apparement, à Mercurial qui permet de le faire?
Le point 3 ne me parait pas possible également.
Apparement, reposurgeon peut faire çà.
[^] # Re: Mensongeries
Posté par Sufflope (site web personnel) . Évalué à 2. Dernière modification le 10 janvier 2014 à 11:41.
Si, pour l'avoir fait, on peut travailler sur un clone partiel (obtenu avec git clone --depth). Enfin il y a des limitations, certes.
[^] # Re: Mensongeries
Posté par cosmocat . Évalué à 2.
Euh… je croyais avoir été clair pourtant. Je disais que c'était pas possible car tu peux pas vraiment travailler avec (puisque tu ne peux pas faire de 'push') et c'est l'objet du débat. Avoir une vrai solution pour pouvoir travailler, non?!?
Sinon, le clone --depth fait exactement ce que je décris et on se retrouve avec des sha1 différents, donc un dépot local qui sert à pas grand chose à part la consultation (et la collaboration à base de patchs).
[^] # Re: Mensongeries
Posté par El Titi . Évalué à 2.
En fait la seule vraie utilité de cette option selon moi c'est d'isoler des gros fichiers (des images, des binaires qu'on intègre sans source, …) dans un dépôt pour éviter de cloner 250 version d'un même fichier de 100 Mo dans son dépôt de travail.
[^] # Re: Mensongeries
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Bah non … je n'ai jamais eu l'occasion de tester en vrai, mais je viens de vérifier, « git clone --depth 1 » me donne bien un repo avec le même sha1 pour HEAD, j'ai pu commiter et pusher (le push n'est pas supporté d'après la doc par contre, ça marche « des fois mais pas toujours »). Bien sûr, un « git log » s'arrête là où l'historique local s'arrête.
Ça n'est pas parce que le commit parent est absent qu'on ne peut pas utiliser son sha1 comme référence. Git sait juste qu'il a une référence qu'il ne peut pas suivre parce qu'il n'a pas l'objet dans sa base locale.
[^] # Re: Mensongeries
Posté par CrEv (site web personnel) . Évalué à 3.
mouai
déjà, pourquoi vouloir migrer vers de multiples dépôts ? nan vraiment, pourquoi ?
d'ailleurs c'est pas uniquement un non-choix dérivé de svn (parce que bon avoir un dépôt svn par projet ça aurait été tout à fait possible) c'est surtout un choix d'avoir un dépot commun et un usage des branches différent. D'ailleurs c'est ce qu'on trouve souvent sous le nom de Trunk Based Development.
Voici par exemple un article comparant les versions Google et Facebook : http://paulhammant.com/2014/01/08/googles-vs-facebooks-trunk-based-development/
Et si vous êtes curieux il y a beaucoup de ressources sur le sujet sur le site de Paul Hammant : http://paulhammant.com/categories.html#trunk_based_development
Mouai, ou alors il faudrait commencer par comprendre comment ils travaillent et pourquoi avant de juger.
[^] # Re: Mensongeries
Posté par El Titi . Évalué à 2.
La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes… Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens…
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.
[^] # Re: Mensongeries
Posté par CrEv (site web personnel) . Évalué à 2.
Et be… spa gagné
Nan mais sérieux
Utiliser du branching by abstraction n'a rien à voir avec l'outil de source hein… c'est pas fait pour combler un quelconque manque mais bien pour permettre d'offrir les features autrement ou d'avoir des migrations plus douces. Vraiment.
Heu, en quoi ? 1 dépôt commun ne va pas dire que tu n'organises rien, bien au contraire.
Encore moins, lorsque tout est dans le même dépôt il est plus simple (au pire simplement identique) d'utiliser un autre composant que si c'est des dépôts différents.
Alors là faut voir. C'est très variable comme affirmation. Je me suis déjà retrouvé avec des tonnes de dépôts différents (ben oui, un par projet / composant / lib) et c'est parfois juste une merde sans nom. Car lorsque tu fais un pauvre changement et que ça va impliquer des commits / tags / push / deploy dans 5 autres dépôts alors que si tout était au même endroit ça n'aurait rien demandé c'est juste horrible.
Peut-être que certains outils ne sont pas adaptés à faire autre chose que du trunk based development (encore que, même svn peut faire autre chose sans trop de problème). Mais aujourd'hui, avec les outils existant, ce type de choix ne dépend justement pas de l'outil. C'est une façon de développer, partager le code, gérer les fonctionnalités. Et c'est loin d'être juste pour les gorets.
J'ai peut-être mal compris, mais les deux cas permettent le déploiement en continu.
[^] # Re: Mensongeries
Posté par El Titi . Évalué à 2.
J'ai jamais dit le contraire. Relis-moi mais j'ai souvent entendu ce discours lorsque des devs SVN en détresse ne se sortaient pas d'un merge:
"Tfacon avec la CI on a plus besoin de branche."
"J'ai vu sur un forum que la feature toogling résolvait ce pb" , pour des applis mobiles niveau sécurité c'est top.
Tu peux appliquer des bonnes pratiques architecturales mais parfois un bon outil vient à la rescousse et les branches deviennent incontournables c'est tout.
Sauf que parfois des développeurs font des svn cp dasn tous les sens sans réfléchir aux conséquences de leur actes (surtout avec des equipes de projet différentes) et tu te retrouves avec du code d'un module qui n'a rien à faire à cet endroit et là le cauchemar commence pour s'y retrouver. Ca arrive moins si tu as des dépôts disjoints (ou alors à moins de forcer tout ca avec des hooks. SVN est déjà un monstre de perf.)
Sinon le trunk based development est un workflow et ne dépend pas de l'outil mais du contexte (architecture, type de produit, équipes, …)
A un moment le trunk based montre ses limites si tu ne peux pas mettre en place le feature toggling.
Tu devras forcément créer des branche d'intégration pour une livraison même en agile (effet mini waterfall avec scrum décrit ici par exemple).
Le seul moyen de déployer en continu de manière fiable est de garder ton trunk toujours propre et d'implémenter chaque feature dans sa branche (parfois locale pour les DVCS) puis de l'intégrer et la livrer dès qu'elle est prête (cf lien sur Github plus haut) et non pas groupée avec d'autre lors de la prochaine livraison (sprint par exemple).
[^] # Re: Mensongeries
Posté par CrEv (site web personnel) . Évalué à 2.
Ok, j'ai du prendre le message de travers alors ;-)
De ce que j'ai compris (enfin j'espère ;-)) tu critiques surtout ceux qui voient dans le trunk based un outil magique pour corriger la nullité de svn ? (ou des devs qui font des svn cp ;-)), c'est ça ? Dans ce cas ok, je comprend bien, mais au final c'est juste un problème d'incompétence, pas de workflow :-)
Ça par contre, c'est certains. Et d'ailleurs c'est dommage, si on pouvait avoir les deux ça serait cool :-)
Heurk
[^] # Re: Mensongeries
Posté par El Titi . Évalué à 2. Dernière modification le 10 janvier 2014 à 15:52.
C'est bien ça.
Relis le lien que je t'ai donné qui fait la différence entre le continuous deployment et les approches agiles traditionnelles (Scrum) .
Avec les méthodes agile les livraisons ne sont pas conditionnées par le périmètre fonctionnel mais par le découpage du temps. On peur revenir sur ce périmètre mais pas sur la date de livraison (sprint). Les équipes ont parfois tendance à repousser les efforts d'intégration et de test à la fin (même avec de la CI derrière). Parfois elles sont à la bourre et bizarrement la course à l’échalote recommence comme au bon vieux temps du cycle en V. Et là ca y va à cou de branches temporaires ou de revert pour virer des stories … c'est l'effet mini-tunnel décrit par l'auteur.
Si on se met dans l'état d'esprit d'accepter que chaque User story complétée est potentiellement déployable (continuous deliveries) ou "pire" si l'on sait qu'elle est vraiment livrée (continuous deplopyment) dès qu'elle est prête pplutôt que de la grouper avec d'autre, alors plus d'effort d'intégration à la dernière minute.
Pour assurer ca, il faut pouvoir facilement désactiver une feature tant qu'il y des commits intermédiaire et que la story n'est pas complète ou de corriger rapidement (pas facile avec une appli dont on ne maîtrise pas le déploiement comme les applis mobiles).
Quand on ne peut pas garantir ça. Le seul moyen qui reste est donc une branche par feature qu'on intègre par merge d'es qu'elle est complétée même si c'est décrié par les agilistes puristes.
Pour assurer la CI. On peut automatiser le merge de chaque commit sur le trunk vers chaque branche de feature.
S'il casse le build, il faut la corriger illico. Du coup on reste en contact avec le trunk et plus de Big Bang merge.
voir ici :
http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow
[^] # Re: Mensongeries
Posté par groumly . Évalué à 1.
Bopf. Tu sers un fichier de config JSON, ton appli le charge au demarrage, et le recharge toutes les 15-30 minutes, t'embeddes une config par defaut dans ton binaire et tu l'as ton feature toggling.
T'as effectivement des cas ou une feature pose probleme (un truc qui demarre au tout debut de l'appli par exemple), mais t'as ta config par defaut pour ca.
Le seul vrai probleme que tu vas avoir c'est une feature en beta qui va rester en beta sur des devices qui ne sont pas mit a jour, mais c'est pas trop un probleme de feature flag ca, tu l'as aussi sur tes features bau.
En pratique, c'est tres chiant a faire pour une autre raison: ca peut sacrement augmenter la complexite de ton code, et le niveau de polish attendu d'une appli mobile est vachement plus eleve que celui d'un site web. Du coup ca fait chier tout le monde, et on pousse fort pour la livrer de base.
Sans compter que les delais entre release sont vachement plus longs - tu passes de qq heures/jours, 2 semaines max dans le web, a 4 a 6 semaines pour les plus applis les plus actives. Ca te donne de la marge pour sortir une feature de beta.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mensongeries
Posté par El Titi . Évalué à 2.
Le lien que tu montres semble corroborer mes propos.
Pour Google, il y a des projets complètement différents qui sont géré sous un même dépot Perforce, qui comme SVN
utilise "l'inter-file branching model" voir (Eric Sink paragrahe "two banchin models") mais qui contrairement a SVN sens sort mieux dans le name tracking lors des merge.
Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.
Git et Hg utilisent l'autre modèle dans lesquelles les branches sont des méta-données gérées par l'outil et sont distribués.
Il est donc impératif d'isoler les modules disjoints dans leur dépôt et de ne réserver le depôt unique que pour le code fortement couplé. C'est pourquoi j'expliquais comment transposer le branching ala SVN sous Git (solution 2)
Après c'est vrai que ce n'est peut-être pas la situation de FB mais si tu me relis bien tu verras que j'avais mis les balises pour les taquiner (trollday).
Pour Clearcase, le schéma que l'auteur présent est celui proposé par la surcouche UCM de Cleracase, mais l'auteur ment en disant que c'est le workflow par défaut. Il est possible, mais le trunk bas est possible puisque ce n'est que la version simplifié du mainline. Qui dit simplifié dit recherche de simplicité. Et en effet c'est préférable. De même qu'il est préferable d'éviter les branches lorsqu'on le peut (http://martinfowler.com/bliki/FeatureBranch.html)en modifiant son architecture (http://martinfowler.com/bliki/BranchByAbstraction.html,
http://martinfowler.com/bliki/FeatureToggle.html,...) mais dans les 2 cas ce n'est pas toujours possible.
[^] # Re: Mensongeries
Posté par cosmocat . Évalué à 2.
Dans ce genre de contrôleur de code source, merger devient un enfer!
Il faut bien comprendre que quelque soit le contrôleur de source utilisé, brancher n'est JAMAIS un problème. C'est merger (ou reporter des commits) qui devient un problème.
Et ceux qui ont cette stratégie de "early branching" où on recopie l'ensemble des fichiers dans un autre "répertoire" ont plus de difficultés à retrouver les modifications et à faciliter la gestion des branche (après branchement donc).
[^] # Re: Mensongeries
Posté par El Titi . Évalué à 3.
C'est bien pourquoi leur rhétorique est : "De toute manière, les branches c'est nul, ce n'est pas agile, ca va à l'encontre de la CI, …".
Bon argument, mais mauvais prétexte.
C'est ce que je m'évertuais à expliquer mais visiblement je n'ai pas été clair.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.