[SPIP Zone] r17662 - /_plugins_/_test_/login_logout/inc/plugin_globales_lib.php

* paladin@quesaco.org tapuscrivait, le 24/12/2007 06:03:

Author: paladin@quesaco.org
Date: Mon Dec 24 06:03:37 2007
New Revision: 17662

Log:
proteger le nom de la fonction de svn commit

Est-ce que tu pourrais expliquer comment et pourquoi ça marche ?
Actuellement, SPIP utilise une lecture de .svn/entries pour déterminer le numéro de version affiché en bas du site.
Et la génération des ZIP met quant à elle un svn.revision à la racine du site.
D'après ce que je comprends, tu as mis en place un mécanisme qui permet de faire mettre par Subversion le n° de révision dans le code source.

Comment ce n° est récupéré quand on fait svn up ?
Comment cette variable n'est pas écrasée dans le code source quand on fait svn co ?

--
RealET

RealET a écrit :

* paladin@quesaco.org tapuscrivait, le 24/12/2007 06:03:

Author: paladin@quesaco.org
Date: Mon Dec 24 06:03:37 2007
New Revision: 17662

Log:
proteger le nom de la fonction de svn commit

Est-ce que tu pourrais expliquer comment et pourquoi ça marche ?
Actuellement, SPIP utilise une lecture de .svn/entries pour déterminer le numéro de version affiché en bas du site.
Et la génération des ZIP met quant à elle un svn.revision à la racine du site.
D'après ce que je comprends, tu as mis en place un mécanisme qui permet de faire mettre par Subversion le n° de révision dans le code source.

Comment ce n° est récupéré quand on fait svn up ?
Comment cette variable n'est pas écrasée dans le code source quand on fait svn co ?

Ah, et aussi, juste une remarque, mais ça n'a pas l'air de faire planter (encore) le rss, mais on a un fichier qui définit la validité du XML des plugins (les différentes balises possibles):
- là Connexion · GitLab
- et là : Connexion · GitLab

Tu ajoutes une balise non prévue :
> + <LastChangedRevision>$LastChangedRevision$</LastChangedRevision>

ça n'a pas l'air de géner, mais je tiens à le signaler pour avoir une trace.

MM.

-----Message d'origine-----
De : spip-zone-bounces@rezo.net
[mailto:spip-zone-bounces@rezo.net] De la part de RealET
Envoyé : lundi 24 décembre 2007 09:47
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] r17662
-/_plugins_/_test_/login_logout/inc/plugin_globales_lib.php

* paladin@quesaco.org tapuscrivait, le
24/12/2007 06:03:
> Author: paladin@quesaco.org
> Date: Mon Dec 24 06:03:37 2007
> New Revision: 17662
>
> Log:
> proteger le nom de la fonction de svn commit
Est-ce que tu pourrais expliquer comment et pourquoi ça marche ?
Actuellement, SPIP utilise une lecture de .svn/entries pour
déterminer le numéro de version affiché en bas du site.

Dans le cas d'une svn, mais ca nécessite de faire un 'Update' à la place
d'un 'Export' avec tout un tas de fichiers/dossiers .svn inutiles dans bien
des cas. D'où ma recherche en me basant plus sur un 'Export' et des
mots-clés existants (propriétés) à insérer dans les scripts, c'est à dire
sans les fichiers ressources de .svn.

La solution proposée, qui n'est peut-être pas la meilleure, consiste dans un
premier temps à insérer l'attribut svn dans un tag de plugin.xml. Mais c'est
incomplet, car ça ne tient pas compte des autres fichiers (vu le système
atomique de svn qui permet d'avoir le numéro de révision par fichier, et non
globalement pour le pack).

La recherche est étendue dans mon dernier commit. En gros, la fonction va
chercher dans tous les fichiers ellisibles du plugin (où il peut trouver le
mot-clé 'LastChangedRevision' et en extraire la valeur max).
Du coup, le tag xml de plugin.xml est devenu presque inutile.

Il y a peut-être plus simple ?

Et la génération des ZIP met quant à elle un svn.revision à
la racine du site.
D'après ce que je comprends, tu as mis en place un mécanisme
qui permet de faire mettre par Subversion le n° de révision
dans le code source.

Comment ce n° est récupéré quand on fait svn up ?

Il est donné par le serveur SVN.

Comment cette variable n'est pas écrasée dans le code source
quand on fait svn co ?

C'est juste un mot-clé. Tu mets $LastChangedRevision:$ dans ton script, si
besoin tu appliques les propriétés du fichier (clic droit, propriétés,
subversion sous windows, ou ajout des propriétés sous console) et tu
envoies. SVN se charge du reste et met à jour le numéro tout seul. Donc la
variable est forcément écrasée.

Mais je n'ai peut-être pas bien compris la question ?

* Christian PAULUS tapuscrivait, le 24/12/2007 12:00:

