pmeunier a écrit 108 commentaires

Il y a des tags dans la beta, on peut les utiliser comme des channels en lecture seule. Par contre, la structure de données qui est dessous peut les utiliser pour libérer un peu d'espace disque, mais ne le fait pas encore. Ça ne change rien au format, et l'utilisateur ne voit rien, c'est juste une optimisation rétro-compatible.

Ça me parait assez primordial

Je pense au contraire que c'est un truc pour les très gros dépôts. Même si beaucoup de gens qui veulent tester Pijul le testent sur des dépôts gigantesques, les dépôts gigantesques représentent une infime minorité des dépôts existants.

D'ailleurs, je ne pense pas implémenter ça si (1) je dois le faire tout seul et (2) il n'y a pas de demande industrielle.

Je réagis aussi sur:

Même si pour Pijul ceci introduit une notion de chronologie qui me parait pas tout à fait rendre justice si l'on considère le commutativité.

Il y a plusieurs années, il n'y avait pas de chronologie, ce n'était pas vraiment utilisable, on retrouvait des vieux patchs en tête de log. C'est mieux d'avoir une chronologie souple que pas du tout.

Fossil est un genre de Git/Hg/SVN, dans le sens où il a un DAG de snapshots, et les fusionne avec une heuristique. Il n'y a pas vraiment de structures de données intéressante dedans, ni d'innovation par rapport à Git (d'autant qu'il interdit le rebase, et que rebase est quand même un très bon couteau suisse).

Les intérêts de Fossil, du point de vue technique, sont de tout stocker en SQLite. C'est une performance technique qui à mon avis relève plus du défi sportif que d'autre chose, mais pourquoi pas ? Autre intérêt pour certains utilisateurs, il a un gestionnaire de bugs inclus.

Pour l'instant c'est énormément de boulot, et pas (encore) de financement. J'ai un plan pour le financer, dès que ça roule je pense le rendre open source.

La commande tag est évoquée dans le poste de blog, j'ai expliqué comment ça marche là: https://pijul.org/posts/2022-01-07-compressed-sanakirja/

Je n'ai pas encore expliqué ce que je compte faire avec par contre, mais j'ai l'intention de me servir des tags pour alléger considérablement la taille des dépôts sur le disque, tout en les rendant un poil plus rapide (mais bon, quand on est sur du O(log n), il faut vraiment de grosses réductions de taille pour voir une amélioration en vitesse).

La structure qui est derrière est un CRDT un peu particulier, ce qui explique les chouettes propriétés.

Si les patchs ne sont pas marqués comme dépendants l'un de l'autre (éventuellement avec une chaîne de dépendances entre eux), tu peux vraiment les appliquer dans n'importe quel ordre, et avoir la garantie à 100% d'obtenir le même résultat.

Le cas où Pijul diffère de Darcs est sur les conflits: Darcs définit un conflit en disant que la commutation naïve ne marche pas, alors que Pijul te garantit que tu auras le même conflit indépendamment de l'ordre.

Certes, mais celui qui l'a rapporté montre aussi qu'un truc qui prend quelques minutes sous Linux (et dont la performance est comparable à la même opération avec Git) n'a toujours pas fini après 1h15 sous ce système. Je ne pense pas qu'il aurait réagi si c'était seulement l'expansion.

Bonjour !

Il y a déjà dans Pijul des choses qui permettent de faire un transition, en particulier une commande intégrée dans Pijul pour importer des dépôts de manière incrémentale, et donc de permettre une transition. Quant à faire une couche pour Github/Gitlab, ça paraît compliqué, parce que ces interfaces sont un peu des pansements pour rendre Git semi-utilisable.

Quand tu as essayé le workflow de collaboration, et la gestion de projet, avec des patchs, c'est difficile de revenir en arrière. Regarde par exemple https://nest.pijul.com/pijul/pijul : certes, il n'y a pas encore d'intégration continue, mais les patchs simplifient le travail à un point qu'il est difficile d'imaginer avant d'avoir essayé.

En effet, c'est une super idée. Malheureusement, les structures de données de Pijul sont significativement plus compliquées, pour des raisons de performance.

Je ne doute pas qu'on puisse écrire un proto-Git en Python en quelques heures, tant les structures sont simples et élégantes. Dans notre cas, c'est un peu moins drôle.

Par contre, si on part déjà du backend, qu'on ne gère qu'un seul fichier, qu'on fait abstraction des suppressions de lignes et qu'on ne détecte pas les conflicts, c'est déjà plus facile.

