[SPIP Zone] [Spip-zone-commit] r5567 - in /_plugins_: _dev_/comarquage/ _stable_/comarquage/1_9_0/plugin.xml _stable_/comarquage/svn/ _stable_/comarquage/svn/plugin.xml

Archives Zone
1

Log:
pas de doublons dans le comarquage

Added:
    _plugins_/_stable_/comarquage/svn/
      - copied from r5556, _plugins_/_dev_/comarquage/

Est-ce que ça ne paraît pas étrange de mettre un dossier "svn", indiquant à priori des choses susceptibles de bouger pas mal, dans le dossier "_stable_" ???

De manière plus générale, il me semble que j'ai loupé le moment où a été décidé l'arborescence du type suivant :

     _plugins_/_stable_/dewplayer/1_9_0/
     _plugins_/_stable_/ecard/1_9_1/
     _plugins_/_stable_/marqueur_stats/1_9_0/

Il me semble que cela complexifie énormément la récupération en svn des plugins stables pour une version particulière de SPIP.

N'aurait-il pas été plus judicieux d'avoir :

     _plugins_/_stable_/1_9_0/dewplayer/
     _plugins_/_stable_/1_9_0/marqueur_stats/
     _plugins_/_stable_/1_9_1/ecard/

Une fois de plus, j'ai peut-être loupé la discussion où se trouvaient les bons arguments, auquel cas désolé pour le bruit...

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
phpHeaven : http://www.phpheaven.net/

2

On 20 Sep, 2006, at 08:10, Nicolas Hoizey wrote:

Une fois de plus, j'ai peut-être loupé la discussion où se trouvaient
les bons arguments, auquel cas désolé pour le bruit...

ça me dérage pas comme organisation, mais c'est vraie que j'ai ratté la fin de la discussion qui arrivait à cela... irc?

Pierre

3

on a tourné le truc dans tous les sens, chaque structure avait autant d’inconvenient que les autres, et aucune n’etait satisfaisante.
de toute facon la version 1_9_0 signifie « a partir de 1.9.0 » et donc le plugin est aussi valable en 1.9.1 si il y a pas de version 1_9_1 explicite.
Par ailleurs, quand on installe un spip, on ne cherche pas en général a avoir « tous les plugins pour une version de spip », mais des fonctionalités précises qui répondent à un besoin, et a partir de la on cherche la bonne version.
Ou alors c’est qu’on est dans une autre démarche, plus inventaire, catalogue, benckmark, veille techno … Mais autant installer tout dans ce cas.
Et dans la pratique, pour les dev, avoir un meme plugin eclaté dans plein de sous rep différent etait lourdingue

Cedric

Nicolas Hoizey a écrit :

Log:
pas de doublons dans le comarquage

Added:
    _plugins_/_stable_/comarquage/svn/
      - copied from r5556, _plugins_/_dev_/comarquage/
    


Est-ce que ça ne paraît pas étrange de mettre un dossier "svn",  
indiquant à priori des choses susceptibles de bouger pas mal, dans le  
dossier "_stable_" ???

De manière plus générale, il me semble que j'ai loupé le moment où a  
été décidé l'arborescence du type suivant :

     _plugins_/_stable_/dewplayer/1_9_0/
     _plugins_/_stable_/ecard/1_9_1/
     _plugins_/_stable_/marqueur_stats/1_9_0/

Il me semble que cela complexifie énormément la récupération en svn  
des plugins stables pour une version particulière de SPIP.

N'aurait-il pas été plus judicieux d'avoir :

     _plugins_/_stable_/1_9_0/dewplayer/
     _plugins_/_stable_/1_9_0/marqueur_stats/
     _plugins_/_stable_/1_9_1/ecard/

Une fois de plus, j'ai peut-être loupé la discussion où se trouvaient  
les bons arguments, auquel cas désolé pour le bruit...

-Nicolas
4

Nicolas Hoizey a écrit :

Log:
pas de doublons dans le comarquage

