Petite question sur l'utilisation.

J'ai fait pas mal d'évolutions sur mon thème pour le rendre compatible 2.2.
Mais forcément, il n'est plus compatible 2.1.

Du coup, si je mets à jour sous SVN avec cette nouvelle version, supposons qu'un jour j'ai un bug sur la version compatible 2.1, je ne pourrais plus gérer ça avec SVN ?

Et tu peux publier aussi facilement depuis le gestionnaire d'extension ?

En fait je me posais la question surtout comme la v2.2 n'est pas encore sorti, j'ai donc fait une version à partir d'une archive hors svn.

Tout est une question d'organisation. Nous avons les deux extrêmes entre ddtddt et Eric.

A toi de voir Zaphod ce que tu préfères.
Perso, j'opterai pour une structure :

|- trunk (dossier de travail)
|- v2.2.a
|- v2.1.a
|- v2.1.b
|- v2.1.c
...

Chaque branche correspondant à une version publiée. Je retrouve facilement les fichiers qui ont été publiés et je ne maintiens pas une grosse arborescence.

trunk c'est un nom (anglais) que l'on donne presque par convention au dossier de travail sur lequel on bosse.

Par exemple pour le projet Piwigo, il y a donc trunk qui sert a ajouter / améliorer / rectifier / supprimer ... certaines choses de manière indépendante de la version de développement en court.
En général, à partir de trunk, on réalisera des branches. (br2.1 br2.0 br1.7 ...). Ces branches correspondent donc à une version majeur de la phase de développement du projet.
Il y aussi les tags... Le principe c'est décider à partir de tel moment, on va créer une nouvelle arborescence.

Par exemple, le développement de la branche 1.7 est figée, ainsi que toutes les autres branches. Rien n'empêche de revenir dessus cependant ! Le découpage est ainsi fait qu'il est possible d'apporter des amélioration sur toutes les versions !

Concrètement il y a deux cas de figures.
1/
On va ajouter une fonctionnalité dans trunk. Là on se pose la question à savoir si cette fonctionnalité pourrait fonctionner sur la branche en court de développement (actuellement la branche 2.1). Si la réponse est oui, on va répercuter le changement dans la branche.
2/
Inversement, on peut corriger un bug dans la branche en court de développement et reporter la correction dans trunk.

Bref, tout ça pour te dire que multiplication des sous-dossiers permet de bien cerner un état de l'avancé du développement.
Et pour publier via PEM, il suffit de faire attention à la configuration de l'extension afin que PEM génère l'archive en se basant sur la bonne branche (ou sur trunk).
=> Pour plus d'information sur la publication sous PEM, voir le [wiki] (figure 03)

Autant sur le core, je trouve ça pertinent d'avoir trunk/branch 2.2/branch 2.1, autant dans les plugins, je trouve ça inutile la plupart du temps. Sur Community, je n'ai pas de sous répertoires par branche.

A ta place Zaphod, je commiterais les modifs dans le répertoire racine, et si un jour tu veux publier une version compatible 2.1 mais corrigée, alors il sera encore temps de "tirer une branche" à partir d'une revision ancienne (je te donnerai un coup de main pour cette opération).

Je remonte ce topic pour savoir s'il y a un client svn pour mac facile à utiliser.
Utilisation de ligne de commande proscrite ;)

Bon en fait avec ce plugin je n'arrive pas à commiter...

J'ai un message d'erreur pourtant avec le bon login/mot de passe :
"authorization failed: Could not authenticate to server: rejected Basic challenge"

Du coup je ne peux faire aucune mise à jour avant de retrouver mon PC...

Accessoirement, il n'y a pas un moyen de mettre à jour les fichiers via un truc style client web ou quelque chose ?