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 :
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 kantien . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 10. Dernière modification le 19 septembre 2017 à 22:38.
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 :
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.