Gestion de Version avec Subversion : Introduction
[Note de l'éditeur : Ceci est un aperçu du premier chapitre de Version Control with Subversion] à sortir chez O’Reilly
La gestion de versions de code est l’art de gérer les modifications d’information. Il s’agit depuis longtemps d’un outil essentiel pour les développeurs, qui passent leur temps à effectuer des petits changements sur leur code puis revenir en arrière le jour d’après. Mais l’utilité de la gestion de versions de code va au-delà des limites du monde du développement logiciel. Partout où des personnes utilisent des ordinateurs pour gérer des données qui changent fréquemment, il y a une place pour la gestion de versions. Et c’est là que Subversion entre en scène.
Ce chapitre présente une introduction sommaire de Subversion : ce que c’est ; ce qu’il fait ; comment l’obtenir.
Qu’est-ce-que Subversion ?
Subversion est un système de contrôle de versions open-source/gratuit. Et donc, Subversion gère les fichiers et répertoires au fil du temps. Une arborescence de fichiers est placée dans un dépôt central (repository). Le repository est un peu comme un serveur de fichiers ordinaire, excepté qu’il se souvient de toutes les modifications faites sur les fichiers et les répertoires. Ceci vous permet de retrouver d’anciennes versions de données ou de suivre l’historique des changements. De ce point de vue, certaines personnes voient le système de gestion de version comme une machine à remonter le temps.
Subversion peut accéder à son repository par le réseau, ce qui lui permet d’être utilisé par différents ordinateurs. Jusqu’à un certain point, la possiblité offerte à plusieurs personnes de modifier et gérer les mêmes données de différents endroits permet d’améliorer la collaboration. La progression est plus rapide quand il n’y a pas qu’un seul point par lequel doivent s’effectuer toutes les modifications. Et comme le travail est versionné, il n’y a pas de risque de perte de données en perdant cette référence unique–si des modifications incorrectes sont apportées, il suffit d’annuler ces modifications.
Certains système de gestion de version sont également des systèmes de gestion de configuration de logiciel. Ces systèmes sont spécialement étudiés pour gérer des arborescence de code source, et ont de nombreuses fonctionnalités qui sont spécifiques au développement logiciel. Subversion, cependant, n’en fait pas partie. C’est un système général qui peut être utilisé pour gérer toutes collections de fichiers. Pour vous, ces fichiers peuvent être du code–pour d’autres, tout depuis une liste de courses juqu’à une liste de vidéos.
L’Histoire de Subversion
Au début 2000, la société CollabNet, Inc. a commençé à rechercher des développeurs pour écrire un substitut à CVS. CollabNet propose une suite logicielle de collaboration appelée SourceCast, dont un des composants est un système de gestion de versions. Bien que SourceCast utilisait CVS pour son système de gestion de version initiale, les limitations de CVS étaient évidentes depuis le début, et CollabNet savait qu’il faudrait un jour ou l’autre trouver quelque chose de mieux. Malheureusement, CVS était devenu un standard de facto dans le monde de l’open source, en grande partie parce qu’il n’y avait rien de mieux, au moins sous licence libre. A cause de cela, CollabNet se décida à écrire un nouveau système de gestion de code en partant de zéro, en s’inspirant des idées de base de CVS, mais sans les bugs ni les erreurs de conception.
En février 2000, la société a contacté Karl Fogel, l’auteur de Open Source Development with CVS / Développement de Logiciel Libre avec CVS (Coriolis, 1999), et lui a demandé s’il pouvait travailler sur ce nouveau projet. Coïncidence, à ce moment, Karl était déjà en discussion avec un ami, Jim Blandy, sur la conception d’un nouveau système de gestion de code. En 1995, ils avaient créé Cyclic Software, une société offrant des contrats de support pour CVS, et bien qu’ils aient vendu la société, ils utilisaient encore CVS quotidiennement dans leur travail. Leur frustration avec CVS a conduit Jim à réfléchir à de meilleures façons de gérer des versions de données. Il avait déjà pensé non seulement au nom Subversion, mais également à la conception de base du repository. Quand CollabNet appelle, Karl accepte immédiatement de travailler sur le projet, et Jim obtient de son employeur, RedHat Software, de l’affecter au projet pour une période indéterminée. CollabNet emploie Karl et Ben Collins-Sussman, et le travail sur une conception détaillée commence en mai. Avec l’aide d’autres développeurs tels que Brian Behlendorf et Jason Robbins de CollabNet, et Greg Stein (qui était à l’époque un développeur indépendant travaillant sur les spécifications de WebDAV/DeltaV), Subversion attira rapidement une communauté active de développeurs. Il se trouve que de nombreuses personnes ont des expériences frustrantes avec CVS et sont heureuses de pouvoir enfin y mettre un terme.
L’équipe originelle de conception s’est donnée des buts simples. Elle ne souhaitait pas proposer de méthodes révolutionnaires, mais simplement réparer CVS. Elle décida que Subversion égalerait CVS en fonctionnalités, et préserverait le même modèle de développement sans répéter les problèmes évidents de CVS. Et bien qu’il ne devait pas être un substitut trait pour trait de CVS, il devait être suffisamment semblable pour permettre à tout utilisateur de CVS d’y passer avec un minimum d’efforts.
Après quatorze mois de développement, Subversion vit le jour le 31 août 2001. Les développeurs purent stopper l’utilisation de CVS pour gérer les versions de Subversion, et commencer à utiliser Subversion lui-même.
Alors que CollabNet a initialisé et fournit encore une large partie du travail (elle paie les salaires de quelques développeurs à plein temps), Subversion est géré comme la plupart des projets open-source, gouverné par un ensemble de règles souples et transparentes qui récompensent les plus méritants. Le copyright de la licence de CollabNet est complètement compatible avec les lignes données par le logicel libre de Debian. En d’autres termes, n’importe qui est libre de télécharger, modifier, et redistribuer Subversion comme bon lui semble ; aucune autorisation, même de CollabNet, n’est requise.
Les Fonctionnalités de Subversion
Plutôt que de discuter des fonctionnalités que Subversion apporte au monde de la gestion de versions de code, il est plus facile d’en parler en les comparant à celles de CVS. Si vous ne connaissez pas CVS, il est possible que vous ne compreniez pas certaines de ces fonctionnalités. Et si vous n’êtes pas du tout familier avec la gestion de versions de code, il se peut que vous ne compreniez rien en attendant de lire le chapitre 2 dans lequel nous en proposons une petite introduction.
Subversion offre :
- Version au niveau Répertoire
- CVS gère uniquement l’historique des fichiers individuels, mais Subversion implémente un système de fichiers versionné virtuel qui gère les modifications sur l’arborescence entière au cours du temps. Fichiers et répertoires sont versionnés.
- Véritable historique de versions
- Comme CVS est limité à la gestion de fichiers, des opérations comme la copie ou le changement de nom –qui peuvent survenir sur des fichiers mais qui sont également des changements au niveau des répertoires qui les contiennent– ne sont pas supportées dans CVS. De plus, avec CVS, vous ne pouvez pas remplacer un fichier versionné avec un nouvel élément par un fichier du même nom sans que ce nouvel élément hérite de l’historique de l’ancien fichier –qui peut n’avoir aucun rapport avec le nouveau– fichier. Avec Subversion, vous pouvez ajouter, supprimer, copier et renommer fichiers et répertoires. Et chaque nouveau fichier commence un nouvel historique.
- Commit atomiques
- Un ensemble de modifications est soit complètement entériné, soit pas du tout. Ceci permet aux développeurs de construire et d’entériner les modifications par blocs logiques, et ainsi d’empêcher les problèmes qui peuvent intervenir quand une partie des modifications seulement a pu être acceptée.
- Metadata versionnées
- Chaque fichier et répertoire possède un ensemble de propriétés -des clés et leur valeur– associées. Il est possible de créer et stocker n’importe quel type de couple clé/valeur. Les propriétés sont versionnées, tout comme le contenu des fichiers.
- Choix des couches réseaux
- Subversion a une vue abstraite de l’accès au repository, ce qui facilite l’implémentation de nouveaux mécanismes réseau. Subversion peut être associé au serveur HTTP Apache par un module d’extension. Ceci donne à Subversion un gros avantage en stabilité et interopérabilité, ainsi qu’un accès immédiat aux fonctionnalités existantes offertes par les serveurs –authentification, autorisation, compression et plus. Une version allégée et autonome de Subversion serveur est aussi disponible. Ce serveur utilise un protocole spécifique qui peut être utilisé en mode tunnel sur SSH.
- Gestion consistante des données
- Subversion exprime les différences entre fichiers par l’utilisation d’un algorithme de différenciation binaire qui travaille de façon identique entre des fichiers texte (lisibles par l’homme) et binaire (illisibles). Les deux types de fichiers sont stockés de façon équivalente, compressés dans le repository, et les différences sont transmises dans les deux directions à travers le réseau.
- Gestion efficace des branchements et labels
- Le coût de la gestion des branchements et labels ne devrait pas être proportionnel à la taille du projet. Subversion crée des branches et labels en copiant simplement le projet, en utilisant un mécanisme semblable au lien (unix). Mais cette opération est très rapide.
- Extensibilité
- Subversion n’a pas de bagage historique ; il est implémenté sous forme de collection de librairies C partagées avec une API bien définie. Ceci fait que Subversion est très facile à maintenir et utilisable par d’autres applications et langages.
L’architecture de Subversion
La figure 1-1 illustre ce qu’on pourrait appeler une vue à un kilomètre du design de Subversion.
Figure 1-1. Architecture de Subversion
D’un côté un repository de Subversion qui contient vos données versionnées. D’un autre côté votre client Subversion qui gère des “miroirs” de portions de ces données versionnées (appelées copies de travail). Entre ces deux extrêmes, il existe de nombreuses voies à travers différentes couches de Repository Access (RA). Certaines de ces voies passent au travers du réseaux et de serveurs qui accèdent au repository. D’autres court-circuitent complètement le réseau et accèdent au repository directement.
Installation de Subversion
Subversion est construit sur une couche portable appelé APR (Apache Portable Runtime). Cela signifie que Subversion doit pouvoir fonctionner sur tout système d’exploitation sur lequel tourne le serveur httpd Apache : Windows, Linux, toules les BSD, Mac OS X, Netware, et les autres.
La manière la plus simple d’obtenir Subversion est de télécharger un paquet du binaire adapté à votre système d’exploitation. Le site Subversion propose une liste de ces paquets mis à disposition par des bénévoles. Le site propose généralement un module graphique d’installation pour les utilisateurs des systèmes d’exploitation de Microsoft. Si vous utilisez un système Unix ou assimilé, vous pouvez utiliser le paquet correspondant à la distribution de votre système (RPM, DEB,…etc…).
Autrement, il vous est possible de compiler Subversion directement depuis le code source. Sur le site de Subversion, téléchargez la dernière livraison de code. Après l’avoir décompressée, suivez les instructions du fichier INSTALL pour le compiler. Il est à noter que le code source contient tout les éléments pour construire un client en mode ligne de commande qui vous permettra de gérer le repository distant (en particulier, les libraries apr, apr-util et neon). Mais d’autres portions optionnelles de Subversion possèdent de nombreuses dépendances telles que Berkeley DB, et éventuellement l’httpd d’Apache. Si vous souhaitez un binaire complet, assurez-vous que vous avez tous les paquets indiqués dans le fichier INSTALL. Si vous envisagez de travailler sur Subversion lui-même, vous pouvez utiliser votre client pour récupérer les toutes dernières version de code. Ceci est documenté dans “Get the Source Code”.
Les Composants de Subversion
Subversion, une fois installé, propose différents éléments. Ce qui suit est un aperçu rapide de ce qui est disponible. Ne vous inquiétez pas si vous ne comprenez pas tout — il y a plein d’autres pages dans ce livre pour éclaircir ce trouble.
- svn
- Le programme client en ligne de commande
- snversion
- Le programme permettant d’afficher l’état actuel (concernant les différente révisions) d’une copie de travail
- svnlook
- Un outil pour inspecter un repository
- svnadmin
- Un outil pour créer, gérer ou réparer un répository
- svndumpfilter
- Un programme pour filtrer les fichiers dump d’un repository
- mod_dav_syn
- Un module plug-in pour le serveur HTTP Apache, pour rendre votre repository disponible à d’autres depuis le réseau
- svnserve
- Le programme serveur qui peut être lancé comme un processus démon ou invocable par SSH ; une autre manière de permettre à d’autres d’accéder au repository à travers le réseau
En considérant que vous avez correctement installé Subversion, vous devriez être prêt à commencer. Les deux chapitres suivants (du livre de l’auteur) vous indiqueront comment utiliser svn, le client en ligne de commande de Subversion.
Textes originaux en anglais sur O’Reilly : Version Control with Subversion: Introduction par Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato
Chargement
Commentaires récents