Added:
    _plugins_/_stable_/comarquage/svn/
      - copied from r5556, _plugins_/_dev_/comarquage/
    
Est-ce que ça ne paraît pas étrange de mettre un dossier "svn", indiquant à priori des choses susceptibles de bouger pas mal, dans le dossier "_stable_" ???
  

alors, si j'ai bien compris, mais rien n'est moins sur..., _stable_ veut dire "pour une version stable *de Spip*"
Pas du tout que le plugin lui meme est stable.

Si le plugin necessite une SVN de spip (pas de la branche 1.9, la version de dev), alors il va dans _dev_

on devrait donc avoir plein de choses dans _stable_ avec soit un sous repertoire 1.9.0 si c'est compatible depuis cette version, soit 1.9.1, soit les 2 si 2 versions differentes sont necessaires...etc

un plugin necessitant la derniere SVN de la branche 1.9 par contre, je ne sais pas ou ca doit aller...
dans la branche _dev_ avec un sous repertoire 1.9 ou dans la branche _stable_ avec un sous repertoire 1.9.2 "anticipé" ?

De manière plus générale, il me semble que j'ai loupé le moment où a été décidé l'arborescence du type suivant :

     _plugins_/_stable_/dewplayer/1_9_0/
     _plugins_/_stable_/ecard/1_9_1/
     _plugins_/_stable_/marqueur_stats/1_9_0/
  

héhéhé, moi hier, je me suis battu 1h avec le SVN.
Je fais des synchros partielles sur un projet qui contient tout spip-zone : il me disait "pas de changement", mais plantait sur les updates et le commit en me disant que le fichier en face n'existait pas...

J'ai fini par jeter un oeil sur les commit et j'ai compris qu'il fallait que je remonte d'un cran pour updater.
Bref, vraiment, c'est pas pour me plaindre, mais un petit mail sur la liste avant de le faire et pour expliquer l'organisation, juste 3 lignes, ca n'aurait pas été de trop.
:stuck_out_tongue:

Il me semble que cela complexifie énormément la récupération en svn des plugins stables pour une version particulière de SPIP.

N'aurait-il pas été plus judicieux d'avoir :

     _plugins_/_stable_/1_9_0/dewplayer/
     _plugins_/_stable_/1_9_0/marqueur_stats/
     _plugins_/_stable_/1_9_1/ecard/
  

non, car si j'ai une 1.9.1, je ne trouverai pas forcement le plugin dans 1.9.1, si il est compatible 1.9.0 ET 1.9.1, il dait etre dans 1.9.0

Une fois de plus, j'ai peut-être loupé la discussion où se trouvaient les bons arguments, auquel cas désolé pour le bruit...
  

Ben finalement, il n'y a eu que peu de bruit sur cette liste, les choses ont du se passer du coté de l'IRC, mais de toutes facons, il fallait poser une regle.
Chacun a donné son avis, tout le monde était d'accord pour dire qu'il y avait un pb, maintenant, c'est reglé.

Bref, peut etre juste un petit manque de communication ?

@++

5

on a tourné le truc dans tous les sens, chaque structure avait autant d'inconvenient que les autres, et aucune n'etait satisfaisante.

OK :wink:

de toute facon la version 1_9_0 signifie "a partir de 1.9.0" et donc le plugin est aussi valable en 1.9.1 si il y a pas de version 1_9_1 explicite.

Sauf si ce n'est pas maintenu...

Par ailleurs, quand on installe un spip, on ne cherche pas en général a avoir "tous les plugins pour une version de spip", mais des fonctionalités précises qui répondent à un besoin, et a partir de la on cherche la bonne version.

Mais si l'on utilise 12 plugins, c'est plus simple de tous les prendre en svn et de cocher les bons dans l'interface, plutôt que faire 12 checkout, non ?

Ou alors c'est qu'on est dans une autre démarche, plus inventaire, catalogue, benckmark, veille techno .... Mais autant installer tout dans ce cas.

