Le trac pose divers problème de disponibilité et des contraintes de maintenance.
J'identifie comme d'usages du trac :
* consultation des logs
* consultation de l'arborescence des fichiers
* export zip d'une arborescence
Sur ces usages trac est surdimensionné et inutile. Il apporte plus de
contraintes (disponibiltié, magie des i/o error avec python,
duplication du serveur svn, ...) que de points positifs (consultation
de la zone).
Je pense donc migrer vers un outil plus simple qui de prime abord
couvre ces besoins initiaux.
Je pense partir sur https://websvnphp.github.io qui malgré l'état de
sa page est encore maintenu et actif.
et pourquoi ne pas en profiter pour switcher sur une forge git la
totalité de la zone.
Pour la réponse courte : cela n'a rien à voir, mais vraiment rien.
Pour plus de détail, le fonctionnement de la zone en svn n'est pas
convertible en l'état en git. Il y a un travail en cours/à faire qui
n'a rien à voir avec le remplacement ou non du trac.
Pour la partie git, je t'invite à te reporter sur git.spip.net/plugin
pour ce point et les échanges sur les listes dev. (problèmatique de la
nomemclature des orgas, démultiplication des autorisations, temps de
réalisation, ....)
en 2019, travailler exclusivement avec GIT c'est un peu la "norme"
Comme cela, plus qu'une forge à maintenir
Cela n'a rien à voir. Ce sont des problèmes distincts.
L'outil svn n'est pas le problème, trac si.
et pourquoi ne pas en profiter pour switcher sur une forge git la
totalité de la zone.
Pour la réponse courte : cela n'a rien à voir, mais vraiment rien.
Pour plus de détail, le fonctionnement de la zone en svn n'est pas
convertible en l'état en git. Il y a un travail en cours/à faire qui
n'a rien à voir avec le remplacement ou non du trac.
Si je ne me trompe, une forge Git (gitea, gitlab, ...) gère les dépôts
sous GIT mais également les tickets, ...
je ne vois pas de fonctionnalités qui sont exclusivement sur trac, mais
je ne maitrise pas tous les tenants et aboutissants de trac et SPIP.
Pour la partie git, je t'invite à te reporter sur git.spip.net/plugin
pour ce point et les échanges sur les listes dev. (problèmatique de la
nomemclature des orgas, démultiplication des autorisations, temps de
réalisation, ....)
Effectivement, donc pourquoi mettre de l'énergie à configurer et
maintenir 2 plateformes ?
et pourquoi ne pas en profiter pour switcher sur une forge git la
totalité de la zone.
Pour la réponse courte : cela n’a rien à voir, mais vraiment rien.
Pour plus de détail, le fonctionnement de la zone en svn n’est pas
convertible en l’état en git. Il y a un travail en cours/à faire qui
n’a rien à voir avec le remplacement ou non du trac.
Si je ne me trompe, une forge Git (gitea, gitlab, …) gère les dépôts
sous GIT mais également les tickets, …
Comme il dit, il y a un travail en cours
Et pour la forge actuelle (trac) on n’utilise pas la plupart des fonctionnalités (les tickets sont faits via les commentaires sous les articles liés sur contrib, et le côté wiki-et-co est géré par contrib aussi)
je ne vois pas de fonctionnalités qui sont exclusivement sur trac, mais
je ne maitrise pas tous les tenants et aboutissants de trac et SPIP.
Je me risque (je n’ai pas toutes les infos et ce n’est que ma vision des choses) à dire que la migration en elle-même est déjà pas un point évident car il ne faut pas perdre l’historique (plus c’est gros plus on a des problèmes de conversion), sachant que la zone n’a pas toujours été organisée ainsi (par exemple les répertoires trunk et branches, ou même les arborescences squeleettes et plugins etc.) Ensuite (outre la migration) il y a tous les workflows autour de svn en lui-même dont génération des archives par exemple.
Pour la partie git, je t’invite à te reporter sur git.spip.net/plugin
pour ce point et les échanges sur les listes dev. (problèmatique de la
nomemclature des orgas, démultiplication des autorisations, temps de
réalisation, …)
Effectivement, donc pourquoi mettre de l’énergie à configurer et
maintenir 2 plateformes ?
Je crois qu’il pointe une urgence liée aux problèmes que pose actuellement Trac (faut croire que SPIP a réussi à atteindre les limites de l’outil) et que la solution proposée semble plus simple et facile ; tandis que précipiter la migration vers git sans avoir pu résoudre tous les soucis identifiés est la catastrophe assurée. Bref, la solution de moindre énergie et de maximum de sécurité.
Le 05/09/2019 à 16:06, cam.lafit@azerttyu.net a écrit :
Je pense donc migrer vers un outil plus simple qui de prime abord
couvre ces besoins initiaux.
Je pense partir sur https://websvnphp.github.io qui malgré l'état de
sa page est encore maintenu et actif.
Il y a les logs de commits au format RSS qui sont utilisés à différents endroits (plugins.spip ? contrib.spip ?)(même dans le Couteau Suisse visiblement).
Je sais pas si y aura moyen de faire matcher l’ancienne URL RSS sur la nouvelle. C’est pas dramatique, et on doit pouvoir mettre à jour.
> Je pense donc migrer vers un outil plus simple qui de prime abord
> couvre ces besoins initiaux.
> Je pense partir sur https://websvnphp.github.io qui malgré l'état de
> sa page est encore maintenu et actif.
Il y a les logs de commits au format RSS qui sont utilisés à différents
endroits (plugins.spip ? contrib.spip ?)(même dans le Couteau Suisse
visiblement).
Ah bien vu. Je n'avais pas pensé au RSS.
Je vais regarder le format d'export actuel et voir s'il y a un
équivalent sur websvnphp
Je sais pas si y aura moyen de faire matcher l’ancienne URL RSS sur la
nouvelle. C’est pas dramatique, et on doit pouvoir mettre à jour.
Si la fonctionnalité existe et qu'elle a une règle
cohérente/normalisée on devrait pouvoir maintenir les anciens urls
valides. Mais déjà voir si on peut avoir cette fonctionnalité.
Le 05/09/2019 à 17:18, cam.lafit@azerttyu.net a écrit :
Si la fonctionnalité existe et qu'elle a une règle
cohérente/normalisée on devrait pouvoir maintenir les anciens urls
valides. Mais déjà voir si on peut avoir cette fonctionnalité.
Le 05/09/2019 à 17:18, cam.lafit@azerttyu.net a écrit :
Salut
Je pense donc migrer vers un outil plus simple qui de prime abord
couvre ces besoins initiaux.
Je pense partir sur https://websvnphp.github.io qui malgré l'état de
sa page est encore maintenu et actif.
Il y a les logs de commits au format RSS qui sont utilisés à différents
endroits (plugins.spip ? contrib.spip ?)(même dans le Couteau Suisse
visiblement).
Ah bien vu. Je n'avais pas pensé au RSS.
Je vais regarder le format d'export actuel et voir s'il y a un
équivalent sur websvnphp
Je sais pas si y aura moyen de faire matcher l’ancienne URL RSS sur la
nouvelle. C’est pas dramatique, et on doit pouvoir mettre à jour.
Si la fonctionnalité existe et qu'elle a une règle
cohérente/normalisée on devrait pouvoir maintenir les anciens urls
valides. Mais déjà voir si on peut avoir cette fonctionnalité.
J'ai utilisé websvn durant plusieures années, sur un NAS synology (^^) il fonctionne parfaitement pour consulter , exporter des zip, faire des diff et propose le flux rss, si besoin le code qui génère le flux RSS est très simple et peut être modifié.
je pense que tu te débrouillera sans exemple de fichier de config, mais si besoin je peut fournir mes sources, ou réactiver l'accès http au nas, pour démo momentanée (trop de hits sinon, j'ai coupé pour cette cause).
