La doc de Spipnet référençait les articles des différentes versions de SPIP
à l'aide de raccourcis de forme [->spipNNN].
Ils étaient définis dans ce fichier:
Ces liens ne marchent plus depuis je ne sais quand,
ce qui rend la comparaison de doc pénible.
Quand je regarde le répertoire consacré à Spipnet sur la zone, savoir:
* Committo, Ergo Sum tapuscrivait, le 06/12/2012 23:51:
La doc de Spipnet référençait les articles des différentes versions de SPIP
à l'aide de raccourcis de forme [->spipNNN].
Ils étaient définis dans ce fichier:
Ces liens ne marchent plus depuis je ne sais quand,
ce qui rend la comparaison de doc pénible.
Quand je regarde le répertoire consacré à Spipnet sur la zone, savoir:
je constate que, comme Spip-contrib, il n'est pas organisé en trunk+branches,
et que le code figurant dans le fichier ci-dessus n'y a pas été inclus.
C'est quoi la raison de cette régression ?
Peut-être parce qu'
Il était une fois Tout le monde, Quelqu'un, N'importe qui et Personne.
Il y avait un travail important à faire et Tout le monde était certain que Quelqu'un le ferait.
N'importe qui aurait pu le faire mais Personne ne le faisait.
Quelqu'un se fâcha, parce que c'était le travail de Tout le monde qui pensait que N'importe qui aurait pu le faire.
Personne ne réalisait que Tout le monde ne voulait pas le faire.
Ainsi Tout le monde blâma Quelqu'un
alors que Personne n'avait fait ce que N'importe qui aurait pu faire.
* Committo, Ergo Sum tapuscrivait, le 06/12/2012 23:51:
>
> C'est quoi la raison de cette régression ?
Peut-être parce qu'
Il était une fois Tout le monde, Quelqu'un, N'importe qui et Personne.
Il y avait un travail important à faire
Non, là il s'agissait d'un travail à NE PAS faire,
savoir faire disparaître un travail qui avait été fait.
Ces liens ne marchent plus depuis je ne sais quand,
s'ils ne fonctionnent pas effectivement dans le privé
(ils renvoient sur SPIP)
ils sont tout à fait fonctionnels dans le plublic en
renvoyant sur la bonne page article.
et bien ! en voilà un joli lien qui fonctionne pas...
donc :
ça devrait plus mieux le faire (sous réserve que la zone n'affiche pas
ses messages d'erreurs python...)
pour en revenir à l'usage d'un trunk et de branches, il faudrait donc
décider de la création d'une branche à chaque changement de branche du
spip utilisé par le site :
la branche v2.0 du *squelette* spip.net étant créée lors du passage du
*site* spip.net en spip 2.1, et la branche v2.1 lors du passage en
spip 3.0 ; le site lui-même étant toujours calé sur le trunk.
ce pourrait être une excellente idée si ce rangement était couplé avec
un versionning des données de spip.net (on pourrait même aller
jusqu'à imaginer un spip.net --squelette + données-- par branche
de spip) .
en-dehors de ce cas de figure, je ne vois pas trop ce que des branches
apporteraient comme bénéfice ; ce squelette n'ayant pas vocation à être
distribué (ne serait-ce que parce profondément lié aux données qu'il
est sensé présenter).
C'est tellement vrai que la dernière URL que tu donnes ne fonctionne pas !
Le fichier mes_options.php a TOTALEMENT disparu du répertoire spipnet.
C'est quoi ce bazar ?
Le 7 déc. 2012 à 00:42, Committo, Ergo Sum a écrit :
RealET <real3t <at> gmail.com> writes:
* Committo, Ergo Sum tapuscrivait, le 06/12/2012 23:51:
C'est quoi la raison de cette régression ?
Peut-être parce qu'
Il était une fois Tout le monde, Quelqu'un, N'importe qui et Personne.
Il y avait un travail important à faire
Non, là il s'agissait d'un travail à NE PAS faire,
savoir faire disparaître un travail qui avait été fait.
Est-il vraiment nécessaire de s'énerver pour si peu ?
En regardant calmement on voit que :
- personne n'a rien fait disparaitre et la fonction des raccourcis personnalisés est toujours là :
- que le branchement de cette fonction personnalisée dans generer_url_entite n'avait jamais été documenté, du coup difficile de le deviner à la lecture (en particulier le retour de la fonction est un array et le code prévoit de le concatener avec une chaine dans certains cas) http://core.spip.org/projects/spip/repository/revisions/20037
- que suite à la prise en charge générique des objets dans SPIP 3.0, generer_url_ecrire_objet génère une url interne dans tous les cas, et il faut maintenant simplement declarer une fonction analogue pour l'espace privé : Connexion · GitLab répare le problème
Est-il vraiment nécessaire de s'énerver pour si peu ?
Je suis parfaitement calme.
En regardant calmement on voit que :
- personne n'a rien fait disparaitre et la fonction des raccourcis personnalisés est toujours là : Connexion · GitLab
Et moi je constate calmement
1. que même Denis, qui contrairement à moi n'a jamais décroché du développement, n'a pas su produire cette URL;
2. que l'URL que tu produis indique le répertoire 2008, alors qu'il existe un répertoire 2011 dont on peut légitimement penser que c'est celui-là où il faut faire ses commits si on souhaite que son travail soit utilisé.
Ce que je déplore avant tout, ce n'est donc pas un dysfonctionnnement certes mineur sur spipnet, mais cette méthode de développement qui consiste à brouiller les pistes pour décourager le travail collaboratif.
- que le branchement de cette fonction personnalisée dans generer_url_entite n'avait jamais été documenté,
la charité qui se fout de l'hôpital. D'autant qu'il suffisait de demander le "revision log" du fichier pour voir apparaître les messages de log à ce propos.
pour un squelette *non distribué* (pour un site précis), un découpage
en années est souvent bien mieux qu'un découpage en branche par version ;
Comme disait Henri Michaux, même si c'est vrai c'est faux.
Je veux dire qu'un développement de grande taille comme celui de SPIP
ne peut s'embarrasser de cas particuliers: il n'est pas acceptable d'obscurcir
le cadre général au nom d'une amélioration locale, car au bout du compte
les nouveaux venus ne voient plus le cadre général.
Il faut renoncer à toute dérogation, et trouver d'autres méthodes
pour signaler ce qu'on voulait signaler.
Cela dit, j'ai vu que tu as effectivement instauré ici truck+branches, très bien.
Mais il y a encore qqch de dérogatoire: pourquoi est-ce dans un répertoire nommé
"squelettes" qu'on trouve ce fichier mes_options.php ?
C'est ça qui m'a fait dire que ce fichier avait totalement disparu,
car jamais on ne met un tel fichier ici: c'est encore un de ces détails qui
découragent le nouveau venu.
Plus généralement je ne comprends pas pourquoi le contenu du répertoire
www.spip.net soit réduit à une seule entrée: c'est un niveau d'arborescence inutile,
et, comme on l'a vu, trompeur.
Mais il y a encore qqch de dérogatoire: pourquoi est-ce dans un répertoire nommé
"squelettes" qu'on trouve ce fichier mes_options.php ?
Je me trompe peut-être, mais je crois me rappeler que c'est parce que le mes_options.php du site en prod comporte une inclusion du mes_options trouvé dans le dossier squelette, ce qui permet de tout empaqueter ensemble, on change de dossier et on a tout. Faut redemander à ceux qui ont accès au site, mais il me semble que c'était ça.
Plus généralement je ne comprends pas pourquoi le contenu du répertoire
www.spip.net soit réduit à une seule entrée: c'est un niveau d'arborescence inutile,
et, comme on l'a vu, trompeur.
Non, c'est parce qu'un site précis ne se compose pas toujours que d'un squelette. Parfois il y a un dossier "config" pour le mes_options (lorsqu'il n'y a pas le comportement décrit ci-dessus). Parfois il y a un dossier "themes" qui contient le ou les thèmes graphiques successifs au fil des refontes (ce qui est différent des squelettes, qui gèrent l'aspect fonctionnel).
Donc là potentiellement, quand le site changera, il pourra y avoir au moins un dossier "themes" qui apparaîtra.
Mais il y a encore qqch de dérogatoire: pourquoi est-ce dans un
répertoire nommé
"squelettes" qu'on trouve ce fichier mes_options.php ?
Je me trompe peut-être, mais je crois me rappeler que c'est parce que le
mes_options.php du site en prod comporte une inclusion du mes_options
trouvé dans le dossier squelette, ce qui permet de tout empaqueter
ensemble, on change de dossier et on a tout. Faut redemander à ceux qui ont
accès au site, mais il me semble que c'était ça.
oui c'est exactement ça, partager le mes_options.php avec le reste dans le
même rép. svn.