C'est de toute façon le seul moyen à l'heure actuelle de découvrir de nouveaux plugins, et donc de les choisir, non ?

Et dans la pratique, pour les dev, avoir un meme plugin eclaté dans plein de sous rep différent etait lourdingue

OK

A mon sens, les développeurs interviennent surtout sur des évolutions dans le trunc, et ils n'interviennent que rarement sur les versions stables tagguées, non ?

Enfin bon, je m'adapterais, après tout si j'utilise svn je fais déjà le choix de la complexité technique... :wink:

-Nicolas

--
Nicolas "Brush" HOIZEY
Clever Age : http://www.clever-age.com/
Gastero Prod : http://www.gasteroprod.com/
phpHeaven : http://www.phpheaven.net/

6

alors, si j'ai bien compris, mais rien n'est moins sur..., _stable_ veut
dire "pour une version stable *de Spip*"

Ah non, ça c'était avant :slight_smile:

Pas du tout que le plugin lui meme est stable.

Maintenant ça veut dire que le plugin est sérieusement consommable, a été
testé et tout ; mais, si le plugin existe en deux versions, on préfère les
mettre côte à côte dans le même répertoire... même si une des deux est pas
bien testée...

Autrement dit, on peut faire un paquet avec tout _stable_, et ça permettra
d'avoir un ensemble de plugins où on ne s'aventure pas trop, disponibles
parfois dans plusieurs versions, correspondant parfois à plusieurs versions
de spip.

Si on veut s'aventurer un peu plus et aider à tester, on peut aller piocher
dans _test_ ; et si on veut chercher le truc qui tue, fouiller dans _dev_.

> De manière plus générale, il me semble que j'ai loupé le moment où a
> été décidé

Tu crois qu'il y a eu une grande réunion secrète du Comité de Pilotage
Clandestin (CPC) !?

Non, sérieux, ce n'est pas comme ça que ça se passe : ça mûrit (et les
quelques mails sur la liste ont participé à ce mûrissement), et à un moment
donné quelqu'un en a marre et agit (de préférence en en parlant un peu sur
irc pour éviter de merder tout seul en ratant quelque chose ... et aussi
avec l'espoir d'éviter de faire tout le boulot tout seul).

> l'arborescence du type suivant :
>
> _plugins_/_stable_/dewplayer/1_9_0/
> _plugins_/_stable_/ecard/1_9_1/
> _plugins_/_stable_/marqueur_stats/1_9_0/

Ca c'était transitoire, puisque les plugins "célibataires" se sont
finalement retrouvés dans _plugins_/_stable_/dewplayer/ (sans
sous-répertoire, donc).

> Il me semble que cela complexifie énormément la récupération en svn
> des plugins stables pour une version particulière de SPIP.

Ah mais, SPIP Zone n'est *pas* un espace de distribution de plugins stables.
C'est un espace de *développement*. Qu'on cherche à rendre le plus
accessible, ok, mais ce n'est pas sa finalité première. On n'a toujours pas
trouvé comment articuler un espace de distribution correct, mais ce n'est
clairement pas SPIP Zone (sauf à la stériliser).

A part ça il y a un nouveau plugin "svn_update" qui prend une liste de
couples (source svn, destination), et qui installe et met à jour les
répertoires en question, *même s'ils ont changé place dans le dépôt* (et
aussi s'ils ont changé de dépôt).

-- Fil

7

Fil a écrit :

alors, si j'ai bien compris, mais rien n'est moins sur..., _stable_ veut dire "pour une version stable *de Spip*"
    
Ah non, ça c'était avant :slight_smile:
  

zut, encore raté...

Maintenant ça veut dire que le plugin est sérieusement consommable, a été
testé et tout ; mais, si le plugin existe en deux versions, on préfère les
mettre côte à côte dans le même répertoire... même si une des deux est pas
bien testée...
  

ben alors je comprend de moins en moins l'interet...
Qu'on separe _test_ et _dev_ je comprend car ca apporte un peu de clareté aux utilisateurs (quoi que, si il y a des sous repertoire, meme pas sur).
Mais _stable_, pourquoi ? pour faire des branches de maintenance ?

