[spip-dev] Gestion de version

Dev
1

Je me suis permis de changer l’objet du thread pour le ramener sur ce vaste sujet …

Olivier Mansour a écrit :

Bonjour et merci pour ces indications.

  • il y a un champs dans la table article liant la nouvelle version de
    l’article à sa version d’origine

comme les traductions … ca revient donc à faire une traduction dans la
meme langue

  • on peut créer une nouvelle version d’un article, on obtient alors
    un article fils identique à l’article père. Un rédacteur, si il a
    accès à la rubrique, peut le faire sur un article qu’il n’a pas écrit
    Jusqu’ici ca doit etre pareil

  • il pourra, une fois rédiger, proposer une nouvelle version de cette
    article

La, on pourrait faire un petit hack de facon avoir un bouton publier
nouvelle version qui ferait la depublication de l’ancienne version et
autres traitements (voir plus bas)

  • le back office présente des liens de type « cet article est une
    version de cet article » ou « autre version de cette article »

Idem si on utilise les traductions

  • au niveau de la classe métier, quand on publie un article étant une
    version d’un autre article, on modifie le statut de l’article père et
    on inverse les id des articles

Petit hack necessaire donc …

  • fonctionnellement, on ne peut créer une version d’un article que
    dans la rubrique de l’article père

En espérant que cela aide. Cette fonctionnalité est assez appréciée
des utilisateurs. De mémoire, elle a été crée pour le site
diplomatie.gouv.fr

Oui mais il y manque beaucoup de choses pour etre operationnelle à mon
sens :

  • Quid de l’historique des modification ? (il est dans agora non ?)
  • Quid des documents ?
  • Quid des mots clés ?
    si je rajoute un document ou un mot à la nouvelle, est il reporté à la
    publication ?

Là c’est plus épineux, il ne faudrait pas faire usine à gaz …
doublonner les liens lors de la crétaion parait une bonne idée et basculer les id_articles dans les liasons lors de la publication cela permet de garder les document rattaché à l’article et aussi de garder les id document d’origine

En fait, on peut faire un squelette qui n’affiche que la derniere
version dans une langue pour eviter le hack (les anciennes versions
resteraient theoriquement accessibles en ligne).
Mais ca ne resoud pas le pb des documents et mots, ni de l’historique
(qui n’est alors pas perdu mais morcelé).

Gérer correctement le versionning à partir de la gestion des langues impose me semble-t-il de traiter la publication de manière différente, la mutualisation n’est-elle pas source de complexité ?

A partir du moment ou on fait un hack de articles.php3, on peut imaginer
recreer un nouvel article avec copie de l’historique et des liaisons de
documents, mots …

