Voir le texte source

==Découverte de Subversion==
Par Corto

Qu'un projet de développement implique une ou plusieurs personnes, il est vivement conseillé d'utiliser un outil de gestion de versions. Cela devient indispensable dès que le projet commence à grossir. En tout cas si l'on souhaite éviter les galères ! Qui n'a jamais fait des copies de fichiers d'un projet donné sans se demander par la suite quelles étaient les différences entre ces copies ? Qui ne s'est jamais dit : "Mince, mes modifications ne sont pas bonnes, j'aurais dû faire une copie pour revenir à la version antérieure" ? Avec subversion, ces cas ne resteront que de mauvais souvenirs.


==Pour quoi faire ?==

Les outils de gestion de versions propose une assistance au programmeur soucieux de pouvoir tracer les modifications sur son projet. Quand plusieurs personnes travaillent ensemble, leur usage s'impose encore plus (il en va de même pour les outils de gestion de bugs). Il est alors inutile de se dire quel fichier est bloqué et par qui, sans que les autres ne puissent y accéder en modification. Cette façon apparaît comme archaïque à côté des possibilités actuelles.

Voila un peu plus dans le détail les principales propriétés de logiciels comme Subversion ou CVS :

Sauvegarde incrémentale : A chaque fois que des modifications sont considérées comme abouties, le programmeur décide de les valider via une fonction commit qui affecte un numéro de version incrémenté aux fichiers du projet.
Récupération, à l'inverse, des sources d'une version ancienne du projet. Par exemple, imaginons qu'un logiciel ne soit plus développé en 68k à partir de sa version 13, on peut retrouver tous les fichiers de la version 12 pour corriger un bug.
Comparaison de fichiers : On peut demander à visualiser les différences entre deux fichiers, par exemple si on n'a pas commenté des changements et qu'on a oublié où ils se trouvaient.
Intégration automatique des modifications faites par plusieurs personnes sur un même fichier : l'intelligence du logiciel arrive à fusionner des fichiers modifiés de part et d'autre, à partir du moment où les changements n'ont pas été opérés au même endroit. Dans ce dernier cas, il faut réconcilier à la main mais ça évite la plus fastidieuse des opérations !


En plus de tout cela, ce procédé permet d'avoir une sauvegarde à jour et éventuellement sur une machine distante, ce qui augmente la sécurité. Bien sûr, il est aussi possible à tout moment d'obtenir simplement l'historique des modifications ou le status de chaque fichier local du projet.

Si l'on parle de termes "local" et "distant", c'est que Subversion et ses équivalents fonctionnent suivant le principe du client-serveur. Chaque développeur utilise un client depuis son ordinateur pour envoyer des commandes à un serveur qui, lui seul, gère la base de fichiers du projet. Pour cela, le serveur accède au répertoire qui contient d'une manière ou d'une autre les sources et des fichiers de configuration. Ce répertoire est appelé dépôt ou repository.

Ces principes généraux s'appliquent à tous ces outils de gestion de versions. Jusqu'ici, l'outil le plus connu et employé dans la quasi totalité des projets open source se nomme CVS. Le site sourceforge ([[Les projets Amiga Open Source sur SourceForge]]) l'utilise par exemple pour les projets qu'il héberge. Mais CVS n'est pas le seul : .... et le dernier à faire parler de lui et qui a des chances de s'imposer : subversion.

==Atouts de Subversion==

Il ne se cache pas de proposer les mêmes fonctionnalités que CVS, son illustre aîné, mais souhaite pourtant clairement s'en distinguer, par les fonctionnalités et l'approche qu'il offre. Subversion reprend les principes classiques mais en repartant sur des bases saines et en apparaissant plus simple et plus logique.

Avant tout, Subversion laisse une plus grande liberté dans la manipulation des fichiers ... et des répertoires, ce dernier point constituant une nouveauté ! Ainsi, sur un renommage, un déplacement ou une suppression de fichier, CVS se défendait de ne pouvoir le faire en prétextant que cela cassait l'historique du projet. En effet, si on supprime un fichier dans le repository, on perd la trace sur ce fichier. Quoique. On comprend la raison mais CVS aurait dû pallier à ça en interne pour que ces opérations soient faisables par l'utilisateur. Par une approche différente, Subversion autorise toutes ses actions !

Un autre avantage de Subversion dans sa gestion des fichiers est le support des fichiers binaires (icones, image, document, ...) et leur reconnaissance automatique. Cela permet le stockage de tous les fichiers d'un projet et pas seulement ceux liés au développement. Un tel fonctionnement avec CVS impliquait de placer manuellement un flag spécial sur chaque fichier.

Même utilisé en ligne de commandes, la manipulation de l'outil client (svn) est simple et ne requiert pas de paramétrage. Les actions possibles sont explicites et en plus bien documentées dans un fichier PDF de référence, librement téléchargeable. Le client peut se connecter de plusieurs manières au serveur, soit en spécifiant l'adresse IP locale (communication avec le démon serveur) et le répertoire du projet , soit via une connexion HTTP. Ce dernier cas est rendu possible car Subversion est livré avec un module destiné au serveur Apache.

Globalement, Subversion est plus clair dans ses actions et donne du sang neuf par rapport à CVS, mettant en place des concepts importants, comme le commit qui s'applique à l'ensemble des fichiers. Ainsi, on ne valide qu'au moment où on obtient une cohérence globale et pas uniquement quand la compilation d'un fichier réussit dans son coin.


==Pour qui ?==

