[SPIP Zone] Marre des tags !

Archives Zone
21

Le 29 août 2013 à 09:42, « Committo, Ergo Sum » <esj@rezo.net> a écrit :

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.

Je pense qu’à ce moment là, le mieux serait de faire comme github et de produire automatiquement un zip par tag.
Ça force donc à poser un tag pour chaque release/version que l’on veut déployer,
et ça a l’avantage d’être économique en ressource machine, car un tag ne bougeant pas (même si ce n’est qu’une convention sous SVN), cela simplifie grandement la production du zip et allègerait les ressources serveurs dédiées : soit le zip est là et il n’y a rien a faire, soit il n’existe pas et on le produit.

Github produit aussi automatiquement un zip du master (le trunk), a voir si c’est pertinent de le faire aussi…

Sinon pour l’historique, le choix initial de ne pas forcer les utilisateurs à créer des trunk/ branches/ et tags/ était surtout un soucis de simplifier au maximum l’apprentissage de ceux qui découvraient svn et le versioning.
Le fait est que cette question des trunk, branches et tags reste un problème pour les débutants, et plus généralement ceux qui ne sont pas à l’aise avec le versioning, qui s’y perdent constamment.
Cette question ne peut pas être évacuée d’un revers de manche, un des objectifs de la zone étant bien d’amener des utilisateurs non geek à partager et collaborer. Mais j’ai bien conscience que le bazar ambiant et la géométrie variable d’un dossier à l’autre ne rend pas les choses très lisibles et compréhensibles non plus.

Cédric

22

de toute manière le résultat est … je suis pas prés d’essayer de faire quoi que ce soit sur la zone en commit trop peur de casser un truc … ceci dit un cadre restrictif permet aussi d’aller tous dans le même sens, mais j’ai cru comprendre que Spip puise ça force dans le fait que chacun peu faire ce qu’il veut donc des que vous essayer de cadrer ou proposer un truc , ça taille dur (de la tendresse bordel) j’ai un souvenir d’une tentative de logo. on dirait que personne ne dirige officiellement mais que officieusement si , , , , , , , , , , , , , , , , , , , , , , , lu sur déjà que de récupérer quelque chose pour moi avec tortoise ou d’utiliser svn sur mon serveur est galère pour moi pourtant les 5 première page de google donne des pistes ceci dit je suis super content d’utiliser spip et de l’entraide que j’y trouve … (ça c’est parcequ’on est pas vendredi …)

23

Le 29/08/2013 10:29, Cédric Morin a écrit :

Le 29 août 2013 à 09:42, "Committo, Ergo Sum" <esj@rezo.net
<mailto:esj@rezo.net>> a écrit :

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.

Je pense qu'à ce moment là, le mieux serait de faire comme github et de
produire automatiquement un zip par tag.
Ça force donc à poser un tag pour chaque release/version que l'on veut
déployer,
et ça a l'avantage d'être économique en ressource machine, car un tag ne
bougeant pas (même si ce n'est qu'une convention sous SVN), cela
simplifie grandement la production du zip et allègerait les ressources
serveurs dédiées : soit le zip est là et il n'y a rien a faire, soit il
n'existe pas et on le produit.

Github produit aussi automatiquement un zip du master (le trunk), a voir
si c'est pertinent de le faire aussi...

Sinon pour l'historique, le choix initial de ne pas forcer les
utilisateurs à créer des trunk/ branches/ et tags/ était surtout un
soucis de simplifier au maximum l'apprentissage de ceux qui découvraient
svn et le versioning.
Le fait est que cette question des trunk, branches et tags reste un
problème pour les débutants, et plus généralement ceux qui ne sont pas à
l'aise avec le versioning, qui s'y perdent constamment.

Oh que oui : merci Cedric de cette préoccupation,
              qui doit pourtant bien vous emm... les pros !

Cette question ne peut pas être évacuée d'un revers de manche, un des
objectifs de la zone étant bien d'amener des utilisateurs non geek à
partager et collaborer. Mais j'ai bien conscience que le bazar ambiant
et la géométrie variable d'un dossier à l'autre ne rend pas les choses
très lisibles et compréhensibles non plus.

