1°/ être fiable (comme bazaar) pour le suivi du déplacement de fichiers
Il n'y a rien de magique ou d'heuristique dans Pijul, tout est basé sur des maths, et est déterministe (il peut y avoir des bugs, quand même).
Donc Pijul est même plus fiable là-dessus que Bazaar, parce qu'il gère proprement les conflits de déplacements fichiers.
2°/ avoir un format de patchs qui garde l'information concernant les blocs déplacés au sein d'un même fichier (ou entre fichiers, si c'était envisageable. Bref j'aimerais qu'un C-X C-V au sein du fichier ou entre différents fichiers soit encodé comme "tel bloc de données à été déplacé de X vers Y" et non comme un ajout+suppression...), mais j'ignore si c'est compatible avec ta théorie des patch et avec le format de données que tu envisages :),
J'aimerais bien avoir ça aussi, mais malheureusement, ça change pas mal la théorie : qu'est-ce qu'on est censé faire si Alice déplace un bloc vers le fichier A, pendant que Bob déplace le même bloc vers le fichier B en parallèle ?
On peut certainement ruser un peu dans pas mal de cas, mais l'idée de Pijul est de faire une théorie mathématique, c'est-à-dire une solution générale qui gère 100% des cas.
(par exemple aussi le cas où Charlie édite le même bloc sans le déplacer, en parallèle d'Alice et Bob).
3°/ cerise sur le gâteau : j'aime plutôt bien fossil pour sa simplicité et le fait que le repo entier est dans un unique fichier qui est une base sqlite : est-ce envisageable dans ton cas ?
Je ne trouve pas Fossil simple, je le trouve simpliste (je préfère Git et Mercurial). J'ai du mal à voir pourquoi SQLite est un bon choix pour faire ça, j'ai plutôt l'impression que c'est Fossil qui est un bon choix pour illustrer SQLite.
Notre backend est aussi une base de données (Sanakirja, dont j'ai aussi écrit un bon morceau), mais largement plus rapide que celle de SQLite, et avec une feature cruciale pour implémenter des branches sur une base de données sans faire aucune copie.
Et faire tenir tout dans un seul fichier est un peu contraire à l'idée de pouvoir échanger plein de petits patchs indépendants. Mais si tu n'as pas l'intention de pousser ou d'unrecorder des patchs, tu peux toujours garder juste le fichier .pijul/pristine/db et effacer tout le reste, ton dépôt marchera sans doute encore.
(en fait pour aller plus loin : imaginons qu'on conçoive un outil de diff/patch intégrant l'opcode "déplacement de bloc" mais par exemple aussi "indentation de bloc", "renommage d'une variable/refactoring", "suppression des espaces blancs" et d'autres choses => cela change t-il quelque chose à ta théorie des patchs ?)
Darcs fait une partie de ces choses. L'indentation ou les espaces, ce serait plutôt facile à ajouter dans Pijul, pour le reste j'ai un peu réfléchi à la question, et ça n'a pas l'air complètement évident : encore une fois, que doit-on faire si Alice et Bob décident en parallèle de renommer la même variable avec deux noms différents ?
[^] # Re: Déplacement de données ?
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 7.
Il n'y a rien de magique ou d'heuristique dans Pijul, tout est basé sur des maths, et est déterministe (il peut y avoir des bugs, quand même).
Donc Pijul est même plus fiable là-dessus que Bazaar, parce qu'il gère proprement les conflits de déplacements fichiers.
J'aimerais bien avoir ça aussi, mais malheureusement, ça change pas mal la théorie : qu'est-ce qu'on est censé faire si Alice déplace un bloc vers le fichier A, pendant que Bob déplace le même bloc vers le fichier B en parallèle ?
On peut certainement ruser un peu dans pas mal de cas, mais l'idée de Pijul est de faire une théorie mathématique, c'est-à-dire une solution générale qui gère 100% des cas.
(par exemple aussi le cas où Charlie édite le même bloc sans le déplacer, en parallèle d'Alice et Bob).
Je ne trouve pas Fossil simple, je le trouve simpliste (je préfère Git et Mercurial). J'ai du mal à voir pourquoi SQLite est un bon choix pour faire ça, j'ai plutôt l'impression que c'est Fossil qui est un bon choix pour illustrer SQLite.
Notre backend est aussi une base de données (Sanakirja, dont j'ai aussi écrit un bon morceau), mais largement plus rapide que celle de SQLite, et avec une feature cruciale pour implémenter des branches sur une base de données sans faire aucune copie.
Et faire tenir tout dans un seul fichier est un peu contraire à l'idée de pouvoir échanger plein de petits patchs indépendants. Mais si tu n'as pas l'intention de pousser ou d'unrecorder des patchs, tu peux toujours garder juste le fichier
.pijul/pristine/dbet effacer tout le reste, ton dépôt marchera sans doute encore.Darcs fait une partie de ces choses. L'indentation ou les espaces, ce serait plutôt facile à ajouter dans Pijul, pour le reste j'ai un peu réfléchi à la question, et ça n'a pas l'air complètement évident : encore une fois, que doit-on faire si Alice et Bob décident en parallèle de renommer la même variable avec deux noms différents ?