Le moment ou il faut passer d'un repertoire à l'autre ne me parait vraiment pas tres clair.
dès que j'ai sorti un version stable, je deplace tout dans _stable_ ?

La division en 3 phases me parait judicieuse, mais on l'a deja dans le plugin lui meme.
si c'est uniquement pour une question de diffusion, ca doit pouvoir se tester directement dans le plugin.xml, charge à nous de dupliquer la version "test" ou "stable" quand on repasse en phase de developpement

Ah mais, SPIP Zone n'est *pas* un espace de distribution de plugins stables.
C'est un espace de *développement*. Qu'on cherche à rendre le plus
accessible, ok, mais ce n'est pas sa finalité première. On n'a toujours pas
trouvé comment articuler un espace de distribution correct, mais ce n'est
clairement pas SPIP Zone (sauf à la stériliser).
  

Si c'est un espace de developpement, alors il faut faciliter la vie aux developpeurs, pas aux utilisateur en quete de stabilité.
Pour moi, ca veut dire effectivement 3 etats possibles :
- dev : le trunk qui peut ne pas marcher à certains moments
- test : la derniere version du trunk supposées marcher
- stable : uniquement si il faut faire des modifs sur une version reputée stable et diffusée, mais mettre systematiquement une copie quand on diffuse, ca permet aux utilisateurs d'aller faire les corrections eux meme (tout comme _test_)
Ca me parait plus simple d'avoir tout dans le meme repertoire, mais un projet vivant devrait au bout d'un moment avoir les 3.
donc tous les projets devraient finir dans stable avec des repertoires dev et test dedans ?
ca fait beaucoup de move alors qu'il n'y a pas une grande difference entre faire un switch _plugin_/monplug/test <=> _plugin_/monplug/dev et un switch _plugin_/_test_/monplug/ <=> _plugin_/_dev_/monplug/
Si c'est un espace collaboratif ouvert, il faut penser egalement aux betatesteurs, d'ou l'interet d'un repertoire des versions _test_ des plugins et d'un systeme de diffusion des plugins en phase de test.

Pour moi la branche stable n'existe que pour des maintenances.
Elle est donc succeptible de ne pas l'etre justement.
On me signale un bug, je tente une correction (le plugin est donc potentiellement inutilisable pendant quelques jours) et je repasse par une phase de test avant de versionner/packager.
zipper et diffuser le contenu de la branche stable pour autre chose que cette phase de test de correctifs, me parait inutile et meme nuisible à la création de contribs documentées.

En gros, amha, soit il y a des repertoires generaux et on met la version correspondante dans le bon repertoire, soit il n'y en a pas et chaque plugin a son repertoire qui les contient.
La premiere solution est sans doute la plus efficace car c'est entre les "testeurs" et la zone qu'il manque des ponts.

La "demi mesure" ne me semble pas apporter pas grand chose, ni au developpeur, ni à l'utilisateur...

M'enfin, comme je disais, je ferai comme on me dit ou on me dit (d'autant plus que c'est pas moi qui me tape les reorganisations... ), mais la, sincerement, je ne sais pas trop ce que je dois faire de mes plugins...
Sans doute dans test car j'ai generalement des versions testables dans lesquels la maintenance n'est pas (encore) necessaire et qu'au final, c'est plutot l'echange sur les usages et les retours utilisateur qui m'interessent.

mes 2 sous tardifs.
@++
   

8

Sans doute dans test car j'ai generalement des versions testables dans
lesquels la maintenance n'est pas (encore) necessaire et qu'au final,
c'est plutot l'echange sur les usages et les retours utilisateur qui
m'interessent.

Oui, moi aussi c'est _test_ qui me convient le mieux ; d'ailleurs je roule
toujours ma "prod" en version SVN, c'est comme ça que je repère les bugs.