vi , par contre pour l’historique il faudrait voir pour pas plomber la base …
L’historique des modification pourrait être réintégré au moment de la bascule de l’id en publication ? pour garder au moins un historique sur les versions publié (je n’ai pas assez regardé le code agora sur ce point j’ai vu que c’était géré de façon distoncte c’est tout.

Au moment de la publication de la nouvelle version, il suffit alors
d’eliminer l’ancienne (et les liens document, mot …) et de changer
l’id de la nouvelle (et des liens documents, mots …).

Pour quoi élminer l’ancienne tout de suite, il pourrait y avoir un statut versionné et une purge ultérieure (cela permet de se dispenser de la mise en place de l’historique si c’est juste sur quelques fichiers ?)

C’est sur qu’en s’appuyant sur les fragments, il y a moyen de faire
mieux (en n’enregistrant que des modifs à appliquer et en les appliquant
à la publication de la nouvelle version)

Est-ce utile ? je ne pense pas que la gestion de version soit un besoin si fréquent. donc dupliquer quelques articles ne doit pas être si lourd ? C’est toujours un pb de compromis entre la génération et le calcul des diffs ou la taille de base si on duplique ?
Eventuellement il faudrait avoir un mécanisme de purge, pour éliminer les vielles versions

, mais pour la gestion des
documents et mots clés, on est limité (sauf à traiter une date
d’affectation ou un statut ou des liaisons « pending »…).
Ca depend du fonctionnel recherché, mais la modif d’articles en ligne
est une demande assez classique (avec ou sans validation).

Il y avait une réflexion sur la gestion des modification de document (Paolo de mémoire ?) mais faut peut être pas tout mélanger …

Si j’ai le besoin avant la sortie officielle de la 1.9, j’implanterai
ca sur mon petit fork (tetraspip) sur lequel je dois deja redescendre
l’accès restreint à /ecrire(v1.1) et une gestion de profils étendu(v1.2).
Pour info, ca integre deja pas mal de gadgets (v1.0 :
spip_liste,spip_forms, spipcarto, mots_partout, remplacement de
documents, gestion des forums par admin restreint …).

Merci pour l’info,

Si ca interesse qqun sur la 1.8, le SVN du Lab est ouvert, n’hesitez pas…
Les modifications sont assez limitées et bien identifiées, meme si ca
touche pas mal de fichiers.
Les differents version de ce fork disparaitront naturellement dès que je
pourrais stabiliser une version isofonctionnelle en 1.9 + plugins.

Je suis plus partant pour l’approche plugins, je préfère différer mes besoins que gérer un fork trop complexe (surtout que je n’ai pas accès au svn).

Mes vacances étant finies j’ai moins le temps de « jouer » avec SPIP mais je reste un peu dispo sur le sujet
A+

2

Ventre Arnaud a écrit :

Je me suis permis de changer l'objet du thread pour le ramener sur ce vaste sujet ....

oui, bien que justement, ca ne soit pas une gestion de versions ...
C'est juste un historique des modifications et on voudrait ajouter la possibilité de faire une copie de travail qui repasse dans le circuit de validation avant de se substituer à la version publiée.
c'est important de le prendre comme ca sinon c'est tout de suite le casse tete des branches ...

[...]

    Oui mais il y manque beaucoup de choses pour etre operationnelle à mon
    sens :
    - Quid de l'historique des modification ? (il est dans agora non ?)

    - Quid des documents ?

    - Quid des mots clés ?
    si je rajoute un document ou un mot à la nouvelle, est il reporté à la
    publication ?

Là c'est plus épineux, il ne faudrait pas faire usine à gaz ...

c'etait une question à propos d'Agora.

doublonner les liens lors de la crétaion parait une bonne idée et basculer les id_articles dans les liasons lors de la publication cela permet de garder les document rattaché à l'article et aussi de garder les id document d'origine

Oui mais ca pose le probleme des modifications faites sur la version publiée (ou sur une autre copie de travail).
Coté base, si c'est juste un etat temporaire, ca n'ajoute que le volume du nombre de copie de travail en cours puisqu'au final, on veut garder un seul article

    En fait, on peut faire un squelette qui n'affiche que la derniere
    version dans une langue pour eviter le hack (les anciennes versions
    resteraient theoriquement accessibles en ligne).
    Mais ca ne resoud pas le pb des documents et mots, ni de l'historique
    (qui n'est alors pas perdu mais morcelé).

Gérer correctement le versionning à partir de la gestion des langues impose me semble-t-il de traiter la publication de manière différente, la mutualisation n'est-elle pas source de complexité ?

Les concepts sont quand meme assez proches ... en tous cas, les contraintes techniques sont les memes.
Les 2 grosses differences, c'est :
- qu'on souhaite partir d'une copie conforme
- qu'on souhaite la substituer à la version initiale une fois publiée (quoi que, ca depend des usages et ca peut se gerer dans les boucles de toutes facons).

    A partir du moment ou on fait un hack de articles.php3, on peut
    imaginer
    recreer un nouvel article avec copie de l'historique et des
    liaisons de
    documents, mots ....

vi , par contre pour l'historique il faudrait voir pour pas plomber la base ...

Si c'est temporaire, c'est pas grave ...

L'historique des modification pourrait être réintégré au moment de la bascule de l'id en publication ? pour garder au moins un historique sur les versions publié (je n'ai pas assez regardé le code agora sur ce point j'ai vu que c'était géré de façon distoncte c'est tout.

    Au moment de la publication de la nouvelle version, il suffit alors
    d'eliminer l'ancienne (et les liens document, mot ...) et de changer
    l'id de la nouvelle (et des liens documents, mots ...).

Pour quoi élminer l'ancienne tout de suite, il pourrait y avoir un statut versionné et une purge ultérieure (cela permet de se dispenser de la mise en place de l'historique si c'est juste sur quelques fichiers ?)

La gestion de "revisions" actuelle permet de faire des versions majeures.
Soit on veut le suivi des revision et on souhaite conserver l'ensemble de l'historique une fois les maips faites, soit on ne veut rien.
Dans les 2 cas le remplacement me semble la bonne methode, non ?

    C'est sur qu'en s'appuyant sur les fragments, il y a moyen de faire
    mieux (en n'enregistrant que des modifs à appliquer et en les
    appliquant
    à la publication de la nouvelle version)

Est-ce utile ? je ne pense pas que la gestion de version soit un besoin si fréquent. donc dupliquer quelques articles ne doit pas être si lourd ? C'est toujours un pb de compromis entre la génération et le calcul des diffs ou la taille de base si on duplique ?
Eventuellement il faudrait avoir un mécanisme de purge, pour éliminer les vielles versions

oui, c'est clair qu'un etat archivé, au lieu de supprimer , c'est pas mal.
Mais en fait, je partais du principe qu'on voulais simplement faire des modifications d'un article en ligne.
Il n'est donc pas necessaire de garder la version archivée, c'est juste une revision parmis d'autres

    , mais pour la gestion des
    documents et mots clés, on est limité (sauf à traiter une date
    d'affectation ou un statut ou des liaisons "pending"...).
    Ca depend du fonctionnel recherché, mais la modif d'articles en ligne
    est une demande assez classique (avec ou sans validation).

Il y avait une réflexion sur la gestion des modification de document (Paolo de mémoire ?) mais faut peut être pas tout mélanger ...

Non, je ne parle pas des documents eux meme mais de leurs metas.
A priori, un document n'est pas modifiable une fois uploadé, si il y a une nouvelle version, c'est un nouveau document (mais j'ai mis en place une astuce pour remplacer les documents, ne serait-ce que pour des corrections de coquilles, mais c'est effectivement une autre histoire)
Par contre, on peut vouloir supprimer ou ajouter un document à la nouvelle version de l'article.
Il ne faut pas pour autant que ces documents apparaissent et disparaissent sur la version en ligne.
De meme, si les metas changent (mais ils ne devraient pas ...), il faut savoir si on travail sur les informations en ligne ou non.
si on veut vraiment pouvoir faire ce qu'on veut, il faut tout dupliquer, y compris les documents (en base, pas les fichiers bien sur ...) et tout remplacer à la mise en ligne.

Je suis plus partant pour l'approche plugins, je préfère différer mes besoins que gérer un fork trop complexe

Moi aussi dans la mesure du possible, mais ca ne depend pas forcement de moi.
Je prefererai bosser sur la 1.9, mais c'est pas toujours faisable, ca depend des projets.

(surtout que je n'ai pas accès au svn).

Ca, c'est rien, il suffit de t'ouvrir un compte chez berlios si c'est pas deja fait et je t'ajoute au projet sur le lab.

Mes vacances étant finies j'ai moins le temps de "jouer" avec SPIP mais je reste un peu dispo sur le sujet

On ne coupera pas à un plugin pour la 1.9 donc autant se concentrer la dessus.

@++

3

Mais en fait, je partais du principe qu'on voulais simplement faire des
modifications d'un article en ligne. Il n'est donc pas necessaire de
garder la version archivée, c'est juste une revision parmis d'autres

Ah mais oui, bien sûr ! Ca simplifie drôlement le problème en fait :slight_smile:

-- Fil

4

Fil a écrit :

Mais en fait, je partais du principe qu'on voulais simplement faire des
modifications d'un article en ligne. Il n'est donc pas necessaire de
garder la version archivée, c'est juste une revision parmis d'autres
    
Ah mais oui, bien sûr ! Ca simplifie drôlement le problème en fait :slight_smile:
  

Oui, il faut rester "centré sur les cas d'utilisation" qu'ils disent dans le RUP...
:o)

Bon, dans cette approche, on perd les modifs faites après copie sur l'article en ligne (admin), mais perso, fonctionnellement, ca me conviendrait deja largement
Maintenant est-ce qu'il faut tout dupliquer ou non, à mon sens : tout, meme les documents (en base) de facon à etre vraiment libre de toute modif sans impacter la version en ligne.
Après, on peut flinguer joyeusement la version en ligne et tout ce qui va autour quand on publie la nouvelle.

Pour les documents, ca reste problematique, mais pas plus qu'avant.
Si on change les metas d'un document, ca peut toucher d'autres articles.
La, ca le fera à la publication.

@++

5

Je me suis permis de changer l'objet du thread pour le ramener sur ce vaste sujet ....

Présentation illustrée de ce qu'il est possible de faire avec Zope/Plone, puisqu'on en parlait ces derniers jours :

<http://www.ilrt.bris.ac.uk/publications/conf/vanPy2004/slides.ppt&gt;

-Nicolas