Carnet Wiki

La Zone Facile

Version 24 — July 2011 Yffic

Pas LA mais LES zones | Accéder à la zone | Regles et repères | Poser un tag

La zone c’est pas un site pour promeneurs, c’est un site pour programmeurs ! Alors une chose est claire : ça pourrait être plus facile de s’y retrouver.

Cette page vise à collecter les repères et jalons... et même, parfois, des idées pour faciliter les choses par des modifications in situ, même si il semble que le paramétrage de trac soit particulièrement ardu.

Enfin, les mauvais esprits considèreront qu’elle ouvre une brèche dans une politique de “security by obscurity”, mais fort heureusement, il n’y en a pas dans les spipeurs.

Note : il n’est pas besoin d’un logiciel client SVN pour récupérer les plugins de la zone qui ne sont pas disponibles en zip sur spip-contrib.
On accède directement à leur zip à l’adresse :
http://zone.spip.org/trac/spip-zone/changeset/latest/_plugins_/NOM_DU_PLUG?old_path=/&format=zip


Pas LA mais LES zones !

Il y a plusieurs sortes de zones SVN, et quand on fait une recherche avec google, c’est pas toujours évident de savoir où est-ce qu’on atterrit, car les zones se ressemblent toutes, avec l’interface insipide de trac.

-  Certaines zones SVN sont pour le core de SPIP, d’autres sont pour les plugins et autres outils ou sites de la galaxie.

Principales adresses des zones :
-  les plugins
-  le core version de développement
-  le core les autres versions
-  les extensions
-  la galaxie
-  la/les dists

