Dans Pijul, deux patchs qui peuvent être produits en parallèle commutent toujours
Je vais modifier un peu ton exemple, parce que ton A et ton B ne sont pas productibles en parallèle dans Pijul (donc Pijul ne garantit pas la commutation dans ce cas).
Par contre, si A modifie un paragraphe, et que B ajoute une ligne au milieu de ce paragraphe, tu as raison, il y a bien un problème. Voici comment Pijul le résout :
Pijul manipule un graphe de lignes. Chaque sommet est une ligne, les arêtes ont un statut. Un patch est un ensemble:
- de nouveaux sommets et arêtes
- et de changements de statut d'arêtes.
(bien sûr, on peut faire des patchs qui ne font que l'un ou que l'autre)
Appliquer un patch, c'est appliquer ces changements au graphe (avec quelques optimisations pour que l'application d'un patch reste en complexité logarithmique en la taille de l'histoire). Note qu'il n'y a pas moyen de supprimer une ligne, on peut juste changer son statut (par exemple, la marquer supprimée).
Quand Alice ajoute une ligne dans un paragraphe, elle marque implicitement le contexte (j'appelle "contexte" la ligne d'avant et la ligne d'après) de cette ligne comme "vivant", alors que Bob le marque mort. Quand on fusionne les deux, on a un graphe valide, mais les lignes autour de la ligne d'Alice ont des arêtes vivantes et des arêtes mortes qui leur pointent dessus. C'est un conflit. On le signale à l'utilisateur (la façon de faire ça a changé énormément dans la nouvelle version, c'est devenu super simple), et on le laisse résoudre.
Remarque au passage que ce problème va se poser à partir du moment où Alice et Bob ont le même ensemble de patchs, même dans un ordre différent. Cependant, comme le contexte des lignes d'Alice est implicitement marqué vivant (et pas explicitement en rajoutant des arêtes), alors que Bob voit de nouvelles lignes avec un contexte qu'il a explicitement supprimé, la façon de le détecter doit être un peu subtile.
Pourquoi ne pas marquer le contexte explicitement ? Parce que pour faire ça, il faudrait rajouter des arêtes sur toutes les lignes qu'Alice considère vivantes, c'est-à-dire sur tout le fichier. Le patch d'Alice aurait alors tous les patchs qui ont touché au fichier comme dépendances, et donc les patchs ne pourraient commuter (on aurait donc juste un Git un peu plus lent, et avec des meilleurs merges).
Il y a une subtilité, qui a changé beaucoup dans la version 0.12, pour récupérer un patch qui parle du graphe à partir des changements de l'utilisateur dans un fichier.
[^] # Re: Difference Pijul vs Git
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 8.
Je me cite dans une réponse antérieure:
Je vais modifier un peu ton exemple, parce que ton A et ton B ne sont pas productibles en parallèle dans Pijul (donc Pijul ne garantit pas la commutation dans ce cas).
Par contre, si A modifie un paragraphe, et que B ajoute une ligne au milieu de ce paragraphe, tu as raison, il y a bien un problème. Voici comment Pijul le résout :
Pijul manipule un graphe de lignes. Chaque sommet est une ligne, les arêtes ont un statut. Un patch est un ensemble:
- de nouveaux sommets et arêtes
- et de changements de statut d'arêtes.
(bien sûr, on peut faire des patchs qui ne font que l'un ou que l'autre)
Appliquer un patch, c'est appliquer ces changements au graphe (avec quelques optimisations pour que l'application d'un patch reste en complexité logarithmique en la taille de l'histoire). Note qu'il n'y a pas moyen de supprimer une ligne, on peut juste changer son statut (par exemple, la marquer supprimée).
Quand Alice ajoute une ligne dans un paragraphe, elle marque implicitement le contexte (j'appelle "contexte" la ligne d'avant et la ligne d'après) de cette ligne comme "vivant", alors que Bob le marque mort. Quand on fusionne les deux, on a un graphe valide, mais les lignes autour de la ligne d'Alice ont des arêtes vivantes et des arêtes mortes qui leur pointent dessus. C'est un conflit. On le signale à l'utilisateur (la façon de faire ça a changé énormément dans la nouvelle version, c'est devenu super simple), et on le laisse résoudre.
Remarque au passage que ce problème va se poser à partir du moment où Alice et Bob ont le même ensemble de patchs, même dans un ordre différent. Cependant, comme le contexte des lignes d'Alice est implicitement marqué vivant (et pas explicitement en rajoutant des arêtes), alors que Bob voit de nouvelles lignes avec un contexte qu'il a explicitement supprimé, la façon de le détecter doit être un peu subtile.
Pourquoi ne pas marquer le contexte explicitement ? Parce que pour faire ça, il faudrait rajouter des arêtes sur toutes les lignes qu'Alice considère vivantes, c'est-à-dire sur tout le fichier. Le patch d'Alice aurait alors tous les patchs qui ont touché au fichier comme dépendances, et donc les patchs ne pourraient commuter (on aurait donc juste un Git un peu plus lent, et avec des meilleurs merges).
Il y a une subtilité, qui a changé beaucoup dans la version 0.12, pour récupérer un patch qui parle du graphe à partir des changements de l'utilisateur dans un fichier.