Git et Subversion : quand plus rien ne va

Les plugins WordPress sont livrés dans le directory WordPress au moyen d’un repository SVN. A chaque nouvelle version du plugin, on en commit les sources et on les tags, ce qui provoque l’apparition de la nouvelle version sur le site WordPress.

Afin de gérer les sources du plugin et de travailler en équipe, on peut utiliser un outil de gestion de source tel que Git et utiliser Github comme repository central. Pour la passerelle Git vers SVN, on utilise alors la commande git svn et ses différentes actions.

Je ne décrirai pas ici comment fonction SVN et Git. Par contre, je souhaite expliquer comment j’ai pu résoudre un problème de mise à jour du repository SVN de WordPress lors de la livraison d’une nouvelle version d’un plugin.

Donc, après des modifications du plugin, je commit et je mets à jours github. Les commandes successives sont en simplifiant :

 

Jusque là tout va bien !

Après ceci, je veux mettre à jour le repoitory svn de WordPress puis tagger une nouvelle version du plugin et là patatra !

 

Que ce fichier soit « out of date », je n’en doute pas car je l’ai bien modifié en local et après avoir mis à jour le repository github, c’est le repository SVN que je veux mettre à jour avec la commande « git svn dcommit » . J’ai l’impression que j’ai manqué quelque chose comme une opération « pull » en provenance de SVN et d’un « rebase » dans la foulée. Mais, étant le seul à travailler sur ce plugin, personne d’autre n’a fait évoluer le repository SVN parallèlement à mes modifications locales. Mystère !

Après de longues recherches sur cette erreur et aucune solution qui ne me permette de commiter et tagger dans svn, je trouve cet article qui me permet de repartir de zéro: http://danielbachhuber.com/2010/09/29/how-to-properly-use-git-with-wordpress-org-subversion/

La manipulation décrite rétablie le répertoire de travail local avec le contenu du SVN WordPress qui contient toujours la version précédente du plugin, puis, réinjecte les modifications qui sont dans le repository sur github. En gros, les étapes sont :

  1. sauvegarder les derniers developpements locaux (tar …) et mettre tout cela de coter au cas où …
  2. recloner le repository svn en local dans un répertoire travail vierge
  3. récupérer la dernière version github qui est à jour avec les dernières modifications (mais sauvegardées par ailleurs au cas où)
  4. commiter sous svn et tagger

 

Et dans la pratique, cela donne :

* Recréer le répertoire local de travail

 

* Récupérer dans SVN le numéro de révision correspondant au dernier commit fait.

On ne retient pas r436435 qui a été créé par une commande « git svn tag », mais r436432.

 

* Cloner le repository SVN dans le répertoire local de travail :

Note : « -s » est un raccourci pour   « -t tags -b branches -T trunk »

 

* Ré-associer le répertoire local de travail au repository Github

 

* Commiter et tagguer la nouvelle version du plugin dans le SVN WordPress

 

Et voilà le plugin est livré !

Il ne me reste plus qu’à trouver ce qui a provoqué cette erreur afin quelle ne se reproduise plus.

 

Mise à jour du 18 mai 2012 :

Pour l’utilisation de git et svn, je recommande la lecture de quelques articles :
git svn en dix minutes

How to Publish a WordPress Plugin – Git

Git to SVN: Automated WordPress Plugin Deployment

How to properly use Git with WordPress.org Subversion

Et donc tout le secret est dans la commande « git svn rebase », ce qui donne une séquence de commandes similaire à celle-ci :

 

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *