Journal Pijul, un nouveau gestionnaire de source

Posté par  (site web personnel) . Licence CC By‑SA.
37
18
sept.
2017

Ce nouveau gestionnaire de version est développé en Rust. Il reprend la même théorie des patches que darcs, mais en résolvant ses problèmes de performance.

Le développeur principal, Pierre‐Étienne Meunier, fait des annonces régulières sur r/rust, répond aux questions de manière très complète et y défend son bébé !

Le but ici n’est pas de traduire le manuel, je vous laisse découvrir les particularités de l’outil.

Chose rare, un papier devrait être publié d’ici la fin de l’année qui fournit les théorèmes, des preuves et la complexité algorithmique du programme.

Quelques liens supplémentaires :

Est‐ce que Pijul arrivera à faire parler de lui ? Il est encore un peu tôt pour le dire, même si la théorie derrière a l’air solide, il faudra que l’interface utilisateur soit simple et fasse justement oublier celle‐ci.

  • # Coquilles et fautes

    Posté par  . Évalué à 5.

    J'ouvre le traditionnel fil des corrections avec "annonces régulièreS", "son bébé" (pas de t), "qui devraiT", "A l'air solide" (pas À), "faSSe justement oublier celle-ci"…

  • # Merci pour l'info !

    Posté par  . Évalué à 9.

    Je vais regarder ça de près.

    Fanboy de Hg dès ses premières heures j'ai du m'incliner face à l'hégémonie de Git. Bien que satisfait dans les grandes lignes, je suis toujours obligé de regarder les man pages pour un certain nombre d'opérations dont je n'arriverai jamais, je crois, à me souvenir de leur fonctionnement exacte, git reset en particulier.

    J'utilise beaucoup aussi le rebase et je suis donc très curieux de voir ce que donne pijul dans un tel workflow.

    Bref merci pour l'info :-)

    • [^] # Re: Merci pour l'info !

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

      Fanboy de Hg dès ses premières heures j'ai du m'incliner face à l'hégémonie de Git.

      Utilisateur Mercurial depuis toujours, je ne me suis pas incliné à git :)

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

      • [^] # Re: Merci pour l'info !

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

        Utilisateur Mercurial depuis toujours, je ne me suis pas incliné à git :)

        Pareil, au pire j'utilise hggit pour interagir avec les moutons qui utilisent Git (qui a dit "broken by design"?)

  • # Un peu de marketing que diable...

    Posté par  (Mastodon) . Évalué à 2.

    Avec un nom pareil c'est pas gagné dans le genre pas évident à retenir. Et oui j'ai lu la FAQ et compris le pourquoi de ce nom mais ça n'y change rien.

    Jami: beabb2b063da0a2f0a2acaddcd9cc1421245d5de

    • [^] # Re: Un peu de marketing que diable...

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 19 septembre 2017 à 09:00.

      Moi je trouve ça pas mal. Ce n'est pas si facile qu'il y paraît de choisir un bon nom. Ce qui plaira à un francophone ne sonnera pas forcément bien à d'autres. Dans le cas présent, je pense que le nom passe bien dans beaucoup de langues. En français, il n'est pas difficile à retenir (ça ressemble un peu à pilule, l'orthographe est simple …) et le lire/dire 2 ou 3 fois devrait suffire à être à l'aise avec.

      Après c'est vrai que Crotophaga aurait été plus classe.

    • [^] # Re: Un peu de marketing que diable...

      Posté par  . Évalué à 6.

      Avec un nom pareil c'est pas gagné dans le genre pas évident à retenir.

      Consonne voyelle consonne voyelle consonne, 5 lettres, pas facile à retenir ?

      Même si la dyslexie va encore frapper et qu’on va entendre (et lire) quelques "piluj"… je trouve que tu exagères.

      • [^] # Re: Un peu de marketing que diable...

        Posté par  . Évalué à 3.

        Là ou ça va être lourd, c'est si la commande source est pijul: sur les claviers "classiques" (enfin, au moins les azerty/qwerty que je connais), ces lettres sont toutes sous la main droite, ça risque d'être douloureux en ligne de commande :)

        • [^] # Re: Un peu de marketing que diable...

          Posté par  . Évalué à 5.

          Raison de plus pour passer au bépo ;)

          Ça, ce sont les sources. Le mouton que tu veux est dedans.

          • [^] # Re: Un peu de marketing que diable...

            Posté par  . Évalué à 2.

            Ben non, il faudrait un clavier comme bépo pour le mexicain du coup la :D

            Enfin, c'est vrai qu'en bépo c'est mieux à écrire: il n'y a que le "pi" qui n'alterne pas les mains.

            • [^] # Re: Un peu de marketing que diable...

              Posté par  . Évalué à 8.

              Salut ! Je suis un des auteurs de Pijul, et je suis super en retard pour répondre.

              Ce nom est en effet horrible à taper, encore pire sur un clavier dvorak. Toutes les lettres sont sur la main gauche, sauf le "l" qui est sur l'auriculaire droit, ligne du haut. En plus la main gauche doit changer de ligne à chaque lettre.

              On a des idées pour le changer, parce qu'un plus il se prononce différemment dans toutes les langues. Les auteurs le prononcent comme en espagnol, mais les finlandais disent "piyoul", les anglophones "pidjoul", les français "pijul" (prononcé comme en français), et il existe sans doute plein d'autres variantes.

              Bref, ce n'est pas la priorité, mais on a des idées pour le changer (peut-être quand il deviendra 1.0).

              • [^] # Re: Un peu de marketing que diable...

                Posté par  . Évalué à 8.

                Bref, ce n'est pas la priorité, mais on a des idées pour le changer (peut-être quand il deviendra 1.0).

                De ce que j'ai entendu dire c'est pas forcement une bonne idee de faire ca "plus tard" car si, je l'espere pour vous, le projet commence a avoir un certains nombre d'utilisateur vous ne pourrez plus changer le nom ou vous allez en perdre en route!
                Mais je suis d'accord avec vous, le choix d'un nom c'est chiant!

              • [^] # Re: Un peu de marketing que diable...

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

                On a des idées pour le changer, parce qu'un plus il se prononce différemment dans toutes les langues. Les auteurs le prononcent comme en espagnol, mais les finlandais disent "piyoul", les anglophones "pidjoul", les français "pijul" (prononcé comme en français), et il existe sans doute plein d'autres variantes.

                Tu sais rien que Linux qui pourtant ne semble pas compliqué à prononcer a 3 manières différentes de le prononcer rien qu'aux États-Unis.

                Et je n'ose imaginer avec des noms plus complexes comme Debian, cela doit arriver fréquemment aussi.

                Bref, je pense qu'il ne faut pas s'arrêter à ça, les gens prononcent les marques de manière personnelle systématiquement, sauf si la publicité mondiale arrive à imposer la prononciation attendue.

    • [^] # Re: Un peu de marketing que diable...

      Posté par  . Évalué à 5.

      Sûr qu'ils vont pas nous faire avaler la Pijul aussi facilement !

  • # Bugs

    Posté par  . Évalué à 1.

    Est-ce que Pijul arrivera à faire parler de lui ? Il est encore un peu tôt pour le dire, même si la théorie derrière à l'air solide il faudra que l'interface utilisateur soit simple et face justement oublier celle-ci.

    Il a aussi intérêt, je pense, à avoir des fonctionnalités qui sortent du lot par rapport à git. Comme par exemple, un gestionnaire de bug intégré, ou un wiki (comme fossil par exemple).

    « 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: Bugs

      Posté par  . Évalué à 8.

      Beurk. Un wiki ou un bug tracker intégré ? Pourquoi ?

      À la rigueur, faciliter l'usage de ces outils, rajouter des moyens pour simplifier l'interfaçage, voir s'associer pour distribuer des packs complets, mais surtout pas une application fourre-tout.

      • [^] # Re: Bugs

        Posté par  . Évalué à 8.

        Beurk. Un wiki ou un bug tracker intégré ? Pourquoi ?

        Parce que ça permet de le distribuer avec les sources. Et si tu fork, Tu récupères tout avec.

        « 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: Bugs

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

          Ce n'est pas au gestionnaire de source de faire ça ! Je suis d'accord que ce serait mieux si github mettait les pages wiki et les bugs dans le repository (google code le faisait pour les pages wiki au moins).

          Mais ça doit rester en dehors du gestionnaire de sources dont ce n'est pas le rôle. Par contre, certaines fonctionnalités peuvent le faciliter (récupérer une sous partie du repository par exemple, éventuellement en lecture seule, ou interface de type système de fichier).

          Avoir des composants séparés qui sont intégrés dans une solution de plus haut niveau permet de changer les composants (et donc d'évoluer) plus facilement. En plus, ça peut permettre d'avoir le choix pour certains composants (tout le monde n'a pas les mêmes préférences pour la gestion de docs, de bugs, etc…)

          • [^] # Re: Bugs

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

            Je suis d'accord que ce serait mieux si github mettait les pages wiki et les bugs dans le repository (google code le faisait pour les pages wiki au moins).

            C'est le cas (dans un repository séparé): https://help.github.com/articles/adding-and-editing-wiki-pages-locally/

            Je trouve l'idée de Fossil d'intégrer le wiki et le suivi de bugs avec les sources intéressant pour faire un truc complètement décentralisé. Chacun travaille sur sa machine avec sa liste de bugs, son wiki qui est tenu à jour avec les sources, etc. Et on synchronise tout ça avec un push sur un serveur, par exemple.

            Je précise que je n'ai pas (encore) joué avec et que je ne sais pas comment ça se comporte en pratique. La solution retenue chez moi pour le moment est un dépôt git avec des pages vimwiki dedans, mais l'inconvénient est que vim est quasiment indispensable pour naviguer dans le wiki ou générer un rendu html.

    • [^] # Re: Bugs

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      Fossil non seulement a plein de fonctionnalités en plus (bug tracker, wiki, documentation, distribution de binaires non versionnés, gestion des utilisateurs, etc.) mais en plus il est beaucoup plus simple d'utilisation que git, plus léger, plus rapide, et ne prends pas la tête pour rien.

      Donc j'ai du mal à voir l'intérêt de ce nouveau venu. Des DVCS corrects et plus simples que git y'en a une palanquée, de Mercurial à Fossil.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Repos

    Posté par  . Évalué à 2. Dernière modification le 19 septembre 2017 à 11:24.

    • [^] # Re: Repos

      Posté par  . Évalué à 2.

      trouvé aussi https://github.com/8l/pijul vieux de 2 ans, avec lien vers le site mais… projet en Ocaml.

      Pijul était initialement écrit en OCaml, il a été ré-écrit en Rust au moment de la version 0.2 début 2016.

      https://nest.pijul.com/pijul_org/pijul

      L'inconvénient d'un VCS auto-hébergé, c'est que quand ça bug ça fout le bazar dans l'historique.

      • [^] # Re: Repos

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

        Pijul était initialement écrit en OCaml, il a été ré-écrit en Rust au moment de la version 0.2 début 2016.

        Qu'est-ce qui a motivé ce changement? Est-ce qu'il y a des choses plus faciles en Rust qu'en OCaml? Et réciproquement? Bref, si tu as choses à dire sur l'étape de traduction, que cela concerne la motivation, les difficultés ou les résultats, ça m'intéresse. :)

        • [^] # Re: Repos

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

          Il me semble que le principal inconvénient, à l'époque, d'OCaml comme choix a été le support sur Windows.

          Aujourd'hui, un effort constant par OCamllabs (en la personne de David Allsopp) essaye d'intégrer OCaml sur Windows. Cependant, cet effort a été entrepris après le choix de l'équipe de Pijul.

          Je suis le premier à être déçu de ce choix (que je comprends ceci dit) puisque Pijul aurait pu être un projet intéressant pour des problématiques courantes à l'éco-système d'OCaml et a des projets sur lesquelles je travaille. Mais bon, si j'ai le temps je pourrais m'y pencher et faire revivre l'implémentation en OCaml :D !

          • [^] # Re: Repos

            Posté par  . Évalué à 3. Dernière modification le 26 septembre 2017 à 12:02.

            Il me semble que le principal inconvénient, à l'époque, d'OCaml comme choix a été le support sur Windows.

            Et il semble bien qu'un bon support de Windows soit un critère essentiel pour pijul, ils ont même écrit leur propre bibliothèque ssh pour cela (openssh supporte mal Windows). Il y a peut être aussi des raisons liées à la performance, en particulier sur la gestion du parallélisme (les quelques libs que j'ai testées pour faire du map-reduce sont tout de même coûteuses en mémoire, ocaml-multicore devrait résoudre ce problème).

            Le mieux serait que pmeunier expose ses raisons, mais il est peut être passé à côté de la question.

            Mais bon, si j'ai le temps je pourrais m'y pencher et faire revivre l'implémentation en OCaml :D !

            Implémenter git en OCaml ne t'a pas suffit ! ;-D Tu vas devenir un spécialiste des systèmes de gestion de versions.

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Repos

              Posté par  . Évalué à 8.

              Le mieux serait que pmeunier expose ses raisons, mais il est peut être passé à côté de la question.

              J'ai bien vu la question, mais j'ai espéré jusqu'au bout qu'on n'allait pas me demander de commenter ce choix ;-)

              Comparer des langages de programmation est difficile, et il est facile d'être mal interprété. Je ne vais donc pas comparer, et seulement dire des trucs que j'aime bien dans Rust.

              • Windows est supporté comme une plateforme considérée comme standard par l'équipe de développement. Notre ambition, c'est de mettre le contrôle de version à la portée de tous, en restant aussi puissant que Git. Exclure les utilisateurs Windows nous éloigne de cet objectif.

              • La communauté Rust est géniale et croît rapidement, il est facile de parler de Rust en dehors de la France.

              • On peut écrire des trucs comme Sanakirja (le backend de Pijul) en Rust, qui a besoin de manipuler des chaînes de caractères sur la pile (sans avoir à écrire du C et des bindings).

              • Il y a une vraie culture crypto dans la communauté Rust, ce qui permet d'apprendre rapidement et de discuter.

              • Petits détails techniques : compiler des programmes en Rust est très facile, et il y a des threads (et personne pour nous expliquer que ce n'est pas la bonne façon de programmer).

              • [^] # Re: Repos

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

                Comparer des langages de programmation est difficile, et il est facile d'être mal interprété.

                Je n'ai pas jugé utile de le préciser mais je le fais à présent: loin de moi l'idée d'ouvrir une guerre de paroisses, ma question est tout à fait naïve – je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml. Donc du coup, merci beaucoup pour ta réponse!

                Il y a une vraie culture crypto dans la communauté Rust, ce qui permet d'apprendre rapidement et de discuter.

                Ça c'est un trait vraiment particulier, est-ce que tu sais l'expliquer historiquement?

                Petits détails techniques : compiler des programmes en Rust est très facile, et il y a des threads (et personne pour nous expliquer que ce n'est pas la bonne façon de programmer).

                Qu'est-ce qui ne vas pas avec les threads? Dans le cas de services dont le terme dominant de la performance est assujetti aux IO, l'approche alternative à la Lwt/NodeJS basée sur un thread système pour les IO, un thread système pour la logique de l'application, et des threads légers collaboratifs dans l'application et une échelonnement (“scalabilité” en bon franglais) horizontal pour monter en charge est maintenant bien mise à l'épreuve; mais c'est totalement hors de propos pour un gestionnaire de version, non? Du moins pour la partie client. ;)

                • [^] # Re: Repos

                  Posté par  . Évalué à 2.

                  Qu'est-ce qui ne vas pas avec les threads?

                  Peut être leur absence dans les normes C et C++ avant une version récente (par ex C11)

                • [^] # Re: Repos

                  Posté par  . Évalué à 3.

                  loin de moi l'idée d'ouvrir une guerre de paroisses

                  D'un autre côté, il a déjà du faire face à des commentateurs défendant git, il craignait peut être que ce soit pareil ici (d'autant que les guerres de chapelle entre langage peuvent être âpres).

                  Qu'est-ce qui ne vas pas avec les threads?

                  Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU. J'ai l'impression que la propriété de commutativité entre patchs indépendants se prête bien à la parallélisation des calculs. Il y a bien le projet ocaml-multicore (encore chez OCaml Labs) à base de fibres mais il en est encore au stade de la recherche (bien qu'il avance sûrement).

                  À l'heure actuelle, il faut forker (comme dans cet exemple du benchmark game) pour faire du map-reduce en parallèle, ce qui n'est pas des plus adapté comme solution.

                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                  • [^] # Re: Repos

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

                    Le parallélisme ? Les approches à la Lwt (ou Async) c'est pratique mais ça ne parallélise pas les calculs sur tous les core du CPU.

                    Je ne connais pas async, quant à Lwt il me semble qu'elle utilise la même approche que NodeJS (à moins que ce ne soit le contraire) en utilisant un deuxième fil d'éxécution (Thread lourd géré au niveau de l'OS par oppositions aux Threads légers implémentés par Lwt.) Comme je l'esquissais plus haut cette approche à le mérité de la simplicité au niveau de l'application dans les cas où le redimensionnement horizontal d'une application est possible, cela permet de travailler avec une variable simple, le nombre de processus, au lieu d'une grandeur composée par le nombre de processus auquel il fait adjoindre le nombre de fils d'éxécution. Évidemment, cela ne convient pas à tous les les problèmes.

                    Ceci dit je suis bien d'accord que la situation des Threads sous OCaml est loin d'être idéale mais j ne suis pas certain que la remarque à laquelle pmeunier fait allusion est spécifique à OCaml.

                • [^] # Re: Repos

                  Posté par  . Évalué à 3.

                  je ne connais absolument pas Rust et je suis curieux d'avoir des éléments de comparaison concrets avec OCaml.

                  Ok. J'ai oublié aussi autre chose : Rust n'a pas de GC, mais un système de propriété des variables qui est très marrant à utiliser.

                  Sur les threads: "ce n'est pas la bonne façon de programmer" est bien le genre de réponses auquel je faisais référence. Même les téléphones portables ont des tas de cœurs, et la communauté OCaml est encore en train d'expliquer à qui veut l'entendre que ce n'est pas la bonne façon de programmer.

                  • [^] # Re: Repos

                    Posté par  . Évalué à 4.

                    Rust n'a pas de GC, mais un système de propriété des variables qui est très marrant à utiliser.

                    Il me semble qu'il y a avait un GC dans les débuts de Rust, puis ils l'ont retiré. Felix Klock (membre de l'équipe en charge des nouvelles fonctionnalités du langage) a écrit une série d'articles intéressante sur le sujet :

                    Pour ce qui est du multi-cœur en OCaml, c'est justement le GC qui pose problème. Xavier Leroy et Damien Doligez avaient écrit un article en 1993 A concurrent, generationnal garbage collector for a multithreaded implementation of ML qui était resté lettre morte avant de servir de base au projet OCaml-multicore. Comme pour pijul, cela pose pas mal de problèmes théoriques qui doivent d'abord être pleinement résolus avant d'avoir plus qu'un prototype. Le projet avance, mais au rythme de la recherche… ;-)

                    Même les téléphones portables ont des tas de cœurs, et la communauté OCaml est encore en train d'expliquer à qui veut l'entendre que ce n'est pas la bonne façon de programmer.

                    J'avais donc vu juste au niveau des besoins de parallélisation ? Je dois reconnaître que j'ai aussi du mal à comprendre la réaction d'une partie de la communauté quand elle explique que ce n'est pas la bonne façon de programmer.

                    Il y a bien des bibliothèques pour le parallélisme, comme functory, mais elles profiteraient d'un GC adapté au multi-cœur. Je m'étais servi de cette dernière pour faire le test du benchmark game sur les GC et ça rivalisait avec Rust (mais j'ai dû tuner le GC pour arriver à égaler les performances en temps CPU et c'était coûteux en mémoire).

                    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                    • [^] # Re: Repos

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

                      J'avoue que pour le coup, j'ai du mal à cerner cette communauté qui ne veut pas d'OCaml-multicore ou même des outils disponibles aujourd'hui comme Lwt ou Async.

                      Après, je peux tout de même essayer de faire une proposition de réponse sur ce qu'est OCaml pour pas mal de gens encore. C'est un langage à PoC ni plus ni moins qui permet de faire l'état de l'art à des concepts qu'on ne retrouve que sur papier. En cela, l'ambition de pas mal de gens qui utilise (utilisait) OCaml n'était que de parvenir à un résultat qui les satisfasse et pas forcément en phase avec ce qu'une communauté attendrait d'eux.

                      En cela, l'intérêt de s'occuper du multi-threading dans les programmes Caml serait une tâche au mieux nécessaire si la mise à l'échelle ne fonctionne pas - et comme le souligne kantien, OCaml a de très bonne performances, donc cette question ce pose rarement - ou au pire trop coûteux en temps et développement pour s'y atteler.

                      Mais à l'opposé de cela, une communauté (plus industrielle) souhaite créer et utiliser des outils et les questions sur le multi-threading interviennent donc (notamment puisque le problème de la mise à l'échelle, dans un contexte industrielle, ce pose de facto). Mais pour cela, il faut un peu se désaliéner du milieu de la recherche et plutôt côtoyer les acteurs industriels de la communauté OCaml - qui n'ont qu'un avis trancher entre Lwt/Async mais pas sur la question du multi-threading vu la proportion de projets utilisant ces librairies.

                      Après, de mon point de vu, je trouve ça plutôt cool qu'il est des gens (qui sont en général pas si bêtes) pour s'offusquer du multicore car ça laisse toujours des questions et réponses intéressantes sur l'intérêt du multicore qui, à mon sens, n'est pas systématique. En cela, la problématique est prise avec des pincettes pour satisfaire le plus grand nombre sans partir tête baissé sur une implémentation duquel un bon nombre de la communauté n'y serait pas regardant.

                      Les extrêmes ne sont jamais bon et dieu sait qu'il y en a dans la communauté OCaml - et c'est toujours drôles de lire les mailing lists - mais si on arrive à cristalliser ces clivages et à en produire quelque chose qui satisfait tout le monde, ça peut prendre du temps et beaucoup de patience, mais le résultat n'en sera que meilleur.

                      • [^] # Re: Repos

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

                        Après, de mon point de vu, je trouve ça plutôt cool qu'il est des gens (qui sont en général pas si bêtes) pour s'offusquer du multicore car ça laisse toujours des questions et réponses intéressantes sur l'intérêt du multicore qui, à mon sens, n'est pas systématique. En cela, la problématique est prise avec des pincettes pour satisfaire le plus grand nombre sans partir tête baissé sur une implémentation duquel un bon nombre de la communauté n'y serait pas regardant.

                        Je ne veux pas parler pour les gens qui sont farouchement opposés au multicore puisque je n'en fais pas partie. Cependant je peux faire quelques remarques qui tendent a relativiser l'importance de la disponibilité d'un système tirant partie des multiples cœurs.

                        Dans mon expérience professionnelle, j'ai eu à travailler sur des systèmes avec beaucoup de cœurs (environ 200) pour faire du calcul numérique (finance) et pour tirer pleinement parti de ce genre d'équipement il ne faut pas seulement paralléliser les calculs mais aussi travailler sur la localisation des données en mémoire pour éviter les mouvements de cache trop importants qui pénalisent grandement l'application. On peut bien-sûr faire du calcul numérique en OCaml ou dans n'importe quel langage de haut niveau et faire attention à la localisation des données mais certaines fonctionnalités des plateformes (de type OpenMP) sont plus faciles à utiliser dans certains langages, et puis il y a tout un écosystéme historique, comme des logiciels scientifiques (Mathematica il me semble) qui peuvent émettre du code C etc., ce qui dans l'ensemble fait qu'il est assez naturel dans ce contexte d'écrire la fonction de calcul dans un langage bas niveau et de faire un binding vers le langage de haut niveau – d'autant qu'il est relativement facile d'écrire ce type de bindings pour OCaml et Lisp, que Python est quasiment conçu “par design“ comme un langage facilement extensible en C++. (Lua a aussi une FFI très facile à utiliser mais je n'ai pas encore entendu parler de gens qui font du calcul scientifique en Lua.)

                        Le type d'application numérique qui demande un grand nombre de cœurs sur une machine donnée est assez spécifique, il faut que le calcul utilise abondamment toute la structure initiale, autrement il est plus avantageux de faire tourner le calcul sur plusieurs machines. Pour prendre deux exemples simples, un calcul du premier genre est le calcul du carré d'une grosse matrice carrée. On peut faire un calcul par blocs en parallèle, mais cela n'est pas facile à délocaliser parceque, si par exemple si on fait 4 blocs de même taille, il faut transférer 3/4 des données pour obtenir 1/4 du résultat (et plus le nombre de blocs augmente, pire le ratio est!). Un calcul du second genre sont les calculs exploratoires faits sur une classification, où chaque fil va faire un calcul très complexe sur une petite donnée ce qui se parallélise facilement sur des machines différentes (pas forcément facile ou judicieux de louer une machine à 200 cœurs en comparaison de la location de 100 machines à 2 cœurs).

                        En dehors du calcul scientifique une autre application du calculs en parallèle est l'écriture de serveurs. L'approche consistant à écrire un serveur monofil dont on fait tourner un grand nombre de copies derrière un répartiteur de charge offre tellement d'avantages (logique d'application plus simple, circonscription a priori des erreurs, bugs plus facilement reproductibles, déploiement plus facile à redimensionner) qu'à la condition qu'il ne pose pas de problème de synchronisation particulier, c'est souvent la solution privilégiée.

                        Pour revenir au cas particulier de pijul je n'au aucune idée des algorithmes mis en jeu ni des structures de données utilisées donc je ne peux pas juger de l'avantage que ce logiciel peut tirer ou non du parallélisme léger (par opposition au fork & IPC) sur une architecture multicœur, mais dans ma petite expérience personnelle les problèmes pour lesquels ce type de parallélisme est bien adapté sont plutôt une niche qu'une généralité – surtout parceque pour que cela soit vraiment efficace il y a un travail considérable à faire sur les structures de données, travail d'autant plus critique sur les machines grand public qui ont souvent moins de mémoires cache que de cœurs. Ce n'est pas que je sois contre OCaml multicœur – et j'ai d'ailleurs bien du mal à comrpendre qu'on puisse l'être – et je serai même ravi de jouer avec lorsqu'il sera là, mais il me semble particulièrement facile de surestimer les bénéfices qu'on peut retirer de ce genre de parallélisme.

  • # Pourquoi du théorie des patch c'est bien

    Posté par  . Évalué à 6.

    Je suis le développement de pijul depuis quelques temps et cet article n'évoque pas un (peut-être LE) point essentiel de pijul (alors que le lien vers le blog ne parle que de ça): pijul a un théorie correcte des patch. Pourquoi c'est important ? Avec git, svn, hg, etc (en gros tous sauf pijul ou darcs), on peut faire un merge de deux codes et se retrouver avec un code inattendu sans conflit. Qu'est-ce que l'on entend par inattendu ? Idéalement il faut lire le blog, sinon ce lien donne un explication visuelle. De la façon dont je vois ça, c'est du même ordre que la différence entre un langage dont le système de type est "sound" (O'Caml, Rust dans le fragment sûr par exemple) ou "unsound" (C, C++, Java, la plupart en fait). Certes on peut tout faire en C/C++/Java mais on peut écrire des choses qui n'ont pas de sens ou ne produisent par le résultat escompté, exemple en Java. Bien sûr être sound/unsound ne suffit pas à être un bon ou un mauvais langage et comme la plupart de ces choses, ce n'est souvent pas le candidat le meilleur techniquement qui gagne. Cela dit on peut espérer un jour avec des langages et DCVS qui sont agréables à utiliser ET corrects.

    • [^] # Re: Pourquoi du théorie des patch c'est bien

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

      J'ai préféré laisser les curieux aller fouiller les liens plutôt que de dire des bêtises, ça reste assez difficile à expliquer.

      Merci d'avoir pris le temps de détailler les différences avec un DVCS classique.

    • [^] # Re: Pourquoi du théorie des patch c'est bien

      Posté par  . Évalué à 3.

      Ce genre de soucis est supposé être repéré par les tests unitaires et/ou les participants aux revues de code. Honnêtement, ce genre de cas se produit très rarement en java parce qu'il n'y a pas un pan énorme du langage et des libs qui permette de faire des choses stupides dans ce genre, les effacements de types et autres joyeusetés.

      Effectivement, un merge git peut donner des incohérences vu que git gère les conflits fichier par fichier. Ça ne veut aucunement dire que l'ensemble est fonctionnel, seuls des tests peuvent le prouver.
      Sur le côté cohérence de git, git n'oblige pas à être cohérent sur le repo, car on considère que ce n'est pas son travail. Les commits et les branches, c'est le travail des développeurs et intégrateurs. Git ne force pas de workflow spécial ou de logique, d'où la prolifération des workflows d'utilisation de git. Si le graphe des commits ne ressemble à rien sous git, faut disputer les devs qui n'y prêtent pas attention. Exemple concret : l'équivalent d'un svn update est un git pull --rebase et il faut donc éduquer les devs sur la bonne commande à utiliser pour ne pas pourrir l'historique.

      Pour en revenir à pijul, malgré leurs bonnes idées, j'ai du mal à lui trouver des atouts suffisants. C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).

      • [^] # Re: Pourquoi du théorie des patch c'est bien

        Posté par  . Évalué à 3.

        En effet, je ne dispute pas le fait que de toute façon il faut toujours regarder le résultat d'un merge. Mais je ne pense que pas qu'il faut voir pijul comme un projet qui veut remplacer git. L'idée c'est plutôt d'expérimenter avec un modèle différent.

        D'ailleurs je ne dirais pas qu'il y a pas que c'est futile. En problème typique en git qui n'existe pas en pijul et darcs: je fork master dans une branche X. Je fais plein de commits, de son côté master diverge. Puis je cherry-pick un commit de master très important dans X. Plus tard je merge X dans master: il y a un conflit car X est appliqué deux fois, git ne réalise pas que c'est "le même commit". Je recommande de lire les deux articles suivants qui expliquent bien les différences, cela ne concerne pas que les merge:
        merging et merging and pjiul (notamment "Case study 2: parallel development" pour l'exemple ci-dessus).

        • [^] # Re: Pourquoi du théorie des patch c'est bien

          Posté par  . Évalué à 5.

          Plus tard je merge X dans master: il y a un conflit car X est appliqué deux fois, git ne réalise pas que c'est "le même commit".

          Dans 90% des cas, git va réaliser que c'est le même commit (cf. git-patch-id(1)). Dans 9% des cas où il bloquera, on se rendra compte que le merge n'est pas si « évident » que ça en pratique, et peut-être qu'il va même nécessiter de le re-travailler. Et dans 1% des cas, peut-être que oui, il aurait pu s'en rendre compte et le faire tout seul mais n'y arrivera pas. Et pour augmenter encore la possibilité de résolution, utiliser git-rerere(1).

          Bref, pour 99% des cas qui concernent ce problème précis, git va être le meilleur en pratique. Et vu que ce problème n'est pas rencontré si souvent, dans 99,999% des cas d'utilisation de git en général, il sera supérieur. À moins que tu arrives au même niveau sur tout le reste de git : fiabilité, communauté, évolution, rapidité, etc.

          Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique. Oui, c'est mieux quand un outil semble « parfait » jusqu'au bout, mais pour ce problème en particulier je pense qu'on n'arrivera jamais à une jolie théorie des patchs qui n'ait pas des perfs de merdes et une complexité ahurissante, tout ça pour un gain très très minime.

          Bon courage pour l'expérimentation en tous cas, ça doit être marrant à coder !

          • [^] # Re: Pourquoi du théorie des patch c'est bien

            Posté par  . Évalué à 10.

            Ça n'est pas pour te décourager, tu dis toi-même que c'est un projet d'expérimentation, et c'est très bien. Dire que la théorie des patchs, « c'est bien », oui, peut-être, mais je ne vois pas en quoi en pratique ça changera quoi que ce soit : l'exemple donné dans ton premier commentaire est complètement tiré par les cheveux et n'arrivera jamais en pratique.

            Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel, même open source, et même en passant les reviews et les tests : aucun test unitaire ne peut garantir l'intégralité d'un code, et d'ailleurs toutes les failles de sécurité qui arrivent (on en découvre tous les jours presque partout) avaient échappé aux tests unitaires dans 100% des cas (encore mieux que 99,999%).

            Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.

            Il n'est pas 100% honnête (et même pas 99,999% honnête) de dire "Git est supérieur" en oubliant les questions essentielles du temps d'apprentissage et du passage à l'échelle sur de gros dépôts et de grosses équipes.

            Dans la vraie vie, on a parlé avec pas mal de monde depuis qu'on a commencé ce projet, et on a déjà entendu (assez rarement quand même) ce "je comprends tout Git, et c'est tellement mieux que votre truc que je ne vais même pas aller regarder ce que c'est".

            Par contre, on ne l'a absolument jamais entendu des gens avec qui on a parlé qui travaillent sur de très gros trucs (par exemple chez Apple ou Facebook, ou même des gens qui gèrent les dépôts du noyau Linux).

            Et on soupçonne un tout petit peu que les gens qui nous disent ça "oublient" en général de mentionner qu'ils ont passé 10 ans à essayer de le comprendre, lus des quantités ahurissantes de livres, de blogs et de manuels pour essayer de forcer Git à rester dans les clous des axiomes que Pijul garantit au débutant qui fait son premier dépôt avec un pote, sans avoir la moindre idée de ces trucs ni de notre théorie.

            • [^] # Re: Pourquoi du théorie des patch c'est bien

              Posté par  . Évalué à 3.

              Oui, sauf que ce problème peut être utilisé pour créer des failles dans un logiciel

              Mouarf, avec ton exemple, là ? Je veux bien un exemple concret, pour moi ça reste un cas irréaliste.

              Sur les autres avantages et "Git va être le meilleur", c'est un peu ce qu'on disait de SVN quand Git est sorti.

              Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds » et même s'il était difficile d'accès, très vite les gens ont reconnu sa supériorité (et les problèmes de SVN) même si on imaginait une période de transition pendant laquelle SVN allait rester encore présent. Mais j'ai rarement vu un soft prendre de l'ampleur aussi rapidement que git !

              Il n'est pas 100% honnête (et même pas 99,999% honnête) de dire "Git est supérieur" en oubliant les questions essentielles du temps d'apprentissage et du passage à l'échelle sur de gros dépôts et de grosses équipes.

              Oui c'est vrai. Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.

              Par contre, on ne l'a absolument jamais entendu des gens avec qui on a parlé qui travaillent sur de très gros trucs (par exemple chez Apple ou Facebook, ou même des gens qui gèrent les dépôts du noyau Linux).

              Chez Facebook & co, et dans les entreprises en général, il y a des contraintes particulières qui font qu'il est moins adapté, mais ce sont pour moi de mauvaises raisons : soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration et on le tord pour en faire un outil d'intégration et ça marche mal, soit on fait des trucs crades parce que « on n'a pas le temps » et du coup ça foire parce que les branches deviennent n'importe quoi. Bref, oui, git impose une certaine méthodologie de développement (bien qu'il n'impose pas de workflow particulier), et c'est celle qui est au cœur du Libre : indépendance, fonctionnalités bien isolées (il y a d'autres outils pour l'intégration), et nécessité d'être plutôt propre et maintenable car c'est le seul moyen d'être gérable quand peu de gens contribuent.

              C'est intéressant de se poser ces questions (même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique), mais je pense que ça a très peu à voir avec la théorie des patchs. Après, si tu veux t'atteler à la résolution des autres « défauts » de git, pourquoi pas, mais à ce moment-là ça n'est plus une histoire de théorie des patchs, qui semble pourtant être ton cheval de bataille ici.

              Et on soupçonne un tout petit peu que les gens qui nous disent ça "oublient" en général de mentionner qu'ils ont passé 10 ans à essayer de le comprendre, lus des quantités ahurissantes de livres, de blogs et de manuels pour essayer de forcer Git à rester dans les clous des axiomes que Pijul garantit au débutant qui fait son premier dépôt avec un pote, sans avoir la moindre idée de ces trucs ni de notre théorie.

              Je pense rentrer dans ta description, effectivement, même si elle est légèrement exagérée sur les besoins de maîtriser git comme il faut ; on y arrive avant 10 ans en général :-) Cependant, je suis convaincu que ça en vaut la peine. Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose…

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 4.

                Ah bon ? J'ai pas souvenir de ça. Dès le début, c'était le soft « codé par Torvalds »

                Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.

                Torvalds lui-même le considère comme très imparfait, même si je suis d'accord que Git a connu un développement impressionnant (j'ai l'impression que c'est en très grande partie grâce à GitHub).

                Mais étant partisan des courbes d'apprentissage paraboliques, j'estime que ça vaut le coup à long terme.

                Cependant, je suis convaincu que ça en vaut la peine.

                Je n'ai aucun problème à apprendre des trucs. Dans la vie, je suis chercheur : mon métier est d'apprendre des trucs qui n'ont pas de courbe d'apprentissage connue.

                Pour des outils standards et connus, je n'ai pas non plus de problème, mais seulement quand ça vaut le coup.
                Si tu as besoin d'exemples, regarde les langages qu'on utilise (Rust, Nix) et les dépendances de Pijul qu'on a dû écrire (Sanakirja, Thrussh).

                Par exemple, il est beaucoup plus difficile d'apprendre le monocycle que le vélo. Si l'objectif est de se déplacer, ton commentaire ressemble à "oui mais le monocycle est plus difficile à apprendre, donc il est forcément plus efficace".

                Pour les cas désespérés, il y a toujours https://git-man-page-generator.lokaltog.net/

                Alors que souvent, les soft plus abordables, c'est agréable à utiliser au début, puis quand on les maîtrise bien, ils deviennent limitants et on passe à autre chose…

                C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.

                Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.

                soit ça donne trop de liberté aux devs et les chefs n'aiment pas ça (git c'est vraiment pour que chaque dev soit complètement indépendant, c'est très présent dans son idéologie, ya pas à dire), soit ça n'intègre pas tout le nécessaire d'intégration

                Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts, parce qu'il a besoin de tout l'historique de tout pour fonctionner.

                Et ces gros industriels veulent de très gros dépôts parce qu'ils ont plein de projets interdépendants compliqués à compiler.

                (même si pour « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique)

                Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.

                • [^] # Re: Pourquoi du théorie des patch c'est bien

                  Posté par  . Évalué à 4.

                  Des gens ont effectivement dit ça, mais en pratique plein de projets et d'entreprises sont encore sous CVS.

                  Quel rapport avec git ? La réticence au changement en entreprise va parfois contre toute logique. Il y aurait le meilleur VCS au monde qu'ils resteraient à CVS…

                  C'est vrai dans plein de cas. Dans le nôtre, c'est plutôt l'inverse qui est vrai : Pijul est capable de reproduire tous les workflows possibles de Git, et peut faire des choses largement plus puissantes, tout en restant simple.

                  Alors j'avoue c'est bien présenté, et que ça donne envie d'aller voir. C'est bien d'avoir une certaine assurance comme tu le fais, et je vois que tu as la théorie derrière pour soutenir ton truc. Mais fais attention à ne pas voir toujours les défauts de git qui t'arrangent : tu pourrais passer à côté des choses géniales que tu ne remarques même pas. Genre le système sous-jacent exposé et exploitable, les formats de données simples et centraux, l'état du VCS exposé dans le filesystem, l'utilisation en shell facile (pas mal de fonctions de merge de git sont même juste du shell !). Plein de trucs sûrement « pas propres » et pas prouvés ni sûrs, mais qui le rendent génial.

                  Ce genre de trucs a déjà existé avant en informatique : dans les années 70, plein de gens adoraient la courbe d'apprentissage de leur langage préféré (et étaient très créatifs pour inventer de nouveaux langages obscures chaque semaine). Et à un moment, tout le monde s'est rendu compte que C offrait au moins la même puissance que les autres, en beaucoup plus souple et facile.

                  C'est drôle que tu prennes l'exemple du C, parce que justement il a une courbe d'apprentissage un peu rude quand même, il n'est pas parfait, et j'aurais donc fait le parallèle avec git…

                  Ce n'est pas du tout le principal problème de ces gros utilisateurs. Leur principale préoccupation est bien le passage à l'échelle : Git devient très lent sur les très gros dépôts,

                  Parce qu'il développent du soft d'une manière qui n'a aucun sens pour le libre. Souvent parce qu'ils ne veulent pas modulariser, parce qu'ils l'utilisent comme outil d'intégration, etc (c'est la liste que j'ai déjà citée). Et qu'aucun outil apportant les fonctionnalités de git ne pourra faire mieux en perf ; ils auront donc des très plus pourris, mais qui tiennent leur taille de projet. Ou alors ça serait une vraie révolution, mais j'y crois très peu. Pijul le serait, d'après toi ?

                  parce qu'il a besoin de tout l'historique de tout pour fonctionner.

                  Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git (je ne vois pas de doc, mais en gros tu peux mettre n'importe quel nombre de ref dedans qui permettent de cacher des parties de la hiérarchie ; ça fait partie des trucs avancés peu exploités mais qui donnent des idées).

                  Torvalds lui-même le considère comme très imparfait, (…) Tu as le droit d'être sceptique, mais dans la vraie vie plein de gens sont insatisfaits de Git, y compris son inventeur.

                  Ça fait deux fois que t'en parles mais je ne l'ai jamais entendu dire ça… source ?

                  • [^] # Re: Pourquoi du théorie des patch c'est bien

                    Posté par  . Évalué à 2. Dernière modification le 24 septembre 2017 à 07:50.

                    Peut-être ça :
                    https://framablog.org/2012/09/26/linus-torvalds-linux-git-fake/

                    (mais j'ai pas compris la fin, il semble que ça soit une blague).

                  • [^] # Re: Pourquoi du théorie des patch c'est bien

                    Posté par  . Évalué à 7.

                    tu pourrais passer à côté des choses géniales que tu ne remarques même pas.

                    Encore une fois, si on a commencé Pijul, c'est qu'on connaissait suffisamment bien Git pour en être insatisfaits.

                    Une partie des "avantages géniaux" que tu évoques sont utiles uniquement parce qu'ils permettent de compenser les problèmes posés par le manque de principes solides dessous.

                    Mais il y a aussi plein de trucs absolument géniaux dans Git ! Je n'ai jamais dit le contraite ! À commencer par la vitesse, designer des algos avec le potentiel pour le battre en vitesse a été vraiment intéressant.

                    Option « --depth » de git-clone, et pour aller plus loin voir le fonctionnement du fichier « shadow » dans le .git

                    Suggestion : suppose que les ingénieurs de Google et Facebook (et plus généralement les gens avec qui tu parles, dont moi) connaissent ces options quand ils disent ce type de trucs.

                    Les shallow clones améliorent un peu ce problème dans certains cas, en particulier ils permettent de compiler le projet, mais pas forcément de "travailler" sur le projet, comme par exemple de fusionner des commits qui ont divergé depuis plus longtemps que la profondeur.

                    Et chaque commit a besoin de calculer un hash de tout le dépôt, même si ce n'est que pour un seul fichier (j'imagine que ce n'est pas le principal souci, même dans une grosse instance).

                    C'est drôle que tu prennes l'exemple du C, parce que justement il a une courbe d'apprentissage un peu rude quand même, il n'est pas parfait, et j'aurais donc fait le parallèle avec git.

                    Je n'ai pas pris C au hasard. Encore une fois, la courbe d'apprentissage n'est pas toujours égale à la puissance de l'outil.

                    C est certes difficile à maîtriser, mais il est basé sur un petit nombre de concepts simples (fonctions, variables, pointeurs, préprocesseur) et orthogonaux, qu'on peut expliquer facilement, ce qui n'était pas le cas des langages d'avant.

                    Git a un point commun avec C, le petit nombre de concepts (branches, commits, trees).

                    Par contre, il est très différent de C sur deux points :

                    • ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.

                    • les relations entre ces concepts sont compliquées et floues, voire incohérentes : par exemple, les fichiers sont rebricolés à partir du contenu par des heuristiques, et les merges entre branches sont faits par 3-way merge, qui n'est pas associatif (pas associatif = des lignes ajoutées par Alice se retrouvent dans un morceau que Bob a écrit indépendamment).

                    • [^] # Re: Pourquoi du théorie des patch c'est bien

                      Posté par  . Évalué à 1.

                      Suggestion : suppose que les ingénieurs de Google et Facebook (et plus généralement les gens avec qui tu parles, dont moi) connaissent ces options quand ils disent ce type de trucs.

                      Eh bien qu'ils partagent leurs raisons. Les arguments d'autorité ne servent à rien, à part envenimer la discussion.

                      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

                      • [^] # Re: Pourquoi du théorie des patch c'est bien

                        Posté par  . Évalué à 4.

                        Eh bien qu'ils partagent leurs raisons.

                        Il y avait les raisons dans mes commentaires précédents, ce n'était pas un argument d'autorité.

                        Les arguments d'autorité ne servent à rien, à part envenimer la discussion.

                        Mon commentaire était en quelque sorte l'inverse d'un argument d'autorité : "ne jette pas les arguments de quelqu'un que tu ne considères pas comme une autorité, il y a plein de gens qui disent la même chose, on peut peut-être considérer leur opinion".

                      • [^] # Re: Pourquoi du théorie des patch c'est bien

                        Posté par  . Évalué à 9.

                        Ah bah ça tombe bien, ils l’ont fait:
                        https://m.cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext
                        https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
                        Tu peux aussi aller demander aux studios de jeux vidéos ce qu’ils pensent de git.

                        En gros, leur position c’est que plusieurs repo c’est une grosse erreur pour une grosse entité (C’est compliqué et ça apporte absolument rien, à part des emmerdes). Même dans une organization de taille moyenne, c’est un gros merdier à gérer (opengrok rend tout juste le,problème gerable).

                        Git à un parti pris très fort pour le multi repo, et n’est absolument pas adapté au mono repo.

                        Ca reste une philosophie qui peut se discuter, mais très honnêtement, d’un point de vue pragmatique, sorti de “ya que perforce qui soit capable de gérer un gros repo, et franchement, ça saoule de l’utiliser”, ya pas vraiment d’avantages du côté du multi repo. N’importe quelle boite de taille moyenne se retrouve vite avec plus de 100 repos, et c’est un enfer à gérer à quotidien ou sur le long terme.

                        Ce qui n’est absolument pas discutable est que git scale tres mal sur de gros repo. La question est “combien de boîtes atteignent cette échelle”, à l’heure des micro services, systèmes distribués et infrastructure as code, Ben je pense que la réponse est “beaucoup plus que ya 10 ans quand git est devenu populaire”.

                        Alors, ouais, le kernel tourne sous git, mais ça reste un projet de relativement petite échelle, essentiellement texte, qui avance assez lentement (3 mois entre chaque release, c’est très lent dans un monde de CD avec plusieurs releases par jour à une échelle de millions, voire centaines de millions d’utilisateurs).
                        C’est aussi un projet très yolo avec les pratiques qualité, qui délègue les tests aux autres.

                        Comme rare sont ceux qui ont les reins assez solide pour implémenter leur propre dvcs dans leur coin, Ben on fait avec. Mais ya clairement matière à détrôner git.

                        Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                        • [^] # Re: Pourquoi du théorie des patch c'est bien

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

                          Alors, ouais, le kernel tourne sous git, mais ça reste un projet de relativement petite échelle, essentiellement texte, qui avance assez lentement (3 mois entre chaque release, c’est très lent dans un monde de CD avec plusieurs releases par jour à une échelle de millions, voire centaines de millions d’utilisateurs).

                          Déjà le noyau a un cycle d'environ 2 mois, pas 3.

                          Et Linux, petit projet, sérieusement ? En 2 mois c'est entre 10 000 et 15 000 commits qui sont intégrés. Soit environ 8 commits par heure en moyenne, à tout heure de la journée. Le noyau grossi de près de 300 000 lignes de code (donc la différence entre suppression et ajouts) à chaque version. Et plusieurs milliers de codeurs y participent à chaque version. Pour un total de plusieurs millions de lignes de code.

                          Pour un projet indépendant (qui ne dépend pas d'autres modules donc), des projets de cette taille et qui évoluent si vite, tu n'en as pas beaucoup. Que ce soit des Logiciels Libres ou des projets internes en entreprise.

                          • [^] # Re: Pourquoi du théorie des patch c'est bien

                            Posté par  . Évalué à 4.

                            Et Linux, petit projet, sérieusement ? En 2 mois c'est entre 10 000 et 15 000 commits qui sont intégrés. Soit environ 8 commits par heure en moyenne, à tout heure de la journée. Le noyau grossi de près de 300 000 lignes de code (donc la différence entre suppression et ajouts) à chaque version. Et plusieurs milliers de codeurs y participent à chaque version. Pour un total de plusieurs millions de lignes de code.

                            relativement. Le kernel est énorme pour un projet individuel. Comparé a la somme de code totale d'une boite de taille moyenne, ya pas de quoi fouetter un chat non plus.

                            Oui, le projet est gros. mais c'est 99.9% du texte. 2 mois entre release c'est super long, Facebook fait 2 releases par jour. Et puisqu'on parle de Facebook/Google, ils ont plus de commit/changements en une année que le kernel en a eu depuis le debut. Et c'est pas que du texte, ya beaucoup de binaires la dedans aussi (images ou autres), vu qu'ils mettent absolument TOUT dans le meme repo.
                            N'importe quelle boite oriente consommateur avec un backend de taille raisonnable (on va dire qq années d'existence avec 5-10 millions monthly active) va rapidement taper dans l'échelle du kernel si tu pars sur du mono repo (et ya de très bonnes raisons de faire du mono repo). Ce genre d'échelle c'est plus que courant, en tout cas par ici.

                            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                            • [^] # Re: Pourquoi du théorie des patch c'est bien

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

                              C'est quoi le rapport entre le nombre de release par jour et le dépôt de version ? C'est git qui crée les paquets .deb/.rpm / construit les images Docker maintenant ? Première nouvelle.

                              Ah et oui un VCS c'est pas forcément idéal pour versionner des .psd de 500Mo, no shit Sherlock, heureusement que la nullité de git nous l'a appris !

                              • [^] # Re: Pourquoi du théorie des patch c'est bien

                                Posté par  . Évalué à 3.

                                Bel argument à 2 balles.

                                C'est pour ça que des boites s'évertuent à inventer des monstruosités comme Git LFS pour contourner les limitations d'un DVCS, tellement le fait d'avoir des gros repo qui peuvent contenir des artworks est un non sens.

                                Ne pas toucher au sacro saint, surtout.

                    • [^] # Re: Pourquoi du théorie des patch c'est bien

                      Posté par  . Évalué à 4.

                      Une partie des "avantages géniaux" que tu évoques sont utiles uniquement parce qu'ils permettent de compenser les problèmes posés par le manque de principes solides dessous.

                      Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ? Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ? Tu restes vague et ça ne me convainc pas.

                      Et chaque commit a besoin de calculer un hash de tout le dépôt

                      Heu… WTF ? Git ne recalcule jamais de « hash de tout le dépôt » ! Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici… C'est justement ce qui fait la vitesse de git, il a juste besoin d'aller chopper les objets en relation avec le(s) commit(s) précédent(s), et que tout est hashé et donc dépend pas du tout de la complexité de ton dépôt, mais légèrement du nombre d'objets.

                      ces concepts ne sont pas orthogonaux : par exemple, les commits sont souvent affichés (et représentés à l'intérieur) comme des patchs.

                      WTF2 ?! Git ne stock aucun diff lié à un commit : il a juste un algo de packing qui dé-duplique, mais sans aucune relation avec un commit donné. Ce dernier ne contient que des SHA1 du/des tree(s) référencé.

                      les relations entre ces concepts sont compliquées et floues, voire incohérentes : par exemple, les fichiers sont rebricolés à partir du contenu par des heuristiques, et les merges entre branches sont faits par 3-way merge, qui n'est pas associatif (pas associatif = des lignes ajoutées par Alice se retrouvent dans un morceau que Bob a écrit indépendamment).

                      Heu… oui, les « fichiers » sont effectivement juste du contenu et la liaison avec un path donné n'est pas reverse-trackée et juste trouvée par heuristique, mais c'est plutôt très clair et simple comme concept. Oui, ça fait que les copies et déplacement de fichiers avec modification sont suivis par heuristique, mais c'est très cohérent en fait : il n'existe de « vrai » lien entre deux fichiers modifiés et déplacés que dans la tête du programmeur, et vouloir tracker ça en plus du contenu va pouvoir amener à des difficultés qui font que git préfère simplement ne pas le faire. Oui, les 3-way merge ne sont pas associatifs, mais pareil, je ne sais pas si chercher absolument un sens à toute combinaison de patch ne va pas t'amener vers des problèmes simplement insolubles. Ou alors qui de toutes façons amèneront une telle complexité que personne n'en voudra.

                      Bref, pour quelqu'un qui dit très bien connaître git, je trouve certains de tes arguments légers. Après, je vois qu'on a une idée du design logicielle assez différente, et donc qu'on aura du mal à réconcilier nos arguments là-dessus, mais perso avec l'expérience (je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi, vu tes vidéos ;-)) je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.

                      • [^] # Re: Pourquoi du théorie des patch c'est bien

                        Posté par  . Évalué à 4.

                        Comment les avantages que j'ai cités seraient là pour compenser un manque de principe solide ?

                        Je te cite :

                        Genre le système sous-jacent exposé et exploitable, les formats de données simples et centraux, l'état du VCS exposé dans le filesystem, l'utilisation en shell facile (pas mal de fonctions de merge de git sont même juste du shell !).

                        En gros: trop bien, on peut aller le bricoler. Sauf qu'on n'a essentiellement besoin de le bricoler parce qu'on se retrouve dans une situation pourrie à cause du manque de théorie solide dessous.

                        Quels principes exactement, puisqu'ils ne sont pas en rapport avec la théorie des patchs, à priori ?

                        Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.

                        Pour quelqu'un qui me sort qu'il connaît git mieux que tout le monde ici

                        Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".

                        WTF2 ?! Git ne stock aucun diff lié à un commit

                        C'est vrai, j'ai écrit ça un peu tard et en décalage horaire, excuse-moi, ça fait bien longtemps que je n'ai pas regardé les entrailles de Git.

                        Ceci dit, ça n'enlève rien à mon argument, au contraire : le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.

                        Après, je vois qu'on a une idée du design logicielle assez différente

                        Plus de détails !

                        je trouve les concepts d'Unix, qu'on retrouve dans Git, vraiment géniaux.

                        Ce n'est pas exactement ce que j'ai dit dans mon commentaire précédent ? À part le fait qu'on ne retrouve à mon avis pas les concepts d'Unix dans Git, pour les raisons que j'ai déjà données, et que tu n'as pas vraiment commentées directement (à part à coups de WTF sur mes imprécisions techniques, et de "Git est mieux de toute façon").

                        je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi

                        C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.

                        • [^] # Re: Pourquoi du théorie des patch c'est bien

                          Posté par  . Évalué à 3.

                          je vais ajouter un argument d'autorité : tu as l'air plus jeune que moi

                          C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.

                          C’est aussi une bonne raison de dire f..k aux vieux et de faire ton rebel ;-)

                          Merci en tout cas de ta patience dans les échanges.

                          Un vieux :'(

                        • [^] # Re: Pourquoi du théorie des patch c'est bien

                          Posté par  . Évalué à 2.

                          Des principes, ce serait une liste d'axiomes que Git garantit à l'utilisateur. L'associativité serait un exemple.

                          On tourne en rond. Je te dis que git est génial pour des choses qui n'ont rien à voir avec la théorie des patchs, et tu me rétorques qu'il lui manque la théorie des patchs…

                          Je n'ai absolument jamais dit ça. J'ai peut-être suggéré d'écouter mes arguments avant de dire "Git sera de toute façon tellement mieux que je n'ai pas besoin de t'écouter".

                          Oui pardon, j'ai un peu exagéré une interprétation personnelle de tes écrits. Mais j'avoue que je n'aime pas trop tes arguments se rapportant à « on a discuté avec des gens qui savent, et vous ne pouvez pas comprendre leurs problèmes », en gros, si je caricature.

                          le fait qu'il t'affiche un diff et qu'il travaille sur un objet complètement différent n'est pas ce que ferait C ou Unix, qui n'ont pas ce type de décalage.

                          Bah si, pour moi, c'est du style Unix. On doit vraiment en avoir une interprétation différente.

                          En tous cas, la vision de la « perfection de la théorie » que tu sembles avoir me paraît elle loin d'Unix : généralement, c'est la simplicité d'implémentation qui prévaut, dans cette philosophie.

                          Plus de détails !

                          Ça serait trop long. Moi par exemple je kiffe le design orienté format de données plutôt qu'API, qu'utilise beaucoup Torvalds. J'aime les principes d'Unix comme évoqué plus haut, mais je vois que chacun peut avoir des interprétations différentes (dire qu'on ne retrouve pas les concepts d'Unix dans git, inventé par le créateur de l'Unix libre majoritaire aujourd'hui… je comprends pas). Ça serait trop long à développer ici.

                          C'est une raison légitime pour ne pas écouter ce que je dis, et c'est honnête de le reconnaître.

                          C'était une blague, même si elle n'était pas drôle. Désolé.

                          • [^] # Re: Pourquoi du théorie des patch c'est bien

                            Posté par  . Évalué à 2.

                            On tourne en rond. Je te dis que git est génial pour des choses qui n'ont rien à voir avec la théorie des patchs, et tu me rétorques qu'il lui manque la théorie des patchs…

                            Je comprends que ça pouvait être mal interprété. C'était uniquement un exemple d'un principe sur lequel Git pourrait être basé. On n'a pas besoin de théorie des patchs pour avoir l'associativité. Peut-être qu'il existe une alternative à 3-way merge qui est associative.

                            Ceci dit, cette question est étrange : les gens qui croient que Git donne certaines garanties à l'utilisateur devraient être en mesure d'énoncer ces garanties (garanties = axiomes = principes), plutôt que l'inverse.

                            Mais j'avoue que je n'aime pas trop tes arguments se rapportant à « on a discuté avec des gens qui savent, et vous ne pouvez pas comprendre leurs problèmes », en gros, si je caricature.

                            C'est une caricature d'autant plus grossière que j'avais énoncé quelques unes des raisons factuelles pour lesquelles un très gros utilisateur pourrait ne pas vouloir de Git, et que des liens vers des blogs de Facebook et Google ont été postés dans la même discussion (pas par moi).

                            Moi par exemple je kiffe le design orienté format de données plutôt qu'API

                            Là-dessus, on est totalement d'accord. À tel point que Pijul est exactement ça : une nouvelle structure de données, dont la principale nouveauté est d'être tolérante aux conflits.

                            (dire qu'on ne retrouve pas les concepts d'Unix dans git, inventé par le créateur de l'Unix libre majoritaire aujourd'hui… je comprends pas)

                            Je suis d'accord qu'il y a un peu de l'esprit Unix dans Git. Par exemple, le fait que beaucoup de choses soient accessibles avec des scripts shell.

                            Mais Torvalds n'a pas inventé C et Unix (et c'est un argument d'autorité).

                            Du point de vue des concepts, les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose (je ne parle pas des commandes shell, qui sont une petite partie du design d'Unix, mais plutôt des appels systèmes), un petit nombre de concepts avec des rapports clairs et déterministes entre eux. Si tu prends deux concepts quelconques d'Unix ou de C, ils ne seront jamais liés par une heuristique qui peut parfois se planter. Exemple : mmap n'utilise pas une heuristique pour savoir s'il doit mapper un seul fichier, ou deux l'un au-dessus de l'autre (cet exemple est tiré par les cheveux, mais comme Unix est designé très rigoureusement, on ne peut pas trouver ce type d'exemples).

                            Dans Git, ce n'est pas le cas pour tout. Par exemple, il y a plein de façons de faire ce qu'on veut (de l'aveu de Torvalds lui-même).

                            Un autre exemple, on voit régulièrement des explications de Git pour des débutants qui commencent par "un commit n'est pas un patch" (plutôt que de dire ce que c'est), on voit plus rarement des explications d'Unix qui commencent par "un fichier n'est pas …" ou "un pointeur n'est pas …".

                            C'était une blague, même si elle n'était pas drôle. Désolé.

                            Bon, vu les commentaires d'autres sur ce fil, je ne pouvais pas trop savoir. Désolé !

                            • [^] # Re: Pourquoi du théorie des patch c'est bien

                              Posté par  . Évalué à 4. Dernière modification le 06 octobre 2017 à 15:34.

                              les concepts d'Unix et de C sont simples et élégants, il n'y a souvent qu'une seule façon de faire chaque chose

                              On ne doit pas connaître le même C alors. Affichage de chaînes de caractères: printf, puts. Idem pour la lecture.
                              Définir un bloc de code réutilisable, entre les macros et les fonctions, on a aussi plus d'une façon de faire.
                              Passer plusieurs données à une fonction? Variadic arguments, pointeurs sur listes.
                              À l'origine, il était aussi possible de ne pas déclarer le type de retour des fonctions si on retournait un int…

                              Du coup, une seule façon de faire les choses en C… mouai.

                              Pour UNIX, je ne connais pas assez l'API des kernels pour juger, mais je doute fort que les choses ne puissent se régler que d'une seule façon.

                              • [^] # Re: Pourquoi du théorie des patch c'est bien

                                Posté par  . Évalué à 2.

                                Il est vrai que prendre C et Unix comme point de comparaison est étrange quand on sait que le créateur de git n'est autre que Linus Torvalds, dont on peut difficilement dire qu'il doit avoir une connaissance succincte tant du langage que du système. D'autant que git fonctionne essentiellement à base de pointeur et « d'effet de bord ».

                                Je vois plus la différence entre les deux approches comme analogue à celle entre les langages dits impératifs et ceux dits fonctionnels purs, surtout que Darcs, qui a servit d'inspiration à pijul, est issu de la communauté Haskell.

                                Bien que j'ai déjà lu des personnes défendant la position (qui se tient) que C est un langage fonctionnel pur.

                                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                                • [^] # Re: Pourquoi du théorie des patch c'est bien

                                  Posté par  . Évalué à 2.

                                  Il est vrai que prendre C et Unix comme point de comparaison est étrange

                                  Je n'ai pas comparé Pijul à C. Il faut replacer mon commentaire dans son contexte. J'ai utilisé cet exemple pour montrer que la difficulté d'utilisation n'était pas une condition nécessaire à la puissance d'un outil, et que C a vite remplacé ses prédécesseurs parce qu'il était beaucoup plus facile à utiliser sans être moins puissant.

                                  Bien entendu, aujourd'hui, après plein d'innovations sur les langages, et d'innombrables couches de re-standardisation, certaines des idées de C et d'Unix ont perdu de leur élégance, semblent moins canoniques ou un peu vieillottes.

                                  Ça n'enlève rien à mon argument, puisqu'il se référait justement à l'époque où C est sorti.

                                  quand on sait que le créateur de git n'est autre que Linus Torvalds

                                  Je n'ai jamais nié les compétences techniques ou la vision de Torvalds. Mais je sais ne pas être seul à juger Unix (et C) élégants et Git pas du tout élégant. Il ne me semble pas choquant que des superstars de l'implémentation de systèmes d'exploitation (qui ont toute mon admiration) ne soient pas nécessairement experts en théorie de la concurrence.

                                  (on pourrait aussi remarquer que Linus Torvalds n'a créé ni C ni Unix)

                                  Bien que j'ai déjà lu des personnes défendant la position (qui se tient) que C est un langage fonctionnel pur.

                                  Je ne sais pas si c'est une blague, mais si je lis ce lien, j'y trouve cette phrase :

                                  As with any purely functional language, cpp consists only of (nestable) expressions, not statements. Now here’s the clever part: when evaluated (not executed), a cpp expression yields a (pure) value of type C, which is an ADT (abstract data type) that represents imperative programs.

                                  Ça me semble faux : en CPP, suivant l'ordre d'évaluation des macros, on peut tomber sur du code différent (avec des sémantiques différentes).

                              • [^] # Re: Pourquoi du théorie des patch c'est bien

                                Posté par  . Évalué à 1.

                                Affichage de chaînes de caractères: printf, puts. Idem pour la lecture.

                                C'est pour ça qu'il y avait un "souvent" dans ma phrase. Je suis totalement d'accord que les entrées-sorties en C sont la principale raison pour laquelle ce n'est pas un "toujours".

                                Je suis d'accord qu'il y a plein de petites fonctions pour simplifier le code (puts/printf), et surtout une double API très moche sous Unix entre les pointeurs et les descripteurs de fichiers (open / fopen).

                                Passer plusieurs données à une fonction? Variadic arguments, pointeurs sur listes.

                                Ça ne fait pas vraiment la même chose, les listes sont sur le tas, les arguments sur la pile. C sert d'abord à manipuler finement la mémoire, non ?

                                je ne connais pas assez l'API des kernels pour juger, mais je doute fort que les choses ne puissent se régler que d'une seule façon

                                Vu que j'ai un peu utilisé Unix dans ma vie, je doute un peu de tes doutes.

                                • [^] # Re: Pourquoi du théorie des patch c'est bien

                                  Posté par  . Évalué à 4.

                                  Ok pour les I/O, mais le souvent couvre-t-il aussi les calculs alors? Par exemple les divisions par puissances de 2?
                                  Ou l'acces a la memoire, que tu consideres le role principal du C (pour moi, le role de C n'est pas de manipuler la memoire, mais de faire des programmes portables et performants qui font quelque chose, peu importe quoi, l'acces memoire etant un moyen, non une fin)?

                                  Pour ce qui est de la "double API"… d'un cote y'a posix (et non unix, qui est un OS, pas un standard) de l'autre C, ce sont des outils differents, et ce point (les acces aux fichiers) se comprends facilement: open est bas niveau, moins portable que fopen (puisque pas forcement implemente par les os non posix), et plus souple. Bref, ce ne sont pas des doublons.

                                  Au final, j'ai l'impression que tu te concentres sur des details d'implementation pour dire qu'on ne peut faire les choses que d'une facon avec ces outils… tiens, un exemple de plusieurs facons de faire un truc avec posix: effectuer plusieurs choses en "meme temps". Multi-thread ou multi-process. Pour communiquer? Entre la memoire partagee, les sockets et les signaux, y'a du choix.
                                  Certes, il y a de grosses differences entre leurs roles et capacites (surtout pour les signaux, pour lesquels envoyer un message complexe necessiterait enormement de code, vu que je ne crois pas qu'il soit possible d'attacher une info, mais c'est faisable, en construisant un systeme qui utiliserait un signal pour envoyer 1, un autre pour les 0… ce serait moche, oui, mais faisable a priori) mais le point est la: ces outils permettent d'echanger des messages.
                                  Tiens en parlant de sockets: poll, epoll, select ou eselect? Ces fonctions font la meme chose, avec diverses limitations ou avantages.

                                  Voila qui devrait aider a ce que tu comprennes mes doutes.

                                  • [^] # Re: Pourquoi du théorie des patch c'est bien

                                    Posté par  . Évalué à 1.

                                    Voila qui devrait aider a ce que tu comprennes mes doutes.

                                    Merci d'avoir pris le temps d'utiliser des arguments, ça marche mieux !

                                    J'ai bien pris note du fait que C était un langage bas niveau, et avec une histoire un peu longue.

                                    Maintenant qu'on a bien discuté des trucs pas très jolis de C, en quoi cela permet-il de contester mon argument initial auquel tu sembles t'opposer, à savoir : C a marché parce qu'il était plus puissant et plus facile à apprendre que ses prédécesseurs ?

                                    • [^] # Re: Pourquoi du théorie des patch c'est bien

                                      Posté par  . Évalué à 2. Dernière modification le 09 octobre 2017 à 19:56.

                                      Je ne rebondissait que sur le fait que l'on ne pouvait souvent faire les choses que d'une maniere en C et posix. Ce qui, a mon avis est faux (mais comme je l'ai dit, je ne suis pas expert en C ni en posix, il me reste tant a apprendre).
                                      Pour le reste, le seul langage anterieur a C que je connaisse est l'asm intel 16 (et un peu 32 donc pas sur de l'anteriorite) bits… meme pas en fait, je sais pas qui est le1er né. Du coup, savoir pourquoi C s'est impose m'est impossible. Je suppute que son gros avantage etait justement qu'il n'etait pas trop bas niveau pour l'epoque (par exemple compare a l'asm), portable et efficace (pas trop de couches intercalaires pour faire le moindre truc). Mais…ca reste supposition de ma part, et j'ai pas envie d'apprendre le B rien que pour le decouvrir :)

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 2.

                « des gens qui gèrent les dépôts du noyau Linux », je suis sceptique

                Moi aussi, parceque en fait ca c'est pas Linus qui le fait? Je ne l'ai pas encore vu re-ecrire git parceque le bonhomme a legerement pris l'habitude de faire cela plutot que de parler.

      • [^] # Re: Pourquoi du théorie des patch c'est bien

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

        Quand je lis 'faut disputer les devs qui n'y prêtent pas attention' je suis tout de suite méfiant.

        Mon compilateur a des messages d'erreurs incompréhensibles mais faut disputer les devs qui écrivent du code qui ne compile pas. J'ai pas écrit de tests mais si quelqu'un casse quelque chose à l'avenir, faut le disputer parce que c'est mal de casser mon code. Le repository est incohérent mais faut disputer les devs qui ont pas utilisé le flag --no_incoherence_introduced_please

        Si l'on cherche à comprendre pourquoi 'les devs' on fait 'une bêtise' on se rend bien souvent compte qu'en fait, l'outil n'est pas pratique à utiliser, permet une erreur (voir l'encourage) sans que cela n'apporte quoi que ce soit et qu'en modifiant l'outil ou en en changeant on fait disparaître le problème définitivement. Alors qu'en 'disputant les devs', on se fatigue juste à crier sans que ça ne change rien.

        • [^] # Re: Pourquoi du théorie des patch c'est bien

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

          J'ai pas écrit de tests mais si quelqu'un casse quelque chose à l'avenir, faut le disputer parce que c'est mal de casser mon code. Le repository est incohérent mais faut disputer les devs qui ont pas utilisé le flag --no_incoherence_introduced_please

          Normalement le développeur, avant de merger officiellement sur le dépôt, doit vérifier sur le merge fonctionne comme attendu (compile et que les tests unitaires tournent correctement). Voire un système d'intégration continue qui vérifie ces propriétés avant de pousser ça définitivement dans le dépôt commun.

          Tu peux donner les outils que tu veux aux développeurs, s'ils ne vérifient pas (ou si aucun mécanisme dans l'intégration du code ne le fait) que son commit / merge n'apporte pas de soucis particuliers, je ne vois pas par quel miracle un outil pourrait tout résoudre. C'est quand même la base… Car bon, si le code ne compile pas, je n'ose imaginer s'il a vérifier qu'il n'y a pas eu de bogues / régressions ou autres introduits.

        • [^] # Re: Pourquoi du théorie des patch c'est bien

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

          Il faut disputer l'équipe pour ne pas être claire sur son workflow.

          Dans certains cas, il est possible d'utiliser git pull --rebase (et d'ailleurs d'activer l'option autorebase dans le .git pour ne pas avoir à le faire à la main tout le temps). Dans d'autres cas, il y a juste trop d'activité et un historique trop compliqué pour que ça soit possible (le noyau Linux, WebKit, ou de très gros projets très actifs dans ce genre).

          Et comme git est conçu d'abord pour le noyau Linux, forcément les réglages par défaut sont surtout appropriés pour ce cas là.

      • [^] # Re: Pourquoi du théorie des patch c'est bien

        Posté par  . Évalué à 10.

        Salut ! Je suis un des auteurs de Pijul, et en retard pour répondre.

        C'est dommage que sa doc se focalise sur un avantage futile (youpi, mes merges sont supposément plus fiables) plutôt que sur des avantages concrets dans 100% des cas (mon repo est 100% fiable, validable et ne peut pas techniquement être corrompu sans rattrapage possible).

        Ces avantages "concrets" sont bien évidemment garantis par notre théorie. L'avantage des merge n'est certes pas le principal avantage, mais l'idée d'avoir une théorie petite, qui garantit un petit nombre d'axiomes simples, est un avantage énorme.
        Et d'ailleurs, si on regarde les bonnes pratiques, les "successful workflows" et autres "Pro Git Book" en connaissant ces axiomes, on se rend compte que tout le monde cherche à garantir la même chose.

        Maintenant, (sauf dans le cas rare de Git is inconsistent, où Git fait vraiment n'importe quoi), il y a deux façons de garantir ces propritétés : soit c'est la machine qui le fait, soit c'est le programmeur. C'est exactement la même différence qu'entre la programmation fonctionnelle et les autres langages. Il n'est d'ailleurs pas extraordinairement surprenant de voir des utilisateurs de Rust, Haskell, OCaml, Scala etc. désirer mieux que Git.

        Notre pari, c'est qu'alors que les langages fonctionnels sont plus difficiles d'accès que Python, pour nous ça a l'air d'être l'inverse : l'utilisateur peut complètement oublier qu'il y a une théorie derrière, tout ce qu'il voit ce que "ça colle à l'intuition" (c'est à ça que servent des axiomes dans toutes les théories) et que "ça va vite".

    • [^] # Re: Pourquoi du théorie des patch c'est bien

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 19 septembre 2017 à 13:24.

      Qu'est-ce que l'on entend par inattendu ? Idéalement il faut lire le blog, sinon ce lien donne un explication visuelle.

      On comprend bien à la lecture que le mec n'aime pas git, mais bon au risque de passer pour insane à ses yeux ça ne me choque pas. Je m'avance beaucoup sur la maitrise de la chose, mais git ne gère pas des patchs mais un graphe orienté d'états successifs. Son exemple visuel montre clairement qu'il ne construit pas le même graphe dans les deux scénarios, ça ne me choque donc pas que l'état final puisse différer dans un cas extrêmement capillotracté.

      • [^] # Re: Pourquoi du théorie des patch c'est bien

        Posté par  . Évalué à 10. Dernière modification le 19 septembre 2017 à 22:38.

        Je m'avance beaucoup sur la maitrise de la chose, mais git ne gère pas des patchs mais un graphe orienté d'états successifs.

        pijul aussi gère, à sa façon, un graphe orienté d'états successifs : un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés. Les sommets du graphes sont des « fichiers » et les arcs des patchs : si il y a un arcs entre deux sommets alors la cible est le résultat du patch appliqué à la source.

        En réalité les sommets ne sont pas des fichiers mais une notion étendue des ceux-ci : des digle (directed graph fi le). Si le graphe est linéaire on a un fichier au sens usuel (ligne à ligne), tandis que l'on obtient un graphe en cas de conflit lors d'un merge.

        merge conflict

        Résoudre un conflit revient juste à appliquer un patch sur un tel sommet : ainsi pijul garde en mémoire, dans son graphe, le sommet conflictuel au lien de l'effacer.

        merge solved

        Un des propriétés marrantes c'est l'associativité des patchs :

        3-way merge

        Ici on a un 3-way merge1 qui s'obtient naturellement comme la composition de merge de 2 patchs : quelque soit le chemin pris on arrivera toujours sur le même état final Q. C'est cette propriété que n'ont pas les autres DCVS comme git et qui constitue la reproche des partisans de darcs et pijul.

        Après, je ne sais pas si en pratique cela s'avérera d'un grand intérêt et plus souple à l'usage que l'existant, mais la théorie qu'il y a derrière est jolie. Elle est expliquée plus en détail dans ces deux articles de blogs :


        1. si le dessin rappelle à certains le problème de l'héritage multiple, c'est normal il lui est formellement identique, et c'est tout l'intérêt des catégories de fournir un outillage conceptuel unifié pour ce type de problématique. 

        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: Pourquoi du théorie des patch c'est bien

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

          C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer. Y a sûrement une nouvelle tradition de magie à la Ouija à monter.

          Je sais d'avance que la suite de cette conversation sera, en réponse, un autre pavé encore plus indigeste pour moi, que je ne comprendrai carrément pas, car j'ai arrêté les maths suffisamment tôt pour ma satisfaction professionnelle vu que j'aime mon travail, mais trop tôt par rapport à la maitrise d'icelles que j'aimerais avoir, mais bon je me lance quand même.

          pijul aussi gère, à sa façon, un graphe orienté d'états successifs

          Oui alors c'est sûr, si tout le monde appelle dans son cas "état" ce qu'il stocke dans un sommet, on gère tous des états. Git stocke en premier lieu des "états"-"sommets" qui représentent concrètement et trivialement le contenu brut du dépôt aux instants T(x), et ajoute par dessus un graphe de relations bête et méchant. J'ai l'impression que pijul travaille dans l'autre sens en ayant comme citoyen de première classe les arêtes avec le patch comme contenu, et en déduit des sommets-"état du dépôt".

          un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés.

          Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers. Je peux envisager de voir un graphe orienté comme une catégorie, en tant que suite de morphismes dans le même groupe (transformation de fichiers) à chaque fois, mais à l'inverse, voire toute catégorie comme un graphe orienté, j'ai plus de mal, puisque dans une catégorie par définition les morphismes de groupe n'ont à priori pas les mêmes ensembles de définition et d'image ? Ou alors un graphe peut avoir des sommets "fichiers" et des sommets "bananes" si une des arêtes est un morphisme de groupe partant de l'ensemble "fichiers" et arrivant dans l'ensemble "banane", ce qui, convenons-en, ne sera que peu exploitable comme gestionnaire de sources.

          Les sommets du graphes sont des « fichiers » et les arcs des patchs : si il y a un arcs entre deux sommets alors la cible est le résultat du patch appliqué à la source.

          Si par arc tu veux parler de ce que j'appellerais arête, alors à vérifier mais dans git les sommets c'est pareil (et c'est pas que "des fichiers", c'est "tous les fichiers du dépôt à l'instant T") par contre les arcs ne sont pas valués comme semblent être ceux de pijul, ils ne représentent que la relation "tel commit a tel ascendant dans le graphe". La sortie de git diff par exemple (dans mon souvenir ; si je me goure, j'ai perdu toute crédibilité :-)) n'est pas l'affichage des "patchs" contenus dans les arêtes comme dans pijul, mais est reconstruite en comparant les deux instantanés du dépôt comparés.

          En écrivant ça j'ai l'intuition de retrouver ce pourquoi git est si plaisant à utiliser (surtout comparé à SVN qui était dominant à l'époque, il est vrai). Faire un "rebase" en git (prendre un bout de graphe et le déplacer) est extrêmement efficace (il ne déplace que des relations) mais peut effectivement créer des changements autres que ceux "contenus" dans les commits (même si pour rappel un commit ne contient pas de changement mais décrit un nouvel état complet) d'où conflits à résoudre. Sauf que je ne vois pas comment pijul peut être magiquement mieux. Si pijul a stocké "alors là tu changes la ligne 3 du fichier 'foo' de 'bar' vers 'baz'" comme patch, par quelle magie, lorsque je le rebase sur un nouveau sommet où précédemment la dite ligne 3 a été modifiée de 'bar' vers 'boo', il recolle les morceaux ? A part en disant "oh merde je m'en fous je colle 'baz' puisque de toute façon on voulait 'baz'". Ou alors en disant "euh au secours conflit !".
          Exactement comme git en fait.

          A ce propos je rebondis sur ta première image, c'est précisément le même biais que dans le lien que je critiquais. Vous prenez tous les deux le cas "simple" où la ligne changée dans les deux branches est la même au départ. C'est "simple" pour un humain parce que c'est "la même" visuellement et on se dit "pffff git est con", mais :

          • il ne peut pas déterminer que fonctionnellement c'est la même (si dans une branche je change 'bar' en 'boo' puis re en 'bar', c'est toujours la même ? Par quelle règle non écrite qui assure que ce n'est pas une coïncidence ?
          • et donc comment votre outil magique résout le problème si malheureusement je sors de votre exemple contrit et je modifie la ligne des deux côtés ?

          Ta deuxième image est carrément malhonnête. Tu ajoutes un original qu'il n'y avait pas et qui comme par hasard renforce l'effet visuel de "j'ai juste ajouté une ligne" (sauf que dans la réalité ce n'est qu'un cas particulier simple pour un humain qui comprend le fonctionnel des sources). Si toi et ta femme aviez changé "work" pour une ligne différente chacun de votre côté ?

          Par ailleurs le merge final (ainsi que sa généralisation dans la 3ème image) est simplement un merge déterministe, ce qui :

          • est parfaitement possible avec git en choisissant une stratégie de merge déterministe
          • ne fonctionne pas en réalité : d'accord tu as résolu le merge technique, mais qui te dit que le code fait ce que tu veux (y a même des chances que ça ne compile juste pas) ? Si tu as la réponse, félicitations, tu as trouvé le programme qui prouve tous les autres programmes, tu vas être maître du monde.
          • [^] # Re: Pourquoi du théorie des patch c'est bien

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

            Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers. Je peux envisager de voir un graphe orienté comme une catégorie, en tant que suite de morphismes dans le même groupe (transformation de fichiers) à chaque fois, mais à l'inverse, voire toute catégorie comme un graphe orienté, j'ai plus de mal, puisque dans une catégorie par définition les morphismes de groupe n'ont à priori pas les mêmes ensembles de définition et d'image ?

            Je pense que la façon habituelle de voir un graphe G comme une catégorie C est de dire que

            1. Les objets de C sont les sommets du graphe
            2. Les morphismes de C entre deux objets A et B sont les chemins de A à B dans le graphe G, que l'on compose comme les chemins de G.

            C'est un “gag” assez déroutant de la théorie des catégories qu'à aucun moment elle ne demande que les objets soient des ensembles avec des éléments ni que les morphismes puissent être appliqués sur des éléments de ces objets. On peut aussi transformer groupes et monoïdes en catégories ou en graphes. Si ces manipulations semblent a priori un peu gratuites il ne faut pas perdre de vue que chacune des ces théories (graphes, catégories, monoïdes) ont chacune un corpus phénoménal de théorèmes ce qui justifie le besoin de changer de point de vue sur les objets qu'on étudie.

          • [^] # Re: Pourquoi du théorie des patch c'est bien

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

            Je rebondis sur mon (y a même des chances que ça ne compile juste pas) avec un exemple.

            Supposons que j'ai sur master cette méthode en Groovy pour récupérer un utilisateur dans mon appli Grails, qui filtre les utilisateurs blacklistés (on passera sur la propreté d'utiliser des null, de ne pas filtrer directement en base, etc., hein, c'est un exemple) :

            def getUser(String login) {
              def user = User.findByLogin(login)
              if (user.blacklisted) return null
              return user
            }

            Dans la branche A le développeur gentil décide que le blacklist c'est trop méchant et retire ce filtre :

            def getUser(String login) {
              def user = User.findByLogin(login)
              return user
            }

            Plus tard, dans la branche B le développeur méchant pense que le blacklist c'est cool et qu'en plus un type qui ne s'est pas connecté depuis 1 mois c'est louche :

            def getUser(String login) {
              def user = User.findByLogin(login)
              if (user.blacklisted) return null
              else if (user.lastAccess < DateTime.now.minusMonths(1)) return null
              return user
            }

            Qu'est-ce que pijul va faire au merge ? S'il applique les patchs successivement le résultat ne compilera même pas avec un else orphelin :

            def getUser(String login) {
              def user = User.findByLogin(login)
              else if (user.lastAccess < DateTime.now.minusMonths(1)) return null
              return user
            }

            Toute autre combinaison valide syntaxiquement (retirer les deux test, garder les deux) est indécidable sans les specs de l'appli. Ainsi que toute modification (genre retirer le premier filtre mais garder celui sur la date en retirant le else, comment tu sais que c'est ce qu'on veut finalement ? Et pijul ne parle pas le Groovy à priori).

            À moins que j'ai vraiment loupé un truc, seule l'attitude de git, s'arrêter et te dire t'es gentil tu corriges tes conneries est valide.

            • [^] # Re: Pourquoi du théorie des patch c'est bien

              Posté par  . Évalué à 4.

              Qu'est-ce que pijul va faire au merge ?

              Il va dire qu'il y a conflit, comme git. Mais la différence entre les deux outils (ou plutôt entre leur fondement théorique) ne se situe pas à ce niveau là, c'est-à-dire que ce n'est pas sur ce genre de question qu'ils se distinguent : pijul n'est en rien un outil magique qui résout tout seul les conflits de merge en devinant ce qu'il y a dans la tête des programmeurs.

              En fait, je me suis rendu compte que j'ai mal utilisé le terme de « 3-way merge » ce qui t'a sans doute induit en erreur sur le fonctionnement de pijul.

              Je n'ai pas le temps de corriger mon erreur de présentation, j'essaierai de voir demain. Sinon, le plus simple est d'aller lire les deux articles de blog que j'ai donné en lien, je voulais juste en faire un résumé et un teaser.

              Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Pourquoi du théorie des patch c'est bien

              Posté par  . Évalué à 10.

              À moins que j'ai vraiment loupé un truc, seule l'attitude de git, s'arrêter et te dire t'es gentil tu corriges tes conneries est valide.

              Pijul fait bien entendu la même chose.

              Je voudrais juste rajouter que "appliquer les patchs successivement" a un sens, mais Pijul garantit que les applique dans n'importe quel ordre fait la même chose, ce qui permet de laisser les deux développeurs faire un pull de l'autre, et d'aboutir à exactement le même résultat :

              • Le développeur cool pull un patch qui ajoute des lignes dans un contexte (les lignes autour) qu'il a supprimé, c'est un conflit.
              • Le développeur pas cool pull un patch P qui supprime des lignes, mais ces lignes supprimées ont du contexte qui ne fait pas partie des dépendances de P. C'est le même conflit.

              L'attitude de Git dans ce cas :

              1. dépend du contenu des lignes. Parfois il ne verra pas le conflit, et ajoutera la nouvelle ligne à un autre endroit du code.
              2. dépend de l'ordre dans lequel ces patchs ont été appliqués.

              Ce n'est pas complètement raisonnable, en particulier sur des codes plus gros qu'une fonction de trois lignes qui fait un truc simple.

              Ce qui est encore moins raisonnable, c'est que Git peut en plus, dans pas mal de cas, indiquer un conflit alors qu'il n'y en a pas, simplement parce que le manuel de bonnes pratiques a dit de faire un rebase il y a trois mois. L'intention du manuel était bonne : il s'agissait juste d'essayer de simuler la commutation de patchs. Mais ça n'a pas trop marché, et maintenant il faut relire un code déjà testé et relu quinze fois auparavant, pour s'assurer encore une fois que tout va bien, alors que ce n'est pas forcément sur ce morceau-là du projet qu'on voudrait travailler maintenant.

              Relire du code est absolument essentiel, on est d'accord, mais on peut aussi supposer que les participants au projet ont un temps de travail fini, et des priorités de relecture et de tests décidés par autre chose que par Git. Dans ce cas, c'est une perte de temps.

          • [^] # Re: Pourquoi du théorie des patch c'est bien

            Posté par  . Évalué à 10.

            Je réponds super en retard (je suis un des auteurs du truc).

            En écrivant ça j'ai l'intuition de retrouver ce pourquoi git est si plaisant à utiliser (surtout comparé à SVN qui était dominant à l'époque, il est vrai).

            Personne ne conteste que Git est bien mieux que SVN. Mais il est basé sur les mêmes heuristiques "qui marchent souvent", et passe encore moins bien à l'échelle de très gros dépôts (un truc à la mode chez Google et Facebook) que SVN.

            Sauf que je ne vois pas comment pijul peut être magiquement mieux.

            Pijul n'est pas "magiquement mieux", dans le sens où il n'y a aucune magie, seulement une vraie théorie qui gère tous les cas, donne des axiomes simples et efficaces à l'utilisateur (et des algos avec une meilleur complexité que Git, même s'il y a encore eu moins de micro-optimisation dans Pijul que dans Git).

            Une conséquence de ces axiomes est que les conflits ne sont pas (comme dans Git ou même Darcs) des "cas pourris" qu'il faut résoudre avant le prochain commit. Ils sont traités comme le cas normal.

            En fait j'aurais plutôt tendance à dire que Git est "magiquement" moins bien, parce qu'il utilise des heuristiques (de la magie) qui marchent souvent. Il n'y a pas de principe qui assure que tout va toujours bien se passer. Au fait, les gens qui font Pijul, c'est-à-dire Florent Becker, moi-même, et les gens qui commencent à nous rejoindre, connaissent très bien Git (et très bien Darcs, et un peu moins Mercurial et SVN).

            Si pijul a stocké "alors là tu changes la ligne 3 du fichier 'foo' de 'bar' vers 'baz'" comme patch, par quelle magie, lorsque je le rebase sur un nouveau sommet où précédemment la dite ligne 3 a été modifiée de 'bar' vers 'boo', il recolle les morceaux ? A part en disant "oh merde je m'en fous je colle 'baz' puisque de toute façon on voulait 'baz'". Ou alors en disant "euh au secours conflit !".

            C'est effectivement un conflict dans Pijul. Pijul n'utilise pas du tout le contenu des lignes pour appliquer un patch, seulement leur histoire et leur contexte.

            Ça n'a rien de magique, il y a simplement des règles pour garantir les axiomes.

          • [^] # Re: Pourquoi du théorie des patch c'est bien

            Posté par  . Évalué à 5. Dernière modification le 23 septembre 2017 à 11:46.

            C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer.

            Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes. Tu disais que git gère un graphe orienté d'états successifs, je t'ai répondu que pijul faisait de même.

            Je sais d'avance que la suite de cette conversation sera, en réponse, un autre pavé encore plus indigeste pour moi, que je ne comprendrai carrément pas, car j'ai arrêté les maths suffisamment tôt pour ma satisfaction professionnelle vu que j'aime mon travail, mais trop tôt par rapport à la maitrise d'icelles que j'aimerais avoir, mais bon je me lance quand même.

            Si mes réponse apparaissent comme des pavés indigestes, alors c'est que j'ai échoué à atteindre mon objectif. Mon intention principale, quand j'écris sur ce site, est d'être compris par le plus grand nombre et non d'utiliser des termes pédants et abscons. Ton choix d'avoir arrêté les maths suffisamment tôt pour ta satisfaction professionnelle est on ne peut plus respectable : chacun fait et étudie ce qu'il lui plait. Cela étant, si je peux réussir à te faire comprendre ce qui distingue git et pijul sans entrer dans des détails techniques et théoriques, j'aurai atteint mon objectif.

            Du peu que je sais j'ai l'impression que le c'est-à-dire est à l'envers.

            Comme te l'a déjà répondu Michaël : toute catégorie peut être vu comme un graphe orienté (on les présente souvent ainsi d'ailleurs) mais la réciproque n'est pas vraie; mon c'est-à-dire n'est pas mis à l'envers. Mais laissons donc de côté le concept de catégorie et gardons donc celui de graphe orienté : il sera compris de tout le monde.

            Git stocke en premier lieu des "états"-"sommets" qui représentent concrètement et trivialement le contenu brut du dépôt aux instants T(x), et ajoute par dessus un graphe de relations bête et méchant. J'ai l'impression que pijul travaille dans l'autre sens en ayant comme citoyen de première classe les arêtes avec le patch comme contenu, et en déduit des sommets-"état du dépôt".

            De ce que j'en ai lu et compris, pijul aussi a pour sommets dans son graphe le contenu du dépôt aux instants T(x), à savoir les fichiers de la branche de travail. En revanche, pijul voit l'évolution de l'historique d'un dépôt comme un succession de patchs appliqués sur lui et c'est ce que représente son graphe en étiquetant chaque arêtes par un patch. Ce qui donne bien aux patchs un statut de citoyens de première classe, mais il ne passe pas son temps à déduire les fichiers par application des patchs par simple soucis d'efficacité :

            Fast algorithms: Pijul's pristine can be seen as a "cache" of applied patches, to which new patches can be applied directly, without having to compute anything on the repository's history.

            pijul documentation

            Venons-en maintenant à une propriété qui distingue git et pijul : l'associativité. C'est certes une notion mathématique mais simple à comprendre : elle dit, en gros, dans le cas de l'addition, que (a + b) + c = a + (b + c) ce qui fait qu'en général on se dispense d'écrire les parenthèses et que l'on écrit tout simplement a + b + c.

            Il est très utile, en pratique, d'avoir des opérations associatives et lorsque ce n'est pas le cas, il faut faire attention à la manière dont on les regroupe. Si je reprend l'exemple de la multiplication des matrices données dans un autre journal pour réduire le nombre de cache miss :

            /* traduction directe de la formule du produit */
            for (i = 0; i < N; ++i)
              for (j = 0; j < N; ++j)
                for (k = 0; k < N; ++k)
                  res[i][j] += mul1[i][k] * mul2[k][j];
            
            /* optimisation pour réduire les cache miss */
            for (i = 0; i < N; i += SM)
              for (j = 0; j < N; j += SM)
                for (k = 0; k < N; k += SM)
                  for (i2 = 0, rres = &res[i][j],
                       rmul1 = &mul1[i][k]; i2 < SM;
                       ++i2, rres += N, rmul1 += N)
                    for (k2 = 0, rmul2 = &mul2[k][j];
                         k2 < SM; ++k2, rmul2 += N)
                      for (j2 = 0; j2 < SM; ++j2)
                        rres[j2] += rmul1[k2] * rmul2[j2];

            Dans son article, Ulrich Drepper précise bien « we ignore arithmetic effects here which might change the occurrence of overflows, underflows, or rounding », et il a raison : l'addition n'étant pas associative en arithmétique flottante, les deux programmes ne sont pas identiques. Mais son intention était surtout de montrer que l'ordre dans lequel les instructions étaient effectuées avaient son importance sur la gestion du cache CPU.

            Quittons cette courte digression et revenons à nos moutons. Si l'arithmétique flottante n'est pas associative, il n'en est pas de même des séries d'instructions dans un langage comme le C : (e1;e2);e3 se comporte comme e1;(e2;e3) ou e1;e2;e3. Par contre, la fusion des patchs et commits en git ne vérifient pas cette propriété. C'est ce qui lui est reproché, entre autre, par les promoteurs de darcs et pijul. Le lien du premier commentaire illustrait ce phénomène, et la documentation de pijul l'illustre avec ces deux schémas :

            pij fork1

            pij fork2

            si chaque point illustre des patchs appliqués, disons A B C, alors avec git on aurait : (A;B);C ≠ A;(B;C). C'est ce qui se passe quand on fait du cherry-picking et du rebase. En revanche, pijul vérifie bien cela et c'est ce qu'illustrait ce graphe :

            pijul asso

            Si l'on part de l'état O du dépôt, qu'Alice et Bob fork pour aller l'un dans l'état B et l'autre dans l'état C. Puis Alice passe ensuite dans l'état M. Peu importe que l'on fusionne d'abord B et C dans l'état N pour ensuite fusionner N et M, ou que l'on fusionne directement C et M : dans tous les cas on arrivera sur le même état Q. Pour revenir rapidement sur la notion de catégorie, cette propriété d'associativité fait partie de sa définition : un graphe qui ne la vérifie pas ne peut être vu comme une catégorie, en revanche une catégorie vue comme un graphe la vérifiera.

            Comme l'a dit pmeunier, git ne vérifiant pas cette propriété (pourtant utile et, dans le fond, désirée par les utilisateurs), il y a des guides de bonnes pratiques pour combler cette lacune, là où, par construction, elle est automatiquement satisfaite dans pijul.

            Outre cette propriété d'associativité des patchs, il y en a une autre fort utile : celle qui cherche à capter l'essence de fonctionnalités orthogonales ou indépendantes. Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat. Cette propriété s'appelle la commutativité des patchs, à savoir p1;p2 fait la même chose que p2;p1 (ou a + b = b + a). Pijul détecte automatiquement de telle situation et transforme (de manière transparente pour l'utilisateur) le graphe de dépendance des états. Dans une telle situation :

            pijul dep1

            pijul va chercher s'il ne peut trouver un patchs a(q) telle que dans le graphe suivant :

            pijul dep2

            la fusion des états A et C donne le même état B que dans la séquence p;q, et en arrière plan on aura dans le graphe de pijul cette situation :

            pijul dep3

            ce qui permet, entre autre, de paralléliser les calculs, mais rend aussi le graphe plus flexible à l'usage. Les guides de bonnes pratiques expliquent également comment obtenir une telle chose en git : avec pijul, rien à faire, elle est fournie de base sans effort de le part des utilisateurs.

            Un dernier point, un peu plus technique que ce qui précède, mais pas si difficile à comprendre, c'est là raison d'être des digle. Lorsque l'on cherche à fusionner deux états, on se retrouve dans la situation suivante :

                 A
               /   \
              /     \
            O        ??
              \     /
               \   /
                 B
            

            Le problème est que si l'on prend pour type des sommets celui des fichiers, ce problème n'a pas toujours de solution : c'est ce qu'il se passe lorsqu'il y a conflit. Il y a un principe général qui consiste à dire : si le problème n'a pas de solution, alors agrandissons l'espace du possible et il aura toujours une solution. C'est, pour donner une comparaison, ce qu'on fait les algébristes quand ils ont inventé les nombres complexes : certains polynômes n'ont pas de racines, ce n'est pas grave, il suffit de rajouter des nombres et tout polynôme aura une racine. Raison pour laquelle, en cas de conflit, pijul produit pour sommet un graphe orienté de lignes et non un fichier. De la même façon que l'on peut projeter de plusieurs façons différentes un nombre complexe sur un nombre réel, on peut aplatir de différentes façon un digle en un fichier ou réduire de différentes façons un conflit. Mais cette phase ne résolution, comme dans git, n'est pas effectuée automatiquement par pijul mais reste à la charge des programmeurs.

            En espérant avoir éclairci quelques différences entre git et pijul, sans avoir écrit un pavet indigeste.

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Pourquoi du théorie des patch c'est bien

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

              Comme te l'a déjà répondu Michaël : toute catégorie peut être vu comme un graphe orienté (on les présente souvent ainsi d'ailleurs) mais la réciproque n'est pas vraie

              Ce n'est pas plutôt le contraire? Un graphe orienté peut toujours être transformé en catégorie (attention, les morphismes de la catégorie correspondent aux chemins!) tandis qu'une catégorie peut ne pas être transformée en graphe, essentiellement parceque les objets de la catégorie ne forment pas nécessairement un ensemble.

              Ceci-dit, c'est une objection essentiellement scolaire parcequ'il va de soi qu'on ne peut tirer quelque chose du point de vue “graphe” sur les catégories que pour des catégories bien particulières.

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 2.

                Ce n'est pas plutôt le contraire?

                Non, c'est bien ce que j'ai écrit : toute catégorie est un graphe orienté, mais la réciproque est fausse. Une catégorie est un graphe orienté qui doit vérifier un certain nombre d'axiomes; autrement dit, ces axiomes sont des contraintes imposées au graphe et tout graphe qui ne les satisfait pas ne peut représenter une catégorie.

                Comme tu évoques la notion d'ensemble, voici un exemple : un modèle de la théorie des ensembles est un graphe orienté qui n'est pas une catégorie. La théorie des ensembles est une théorie axiomatique d'une relation binaire que l'on appelle l'appartenance (notée \in) et une relation binaire peut parfaitement se représenter comme un graphe orienté où l'existence d'une relation entre deux objets est signifiée par la présence d'une arête entre les deux sommets du graphe. Pour qu'un tel graphe puisse représenté une catégorie, il faudrait que la relation soit réflexive et transitive : ce qui n'est pas le cas de la relation d'appartenance, ni de nombreuses autres relations binaires.

                En revanche on peut toujours, à partir d'un graphe orienté, engendrer une catégorie en prenant sa fermeture transitive :

                fermeture transitive

                puis en rajoutant une flèche de chaque sommet vers lui-même.

                Pour revenir sur le graphe de l'univers des ensembles, les contraintes imposées par les axiomes sont tels que l'on peut plonger ou encoder n'importe quelle construction mathématique en son sein. La généralité de la notion de catégorie permet de faire la même chose : ce sont deux approches distinctes sur le fondement des mathématiques mais d'égale utilité.

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: Pourquoi du théorie des patch c'est bien

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

                  Ah oui effectivement, comme mathématicien assez peu versé dans la logique je considère un peu rapidement que les sommets d'un graphe et ses arêtes sont des ensembles, mais si on relaxe ces conditions au même niveau que celles que l'on met sur les objets d'une catégorie, il n'y a pas d'obstacle à associer formellement les deux notions.

                  • [^] # Re: Pourquoi du théorie des patch c'est bien

                    Posté par  . Évalué à 2.

                    je considère un peu rapidement que les sommets d'un graphe et ses arêtes sont des ensembles

                    Disons que la notion d'ensembles en mathématique est ambigüe (cf. le pardoxe de Russel), alors j'ai tendance à utiliser ce terme pour désigner les objets d'un modèle de la théorie des ensembles (ou les sommets d'un graphe qui est modèle de la théorie). Ce qu'il y a avec ZF (comme avec la théorie des catégories) est que l'on peut réflchir la métathéorie dans la théorie elle-même et aboutir à des théorèmes du style : si ZF est consistante alors elle a un modèle dénombrable (bien que le modèle en question possède des ensembles non dénombrables de son point de vue).

                    Pour une présentation succincte de la théorie des catégories, il y a le cours Inititation à la théorie des catégories de Gérad Huet qui commence ainsi :

                    Une catégorie C se compose d'objets et de flèches. On écrit A : C pour dire que A est un objet de C, et f : C(A,B) pour dire que f est une flèche de C reliant l'objet A à l'objet B. En général la catégorie dans laquelle on travail est sous-entendue, et on écrit plus simplement f : A -> B.

                    Jusqu'ici, une catégorie est un graphe orienté dont les nœuds sont les objets et les arcs sont les flèches. Mais les catégories possèdent la structure minimale donnée par l'associativité de la composition des flèches. Les flèches doivent donc être vue comme les chemins du graphe, quotientés par l'égalité des flèches.

                    Comme les notations ci-dessus te rappellerons celles utilisées pour les annotations de typage en OCaml, et que CAML signifie Categorical Abstract Machine Language (c'est la machine abstraite du bytecode OCaml), tu pourras aussi jeter un œil à De la déduction naturelle a la machine categorique :

                    Le titre de cet article résume trois slogans :

                    • La Déduction naturelle, c'est du lambda-calcul.
                    • Le lambda-calcul, c'est la théorie des Catégories Cartésiennes Fermées.
                    • La théorie des Catégories Cartésiennes Fermées, c'est du langage machine.

                    On réalise ainsi le Programme de Constructivation des Mathématiques :

                       preuve       ---->  programme   ---->  combinateur --->    code
                    intuitionniste         fonctionnel        catégorique       exécutable
                    

                    Sinon, pour en revenir à pijul, j'ai eu une nouvelle idée pour présenter la notion de fusion dans ce système. Quand on a une relation reflexive et transitive (un préodre), on peut la voir comme une catégorie (en réalité ce sont les catégories ayant au plus une flèche entre deux objets). Prenons, par exemple, la catégorie dont les objets sont les entiers et la relation de préodre « être un multiple de ». Ainsi le schéma de fusion suivant :

                    fusion

                    peut se lire : A et B sont des mutliples de O (A = p * O et B = q * O) et M (M = r * A = s * B) est un multiple commun de A et B. Mais parmi tous les mutliples communs de A et B, il y en a un qui est plus petit que les autres : c'est lui la fusion !!! Ce qu'exprime ce diagramme :

                    fusion parfaite

                    si je prends un autre multiple F de A et B alors il est multiple de leur ppcm M.

                    Cette notion, qui est une généralisation de la notion de borne supérieure (le plus petit des majorants si on y voit une relation d'ordre, le descendant minimal dans l'historique du dépôt) est ce que les catégoriciens appellent une somme amalgamée. Comme une telle somme n'existe pas toujours si on prend pour objets des fichiers, il faut prendre pour objets des digles.

                    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

            • [^] # Re: Pourquoi du théorie des patch c'est bien

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

              Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes.

              Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".

              les deux graphes colorés un peu différents

              D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process". J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur (pas terrible mais mieux que vos exemples soit sans code tout court (intéressant pour un gestionnaire de sources) soit avec des exemples encore moins réalistes et spécialement conçus dans votre sens pour que les parties en conflit aient exactement la même apparence, pour qu'on puisse les confondre alors que rien ne permet à priori de supposer qu'elles seront identiques) et la conclusion qu'on m'a livrée c'est "ah bah là pijul arrête aussi de bosser en disant qu'il y a conflit".

              Si ça te fait mal de te taper sur le tibia avec une serpette, est-ce que vraiment la bonne solution c'est de la remplacer par une serpette en mousse ?

              dans tous les cas on arrivera sur le même état Q

              Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit. Deuxièmement : encore heureux, si pijul décidait tout seul quoi faire, il pourrait aboutir à un arbre de sources qui ne compile pas…

              là où, par construction, elle est automatiquement satisfaite dans pijul

              Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).

              Outre cette propriété d'associativité des patchs, il y en a une autre fort utile : celle qui cherche à capter l'essence de fonctionnalités orthogonales ou indépendantes. Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat.

              Je veux pas te provoquer de douleur psychique à base de dissonance cognitive, mais, breaking news, dans ce cas de figure (modifications non colocalisées) git fera la même chose !

              Les guides de bonnes pratiques expliquent également comment obtenir une telle chose en git

              Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.

              Ça va faire très argument d'autorité, mais je bosse avec git depuis bientôt 10 ans, et il semble que je sois gâté par la nature sur ce point, ou que j'ai la même topologie neuronale que Linus, car même mes collègues très intelligents se tournent vers moi quand il faut "un guru git" et je suis extrêmement à l'aise avec. Ça n'est pas un argument pro-git (au contraire, à la limite…), c'est pour dire que si tu veux attaquer git avec des exemples, muscle ton jeu, car sortir des contre-vérités évidentes comme ça ne t'aide pas.


              La problématique de fiabiliser la production logicielle m'intéresse réellement. C'est le fait de pouvoir y prendre une bonne part dans ma nouvelle boite, qui m'a fait accepter ce poste. Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot ! Néanmoins, pour l'instant je vois :

              • des approximations voire des contre-vérités sur git

              Certaines par toi que je viens de pointer, certaines par un des auteurs de pijul même, pointées par d'autres ailleurs dans les commentaires.

              • des grands discours faux dans la réalité du travail de développeur

              OK c'est super que pijul ait une théorie lui permettant de toujours produire un résultat déterministe au lieu de lâcher l'affaire ou de diverger; sauf que tu oublies un petit détail : je m'en fous que pijul ait une théorie lui garantissant de toujours être un endomorphisme de "l'ensemble des combinaisons de chaines de caractère" (les "sources") et donc de ne jamais être indéterminé (aucun résultat) ou une distribution (plusieurs "ordonnées" pour une abscisse), car dans le monde réel nous ne travaillons pas sur "l'ensemble des combinaisons de chaines de caractère" mais "l'ensemble des combinaisons de chaines de caractère ayant un sens" (que ce soit un sens du point de vue du compilateur, ou pire du point de vue de leur but métier, c'est-à-dire qu'il faut qu'elles compilent mais en plus qu'elles fassent ce qu'on voulait exprimer).

              Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.

              Indice avant que tu t'échines pour rien : l'auteur de pijul a dit qu'il fera comme git, qu'il s'arrêtera sur un conflit (merde c'est pas un endomorphisme défini sur tout l'ensemble des "trucs à versionner" alors ?? :-( ), alors c'est pas avec tes petits graphiques sans contenu que tu y arriveras.

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 4.

                Non bien sûr, les graphes orientés c'est du bon sens populaire, l'autre jour j'en parlais avec ma boulangère. Elle m'a d'ailleurs dit "oublie pas d'étiqueter les arêtes sinon c'est un peu trop simple".

                Je ne comprends absolument pas le sens de cette partie de ton commentaire. On va reprendre l'historique de nos échanges, ce sera plus clair.

                Tu as commencé par écrire

                git ne gère pas des patchs mais un graphe orienté d'états successifs

                ce à quoi je te réponds

                pijul aussi gère, à sa façon, un graphe orienté d'états successifs : un dépôt c'est une catégorie, c'est-à-dire un graphe orienté qui vérifie certaines propriétés

                tu réagis ensuite par

                C'est marrant comme il suffit de parler d'un concept mathématique relativement avancé en termes un tant soit peu profanes pour t'invoquer.

                et je réponds à cela par

                Je n'ai pas vu à quel moment il a été fait mention d'un concept mathématique relativement avancé en termes profanes. Tu disais que git gère un graphe orienté d'états successifs, je t'ai répondu que pijul faisait de même.

                À moins que j'ai complètement la berlue ou que j'ai perdu la raison, c'est bien toi qui as parlé de graphe orienté et je ne vois toujours pas en quoi c'était en termes profanes. Que ta boulangère ne sache pas ce qu'est un graphe orienté, personne ne l'a nié, mais là n'était pas la question. Le fait est que pijul aussi gère un graphe orienté d'états successifs, la différence entre les deux outils ne se situe pas à ce niveau là. Que ce graphe soit une catégorie (et c'est peut être cette notion que tu appelais « concept mathématique relativement avancé »), on s'en fout un peu dans le fond, raison pour laquelle j'ai ensuite écrit :

                Mais laissons donc de côté le concept de catégorie et gardons donc celui de graphe orienté : il sera compris de tout le monde.

                Il va de soi que par mon tout le monde, j'entendais tout programmeur (ce qui exclus ta boulangère, à moins qu'elle ne programme dans ses moments de loisir), c'est-à-dire les seules personnes susceptibles de discuter des entrailles de ce genre d'outils.

                Reprenons la distinction entre pijul et git.

                les deux graphes colorés un peu différents

                D'accord je vois certains cas où le comportement de git peut différer suivant la stratégie choisie. Ce sont des symptômes de "n'importe quoi as a process".

                Là je ne comprends pas trop non plus. Les deux graphes en question expose la même situation que celle dans le lien du tout premier commentaire de pamaury, et à ce moment tu ne semblais pas avoir compris. Pourtant ils disent la même chose. En revanche tu continues avec :

                J'ai essayé de l'illustrer avec du "vrai code" avec mon histoire de validation d'utilisateur

                sauf que ton exemple ne correspond pas du tout à cette situation. Ton code illustre deux branches qui divergent et qui rentrent en conflit quand on les fusionne : ce n'est pas du tout ce qu'illustrent les graphes colorés. Ils illustrent deux stratégies qui ne génèrent pas nécessairement de conflit mais avec deux résultats différents pour git et un seul avec pijul. Ainsi, lorsque tu écris :

                dans tous les cas on arrivera sur le même état Q

                Premièrement : dans un cas "réel" l'auteur a été obligé d'admettre que pijul n'arrivera nul part, qu'il abandonnera en déclarant un conflit.

                tu n'as toujours pas compris. Non, dans un cas réel il n'y a pas nécessairement conflit et pijul arrivera bien toujours dans le même état Q quelque soit le chemin pris dans le graphe, c'est-à-dire quelque soit la stratégie utilisée. Assurément, bien que git fusionne sans se plaindre (il n'y a pas de conflit) le code ne compilera pas, mais cela demandera un travail supplémentaire au développeur ou alors il faudra utiliser un workflow conditionné par l'outil. On est là dans le même genre de problématiques qu'entre typage statique ou typage dynamique : pour éviter les runtime error (un code qui ne compile pas après fusion) il faut prendre ses précautions.

                Pour la suite :

                là où, par construction, elle est automatiquement satisfaite dans pijul

                Non. Cf. point précédent. Ou alors pour mon code de gestion d'utilisateurs, donne-moi le code final automatiquement produit (indice : il est indécidable (ça devrait te plaire comme mot)).

                Si ! cette propriété est automatiquement satisfaite par construction dans pijul. Cf. mon point précèdent. Ton exemple de code de gestion d'utilisateur est hors propos pour parler de cette spécificité de pijul.

                De plus, personne, mais alors vraiment personne, n'a prétendu qu'il existait un outil de fusion magique qui résout les conflits tout seul. Là n'est pas la question, ni le problème que cherche à résoudre pijul.

                Pour la question des patchs indépendants :

                Non, tu ne les as pas compris. Cf. argument précédent : si deux patchs ne se recouvrent pas "géographiquement" ils sont interchangeables.

                La question n'était pas là mais celle-ci : dans un tel cas, git crée-t-il automatiquement deux branches distinctes dans son graphe d'états pour se faciliter le travail ?

                La problématique de fiabiliser la production logicielle m'intéresse réellement.

                Je veux bien te croire, mais tu ne sembles pas disposer à faire l'effort d'essayer de comprendre ce que les autres écrivent. Dans un autre journal où j'essayais d'illustrer l'analogie stricte entre typage statique et démonstration de théorèmes, tu m'avais également lu de travers. À moins que tu ne considères pas le typage statique comme relevant de la problématique de fiabiliser la production de logicielle. Une partie du système qui gère les lignes automatiques du métro parisien a été développé selon une telle méthodologie, et il est difficile de remettre en cause pas les faits sa fiabilité.

                Je suis un fan de git, mais si concrètement pijul apporte de vraies avancées, j'en parlerai au boulot !

                Si git te satisfait pleinement, pourquoi changer d'outil ? Pijul offre certes des avancés (ne serait-ce que celle de fournir une spécification à la notion de fusion), mais pas celles qui semblent correspondre à tes attentes :

                Et ça pijul ne le garantit évidemment pas, puisqu'il ne parle pas tous les langages de programmation / de balisage / les langues du monde (si on décide de versionner un manuscrit par exemple), et n'a encore moins conscience des specs du code. Je pense l'avoir illustré par mon exemple de fonction de récupération d'utilisateur. Je ne changerai pas d'avis tant qu'on ne m'aura pas prouvé que pijul résout le problème.

                Pijul ne le résout évidemment pas, personne n'a jamais dit le contraire, il n'y a rien à prouver. Tu l'as dit toi même : aucun logiciel ne viendra jamais le résoudre, le problème est indécidable, c'est même pire, il est informulable (le problème n'est pas l'absence de procédure de décision, mais qu'on ne peut même pas l'exprimer formellement).

                Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

                • [^] # Re: Pourquoi du théorie des patch c'est bien

                  Posté par  . Évalué à 3.

                  J'ajouterais un petit détail technique supplémentaire : les conflits dans Git sont bien un truc qu'il "essaie" de résoudre, parce que 3-way merge est une heuristique.

                  De plus, certains conflits sont provoqués par l'outil lui-même, comme par exemple quand on cherry-pique plusieurs fois depuis la même branche.

                  Dans Pijul, au contraire, les conflits sont définis clairement. Ce n'est pas un truc qu'il "n'arrive pas à faire et doit jeter l'éponge", mais au contraire une situation normale. Et c'est d'ailleurs la solution raisonnable : si un outil de résolution automatique de conflits sur du texte était possible, on pourrait essayer de l'appliquer sur des textes produits par des Israéliens et des Palestiniens.

                • [^] # Re: Pourquoi du théorie des patch c'est bien

                  Posté par  . Évalué à 3.

                  Il parle de dissonance cognitive, de mon coté je vois un autre biais dans son raisonnement:un homme de paille. Il construit un raisonnement dans lequel git comm pijul sont indecidabele, donc git est aussi bon que Pijul, et les autres cas OSEF dasn la vrai vie.

                  Du grand art !

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 4.

                Un détail non-technique : je comprends qu'il soit tentant de juger Pijul en discutant des détails d'implémentation de Git.

                Ceci dit, pour être cohérent, il faudrait aussi éviter de dire d'énormes âneries sur des concepts élémentaires d'informatique ("élémentaires" dans le sens "essentiels", pas forcément "simples"). Par exemple, la décidabilité, ça a une définition précise.

                Ou sinon, quand tu écris

                Si, dans un commit, je modifie une partie d'un fichier, puis dans le commit suivant j'en modifie une autre qui n'a rien à voir : peu importe l'ordre dans lequel je les réalise, on devrait aboutir au même résultat.

                Je veux pas te provoquer de douleur psychique à base de dissonance cognitive, mais, breaking news, dans ce cas de figure (modifications non colocalisées) git fera la même chose !

                C'est complètement faux, dans tous les cas. Git n'est jamais commutatif, au contraire : il ordonne scrupuleusement les commits, c'est même sa principale utilité.

                C'est une différence fondamentale entre Git et Pijul : Pijul a un nouveau type de structure de données qui rend la commutativité possible, et cette structure de données est même l'idée centrale (les merge corrects dans 100% des cas sont importants, mais moins).

                Il aurait fallu mieux comprendre l'argument avant de le mépriser : ça m'étonnerait que tu penses que les commits de Git commutent, d'ailleurs tu as parlé de graphes orientés acycliques dans un autre commentaire.

                Ceci n'est pas une critique sur le fait de dire des âneries (c'est cool de se laisser le droit de dire des âneries, de l'accepter et de le reconnaître), mais uniquement sur le mépris.

                Autre exemple du même mépris : toute boulangère ou boulanger qui se déplace de chez lui à sa boulangerie en passant par des rues a chaque jour une expérience directe des graphes orientés, avec des étiquettes sur les arêtes.

                Cet exemple est loin d'être anodin : le seul truc que Pijul essaie de faire, c'est de modéliser proprement l'expérience directe et quotidienne de millions de programmeur, et d'implémenter une théorie conforme à leur expérience quotidienne directe.

                Les deux types de mépris (envers "la boulangère" et envers Pijul) se ressemblent étrangement, non ?

                • [^] # Re: Pourquoi du théorie des patch c'est bien

                  Posté par  . Évalué à 2.

                  C'est complètement faux, dans tous les cas. Git n'est jamais commutatif, au contraire : il ordonne scrupuleusement les commits, c'est même sa principale utilité.

                  Il est tout de même possible de réordonner manuellement l'historique à coup de git rebase -i. Après contrairement à pijul, il faut le faire à main, rien ne garantie que les commits que l'on réordonne commutent, on peut supprimer un commit sans supprimer la clôture transitive de ses dépendances futures… C'est totalement casse-gueule, il faut être un git guru et avoir une connaissance précise de l'historique.

                  Je t'accorde que c'est une conception assez étrange de l'informatique que de ne pas automatiser ce qui peut l'être, et cela sans filet de sécurité.

                  Autre exemple du même mépris : toute boulangère ou boulanger qui se déplace de chez lui à sa boulangerie en passant par des rues a chaque jour une expérience directe des graphes orientés, avec des étiquettes sur les arêtes.

                  À sa décharge, je ne pense pas que c'était du mépris vis à vis de sa boulangère, mais seulement qu'elle n'emploie pas le terme de « graphe orienté » pour décrire son déplacement dans des rues. Après je suis bien d'accord qu'elle en a une expérience directe et quotidienne, et que les raisonnements qu'elle effectue sont identiques à ceux que l'on fait en théorie des graphes. L'exemple historique typique sur le sujet est celui de Socrate faisant démontrer le théorème de Pythagore (sous la forme du problème de la duplication du carré) à un jeune esclave dans le dialogue du Ménon, en lui posant seulement des questions, laissant son auditeur y répondre tout seul, et introduisant seulement à la fin de leur échange le terme technique de diagonale du carré. L'art du mathématicien étant, comme le disait Poincaré, de donner le même à nom des choses qui se distinguent par leur contenu mais sont identiques dans leur forme.

                  Cet exemple est loin d'être anodin : le seul truc que Pijul essaie de faire, c'est de modéliser proprement l'expérience directe et quotidienne de millions de programmeur, et d'implémenter une théorie conforme à leur expérience quotidienne directe.

                  Ce qui est conforme à ce que doit faire toute bonne théorie : la théorie n'est que l'universelle pratique mise en principes.

                  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: Pourquoi du théorie des patch c'est bien

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 19 septembre 2017 à 23:50.

          Après, je ne sais pas si en pratique cela s'avérera d'un grand intérêt et plus souple à l'usage que l'existant, mais la théorie qu'il y a derrière est jolie. Elle est expliquée plus en détail dans ces deux articles de blogs :

          Merci pour ces références! Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles – il faut se souvenir que GIT ne sauvegarde pas les résolutions de conflit – à moins d'un paramétrage spécial. C'est gênant lorsqu'on travaille sur l'historique, par exemple, dans les rebase complexes où figurent des résolutions de conflit, que git demande de résoudre à nouveau. Par ricochet cela rend inutilement pénible la fusion de deux dépôts GIT, puisque l'approche bébête consistant à importer (fetch) une deuxième historique COMMIT-0 … { historique complexe … } COMMIT-1 puis à faire un cherry-pick de COMMIT-0 sur la tête de la vieille historique puis un rebase de COMMIT-0..COMMIT-1 ne marche pas. Le problème peut être résolu grâce au filter tree mais c'est bien plus compliqué à mettre en œuvre et incroyablement lent. (J'en ai récemment fait un de 12h sur une historique assez modeste, 4 ans et équipe de 4 à 8 personnes.)

          • [^] # Re: Pourquoi du théorie des patch c'est bien

            Posté par  . Évalué à 2.

            il faut se souvenir que GIT ne sauvegarde pas les résolutions de conflit

            Dans un rebase je suis d'accord dans un merge je le suis beaucoup moins.

            • [^] # Re: Pourquoi du théorie des patch c'est bien

              Posté par  (site web personnel) . Évalué à 4. Dernière modification le 20 septembre 2017 à 10:03.

              Qu'est-ce que tu veux dire exactement?

              Ce dont je parle est la situation suivante: partant de la branche maintenance/v2.0 deux branches fix/bug-1 et fix/bug-2 sont “mergées“ vers une nouvelle branche patchset/v2.0.1 elle aussi issue de maintenance/v2.0, ce qui donne lieu à une résolution de conflit. Si maintenant on décide que le “patchset” patchset/v2.0.1 ne soit finalement pas ajouté à maintenace/v2.0 mais seulement à master alors on a envie de “rebaser” la branche maintenance/v2.0..patchset/v2.0.1 sur master et cela ne marche pas facilement parceque dans sa version la plus simple l'appel

              git rebase --onto master --preserve-merges patchset/v2.0.1 maintenance/v2.0`
              

              demande de rerésoudre les conflits résultant du “merge” de fix/bug-1 et fix/bug-2. C'est dans ce sens que “git ne sauvegarde pas les résolutions de conflit”. Ce comportement peut dépendre de la version (2.8.4 ici) et de la configuration (cf. rerere) mais c'est dans certains cas le fonctionnement normal de git.

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 3.

                Ah d'accord je vois ce que tu veux dire. Ce que je voulais dire c'est quand tu fais un merge (et pas un rebase) si tu as des conflits ils sont gardes dans un commit specifique contrairement a rebase ou tu les resouts un par un dans une branche detache et tu n'auras plus de trace des resolutions une fois le rebase fini (enfin il me semble).

              • [^] # Re: Pourquoi du théorie des patch c'est bien

                Posté par  . Évalué à 2.

                C’est un peu à côté de la plaque, mais si t’as vraiement autant de branches que ça, le problème c’est pas l’algorithme de merge ou le fait que rebase écrase les merge conflict…

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: Pourquoi du théorie des patch c'est bien

                  Posté par  . Évalué à 10.

                  Pas vraiment. Par exemple, dans un projet de petite taille comme Pijul, qui a été essentiellement écrit à deux, on travaillait tous les deux sur quarante trucs à la fois.

                  On a utilisé Darcs, et presque chaque patch avait une nouvelle fonctionnalité ou une nouvelle résolution de bug. Pour faire la même chose avec Git, il nous aurait effectivement fallu plusieurs dizaines de branches. Pire, il aurait fallu se souvenir, en même temps qu'on démouchait du code, de la branche courante et des interactions potentielles avec toutes les autres branches.

              • [^] # Re: Pourquoi du théorie des patch c'est bien

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

                Cf. git rerere :)

          • [^] # Re: Pourquoi du théorie des patch c'est bien

            Posté par  . Évalué à 2.

            Au delà de l'aspect esthétique – dont l'expérience montre en général qu'un problème mieux représenté est également mieux compris et les traitements afférents sont plus faciles

            Au fond, je n'en doute pas vraiment. J'ai présenté la chose ainsi1 pour ne pas heurter certaines sensibilités. Si je devait faire un parallèle, le fondement du système me fait penser au passage du paradigme ptoléméen avec ces épicycles au paradigme héliocentrique de Copernic et Kepler.


            1. en fait, j'ai eu ce week-end des idées similaires pour essayer de fonder les Modular Implicits en OCaml; mais sur cette dernière question il faut que j'approfondisse encore mes pressentiments pour être sûr que ce n'est pas un cul de sac. 

            Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

  • # Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

    Posté par  . Évalué à 10.

    Is it possible to refer to a specific version?

    Yes! Although nothing is implement so far, we currently see two possibilities:

    Oui, c'est possible, enfin, on sait pas trop mais ça doit bien pouvoir se faire, on à même de superbes idées sur comment faire…
    Du coup, on fait comment pour contribuer à un logiciel?

    Parce que sans moyen actuel de se référer à une version (que ce soit des numéros de révisions comme SVN ou des hash de commit comme git, peu importe, tant qu'on peut différencier les versions) je vois très mal comment discuter de problèmes (j'utilise un soft, je vois un bug ou une fonctionnalité qui serait intéressante, comment je fais pour savoir que j'ai bien la dernière version et que donc mon problème est encore d'actualité?)…

    Pour moi, en tout cas, c'est pas un frein, mais bien un point bloquant.

    • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

      Posté par  . Évalué à 10.

      Oui, c'est possible, enfin, on sait pas trop mais ça doit bien pouvoir se faire, on à même de superbes idées sur comment faire…

      Non, en l'occurrence c'est plutôt "c'est déjà implémenté dans la bibliothèque, c'est rétro-compatible, mais il faut écrire plein de commandes supplémentaires, ce qui implique de bike-shedder beaucoup, et il y a plein de trucs d'ingénierie plus urgents à résoudre".

      Exemples de trucs d'ingénierie :

      • s'assurer que notre bibliothèque SSH marche correctement sur toutes les plateformes. Oui, j'ai écrit une bibliothèque SSH, c'est l'un des inconvénients de travailler avec un langage trop jeune.
      • faire en sorte de lire ~/.ssh/config, et résoudre tous les problèmes avec les clefs protégées par mot de passe.
      • résoudre les deux ou trois problèmes restants sur nest.pijul.com. Il est tout asynchrone, mais un thread peut parfois se retrouver bloqué par une opération sur un dépôt, sans que le reste de la boucle d'événements puisse avancer pour le débloquer.

      Et il y a des trucs qui demandent des algorithmes plus durs à écrire, comme par exemple l'affichage des patchs déjà recordés dans le terminal, ou l'affichage plus complet des contextes des patchs sur nest.pijul.com.

      • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

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

        s'assurer que notre bibliothèque SSH marche correctement sur toutes les plateformes. Oui, j'ai écrit une bibliothèque SSH, c'est l'un des inconvénients de travailler avec un langage trop jeune.

        Et déléguer tout ça à OpenSSH (comme le fait Git, sous GNU/Linux du moins), ce n’était pas envisageable ?

        Un programme qui vient avec sa propre implémentation de SSH, c’est un programme ui dans 99% des cas :

        • ignore le contenu de ~/.ssh/config,
        • ou essaie de prendre en compte ce fichier mais n’en gère pas toutes les subtilités (ProxyCommand par exemple),
        • ne sait pas utiliser un agent SSH.

        Rien que le dernier point rend un tel programme inutilisable pour moi, ma clef privée étant stockée sur une carte à puce rendant l’utilisation d’un agent indispensable.

        J’admets ne pas lire le Rust couramment, mais je ne vois rien dans le code de thrussh ou de pijul lui-même qui me laisse penser que le protocole SSH-Agent est pris en charge.

        • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

          Posté par  . Évalué à 10.

          Et déléguer tout ça à OpenSSH (comme le fait Git, sous GNU/Linux du moins), ce n’était pas envisageable ?

          Excellente question ! D'autant que je suis moi-même un utilisateur de Yubikey, et j'ai une clef SSH cryptée avec.
          En fait j'aurais même pu déléguer à libssh et/ou libssh2. Il y a eu plusieurs raisons à ce choix :

          • OpenSSH ne marche pas bien sous Windows. Des projets avec peu de moyens d'ingénierie, comme par exemple Darcs, sont empêtrés là-dedans depuis des années.

          • J'avais https://nest.pijul.com en tête quand j'ai commencé à écrire Thrussh. Maintenir une version d'OpenSSH à jour et sécurisée sur un serveur distant était une tâche au-dessus de mes compétences en administration système, et du temps que nous pouvions passer à l'administration. En fait, j'ai commencé par écrire un binding Rust vers la partie serveur de libssh. Au bout de 5000 lignes de bindings, de cheveux arrachés à lire leur code C (la doc n'existe presque pas), et toujours pas de serveur en vue, j'ai craqué.
            Bien sûr, je pourrais maintenir une version de Pijul qui parle à OpenSSH, et une autre qui parle au client de Thrussh. Ou même ne pas maintenir le client, et seulement un serveur. Mais écrire/maintenir un client et un serveur est moins cher que l'un des deux seulement, parce qu'on peut tester plus facilement avec des tests d'intégration. Comme je n'ai pas un temps infini, c'est pratique. En plus, le serveur de Thrussh n'a pas beaucoup d'utilisateurs (il est vraiment jeune), donc les rapports de bugs sont plutôt sur le client, et les réparations sont souvent communes avec le serveur.

          • On finira par lire ~/.ssh/config et prendre en compte les agents, mais ce n'est pas du tout le rôle de Thrussh de faire ça. L'idée de Thrussh (contrairement au monolithique OpenSSH) est d'offrir une petite bibliothèque facile à utiliser et à auditer, et qui contient tout le protocole SSH 2. J'ai commencé à implémenter les agents dans une autre bibliothèque, et j'ai été pour l'instant bloqué par des choix contradictoires entre *ring* (une bibliothèque de crypto en Rust) et le protocole. Mais ça viendra !

          • Il y a eu un gros effort sur la crypto en Rust. Des bibliothèques comme *ring* ont commencé à tourner un petit peu avant Thrussh, et c'était l'occasion de contribuer à faire évoluer l'écosystème. Le problème des agents met en valeur un cas que *ring* n'avait pas prévu, par exemple.

          • Pareil pour Mio et Tokio, deux excellents projets pour les entrées-sorties asynchrones en Rust. Mio est arrivé avant Thrussh, et Tokio un peu après (mais maintentant Thrussh ne parle plus qu'à Tokio, Mio est la couche du dessous).

          • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

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

            Maintenir une version d'OpenSSH à jour et sécurisée sur un serveur distant était une tâche au-dessus de mes compétences en administration système,

            apt install openssh-server ou équivalent c'était trop compliqué, donc pour faire plus simple je réimplémente SSH ? Si la page Wikipedia pour NIH avait besoin d'une illustration, elle est servie.

            • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

              Posté par  . Évalué à 9.

              apt install openssh-server ou équivalent c'était trop compliqué, donc pour faire plus simple je réimplémente SSH ? Si la page Wikipedia pour NIH avait besoin d'une illustration, elle est servie.

              Ce n'est pas du tout ce que j'ai écrit dans mon commentaire. D'abord il y a d'autres raisons que j'ai expliquées, par exemple au sujet de Windows. Était-ce "trop compliqué" de lire ces lignes dans mon commentaire avant de répondre n'importe quoi ?

              Ensuite, le cas précis de mon serveur est particulier : je veux pouvoir laisser n'importe qui envoyer des patchs, ou enregistrer une nouvelle clef publique, par SSH. Je veux aussi que mon serveur tourne vite. En fait je veux qu'il tourne super vite. Et d'ailleurs ses utilisateurs le remarquent ici ou .

              Pour ça j'ai besoin de plusieurs choses :

              • Un contrôle total sur les interactions entre le client et le serveur, alors qu'OpenSSH ne me permet que de lancer un exécutable à distance. Je veux aussi pouvoir enregistrer les clefs de l'utilisateur s'il m'a donné un password correct, par exemple, et s'il me confirme qu'il veut enregistrer sa clef. OpenSSH ne me permettrait de faire ça qu'à grands renforts de scripts pour parser les logs, qu'il serait difficile à intégrer au reste du service, à moins de hacks qui finiraient par casser rapidement.

              • Une connexion avec une base de données. Les clefs publiques des utilisateurs ne sont pas stockées dans un fichier, mais dans une base de données PostgreSQL.

              • Une interdiction absolue de faire quoi que ce soit d'autre que les trucs autorisés. Je ne sais pas sécuriser ce type de trucs, il y a trop de pièges qu'on peut envoyer dans des arguments de shell, et ça nécessite une équipe pour veiller dessus, quand on veut faire les choses bien. Pareil pour les mécanismes d'authentification : OpenSSH peut certainement utiliser des tas de modules pam, mais je ne sais pas faire, et les experts de ça que je connais y ont passé dans leur vie environ 100 fois le temps-homme que Thrussh, et il reste encore sans doute plein de failles dans leurs configurations.

              • Je veux une performance de ouf sur mon serveur. Fork + exec de la part d'OpenSSH serait déjà beaucoup, et je ne parle pas du changement de contexte entre process à chaque connexion.

              Maintenant j'ai tout ça à la fois, avec en prime des trucs de sécurité intéressants fournis par l'IO asynchrone, comme des délais avant accept() de plus en plus grands quand les connexions n'aboutissent pas à une authentification réussie.
              Avant de commencer j'avais un peu discuté avec un ingénieur de chez SSH (l'entreprise finlandaise) quand j'habitais à Helsinki, ce qui a un peu achevé de me convaincre.

              • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

                Posté par  . Évalué à 5.

                Était-ce "trop compliqué" de lire ces lignes dans mon commentaire avant de répondre n'importe quoi ?

                Tu es nouveau ici :-p raconter n'importe quoi c'est juste une manière de dire bonjour :-)

              • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

                Posté par  (site web personnel) . Évalué à 2. Dernière modification le 30 septembre 2017 à 02:00.

                apt install openssh-server ou équivalent c'était trop compliqué, donc pour faire plus simple je réimplémente SSH ? Si la page Wikipedia pour NIH avait besoin d'une illustration, elle est servie.

                Ce n'est pas du tout ce que j'ai écrit dans mon commentaire.

                Maintenir une version d'OpenSSH à jour et sécurisée sur un serveur distant était une tâche au-dessus de mes compétences en administration système, et du temps que nous pouvions passer à l'administration. En fait, j'ai commencé par écrire un binding Rust vers la partie serveur de libssh. Au bout de 5000 lignes de bindings, de cheveux arrachés à lire leur code C (la doc n'existe presque pas), et toujours pas de serveur en vue, j'ai craqué.

                Non tu n'as jamais écrit ça, ostensiblement. Moi aussi je trouve plus simple d'écrire 5000 lignes de code (orienté crypto qui plus est…) que d'installer le serveur OpenSSH packagé par ma distrib qui fournit une config maintenue et sécurisée. En plus quand je comprends pas l'install et la config de 50 lignes d'un serveur, il est évident que je ferai mieux en l'écrivant moi-même…

                • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

                  Posté par  . Évalué à 7.

                  En quoi ce commentaire est-il constructif ?

                  Si tu avais lu le commentaire auquel tu réponds, tu n'écrirais pas ça. Mais je peux répondre à ce que tu dis :

                  Moi aussi je trouve plus simple d'écrire 5000 lignes de code (orienté crypto qui plus est…) que d'installer le serveur OpenSSH packagé par ma distrib

                  Ce que tu écris est faux : Windows, une "distrib" très courante, ne package pas le client d'OpenSSH.

                  5000 lignes, ce n'est pas Thrussh, c'est les bindings que j'avais entrepris vers Libssh, une bibliothèque C existante qui implémente SSH. La prochaine fois, essaie de lire avant de répondre.

                  qui fournit une config maintenue et sécurisée.

                  Oui, pour un cas d'utilisation complètement différent du mien. Je veux que mon serveur accepte des patchs, ne fasse rien d'autre, et vérifie les mots de passe et les clefs avec une base de données.

                  OpenSSH ne fait pas ça. La combinaison OpenSSH + shell + pam + dix modules de pam fait peut-être ça, après plusieurs semaines à temps plein de configuration.

                  En plus quand je comprends pas l'install et la config de 50 lignes d'un serveur, il est évident que je ferai mieux en l'écrivant moi-même…

                  Autre exemple de mépris, et autre exemple d'ânerie : la configuration d'OpenSSH avec PAM pour parler à PostgreSQL, avec toutes les barricades pour éviter que le client ne fasse des trucs louches avec les commandes shell, ce n'est pas 50 lignes, ça ne s'écrit pas en deux minutes, et ce n'est pas facile à sécuriser.

                  En plus, il est hors de question pour le Nest de laisser OpenSSH lancer Pijul à chaque commande. Le Nest est asynchrone, et Pijul prend un lock sur le dépôt, ce qui bloquerait au moins un thread du serveur (très grave en asynchrone), et potentiellement le serveur entier, à chaque fois que quelqu'un pousse un patch.

                  • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

                    Posté par  . Évalué à 2.

                    avec PAM

                    Du coup, complètement hors sujet, mais PAM, c'est quoi, en vrai, l'intérêt de ce truc?
                    J'ai vaguement compris que c'est censé être une lib pour gérer la sécurité, mais ça m'a toujours eu l'air vachement complexe et lourd, un peu trop peut-être pour être vraiment sûr? Il y a des gens qui utilisent vraiment ce truc? Je veux dire, volontairement, en dehors du fait que ce soit installé par défaut sur la distribution… j'ai cru comprendre que certaines (slackware, pour ne pas la nommer) s'abstenaient de l'utiliser?

                    Bon, tu ne sais peut-être pas, mais vu que tu en parles je me suis dit que tu avais essayé de comprendre le fonctionnement de ce machin :)

                    • [^] # Re: Is it possible to refer to a specific version? Yes. Maybe. In practice, no.

                      Posté par  . Évalué à 1.

                      PAM est une système modulaire pour gérer l'authentification sur des machines Unix. Certains de ses modules parlent avec des serveurs LDAP, d'autres comprennent les tickets Kerberos, etc.

                      Le module le plus commun consiste à gérer l'authentification par mot de passe, mais dans le contexte d'une grosse organisation, ça devient vite très limité : les gens veulent se connecter sur plusieurs machines, parfois à distance et avec plusieurs protocoles (SSH, IMAP, etc.), veulent changer leur mot de passe, accéder à des services web avec le même mot de passe, etc.

                      Je ne sais pas qui utilise Slackware dans ce genre de contexte.

                      ça m'a toujours eu l'air vachement complexe et lourd, un peu trop peut-être pour être vraiment sûr

                      Oui, mais dans une grosse boîte ce n'est pas un gros problème : il y a des équipes pour le sécuriser. Dans mon cas, je n'ai pas ça. Et même si j'avais plus de gens sur le projet, je préférerais qu'ils travaillent sur d'autres trucs.

  • # Preuves ?

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

    …qui fournit les théorèmes, des preuves et la complexité algorithmique du programme

    Alors :

    • théorèmes, ok (cf. commentaire de Kantien, c'est basé sur la théorie des graphes.
    • Complexité algorithmique du programme : ok
    • Preuves : Pas ok

    De quoi parle-t-on au juste ici pour les preuves ? Démonstration mathématique basée sur les théorèmes précédant ou preuves de bon fonctionnement du programme ?
    Il ne semble pas qu'il y ait, en Rust, moyen de prouver le bon fonctionnement du programme.
    Si ?

    • [^] # Re: Preuves ?

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

      J'ai lié dans le journal ce commentaire

      Il y aura publication d'ici la fin d'année. Donc on verra bien.

      Est-ce que l'algo seul peut être prouvé sans que le programme complet soit prouvé ? Je ne sais pas.

      Côté Rust il y a quelqu'un qui travaille dessus :
      https://www.ralfj.de/blog/2017/07/08/rustbelt.html

      • [^] # Re: Preuves ?

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

        Est-ce que l'algo seul peut être prouvé sans que le programme complet soit prouvé ? Je ne sais pas.

        Alors, tout dépend de la techno utilisée.
        De ma petite expérience en Spark, on peut prouver des morceaux du programme en ne marquant que certaines unités de compilation comme étant en Spark.
        Typiquement, les entrées/sorties sont exclues du sous-ensemble vérifiable par Spark.
        Mais, il faut bien voir qu'il faut quand même écrire les annotations Spark dans le code Ada pour pouvoir prouver quoique ce soit et ça, c'est pas forcément toujours très aisé.

        Côté Rust il y a quelqu'un qui travaille dessus

        Après, j'ai aussi vu un Coq2Rust permettant donc de créer son programme Rust à partir d'un programme Coq mais j'avoue ne pas avoir regardé plus que ça.

      • [^] # Re: Preuves ?

        Posté par  . Évalué à 8.

        Salut ! Je suis un des auteurs de Pijul.

        Est-ce que l'algo seul peut être prouvé sans que le programme complet soit prouvé ? Je ne sais pas.

        Ce n'est pas non plus ce qu'on demande aux autres (dont Git et Mercurial), mais j'avoue qu'on a hésité entre Rust et Idris à un moment, entre autres pour cette raison.

        Si les algos sont prouvés, c'est déjà bien mieux que Git par exemple (en plus, quelle spécification donner à Git, vu qu'il fait parfois des bêtises ?).

        Je veux bien aider des gens à le prouver, par contre, mais il faut commencer par les fondations (qui nous ont pris plus de temps que le projet lui-même). Exemples :

        • Sanakirja, un dictionnaire clef-valeur à la LMDB, mais avec des tables forkables efficacement (la complexité est compliquée à expliquer, je l'ai fait ). Le code n'est pas très gros, mais les algos sont un peu tordus : il y a des skiplists et des B trees, mais tout est transactionnel, y compris la gestion de la mémoire. Exemple, si on débranche la machine au milieu d'une transaction qui a alloué plein de blocs dans le fichier, quand on redémarrera, la base de données sera retrouvée exactement dans l'état initial (et Sanakirja n'a rien de spécial à faire, il n'y a pas besoin de journal, c'est seulement que le commit de transaction est atomique).

        • Thrussh, une bibliothèque SSH asynchrone.

        • [^] # Re: Preuves ?

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

          Donc en fait tu ne bosses pas sur projet qui mérite une dépêche, mais plusieurs.

          Je me sens nul…

          • [^] # Re: Preuves ?

            Posté par  . Évalué à 4.

            Je me sens nul…

            C'est pas trop l'objectif.
            Au contraire, viens coder avec nous, il y a du boulot !

            • [^] # Re: Preuves ?

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

              C'était une façon détournée de dire "bravo" et "j'ai hâte de lire ces dépêches". :)

              (en vrai je code déjà du libre à plein temps ; ça vaut ce que ça vaut, mais je pourrai difficilement faire plus)

    • [^] # Re: Preuves ?

      Posté par  . Évalué à 1.

      Je pense qu'il ne parle que de la preuve des théorèmes et de l'algo, pas du programme.

  • # Transport via SSH

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

    J'ai un peu regardé le projet, et j'ai l'impression que le seul transport est via SSH. Est-ce correct ?

    Pourquoi ce choix ? Je trouverais dommage d'abandonner HTTP (ou websocket si on veut un mode connecté).

    • HTTP permet plein de choses en matière de proxy ou d'authentification
    • j'aime bien que SSH ne serve qu'à l'administration (donc ouvert uniquement à un sous-réseau dédié), en ouvrant un serveur HTTP (qui tourne avec un simple utilisateur) pour les services.

    Enfin, peut-être que je me trompe complètement :)

    • [^] # Re: Transport via SSH

      Posté par  . Évalué à 2.

      Très bonne remarque. Note que nest.pijul.com, notre service d'hébergement, a évidemment une partie HTTP. Il contient aussi un petit serveur SSH maison qui ne sert qu'à ça. Il est impossible d'ouvrir une session pour "faire de l'administration" dessus, non pas parce qu'il est "très bien sécurisé", mais parce qu'il ne gère pas un paquet de trucs, entre autres les sessions.

      La bibliothèque elle même saurait les gérer, mais le serveur ne contient pas le handler qui permettrait d'ouvrir un pseudo-terminal ou une session.

      Note d'autre part que SSH est un protocole bien plus général que ce qu'on lui fait souvent faire : il a deux ou trois commandes pour ouvrir des sessions et renvoyer des ports TCP, mais il sait aussi envoyer des données arbitraires sans avoir besoin d'une session, d'un shell ou d'un programme autre que le client et le serveur.

      À la dernière RustFest, j'avais par exemple live-codé un prototype de communication entre microservices.

      Pour répondre à ton commentaire, depuis Pijul, on peut cloner ou puller depuis HTTP, mais pusher seulement par SSH.
      On aura peut-être des pushs par HTTP dans le futur (et on accepte très volontiers une contribution là-dessus, même si ce n'est "que" du design), mais il y a plusieurs inconvénients aujourd'hui au niveau de l'expérience utilisateur :

      • J'ai du mal à voir un cas de figure précis où on voudrait ça. Si tu as une machine dans le cloud par exemple, d'où viendrait le serveur HTTP capable de gérer ça ? Et pourquoi avoir besoin d'une authentification/proxy très sophistiquée ? Pourquoi SSH ne serait pas suffisant ? Faire de l'UX sans cas un peu précis, c'est compliqué. Mais je suis ouvert à la discussion là-dessus.

      • S'authentifier en HTTP est compliqué, et nous n'avons pas encore imaginé de manière de rendre ça fluide en ligne de commande (c'est quand même le principal objectif du projet). Dans un navigateur, il y a plein de manières de s'authentifier : SSO, OAuth, Mots de passe, Yubikeys, pseudo-2-factor avec un téléphone, gestionnaires de mots de passe… Comment on fait ça en ligne de commande ?

      • [^] # Re: Transport via SSH

        Posté par  . Évalué à 3.

        Et pourquoi avoir besoin d'une authentification/proxy très sophistiquée ? Pourquoi SSH ne serait pas suffisant ?

        Tu peux déjà avoir une infra qui toute la chaine d'authentification en place pour HTTP (LDAP, Kerberos, TLS client…) . Cela peut être plus simple de réutiliser cela avec un reverse proxy que de devoir refaire la même configuration pour SSH et ne pas oublier de la modifier là en plus que les autres.

        Comment on fait ça en ligne de commande ?

        On arrive bien à faire du TLS client, du Kerberos, du 2factor, du Yubikey en SSH en ligne de commande. Pourquoi on n'y arriverait pas en HTTP ?

        « 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: Transport via SSH

          Posté par  . Évalué à 4.

          Oups, je me rends compte que j'avais oublié autre chose : les performances de HTTP <= 1.1 n'égalent pas SSH, qui a des paquets binaires, le multiplexage de flux, et les connexions ouvertes longtemps (websocket est un peu un hack, quand même).

          Avec HTTP 2, on pourra comparer.

          Tu peux déjà avoir une infra qui toute la chaine d'authentification en place pour HTTP (LDAP, Kerberos, TLS client…) .

          Bonne remarque. Mais sauf si j'ai loupé un truc, la question n'est donc pas "je voudrais bien pousser en HTTP", mais plutôt "je voudrais bien que Pijul gère les cent-cinquante standards différents d'authentification en HTTP".

          Ou alors il doit y avoir un moyen générique de faire faire ça à un proxy ? Je serais bien content d'avoir une référence à lire sur le sujet.

          On arrive bien à faire du TLS client, du Kerberos, du 2factor, du Yubikey en SSH en ligne de commande.

          On pourrait certes y arriver, mais ce n'est quand même pas (à mon avis) le même degré de complexité. SSH est un seul protocole, qui comporte trois façons de s'authentifier (password, public key, none), plus une extension très utilisée (keyboard-interactive, utilisée par OpenSSH pour les mots de passe à la place de password).

          Tout est spécifié de manière extrêmement précise dans une seule RFC (plus l'extension dans une autre RFC), et on a déjà une bonne sécurité une fois qu'on a ça. C'est tellement facile à implémenter que les implémentations les plus utilisées ont des failles de sécurité qui se comptent sur le doigts de la main, alors qu'OpenSSL a un très gros problème par an, et plusieurs petits chaque mois.

          • [^] # Re: Transport via SSH

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

            Ah non, il n'y a pas forcément besoin de gérer toutes les méthodes d'authentification HTTP… qui ne sont d'ailleurs pas forcément si nombreuses que ça côté client (beaucoup sont faites par le site lui-même, pas en HTTP : si tu regardes les pages web, le code renvoyé est toujours 200 et non 401/403). Mais les principales pourraient l'être.

            Après, tu peux effectivement faire confiance au proxy (apache ou nginx), qui va (par exemple) ajouter un header HTTP (souvent REMOTE_USER) contenant le nom d'utilisateur. Le serveur applicatif n'a plus qu'à utiliser ce header HTTP, et c'est gagné.

            Au passage, SSH connaît d'autres méthodes que les trois que tu cites (notamment Kerberos/GSSAPI) :)

          • [^] # Re: Transport via SSH

            Posté par  . Évalué à 3.

            Ou alors il doit y avoir un moyen générique de faire faire ça à un proxy ? Je serais bien content d'avoir une référence à lire sur le sujet.

            Il me semble que la convention, c'est de définir le header REMOTE_USER.

            « 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: Transport via SSH

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

        • je ne connais pas bien le cloud, mais je n'ai jamais eu de problème à installer un git avec authentification Kerberos en HTTP (y compris en bidouillant gitlab pour le faire sur la version open-source) sur des machines à ma disposition. Ensuite, même si SSH permet de faire plein de choses, je ne suis pas sûr qu'il soit aussi souple que HTTP (ce n'est pas un reproche, ils n'ont pas été conçu pour faire la même chose) :

          • plein de serveurs HTTP existent pour faire des proxy (reverse ou forward)
          • pas besoin d'ouvrir de nouveaux ports si le 443 est déjà ouvert (j'aime bien limiter les ports ouverts)
          • on peut faire des accès sans authentification (sauf si on fait de l'authentification SSL mutuelle, certes), quelque soit le serveur
          • on peut mettre un certificat SSL sur le serveur (pour être sûr de s'adresser au bon serveur dès la première connexion) — ok, si on a la main sur le DNS, on peut également faire ou un LDAP, ça peut être jouable en SSH… mais c'est bien plus complexe
          • on peut faire des virtualhost (donc plusieurs sites qui n'ont rien à voir entre eux sur le même serveur)
          • des milliards de plugins d'authentification sont déjà codés, avec notamment la capacité de bien dissocier la phase d'autorisation et celle de l'authentification (je m'authentifie en Kerberos, mais c'est un serveur LDAP qui m'attribue les droits)
          • OpenSSH n'est pas franchement pensé pour avoir plusieurs serveurs simultanés (ne serait-ce qu'un tournant root et l'autre avec un utilisateur standard), ce qui est requis pour éviter d'exposer un service root aux utilisateurs
          • cURL est là pour faire des requêtes en lecture
        • Je connais essentiellement Kerberos comme authentification (c'est du du SSO), et git sait s'en servir de façon transparente en HTTP (le serveur lui réclame du Kerberos, le client se contente de lui en fournir). J'ai également une Yubikey, mais elle me permet de récupérer mon ticket Kerberos au login, du coup je ne sais pas si on peut faire de l'authent' SSL avec git de façon simple.
          En termes d'interface, je ne vois pas trop en quoi ça serait différent par rapport au SSH. cURL propose plein d'authentifications, si tu veux regarder :)

        • [^] # Re: Transport via SSH

          Posté par  . Évalué à 1.

          Merci pour les références ! Mon problème d'interface utilisateur était essentiellement lié à l'authentification (je ne connais pas grand chose à tout ça en HTTP).

          Effectivement, c'est envisageable.

        • [^] # Re: Transport via SSH

          Posté par  . Évalué à 3.

          Certains de tes arguments sont inversables me semble, voire errones:

          • pas besoin d'ouvrir de nouveaux ports si le 22 est deja ouvert
          • ssh force l'authentification, mais n'impose pas d'authentification forte. Utiliser une cle sans pass, ca me semble proche de ce que fait https: on pourrait considerer ca comme un simple certificat, avec non pas le but d'authentifier le serveur (ce cote etant automatique avec ssh me semble) mais l'utilisateur, certes. Enfin, d'un autre cote mieux vaut ne pas laisser n'importe qui pousser un patch.
          • openssh n'est pas adapte a plusieurs instances. Peut-etre (jamais essaye, ca serait amusant de verifier) mais on s'en fout: pijul implemente un autre serveur ssh, lui pourra tres bien l'etre.

          De maniere generale, j'ai l'impression que tu confonds le protocole SSH et le serveur OpenSSH. Et meme si un certain nombre de tes arguments sont valides (moins d'usages actuels pour ssh que http, donc moins de code) je trouve quand meme ssh plus pertinent des lors que l'on a besoin de sessions: les "cookies du http", ca fait quand meme gros hack, avec re-nego tcp a chaque transfert de fichier en plus.

          • [^] # Re: Transport via SSH

            Posté par  . Évalué à 1.

            Sur la distinction protocole SSH / serveur OpenSSH, c'est totalement vrai. Par contre, pour le coup de la clef sans mot de passe, je ne suis pas sûr de suivre : tout ce que fait le mot de passe est de crypter la clef secrète sur le disque. Si ton disque est déjà crypté, c'est redondant, parce que le noyau linux remplit alors exactement le même rôle qu'un agent SSH,
            avec cryptsetup comme interface (sauf que le noyau tourne en root, ce qui protège même un peu mieux la clef).

            Sur les gros hacks de HTTP, je suis totalement d'accord. Les websockets sont un autre exemple de trucs pour lesquels le protocole n'était clairement pas prévu.
            Mais HTTP 2 résout une partie des problèmes de performance de HTTP 1/1.1, et c'est vrai que plein d'entreprises ont des systèmes d'authentification basés sur les hacks en question. Étant donné que le principal argument de Pijul pour des entreprises d'une taille suffisante pour utiliser ce type de hacks est "on passe à l'échelle bien mieux que Git", je suis d'accord que ça vaut le coup de s'y préparer.

            Le seul truc un peu relou pour l'instant étant la transition "je récupère un cookie/ticket SSO dans mon navigateur, et je le file à Pijul en ligne de commande".
            Notre objectif (on n'y est pas encore) est que n'importe quel débutant en programmation soit capable d'utiliser Pijul sur son premier projet, et qu'il n'ait (presque) rien à apprendre ensuite, même pour aller travailler sur un énorme projet propriétaire.

            • [^] # Re: Transport via SSH

              Posté par  . Évalué à 3.

              tout ce que fait le mot de passe est de crypter la clef secrète sur le disque

              Non, il chiffre au dessus du FS. Cela veut dire qu'un utilisateur du système (par exemple un navigateur ou un client mail troué) qui a accès au fichier ne pourra lire que la version chiffré.

              « 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: Transport via SSH

                Posté par  . Évalué à 1.

                Oui, c'est vrai. Apparemment j'ai oublié comment était la vie avant l'administration système à distance ;-)

            • [^] # Re: Transport via SSH

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

              J'ai l'impression que je me suis mal exprimé sur Kerberos/GSSAPI ; c'est du SSO qui n'a rien à voir avec HTTP (enfin, autant que le concept de login/mot de passe).
              Quand je me connecte à ma session (Windows/Linux/macOS), que ce soit par carte à puce/Yubikey ou avec un mot de passe, mon ordinateur envoie tout ça au serveur Kerberos de mon employeur qui lui renvoie en échange un ticket valable une journée (on peut également obtenir un ticket n'importe quand avec kinit, après s'être connecté en local sur la session). L'ordinateur ouvre alors la session et garde le ticket pour lui. Ensuite, quand je me connecte à un service quelconque (serveur web, mail, NFS, SSH, imprimante, Jabber, …), mon ordinateur va transmettre le ticket au service qui me reconnaîtra automatiquement, sans que j'ai besoin de rentrer le moindre login ou mot de passe. Bon, en vrai, c'est un chouia plus compliqué, mais ça reste vrai dans les grandes lignes.
              Du coup, il n'y a aucun hack à utiliser une authentification Kerberos sur HTTP ou sur SSH (en cherchant des cookies dans le navigateur).

          • [^] # Re: Transport via SSH

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

            • mais si tu respectes certaines bonnes pratiques, ton réseau d'administration est différent de ton réseau de développement, donc ton port 22 n'est pas accessible aux développeurs. Au contraire, 443 a de fortes chances d'être accessible sur le réseau des utilisateurs.

            • je ne comprends vraiment pas ce que tu veux dire ; en quoi utiliser une clef sans mot de passe est proche de ce que fait HTTPS ? Le fonctionnement de ces deux protocoles est fondamentalement différent :

              • HTTPS permet l'authentification du serveur très facilement, SSH ne permet que de savoir si tu te connectes toujours au même serveur (sauf si tu mets l'empreinte de sa clef publique dans le DNS, mais ça commence à être compliqué à faire, sans garantie que le client la prenne en compte).
              • HTTPS permet les connexions anonymes, pas SSH (qui force l'authentification mutuelle)
            • oui, mais dans ce cas, soit tu acceptes de remplacer du code éprouvé (OpenSSH) par du code très jeune pour l'administration, soit tu as deux services SSH qui tournent sur la même machine (cette option étant de toute façon obligatoire si tu respectes la séparation entre réseau d'administration et réseau de dév.).

            • je ne vois pas pourquoi tu parles de cookies HTTP, et en quoi ils sont un hack. En tout cas, quand tu fais du git+http, tu n'as absolument pas besoin de cookies…

            • [^] # Re: Transport via SSH

              Posté par  . Évalué à 3.

              • le port n'est pas lié au protocole, donc pas vraiment de rapport? Est-on obligé de passer par un service web (si on respecte la convention… ou est-ce un standard?) securise (en supposant que la chaine de confiance n'est pas compromise) pour pousser des modifications sur un dépôt? Pour gérer des tiquets? Pas que je sache (l'immense majorité des forges passe par du www, certes, mais ce n'est pas une obligation, il me semble meme etre tombe sur des bugtrackers utilisables 1: en local et 2: en cli). Personnellement, j'ai plus confiance en ssh pour savoir si je parle au bon serveur qu'en https. Tu dis qu'il faut bidouiller pour savoir si c'est le bon la 1ere fois et c'est vrai, mais ca l'est aussi pour https: il faut un certificat en qui le client ait confiance (ce qui implique donc que le client a installe un fichier, consciemment ou non). Pour ce qui est des forges, parce que c'est la seile raison valide que je voie d'ouvrir un https sur un serveur de dev, si je suis tombe sur des traqueurs qui ne sont pas utilisables qu'en acces web, c'est parce que je ne les trouve pas pratiques du tout. Rien que le fait que les bugs ne puissent pas (dans le cas des bt web-based classiques) etre integres au depot est une vraie limitation, mais c'est un autre sujet (je sais, la solution est fossil). Bref, je ne suis pas sur qu'il soit pertinent de se baser sur le fait que le 443 est ouvert sur un serveur de dev. C'est plus une lie au fait que la mode actuelle soit full-web, amha.
              • pas faux
              • ce n'est pas un remplacement: le protocole utilise est le meme, mais pas le service, pijul ne permettant a priori pas de lancer des commandes shell, nottament. Pour la jeunesse, ma foi, tout code passe par la, non? Et comme tu le dis, les vrais admin (je n'en suis pas un) savent separer les choses proprement.
              • j'ai parle de cookies parce que j'ai dis une anerie :S

              PS desole pour le pate du point 1, je n'arrive pas a formater quand j'utilise les * :/

  • # suggestions

    Posté par  . Évalué à 5.

    Au fait petite suggestion, si jamais vous voulez que votre outils soit adoptes il doit y avoir un moyen de communiquer et d'echanger au minimum avec git (dans les deux sens).
    C'est LA condition sine qua non.

    Git a une tel base que sans cela personne ne voudra l'essayer et donc l'adopter.

    Git le fait avec git-svn (Mercurial le fait avec git je crois).

    Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents. C'est a vous de voir mais sans cela je suis desole de vous dire mais pijul restera un projet academic rigolo et sympa.

    • [^] # Re: suggestions

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

      J'appuie à fond. Dans toutes les entreprises que j'ai fait, la migration SVN --> Git n'a pu se faire que parce qu'il y avait des outils permettant de basculer les projets déjà existants.

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: suggestions

      Posté par  . Évalué à 4.

      Au fait petite suggestion, si jamais vous voulez que votre outils soit adoptes il doit y avoir un moyen de communiquer et d'echanger au minimum avec git (dans les deux sens).

      Oui, bien entendu. D'ailleurs on a déjà commencé à écrire ça.

      Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents.

      Git ne conserve pas toujours suffisamment d'information pour pouvoir importer l'historique correctement, mais on peut très bien imaginer un outil qui marche dans suffisamment de cas.

    • [^] # Re: suggestions

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Le probleme c'est que je ne suis pas sur que cela soit faisable vu que vous utilisez des concepts differents.

      On arrive bien à importer du SVN et même du CVS ou du RCS (le système de gestion de versions standardisé par POSIX) dans git. Par contre, le "dans les deux sens" est moins facile, je pense. Je n'ai heureusement pas eu besoin de ce genre de choses pour l'instant, seulement de migrer des projets existants de SVN ou RCS vers git.

      • [^] # Re: suggestions

        Posté par  . Évalué à 2.

        Les concepts en ce qui concerne les patchs sont, me semble, t'il tres similaire.

        Pijul, d'apres ce que j'ai compris, amene un truc nouveau sur ce point la.

        J'ai fait avec svn dans les deux sens ca fonctionne, par contre c'est LEEEENNNNNTTTTTTTT.

Suivre le flux des commentaires

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