PRATIQUE OUTILS 
Passer de CVS à Subversion
 
Subversion, extension du célèbre outil de contrôle de version, apporte suffisamment d'innovations, tout en restant proche de son prédécesseur, pour justifier de sauter le pas. La transition pas à pas. (27/01/2006)
  Forum

Réagissez dans les forums de JDN Développeurs

Le contrôle de versions est aujourd'hui une évidence qui a touché nombre de développeurs - et dans le cas contraire, ils feraient bien de se pencher sur la question.

Pouvoir modifier un fichier sans se soucier de conserver d'anciens morceaux de code "au cas où", et revenir à une version précédente d'un fichier donné si le besoin se présente, sont des avantages certains lors de la réalisation d'un projet - surtout lorsque plusieurs personnes travaillent sur un même groupe de fichiers simultanément.

CVS, abréviation de Concurrent Versions System (système de versionnage concurrentiel) a été parmi les premiers de ces outils (1986), et le plus populaire. Il a été conçu à partir de RCS (Revision Control System), en lui ajoutant principalement la capacité de gérer des projets entiers plutôt que seulement des fichiers, ainsi que la gestion de multiples utilisateurs. CVS est un standard de fait, intégré dans la plupart des environnements de développement, comme Eclipse, JBuilder ou Netbeans.

Bien qu'un standard établi, CVS a depuis atteint certaines limites : les fichiers et dossiers ne peuvent pas être directement renommés, les dossiers ne peuvent pas être déplacés, le support Unicode est restreint...

En 2004, certains développeurs de CVS ont lancé Subversion (SVN), dans le but explicite de remplacer CVS tout en construisant sur les bases qu'il a établies. Les capacités de Subversion sont largement étendues, et de nombreux outils récents de gestion de projet, comme Trac, s'intègrent parfaitement avec lui.

Pour beaucoup, l'heure est venue de voir ce que Subversion peut leur offrir... Les projets Python, Apache, WordPress, Samba, Mono, GCC, KDE ou Apache ont déjà réalisé la transition.

Ce qu'apporte Subversion
Outre la possibilité de renommer/déplacer/effacer les fichiers et dossiers tout en conservant leurs historiques, et le support Unicode amélioré, Subversion dispose de sérieux atouts :

 - modification atomique : on peut envoyer des modifications sur plusieurs fichiers tout en garantissant que tous les fichiers seront bien pris en compte. Si une erreur survient, l'ensemble de la mise à jour est annulé.
 - support des fichiers binaires, avec différenciation de versions.
 - seules les modifications sont transférées, et non les fichiers entiers.
 - système de tronc, branches et balises (tags).

Changer de système
Subversion descend de CVS, et les deux systèmes restent très proches, mais les fonctionnements internes diffèrent suffisamment pour justifier l'existence d'outil de conversion : cvs2svn, créé par les auteurs de Subversion, en fait partie. Il s'agit d'un script Python, destiné à ne servir qu'une seule fois (et non pour faire des synchronisations répétées entre CVS et SVN). Il ne faut donc s'en servir qu'une fois le passage d'un système à l'autre clairement validé.

Il reste cependant possible de convertir des répertoires séparément. Une fois les projets entrés dans le dépôt SVN, il est tout a fait possible de déplacer les différents dossiers, tout en conservant leurs historiques.

Un aspect important, à ne pas oublier, est la terminologie utilisée par Subversion, ainsi que ses commandes. Les auteurs de SVN ont fait leur possible pour conserver les commandes standards de CVS, mais lui ont ajouté une palanquée de nouvelles.

Ainsi, on retrouvera les commandes co (checkout), commit, diff ou update, respectivement pour récupérer des modifications, envoyer de nouvelles modifications, voir la différence entre deux versions, et mettre à jour les fichiers du dépôt.

Les habitués de CVS découvriront en revanche move et copy (remplaçant les suites de commandes comme remove/add/commit), revert (retourne à la version précédente d'un fichier), ou status (donne un résumé des modifications depuis la dernière mise à jour d'un utilisateur)...

Reste à intégrer certains concepts, à commencer par les tags et branches. Un projet SVN typique comprend trois dossiers principaux : /trunk, /branches et /tags.

Le premier est l'emplacement de tous les travaux en cours : les modifications au jour le jour se feront dans les fichiers et dossiers de /trunk. /branches, de son côté peut soit servir à gérer de possibles extensions du projet initial (fork), soit à stocker une copie complète du dossier /trunk à un moment donné, par exemple lors de la sortie d'une version majeure du projet. Le dossier /tags, enfin, sert normalement a stocker une version donnée du projet.

Dans les faits, /branches et /tags ne sont que des copies de /trunk, et se gèrent donc de la même manière. On peut ne pas utiliser ces deux dossiers, ou n'en utiliser qu'un seul, et y stocker les fichiers selon les besoins...

Enfin, on pourra profiter avantageusement de l'intégration de SVN avec Apache, en offrant directement un accès sécurisé aux fichiers du dépôt SVN depuis le navigateur Web. L'outil TortoiseSVN fera également le bonheur des utilisateurs Windows.
 
Xavier Borderie, JDN Développeurs
 
 
Accueil | Haut de page