cosmocat a écrit 2112 commentaires

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.

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.

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).

Apparement, reposurgeon peut faire çà.

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 ;)

Tu as raison, il faut faire des cpold des répertoires .git et .hg…

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, …

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à

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)

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…

au vu du nombre de serveurs en activité, y'a-t-il ENCORE un besoin pour se genre de serveur en Europe? Le besoin est plutôt dans le reste du monde, non?

Surtout que dans la page "join", ils indiquent que les serveurs sont faiblement sollicités…

Dans OSX, y'a un truc qui est vachement bien (bon OK, c'est pas dans l'interface), c'est leur système d'init très similaire à systemd!

(Comme je suis en vacances ce soir, c'est comme si on est vendredi…)

Je ne sais pas vraiment à quoi c'est dû (enfin, c'est surtout que je veux pas lancer de troll) mais j'ai l'impression qu'on a affaire à une "clientélisation" du logiciel libre (pour le pire comme pour le meilleur)

Je ne peux pas donner un avis car je n'ai pas assez d'informations en main mais, pour modérer tes propos, il ne faut pas oublier que toute personne peut être "client" pour certains logiciel (où elle n'a pas les compétences ou le temps pour s'investir) et contributeur sur d'autres. Perso, en ce qui concerne les distrib, je suis un parfait "client" par contre je contribue à au moins 3 logiciels libres et je fais des rapports de bugs sur pas mal d'autres…

Après, c'est vrai qu'il ne faut pas cracher sur le travail des autres et savoir que quand on contribue pas, il vaut mieux rester humble (mais il est vrai que certains ne savent pas faire…).

