Carnet Wiki

La Zone Facile

Voir
-  Commandes svn de base pour la zone l’essentiel de SVN pour la Zone, pratique et immédiatement utilisable,
-  Commiter un plugin sur la zone (ou en récupérer le code),
-  Dossiers d’un plugin : trunk / branches / tags pour la structure recommandée pour les dossiers d’un plugin (trunk et tags)
-  Comment distribuer ma super contrib dans SPIP (Processus opérationnel)

Attention : Le texte qui suit peut être utile mais il n’est pas toujours opérationnel ou à jour.

Pas LA mais LES zones | Regles et repères | VocableSVN | Poser un tag

La zone c’est pas un site pour promeneurs, c’est un site pour programmeurs ! Cette page vise à collecter les repères et jalons.

Antisèche

  1. en bref : svn://trac.rezo.net/spip/spip et svn://zone.spip.org/spip-zone/ sont les 2 mamelles de SVN.
  1. récupérer un ZIP d’un plugin de la zone alors que ce plugin n’est pas zippé par SPIP pour SVP : https://zone.spip.org/trac/spip-zone/changeset/latest/_plugins_/NOM_DU_PLUGIN?old_path=/&format=zip (notez le &format=zip)

Pas LA mais LES zones !

Il y a plusieurs sortes de zones SVN. Certaines zones SVN sont pour le core de SPIP, d’autres sont pour les plugins et autres outils ou sites de la galaxie :
-  https://zone.spip.org/trac/spip-zone/browser c’est la zone
-  https://core.spip.net/projects/spip/repository/show/spip c’est le core.
-  mais https://zone.spip.org/trac/spip-zone/browser/_core_/plugins, c’est les plugins-dist (qui sont distribués avec le core).

