🌍
Français
EX-FTB a écrit:
je n'arrive pas à créer de nouvelles extensions !!!
Qui peut me créer:
All_page_with_menubar (plugin)
GBO_hk-3_clear (Style)
GBO_hk-3
d'avance merci.
Fait [Subversion] r5969, [Subversion] r5970 et [Subversion] r5971
je n'arrive pas à créer de nouvelles extensions !!!
Qui peut me créer:
All_page_with_menubar (plugin)
GBO_hk-3_clear (Style)
GBO_hk-3
d'avance merci.
En y réfléchissant, peut-être que le mieux c'est de ne pas sauvegarder le zip mais d'utiliser le couple (nom du dossier de l'extension sur le dépot, révision), que ce soit par PEM ou par l'administration de la galerie, le svn proviendrait directement de svn (en zipper si c'est possible).
C'est moins de place mais plus de ressources sur le serveur... pour le client, c'est le même nombre d'octets à télécharger...
P@t a écrit:
rub a écrit:
P@t a écrit:
- Un nom d'utilisateur et un mot de passe afin de vérifier que qu'il a bien les droits sur le dossier en question
Si l'utilisateur utilise le meme identifiant et mot de passe pour PEM et le dépot, alors, il pourra laisser vide les deux champsPour moi, ce n'est pas nécessaire.
Il faut juste de PEM puisse lire (voir ecrire) dans le svn de piwigo.
En lecture tout est public, si on modifie la version, il faudra un user PEM spécifique pour PEM...Justement, si PEM doit écrire quelque chose, il faut ABSOLUMENT un nom d'utilisateur et un mot de passe...
Sinon, n'importe qui peut créer une extension sur PEM et publier une révision d'un plugin qui ne lui appartient pas.
C'est parce que pour moi, ce n'est à PEM de créer le dépot sous svn... Le développeur doit savoir le faire, sinon, il ne pourra pas commiter ses modifs...
plg a écrit:
Je trouverais ça plus naturel et sécurisant de prendre un tag (donc au développeur de faire son tag et de mettre le bon nom de revision).
Oui sans doute.
Pourquoi un tag? En gros, c'est surtout pour comprendre rapidement pourquoi cela marchait et ne marche plus avec la trunk ou la branch.
Je pense que si on a exceptionellement besoin d'un tag, il est déjà là, c'est le zip publié dans PEM.
Certes, on perd beaucoup d'infos mais est-ce qu'on les utilise vraiment?
Par contre, gérer des branches comme souhaite le faire rvelices, pas de débat, c'est évident AMA.
rub a écrit:
P@t a écrit:
- Un nom d'utilisateur et un mot de passe afin de vérifier que qu'il a bien les droits sur le dossier en question
Si l'utilisateur utilise le meme identifiant et mot de passe pour PEM et le dépot, alors, il pourra laisser vide les deux champsPour moi, ce n'est pas nécessaire.
Il faut juste de PEM puisse lire (voir ecrire) dans le svn de piwigo.
En lecture tout est public, si on modifie la version, il faudra un user PEM spécifique pour PEM...
Justement, si PEM doit écrire quelque chose, il faut ABSOLUMENT un nom d'utilisateur et un mot de passe...
Sinon, n'importe qui peut créer une extension sur PEM et publier une révision d'un plugin qui ne lui appartient pas.
Pour modifier le main.inc.php automatiquement, je ne suis pas trop partant pour le moment...
Je vais d'abord partir sur mon idée, et on rajoutera éventuellement ca après (car le fichier main.inc.php, c'est quand meme spécifique à piwigo)
plg a écrit:
P@t a écrit:
rub a écrit:
Bon, maintenant, qu'on a un dépôt pour les extensions... à quand le bouton magique dans PEM qui zippe le dernier commit (ou celui demandé), qui change les versions dans les fichiers sous svn et qui fait l'ajout dans PEM en reprenant les commentaires des commits...
;-)Oula, ca c'est un truc qui m'inspire!
Je peux?Pourquoi pas :-) ça m'a l'air un peu chaud quand même. Je ne vois pas très bien à quel moment du workflow d'ajout de revision on peut le faire, et surtout on publie quelque chose qu'on n'a pas testé tel quel.
A mon avis, le coup de faire des manips sur l'export SVN, c'est tendu. Je trouverais ça plus naturel et sécurisant de prendre un tag (donc au développeur de faire son tag et de mettre le bon nom de revision). Comme lorsqu'on fabrique les releases de Piwigo.
plg a écrit:
... surtout on publie quelque chose qu'on n'a pas testé tel quel.
...
C'est à dire?
P@t a écrit:
Hum... si chacun commence à créer un tag, pour chaque révision, on a pas finit!
Perso, pour mes plugins, je n'ai pas envie de devoir faire ca...
Moi aussi...
P@t a écrit:
On peut éventuellement proposer de rentrer une un numéro de commit.
C'est plus que nécessaire si on gérer plusieurs "branches".
P@t a écrit:
On peut également proposer de reprendre le commentaire du commit.
Des derniers commits, non?
P@t a écrit:
Après, je dois dire que c'est plus que chaud de modifier en direct le numéro de version...
D'autant plus, qu'il n'y a pas que les plugins, il y a aussi les autres extensions (templates, themes, etc...) qui n'ont pas pas d'"emplacement" pour le numéro de version.
Il suffit juste de faire le changement si le main.inc.php existe.
D'ailleurs, ils seront de mettre aussi un systéme de version sur les autres extensions.
P@t a écrit:
- le nom du dossier de l'extension sur le dépot.
Oui, ca sera la clef.
P@t a écrit:
- Un nom d'utilisateur et un mot de passe afin de vérifier que qu'il a bien les droits sur le dossier en question
Si l'utilisateur utilise le meme identifiant et mot de passe pour PEM et le dépot, alors, il pourra laisser vide les deux champs
Pour moi, ce n'est pas nécessaire.
Il faut juste de PEM puisse lire (voir ecrire) dans le svn de piwigo.
En lecture tout est public, si on modifie la version, il faudra un user PEM spécifique pour PEM...
Hum... si chacun commence à créer un tag, pour chaque révision, on a pas finit!
Perso, pour mes plugins, je n'ai pas envie de devoir faire ca...
Je suis assez partant pour créer une archive directement à partir du checkout SVN (comme le proposait rub)
On peut éventuellement proposer de rentrer une un numéro de commit.
On peut également proposer de reprendre le commentaire du commit.
Après, je dois dire que c'est plus que chaud de modifier en direct le numéro de version...
D'autant plus, qu'il n'y a pas que les plugins, il y a aussi les autres extensions (templates, themes, etc...) qui n'ont pas pas d'"emplacement" pour le numéro de version.
Pour récapituler, sur la page d'une extension, on doit avoir:
Un bouton de configuration pour le dépot SVN
L'utilisateur pourra indiquer à PEM:
- le nom du dossier de l'extension sur le dépot.
- Un nom d'utilisateur et un mot de passe afin de vérifier que qu'il a bien les droits sur le dossier en question
Si l'utilisateur utilise le meme identifiant et mot de passe pour PEM et le dépot, alors, il pourra laisser vide les deux champs
D'autres options pourront etre ajoutées par la suite (les idées me manquent!)
Un bouton permettant de sélectionner l'archive (upload ou création à partir du checkout)
- Si c'est le checkout qui est choisit, possibilité de choisir la révision (HEAD ou perso)
- Une option pour récupérer automatiquement le commentaire du commit
P@t a écrit:
rub a écrit:
Bon, maintenant, qu'on a un dépôt pour les extensions... à quand le bouton magique dans PEM qui zippe le dernier commit (ou celui demandé), qui change les versions dans les fichiers sous svn et qui fait l'ajout dans PEM en reprenant les commentaires des commits...
;-)Oula, ca c'est un truc qui m'inspire!
Je peux?
Pourquoi pas :-) ça m'a l'air un peu chaud quand même. Je ne vois pas très bien à quel moment du workflow d'ajout de revision on peut le faire, et surtout on publie quelque chose qu'on n'a pas testé tel quel.
A mon avis, le coup de faire des manips sur l'export SVN, c'est tendu. Je trouverais ça plus naturel et sécurisant de prendre un tag (donc au développeur de faire son tag et de mettre le bon nom de revision). Comme lorsqu'on fabrique les releases de Piwigo.
rub a écrit:
Bon, maintenant, qu'on a un dépôt pour les extensions... à quand le bouton magique dans PEM qui zippe le dernier commit (ou celui demandé), qui change les versions dans les fichiers sous svn et qui fait l'ajout dans PEM en reprenant les commentaires des commits...
;-)
Oula, ca c'est un truc qui m'inspire!
Je peux?
plg a écrit:
3. clic-droit sur "Register_FluxBB", Tortoise add (ou un truc dans ce goût là j'imagine)
4. clic-droit sur "Register_FluxBB", Tortoise commit (ou un truc dans ce goût là j'imagine)
3 - TortoiseSVN > Add... (ou Ajouter...)
4 - SVN Commit... (ou SVN Livrer...)
;-)
VDigital a écrit:
rub a écrit:
... à quand le bouton magique dans PEM qui zippe le dernier commit (ou celui demandé)...
;-)Zippe en excluant tous les .svn des répertoires !!!
Oh! Oui...
Of course... sans les .svn ;-)
[HS]
La truffe c'est bon. Mangez-en !
[/HS]
Je vous l'avais dit dès le début : "Je suis une truffe mais je me soigne" !! Et la convalescence prend un peu plus de temps que prévu... ;-)
Et oui, c'est bien sur de l'URL http://piwigo.org/svn/extensions que je voulais parler. Un malheureux copier/coller sauvage qui m'a perturbé.
Mais cà fonctionne cette fois. J'ai pu faire un checkout complet. En fait, il fallait que je redémarre mon PC suite à une mise à jour de TortoiseSVN que j'ai effectuée. Sans le reboot, les fonctions intégrées à l'explorateur ne fonctionnaient plus correctement.
Donc tout est OK. Merci !
Eric a écrit:
Merci Pierrick mais comme je le craignais, pas moyen de faire un checkout sur ces extensions avec TortoiseSVN. C'est bien l'URL http://piwigo.org/dev/browser/extensions qu'il faut utiliser pour le checkout et non svn://piwigo.org/dev/browser/extensions, n''est ce pas ?
c'est http://piwigo.org/svn/extensions
edit
Grattée de 32 secondes j'aurais pas du mettre la couleur !