Est-il possible de rendre plus "present" l'organisation recommandée,
avec un vrai tutoriel (un nouveau que je n'ai pas vu ?),
avec la synthèse de cette discussion => dnas la Caverne de Tonton ??

Un qui n'ose meme pas tenter....
--
YannX

24

Le 29 août 2013 à 13:21, YannX/SPIP a écrit :

Est-il possible de rendre plus "present" l'organisation recommandée,

Ben justement le problème c'est qu'il n'y en a pas,
c'est bien le sujet de ce fil.
Pour ma part, j'ai dit pourquoi je pensais que /tags devrait être supprimé,
et que tout plugin sur la zone devrait avoir dans son répertoire uniquement
un répertoire "trunk", et un répertoire "branches",
mais comme on l'a vu ça ne fait pas l'unanimité.

D'autre part, comme je l'ai signalé, si on ne veut pas laisser croire
que son projet vient de démarrer, il ne faut pas créer le répertoire trunk
n'importe comment.

Committo,Ergo:Sum

25

Hop,

Le 29/08/2013 13:40, Committo,Ergo:sum a écrit :

Le 29 août 2013 à 13:21, YannX/SPIP a écrit :

Est-il possible de rendre plus "present" l'organisation recommandée,

Ben justement le problème c'est qu'il n'y en a pas,
c'est bien le sujet de ce fil.

Je crois qu'on a déjà souvent abordé le sujet de l'organisation trunk/branches. J'ai souvent posté un lien vers un petit article que j'avais rédigé à ce sujet (reste que parfois, et malgré des mails explicatifs de plusieurs personnes à ce sujet, les auteurs de plugins ne souhaitent pas suivre cette organisation).

Je vois aussi qu'on en cause sur la page d'accueil de la zone :

Des exemples en vidéo (environ 5mn chacune) :

     Episode 1) Création d'un nouveau projet, ajout au dépôt
     Episode 2) Ajout, modification, et suppression de fichiers/répertoires sous SVN
     Episode 3) Mise à jour de sa version de travail, fusion de modifications concurrentes
     Episode 4) Conventions standards trunk / tags / branches

Bon, manque de chance, ces vidéos ne semblent plus être en ligne (les joies des services externes ^^). Comme le proposait Camille il y a quelques temps déjà, il serait intéressant de déposer ces vidéos sur videos.spip.org :

http://comments.gmane.org/gmane.comp.web.spip.zone/13696

Donc si on "officialise" cette organisation sur la page d'accueil de la zone (et pourquoi pas dans la charte), il ne reste plus qu'à régler le problème des tags. Sur ce point je suis totalement d'accord pour les virer/déplacer/ce que vous voulez :slight_smile:

++
b_b

26

Hop

Cette question ne peut pas être évacuée d’un revers de manche, un des
objectifs de la zone étant bien d’amener des utilisateurs non geek à
partager et collaborer. Mais j’ai bien conscience que le bazar ambiant
et la géométrie variable d’un dossier à l’autre ne rend pas les choses
très lisibles et compréhensibles non plus.

Est-il possible de rendre plus « present » l’organisation recommandée,
avec un vrai tutoriel (un nouveau que je n’ai pas vu ?),
avec la synthèse de cette discussion => dnas la Caverne de Tonton ??

Un qui n’ose meme pas tenter…

Justement il faut tenter et oser !!! Au départ on m’as imposer subversion dans une entreprise/groupe, j’avais a l’époque mes petites sauvegardes sur mon ordi et je bossait en electron libre sans aucun suivi de version. On ne m’as pas laissé le choix et cela dit j’ai été heureux le jour ou mon disque dur a laché car la DSI nous achetait des pc pourris avec windows obligé (même pas le droit d’installer un Ubuntu : la tôle quoi). Maintenant je bosse tout seul et j’ai gardé cette habitude de travail qu’il faut voir comme un confort, pas comme une galère. Tu peut faire n’importe quoi tout est réversible (si le dépot est bien organisé et que les paquet ne sont pas générés depuis la ou tu as fait ta bourde : c’est du coup le débat qui est soulevé dans cette discussion, en plus de l’organisation logique).

