[SPIP Zone] SVN et mises à jour en ligne (+ détail des 2 modes de maintient possibles)

Archives Zone
1

2008/4/13 Stéphane Santon <m.spiprezo@team-santonum.com>:

J'ai bien reçu mes identifiants, merci.

Qq points :
- Ai-je accès à toute la zone ?? N'est-ce pas dangereux (pour la zone) ?

tu peux t'entrainer sur svn://trac/rezo.net/test
Une fois que tu seras à l'aise avec les 2 ou 3 manips de base il n'y
aura pas de problème.

Je développe un squelette de site sous forme de plugin
- Où le déposer ?
  . dans _squelettes_ ?
  . dans _plugins_ ?
  . où je veux ?

un sous répertoire de _squelettes_

Pour passer d'une version _dev_ à une version _stable_ , il faut que je
recopier tout le dossier dev vers stable en local ? Donc avoir 2 versions en
ligne ?

Si tu veux maintenir en même temps le suivi d'une version de dev et
une version stable de ton plugin (par ex. le premier pour SPIP SVN,
avec des fonctionnalités en plus, le second juste pour spip1.9.2), tu
es obligé d'avoir 2 répertoires (qu'on appelle aussi "branche") à
maintenir de front.
Attention, la création d'une branche se fait par un svn cp sur 1 dépôt
svn (de type svn cp svn://serveur/bidude svn://serveur/bidule-stable)
Si tu choisis d'avoir les 2 versions en même temps, il faut
impérativement utiliser 2 sous-répertoires d'un répertoire ayant le
nom de ton plugin.
C'est comme cela que fonctionne SPIP (http://trac.rezo.net/trac/spip/browser)

L'avantage que je vois à cette méthode est que quelqu'un qui arrive à
n'importe quel moment peut télécharger la version stable.

Une seconde méthode est de ne maintenir qu'un version, et de décider
que ton plugin est stable à telle version. C'est la méthode dite "du
sabot" : tu indiques ce numéro de version dans la doc ou dans le
répertoire qui construit automatiquement des archives des plugins :
archivelist.txt

exemple de contenu :
_plugins_/_stable_/agenda/1_9_1:8642;agenda_1_9_1
_plugins_/_stable_/agenda/1_9_2:13400;agenda_1_9_2
_plugins_/_stable_/agenda/1_9_3;agenda_1_9_3

Ces lignes vont créer 3 archives agenda_1_9_1.zip, agenda_1_9_2.zip et
agenda_1_9_3.zip

et pour un exemple plus orienté dev+stable :
_plugins_/_test_/plugin-thelia:19326;plugin-thelia-1.0
_plugins_/_test_/plugin-thelia;plugin-thelia-1.1dev

Les inconvénients de la méthode du sabot sont nombreux :
- tu ne peux pas travailler dans ton plugin sur des fonctionnalités
qui ne sont pas dans les versions stables.
- tu ne maîtrises pas complètement la stabilité de ton plugin, car des
développement apportés par des tiers peuvent avoir des effets de bords
non négligeables (ou orienter le plugin vers un usage autre que celui
que tu avais insufflé)
- Trac ne montre directement que la version de dev
- cela oblige +/- à passer par les archives pour avoir la dernière
version stable (un checkout classique te donne la version de dev)
- Les sabots étant définis dans Trac, il n'est pas possible de
récupérer la version stable par svn (sans passer par Trac pour trouver
le bon numéro de version).

Pour être honnète je ne vois qu'un avantage à cette méthode : il est
purement administratif côté serveur : ça diminue par 2 l'espace occupé
par ton plugin. Il s'applique très bien aux petits plugins qui sont
toujours stables en 192 et en SVN.

L'usage le plus courant pour SPIP reste quand même cette méthode.
Maintenant c'est toi qui décide.

.Gilles
---

Merci

--
Stéphane

Jeune Chambre Economique, Mouvement Jeunes Citoyens Entreprenants
  http://www.jce-rochefort.org - http://www.jce-poitoucharentes.org

Loisirs, arts, nature, technologie en Pays Santon
   Accueil en Charente Maritime *** http://www.team-santonum.com
   BTS Electrotechnique *** http://enselec.team-santonum.com

2

Le 13/04/08, Gilles Vincent <gilles.vincent@gmail.com> a écrit :

…

Si tu choisis d’avoir les 2 versions en même temps, il faut
impérativement utiliser 2 sous-répertoires d’un répertoire ayant le
nom de ton plugin.
…
Pour être honnète je ne vois qu’un avantage à cette méthode : il est
purement administratif côté serveur : ça diminue par 2 l’espace occupé
par ton plugin…

Bonsoir,
Le doublement ne concerne que la place occupée par les zips d’archives.
comme la branche est créée par un CP elle n’est composée que de pointeurs vers la version de référence. Ensuite seul les deltas sont stockés en double. Donc au final ce n’est en général pas beaucoup plus gros.

A+

Arnaud

3

> Pour être honnète je ne vois qu'un avantage à cette méthode : il est
> purement administratif côté serveur : ça diminue par 2 l'espace occupé
> par ton plugin.....

L'énorme inconvénient des branches, c'est que, lorsqu'un plugin a des
branches, il est difficile de s'y retrouver, surtout quand on connaît
mal ce plugin. Du coup on se prive de l'apport de gens qui auront
testé la mauvaise version, ou qui n'auront pas envie de se plonger
dans les arcanes des modes de compatibilité. J'ai ce problème avec
plusieurs plugins, y compris certains que j'ai en partie programmés,
et où je ne m'y retrouve pas (ex: Thickbox).

-- Fil

4

2008/4/13 Fil <fil@rezo.net>:

> > Pour être honnète je ne vois qu'un avantage à cette méthode : il est
> > purement administratif côté serveur : ça diminue par 2 l'espace occupé
> > par ton plugin.....

L'énorme inconvénient des branches, c'est que, lorsqu'un plugin a des
branches, il est difficile de s'y retrouver, surtout quand on connaît
mal ce plugin. Du coup on se prive de l'apport de gens qui auront
testé la mauvaise version, ou qui n'auront pas envie de se plonger
dans les arcanes des modes de compatibilité. J'ai ce problème avec
plusieurs plugins, y compris certains que j'ai en partie programmés,
et où je ne m'y retrouve pas (ex: Thickbox).

C'est juste un problème de référentiel.
Si on utilise une branche dev/ et une branche stable (voire un
stable_192 et stable_svn), je ne vois pas quel problème on peut
rencontrer :
Tous les développement doivent se faire dans la branche de dev/
Les autres branches sont des branches de maintenance : il ne faut y
reporter que des corrections de bugs (qui sont généralement d'abord
corrigées dans la branche principale)

(Par contre je reconnais que je ne mettrais pas de branche test/ car
c'est vraiment un truc foireux. Au pire je suis d'avantage pour la
création d'une branche temporaire "beta0.9" si ça se justifie )

Actuellement la tendance est trop souvent à installer tout plein de
plugins à l'état de dev, avec un SPIP SVN.. On peut se retrouver avec
des problèmes (type chute de perf') sans savoir d'où ça vient.
Avoir dans branches c'est quand même plus simple pour le support.
Et avoir des branches de distribution stable pour les plugin serait
cohérent avec le mode de distribution de SPIP.

.Gilles
---

-- Fil