j'ai créé les tags sur saisies et formidable avec l'outil de création retrospective de Camille. Ca marche nickel !
Pourquoi j'ai fait cela? Pour pouvoir remonter facilement à des vieilles versions des plugins si on me signale un bug qui apparait entre 2 versions
Par contre, je viens de de m'apercevoir qu'avec la synchro svn
1) ca faisait un paquet de commit svn d'un coup > du coup beaucoup de commit d'un coup
2) et shiraz devient folle avec un paquet de commit d'un coup. Elle a tourné en rond puis est partie. Si quelqu'un peut regarder si elle tourne pas encore en rond
Je tiens donc à m'excuser pour cela.
A l'avenir il me semble que pour les plugins ayant beaucoup de version, la création retrospective n'est pas idéale (tant qu'il y une synchro svn), car cela fait un flood.
Pour autant, je maintiens qu'il est bon d'avoir des tags de toutes les versions officiellement sortie. Donc ma question est: comment permettre cela en évitant le flood ?
Par ailleurs, il me semble qu'à l'avenir, ce serait une bonne chose de poser au fur et à mesure les tags, vu que c'est bien plus simple en git qu'en svn. A moins qu'on se serve de l'outil de Camille pour faire un hook de post push et le faire automatiquement ? Mais je ne suis pas sur que ce soit une bonne idée.
Pour moi ce n'est pas le flood qui pose un problème mais l'approche elle même.
Et non je ne vois l'intérêt de ce système de versionnement systématique alors qu'on a tous les moyens de restaurer la versions qu'on veut.
Je pense qu'il faut qu'on en discute avant de balancer un truc comme ça surtout quand on est en train de migrer la zone sous git.
Le gogogo a des limites surtout quand cela est une pratique qui nécessite une discussion.
++
Eric
sans le flood, je vois pas ce qui poserait problème d'avoir des tags cohérents avec l'historique? C'est une pratique adapté par tous les logiciels un peu sérieux de taguer les releases.
que cela puisse attendre, je veux bien (on est plus à cela près).
mais je suis désolé, "tous les moyens de restaurer la version qu'on veut", c'est reparcourir l'historique. donc c'est pas franchement idéal. Les cas d'usages sont limités, j'en conviens
Pour autant, je maintiens qu'il est bon d'avoir des tags de toutes les versions officiellement sortie. Donc ma question est: comment permettre cela en évitant le flood ?
Amah, maintenant que la transition git est lancée, il faudrait brancher les mails sur git et non plus svn, mais ce n'est pas possible tant que tous les plugins ne sont pas sous git (ou qu'on n'a pas fermé l'accès svn). Sans quoi, on passerait à côté de commits en svn sur des plugins non dispos en git.
Par ailleurs, il me semble qu'à l'avenir, ce serait une bonne chose de poser au fur et à mesure les tags, vu que c'est bien plus simple en git qu'en svn. A moins qu'on se serve de l'outil de Camille pour faire un hook de post push et le faire automatiquement ? Mais je ne suis pas sur que ce soit une bonne idée.
Une bonne pratique oui, mais un hook bof, il faut se méfier des automatismes qui peuvent devenir contre-productifs.
que cela puisse attendre, je veux bien (on est plus à cela près).
Ça va non ? Tu trouves que les choses n'avancent pas "assez vite" ?
Amah, maintenant que la transition git est lancée, il faudrait
brancher
les mails sur git et non plus svn, mais ce n'est pas possible tant
que
tous les plugins ne sont pas sous git (ou qu'on n'a pas fermé l'accès
svn). Sans quoi, on passerait à côté de commits en svn sur des
plugins
non dispos en git.
oui
> Par ailleurs, il me semble qu'à l'avenir, ce serait une bonne chose
> de
> poser au fur et à mesure les tags, vu que c'est bien plus simple en
> git
> qu'en svn. A moins qu'on se serve de l'outil de Camille pour faire
> un
> hook de post push et le faire automatiquement ? Mais je ne suis pas
> sur
> que ce soit une bonne idée.
>
Une bonne pratique oui, mais un hook bof, il faut se méfier des
automatismes qui peuvent devenir contre-productifs.
je suis d'accord
> que cela puisse attendre, je veux bien (on est plus à cela près).
Ça va non ? Tu trouves que les choses n'avancent pas "assez vite" ?
non c'est juste un constat empirique : on a fonctionné des années sanstags, donc rien n'est pressé.
Le fait de pouvoir tagguer coté git est en soit une bonne pratique (et
on aurait dû le faire aussi coté svn depuis longtemps). Ne pas le
faire ne pose pas pour autant de problème dans notre écosystème
actuel.
Que ce soit avec svn ou git, l'aspect flood ne changera pas si on
reprend un projet avec plein de version.
"Tu commites ? Le serveur notifie, point" et peut importe la nature du commit.
Pour le moment il n'y pas de grande valeur ajouter à tagguer les
projets vu qu'on n'a rien qui exploite cette fonctionnalité. Cela
pourrait arriver (ou non) mais on a déjà assez de quoi nous occuper
dans l'immédiat
Pour rappel le besoin initial de https://git.spip.net/spip-contrib-outils/creer_tags était de répondre
à la problématique de composer qui profite des tags git quand ils sont
présents. Le script a été fait de façon généralisable
On peut imaginer que cela pourrait servir à télécharger de zip tout
prêts mais on n'en ai pas encore là.
Le fait de pouvoir tagguer coté git est en soit une bonne pratique (et
on aurait dû le faire aussi coté svn depuis longtemps). Ne pas le
faire ne pose pas pour autant de problème dans notre écosystème
actuel.
Que ce soit avec svn ou git, l'aspect flood ne changera pas si on
reprend un projet avec plein de version.
"Tu commites ? Le serveur notifie, point" et peut importe la nature du commit.
bah en git un tag n'est pas un commit, c'est un objet différent (tag leger = une étiquette, tag annoté = un objet à part)
Pour le moment il n'y pas de grande valeur ajouter à tagguer les
projets vu qu'on n'a rien qui exploite cette fonctionnalité. Cela
pourrait arriver (ou non) mais on a déjà assez de quoi nous occuper
dans l'immédiat
oui bien sûr, je l'avais fait parce que j'étais présentement sur le projet formidabke, et que je voulais tester, mais je suis d'accord qu'il n'y a strictement aucune urgence (surtout si cela implique d'aussi grosses notifs)
> Que ce soit avec svn ou git, l'aspect flood ne changera pas si on
> reprend un projet avec plein de version.
> "Tu commites ? Le serveur notifie, point" et peut importe la nature du commit.
>
bah en git un tag n'est pas un commit, c'est un objet différent (tag
leger = une étiquette, tag annoté = un objet à part)
Si tu veux jouer sur les mots c'est ton droit mais faut pas pousser Maurice.
Tu pousses une information (peut importe laquelle) sur le serveur
central, il y a notification.
Après oui on peut jouer à faire un cours complet sur la nature même
des objets git et leur différences mais cela n'aura aucune pertinence
dans le cas présent. Et si on essaye d'avoir un vocabulaire
compréhensible pour la majorité même si cela implique des abus de
langage.
oui bien sûr, je l'avais fait parce que j'étais présentement sur le
projet formidabke, et que je voulais tester, mais je suis d'accord qu'il
n'y a strictement aucune urgence (surtout si cela implique d'aussi
grosses notifs)
C'est une bonne idée de vouloirs tester ce qui est proposé, (et je
suis content que le code fonctionne) mais il est autorisé de demander
avant quand on ne sait pas. Ou un moindre mal d'essayer sur un
périmètre maîtrisé.
Il me semble que vouloir tester sur un plugin comme formidable quand
on sait pas ce que cela va donner et pourquoi , c'est un peu comme
vouloir jouer avec un gros bouton rouge.
La différence entre git et SVN c’est qu’un tag c’est juste une etiquette sur un commit en git, alors qu’en SVN c’est une copie dans le file system.
Donc quand je vais svn up formidable ou saisies je me retrouve avec pléthore copies du plugin sur mon disque ce qui est franchement pénible.
Ce taggage automatique et restrospectif est donc à bannir tant qu’on est synchro avec la zone amha