-----Message d'origine-----
De : spip-zone-bounces@rezo.net [mailto:spip-zone-bounces@rezo.net] De la part de RealET
Envoyé : lundi 24 décembre 2007 09:47
À : spip-zone@rezo.net
Objet : Re: [SPIP Zone] r17662 -/_plugins_/_test_/login_logout/inc/plugin_globales_lib.php

* paladin@quesaco.org tapuscrivait, le
24/12/2007 06:03:

Author: paladin@quesaco.org
Date: Mon Dec 24 06:03:37 2007
New Revision: 17662

Log:
proteger le nom de la fonction de svn commit

Est-ce que tu pourrais expliquer comment et pourquoi ça marche ?
Actuellement, SPIP utilise une lecture de .svn/entries pour déterminer le numéro de version affiché en bas du site.

Dans le cas d'une svn, mais ca nécessite de faire un 'Update' à la place
d'un 'Export' avec tout un tas de fichiers/dossiers .svn inutiles dans bien
des cas. D'où ma recherche en me basant plus sur un 'Export' et des
mots-clés existants (propriétés) à insérer dans les scripts, c'est à dire
sans les fichiers ressources de .svn.

La solution proposée, qui n'est peut-être pas la meilleure, consiste dans un
premier temps à insérer l'attribut svn dans un tag de plugin.xml. Mais c'est
incomplet, car ça ne tient pas compte des autres fichiers (vu le système
atomique de svn qui permet d'avoir le numéro de révision par fichier, et non
globalement pour le pack).

La recherche est étendue dans mon dernier commit. En gros, la fonction va
chercher dans tous les fichiers ellisibles du plugin (où il peut trouver le
mot-clé 'LastChangedRevision' et en extraire la valeur max). Du coup, le tag xml de plugin.xml est devenu presque inutile.

Il y a peut-être plus simple ?

Alors, la solution de SPIP est plus simple : il n'y a que /.svn/entries qui est regardé : un seul fichier.

Et la génération des ZIP met quant à elle un svn.revision à la racine du site.
D'après ce que je comprends, tu as mis en place un mécanisme qui permet de faire mettre par Subversion le n° de révision dans le code source.

Comment ce n° est récupéré quand on fait svn up ?

Il est donné par le serveur SVN.

Comment cette variable n'est pas écrasée dans le code source quand on fait svn co ?

C'est juste un mot-clé. Tu mets $LastChangedRevision:$ dans ton script, si
besoin tu appliques les propriétés du fichier (clic droit, propriétés,
subversion sous windows, ou ajout des propriétés sous console) et tu
envoies. SVN se charge du reste et met à jour le numéro tout seul. Donc la
variable est forcément écrasée.

Mais je n'ai peut-être pas bien compris la question ?

La question, c'est : si dans le code source je met $LastChangedRevision:$ et que je commite. Puis que je fais svn up : est-ce que le code source que je récupère, c'est $LastChangedRevision:$ ou sa valeur ?

Mais de toute manière, d'après ce que j'ai dit plus haut, ta solution demande trop de contorsions par rapport à la simple lecture de .svn/entries

--
RealET

-----Message d'origine-----
[...]
>

Ah, et aussi, juste une remarque, mais ça n'a pas l'air de
faire planter
(encore) le rss, mais on a un fichier qui définit la validité
du XML des plugins (les différentes balises possibles):
- là
Connexion · GitLab

plugin.xsd

- et là :
Connexion · GitLab

plugin-own.dtd

Tu ajoutes une balise non prévue :
> + <LastChangedRevision>$LastChangedRevision$</LastChangedRevision>

ça n'a pas l'air de géner, mais je tiens à le signaler pour
avoir une trace.

Je retire le tag. Connaissant l'extreme sensibilité du générateur rss,
autant l'enlever. Pas envie de le voir faché.

Merci pour les liens.

-----Message d'origine-----
[...]
La question, c'est : si dans le code source je met
$LastChangedRevision:$ et que je commite. Puis que je fais svn up :
est-ce que le code source que je récupère, c'est
$LastChangedRevision:$ ou sa valeur ?

1/ ajouter dans le source, en commentaire :

  // $LastChangedRevision: 17662 $

ou

  // $LastChangedRevision: 0123456789123456789 $

ou

  // $LastChangedRevision$

2/ faire le commit. La ligne est automatiquement modifiée en qq chose du
genre :

  // $LastChangedRevision: 17672 $

par le poste client (en admettant que 17672 soit la dernière révision).
Cette même ligne sera automatiquement mise à jour localement lors de
l'update par le numéro de révision donné par le serveur.

Si bien sur les propriétés subversion ont été placées correctement sur
le/les fichiers.

Mais de toute manière, d'après ce que j'ai dit plus haut, ta
solution demande trop de contorsions par rapport à la simple
lecture de .svn/entries

En effet, si .svn/entries est présent, autant en profiter.