Voir aussi
- Poser un tag d’un plugin
- Commandes svn de base pour la zone
Introduction
- le trunk c’est le développement le plus avancé. En pratique c’est quasiment toujours la version pour SPIP3.
- les branches sont les autres versions : versions antérieures mais toujours maintenues, avec des mises à jours, corrections de bugs, et en pratique des nouvelles fonctionnalités. En pratique la plupart du temps ce sont les version toujours maintenues et développées pour spip2.
- les tags, c’est une copie instantannée d’une version. C’est destiné à ne plus jamais bouger. On ne commite jamais sur une version « tag »
En pratique, les tags sont créés exactement comme les branches, mais contrairement aux branches, ils ne sont jamais modifiés ensuite.
Préalable
Pour les indications suivantes, il faut avoir téléchargé toute la zone via svn :
svn co svn://zone.spip.org/spip-zone/_plugins_
, et se déplacer dans ce répertoire : cd _plugins_
.
On peut alors déployer les instructions suivantes.
Passage d’un plugin en trunk et branches
La crème des indications est proposée par marcimat sur le blog de b_b :
svn mv querypath querypath_old
svn mkdir querypath/branches
svn cp querypath_old querypath/branches/v1
svn mv querypath_old querypath/trunk
svn commit -m "Passage trunk/branches de querypath" querypath
Autres témoignages
cedric préconise :
svn mv corbeille corbeille_trunk
svn commit
mkdir corbeille
svn add corbeille
svn mv corbeille_trunk corbeille/trunk
svn commit
jluc constate que ça marche bien sans le premier svn commit (qui sert juste de sauvegarde d’étape ?) donc :
svn mv bidule bidule_trunk
mkdir bidule
svn add bidule
svn mv bidule_trunk bidule/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
Joseph, qui se sert de TortoiseSVN indique avec l’appui de Cerdic :
- renommer le répertoire monplugin en monplugin_trunk
- commiter (pour pouvoir plus loin recréer un répertoire du même nom)
- créer le répertoire monplugin
- renommer le répertoire monplugin_trunk en monplugin/trunk
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
Structure élémentaire normative conseillée
En résumé, sur chaque sous-répertoire de la zone (consultez : ces sous-répertoires de http://zone.spip.org/trac/spip-zone/browser/ )
Le schema normatif à utiliser est donc le suivant :
spip-zone/_plugins_/ monplugin /
spip-zone/_plugins_/ monplugin / branches : pour des versions « stables » à ne plus modifier
spip-zone/_plugins_/ monplugin / branches/version_0 :
spip-zone/_plugins_/ monplugin / branches/version_2 :
spip-zone/_plugins_/ monplugin / branches/version1 :
spip-zone/_plugins_/ monplugin / tags
spip-zone/_plugins_/ monplugin / trunk : normalement la version principale
choisir pour /selon regles definies dans REGLES_COMMIT/pour la version « utile »
spip-zone/_plugins_/ monplugin /
Rappel :
- éliminez les scories (.bak, .diff, logs et code de debuging) avant de transférer
- commentez les commits (mettre un message avec l’option -m)