Par contre, vous avez conscience que Git est hégémonique aujourd'hui ? Quasiment toutes les forges s'appuient dessus. Un écosystème phénoménal s'est construit autour pour pallier certaines de ses erreurs de jeunesse, ...
C'est vrai, et on en avait totalement conscience au moment de démarrer. Mais:
Au début, comme Florent et moi travaillons en général sur des modèles de calcul asynchrone (plutôt sur de la vraie théorie), le défi nous a motivés.
Ensuite, on a vu à la première démo (même toute ridicule) que c'était un sujet controversé, que l'hégémonie de Git ne faisait pas que des heureux, que des gens souffraient en l'utilisant.
Et on a parlé avec des gens qui n'utiliseront jamais Git, même s'ils ont besoin d'un VCS, parce qu'ils ont besoin d'un outil aussi puissant que Git, mais beaucoup plus facile à utiliser (ce n'est pas pour du code).
L'autre point qui ne manquait jamais d'apparaître dans les trolls de l'âge d'or des VCS, c'était quand même les perfs assez déplorables de Darcs.
C'est ça qui a tué Darcs. Le principal utilisateur était GHC (le compilateur Haskell), avec un dépot énorme, et le merge exponentiel, l'incapacité à gérer des gros fichiers ou des gros patchs ont poussé GHC à changer, même s'ils ont essayé de le soutenir pendant longtemps. À l'époque où Haskell était encore confidentiel, Darcs a été le seul projet open source écrit avec, en dehors du compilateur.
Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
Pas du tout. Notre merge est toujours en temps O(log H), où H est le nombre de lignes écrites depuis le début du dépot, il n'y a pas d'heuristique, il est complètement déterministe, donc il n'y a pas d'optimum local, puisqu'il n'y a rien à minimiser (contrairement à diff3).
Ceci ne remet-il pas en question tout l'édifice ?
Donc non !
Pourrais-tu développer un peu ?
En fait c'est ultra simple. Pijul modélise un fichier comme un graphe de lignes. Faire un patch, c'est ajouter des sommets et des arêtes, ou changer les étiquettes des arêtes. Fusionner deux patchs, c'est faire l'union de tous ces changements, c'est-à-dire l'union de deux ensembles de sommets. C'est aussi simple que ça.
Les trucs difficiles sont :
- Une astuce pour ne pas regarder les lignes qui ont été supprimées, sinon la complexité devient O(H).
- Des algos non-triviaux pour modéliser la résolution de conflits comme ajout de sommets.
- Un algo pour "désappliquer" un patch (la commande pijul unrecord).
Le seul point non-optimal est l'algo de diff, parce que le problème est NP-complet s'il y a un conflit, et on utilise un algo d'approximation.
Etant donné les différences d'approche, j'ai conscience que ça limiterait l'expression du potentiel de Pijul (pas de bijection: 2 commits git de même contenu ne matchant pas un même patch) mais penses-tu de la faisabilité ?
C'est totalement faisable, et sans doute pas très dur. C'est clairement la prochaine étapie, mais ce n'est pas encore écrit. J'ai connaissance de plusieurs tentatives, et j'étais jusqu'à maintenant assez occupé sur le reste (montrer que Pijul pouvait marcher, par exemple !).
[^] # Re: Soit j'ai rien compris soit...
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 5.
C'est vrai, et on en avait totalement conscience au moment de démarrer. Mais:
C'est ça qui a tué Darcs. Le principal utilisateur était GHC (le compilateur Haskell), avec un dépot énorme, et le merge exponentiel, l'incapacité à gérer des gros fichiers ou des gros patchs ont poussé GHC à changer, même s'ils ont essayé de le soutenir pendant longtemps. À l'époque où Haskell était encore confidentiel, Darcs a été le seul projet open source écrit avec, en dehors du compilateur.
Pas du tout. Notre merge est toujours en temps O(log H), où H est le nombre de lignes écrites depuis le début du dépot, il n'y a pas d'heuristique, il est complètement déterministe, donc il n'y a pas d'optimum local, puisqu'il n'y a rien à minimiser (contrairement à diff3).
Donc non !
En fait c'est ultra simple. Pijul modélise un fichier comme un graphe de lignes. Faire un patch, c'est ajouter des sommets et des arêtes, ou changer les étiquettes des arêtes. Fusionner deux patchs, c'est faire l'union de tous ces changements, c'est-à-dire l'union de deux ensembles de sommets. C'est aussi simple que ça.
Les trucs difficiles sont :
- Une astuce pour ne pas regarder les lignes qui ont été supprimées, sinon la complexité devient O(H).
- Des algos non-triviaux pour modéliser la résolution de conflits comme ajout de sommets.
- Un algo pour "désappliquer" un patch (la commande
pijul unrecord).Le seul point non-optimal est l'algo de diff, parce que le problème est NP-complet s'il y a un conflit, et on utilise un algo d'approximation.
C'est totalement faisable, et sans doute pas très dur. C'est clairement la prochaine étapie, mais ce n'est pas encore écrit. J'ai connaissance de plusieurs tentatives, et j'étais jusqu'à maintenant assez occupé sur le reste (montrer que Pijul pouvait marcher, par exemple !).