Tous ceux qui manipulent des fichiers, en souhaitant conserver l’historique de leur travail, trouveront un intérêt à s’appuyer sur un VCS. L’un de leurs principaux intérêts est de permettre le développement mutualisé, avec une gestion des conflits. Pourtant en pratique, il s’avèrera particulièrement utile, même pour un utilisateur isolé.

Son choix parmi les nombreux outils disponibles (centralisé ou réparti) aura nécessairement un impact fort sur le modèle de développement suivi.

Qu’est-ce qu’un ’Système de gestion de versions’ ?

Un VCS (Version System Control) est un outil informatique capable de gérer les évolutions et l’historique d’un ensemble de fichiers et de ressources. Stockant les informations dans un dépôt, il permet de récupérer toutes les versions intermédiaires, ainsi que les différences entre les versions. Il permet à plusieurs développeurs de travailler sur un même projet et effectue la fusion des modifications non conflictuelles en protégeant contre celles qui le sont.

Les mots clés de base :

• Le dépôt ou référentiel ou encore ’repository’ est l’élément de référence contenant l’ensemble des fichiers et informations associées y compris l’historique
• L’espace de travail ou ’working area’ ou encore ’working set’ correspond à l’espace dans lequel on développe et modifie les fichiers
• Une révision est l’identifiant d’un fichier versionné
• HEAD : la dernière révision dans le dépôt
• ’check out’ est l’opération de chargement, copie de fichier(s) depuis le dépôt dans l’espace de travail.
• ajout - ’add’ ajoute le(s) fichier(s) dans le mécanisme de gestion de version
• ’check in’ ou ’commit’ envoie le(s) fichier(s) - si modifié(s) - dans le dépôt ; le fichier acquiert une nouvelle révision et cette dernière version peut être rechargée par d’autres utilisateurs
• Un message de ’commit’ est un message décrivant la modification enregistrée dans le dépôt
• historique - ’log’ ou ’Changelog’ - donne à la liste des modifications
• ’update’ ou ’synch’ synchronise les fichiers locaux avec les autres développeurs ou le dépôt de référence
• ’revert’ permet de revenir sur les dernières modifications locales

Les notions de base communes à tous les VCS :

’Check out’, édition et ’commit’

’branche’ et ’fusion’ (’merge’)

’conflits’

Quel type de VCS choisir ?

A- Le modèle centralisé

Il est caractérisé par un dépôt (repository) privilégié géré par un serveur et une politique stricte d’accès ; chaque développeur travaille sur une copie et synchronise ses évolutions avec le dépôt central, le serveur détectant les conflits. CVS et son successeur Subversion (SVN) sont deux exemples d’outils très utilisés par notre communauté.

Ses points forts :

• la simplicité et la familiarité du modèle
• la maturité et la robustesse des implémentations (surtout SVN)
• le grand nombre d’outils de gestion et d’interfaces, graphiques ou non, disponibles

Subversion :

Principal compétiteur dans notre environnement, c’est le successeur, par conception même, de l’historique CVS. Il bénéficie d’une énorme base installée et d’un grand nombre d’hébergements, CERN y compris. Il est accompagné d’une excellente documentation.

Subversion 1.5

En plus de nombreux bugs corrigés, SVN 1.5 apporte un certain nombre de nouvelles fonctionnalités, dont certaines très attendues :

• La gestion des copies et déplacements de fichiers a été totalement revue et améliorée (déplacement direct du fichier dans l’espace de travail)
• Subversion 1.5 est beaucoup plus rapide (optimisation complète)
• Apparition du ’sparse checkout’ : on peut ne récupérer qu’une partie de projet, et non nécessairement l’intégralité
• Implémentation du ’merge tracking’ : la fusion de 2 branches devient beaucoup plus facile et ne demande plus de gestion manuelle des numéros de révision ... (voir ’svn help mergeinfo’ et ’svn help merge’)

Subversion 2

Prochaine évolution majeure, elle s’inspirera d’un certain nombre de caractéristiques apportées par les DVCS :

• ’offline commits’ : permettant de gérer la granularité de ses commits dans des branches locales
• La gestion de branches locales synchronisées ultérieurement avec le dépôt central
• La centralisation de la gestion des ’metadata’ en un seul endroit de la copie locale (plus de .svn à chaque niveau de la hiérarchie du projet)
• Elle devrait conserver son interface très simple