Certes, et le travail en très petit comité est la règle en recherche aussi (en tout cas dans mon domaine). Mais quand tu as un truc qui n'a clairement aucune chance de passer à l'échelle, que tu as à moitié le droit de bosser dessus, ça n'a que peu de chances d'intéresser des gens.

Ceci dit, maintenant que les problèmes de passage à l'échelle sont derrière nous, je passe en temps conséquent à répondre à des mails et à reviewer des patchs ;-) Il y a des jours où c'est plus que mon temps de travail technique, ça fait plaisir.

Est-ce le principe en lui-même où ça n'a rien à voir ?

Il y a plein de raisons:

• d'abord, aucun des auteurs n'a jamais été à plein temps dessus. C'est moi qui en ai écrit le plus gros morceau, et j'avoue que j'ai été peu soutenu par mes employeurs successifs, et carrément méprisé par le dernier en date. Pour faire court, un collègue m'a promis un poste permanent à l'Inria, donc j'ai lâché mes autres opportunités pour y aller, et au moment où l'Inria devait pérenniser l'équipe, il l'a déménagée dans une université de merde en Irlande, pour des raisons totalement absurdes.

• le proto a demandé d'écrire une masse de trucs horribles à débugger, simplement pour parvenir en pratique à la complexité théorique. Un des pires a été un moteur de bases de données avec compteur de références transactionnel, c'est-à-dire que tu peux cloner des bases de données en temps O(log n), et si tu débranches la machine avant de commiter la transaction, tout peut reprendre sans avoir rien à faire quand tu reviens.

• un système asynchrone est exponentiellement plus compliqué à concevoir qu'un système synchrone comme Git, parce qu'il y a une quantité de scénarios incroyable.

• il a végété un bon moment parce qu'il ne passait pas du tout à l'échelle, et que j'ai pensé à l'abandonner pour cette raison. J'ai dû le réécrire de zéro quand j'ai trouvé la solution, parce que tous les algos ont changé.

• l'envie de laisser tomber a été renforcée par le peu de contributeurs, peut-être parce que peu de gens ont envie de s'investir dans des maths, et ceux qui ont envie n'ont pas envie de les implémenter et de débugger.

Meme sur un projet open source que je contrôle pas, si je sais que je vais casser une partie important de l'architecture/code, je vais commencer par une RFC/RequestForComment avant de me lancer dedans

Bien sûr, c'est ce qu'on veut faire.