Mais tout le monde ne fonctionne pas comme ça, y compris parmi les
développeurs, et au premier chef Cedric qui a développé (à la louche) 50% du
répertoire _plugins_ ;-D

Donc voilà, il y a des attentes forcément contradictoires, entre ceux qui
voudraient un truc "tout à plat", ceux qui voudraient une arborescence super
précise, d'autres qui préfèrent du solide d'un côté et du fluide de l'autre.

Ce qui est clair c'est que dans l'arbo d'avant, il était impossible de s'y
retrouver ! Je crois qu'on a un bon compromis, maintenant. Mais il ne s'agit
pas d'une règle à appliquer d'une main de fer.

Mon approche du truc, c'est que je ne vais pas conseiller à quelqu'un qui me
demande un conseil d'aller chercher un plugin dans _test_ ni dans _dev_,
parce que ce sont des endroits où, si ça marche à un instant t, rien ne
garantit que le plugin restera fonctionnel, voire même que son "concept"
restera valable.

Par exemple pagination_ahah, ou miroir_syndic, pourraient très bien
disparaître et être remplacés, à court terme, par d'autres trucs qui "feront
la même chose" mais totalement différemment. Pour "forms", par contre, c'est
un truc bien établi (donc _stable_), même si forms2 sera peut-être en état
"dev" pendant 6 mois, dans ce même répertoire "_stable_". (Quoi c'est pas
clair ? c'est un espace à deux dimensions ! ou deux-et-demi)

A l'inverse, pour faire des "preuves de concept" et les partager rapidement,
_dev_ est idéal.

Ca pourrait s'appeler "serieux", "test" et "hacks" aussi. :slight_smile:

-- Fil

9

Oulala, il ne faut surtout pas utiliser le svn copy et svn move pour développer différentes version d’un même plugin ! La fonctionalité de branche est justement faite expres rien que pour gérer ça : on n’a pas 3 trucs qui vivent en parralèle, mais une seule entité qu’on aborde sous différents angles – avec la possibiliter de merger une branche vers une autre, d’impacter une modif faite sur une branche à d’autres branches, etc… et tout ça « assez » simplement (en tout cas ça reste plus fiable que si on faisait ces opérations à la main)

Maintenant je ne me suis pas plongé plus dans la doc de svn pour en dire plus que ça. D’autres pourront apporter plus de détail. Mais à mon avis, ce qu’il faut avoir en tête, c’est qu’il faut se simplifier la vie, et qu’on sache intuitivement où aller piocher la version de dev / test / stable (et donc que tous les plugins soient organisés + / - de la même manière, ce qui va demander à certains pas mal de rigueur :wink:

Mes 2 cents de gestionnaire,

.Gilles

Le 20/09/06, Bill <bill@adequates.com> a écrit :

Fil a écrit :

alors, si j’ai bien compris, mais rien n’est moins sur…, stable veut
dire « pour une version stable de Spip »

Ah non, ça c’était avant :slight_smile:

zut, encore raté…

Maintenant ça veut dire que le plugin est sérieusement consommable, a été
testé et tout ; mais, si le plugin existe en deux versions, on préfère les
mettre côte à côte dans le même répertoire… même si une des deux est pas
bien testée…

ben alors je comprend de moins en moins l’interet…
Qu’on separe test et dev je comprend car ca apporte un peu de
clareté aux utilisateurs (quoi que, si il y a des sous repertoire, meme
pas sur).
Mais stable, pourquoi ? pour faire des branches de maintenance ?

Le moment ou il faut passer d’un repertoire à l’autre ne me parait
vraiment pas tres clair.
dès que j’ai sorti un version stable, je deplace tout dans stable ?

La division en 3 phases me parait judicieuse, mais on l’a deja dans le
plugin lui meme.
si c’est uniquement pour une question de diffusion, ca doit pouvoir se
tester directement dans le plugin.xml, charge à nous de dupliquer la
version « test » ou « stable » quand on repasse en phase de developpement

Ah mais, SPIP Zone n’est pas un espace de distribution de plugins stables.
C’est un espace de développement. Qu’on cherche à rendre le plus
accessible, ok, mais ce n’est pas sa finalité première. On n’a toujours pas
trouvé comment articuler un espace de distribution correct, mais ce n’est
clairement pas SPIP Zone (sauf à la stériliser).

Si c’est un espace de developpement, alors il faut faciliter la vie aux
developpeurs, pas aux utilisateur en quete de stabilité.
Pour moi, ca veut dire effectivement 3 etats possibles :

  • dev : le trunk qui peut ne pas marcher à certains moments
  • test : la derniere version du trunk supposées marcher
  • stable : uniquement si il faut faire des modifs sur une version
    reputée stable et diffusée, mais mettre systematiquement une copie quand
    on diffuse, ca permet aux utilisateurs d’aller faire les corrections eux
    meme (tout comme test)
    Ca me parait plus simple d’avoir tout dans le meme repertoire, mais un
    projet vivant devrait au bout d’un moment avoir les 3.
    donc tous les projets devraient finir dans stable avec des repertoires
    dev et test dedans ?
    ca fait beaucoup de move alors qu’il n’y a pas une grande difference
    entre faire un switch plugin/monplug/test <=> plugin/monplug/dev et
    un switch plugin/test/monplug/ <=> plugin/dev/monplug/
    Si c’est un espace collaboratif ouvert, il faut penser egalement aux
    betatesteurs, d’ou l’interet d’un repertoire des versions test des
    plugins et d’un systeme de diffusion des plugins en phase de test.

Pour moi la branche stable n’existe que pour des maintenances.
Elle est donc succeptible de ne pas l’etre justement.
On me signale un bug, je tente une correction (le plugin est donc
potentiellement inutilisable pendant quelques jours) et je repasse par
une phase de test avant de versionner/packager.
zipper et diffuser le contenu de la branche stable pour autre chose que
cette phase de test de correctifs, me parait inutile et meme nuisible à
la création de contribs documentées.

En gros, amha, soit il y a des repertoires generaux et on met la version
correspondante dans le bon repertoire, soit il n’y en a pas et chaque
plugin a son repertoire qui les contient.
La premiere solution est sans doute la plus efficace car c’est entre les
« testeurs » et la zone qu’il manque des ponts.

La « demi mesure » ne me semble pas apporter pas grand chose, ni au
developpeur, ni à l’utilisateur…

M’enfin, comme je disais, je ferai comme on me dit ou on me dit
(d’autant plus que c’est pas moi qui me tape les reorganisations… ),
mais la, sincerement, je ne sais pas trop ce que je dois faire de mes
plugins…
Sans doute dans test car j’ai generalement des versions testables dans
lesquels la maintenance n’est pas (encore) necessaire et qu’au final,
c’est plutot l’echange sur les usages et les retours utilisateur qui
m’interessent.

mes 2 sous tardifs.
@++

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

10

Le 20/09/06, Fil <fil@rezo.net> a écrit :

Mais tout le monde ne fonctionne pas comme ça, y compris parmi les
développeurs, et au premier chef Cedric qui a développé (à la louche) 50% du
répertoire plugins ;-D

Au moins :wink:

Donc voilà, il y a des attentes forcément contradictoires, entre ceux qui
voudraient un truc « tout à plat », ceux qui voudraient une arborescence super
précise, d’autres qui préfèrent du solide d’un côté et du fluide de l’autre.

Ce qui est clair c’est que dans l’arbo d’avant, il était impossible de s’y
retrouver ! Je crois qu’on a un bon compromis, maintenant. Mais il ne s’agit
pas d’une règle à appliquer d’une main de fer.

Si on met à 2 endroits de l’arbo svn les mêmes noms de répertoire, c’est sûr qu’on s’y perd.
Ca s’est amélioré ;p

Mon approche du truc, c’est que je ne vais pas conseiller à quelqu’un qui me
demande un conseil d’aller chercher un plugin dans test ni dans dev,
parce que ce sont des endroits où, si ça marche à un instant t, rien ne
garantit que le plugin restera fonctionnel, voire même que son « concept »
restera valable.

Par exemple pagination_ahah, ou miroir_syndic, pourraient très bien
disparaître et être remplacés, à court terme, par d’autres trucs qui « feront
la même chose » mais totalement différemment. Pour « forms », par contre, c’est
un truc bien établi (donc stable), même si forms2 sera peut-être en état
« dev » pendant 6 mois, dans ce même répertoire « stable ». (Quoi c’est pas
clair ? c’est un espace à deux dimensions ! ou deux-et-demi)

Là c’est une approche qui me chagrine :
par exemple à un moment on avait thickbox et thickbox2
Faire disparaitre l’un sous prétexte que l’autre « est mieux » est inutile et subjectif : par exemple si je veux faire que des popups basiques
je préfère utiliser thickbox qui n’utilise pas d’artillerie externe trop lourde et inutile pour mon cas particulier.
Le problème est le même pour pagination_ahah ou mirroir_syndic…

A l’inverse, pour faire des « preuves de concept » et les partager rapidement,
dev est idéal.

Pour moi la notion de « dev » et « stables » sont liés à la distribtion d’un même plugin. C’est pour cela qu’à mon avis ça doit passer par des
branches qui permettraient aussi d’explorer beaucoup plus les variantes d’un même plugin. Actuellement, si j’ai envie de jouer avec la pagination, je ne peux pas aller très loin sans casser le mécanisme de base… Hors si je veux n’en faire qu’une variante (avec une approche plus sur l’accessibilité, ou une ergonomie différente), à mon avis c’est dans une branche de ce plugin que ça doit se développer…

.Gilles

Ca pourrait s’appeler « serieux », « test » et « hacks » aussi. :slight_smile:

– Fil

spip-zone@rezo.net - http://listes.rezo.net/mailman/listinfo/spip-zone

11

On 20 Sep, 2006, at 22:39, Gilles Vincent wrote:

Oulala, il ne faut surtout pas utiliser le svn copy et svn move pour
développer différentes version d'un même plugin ! La fonctionalité de
branche est justement faite expres rien que pour gérer ça : on n'a pas 3
trucs qui vivent en parralèle, mais une seule entité qu'on aborde sous
différents angles -- avec la possibiliter de
merger une branche vers une autre, d'impacter une modif faite sur une
branche à d'autres branches, etc.. et tout ça "assez" simplement (en tout
cas ça reste plus fiable que si on faisait ces opérations à la main)

La doc de SVN est assez clair:
http://svnbook.red-bean.com/en/1.1/ch02s02.html#svn-ch-2-sect-2.3
http://svnbook.red-bean.com/en/1.1/ch04s02.html#svn-ch-4-sect-2.1

Il n'y a pas de tag ou de branch dans le sens CVS sur SVN. Pour brancher quelque-chose sur svn, il faut faire un
svn copy
(il parle pas trop du move)

Ensuite, on peut faire des svn merge entre deux fichier qui sont des copies différentes d'un même fichier dans l'historique...

Il y a aussi un svn switch
qui permet de passer une working copy d'une branche à une autre.

Donc, on pourrait avoir un plugin stable qu'on veut modifier pour une version de dev de SPIP (qui ne colle pas avec la version stable). On fera donc:

svn copy _plugins_/_stable_/monplugin/1_9_0 _plugins_/_dev_/monplugin/svn

puis, si on fait des modifs dans un fichier du monplugin/svn, on peut ensuite faire un merge avec le même fichier de monplugin/1_9_0

svn merge svn://.../_plugins_/_stable_/monplugin/1_9_0/plugin.xml _plugins_/_dev_/monplugin/svn/plugin.xml

Pour le dev/tester qui veut passer de la version stable 1.9.0 à la version de dev svn du plugin, il fait:

svn switch svn://.../_plugins_/_dev_/monplugin/svn monplugin

Voilà,

j'espère que ça aide. Lisez les deux liens que j'ai donné, c'est court et ça aide :wink:

Pierre

12

Là c'est une approche qui me chagrine :
par exemple à un moment on avait thickbox et thickbox2

Personne n'a intégré thickbox2, à ma connaissance, il n'y a que thickbox1
pour l'instant.

En revanche il y avait lightbox, et quelqu'un (un certain ... Gilles) l'a
écrasé avec lightbox2 ...
        Connexion · GitLab

Par la suite j'ai rétabli lightbox1 (parce que je ne
cherchais pas "le meilleur" mais "une démarche").
        Connexion · GitLab

