J’essaie de comprendre pourquoi le fichier svn.revision généré quand un paquet (spip ou plugin apparement) est fabriqué est si compliqué. C’est du xml qui double les propriétés récupérée d’un svn info si je comprends bien, dans une balise <svn_revision><text_version / > et dans des propriétés <svn_revision>valeur …
Hors, mais je peux encore une fois, avoir raté un truc, il n’y a que dans spip (ecrire/inc/filtre.php:version_svn_courante()) que la chaine ‘Revision: *’ est exploitée.
à quoi sert ce formalisme ? J’ai l’impression qu’un svn info > svn.revision suffirait amplement.
Revision, c’est le numéro du dernier commit du dépôt.
Or que ce soit pour un plugin ou pour spip, il serait plus intéressant de récupérer le numéro du dernier commit de la branche qui a servi à faire le paquet : “Last Changed Rev: *”
Dans l’interface d’installation, si on choisi le tag de la 3.1.1, l’inteface affiche un lien vers la révision 22980 (là maintenant, mais ça va évoluer) de l’interface web. Or ce commit n’a rien a voir, c’est une mise à jour de lang dans la version de dev. Le dernier commit de la 3.1.1, c’est 22913.
J'essaie de comprendre pourquoi le fichier svn.revision généré quand un
paquet (spip ou plugin apparement) est fabriqué est si compliqué. C'est du
xml qui double les propriétés récupérée d'un `svn info` si je comprends
bien, dans une balise <svn_revision><text_version / > et dans des
propriétés <svn_revision><prop>valeur</prop> ...
Hors, mais je peux encore une fois, avoir raté un truc, il n'y a que dans
spip (ecrire/inc/filtre.php:version_svn_courante()) que la chaine
'Revision: *' est exploitée.
à quoi sert ce formalisme ? J'ai l'impression qu'un `svn info >
svn.revision` suffirait amplement.
Ces fichiers sont générés par la fonction suivante :
Le commentaire indique qu'ils permettent à SPIP d'afficher le numéro de version du paquet dans l'interface privée à l'aide de la fonction que tu pointais, version_svn_courante().
Ensuite, le log de commit suivant ne me permet pas de te dire pourquoi on utilise du xml... ^^
Le patch qui accompagne ma réponse permet de faire les 2, chercher Last Changed Rev: ou Revision:, dans cet ordre.
Ainsi, un paquet produit “à l’ancienne” renverra la réponse attendue et un paquet produit avec un svn info > svn.revision aussi. Ceci permettra, soit de simplifier smart_paquets, soit d’essayer le script que j’ai proposé sur la zone aujourd’hui.
Si quelqu’un trouve à redire, on oublie. Sinon, je commit
Je ne sais pas/plus pourquoi on fait ça. Peut-être parce que attention, quand on a une console en FR, le fichier brut qui sort du svn info est libellé en français, et peut-être aussi pour maintenir un formalisme figé, même avec les évolutions de SVN qui changent le format/contenu au fur et à mesure des nouvelles versions ?
En effet, bien qu’ayant vu les expressions régulières que tu signales et ayant effectué tous mes tests sur une machine avec LANG=fr_FR.UTF-8, j’ai constaté que mon client subversion ne changeait pas de langue (résultats en anglais). Ayant aussi testé sur des machines debian (svn 1.8) ou fedora (svn 1.9) avec docker, je n’ai pas constaté non plus ce genre de problème. Mais avec une version 1.6 sur une “vraie” debian installée en français, en effet, ça se produit. Le plus simple ne serait-il pas de produire un fichier svn.revision en anglais systématiquement ?
D’autres part, la commande svn info n’a pas changé de format depuis pas mal de temps et la version 1.10 ne le changera pas non plus à ce que j’ai pu lire ici et là. Et SPIP est quand même vachement… ok, disons relativement, plus réactif que subversion pour sortir des versions !
Je reviens à la question que je pose depuis le début : Pourquoi du xml alors que nulle part dans SPIP ou dans les plugins de la zone il n’y a manipulation xml, pas de xml_parse() en gros, quand le fichier svn.revision est traité ? Je n’y trouve que des expressions régulières du type “^truc: (.*)”
