🌍
Français
subversion est installé de base sous macos... et cornerstone est payant...
Il y a sans doute un truc à faire dans la config de subversion... mais ça me dépasse...
Je vais peux-être dire des bêtises... :
http://subversion.apache.org/packages.html#osx
http://www.zennaware.com/cornerstone/index.php
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 ?
Donc sous mac, il y a SCplugin, qui a l'air de très bien fonctionner :
http://scplugin.tigris.org/
Et qui évite la ligne de commande !
Je remonte ce topic pour savoir s'il y a un client svn pour mac facile à utiliser.
Utilisation de ligne de commande proscrite ;)
Encore une fois, chacun s'organise comme il veut :-)
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).
Mouais, je vais me contenter de gérer une seule version... c'est trop compliqué pour moi tout ça.
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)
C'est quoi le trunk ?
Mon dossier de travail, actuellement, n'est pas synchronisé sur svn.
Je ne comprends pas trop comment, avec cette organiser, publier des versions dans le gestionnaire d'extensions.
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.
Zaphod a écrit:
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.
Tu organises bien sur comme tu veux.
Mais moi je suis réaliste quand la 2.2 sera sortie je ne corrigerais plus d'erreur sur la branche précédente. Donc je ne vois pas l'intérêt de complexifier le dépôt de chaque extension.
C'est un peux comme les Tag des plugins, cela ne me sert à rien pour moi il ne sont jamais réutilisé derrière. Si par hasard j'avais besoins de regarder un ancienne version de me met à la bonne révision !
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.
Zaphod a écrit:
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 ?
Tu n'auras plus qu'a suggérer au utilisateur de migrer en 2.2 :-D
Moi perso je ne mettrais plus à jour pour le 2.1 quand la 2.2 sera sortie
Et tu peux publier aussi facilement depuis le gestionnaire d'extension ?