"J'utilise CVS depuis quelque temps déjà et récemment SVN pour mes projets importants sous TYPO3 afin de répondre aux exigences de mes clients.

En général, il faut se poser la question de l'utilité de faire du versioning avec TYPO3. Concernant les extensions que vous développez, cela parait évident. Si vous modifiez en local les extensions téléchargées depuis le TER, un versioning s'impose pour faire un MERGE entre vos modifications et celles du TER. Ceci est également valable pour le Typo3 core lorsque vous ajoutez des hooks par exemple. Enfin, le versioning permet de suivre plus facilement les mises à jour de sécurité.

Vous pouvez également passer sous versioning vos typoscripts, css, javascript, html, ... bref, tout ce qui fait partie de votre site et inutile de vous dire que l'on passe souvent pas mal de temps à travailler sur les typoscripts ou les css, d'où l'utilité.

Et concernant les fichiers media, genre images ou pdf ? C'est parfois nécessaire dans un processus de workflow ou bien si c'est le client qui vous l'impose mais ce système rencontre ici des limites (d'après mon expérience). Un client vous demandera de faire un rollback de votre système, c'est à dire de mettre en ligne une version du site à telle date. Le versioning de TYPO3 s'applique uniquement sur le contenu stocké en base de données et non sur les fichiers.

Evidemment, tous les fichiers générés automatiquement (typo3temp, localconf.PHP ,
typo3conf/fichiers temporaires, typo3conf/l10n, ... etc) doivent être en dehors du projet SVN. Vous pouvez faire des sauvegardes régulières du fichier localconf.php. A titre personnel, j'ai un fichier "localconf.OK.php" sous versioning et si mon fichier de production localconf.php est corrompu, je n'ai qu'à l'écraser avec ma sauvegarde.

En général, vous rencontrerez toujours des problèmes si vous pouvez modifier à la fois vos fichiers sous SVN avec un checkout et avec l'interface web de TYPO3. Un conseil : pour les fichiers mis à jour absolument par TYPO3 (typo3temp,localconf,fileadmin/_temp_), écartez SVN !

Pour les fichiers dont la mise à jour via TYPO3 est optionnelle, désactivez là. par exemple, typo3conf/ext ne devrait pas être accessible depuis le backend mais seulement depuis le SVN. Si vous avez plusieurs installation de TYPO3, ne conservez qu'un seul repository plutôt que de rajouter le même code encore et encore. Veillez également à surveiller le contenu des extension que vous téléchargez. Certaines comportent des traces de fichiers CVS... il faut impérativement les supprimer, sous peine de les voir dans votre SVN.

Vous devriez mettre le plus possible de code typoscript et de TSConfig dans des fichiers externes afin qu'ils soient sous SVN. D'ailleurs, ca peut être pratique si vous utilisez Pspad et "SweeTS" (http://typo3.area42.de). Si vous avez des informations sensibles dans vos typoscripts, je vous conseille de les placer dans fileadmin, genre fileadmin/template/{nondusite}/t3s et de configurer Apache de telle sorte que l'accès en lecture soit refusé pour ces répertoires.

Vous pouvez placer le contenu des fichiers contenus dans fileadmin sous subversion mais vous devrez interdire l'écriture depuis le backend de TYPO3 à moins que vous adaptiez le gestionnaire de fichiers pour que celui ci place les nouveaux fichiers dans le repository et gère également les copies, modifications ou suppressions de fichiers avec les commandes appropriées (voir subversion.tigris.org/faq.html - à moins que vous n'implémentiez un client subversion via des hooks dans les fonctions de fichiers).

Ainsi, réussir à faire un "postcommit" (manipulation d'un fichier puis commande SVN), vous permet d'avoir à la fois le fichier chargé dans le SVN et dans fileadmin, ce qui signifie que les éditeurs qui ont le droit d'ajouter de nouveaux fichiers, doivent également disposer d'un client SVN sur leur ordinateur (c'était nécessaire dans mon cas). Ainsi, le module de fichiers de TYPO3 est quasi inutilisé.

Il faut cependant nuancer cette approche. Il est difficile de contrôler les fichiers qui sont réellement sur le site, car TYPO3 copie les fichiers à différents endroits (uploads/pics, uploads/media, etc).

Prenons l'exemple d'un fichier pdf situé dans fileadmin/pdfs. Nous offrons la possibilité de télécharger ce fichier dans le frontend mais il ne s'agira que d'une copie située dans le répertoire uploads. Ainsi, peu importe les changements effectués avec SVN, le fichier en ligne ne refletera pas ces modifications car il ne fait pas référence au fichier d'origine dans fileadmin, mais uniquement à une copie créée lors de l'insertion de l'élément de contenu. Me concernant, c'est une obligation contractuelle d'éviter que de tels scénarios se produisent.

Par contre, le DAM effectue des copies par référence mais à ma connaissance, les extensions doivent supporter le DAM pour que cette copie par référence fonctionne uniformément sur TYPO3. L'autre solution, utilisée surtout avant l'existence du DAM, consiste à interdire l'extension de créer une copie. Ceci devrait s'appliquer à toutes les extensions. Notez que le répertoire uploads ne devrait contenir que les images générées par imageMagick depuis le RTE ; ces fichiers doivent donc être en dehors du projet SVN. Honnêtement, et ce dans une perspective de contrôle étroit du contenu, je suggère d'éviter ce type d'image.

Considérez également que Subversion va occuper plus d'espace qu'un système de fichiers sans versioning. Subversion consomme d'ailleurs plus d'espace que son prédécesseur CVS qui lui, ne créé que 3 fichiers. Si votre hébergement est mutualisé, veillez à disposez d'un espace disque suffisant. La version 1.4 de Subversion à cependant apporté des améliorations à ce niveau.

Biensur, on pourrait se demander pourquoi utiliser TYPO3 de la sorte plutôt qu'un CMS qui intègre de base un versioning. Dans notre cas, le client avait déjà perdu un nombre significatif de ressources avec des CMS couteux qui ne permettaient pas de créer des sites qui répondaient à leurs exigences. Il s'est tourné vers TYPO3 qui s'est révélé meilleur que la concurrence."

Christian Reiter