En 2017, je vous présentai Pijul, ici même Pijul, un nouveau gestionnaire de source, un DVCS basé sur la même théorie des patchs que darcs, mais avec pour objectif d'en résoudre les problèmes de performance. Il est développé en Rust et publié sous licence GPL v2.
Depuis le sujet a été évoqué deux fois de plus : Tous les contenus étiquetés avec « pijul »
Après plusieurs années de développement et des ré-écritures, la version 1.0 approche.
Une annonce a été faite sur le blog du projet début novembre : Towards 1.0
Aujourd'hui via r/rust je découvre deux articles qui reprennent la genèse et les évolutions récentes du projet :
- Pijul - The Mathematically Sound Version Control System Written in Rust
- Q&A with the Creator of the Pijul Version Control System
Ça reste une version alpha, avec énormément de détails à régler, mais la théorie et les objectifs restent prometteurs.
Bravo à Pierre‐Étienne Meunier et Florent Becker de s'être lancés dans ce projet de proposer de la concurrence parmi les DVCS et d'avoir maintenu l'effort sur des années !
# Retour aux sources
Posté par Dr BG . Évalué à 8.
Ah tiens, ils ont finalement renoncé à le renommer en anu ? Tant mieux !
[^] # Re: Retour aux sources
Posté par cosmocat . Évalué à 2.
Ce anu est bloqué par mon proxy d'entreprise ;)
mais pas https://pijul.org/ donc je suppose que c'est un bon point pour le nom actuel…
[^] # Re: Retour aux sources
Posté par freem . Évalué à 3.
Par contre ils se sont trompé de terme, je pense, parce que pour moi, c'est pas des pijul qu'on entre par l'anu.
[^] # Re: Retour aux sources
Posté par Guillawme (site web personnel, Mastodon) . Évalué à 5.
Suppositware ? (ce nom d’organisation est disponible sur GitHub, dépêche-toi).
# Coïncidence
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8.
C'est amusant, il y a deux jours, en discutant à propos de fusion de branches, je me suis souvenu de Pijul, que j'avais découvert à l'occasion du précédent journal à ce sujet. Je m'étais régalé en lisant une vulgarisation de la théorie utilisée par ce gestionnaire de version !
[^] # Re: Coïncidence
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Dans le même genre de papier, il y a https://github.com/automerge/automerge , qui serait le seul moyen de merge sans élement central.
cf https://www.youtube.com/watch?v=GXJ0D2tfZCM comme introduction.
"La première sécurité est la liberté"
[^] # Re: Coïncidence
Posté par Tangi Colin . Évalué à 3.
Automerge m'avait l'air merveilleux jusqu'à lire le paragraphe suivant : https://github.com/automerge/automerge#conflicting-changes
Par rapport à un 'gît merge-s ours' ça change quoi ? 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, en tout cas pour un gestionnaire de version je préfère avoir un œil humain à ce moment là.
[^] # Re: Coïncidence
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Comment veux tu faire autrement ? Il s'agit de 2 changements contradictoires sémantiquement, il n'y a pas d'autre choix.
En pure merge, XML et Json ne sont pas connu pour fonctionner correctement, le présupposé de Git étant une "instruction par ligne". Il faudrait voir ce que donne un diff spécialisé json pour Git utilisant automerge pour vérifier l'utilité de l'algo.
"La première sécurité est la liberté"
[^] # Re: Coïncidence
Posté par pmeunier . Évalué à 4.
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).
# Super
Posté par barmic 🦦 . Évalué à 5.
Excellent ! J'espère qu'il trouvera à place !
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Sympa
Posté par mothsART . Évalué à 4. Dernière modification le 01 décembre 2020 à 14:00.
Le concept (Darcs) et l'implémentation sont vraiment intéressants! En espérant qu'il trouve ça place dans le milieu des DVCS écrasé par le (trop) populaire git.
[^] # Re: Sympa
Posté par reno . Évalué à 5.
Je ne suis pas très optimiste: il y a plein de choses qui pourraient être amélioré dans un DVCS par rapport à git: la gestion des sous-modules, la gestion de l'historique (je considère que "squasher des commit" est une hérésie, on devrait pouvoir "compresser" l'historique mais de manière réversible pas de manière irréversible), la cohérence des commandes, la scalabilité, la gestion des gros fichiers binaires, un système de ticket/doc intégré..
Mais un meilleur merge est-il une killer feature contre git?
Personnellement je n'en suis pas sûr, car c'est rarement un problème pour moi, mais je souhaite quand même du succès à Pijul,
[^] # Re: Sympa
Posté par pmeunier . Évalué à 9.
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.
[^] # Re: Sympa
Posté par reno . Évalué à 3.
Effectivement ça semble intéressant les clone partiels d'un point de vue scalabilité.
[^] # Re: Sympa
Posté par Tangi Colin . Évalué à 1.
Merci pour ces réponses, ça à l'air effectivement intéressant.
Il est vrai que git rerere ne marche pas toujours comme on le veut mais personnellement il assez rare que j'en ressente le besoin même dans un projet multi-personne. Si il y a deux évolutions majeures et assez longues à développer en parallèle qui vont toucher une même partie du code, on va réfléchir et s'organiser pour découper ça en plusieurs sous taches avec des dépendances entre elles et intégrer au plus tôt.
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 et je vais devoir réfléchir encore plus à découper mon travail en plusieurs changement indépendant intégrable au fil de l'eau.
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).
Mais ce mode de fonctionnement actuelle me convient bien et convient bien aux équipes avec lequel j'ai travaillé.
J'ai vraiment du mal à m'imaginer si je changerai ma manière de travail avec darcs/pijul ou pas.
En soit si y deux branches qui divergence trop longtemps, le risque est grand de tomber dans un cas où il n'a pas de résolution automatique possible sans un choix fonctionnel et donc une décision humaine et donc je continuerai très certainement à utiliser mon fonctionnement actuel (petit commit, rebase régulier).
[^] # Re: Sympa
Posté par cosmocat . Évalué à 3.
Je serais tenté de dire oui…
Git a changé ma manière de travaillé grâce à la souplesse qu'il permet. Donc si un outil te permet plus de souplesse, tu peux faire plus de choses avec…
En plus tu décris bien le fait que tu te sois adapté aux limites de l'outil. Donc si la limite n'existe plus, forcement tu vas pouvoir faire les choses différemment, pas forcement tout le temps, et tu passeras moins de temps à faire certaines taches…
[^] # Re: Sympa
Posté par pmeunier . Évalué à 5.
Bien sûr, c'est ce qu'on veut faire.
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.
[^] # Re: Sympa
Posté par cosmocat . Évalué à 3.
Effectivement, j'aimerais pouvoir avoir cela. Une sorte de "squash" commit qui garde une reference sur l'ensemble des commits squashed et qu'on puisse les voir si besoin (mais pas par défaut). Et que l'on puisse choisir si le bisect passe par là ou pas…
[^] # Re: Sympa
Posté par Tangi Colin . Évalué à 2.
Tu as déjà quasiment cette fonctionnalité la sous gerrit. Un change-id fixe dans le message de commit. Avec ça tu peut facilement retrouver la 'branche de merge' qui est dans un namespace/ref git (afin de pas poluer le ref/heads courant)
Ça ce met assez facilement en place manuellement avec un script (information fixe dans le message de commit et sauvegarde de la branche dans un namespace dédié). Perso je mets ça en place dans tous les projets où j'ai un rôle d'intégrateur, gerrit ou pas.
[^] # Re: Sympa
Posté par reno . Évalué à 2.
Je ne suis pas un pro de gerrit mais pour moi au contraire gerrit est la source de la perte d'historique: je me fais mes petits commit local donc tout va bien pour git mais pour pouvoir les pousser sur gerrit je suis obligé de les squasher en un seul commit..
# Implémentation
Posté par wilk . Évalué à 3.
D'où vient le fait que l'implémentation à l'air si longue ?
Je me souviens qu'à l'époque ou Git est né, mercurial, arch, tla, bazaar… il ne semblait pas si difficile d'implémenter de nouvelles idées de dvcs.
Est-ce le principe en lui-même où ça n'a rien à voir ?
Je ne pense quand même pas non plus que ça vienne de Rust ?
[^] # Re: Implémentation
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 4.
Un début d'explication est donné à la fin de l'annonce à propos de la future version 1.0: un des auteurs avait eu un nouveau poste de recherche académique qui l'empêchait de mener tout projet de recherche en dehors du travail (ou en tout cas qui poserait des questions juridiques).
[^] # Re: Implémentation
Posté par pmeunier . Évalué à 5.
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.
[^] # Re: Implémentation
Posté par GuieA_7 (site web personnel) . Évalué à 2.
Si ça peut te rassurer (bon, pas sûr) c'est le cas d'une grande partie des logiciels libres d'être portés par une équipe (parfois d'une seule personne) sans grosse contribution externe (même s'ils ont des utilisateurs). Les logiciels comme Linux, pour qui gérer les contributions externes est complexe tellement elles sont nombreuses, sont l'exception et pas la règle.
Bon courage !!
[^] # Re: Implémentation
Posté par pmeunier . Évalué à 2.
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.
[^] # Re: Implémentation
Posté par wilk . Évalué à 4. Dernière modification le 06 décembre 2020 à 20:05.
Merci pour ces explications.
Un truc qui m'a aidé à comprendre et utiliser Git (j'utilisais plutôt Mercurial) c'est un tuto où on écrit un proto en Python :
https://www.leshenko.net/p/ugit/
J'adorerai voir la même chose avec Pijul !
[^] # Re: Implémentation
Posté par pmeunier . Évalué à 1.
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.
# frontal qui ressemble à git ?
Posté par EraZerg . Évalué à 2.
Bonjour,
100% convaincu par pijul qui me semble être "ce-que-devrait-être-git++'… Je me pose toutefois une question: Serait-il judicieux d'avoir un frontal compatible avec git ? pour aider à la transition (et j'ai bien saisi que certaines opérations git seraient des no-op pour pijul, vu qu'il est mieux conçu… mais bon, faut bien commencer qqpart). Ce qui est inquiétant aujourd'hui c'est que git est aussi une sous-couche pour gitlab/github… et qu'avoir un meilleur 'git' sans avoir les couches du dessus risque d'être difficile à avaler… Alors effectivement avec CVS on avait le même problème et pourtant git est là.
voilà donc ma remarque.
[^] # Re: frontal qui ressemble à git ?
Posté par pmeunier . Évalué à 3.
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é.
[^] # Re: frontal qui ressemble à git ?
Posté par EraZerg . Évalué à 1.
re bonjour,
pijul a le potentiel d'être git v2.0. je pense par contre qu'il n'est pas judicieux de travailler sur un compétiteur à gitlab ( + de 1000 personnes pour développer gitlab ): à courir après trois lapins, on en attrape aucun.
Git est un cauchemard (mais indispensable) pour tous ceux qui ont des développeurs de tous niveaux / ancienneté, à tel point qu'on a des merge master dans les entreprises… Au contraire, pour Pijul, avec cette logique centrée sur les patchs et l'associativité… je suis certain que l'adoption et la courbe de progression des développeurs, notamment débutants, serait bien plus pentue.
mais, pour l'instant, le problème principal c'est la masse critique largement atteinte et dépassée par git qui est un standard de fait et une sous-couche de sur-couches indispensables … comme gitlab. C'est pour ça que je pensais que faire un cli "git-pijul" qui serait syntaxiquement identique pour les opérations les plus courantes serait peut-être un bon cheval de troie pour conquérir l'univers (des SCM en tout cas). En plus évidemment d'un convertisseur de repository.
de la même manière que podman qui essaye d'être docker compatible… je n'ai pas assez creusé pijul pour comprendre à quel point il serait possible/impossible de faire que pijul init, pijul checkout, pijul checkout -b … pijul rebase… semble marcher comme git mais ce serait vraiment cool que, comme podman, on puisse faire "alias git=pijul"… et commencer à bosser sans plus se soucier qu'un merge à trois voies se pointe et nécessite du staff spécialisé…
voilà pour mon rêve éveillé donc :-) Et un grand bravo encore pour ce projet que je suis depuis des années et qui se rappelle à mon bon souvenir à chaque fois que je vois des gens littéralement débugger leur branches.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.