Il s’agit de pouvoir gérer la succession des modifications apportées à un article donné (notamment dans un contexte multi-auteurs). Il s’agit donc de : 
stocker au fur et à mesure les différentes versions d’un article (à chaque fois qu’on appuie sur "Valider" dans le formulaire d’édition) régurgiter à la demande, dans l’espace privé, les versions précédentes d’un article, et afficher les différences entre deux versions au choix de l’utilisateur
D’autre part, il serait utile de pouvoir repartir d’une version antérieure à la courante pour créer une nouvelle version, comme dans Spikini.
Mais aussi d’offrir la possibilité, pour un auteur non-administrateur, de créer une nouvelle version d’un article déjà publié, et de proposer cette version à la publication afin de remplacer l’ancienne. Actuellement, les auteurs doivent créer un nouvel article en recopiant l’ancien texte, et contacter un administrateur pour lui demander de remplacer l’ancien texte par le nouveau dans l’article original (l’article ne devant pas changer d’URL id est d’id_article).
Les méta-données (mots-clés, auteurs...) et données attachées (documents) ne font pas partie des données "versionnées".
Cette partie est fonctionnelle. Elle se base sur un stockage consommant très peu d’espace pour chaque version (l’extension ZLib est obligatoire). La dernière version d’un article reste stockée "en clair" dans la table principale afin d’y garantir un accès rapide (c’est la seule version qui peut être consultée dans l’espace public).
L’affichage des différences entre deux versions consiste à récupérer les textes des deux versions (simple) et à "calculer" les différences entre les deux versions (moins simple). Compte tenu des différences entre un texte rédigé et du code informatique, il a fallu écrire quelque chose d’un peu différent du diff Unix traditionnel (souvent adopté dans les Wikis). Le diff SPIP est à étages (il traite d’abord les paragraphes, puis les phrases, puis les mots), et il est capable de détecter le déplacement de paragraphes et de phrases (même s’il y a eu des modifs à l’intérieur).
l’extension ZLib est obligatoire
(NicolasHoizey) Pourquoi ne pas autoriser le versionnage quand même pour ceux qui ne peuvent pas avoir la zlib, mais ont de l’espace à foison ? Et donc rendre le versionnage (dés)activable globalement dans l’admin.
— Parce que la Zlib est utilisée dans les fonctions d’appariement. Y a-t-il des raisons pour "ne pas pouvoir avoir la Zlib" ? Je n’ai pas vu un hébergeur qui ne la proposait pas en PHP4.
C’est un sujet délicat. Il s’agit de gérer une version publiée, et en parallèle des versions ultérieures que leur auteur peut décider de proposer à la publication. Cela introduit cependant un niveau de complexité supplémentaire dans le processus de publication, et des risques de confusion dans l’espace privé (suis-je en train de visionner la version "officielle" de l’article, ou sa dernière version proposée ?). Cela introduit aussi, en quelque sorte, la notion de branche et donc transforme en arbre (explicitement ou non) la suite des versions d’un article, qui jusque là est simplement linéaire...