Une chose (parmi d'autres) que j'ai toujours un peu déplorée dans les outils de diff/patch est la sémantique plutôt pauvre concernant le déplacement de données, qui est vue comme un ajout+suppression plutôt qu'avec un opcode décrivant le déplacement. Certains outils comme Meld sont capables d'afficher (plus ou moins bien) des déplacements en interprêtant l'ajout+suppression comme tel, et l'existence d'outils de diff alternatifs montre que ça devrait être possible (mais n'est intégré au niveau de GNU Diff ou de git).
Autre chose en lien (ou pas) : j'ai eu régulièrement des soucis avec git lors du renommage/déplacements de fichiers ou de dossiers (même en faisant attention à ne pas mélanger ça avec un commit "habituel") : plusieurs fois la détection "automagique" du renommage/déplacement ne marchait pas et je perdais l'historique dudit fichier...
P.S. je ne suis pas un grand codeur donc peut-être que c'est simplement le résultat d'une méconnaissance de l'outil ou d'une mauvaise utilisation, mais en comparaison avec git ce serait cool si pijul pouvait 1°/ être fiable (comme bazaar) pour le suivi du déplacement de fichiers et 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 :), 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 ?
(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 ?)
# Déplacement de données ?
Posté par karteum59 (site web personnel) . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 8. Dernière modification le 24 avril 2019 à 21:12.
Une chose (parmi d'autres) que j'ai toujours un peu déplorée dans les outils de diff/patch est la sémantique plutôt pauvre concernant le déplacement de données, qui est vue comme un ajout+suppression plutôt qu'avec un opcode décrivant le déplacement. Certains outils comme Meld sont capables d'afficher (plus ou moins bien) des déplacements en interprêtant l'ajout+suppression comme tel, et l'existence d'outils de diff alternatifs montre que ça devrait être possible (mais n'est intégré au niveau de GNU Diff ou de git).
Autre chose en lien (ou pas) : j'ai eu régulièrement des soucis avec git lors du renommage/déplacements de fichiers ou de dossiers (même en faisant attention à ne pas mélanger ça avec un commit "habituel") : plusieurs fois la détection "automagique" du renommage/déplacement ne marchait pas et je perdais l'historique dudit fichier...
P.S. je ne suis pas un grand codeur donc peut-être que c'est simplement le résultat d'une méconnaissance de l'outil ou d'une mauvaise utilisation, mais en comparaison avec git ce serait cool si pijul pouvait 1°/ être fiable (comme bazaar) pour le suivi du déplacement de fichiers et 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 :), 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 ?
(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 ?)