il y a quand même une commande git rerere, ça ne s'invente pas !
1 point pour toi. Je commence à me laisser séduire.
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, ...
Darcs a eu ses chances et est passé aux oubliettes.
Qu'est-ce qui ferait qu'aujourd'hui Pijul réussirait mieux et ne répéterait pas les mêmes erreurs que son aïeul malgré ses atouts ?
J'ai bien ma petite idée mais les tiennes m'intéressent.
De mon coté, je vois déjà le fait que l'implémentation était basée sur un langage assez abrupt et confidentiel. Rust est plus populaire, il me semble.
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.
Le modèle de données a évolué et les algos aussi de ce que je comprends.
Mais il reste ce point évoqué dans votre FAQ: le "exponential merge problem". Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
Ceci ne remet-il pas en question tout l'édifice ?
Pourrais-tu développer un peu ?
Question subsidiaire: Un point important pour son adhesion est l'interopérabilité.
J'ai cru voir qu'il y avait des scripts d'import depuis Git mais je crois que ce qui rassurerait les early adopters serait plutôt un genre de pont qui permettrait de se synchroniser avec un repo git tout en jouant avec Pijul en local (un peu comme git-svn).
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é ?
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
1 point pour toi. Je commence à me laisser séduire.
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, ...
Darcs a eu ses chances et est passé aux oubliettes.
Qu'est-ce qui ferait qu'aujourd'hui Pijul réussirait mieux et ne répéterait pas les mêmes erreurs que son aïeul malgré ses atouts ?
J'ai bien ma petite idée mais les tiennes m'intéressent.
De mon coté, je vois déjà le fait que l'implémentation était basée sur un langage assez abrupt et confidentiel. Rust est plus populaire, il me semble.
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.
Le modèle de données a évolué et les algos aussi de ce que je comprends.
Mais il reste ce point évoqué dans votre FAQ: le "exponential merge problem". Vous vous appuyez sur une heuristique d'après ce que j'ai cru comprendre, au risque de tomber dans un optimum local.
Ceci ne remet-il pas en question tout l'édifice ?
Pourrais-tu développer un peu ?
Question subsidiaire: Un point important pour son adhesion est l'interopérabilité.
J'ai cru voir qu'il y avait des scripts d'import depuis Git mais je crois que ce qui rassurerait les early adopters serait plutôt un genre de pont qui permettrait de se synchroniser avec un repo git tout en jouant avec Pijul en local (un peu comme git-svn).
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é ?