Effectivement ici j'adapte mon workflow de travail à l'outil (petit commit régulier, intégrer le plus tôt possible par rapport à un gros commit intégré en mode big bang, ceci afin d'éviter les conflits).

Je ne pense pas que ce soit "ici" que tu adaptes ton mode de travail à l'outil, parce que c'est une façon de travailler raisonnable. Par contre, je pense que ce mode de travail n'est justement pas très adapté à Git, parce qu'il t'impose une grande quantité de travail supplémentaire :

• il t'impose de fréquents rebases et merges (parce que tes collaborateurs font pareil), et on sait que Git peut faire vraiment n'importe quoi à ce moment-là, exemples là : https://pijul.org/manual/why_pijul.html. Personnellement, je valorise un peu trop mon temps de travail pour laisser un outil mélanger mes lignes aléatoirement comme ça.

• pour la même raison, si tu as un processus de reviews en place, Git ne te permet pas de prévoir manuellement comment le merge va se passer, même s'il n'y a aucun conflit, parce qu'un 3-way merge n'est pas le bon problème à résoudre : sa solution n'est pas unique et dépend de l'algorithme utilisé.

• tu vas aussi devoir planifier précisément le travail en amont, pour organiser tes branches. Même si c'est possible au début d'un projet, on sait bien que dans un projet compliqué, un bug peut venir de plein d'endroits différents, et révéler complètement autre chose que ce qui était planifié au départ.

• si jamais tu voulais maintenir deux versions d'un projet, la quantité de rebases, merges et rerere nécessaires te découragerait rapidement. J'ai un exemple très concret d'un bibliothèque Rust pour SSH (https://nest.pijul.com/pijul/thrussh), qui a plusieurs versions en parallèle avec presque les mêmes patchs, parce que l'écosystème Rust est en train de migrer entre deux versions d'une bibliothèque fondamentale pour les entrées-sorties asynchrone (Tokio), et qu'il faut pouvoir corriger les bugs sur les deux versions en même temps.

Pijul n'a pas ces contraintes.

Parce ce que dire on sait faire des merge sans conflit parce que quand y en a on fait un choix arbitraire ça me paraît pas ouf

C'est le principe des CRDT, et si tu regardes d'un peu plus près ce n'est pas complètement trivial : l'idée est que les opérations peuvent être associatives et commutatives, pour pouvoir être complètement asynchrones.

Donc les choix sont souvent un peu arbitraires, mais ne sont pas "aléatoires".

L'idée de Pijul est d'ailleurs de généraliser les fichiers pour modéliser les conflits. La structure qui en résulte a le bon goût d'être en CRDT, c'est-à-dire qu'il n'y a pas de choix arbitraire à faire, et les conflits restent modélisés correctement (et non pas "résolus automatiquement", ce qui n'a aucun sens pour un contrôle de versions).

Mais un meilleur merge est-il une killer feature contre git?

Pas du tout, d'abord parce que l'algo de merge est customisable dans Git.

Par contre:

• la commutation de patchs permet de faire des clones partiels, permet d'éviter d'avoir à rebaser (rebase, merge et commit sont la même commande: appliquer un patch), limite la nécessité de créer des branches (puisqu'on peut toujours le faire après si besoin, ou pousser des patchs indépendants).

• la modélisation correcte des conflits a aussi plein d'avantages : dans Pijul, un conflit se passe entre deux (ou plus) patchs, et se résout avec un patch. La conséquence, c'est que tu peux pousser la résolution du conflit vers une branche qui a les deux patchs en conflit, mais pas nécessairement les mêmes autres patchs (par exemple, vers un monorepo). Git essaie de faire ça localement avec rerere, mais ça ne marche pas.

Les linuxiens bornés auxquels je fais allusion (mais je n'ai écrit nulle part que tu en faisais partie, hein !) font en général bien rire les Windowiens qui connaissent un minimum leur système.

C'est ce que j'avais compris (et j'avais noté la précaution de t'en tenir à une insinuation).

Mais pour avoir parlé avec des gens qui connaissent très bien Git et l'utilisent beaucoup, le fait qu'on travaille à une alternative basé sur une théorie propre ne les fait pas rire.

n'importe quoi de non-trivial sous Git est infaisable

C'est encore une extrapolation de ce que j'ai écrit. Elle va moins loin que la précédente (la comparaison avec Windows et Linux), mais elle n'est pas rigoureuse pour autant.

J'ai écrit que dès qu'on bossait avec plusieurs branches ou plusieurs coauteurs, c'était non-trivial. "Non-trivial", ça ne veut pas dire inutilisable ou que je ne le comprends pas (contrairement à l'insinuation "le problème ne vient pas de l'outil"), ça veut juste dire qu'il y a besoin de réfléchir et de faire un truc (par exemple git rebase) pour que ça marche (et d'ailleurs, parfois c'est vraiment dur, même pour des experts).

Ceci dit, si ces extrapolations (qui ne sont pas de moi) sont ce que tu as retenu de mon discours, ton impression que je suis un fanatique en croisade contre Git est justifiée. Sauf que ce n'est pas ce que j'ai écrit…

la plupart de tes interlocuteurs sont très connus ici pour être de bonne foi et aussi des dévelopeurs très expérimentés avec Git.

Je m'en suis rendu compte, et j'ai apprécié la qualité de cette discussion en général. J'ai aussi appris pas mal de trucs sur la façon de documenter Pijul (clairement notre prochain défi !).

J'ai aussi approuvé votre "triturage" de la dépêche avant la publication, donc je ne suis pas sûr que tu puisses être désolé de quoi que ce soit.

Effectivement, je me suis contenté de ma mémoire (apparemment défaillante) pour savoir ce que j'avais dit.
J'aurais du relire, au temps pour moi.

Je rappelle que Linus a codé le coeur de git en 15j

C'est exactement ce que j'ai dit dans mon commentaire précédent.

Alors là je ne comprends pas, je pensais que Pijul était un DVCS comme git, pourquoi tu dis qu'ils ne servent pas vraiment à la même chose??

Git est un système de fichiers distribué adressable par le contenu, alors que Pijul est un outil d'édition de fichiers asynchrone.

Les deux peuvent être utilisés comme DVCS, mais j'utilise :

• Pijul (et encore un peu Darcs) quand je veux travailler avec des gens et qu'on a le choix.
• Git quand je veux faire des sauvegardes horodatées, et avoir des tags automatiques de chaque version.

Quand je travaille sur de très gros projets (NixOS), Pijul n'est pas encore assez efficace, et est encore un peu gourmand en espace disque. Ça devrait s'améliorer rapidement.

Oui, mais je parlais dans mon dernier commentaire d'un cas où git rerere est utile. Pour voir une différence entre Git et Pijul, il faut vraiment que C résolve le conflit en laissant les lignes de A et de B. { A, B, C } (désolé pour les dépendances) donne :

a
b

Si C résout le conflit en supprimant les deux lignes, et que F fait autre chose, tu vas voir un nouveau conflit, quel que soit l'outil que tu utilises. C'est simplement parce que "tadaaa", ce n'est pas la même chose que "tadaa". Un outil qui ne verrait pas de conflit sur ce cas serait foireux.

C'est exactement ça. Tu n'es pas allé assez loin pour avoir besoin d'un rerere.

Pour simplifier un peu, on va dire que C ne fait que garder toutes les lignes de A et B, dans l'ordre où elles sont affichées.

Maintenant, la personne qui a produit B continue à travailler, pour produire par exemple F (on pourrait dire que F change toutes les lignes introduites par B, et ne fait que ça).

Elle a donc un dépôt e_3 = {B, F}. Si maintenant tu pulles son dépôt depuis e_2, tu vas te retrouver dans Pijul avec {A<-C->B, D<-E, F}, et dans Git avec un nouveau conflit sorti de nulle part, qu'un git rerere au moment de produire C aurait résolu.

D'après vous, pourquoi Linus Torvalds n'a pas utilisé ce concept pour git ?

Je ne sais pas, mais il y a plusieurs bonnes raisons :

• SVN et CVS avaient le même genre de concepts de développement "séquentiel", et la plupart des développeurs savaient les utiliser. Git l'a juste rendu plus simple et (presque) distribué.

• Faire un prototype de Git n'est pas très dur, une fois qu'on a les bonnes idées (qui étaient déjà dans l'air, Torvalds a aussi ajouté quelques trucs nouveaux).

• Darcs avait de gros problèmes de performance. Avant Darcs 2 (2008), c'était catastrophique. Avant Pijul (proto en 2015, version qui marche en 2019), on ne savait pas si on pouvait faire un système basé sur des patchs plus efficace qu'exponentiel dans le pire cas.

Torvalds connaît Darcs et Pijul. Il voyait Darcs comme une bêtise purement académique (à cause des performances), mais n'a rien contre Pijul.

Je ne crois pas que lui ou nous pensent que Git et Pijul doivent être concurrents, ils ne servent pas vraiment à la même chose.

Pour info, Erlang n'est pas du tout académique et provient de l'industrie des télécoms.

Bien sûr, je parlais de "curiosité académique" dans le sens "théorie qui ne sert à rien". Et ni OCaml, ni Haskell, ni NixOS, ni Pijul n'ont comme motivation la pureté théorique, bien au contraire.

La version 12 de Pijul devrait arriver bientôt. Elle est pour l'instant un peu compliquée à compiler, il faut bricoler un peu Carnix avant d'y arriver, et trouver une solution pérenne à l'accumulation de vieux crates dans nixpkgs.

En lisant ces messages, j'ai un peu l'impression de lire le discours des Linuxiens qui n'ont pas touché à Windows depuis 20 ans et qui essayent d'argumenter que Windows, c'est de la merde, ça plante tout le temps et il faut reformater le disque et réinstaller toutes les semaines

Pardon, j'avais loupé cette accusation particulièrement grossière. Je ne vois ni le rapport avec le sujet, ni en quoi ça fait avancer la discussion. Je ne sais pas où j'aurais dit un truc pareil.

C'est con, parce que si tu voulais une comparaison entre un truc d'ingénierie "qui-marche-somme-toute-pas-mal" et un truc qui vient d'une théorie propre, il y avait d'autres exemples largement plus à propos :

• Tu pouvais parler par exemple de OCaml, Haskell, Erlang, des curiosités académiques, que les programmeurs Java prenent de haut, parce que "Java/C++ ça marche bien quand même", "c'est toi le problème, si tu définis pas tes classes proprement". Bien sûr, ça n'aurait pas trop alimenté ta hargne, parce qu'aujourd'hui ces langages sont mainstream. Mais on ne peut pas non plus être tout le temps hargneux.

• En moins consensuel (parce que plus récent), tu aurais pu tenter un troll sur NixOS (issu d'une thèse) contre Debian ou RedHat (les standards qui marchent-bien-quand-même). Tu aurais pu dire que ce n'est quand même pas la mort de lire des pages de manuel Debian pendant des heures pour pouvoir faire un brouillon de package pour "GNU Hello", à perfectionner pour éviter qu'il casse à la première mise à jour.

En effet, désolé pour le malentendu.