Si il y a une chose qui est compliquée au débutant sur svn, ce n’est pas la notion de tag, trunk, branche je trouve : c’est de faire sont premier revert et revenir a une ancienne version quand beaucoup de révisions sont passées. Tout le monde arrive vite a faire son commit (envoyer sa modif), mais revenir et restaurer une révision est toujours une grande expérience la première fois. Penser a faire un update aussi ça s’oublie au départ et quand on veut envoyer, la on a son premier conflit de version (trop drôle lol).

Pour ce qui est de la structure conseillée et l’explication des termes tag,branche,trunk, j’insiste lourdement mais :

ont est bien d’accord ça peut permettre de tester une version de dev localement sans checkouter tout de suite si le projet/plugin n’interresse pas ou ne convient pas finalement. Et aussi si on as pas svn : par exemple un utilisateur peut tester un correctif sans avoir a faire un checkout, et confirmer que le correctif est bon et peut passer en version validée. J’utilise souvent quand je cherche un librairie ou un plugin jquery, des fois j’en fait 4 ou 5 avant de faire mon choix.Donc pourquoi pas, cela dit ça double le poid des files, peut être que ça peut être généré via une action genre clic comme sur sourceforge ou git.

27

Hello,

28

Le 29 août 2013 à 14:08, Bruno Bergot a écrit :

Je crois qu'on a déjà souvent abordé le sujet de l'organisation trunk/branches. J'ai souvent posté un lien vers un petit article que j'avais rédigé à ce sujet (reste que parfois, et malgré des mails explicatifs de plusieurs personnes à ce sujet, les auteurs de plugins ne souhaitent pas suivre cette organisation).

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. Et qu'on n'aille pas me dire que c'est plus difficile de faire ça que d'apprendre où est le fichier archivelist.txt, quelle est sa syntaxe et à quoi il sert, car c'est le contraire qui est vrai: dans un cas on demande à avoir un minimum de connaissances d'un outil universellement utilisé, dans l'autre il faut apprendre un fonctionnement spécifique à SPIP. Je pense même que cette posture "on n'en fait qu'à notre tête, vous n'avez qu'à vous plier" fait partie des mauvais points de SPIP.

Committo,Ergo:Sum

29

Bouhhh

Et bien, j'ai declenché des foudres, SYMPATHIQUES
- d'abord merci a B_b qui recherche et trouve des "vieilles infos"
- et bien sur aux deux reponses appliquées de Arnaud et Eric.

Oui, je n'ose meme pas tenter : j'ai pourtant un compte,
j'ai fait qq.essais sur le bac a sable,
j'ai meme charge un jour un truc.... mais

Je suis pas forcement du genre gogogogo si je sais pas
Meme Suske a essayé de m'interesser, alors...

Comprendre l'interet, c'est pas le pb. : j'aimerais,
car j'ai tendance deja a garder en local toutes mes modifs,
et un gestionnaire de versions serait bien mieux !

Ce que je veux dire sur ce sujet c'est :
- la difficulté de trouver la "bonne" information
     (recurrent sur SPIP, on sait mais...)