Subversion offre donc confort et puissance dans la gestion de projet, tout en restant simple et logique. Les bénéficiaires sont nombreux et ne s'arrêtent pas aux seuls développeurs. D'autres peuvent ainsi partager l'accès simultané de fichiers entre plusieurs personnes, pour consultation mais aussi modification. Cela concerne les documents par exemple : combien de fois on en vient à se demander qui a la "bonne version" d'un fichier ou s'il est possible d'avoir la documentation utilisateur de telle date ?

Les membres d'une équipe peuvent ainsi travailler en même temps sur des parties différentes d'un document. De plus, cette gestion permet au passage la sauvegarde et l'archivage sur un serveur distant ! Si des changements ont lieu dans des endroits différents d'un fichier, Subversion les prends en compte automatiquement. Sinon il y a besoin d'une intervention manuelle mais c'est un moindre mal, l'outil ne peut pas non plus tout deviner ! Il y a alors conflit et une des personnes doit corriger le fichier puis dire à Subversion que le conflit est résolu, un commit redevient possible en toute confiance.

Chacun peut aussi s'approprier Subversion avec un minimum d'efforts. La mise en place n'est pas difficile mais il est quand même conseillé d'avoir un serveur sous Linux.
Par contre, encore une fois, les outils s'utilisent en lignes de commandes .... jusqu'à ce qu'une interface soit conçue (avis aux courageux !). Ce n'est franchement pas gênant à l'usage.

Pour améliorer encore l'accessibilité, la documentation est très bien faite, au format PDF et ... gratuite ! Le contenu est pourtant exactement celui du livre vendu dans le commerce. Il faut juste ne pas détester lire sur l'écran et ... comprendre l'anglais (le livre en français vaut 38 Euros, aux éditions O'Reilly).


==En pratique==

A présent, voyons comment on met en oeuvre un serveur et un client Subversion. Ceci est basé sur ma propre expérience, acquise pendant quelques mois, période pendant laquelle j'ai mis plusieurs de mes projets en place.

Tout commence bien sûr par l'installation. Du côté serveur d'abord. Sous Linux Debian, les packages sont facilement récupérable via une recherche dans l'outil graphique Synaptic. L'outil serveur (appelé démon de manière générale) se lance ainsi :
svnserve -d
Toujours sur le poste Linux, le projet doit être créé : "svnadmin create nom_du_projet". Un répertoire est créé ainsi que plusieurs sous-répertoires, dont le repository qui stockera les données de toutes les versions du projet.
Un des sous-répertoire nommé "conf" contient un fichier de paramétrage à modifier absolument. C'est lui qui permettra aussi de déterminer les autorisations en lecture ou écriture sur le projet, en gérant notamment les comptes utilisateurs et leur mot de passe associé.

Le client peut alors être testé. On commence par importer le projet en cours dans le dépôt sur le serveur :
Svn import svn://192.168.0.13/home/mathias/svn/nom_du_projet
Ensuite, toutes les opérations sont possibles : ajouter ou supprimer des fichiers, voir le log des opérations effectuées, visualiser les différences entre deux versions d'un même fichier, etc. Ces commandes sont extrêmement simples à utiliser. Pour ajouter un nouveau fichier juste créé en local : "svn add fichier1.c". La commande "update" est très souvent utilisées et elle sert à mettre à jour les fichiers locaux en fonctions des fichiers du dépôt qui ont été validés (commit, même terme que pour les bases de données).

En cas de problème, il est possible de vérifier son fonctionnement avec un projet online. Dans ce cas, on procède à une opération de checkout (on peut aussi utiliser son diminutif "co") pour récupérer l'ensemble des fichiers et créer une copie locale du projet qui servira de base de travail. Par exemple, pour récupérer les sources de Samba, la commande est la suivante :
svn co svn://svnanon.samba.org/samba/trunk samba-trunk

Toutes les commandes sont documentées et on prend vite le pli. Le status des fichiers, notamment après update, est également assez clair : 
*'''U''' : Mise à jour de la copie locale.
*'''G''' : Des modifications avaient été apportées sur le fichier local et SVN a pu lui intégrer les modifications du repository.
*'''C''' : Idem mais les modifications provenant du repository provoquent un conflit avec les changements apportés en local.

Etc.
Un avant-goût est donné, j'espère qu'il vous aura donné l'envie d'expérimenter.


==Adoption==

Après plusieurs mois d'utilisation (serveur Linux/Debian et client MorphOS), je suis extrêmement satisfait de Subversion et enthousiaste de ne plus avoir à utiliser CVS, performant mais d'une approche moins naturelle. Les projets CVS peuvent d'ailleurs être migrés vers Subversion.

Les outils du côté client sont disponibles pour MorphOS, OS4 et même AmigaOS depuis peu. Ils devraient donc rejoindre les incontournables de votre boîte à outils du développeur : amuidiff, splint, mpatrol, éditeur hexa, ... Outre les facilités apportées pour le développement à plusieurs, les bénéfices peuvent aussi être obtenus en l'utilisant comme serveur de fichiers, outil de backup, ... Rappelons quand même que sa fonctionnalité principale est de modifier des fichiers sources en même temps par des personnes différentes.

Rien que sur cet aspect, Subversion ne se limite pas seulement aux sources de programmes : ceux qui rédigent de la documentation peuvent tout à fait travailler à plusieurs dans ces conditions, les modifications de chacun étant prises en compte automatiquement.

A la clotûre de ce texte, j'ai découvert [http://toutprogrammer.com/article_19.html un article en français détaillé et consacré à Subversion]. Certains passages vont au-dela de ce qu'un débutant a besoin mais chacun peut faire en faire une lecture à son niveau.