Produits Entr'ouvert » w.c.s.

Ça ne peut pas fonctionner avec les patches tels qu'ils sont générés/appliqués actuellement par wcs : il n'y a pas de lignes de contexte, ça fonctionne en se basant sur le numéro de ligne.

Or ici ce qu'on veut c'est des patches façon git : les différences sont entourées de ligne de contexte, c'est là dessus qu'on se base pour les appliquer, ça permet pour des historiques qui ont divergé mais qui gardent des bouts en commun, d'appliquer les même patches sur ces bouts.

J'ai fait le tour les libs disponibles et il n'y a que https://github.com/google/diff-match-patch qui fasse le café proprement, c'est packagé dans Debian mais ça n'a plus l'air maintenu depuis 5 ans. OK quand même pour essayer avec ça ? (en ne touchant aucune ligne de l'existant, la tambouille sera bien circonscrite aux tests)

Avant même de savoir comment l'implémenter je me dis qu'on pourrait étayer le fait que ça va faire gagner du temps; t'aurais un cas d'espèce sur une recette avec au moins 3 tests où cette tentative de patch automatique aurait fonctionné et montrer à la main le patch commun ?

D'abord des exemples : si on prend le workflow par défaut, on un tronc commun Juste envoyé -> Nouveau, puis ça se sépare en Accepté/Refusé, donc si on veut tout couvrir par les tests, ça en fait 2. Si derrière Accepté et Refusé il y a à nouveau deux statuts possibles, il en faudra 4, etc. Dans cette histoire les tests auront forcément en commun les actions qui permettent de parcourir le début du chemin avant l'embranchement. Si entre Juste envoyé et Nouveau j'ajoute un statut Vérification, que pour en sortir il faut un saut manuel, tous les tests sont par terre et il faut que j'aille ajouter une action de test « Clic sur un bouton » pour effectuer ce saut.

Même problématique pour les formulaires, si j'ajoute en première page un champ vérification de la commune avec condition de sortie pour que les gens arrêtent de remplir ma démarche alors qu'ils ne sont pas concernés, il faut que j'aille éditer tous les tests pour renseigner une commune valide.

De là à savoir si le patch fonctionne, j'imagine que ça dépend pas mal de l'algo qui essaye d'appliquer le diff, donc je préférais demander si ça se tentait d'ajouter cette dépendance avant d'expérimenter plus avant.

L'absence de maintenance pour un truc purement algorithmique ne me perturbe pas plus que ça et si ça marche et que c'est packagé je ne vois pas de raison de ne pas l'intégrer.

Par contre cette histoire de maintenance m'étonne, le paquet Debian testing date de 2023 le stable de 2020 d'après leurs versions.

J'ai donc testé https://github.com/google/diff-match-patch : le problème c'est que ça applique les patches en mode « fuzzy », à la fois en cherchant ailleurs qu'à la ligne spécifiée dans le patch, mais également en tolérant des variations sur les endroits à modifier. Or je veux juste le premier et pas du tout du deuxième, mais la lib ne permet pas ça (même si ça a l'air de s'approximer en bougeant des paramètres de config).

J'ai aussi testé https://github.com/Shoobx/xmldiff, la manière de produire/appliquer les diffs est très différente, par exemple ça va dire « ajouter la balise <b> après la troisième balise <a> ». Sur cet exemple ça permet donc d'appliquer à l'infini le même diff, qui ajoutera une balise à chaque fois, je n'aime pas trop.

Bref il y a trop à inventer pour ce ticket je trouve, je vais attendre que le boulot autour de l'application des diffs avance côté applification.

(une troisième solution ce serait d'appeler la commande patch, en créant un fichier temporaire sur lequel appliquer le patch, moche mais garantie que le comportement sera le bon)