J'ai essayé mais j'ai maintenant des problème de clé PGP :(

Dans ce lien donné précédemment : http://forums.fedoraforum.org/showthread.php?p=1680574#post1680574
des message indiquent d'utiliser l'option --nogpgcheck …
Je ré-essaierais dans 15 jours lorsque je rentrerais chez moi…

Ce genre de commentaire condescendant et sans aucun soupçon d'empathie (dans le sens, essayer de se mettre à la place de l'autre et ne pas voir le problème qu'avec tes yeux) me fera toujours rire…

Si tout n'est pas rose sur ce point chez Fedora, tu devrais tout de même te poser quelques questions je pense.

Ben, justement, je m'en suis posé. J'ai une install PARFAITEMENT standard sans changement de config ni dépot exotique. Donc mis à part cela, je vois pas…

Depuis Fedora Core 4, je du reinstaller en moyenne toutes les 4/5 versions, uniquement par aquis de conscience et souvent après avoir fait l'upgrade. Jamais une upgrade n'a foirée.

L'argument, par ce que j'arrive à le faire sans problème n'implique pas forcement que ça marche tout le temps…

Il suffit de deux choses: lire la doc correctement

J'ai fait et justement, c'est le cas nominal qui marche pas!

et éventuellement ne pas upgrader 2h après l'annonce histoire que les éventuels bugs restant soient trouvés.

C'est ce que je fait d'habitude mais il s'avère que j'ai pas trouvé le temps de mettre à jour vers la version précédente et j'ai profité du temps libre que j'avais avant de partir en vacances pour essayer. Il s'avère que j'ai pas réussi, d'où mon message…

Et si tu penses que la QA c'est de la merde, tu les as testé les beta ?

c'est bien de citer que les parties d'un commentaire qui permet de faire avancer ses idées. Le titre et la 1ère ligne du commentaire aurait du te permettre de comprendre que je n'ai peut-être pas le niveau de tester un beta car si ça foire, je ne pense pas pouvoir remettre le système d'aplomb. Et également que je ne suis peut-être pas en mesure de faire un rapport de bug intéressant (même s'il m'arrive d'en faire sur d'autre logiciels).

Et un commentaire comme cela :

Depuis Fedora Core 4, je du reinstaller en moyenne toutes les 4/5 versions, uniquement par aquis de conscience et souvent après avoir fait l'upgrade. Jamais une upgrade n'a foirée.

me fait doucement rire lorsqu'il arrive après la bataille et qu'on sait maintenant que c'est un bug dans fedup qui fait que l'install ne marche pas…

PS : j'espère que ce commentaire t'auras au moins appris à prendre les gens un peu moins de haut…

j'avais pas installé fedup-dracut, mais après un nouvel essai, ça change rien…

En tout cas, pour moi, elle porte bien son nom :(

Je suis un utilisateur de cette distrib sans grande connaissance technique de linux.
Et j'ai toujours trouvé que les mises à jours pour fedora, c'est un peu le bordel. Il y a plusieurs façon de faire (fed up, preupgrade, yum) et on sait pas quelle est la bonne.
Depuis que je suis sur fedora (la 13, je crois), j'ai toujours eu une bonne raison de refaire une install complète.
Seulement, pour le passage de la 18 vers la 19, je souhaitais faire une mise à jour pour faciliter le passage à la version. N'ayant pas cherché la solution plus que çà, je n'ai finalement pas mis à jour.

La sortie de la 20 étant un bon moment pour me lancer, j'ai essayé :

• fed up. Tout se passe bien (màj des dépot, téléchargement des paquets, …) jusqu'au reboot pour faire la mise à jour et là y'a surement un problème qui fait que ça reboot aussitôt sans rien faire et je me retrouve avec mon ancienne version. Je sais pas où trouver les logs :(

• preupgrade (ensuite) qui me dit qu'il n'y a pas de version plus à jour (surement à cause de fed up).

Du coup, je suis bloqué sans savoir quoi faire et la mise à jour ne fonctionne pas…

Effectivement, c'est un GROS problème de jouabilité çà…

Il y a pas très longtemps, un doodle de Google avait ce problème là : http://www.google.com/doodles/doctor-whos-50th-anniversary

Peut-être faudrait-il changer l'angle de vue pour voir un peu plus d'au dessus sans pour autant être complètement en haut, non?

Pourquoi pas, ça peut être utile pour mieux comprendre le brol.

Je suis pas certain. Quand tu veux comprendre un outil, il faut des fois rechercher des messages d'erreur sur le web. Et si ton message est localisé, t'as du mal à trouver.

Pour moi, la traduction est SEULEMENT pour ceux qui ne parlent pas DU TOUT l'anglais.

PS : Et pourtant, je suis le traducteur français d'une des IHM de Git. Je continue à l'utiliser en anglais (et le conseille fortement à mes collègues) même si je suis l'auteur de la traduction française.

Avant même d'avoir lu la dépêche, je me suis dis que la vue isométrique, c'est vraiment pas le bon choix…
Et, Oh!, grande surprise :

les graphismes ont été bien accueillis, même si le choix de la vue isométrique perturbe dans un premier temps ;

Le caractère essential du package sysvinit me semble raisonnable contenu compte tenu de l'historique des unix et la compatibilité à avec l'existant. Rien n'empêche personne d'installer systemd s'il le veut.

Tiens, en parlant de choix, il y a une date butoir à laquelle Debian a prévu de faire son choix?
Ou là encore, ils ont le choix…

On peut savoir ce que tu développes pour avoir un meilleur contexte de quoi tu parles?

Tout à fait. Il suffit même d'être juste 2 pour que ça permette une revue de code assez facile…

Aussi, e fait de brancher et merger ajoute de l'information et permet une meilleure recherche de régression lorsqu'on a besoin de plonger dans l'historique…

Je me suis rendu compte que les workflows git à base de beaucoup de branches sont un peu sur-côtés. Ils fonctionnent peut être très bien pour des très gros projets mais dans l'ensemble les forks github suffisent largement.

C'est ton choix des version supportées qui va impliquer le choix que tu vas faire au niveau de ton worklow git. Si tu dois faire du support (avec correctifs) sur de nombreuses versions, je ne pense pas que des workflow comme gitflow soient sur-côtés. Je ne pense pas qu'un éditeur de logiciel serait du même avis…

Il s'avère juste que tu es pile dans le cas du développement d'un service web donc tu peux te permettre de n'avoir qu'une seule version maintenue car tu n'as qu'une seule version en prod à un moment donné. Dans ce cas, n'avoir qu'une seule branche master dans laquelle tu merges tes feature branches (workflow github) est effectivement largement suffisant (jusqu'à ce que tu doives faire un changement 'cassant' dans ton architecture et que pendant ce temps tu doivent continuer à développer la version courante…)

Ah, bon! Debian a choisi l'init systemd !?!

S'il y a UN SEUL lecteur audio disponible sous windows qu'il faudrait libérer, il faudrait plutôt faire une pétition pour http://www.foobar2000.org/