Quand on fait une recherche par google et qu’on tombe sur une zone, il faut être vigilant pour déterminer sur une page de quelle zone on arrive :
[->org/trac/spip-zone/browser" class='spip_url spip_out auto' rel='nofollow external'>http://zone.spip.org/trac/spip-zone/browser] net/trac/spip/browser]
org/trac/spip-zone/browser/_core_/plugins/forum]
c’est la zone, tandis que
[->http://core http://trac .spip rezo .org/projects/spip/repository]
c’est le core.

De plus, à certains moments de l’histoire de SPIP, les adresses et serveurs changent, mais les anciennes versions restent : attention à être bien dans une zone “active”. C’est un peu une devinette, mais les dates de changement des derniers commits permettent de savoir si c’est une zone vivante ou une vieille chaussette qui traine trainent . A l’heure actuelle, il n’est pas exclu que seules des zones actives soient en ligne, mais je n’y mettrais pas ma souris au feu.

-  Ensuite, dans le noyau de SPIP, il y a plusieurs branches de développement correspondant à différentes versions. La page [->http://core http://trac .spip rezo .org/projects/spip/repository/] net/trac/spip/browser] donne ainsi accès à
-  “spip” (actuellement la version 2.2, soit la plus récente)
-  “branches” (les versions anciennes, encore maintenues, de 1.8 à 2.1)

Donc là encore, attention : quand on tombe par google sur [->http://core http://trac .spip rezo .org/projects/spip/repository/changes/spip/ecrire/index net/trac/spip/browser/spip/ecrire/exec/accueil .php], il ne s’agit pas d’un fichier actuel, mais de la version actuelle d’une version de SPIP qui ne sortira que dans plusieurs mois, ou peut être pas...

<blockquote class="spip">

Suggestions pour améliorer ça

Actuellement, il n’y a pas de repère visuels, il faut lire et décrypter l’adresse pour savoir à quelle sorte de zone SVN appartient la page affichée. Ce point gagnerait à être amélioré.
Il serait utile de manifester de manière immédiate et non ambigüe la nature de la zone SVN de la page affichée. Par exemple par un surtitre ou un graphisme ou un logo ou un bandeau haut ou bas ou gauche ou droite.
Pour info, la page http://trac.edgewall.org/wiki/TracI... indique comment changer le look en modifiant les templates Genshi (templating engine écrit en python) .

</blockquote>


SVN : pour accéder à tout ça

Il y a quelques docs dont la lecture sera utile voire nécessaire comme préalables :
-  http://zone.spip.org/trac/spip-zone/wiki/CommentUtiliserSvn
-  http://zone.spip.org/trac/spip-zone/wiki/CharteDeFonctionnement
-  http://s5.scriibe.net/spip.php?rubrique9
-  http://www.cent20.net/spip.php?article155

On a référencé plus haut les adresses des zones SVN par leur adresse http. On peut ainsi leur rendre visite avec un simple browser. Mais pour travailler avec, pour bénéficier du SVN, il faut un compte avec un code d’accés à la zone, un client SVN et utiliser les adresses SVN.

-  Pour ouvrir un compte il faut s’inscrire à la liste de discussion associée à la zone, et demander à bénéficier d’un accés. 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.

-  Les clients svn sont divers mais sous MSWindows, il y en a surtout un : tortoisesvn, [à télécharger->http://tortoisesvn . télécharger -> ] net/] et installer sur sa machine. Ca ça intègre de nouvelles options au menu contextuel de l’explorateur (sur clic droit droitr dans un dossier)

-  Les adresses svn se déduisent des adresses http en remplaçant http:// par svn://
(sauf exception ? à confirmer)

Hum, exception confirmée! car ça peut bouger sur le zone...

Par exemple, pour
http://zone.spip.org/trac/spip-zone/browser/tags/abomailmans_spip2
svn://zone.spip.org/spip-zone/tags/abomailmans_spip2

En juin 2010, l’équivalence de la zone svn / http (ROOT) sera
SVN : svn://zone.spip.org/spip-zone/
HTTP: http://zone.spip.org/trac/spip-zone/browser/

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. Cette liste bénéficie d’une interface newsgroup sur gmane

Pour tester SVN il y a un répertoire bac à sable : svn://zone.spip.org/test ou plutot svn://spip svn :// spip .org/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).

<blockquote class="spip">

Il y a aussi des VDOs pédagogiques que Gilles est en train de documenter :
-  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

</blockquote>

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.

Note : 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”...

Voici donc quelques repères, à confirmer et préciser encore :

-  la commande “checkout” permet de récupérer localement un répertoire de la zone
C’est par là qu’on commencera sans risque.

-  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 allourdissent chaque sous-répertoire de l’arborescence

-  la commande “import” uploade sur le SVN le contenu du répertoire courant.

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.

Ya des trucs évidents et pas spécifiques au SVN :
-  pas casser le code des copains
-  documenter ce qu’on fait
-  faire “coopératif”

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é).

<blockquote class="spip">

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...

</blockquote>

-  Attention : la commande import peut conduire à déposer des fichiers ou répertoires entiers sur la SVN alors qu’on voulait importer quelquechose 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.

2011 : branches et version d’un plugin

Plusieurs sous-répertoires dans le dossier d’un plugin : trunk (pour SPIP en développement), branches/1.5 ...

[SPIP Zone] trunk/branches/tags

cedric préconise :

svn mv corbeille corbeille_trunk
svn commit 
mkdir corbeille
svn add corbeille
svn mv corbeille_trunk corbeille/trunk
svn commit

Rastapopoulos précise :

// Sauver le dossier actuel en gardant l'historique
svn move monplugin monplugin_tmp


// Créer la nouvelle structure de dossier et la commiter
mkdir monplugin
mkdir monplugin/branches
svn add monplugin
svn commit monplugin


// Si on veut tout péter : sauver l'état actuel dans une branche du nom de la version
svn cp monplugin_tmp monplugin/branches/1.5.x


// Déplacer vraiment la sauvegarde dans le trunk cad la branche de dev
svn move monplugin_tmp monplugin/trunk


svn commit monplugin

b_b rédige un pense bête ainsi : http://www.weblog.eliaz.fr/article113.html

et marcimat explique en détail comment pour sa part, pour partir d’un plugin existant X, il a fait :

svn mv X X_tmp
svn commit -m "prépa trunk/branches" X X_tmp


svn mkdir X
svn mkdir X/branches
svn cp X_tmp X/trunk
svn mv X_tmp X/branches/v1
svn commit -m "trunk/branches" X X_tmp

Retour à la version courante

Toutes les versions