Yop,
Le 29/08/13 15:43, Committo,Ergo:sum a écrit :
C'est bien pourquoi il faut être directif. Si on vire les fichiers archivelist* en disant: pour que votre plugin soit zippé, il faut que vous organisiez son répertoire avec un trunk et un branches, à l'intérieur de branches il faut des sous-répetoires dont le premier niveau contient un plugin.xml ou un paquet.xml, eh bien le développeur de plugin il va tenir compte de la recommandation.
Ce n'est pas plus compliqué que d'apprendre les choses au cas par cas,
je pense en effet... +1 quoi.
Par contre: "Ne serit-ce pas plus difficile de faire ça que d'apprendre
où est le fichier archivelist.txt, quelle est sa syntaxe et à quoi il
sert ?" // je rigole 
--
Suske-ki-a-decouvert-et-appris-svn-un-peu_grace-a-SPIP
Le 29 août 2013 à 20:39, Eric a écrit :
un fichier archivelist :
- contient des zips qui font référence à _plugins_/, _squelettes_/ ...
- génère un fichier xml des plugins générés nommés archives.xml
c'est ce fichier qui est utilisé par SVP pour charger la base de données des plugins disponibles.Il y a aujourd'hui 3 archivelist qui créent par là même 3 dépots logiques :
- celui du core, archivelist_core
- celui des plugins, archivelist
- celui des contrib non plugin archivelist_contrib.
Ah ok, il est vrai que les contenus de ces fichiers ne se limitent pas à un répertoire
(_core_ pour le 1er, _plugins_ pour le 2e etc).
Mais qui décide que tel Zip fait partie de tel dépot logique ?
Et où y a-t-il des recommandations pour décider où on demande le Zip de sa contribution ?
Moi je trouve que cette notion est une souplesse intéressante pour filtrer les plugins ou les contributions surtout quand on commence à avoir des milliers de contribs.
Ou alors il faudrait trouver des moyens plus simples de décrire les dépôts, un peu comme les listes intelligentes de mac c'est à dire décrit par une ou plusieurs conditions sans lister les zips explicitement : ce que tu proposes en utilisant l'état par exemple.
Mais c'est le champ "categorie" qui filtre de manière indépendante du dépot physique ! Ce que tu décris ci-dessus, c'est moins une notion de dépot logique (ce que fait pleinement "categorie") qu'un sous-ensemble d'un dépot physique ayant une certaine cohérence. Normalement cette cohérence est assurée par le découpage des répertoires de premier niveau (_plugins_ etc), mais je peux admettre qu'on puisse vouloir, EN PLUS, des assemblages inter-répertoires. A ce moment-là, créer des répertoires supplémentaires sur la zone, dont le contenu serait des liens symboliques vers d'autres points de la zone me semble suffisant.
Au passage, c'est à nouveau la question des ensembles cohérents de plugins pour avoir des distributions étendues de SPIP qui pointe le bout de son nez, là.
Committo,Ergo:Sum
Le 29 août 2013 à 20:05, « Committo,Ergo:sum » <esj@rezo.net> a écrit :
- l’organisation doit elle comporter, en plus de trunk,
deux répertoires branches et tags ou un seul des 2 ?Moi j’opterais pour le trunk et les branches. Exit les tags sauf pour les distributions spip mais à part dans une arborescence à part.
ok, c’est bien mon avis.
Je ne comprends pas trop pourquoi choisir entre les tags et les branches.
Ce sont bien 2 usages différents : les branches pour développer les variantes en parallèle, les tags pour un instantané.
Et si on en vient à imposer une structure trunk/ branches/ systématique, autant qu’elle soit complète.
Par ailleurs, je réitère ce que je disais, que la production des zip à partir des tags comme le fait Github me parait la meilleure alternative à archivelist.txt
On veut un zip : on pose un tag, et c’est tout, c’est sans ambiguité.
On est sur de pas distribuer quelque chose qui bouge, sans le vouloir, d’envoyer dans la nature des commit pas ou insuffisamment testé de manière involontaire, et ça permet de produire un zip sur une version dev si on le veut (version alpha par exemple) sans avoir à faussement dire que ce n’est pas une version de dev pour arriver à ça.
Cédric
Si,si j’aime bien débattre, justement sinon je la ramènerais pas aussi souvent 
l’argument principale était pour ma pars de proposer des zip ou paquets sur et validés (ce qui est pour moi le point le plus important, plus que la simplicité d’utilisation du dépôt), ce qui est garanti par archivelist.txt simplement et sans ré-écrire l’histoire, à l’heure actuelle, si on n’enregistre pas dedans le chemin vers /trunk pour générer le paquet. C’était donc la réflexion (au sens réfléchir) sur le /tag, ayant appris svn sur le tas au grès de mes erreur, j’ai lu la doc de svn et j’ai fait comme c’est marqué dedans tout bêtement donc tag, trunc, branche.
Après se baser sur l’état inscrit dans le paquet.xml est effectivement une bonne approche certes, mais qui aura aussi ces inconvénients, certaines choses méritent une décision humaine, collective et non automatisable (on le voit sur les sites e-commerce pour les transactions, ça se valide a la mano quand c’est sur ton compte), de nombreux plugins sont toujours restés en état test ou dev, ce n’est pas pour autant qu"ils ne sont pas utilisé ou utilisable si on sait (un minimum) ce qu’on fait et les risques
J’ai mis des sites en prod avec Spip-r qui était en test, ce n’est pas pour ça que j’ai frôlé la cata, est-ce que pour autant il ne devait pas être proposé en zip ? Après j’ai peut être pas encore bien saisi la ou vous souhaitez en venir aussi, et la manière dont cela va être étudié et fait, cela dit j’ai confiance j’ai jamais été déçu et de toute façon je m’adapterais, comme j’ai toujours fais.
Et pour les fork ont fera un autre thread, cela dit ils sont publiques et accessibles, je n’ai répondu qu’a des demandes et n’étant pas l’auteur ils sont publiques :
? ça devrait bouger sur GitHub bientôt d’ailleurs, mon petit syno ne peut se permettre trop d’accès (y’a du PluXML aussi j’aime beaucoup simple léger efficace et bien écris ). Écrire un code portable et générique comme tu le disais, demande aussi de l’expérience, du partage de compétences, des retours et conseils (pas des critiques ou reproches), et surtout du temps, ce qui n’est pas toujours facile a combiner. Mes considérations sur GitHub allaient dans ce sens, car pour moi et a mon petit niveau c’est l’outil idéal pour proposer des idées, peut être jetées en vrac, mais qui peuvent êtres illustrées concrètement, et discutées avec les outils adéquats, sans pourrir le dépôt principal (ici la zone). Je pense que plutôt que de commiter des plugins a l’arrache ou des embryons (comme il m’est arrivé de le faire) et de discuter après, un espace comme GitHub devrait être plus souvent utilisé, ce qui n’était pas hors sujet complet rapport a la gestion des répertoires de la zone. A++ Arnaud B.
Le 29 août 2013 à 22:07, Cédric Morin a écrit :
Je ne comprends pas trop pourquoi choisir entre les tags et les branches.
Ce sont bien 2 usages différents : les branches pour développer les variantes en parallèle, les tags pour un instantané.
Et si on en vient à imposer une structure trunk/ branches/ systématique, autant qu'elle soit complète.
J'ai donné mon avis là-dessus: comme Svn, sur le plan technique, n'a en fait pas de branches (au sens de Git ou de Mercurial),
avoir 2 répertoires qui en fait vont remplir les mêmes fonctions va troubler les novices, et immanquablement on va voir périodiquement des questions "je mets ça dans branches ou dans tags ?". Alors ça me paraît plus simple de dire qu'en raison des lacunes de Svn on n'en prend qu'un et on évitera les faux problèmes. Mais bon, c'est un détail, qui peut le plus peut le moins, on peut prendre le trio standard ça ne me gênerait pas plus que ça.
Par ailleurs, je réitère ce que je disais, que la production des zip à partir des tags comme le fait Github me parait la meilleure alternative à archivelist.txt
Pour ma part, je réitère ça depuis 3 ans !
Committo,Ergo:Sum
Le 29/08/2013 22:07, Cédric Morin a écrit :
On veut un zip : on pose un tag, et c'est tout, c'est sans ambiguité.
On est sur de pas distribuer quelque chose qui bouge, sans le vouloir,
d'envoyer dans la nature des commit pas ou insuffisamment testé de
manière involontaire, et ça permet de produire un zip sur une version
dev si on le veut (version alpha par exemple) sans avoir à faussement
dire que ce n'est pas une version de dev pour arriver à ça.
Personnellement je ne comprends absolument pas ce principe. Lorsque je veux produire un zip automatique, je veux absolument que chaque correction de bugs, lorsque Z change (dans X.Y.Z), soit inclus dans l'archive au prochain passage du robot. C'est justement un des grands intérêts de l'automatisme. Si à chaque fois que l'on change Z, il faut ensuite copier le dossier dans un tag, autant produire le zip soi-même, ça va tout aussi vite.
Lorsque je crée une branche, au moins Z ne fait pas partie du nom de la branche ("branches/v1.1/"), et parfois même Y non plus ("branches/v1/"). Ainsi, dès qu'il y a une correction de bug, ou un ajout fonctionnel qui ne casse pas la compatibilité de la branche, le zip qui pointe sur cette branche contient automatiquement les dernières modifs.
--
RastaPopoulos
Le 29.08.13 23:16, RastaPopoulos a écrit :
Le 29/08/2013 22:07, Cédric Morin a écrit :
On veut un zip : on pose un tag, et c'est tout, c'est sans ambiguité.
On est sur de pas distribuer quelque chose qui bouge, sans le vouloir,
d'envoyer dans la nature des commit pas ou insuffisamment testé de
manière involontaire, et ça permet de produire un zip sur une version
dev si on le veut (version alpha par exemple) sans avoir à faussement
dire que ce n'est pas une version de dev pour arriver à ça.Personnellement je ne comprends absolument pas ce principe. Lorsque je
veux produire un zip automatique, je veux absolument que chaque
correction de bugs, lorsque Z change (dans X.Y.Z), soit inclus dans
l'archive au prochain passage du robot. C'est justement un des grands
intérêts de l'automatisme. Si à chaque fois que l'on change Z, il faut
ensuite copier le dossier dans un tag, autant produire le zip soi-même,
ça va tout aussi vite.Lorsque je crée une branche, au moins Z ne fait pas partie du nom de la
branche ("branches/v1.1/"), et parfois même Y non plus ("branches/v1/").
Ainsi, dès qu'il y a une correction de bug, ou un ajout fonctionnel qui
ne casse pas la compatibilité de la branche, le zip qui pointe sur cette
branche contient automatiquement les dernières modifs.
je plussoie.
--
Maïeul
Bonsoir,
(Étant en "vacances" hors territoire français, je suis la conversations tardivement)
Je rejoins un peu rastapopoulos. Si on va sur branches, The et trunk, je vois le fonctionnement de cette façon:
- branches contient les versions X du plugin. (V0, v1, v2,etc.)
- tags contient les versions x.y.z "figées" qui généreront les zip. A cela il faudrait trouver un moyen pour smart-paquets pour qu'il génère le dernier 0.y.z, 1.y.z, 2.y.z, etc.
- trunk, la version de développement. Quelle soit stable ou pas. Quant on fige qqch, on balance dans branches/vX/ puis dans tags/vX.Y.Z et smart-paquets génère tout ça comme un grand.
Soit smart-paquets générera un zip avec préfixe-x.y.z et SVP affichera le dernier de la branche x au besoin, soit smart-paquets ne générera que préfixe-x pour chaque tags.
En tout cas, c'est ainsi que je vois la conversation jusqu'à maintenant… et donc, plus de archivelist.txt pour la génération d'archives. Tags gérant tout ça (avec l'aide de smart-paquets retravaillé).
Cela qu'on soit en SPIP 1.9, SPIP 2.0, SPIP 2.1, SPIP 3.0, etc. La, c'est plugins.spip.net qui gère les xml adéquates pour chaque version "majeure" de SPIP.
Voili voilou ma pensée du soir. 
---------
Ybbet
Le 29 août 2013 à 23:16, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 29/08/2013 22:07, Cédric Morin a écrit :
On veut un zip : on pose un tag, et c'est tout, c'est sans ambiguité.
On est sur de pas distribuer quelque chose qui bouge, sans le vouloir,
d'envoyer dans la nature des commit pas ou insuffisamment testé de
manière involontaire, et ça permet de produire un zip sur une version
dev si on le veut (version alpha par exemple) sans avoir à faussement
dire que ce n'est pas une version de dev pour arriver à ça.Personnellement je ne comprends absolument pas ce principe. Lorsque je veux produire un zip automatique, je veux absolument que chaque correction de bugs, lorsque Z change (dans X.Y.Z), soit inclus dans l'archive au prochain passage du robot. C'est justement un des grands intérêts de l'automatisme. Si à chaque fois que l'on change Z, il faut ensuite copier le dossier dans un tag, autant produire le zip soi-même, ça va tout aussi vite.
Lorsque je crée une branche, au moins Z ne fait pas partie du nom de la branche ("branches/v1.1/"), et parfois même Y non plus ("branches/v1/"). Ainsi, dès qu'il y a une correction de bug, ou un ajout fonctionnel qui ne casse pas la compatibilité de la branche, le zip qui pointe sur cette branche contient automatiquement les dernières modifs.
--
RastaPopoulos----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Ah et je reviens sur une chose.
On pourrait limiter a tags/ et branches/.
Branches/ peut évoluer encore selon la découverte de bug ou ajout de petites fonctionnalités et compatibilités SPIP.
On pose un tag dans tags/x.y.z quand stabilisé dans branches/.
Plus la peine d'avoir trunk en fait. Parce que comment debuguer une version "spip2" si l'archive est sur branches/v1 ?
Si une nouvelle version de SPIP sort (actuellement SPIP 3.0), et que la branche v1 correspond a SPIP 2, on réécrit le plugin v1 avec les APIs de SPIP 3 sans rajout de fonctionnalités. On passe a y+1. Soit dans tags vX.Y+1.0.
Si on rajoute des fonctionnalités majeures, on passe a vX+1.0.0
Donc, pour ma part, lors d'un passage a une version majeure de SPIP, on ne fait que réécrire le plugin avec le APIs standards de la nouvelle version. Puis on ajoute les fonctionnalités voulues.
Utoqipues… ouais, ok 
----------
Ybbet
Le 29 août 2013 à 23:45, Ybbet SPIP <teddy.spip@gmail.com> a écrit :
Bonsoir,
(Étant en "vacances" hors territoire français, je suis la conversations tardivement)
Je rejoins un peu rastapopoulos. Si on va sur branches, The et trunk, je vois le fonctionnement de cette façon:
- branches contient les versions X du plugin. (V0, v1, v2,etc.)
- tags contient les versions x.y.z "figées" qui généreront les zip. A cela il faudrait trouver un moyen pour smart-paquets pour qu'il génère le dernier 0.y.z, 1.y.z, 2.y.z, etc.
- trunk, la version de développement. Quelle soit stable ou pas. Quant on fige qqch, on balance dans branches/vX/ puis dans tags/vX.Y.Z et smart-paquets génère tout ça comme un grand.
Soit smart-paquets générera un zip avec préfixe-x.y.z et SVP affichera le dernier de la branche x au besoin, soit smart-paquets ne générera que préfixe-x pour chaque tags.En tout cas, c'est ainsi que je vois la conversation jusqu'à maintenant… et donc, plus de archivelist.txt pour la génération d'archives. Tags gérant tout ça (avec l'aide de smart-paquets retravaillé).
Cela qu'on soit en SPIP 1.9, SPIP 2.0, SPIP 2.1, SPIP 3.0, etc. La, c'est plugins.spip.net qui gère les xml adéquates pour chaque version "majeure" de SPIP.Voili voilou ma pensée du soir.
---------
YbbetLe 29 août 2013 à 23:16, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 29/08/2013 22:07, Cédric Morin a écrit :
On veut un zip : on pose un tag, et c'est tout, c'est sans ambiguité.
On est sur de pas distribuer quelque chose qui bouge, sans le vouloir,
d'envoyer dans la nature des commit pas ou insuffisamment testé de
manière involontaire, et ça permet de produire un zip sur une version
dev si on le veut (version alpha par exemple) sans avoir à faussement
dire que ce n'est pas une version de dev pour arriver à ça.Personnellement je ne comprends absolument pas ce principe. Lorsque je veux produire un zip automatique, je veux absolument que chaque correction de bugs, lorsque Z change (dans X.Y.Z), soit inclus dans l'archive au prochain passage du robot. C'est justement un des grands intérêts de l'automatisme. Si à chaque fois que l'on change Z, il faut ensuite copier le dossier dans un tag, autant produire le zip soi-même, ça va tout aussi vite.
Lorsque je crée une branche, au moins Z ne fait pas partie du nom de la branche ("branches/v1.1/"), et parfois même Y non plus ("branches/v1/"). Ainsi, dès qu'il y a une correction de bug, ou un ajout fonctionnel qui ne casse pas la compatibilité de la branche, le zip qui pointe sur cette branche contient automatiquement les dernières modifs.
--
RastaPopoulos----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Yo,
Le 29 août 2013 22:10, Arnaud Bérard <arnaud.berard@mister-graphx.com> a
écrit :
Si,si j'aime bien débattre, justement sinon je la ramènerais pas aussi
souvent
paquets sur et validés (ce qui est pour moi le point le plus important,
plus que la simplicité d'utilisation du dépôt),
Oui je sais que tu as déjà posé la question et je ne pense pas que la
réponse soit dans un outil quel qu'il soit. Il peut y en avoir de plus ou
moins pratique ou favorable et peut-être que c'est le cas du fonctionnement
de Github sur les zips mais je vois pas en quoi ça m'assure de son contenu.
Écrire un code portable et générique comme tu le disais, demande aussi de
l'expérience, du partage de compétences, des retours et conseils (pas des
critiques ou reproches), et surtout du temps, ce qui n'est pas toujours
facile a combiner. Mes considérations sur GitHub allaient dans ce sens, car
pour moi et a mon petit niveau c'est l'outil idéal pour proposer des idées,
peut être jetées en vrac, mais qui peuvent êtres illustrées concrètement,
et discutées avec les outils adéquats, sans pourrir le dépôt principal (ici
la zone). Je pense que plutôt que de commiter des plugins a l'arrache ou
des embryons (comme il m'est arrivé de le faire) et de discuter après, un
espace comme GitHub devrait être plus souvent utilisé, ce qui n'était pas
hors sujet complet rapport a la gestion des répertoires de la zone.
Je ne sais qu'une chose sur ce sujet. Si on changeait d'outil sans
réfléchir au préalable sur le fonctionnement collaboratif qu'on souhaite
mettre en place, ça serait pour moi un échec.
L'outil je m'en tape un peu pour peu que je puisse l'appréhender sans
devoir changer de métier.
++
Eric
Le 29 août 2013 à 23:16, RastaPopoulos <rastapopoulos@spip.org> a écrit :
Le 29/08/2013 22:07, Cédric Morin a écrit :
On veut un zip : on pose un tag, et c'est tout, c'est sans ambiguité.
On est sur de pas distribuer quelque chose qui bouge, sans le vouloir,
d'envoyer dans la nature des commit pas ou insuffisamment testé de
manière involontaire, et ça permet de produire un zip sur une version
dev si on le veut (version alpha par exemple) sans avoir à faussement
dire que ce n'est pas une version de dev pour arriver à ça.Personnellement je ne comprends absolument pas ce principe. Lorsque je veux produire un zip automatique, je veux absolument que chaque correction de bugs, lorsque Z change (dans X.Y.Z), soit inclus dans l'archive au prochain passage du robot. C'est justement un des grands intérêts de l'automatisme. Si à chaque fois que l'on change Z, il faut ensuite copier le dossier dans un tag, autant produire le zip soi-même, ça va tout aussi vite.
Il "suffit" que ce soit le tag qui contient "Z".
Lorsque je crée une branche, au moins Z ne fait pas partie du nom de la branche ("branches/v1.1/"), et parfois même Y non plus ("branches/v1/"). Ainsi, dès qu'il y a une correction de bug, ou un ajout fonctionnel qui ne casse pas la compatibilité de la branche, le zip qui pointe sur cette branche contient automatiquement les dernières modifs.
Il me semble que la convention la plus courante de développement en branches est que ces branches servent à tous les nouveaux développements —bugfix, évolutions déjà bien spécifiés, explorations, etc.—, avec des commits potentiellement nombreux et sur une période plus ou moins longue, et si ces développements sont valables les branches sont "redescendues" dans le trunk quand elles sont stabilisées. Les tags sont faits à partir de ce trunk. Les branches ne sont pas du tout liées à une notion de version courante ou à venir.
Dans les best practices SVN c'est ce qui est appelé "The Always-Branch system" :
http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html
Mais c'est clairement plus simple à gérer avec Git que SVN…
-Nicolas
--
Nicolas Hoizey
Mon blog : http://gasteroprod.com/
Mon jeu : http://esviji.com/
Non, la je ne parle pas d’outil justement, je passerais pas a git ou mercurial svn me convient très bien. Je parle bien de procédure et de logique. Tout les dépots hors zone sont fait en /trunc et /tags mais pas sur la zone ! la plupars des plugins sont inscrit dans archivelist.txt depuis le répertoire /trunc c’est a dire le répertoire de travail, en gros pour moi c’est comme un mécano qui répare un moteur avec le moteur qui tourne. Donc en gros a pars cette « mauvaise » habitude je ne vois pas ce qu’il peut y avoir a changer. Quand je pose un Tag sur mon Dépot, il m’arrive d’y envoyer aussi a l’arrache (oui je fais un peut souvent du quick & dirty) une correction sans pour autant incrémenter, mais on peut envisager d’avoir un /tag/1.1 ou on incrémente les correctifs 1.1.1 dans le paquet.xml, … , pendant que dans le trunc on prépare la /1.2.0 ceci ne change rien a svp, smart-paquet et ne necessite que de la bonne volonté, voir logique, sans avoir a tout ré-écrire et repenser, alors que c’est déjà très bien fait. Après faire une spip-forge qui serait identique a GitHub et proposerais des outils collaboratifs aussi bien conçut, pourquoi pas ça éviterais de jongler entre le carnet, IRC, les forums, les listes … mais ç’est une autre histoire et pas le sujet. A++ Arnaud B.
Hello,
Le 01/09/2013 10:37, Eric a écrit :
Donc oui, générer les zips de façon plus automatique me plait bien, les
générer de façon "brutale" comme c'est proposé me satisfait pas. Mais je
ne sais pas si il existe une solution simple à ma demande qui évite de
mettre les mains dans le cambouis d'un archivelist.
Ben oui c'est ça l'intérêt du archivelist : le fait qu'il y ait des regroupements logiques, au sens humain, c'est-à-dire qu'il y a un ou plusieurs humains qui choisissent de placer tel plugin dans tel regroupement (regroupement qui n'a rien à voir avec la catégorie). Du coup ça permet de savoir s'il faut générer souvent ou pas ces paquets *avant* même d'avoir parcouru les dossiers des plugins et leur XML (si jamais on compare ça à un autre système où il faudrait à chaque fois tout rescanner pour savoir si le truc est "vieux", obsolète, ou autre).
--
RastaPopoulos
Téléchargements - Plugins SPIP
qui a vocation à remplacer files.spip.org/spip-zone car elle donne,
contrairement à files, toutes les informations utiles sur un zip et permet
de filtrer le contenu. Cependant je pense qu'elle n'est pas très utilisée.
Comme beaucoup, je connaissais pas et donc n'utilise pas.
Est-il possible de faire une redirection automatique ? (je vois cette
solution pour l'instant parce-que sur contrib --et sûrement ailleurs
sur la toile-- beaucoup de liens pointent vers files... )
Le 1 sept. 2013 à 10:37, Eric a écrit :
En fait, aujourd'hui on a juste distingué :
- les plugins du core
- plugins de zone
- les contributions qui ne sont pas des plugins et qui sont diront nous plutôt "historiques" pour certaines ou un catalogue de thèmes pour les plus utilisées.Néanmoins, il y a toujours la possibilité d'utiliser cette souplesse pour affiner ces sous-ensembles pour des raisons de performances de génération des zips, de présentation des infos ou de filtrage des infos comme c'est le cas dans cette page actuellement :
Téléchargements - Plugins SPIP
qui a vocation à remplacer files.spip.org/spip-zone car elle donne, contrairement à files, toutes les informations utiles sur un zip et permet de filtrer le contenu. Cependant je pense qu'elle n'est pas très utilisée.
Je ne la connaissais pas et elle est effectivement beaucoup mieux de files.spip.org (j'étais intervenu sur ce squelette sans être satisfait du résultat d'ailleurs). Pourquoi ne pas remplacer ce squelette par une redirection vers ton URL ? (A tiens le mail de Gildas vient d'arriver le temps que j'écrive ce mail).
Donc je prône depuis longtemps le fait de repenser ces dépôts logiques par exemple avec un dépôt pour les zips plutôt obsolètes qui n'ont pas vocation à être générés tous les jours, ou les zips instables pour répondre à l'interrogation de certains users...
J'al l'impression qu'on mélange deux choses: la production des Zip, et la production des fichiers archivelist. Cette dernière est pour l'instant manuelle, tout le monde écrit dedans en respectant les directives données ici:
Si maintenant on dit qu'il n'est plus nécessaire de manipuler ce fichier, du moment que vous respectez des conventions d'organisation de votre répertoire sur la zone (trunk etc), c'est pas plus compliqué, ça évite le problème des accès concurrents, et il suffit décrire un Cron pour le produire.
en l'état donner la liste permet simplement de faire le tri à priori mais a la contrainte justement de définir cette liste (qui la définit, comment on la garde cohérente...).
Donc oui, générer les zips de façon plus automatique me plait bien, les générer de façon "brutale" comme c'est proposé me satisfait pas. Mais je ne sais pas si il existe une solution simple à ma demande qui évite de mettre les mains dans le cambouis d'un archivelist.
Je comprends le besoin en théorie, mais je ne vois pas en quoi archivelist.txt y répond dans son état actuel. Les stats du répertoire de premier niveau pour les entrées de ce fichier donnent:
886 _plugins_
110 _themes_
84 _squelettes_
44 tags
7 _grenier_
3 _galaxie_
C'est quoi la rationnalité de ces choix ? C'est quoi sont intérêt en pratique ?
Ce qui me paraîtrait utile éventuellement, c'est un Zip qui contiendrait un plugin donné plus tout ceux dont il a besoin pour fonctionner (ses dépendances et au-delà par transitivité). Mais là je ne vois pas.
Committo,Ergo:Sum
Le 29/08/2013 17:12, Arnaud Bérard a écrit :
Le débutant dont on est entrain de parler, il a une mutu spip sur serveur dédié quand on lit les messages de la liste user ça me parait plus balaise qu'un coup de svn ou la peur du mot /trunk .. non ??
ben non , j'ai vraiment peur de ce truc ............... pb de doc et de courage :-[
faudrait que je retrouve la doc que j'ai eu en son temps lors de mon inscription pour avoir un accès a la zone
d'ailleurs si quelqu'un a ça sous le coude, parce-que je retrouve pas
pb de l'amateur qui ne sait pas encore bien gérer les sauvegardes pfffffff
ceci dit moi je suis toujours autant paumé dans les repertoire des plugins quand j'utilise mon tortoise
- certain n'on pas de dossier
- d'autre des v1 v2 pourquoi pas les V3 ... afin que ça décolle <mode> jeux de mot</mode>
- d'autre des branches
- d'autres des versions de spip
et dans tous ça certain on des trunk
donc je rame pour mes chekout :-\
--
Merci beaucoup de vous interessé a ma problématique
Je suis réceptif a Un tuto, une idée, une piste, un bout de code
Le 29/08/2013 09:42, Committo, Ergo Sum a écrit :
Un des deux répertoires est donc superflu en Svn,
mais je pense que c'est l'idée d'un répertoire
qui ne bouge pas (Tags) qui l'est: le Zip joue déjà ce rôle,
oui !
ça ne sert à rien d'avoir en plus une version déballée sur un site,
qu'en plus on peut retrouver en faisant le "svn cp -r" quand on veut.
re oui.
pourquoi garder des trucs figés dans un outil comme svn ?
JL