ensuite une fois que j'ai adopté thickbox, j'ai préféré supprimer lightbox1
puisque je l'avais conçu comme un exercice.
        Connexion · GitLab

Mais si tu veux l'utiliser, rien ne t'empêche de le rétalir comme j'avais
rétabli à partir des archives

si je veux n'en faire qu'une variante (avec une approche plus sur
l'accessibilité, ou une ergonomie différente), à mon avis c'est dans une
branche de ce plugin que ça doit se développer..

Oui, c'est comme ça maintenant :slight_smile:

-- Fil

13

Le 21/09/06, Fil <fil@rezo.net> a écrit :

Là c’est une approche qui me chagrine :
par exemple à un moment on avait thickbox et thickbox2

Personne n’a intégré thickbox2, à ma connaissance, il n’y a que thickbox1
pour l’instant.

En revanche il y avait lightbox, et quelqu’un (un certain … Gilles) l’a
écrasé avec lightbox2 …
http://zone.spip.org/trac/spip-zone/changeset/4007

Oups’ je m’a planté :wink:
J’ai vraiment écrasé ça moi ? :o)

si je veux n’en faire qu’une variante (avec une approche plus sur
l’accessibilité, ou une ergonomie différente), à mon avis c’est dans une
branche de ce plugin que ça doit se développer…