-  Il est arrivé, à certains moments de l’histoire de SPIP, que les adresses et serveurs changent. Les dates de changement des derniers commits permettent de savoir si c’est une zone vivante ou non
-  Concernant le noyau de SPIP, il y a plusieurs branches de développement correspondant à différentes versions. La page [https://core.spip.net/projects/spip/repository] donne ainsi accès à "spip" (actuellement la version 3.2, soit la plus récente) et "branches" (les versions anciennes, maintenues ou non, de 1.8 à 3.1)

SVN : pour récupérer localement ou envoyer des modifications

Préalables :
-  Comment utiliser SVN
-  Charte Spip-Zone
-  Présentation de Subversion

On a référencé plus haut les adresses des zones SVN par leur adresse http. Cela permet de lire le code dans un browser (ou dans TortoiseSVN). Sinon pour le récupérer localement, par SVN, il vous faut l’adresse au protocole svn ://. Sauf exception, les adresses svn se déduisent des adresses http en remplaçant http:// par svn ://, (éliminer aussi /browser/spip-zone/ avant l’un des titres d’espaces : _plugins_ ou _core_ pour les plugins , _squelettes_ ou encore _outils_... ).

En février 2019, ces adresses fonctionnent bien, exemple :
-  pour le plugin memoization, svn://zone.spip.org/spip-zone/_plug...
-  pour le core de SPIP DEV : svn://trac.rezo.net/spip/spip .Ça inclue les plugins-dist qui sont des "externals", en fait accessibles via svn ://zone.spip.org/spip-zone/_core_
-  et pour le plugin forum qui est un plugin-dist : svn ://zone.spip.org/spip-zone/_core_/plugins/forum

-  Pour les diverses versions du core l’adresse générale svn est : svn://trac.rezo.net/spip.
On y trouve les différentes versions de SPIP :

  • les « tags » : c’est les versions sorties telles quelles, ça évolue pas
  • les « branches » : c’est les versions déjà sorties et parfois anciennes, mais qui sont susceptibles d’évoluer notamment parce que certaines sont encore maintenues et pourraient donner une nouvelle sous-version d’une ancienne version.
  • le « trunk », dans le sous-répertoire ’spip’, c’est la version à la pointe du progrès, qui un jour donnera la prochaine version....

-  Pour les plugins de la zone, l’adresse générale est svn://zone.spip.org/spip-zone/_plugins_/, suivie du prefixe du plugin : on peut y retrouver des « branches » correspondant à d’anciennes versions (parfois toujours exploitées), et normalement le « trunk » contenant la version de source active, souvent en travail (voire Dossiers d’un plugin : trunk / branches / tags, les états des plugins : « dev » « test » et « stable », et la balise de compatibilité dans le paquet.xml).

Pour publier un modification ou un nouveau code ("commiter"), il vous faudra un compte SVN pour SPIP. Il faut pour cela s’inscrire à la liste de discussion associée à la zone (archives ; ; Inscriptions), et demander à bénéficier d’un accés en écriture sur la zone. Il faut avoir préallablement lu la charte de développement évoquée ci dessus, et compris l’esprit dans lequel est développé SPIP et proposé la zone. C’est Gilles qui délivre généralement les comptes et mots de passes associés.

Pour tester les commits SVN il y a un répertoire bac à sable : svn://trac.rezo.net/test/ ou plutôt svn ://trac.rezo.net/test/ !!
C’est là qu’il faut tester SVN car c’est un "repository" à part, pour lequel il n’y a pas génération de notification mail (tant qu’à faire, autant ne pas polluer les listes avec des tests).

Tout commit sur la zone se traduit par l’envoi de mails de notifications automatiques, reçus par tous les développeurs et utilisateurs intéressés, ce qui leur permet de suivre le développement de SPIP et des plugins. voir et s’inscrire sur http://listes.rezo.net/mailman/list.... Cette liste bénéfici(ait) d’une interface newsgroup sur gmane

Outils et GUI

Vous pouvez utiliser un client SVN en ligne de commande, ou bien si vous êtes familiarisé-e avec ce type d’outils sur votre OS, essayez https://contrib.spip.net/spip_svn_loader

Les interfaces graphiques des divers OS disposent de clients GUI, souvent intégrés à l’explorateur de fichiers.

Sous MS/Windows, il y en a surtout un, disponible en 32 et 64bits : TortoiseSVN à télécharger et installer sur sa machine. Il intègre les options au menu contextuel de l’explorateur (sur clic droit dans un dossier). Voir un équivalent sous Linux : RabbitSVN (pas de M@J depuis 2012).

-  Vincent avait écrit un Tutoriel pour l’outil Tortoise [1] ; il reste http://zine.spip.org/spip.php?article44 pour Mac OSX et les Chapitres de la documentation en-ligne (PDF téléchargeable sur http://tortoisesvn.net/support.html), et un support assez complet PDF 24p. y compris tags & trunks !)
Nota Bene : si TortoiseSVN accepte les URL de dépôts au protocole https://zone.spip.net/spip-zone/_plugins_/.. en lecture (checkout), il faut s’être positionné sur un lien au protocole svn ://zone.spip.net/trac/spip-zone/_plugins_/... pour pouvoir passer les commits (avec l’authentification d’accès à la zone que vous avez reçue)..

Il y a aussi quelques VDOs pédagogiques que Gilles a préparé :
-  Création d’un nouveau projet, ajout au dépôt
-  Ajout, modification, et suppression de fichiers/répertoires sous SVN
-  Mise à jour de sa version de travail, fusion de modifications concurrentes
-  Conventions standards trunk / tags / branches

L’interface TortoiseSVN est agréable et intuitive, du moins en ce qui concerne les fonctions de base. Elle propose notamment une navigation à travers les dossiers du repository svn maître ou local, avec de riches menus contextuels qui permettent de choisir facilement ce qu’on veut. ça va d’autant mieux qu’on connait le vocabulaire svn, bien spécifique, et c’est là que c’est pas intuitif au départ : pensez que votre Tortoise est le serveur !.

Les options du menu de TortoiseSVN sont décorées par des petites icones : fléches vers le bas ou vers le haut notamment. Faites y bien attention pour vous assurer que vous faites une opération "dans le bon sens" [2], c’est ", car elles sont souvent plus intuitives que les termes (’export’ ou ’import’ sont bien ambigus en particulier).

Commandes SVN de base

-  la commande "checkout" permet de récupérer localement un répertoire de la zone
C’est par là qu’on commencera sans risque. Il n’est pas besoin d’un mot de passe pour cela.

-  la commande "commit" : permet d’envoyer sur la zone les modifications faites sur les versions locales des fichiers.

-  la commande "up" permet de faire une mise à jour de la version perso des documents, à partir de la version "maître"". Si on travaille en local avec une copie récupérée par SVN des fichiers de la zone, "up" ça veut dire télécharger depuis le site de la zone les nouveaux fichiers et les fichiers qui ont entre temps été modifiés par d’autres développeurs. (C’est donc éventuellement trompeur au début puisque ce n’est pas un upload mais un download).

-  la commande "export" permet de recopier ailleurs le contenu d’un répertoire svn local, mais sans les informations techniques de SVN qui alourdissent chaque sous-répertoire de l’arborescence : utile pour se récupérer une version utilisable propre....

-  la commande "import" uploade sur le dépot SVN le contenu du répertoire courant ; opération d’initiation uniquement pour la création d’un nouveau plugin, à utiliser avec précaution.

Difficulté :
-  les conflits de modification d’un même fichier

Les Règles à Respecter et les Erreurs à Eviter

La zone c’est pas (que) pour rigoler. C’est le support IN FINE de ce qui nous relie : le code. C’est donc précieux, on ne fait pas n’importe quoi avec. ça se traduit par des interdits et des règles de conduites à respecter quand on y touche.

Ce qui suit a parfois été formulé, de manière plus ou moins formelle, mais parfois ça n’a que "réagi", après une erreur justement.

Y’a déjà des trucs évidents et pas spécifiques au SVN :
-  ne pas casser le code des copains
-  documenter ce qu’on fait
-  faire "coopératif"
-  se renseigner sur l’existant avant de coder (si ça se trouve, ce que vous vous apprêtez à faire a déjà été fait)

Ya des trucs spécifiques à SPIP :
-  "on code d’abord, on discute après" (pour donner du coeur à l’ouvrage et éviter les discussions stériles)
-  "gogogo" ! (version applicative du précédent précepte)

Enfin, ya des trucs très spécifiques à la zone :

-  Scrupuleusement documenter chaque commit au moins par un log qui décrit le code (ne pas dire "encore un commit sur formulaire.php", qui est totalement redondant, mais "ajout d’un paramètre $date à la fonction form_youpi pour indiquer la date de création" par exemple)

-  Eviter de faire des commits pour rien du tout ou de trop petites modifications (les rassembler si possible car ça encombre la liste d’information sur les commits et nuit au suivi). C’est pour cela d’ailleurs qu’il y a un espace de test à part.

-  Respecter l’historique !!! L’historique, c’est l’armoire en dentelle de l’arrière grand-mère et les actions russes du grand père : inestimable. L’historique du code, c’est la possibilité d’accéder à toutes les modifications qui ont mené à la version actuelle du code (pour l’instant, dans le passé seulement...).
ça peut être utile pour comprendre le code (en lisant les logs passés par exemple) ou pour restaurer une version antérieure (si on s’est trompé).

Si par exemple on doit déplacer un répertoire, effacer ce répertoire puis le copier à sa destination, effacerait l’historique, ce qui doit être absolument évité. Pour obtenir le même résultat, mais en conservant l’historique, on utilisera la commande SVN dédiée au déplacement...

-  Attention : la commande import peut conduire à déposer des fichiers ou répertoires entiers sur la SVN alors qu’on voulait importer quelque chose localement. Attention donc à la flèche petit logo sur l’option de la commande : c’est une flèche qui monte...

Poser un TAG en SVN

Un tag (anciennement sabot) est un moyen de ’figer’ un plugin a un moment T de son développement. Si vos modifications risquent d’affecter les utilisateurs antérieurs ou pour ne pas risquer d’erreurs, posez un tag dans tags.

Voici comment poser un tag dans /tags en ligne de commande en restant sur le serveur de spip-zone, le dossier SVN "abomailmans" et son contenu sera recopié sous "abomailmans_spip2"

ordinateur:~ touti$ svn copy svn://zone.spip.org/spip-zone/_plugins_/abomailmans \
           svn://zone.spip.org/spip-zone/tags/abomailmans_spip2 \
          -m "creation tag pour abomailmans"
Authentication realm: <svn://zone.spip.org:3690> SPIP Zone
Password for 'touti':
Authentication realm: <svn://zone.spip.org:3690> SPIP Zone
Username: toutati@exemple.com
Password for 'toutati@exemple.com ':

Committed revision 38595.

Une fois que Committed revision n° apparait c’est bon, le tag est posé !

Tags et versions de dev et stable des plugins

davux :
Le processus de développement pourrait (devrait ?) être le suivant :
-  1. à la création du plugin, utiliser dans plugin.xml l’état "dev"
-  2. on développe son plugin par commits successifs
-  3. quand on est sur une version stable, on change en "stable", on commit
et on copie dans tags/. La première fois, on ajoute une ligne spécifique
dans l’empaqueteur.
-  4. on remet l’état à "dev", et on reprend à 2.

ça serait nickel : un petit filtre dans la page de plugins qui ne montre que les plugins stables par défaut, ou même un fil RSS distinct avec juste les versions stables, et c’est bon. La grosse question reste de comment simplifier le process aux auteurs de plugins pour les inciter à indiquer la dernière version stable.

Annuler un commit

Pour annuler un commit désastreux et revenir à la version antérieure, il faut le ’revert’.

Une commande svn possible pour annuler le commit 58754 est :
svn merge -c -58754

Avec les outils GUI (tortoiseSVN, rabbitSVN, rapidsvn) il faut

  1. reverter la copie locale jusqu’à la bonne version avant le mauvais commit, puis
  2. commiter les changements

[1Encore accessible en https://web.archive.org/web/2012062..., vous le pourrez consulter sur SPN...

[2C’est le serveur qui est l’origine du sens significatif pour TortoiseSVN (évidemment, y’a pas que votre poste de développeur : réfléchissez-y !

JLuc - Mise à jour :4 mars 2019 à 18h06min

Toutes les versions