Hello :)),
Ce titre juste pour proposer de déplacer les tags des plugins du core dans le répertoire tags/ au niveau root plutôt que de les laisser dans core/tags/.
En effet, quand on travaille avec la zone on doit rapatrier de plus en plus de fichiers inutiles étant donné qu’on ne modifie jamais ces tags.
Donc un petit svn mv ça vous direz ?
++
Eric
Errata : Ca vous dirait ?
D’un côté toi tu veux virer les tags dans le dossier tags/ pour avoir moins de choses à checkout
De l’autre Azerty proposait au contraire de reorganiser chaque plugin du core en /branches /trunk /tags pour pouvoir le synchroniser avec git
Dans la mesure où l’on gère actuellement les tags des plugins du core par lot (on tag tous les plugins d’un coup), ça ne colle ni avec l’un ni avec l’autre, et ça veut donc dire qu’il faut aussi revoir le processus de release.
Actuellement les tags du core sont deja dans un dossier dédié, et il est donc assez facilement evitable de les checkout.
Il faudra sans doute faire bouger l’organisation vers une arbo complète par plugin comme le propose Azerty, mais il faut gèrer la question des releases en même temps, on peut pas se contenter de tout chambouler et advienne que pourra.
Cédric
yop,
Hop,
Le 10/08/2013 13:58, Eric a écrit :
yop,
Le 10 août 2013 13:49, Cédric Morin <cedric@yterium.com> a écrit :
Actuellement les tags du core sont deja dans un dossier dédié, et il est
donc assez facilement evitable de les checkout.Euh surement, mais comment ?
Sur une zone locale il est possible d'exclure certains dossier d'un up comme ceci :
svn update --set-depth=exclude <foldername>
Lors d'un checkout c'est un peu plus lourd à gérer :
++
b_b
Re,
Pour les erreurs c’est :
alpha1/compresseur/lib/csstidy’:
svn: warning: W000000: Unable to connect to a repository at URL ‹ http://svn.github.com/Cerdic/CSSTidy.git ›
svn: warning: W200000: Error handling externals definition for ‹ tags/spip-3.0.0-rc/compresseur/lib/csstidy ›:
svn: warning: W000000: Unable to connect to a repository at URL ‹ http://svn.github.com/Cerdic/CSSTidy.git ›
At revision 74697.
svn: E205011: Failure occurred processing one or more externals definitions
* Eric tapuscrivait, le 10/08/2013 15:22:
Ca fait pas mal de temps que ça dure, y a pas un moyen d'éviter ça ?
Les URLs du repository ont changées :
Le problème, c'est que théoriquement, on n'est pas sensé faire de commits sur un tag (Debian n'aime pas ça).
Mais si le commit ne concerne qu'un external, est-ce que ça change la donne ?
--
RealET
Ciao
Le problème, c'est que théoriquement, on n'est pas sensé faire de commits
sur un tag (Debian n'aime pas ça).
Cela n'a rien à voir avec Debian. C'est uniquement une règle de bon
sens sur l'usage d'un outil de versionning tel que svn.
L'usage de trunk, branches, tags se base sur une convention, que
maintenant tout le monde ou prou respecte.
Par exemple on a une exception dans SPIP vu que trunk se nomme spip.
Dans le cas de svn, pour simplifier on peut considérer que tout est
fichier et que l'utilisateur a des droits de modification, création et
suppression sur l'ensemble de l'arboresence svn.
En simplifiant, la convention veut que :
-* trunk soit le répertoire contenant un développement à flux continu,
on pousse les modifications et on ne s'impose pas de principes de
stabilité.
-* branches contient les développement spécifiques. Selon les cas on
raisonne soit par fonctionnalités/besoin, soit par version (comme le
fait SPIP)
-* tags correspond à un instantané on prend une photo du développement
à un instant T, c'est un lien symbolique vers un numéro de commit.
Dans le cas de git, tout est objet. Lla convention est gérée pour
partie directement dans la technique même. Les tags sont biens des
raccourcis vers un commit donné.
Mais si le commit ne concerne qu'un external, est-ce que ça change la donne
?
Cela n'a rien à voir. Un svn external revient à faire un lien
symbolique entre un repertoire local et un dépot distant. On niveau
local on nomme le repertoire du nom du projet distant. Le projet
distant pouvant respecter lui même la convention. On reste donc
cohérent.
Le problème réside dans le fait qu'on utilise directement le dépot svn
comme source des paquets. Or svn ne devrait être utilisé que pour le
developpement et non pour la mise en production des sites. Ce ne sont
pas les même problématiques.
Comme le passif est important il est assez difficile de résoudre cela
simplement et de pouvoir isoler les 2 besoins sans tout casser.
Km
cam.lafit <at> azerttyu.net <cam.lafit <at> azerttyu.net> writes:
Le problème réside dans le fait qu'on utilise directement le dépot svn
comme source des paquets. Or svn ne devrait être utilisé que pour le
developpement et non pour la mise en production des sites.
Je ne comprends pas en quoi c'est un problème.
Quant à la réorganisation éventuelle des sources,
un point qu'on peut (pas forcément) prendre en considération
est la recommandation d'Ohloh de ne fournir que la branche Trunk
pour qu'il fasse son travail d'analyse.
Il a subitement renoncé à le faire pour spip-zone depuis 2 ans,
qui apparaît pour Ohloh comme un projet mort, ce qui est un peu dommage.
Hop,
Le 15/08/2013 12:27, Committo Ergo Sum a écrit :
Je ne comprends pas en quoi c'est un problème.
Quant à la réorganisation éventuelle des sources,
un point qu'on peut (pas forcément) prendre en considération
est la recommandation d'Ohloh de ne fournir que la branche Trunk
pour qu'il fasse son travail d'analyse.
Il a subitement renoncé à le faire pour spip-zone depuis 2 ans,
qui apparaît pour Ohloh comme un projet mort, ce qui est un peu dommage.
J'ai contacté le support de ohloh il y a quelques semaines et le problème est en cours de résolution :
https://www.ohloh.net/forums/10/topics/8482
L'indexation de la zone était bloquée car la zone était inaccessible lors d'un passage de leur robot.
++
b_b
Le 16 août 2013 à 11:10, Bruno Bergot a écrit :
Le 15/08/2013 12:27, Committo Ergo Sum a écrit :
Je ne comprends pas en quoi c'est un problème.
Quant à la réorganisation éventuelle des sources,
un point qu'on peut (pas forcément) prendre en considération
est la recommandation d'Ohloh de ne fournir que la branche Trunk
pour qu'il fasse son travail d'analyse.
Il a subitement renoncé à le faire pour spip-zone depuis 2 ans,
qui apparaît pour Ohloh comme un projet mort, ce qui est un peu dommage.J'ai contacté le support de ohloh il y a quelques semaines et le problème est en cours de résolution :
On avait déjà signalé le problème avec Camille il me semble, mais comme dit dans ce fil:
Looks like the fetch is progressing at approximately 250 commits per day. Hopefully will finish before winter sets in...
A little math: 28,535 divided by 250 = 114 days! What was I thinking??? Will finish before the end of November with fair sailing.
Et justement il y a eu un "unfair sailing" la dernière fois qui a fait que ça a capoté, car sur une durée pareille la probabilité d'un incident qui oblige à tout recommencer n'est pas nulle. Mais ce qui intéressant avant tout c'est le regard que ça donne sur la question posée par Eric quant à l'organisation des sources. Y a-t-il un sens à parler du "projet SPIP-Zone" ? En terme de communauté peut-être, en terme de produit unique certainement pas (dans l'état actuel de son fonctionnement du moins). Actuellement il serait plus logique d'avoir un Trunk par sous-projet (chaque plugin, chaque point de la galaxie etc, c'est déjà le cas pour 30% d'entre eux environ), les déclarer chacun dans Ohloh et en retirer Spip-Zone. Maintenant on peut aussi dire que la déclaration actuelle dans Ohloh reflète un but qu'il faudrait atteindre. Une fois de plus ce n'est pas un problème technique qui est à la base de la question, mais bien un comportement social.
Committo,Ergo:Sum
Hello
Je reviens là-dessus:
Le 16 août 2013 à 11:10, Bruno Bergot a écrit :
un point qu'on peut (pas forcément) prendre en considération
est la recommandation d'Ohloh de ne fournir que la branche Trunk
pour qu'il fasse son travail d'analyse.
Il a subitement renoncé à le faire pour spip-zone depuis 2 ans,
qui apparaît pour Ohloh comme un projet mort, ce qui est un peu dommage.J'ai contacté le support de ohloh il y a quelques semaines et le problème est en cours de résolution :
Je viens de faire un essai en déclarant le plugin AssociaSPIP à Ohloh, et en 1/2 journée il a analysé les 23 000 lignes de code et les 1000 commits de son tronc. La zone a 75 fois plus de commits, et pour le code ça doit être un facteur encore pire à cause justement des Tags qu'on demande à tort à Ohloh d'analyser. Je pense donc que ce nouvel essai va échouer lui aussi, et à supposer qu'il réussisse ses statistiques ne voudront rien dire précisément à cause des Tags dont les lignes de code seront vues comme autant de lignes de codes neuves (ce qui est long et de plus mensonger quant à la taille réelle du projet).
J'ai fait par ailleurs un autre essai, la création des répertoires trunk et branches dans un plugin (Plugonet), en faisant dedans:
a=$(ls); svn mkdir trunk; svn mv $a trunk; svn ci -m "Création du tronc"
Ca marche mais avec une grosse perte qu'on ne réalise pas tout de suite: quand on fait "svn log" dans le sous-répertoire trunk, l'historique se réduit à l'unique commit ci-dessus, et non à tout l'historique de développement initial.
Le bon plan apparement est plutôt de se placer dans le répertoire _plugins_, et pour un plugin X faire:
svn mv X trunk; svn ci -m Renommage; svn mkdir X; svn mv trunk X; svn ci -m "Création du tronc de X"
Mais je suppose qu'il n'y a pas beaucoup d'auteur de plugin qui ont tout le répertoire _plugins_ sur leur machine pour pouvoir faire ça. Ca milite donc pour que l'adoption systématique d'un tronc soit effectuée en une seule fois, par qui a une copie complète de ce répertoire.
Committo,Ergo:Sum
Le 27 août 2013 à 17:59, Committo,Ergo:sum a écrit :
J'ai fait par ailleurs un autre essai, la création des répertoires trunk et branches dans un plugin (Plugonet), en faisant dedans:
...
Ca marche mais avec une grosse perte qu'on ne réalise pas tout de suite: quand on fait "svn log" dans le sous-répertoire trunk, l'historique se réduit à l'unique commit ci-dessus, et non à tout l'historique de développement initial.
Le bon plan apparement est plutôt de se placer dans le répertoire _plugins_, et pour un plugin X faire:
...
Mais je suppose qu'il n'y a pas beaucoup d'auteur de plugin qui ont tout le répertoire _plugins_ sur leur machine pour pouvoir faire ça.
Finalement il y a un moyen de s'en tirer qui n'exige pas ça, c'est de faire la copie du répertoire uniquement en mode distant. Si le plugin X est à l'URL U, on se met dans le répertoire de X et on fait:
a=$(ls); svn cp U U/trunk; svn rm $a
Ca marche car Subversion a la précaution de répertorier le contenu de U avant de créer U/trunk, on ne rentre pas dans une boucle infinie.
Committo,Ergo:Sum
cam.lafit <at> azerttyu.net <cam.lafit <at> azerttyu.net> writes:
Le problème réside dans le fait qu'on utilise directement le dépot svn
comme source des paquets. Or svn ne devrait être utilisé que pour le
developpement et non pour la mise en production des sites.
Je ne suis vraiment pas d'accord avec ça.
Pourquoi mets-tu un interdit là-dessus ?
Comme le passif est important il est assez difficile de résoudre cela
simplement et de pouvoir isoler les 2 besoins sans tout casser.
Je viens de faire quelques statistiques voir si ce passif est si important.
Le répertoire /tags/ à la racine ne contient que 84 répertoires,
à comparer avec les 238 répertoires branches/ ou tags/
existants ailleurs sur la zone: ne pas utiliser le répertoire /tags/
à la racine est donc le comportement dominant.
Sur ces 84 répertoires, un seul a un fichier paquet.xml,
les autres ayant un fichier plugin.xml, ce qui semble indiquer que ce
/tags est de moins en moins utilisé.
Avec un grep de "<auteur>" sur ces fichiers plugin.xml et un nettoyage rapide,
on dénombre qu'il n'y a qu'une vingtaine d'auteurs à qui il faudrait demander
d'aller commiter ailleurs (et encore, 5 d'entre eux sont membres de spip-team).
De plus, sur ces 84 répertoires, seulement 45 figurent dans archivelist.txt
(plus 1 dans archivelist_autre.txt).
Enfin, 5 de ces 84 répertoires
n'ont pas de fichier plugin.xml à leur premier niveau.
L'un parce que ce n'est pas un plugin,
les 4 autres parce qu'ils ne respectent pas
l'intention du répertoire /tags en organisant des sous-sous-répertoires.
La palme revient à celui qui a comme sous-sous-répertoires
un nommé "truck" et l'autre "branche".
Donc planifier la disparition du répertoire /tags/ ne me semble pas devoir
déclencher l'apocalypse.
Committo, Ergo Sum
Committo, Ergo Sum <esj <at> rezo.net> writes:
La palme revient à celui qui a comme sous-sous-répertoires
un nommé "truck" et l'autre "branche".
je voulais écrire évidemment:
branches/ trunk/
Committo, Ergo Sum
Le problème réside dans le fait qu'on utilise directement le dépot svn
comme source des paquets. Or svn ne devrait être utilisé que pour le
developpement et non pour la mise en production des sites.Je ne suis vraiment pas d'accord avec ça.
Pourquoi mets-tu un interdit là-dessus ?
Moi reformulerais en disant que le problème réside en : on utilise le /trunk comme source des paquets,
ce qui est une grosse erreur de part le fait que le /trunk est par principe une version en cours de dev et donc pas stable par définition
la source des paquets devrait être un /tag c'est a dire un instantané d'une version stable et approuvé, testé (c'est pas moi qui le dit c'est la doc de svn chez tigris )
Personnellement c'est comme ça que j'ai dupliqué sur mon propre svn, les plugins de la zone que j'utilise,
pour ne pas subir certains reverse et commit , et que je génère mes paquets , quand je le décide.
Par exemple si je m'absente 3 semaine (sans internet ... le cauchemard quoi), j'ai pas un de mes sites ou quelqu'un fait une mise a jour depuis svp, et m’appelle pour me dire : ho c'est tout cassé la ils ont pas eut de maj, je rentre, j'update, je teste, je valide, je commit, je génère mes paquets et zou.
Bien entendu je parle des structure de sous rep des plugins, qui n'ont aucune cohérence entre eux, et dont beaucoup vont a l'encontre des "bonnes pratiques" svn.
Bonnes pratiques d'ailleurs si chère a la communauté spip mais pas pour svn apparemment ;-).
le /tag et j'insiste : est un instantané, a aucun moment il ne devrait être modifié par la suite. Dans la définition c'est gelé.il ne prend pas de poids vu qu'il n'aura pas d'historique svn.
Après on nettoie et on efface les tag obsolètes, genre une v1.0.0 quand on en est a la V3.50 ça sert plus a grand chose.Mais au moins quand on propose un paquets tout les devs ou intéressés on pu le tester le valider dans plusieurs contextes (hébergeurs, serveurs, version de php, ...) avant de la tagger et de modifier archivelist pour proposer aux utilisateurs la mise a jour.
Après le /branche peut ne pas être utile, c'est occasionnel et devrait être considéré comme le fork sur GitHub, un moyen de proposer un dev parralèle sans géner le travail et pouvoir faire un merge/pull par la suite, vers le trunk. Donc peut de plugins en auraient réellement besoin.
Sur ces 84 répertoires, un seul a un fichier paquet.xml,
Oui c'est bien dommage ! c'est du au fait que beaucoup d'après ce que j'ai compris ne veulent pas quitter la compat spip2 et du coup, ben ça avance pas et ça fait de la ligne de code ou on passe la moitié du temps a faire du if version ou truc dans le genre.
Personnellement je dégage tout pour y voir plus clair dès que j'ai un soucis avec un plugin : moins y'a de ligne mieux ça marche chez moi en tout cas.
Pour le seul site qu'il me reste pour spip2 , j'ai taggè et il ont des correctifs si besoins mais plus d'évolutions de fonctionnalités (justement pour les emmener vers l'avant). Pour le reste j'ai pas de plugin.xml ça m'évite d'oublier de reverser un nécessite ou un schema dans un des deux, et ça me permet de savoir direct si c'est un plugin spip2 ou 3.
Je fais du svn en ligne de commande juste pour mes scripts sh (rapatrier une distrib spip, nouveau projets, mise en prod ..), sinon j'ai un soft pour le tout les jours ce que je trouve plus confortable (même si mon terminal est ouvert au lancement , hein ho ^^ ),
bref, quand je crée un dossier sur un dépôt le premier truc qu'il me demande c'est :
voulez vous créer la structure /branche,/tag,/trunk et la bêtement je dis oui , et comme il est gentil il me fait ça tout bien 
donc du coup je commence toujours ainsi, car chaque projet ou j'ai démarré direct dans le dossier, j'ai du par la suite modifier la structure et revenir a au moins /tag,/trunk, en me tappant create, move, etc.. donc l'arbo minimal reste trunk & tags
Au final ça me parais quand même un soucis que les paquets soient générés depuis le trunk pour la plupart, je ne trouve pas que ce soit une procédure correcte surtout quand on sait que les paquets sont générés via un cron et que une boulette peut se retrouver en prod, très peut de users lambda font des test en local et la plupart travaillent sur leur site en prod (et oui y'en as qu'ont pas peur).
Donc plutôt que de dire marre des tags, je dirais mettons nous au tags
Mon humble avis sur cette question épineuse ...
A++
Arnaud B.
Le 28/08/13 23:38, Committo, Ergo Sum a écrit :
cam.lafit <at> azerttyu.net <cam.lafit <at> azerttyu.net> writes:
Le problème réside dans le fait qu'on utilise directement le dépot svn
comme source des paquets. Or svn ne devrait être utilisé que pour le
developpement et non pour la mise en production des sites.Je ne suis vraiment pas d'accord avec ça.
Pourquoi mets-tu un interdit là-dessus ?Comme le passif est important il est assez difficile de résoudre cela
simplement et de pouvoir isoler les 2 besoins sans tout casser.Je viens de faire quelques statistiques voir si ce passif est si important.
Le répertoire /tags/ à la racine ne contient que 84 répertoires,
à comparer avec les 238 répertoires branches/ ou tags/
existants ailleurs sur la zone: ne pas utiliser le répertoire /tags/
à la racine est donc le comportement dominant.Sur ces 84 répertoires, un seul a un fichier paquet.xml,
les autres ayant un fichier plugin.xml, ce qui semble indiquer que ce
/tags est de moins en moins utilisé.Avec un grep de "<auteur>" sur ces fichiers plugin.xml et un nettoyage rapide,
on dénombre qu'il n'y a qu'une vingtaine d'auteurs à qui il faudrait demander
d'aller commiter ailleurs (et encore, 5 d'entre eux sont membres de spip-team).De plus, sur ces 84 répertoires, seulement 45 figurent dans archivelist.txt
(plus 1 dans archivelist_autre.txt).Enfin, 5 de ces 84 répertoires
n'ont pas de fichier plugin.xml à leur premier niveau.
L'un parce que ce n'est pas un plugin,
les 4 autres parce qu'ils ne respectent pas
l'intention du répertoire /tags en organisant des sous-sous-répertoires.
La palme revient à celui qui a comme sous-sous-répertoires
un nommé "truck" et l'autre "branche".Donc planifier la disparition du répertoire /tags/ ne me semble pas devoir
déclencher l'apocalypse.Committo, Ergo Sum
----
spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone
Le 29/08/2013 05:30, Arnaud Bérard a écrit :
Le problème réside dans le fait qu'on utilise directement le dépot svn
comme source des paquets. Or svn ne devrait être utilisé que pour le
developpement et non pour la mise en production des sites.Je ne suis vraiment pas d'accord avec ça.
Pourquoi mets-tu un interdit là-dessus ?Moi reformulerais en disant que le problème réside en : on utilise le /trunk comme source des paquets,
ce qui est une grosse erreur de part le fait que le /trunk est par principe une version en cours de dev et donc pas stable par définition
la source des paquets devrait être un /tag c'est a dire un instantané d'une version stable et approuvé, testé (c'est pas moi qui le dit c'est la doc de svn chez tigris )
ah merdum moi qui croyais que trunk c'été pour la version spip 3
parce que dans branche on a bien des numéro de version de spip 3.0.0
si on creuse on a un peu n'importe quoi du v1 , v2 ou bien la version de spip, ou bien rien du tout
difficile de comprendre pour un autodidacte
--
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
Arnaud Bérard <arnaud.berard <at> mister-graphx.com> writes:
le /tag et j'insiste : est un instantané, a aucun moment il ne devrait
être modifié par la suite.
....
Après le /branche peut ne pas être utile, c'est occasionnel et devrait
être considéré comme le fork sur GitHub
La première chose à dire est qu'en Svn,
Tags et Branches sont en fait la même chose,
c'est justement son point faible par rapport à Git,
J'ai essayé d'utiliser les branches en Svn sur le mode Git,
j'ai renoncé tant c'est lacunaire
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,
ç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.
Le Branches me paraît au contraire indispensable, car il gèle une version
en tant qu'ensemble de fonctionnalité décrit par une documentation,
mais il doit pouvoir être changé quand on découvre un bug,
et provoquer la production d'un Zip remplaçant l'ancien.
Mais bon, on peut permuter les noms, l'essentiel n'est pas le nom.
Par ailleurs, je ne crois pas que l'apparition d'une version
avec de nouvelles fonctionnalités
doive provoquer la disparition des précédentes:
il y a régulièrement des gens qui demandent une vieille version
car leur environnement de travail les y contraint.
Au final ça me parais quand même un soucis que les paquets soient
générés depuis le trunk pour la plupart
Plus exactement, il faut dire que sur les 1308 Zip produits par smart-paquets,
seulement 305 viennent d'un répertoire nommé "branches" (252) ou "tags" (53).
Pour le millier restant, il y a explicitement trunk pour 203 d'entre eux,
les autres sont des trunk qui ne disent pas leur nom.
Le pb de départ est ce mauvais nommage,
la production du Zip n'en est qu'une conséquence.
je ne trouve pas que ce soit
une procédure correcte surtout quand on sait que les paquets sont
générés via un cron
Quand Eric et moi avons défini la DTD des paquets.xml et ses conséquences
sur smart-paquets, on avait souhaité aller jusqu'à la disparition des fichiers
archivelist.txt, l'idée étant que tout répertoire contenant un paquet.xml
ou un plugin.xml (éventuellement en tenant compte de la valeur de "etat" dedans)
était éligible au ZIp. On a renoncé parce que l'organisation de la Zone est trop
le bazar, mais je pense toujours qu'on devrait être plus directifs
(i.e. imposer la création truck + branches et/ou tags)
pour pouvoir faire ça et du coup éviter les mauvaises manip sur ces fichiers Txt
auxquels tout le monde accède n'importe quand.
Committo, Ergo Sum
spip.factory <at> laposte.net <spip.factory <at> laposte.net> writes:
ah merdum moi qui croyais que trunk c'été pour la version spip 3
parce que dans branche on a bien des numéro de version de spip 3.0.0
si on creuse on a un peu n'importe quoi du v1 , v2 ou bien la version de
spip, ou bien rien du tout
difficile de comprendre pour un autodidacte
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
Merci de confirmer ainsi ce que j'essaye de faire comprendre depuis longtemps:
imposer un cadre arbitraire n'est pas forcément un acte d'autorité insupportable,
mais au contraire ici un moyen de garantir que le travail effectué
par les nouveaux venus sera intégré à coup sûr et sans dommages.
Committo, Ergo Sum