Oui, c’est comme ça maintenant :slight_smile:

Yep!

– Fil

14

2006/9/21, Gilles Vincent <gilles.vincent@gmail.com>:

Le 21/09/06, Fil <fil@rezo.net> a écrit :

Là c’est une approche qui me chagrine :
par exemple à un moment on avait thickbox et thickbox2

Personne n’a intégré thickbox2, à ma connaissance, il n’y a que thickbox1
pour l’instant.

En revanche il y avait lightbox, et quelqu’un (un certain … Gilles) l’a
écrasé avec lightbox2 …
http://zone.spip.org/trac/spip-zone/changeset/4007

Oups’ je m’a planté :wink:
J’ai vraiment écrasé ça moi ? :o)

En fait c’est à lightbox que je songeait :
la v.1 est certes moins fonctionnelle, mais elle a l’avantage d’être super légère, et de ne pas utiliser d’autres librairies (la v2 standard fait appel à prototype et scriptaculous, qui sont un peu des monstres pour un simple diaporama)
Je pense que je vais la rétablir, car les 2 versions ne correspondent pas aux mêmes besoins.

.Gilles

15

Fil a écrit :

Oui, moi aussi c'est _test_ qui me convient le mieux ; d'ailleurs je roule
toujours ma "prod" en version SVN, c'est comme ça que je repère les bugs.

Mais tout le monde ne fonctionne pas comme ça, y compris parmi les
développeurs, et au premier chef Cedric qui a développé (à la louche) 50% du
répertoire _plugins_ ;-D

Donc voilà, il y a des attentes forcément contradictoires, entre ceux qui
voudraient un truc "tout à plat", ceux qui voudraient une arborescence super
précise, d'autres qui préfèrent du solide d'un côté et du fluide de l'autre.

Ce qui est clair c'est que dans l'arbo d'avant, il était impossible de s'y
retrouver ! Je crois qu'on a un bon compromis, maintenant. Mais il ne s'agit
pas d'une règle à appliquer d'une main de fer.
  

OK, merci pour ces explications.

Bon ben je vais essayer le "move" alors...

@++