B- Le modèle réparti

Contrairement au modèle centralisé, il n’impose pas techniquement de dépôt de référence ou privilégié ; chaque développeur travaille avec son dépôt qu’il synchronise avec ceux des co-développeurs et, selon le modèle de développement, avec un dépôt de référence et/ou de publication. Les principaux cités actuellement sont sans doute Git, Mercurial, Bazaar mais il en existe beaucoup d’autres ! Cette famille de VCS a été portée par les développements Open Source et correspond à l’ère du laptop dans le train ...

Ses points forts :

• pas de serveur à installer et à gérer
• travail déconnecté - accès rapide aux dépôts sans réseau
• modèle de développement très souple
• utilisation de branches privées très facilitée

Parmi les VCS décentralisés du moment :

Git

• Écrit essentiellement en C, par Linus Torvalds ...
• Très rapide, robuste et accompagné d’une documentation assez riche
• Il peut être utilisé comme un super client (bi-directionnel) de SVN - voir svn2git
• Adopté par de nombreux projets (Kernel Linux, Android (Google), Ruby on Rails, VLC, ...)
• Mais complexe et présentant une interface compliquée et moins élégante que celle de SVN
• Mais pas encore de version Windows native

Mercurial

• Écrit en Python
• Interface simple et élégante
• Bonnes performances
• Bonne documentation
• Choisi par OpenSolaris, Mozilla

Autres ...

• Bazaar (choisi par MySQL)
• Darcs
• Monotone

Pourquoi et comment choisir ?

Le modèle centralisé est séduisant :

Le modèle est assez simple ; on le connaît, on le pratique, on le maîtrise bien Subversion est pratiquement fourni par défaut et il existe de nombreuses intégrations avec les principaux éditeurs et IDE Enfin, Subversion évolue en intégrant l’expérience acquise avec les DVCS

Le modèle réparti est également séduisant :

Il n’y a plus de serveur à installer et à maintenir et on s’affranchit largement des contraintes du réseau dans le travail quotidien Il permet de démarrer plus facilement et plus souplement une contribution à un projet L’implémentation de mécanismes performants de fusion entre branches simplifie la mise en oeuvre de nouveaux modèles de développement (’workflow’) facilitant le travail collaboratif et la remontée de correctifs ou d’améliorations Une utilisation ’dégradée’ très proche de celle du modèle centralisé et avec un modèle de développement similaire est possible pour minimiser la marche à franchir ... On peut même utiliser certains VCS répartis comme de super clients sur Subversion, les dépôts répartis jouant le rôle d’espace de travail.

Les craintes face au nouveau paradigme :

Dans le modèle centralisé, il n’y a qu’un seul dépôt. Par défaut, tout le travail est public et il est publié dans le seul dépôt partagé. Il est techniquement difficile de travailler de façon privée : cela signifie gérer un gros ’patch’, sans historique et créer un ’fork’ est découragé. Dans le modèle réparti, chaque développeur démarre de façon tout à fait légitime un ’fork’ du projet. En fait, le dépôt ’officiel’ est purement conventionnel ; par défaut tout le travail du développeur est privé et caché ; la publication ne peut être que volontaire et nécessite un certain effort ! La facilité à créer des branches peut faciliter, voire encourager, le développement ’obscur’, sans échanges dans l’équipe et rendant le ’code review’ difficile sinon impossible. Si on considère que l’absence ou le manque de communication au sein d’un projet est un problème de cohésion et de gestion d’équipe et non pas un problème technique dû aux outils, y compris le système de gestion de versions, alors la souplesse et la richesse de fonctionnalités qu’apportent les VCS répartis peuvent valoir l’effort d’adaptation.

Conclusion Aujourd’hui, les diverses implémentations du nouveau modèle réparti semblent matures au point qu’un grand nombre de projets (’open source’) ou d’organisations ont déjà effectué la migration.

Le modèle réparti de gestion de versions apporte certainement une plus grande souplesse de travail. On peut vouloir attendre Subversion 2.0 ou bien, dès maintenant, utiliser un VCS réparti comme client d’un serveur SVN.

Antoire Pérus et Laurent Garnier (LAL)