- les difficultes à gérer sous Windows (comme trop, je sais ;-(
   "comme sous Linux" (un tuto pour m'installer un SVN local ? )

- sans oublier la peur de "planter" tout le bouzin
   (j'ai proposé qq.mini-patchs a mesure, mais
   (sans les charger -sur SPIP ou Spip_loader )
   sans retours, je laisse le desinteret me reprendre !

Et cela donne l'impression d'un fonctionnement un peu "distant".....

Pour dire les choses simplement, je ressens que les "experts"
prefereraient presque redire 5 fois la meme chose à 5 demandes
(sur IRC, spip@rezo et forum) que de compléter l'article de réference.
(quand on le retrouve...: outre SPN, dont il manque 2 sections
je me suis meme fait des SPIP de liens vers les docs SPIP)

Et je regrette toujours que les echanges possibles entre
Contrib et Carnet ne soient pas plus mis en valeur.

Comme je suis -de fait- et je m'en excuse- tjrs un peu "provoc"
(le plus souvent involontairement dans la formulation),
je vais juste regretter aussi que Contrib ne soit pas
plus souvent "jardiné" ou "co-editoré" ; trop souvent,
on trouve plein de renseignements dans les multiples
msgs de forum, qui gagneraient à etre remontés dans l'article !
Est-ce "interdit" aux administrateurs de le faire ?

Peut-etre -/j'espere/- que je me trompe complètement,
ce n'est que le ressenti d'un ... à l'Ouest !

Le 29/08/2013 13:21, YannX/SPIP a écrit :

Le 29/08/2013 10:29, Cédric Morin a écrit :

Le 29 août 2013 à 09:42, "Committo, Ergo Sum" <esj@rezo.net

Un qui n'ose meme pas tenter....

PS peut-etre est-ce aussi parce que pour moi,
il est plus facile d'ecrire directement au clavier, de rédiger..
que d'ecrire trois lignes de HTML,
encore moins de PHP (et plus de Cobol :wink:

PPS et voyant les histories de !bang duckduckgo
cy_altern & denisb ont une arme secrète...
https://www.google.com/cse/home?cx=006670395242166965407:rjhbrr1gwro
--
YannX

30

Hop,

Le 29/08/2013 15:47, YannX/SPIP a écrit :

Pour dire les choses simplement, je ressens que les "experts"
prefereraient presque redire 5 fois la meme chose à 5 demandes
(sur IRC, spip@rezo et forum) que de compléter l'article de réference.
(quand on le retrouve...: outre SPN, dont il manque 2 sections
je me suis meme fait des SPIP de liens vers les docs SPIP)

Je ne peux pas te laisser dire ça, les soit disant experts dont tu parles rédigent des articles de ce genre (pour n'en citer qu'un) :

Et qu'on ne vienne pas me faire un plan "mais que fout cet article sur ce site ?", dans quel cas je répondrai que n'importe qui peut le copier et le publier où ça lui chante :stuck_out_tongue:

++
b_b

31

Le 29/08/13 15:08, Eric a écrit :

Après singer Git qui est l'outil le plus anti-collaboratif...

Argumente car pour le moment, j'ai pas vraiment trouvé plus conviviale et simple. Exemple, j'ai pus en trois clic proposer des modifs sur l'admin2 de thelia, sans rien casser, et embêter tout le monde, directement dans mon navigateur web, j'ai fait un pull-request deux jours après c'était accepté et hop (le genre de chose qu'il n'est pas possible de faire avec spip actuellement et aux discussions je ne pense pas dans le futur non plus).
On peut commenter un ligne de code par annotations,y'a un forum attaché a chaque page, on peut suivre, télécharger un zip, bref parler efficacement d'un développement, avec une interface simple et efficace accessible justement a ceux dont tu parle : les débutants. Pas de jargon complex, que des outils simple (on dirais du apple tellement c'est bien fait tiens ^^). C'est toujours plus efficace et conviviale qu'un trac ou autre dinosaures, et pour ce qui en est fait on pourrais le remplacer bien souvent par un webSVN ce serait suffisant, y'a la diff et le rss, et les zip : ça ne prend pas de ressource serveur ... (j'en intégrerais bien un en plugin spip a l'occase tiens au passage un webSVN, avec Zora pour la doc tip top ...).

Enfin bon chacun ses habitudes ou méthodes, mais je préfère Git a SourceForge, et je trouve pas trac ou RedMine si bien que ça, beaucoup de fonctionnalités inutile et d'autres essentielles qui manque.
Donc qu'est ce que tu appel collaboratif ? Un exemple, un nom ?

Voir a aussi prendre en compte que l'acte de contribuer, ne doit pas se transformer en une perte de temps en plus déjà d'en faire cadeaux du temps, sinon c'est sur que les nouveaux ne vont pas se presser a la porte. Je vais prendre encore thelia en exemple (vu qu'en ce moment je suis plus sur ça), depuis que l'espace contributeur a été repenssé (et sous spip d'ailleurs), faut soumettre sa doc a la mano (alors que tout est dans les readme et au format markdown pour moi), générer son zip a chaque version, et l'uploader sur le site, ... bref faut pas s'étonner si tous les dev baisse les bras et reste juste sur le svn, au final, du coup les modules sont pas a jour et faut passer sur sourceforge ou svn pour avoir un truc a jour, je comprend même pas qu'il aient pas adapté smartpaquet a leur sauce avec z et svp-skel en plus c'était réglé en 2/2 (je leur ai soufflé l'idée tout de même, mais bon).

Autre chose, qu'entends t'on par nouveaux, débutants ... ? le web est plus au table et page statiques sous front page hein ?, tout le monde quasiement bosse avec des outils bien plus complexe que svn, le php est devenu un vrai langage (presque ^^), le javascript est partout, les thème sont responsive et css3 ... bref je commence a me demander qui peut être contributeur sur des plugin sans avoir tout de même un certain niveau, pour les squelettes ou thème idem. Donc discutter sur le fait de rebuter certains qui vont avoir peur d'un dossier /trunk et un /tag ou autre j'y crois moyen. 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 ??

ou sinon on françise tronc, branche, étiquette ? mais je sens qu'ont va pas être d'accord sur la trad tout de suite :wink:

ha au passage aussi, merci a ceux qui entretiennent on créé la zone et maintienne tout ça au quotidien, on peut dire ce qu'on veut c'est beau de voir tous les outils dispos, les docs, les sites et le tout en libre.

A++
Arnaud B.

32

Bien,

33

Arnaud Bérard <arnaud.berard <at> mister-graphx.com> writes:

Le 29/08/13 15:08, Eric a écrit :
> Après singer Git qui est l'outil le plus anti-collaboratif...

Argumente car pour le moment

Faudrait éviter de partir en troll sur un sujet annexe,
c'est comme ça qu'on n'aboutit jamais à rien.
A supposer qu'on migre un jour en Git,
il faudra que le site actuel soit un peu moins en bazar
pour pouvoir effectuer la transition avec une casse minimum.
Là on parle seulement de supprimer un répertoire,
Eric a lancé ce fil il y 19 jours et pour l'instant toujours rien,
alors recentrons-nous sur le problème du jour.

Les points à trancher sont les suivants:

1. est-il souhaitable de supprimer les fichiers archiveslist.txt,
au profit de contraintes sur l'organisation des répertoires
(si la réponse est non, alors à mon avis autant ne rien faire) ?

2. l'organisation doit elle comporter, en plus de trunk,
deux répertoires branches et tags ou un seul des 2 ?

3. sur quels critères produit-on un zip: tout répertoire possédant
plugin.xml ou paquet.xml; uniquement si etat=stable; seulement
pour tags/branches ?

Si on ne ce concentre pas sur ces questions pratiques,
on aura encore parler pour rien.

Committo Ergo Sum

34

Le 29/08/2013 17:12, Arnaud Bérard a écrit :

Le 29/08/13 15:08, Eric a écrit :

Après singer Git qui est l'outil le plus anti-collaboratif...

Argumente car pour le moment, j'ai pas vraiment trouvé plus conviviale
et simple. Exemple, j'ai pus en trois clic proposer des modifs sur
l'admin2 de thelia, sans rien casser, et embêter tout le monde,
directement dans mon navigateur web, j'ai fait un pull-request deux
jours après c'était accepté et hop (le genre de chose qu'il n'est pas
possible de faire avec spip actuellement et aux discussions je ne pense
pas dans le futur non plus).

Attention, je lis un amalgame :slight_smile:

Tu parles de github là, non de git.

Autant github est une interface conviviale et simple (à peu près) à utiliser, autant git tout seul (en ligne de commande) est vraiment plus difficile à appréhender que svn.

MM.

35

Le 29 août 2013 à 17:50, Eric <eric@smellup.net> a écrit :

En plus il faut s’entendre sur ce qu’on appelle contribution. Un embryon qui moisit dans un coin pendant des mois ou quelque chose de plus abouti et donc réutilisable par d’autres ?

Je ne pense pas qu’on puisse préjuger de ce qu’est une contribution. J’ai des embryons de trucs qui ont moisit des années et que je croyais morts avant de découvrir que quelqu’un en avait trouvé un usage.
Et a contrario, d’autres trucs peuvent être utilisables, aboutis, supportés mais mourir rapidement parce que dépassés.

Il n’y a pas de bonne ou de mauvaise contribution, il n’y a que des idées qui germent, certaines qui se développent vite, d’autre qui mettent du temps, mais on ne peut pas présager du futur.

Très clairement la zone n’est comparativement pas un espace idéal pour porter le développement de projets : ça a été une bonne réponse pour donner accès aux débutants a un espace de versionnage, mais aujourd’hui github est 100 fois mieux, même pour les débutants.
A ce titre le mail d’Arnaud est très illustratif au point qu’il en confond git et GitHub.

Je ne sais pas comment on peut se positionner par rapport à cette plateforme, mais il est difficile d’en ignorer l’existence, la réaction d’Arnaud le montre.

Cédric

36

Yop,

37

Mes réponses :

38

Le 29 août 2013 à 19:48, Eric a écrit :

1. est-il souhaitable de supprimer les fichiers archiveslist.txt,
au profit de contraintes sur l'organisation des répertoires
(si la réponse est non, alors à mon avis autant ne rien faire) ?

Si on fait disparaitre les archivelist on perd du même coup la notion de dépôt logique utilisé par SVP et par Plugins SPIP. Il faudrait donc utiliser une structure physique pour séparer les dépots ce qui est moins souple. Néanmoins, et c'est un de mes regrets, on utilise peu cette notion de dépôt logique qui aurait pu permettre de créer des zips type nighty build, grenier, ou autres...

Je ne vois pas où est la perte. Sauf erreur, les fichiers archivelist actuels font implicitement référence au dépot physique sur lesquels ils se trouvent, je ne vois donc pas où il y a une séparation physique/logique au niveau de ces fichiers. Ce que je vise c'est seulement de dispenser les auteurs de plugins de manipuler les fichiers archivelist*
(au passage ce serait déjà une différence de moins avec Github), avec l'idée que c'est smart_paquet qui le produirait au lieu de le trouver d'avance. Où y aura-t-il une différence ?

Après si on supprimait ls archivelist pour se baser sur la structure de la zone il serait peut-être utile de créer un "non-archivelist" pour désactiver la production de certains zips pendant un temps donné voire à jamais si il est devenu obsolète.

Si on remplace un fichier par un autre, même plus petit, on perd en facilité. Pour ce pb, j'ai proposé de regarder l'attribut "etat".

2. 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.

3. sur quels critères produit-on un zip: tout répertoire possédant
plugin.xml ou paquet.xml; uniquement si etat=stable; seulement
pour tags/branches ?

Il faudrait se baser sur le xml. Mais là ça veut dire qu'on ne sait plus construire le zip d'une distribution comme l'ensemble des thèmes de Zpip ou simplement d'un ensemble de répertoires comme cela existe dans le fichier archivelist_contrib.txt

Euh, il est où ce fichier ? De quoi s'agit-il ?

L'état me parait trop aléatoirement attribué pour être utilisé mais pourquoi pas. Ca reste à creuser.

De nouveau si on est plus directif sur l'utilisation de qqch d'aussi peu cadré, je pense que ça ne sera pas mal vécu.

Committo,Ergo:Sum

39

oui autant pour moi c’est bien de l’outil GitHub dont je parlais et pas Git a ce moment beaucoup de dev que je côtoyais on choisit mercurial autant alors se poser aussi cette question.

Pour le reste un peut d’humour ne nuit pas non plus et je ne pense pas que vous trancherez un jour sur cette histoire de tag alors que la solution proposé par cédric et que j’approuve totalement est encore la meilleur procédure a aborder. Cela ça a déjà été discutté bien dès fois …

A++
Arnaud

40

Hihi