Subversion est un logiciel libre de gestion de versions. Cela veut dire que Subversion gère les fichiers et les répertoires, ainsi que les changements que vous y apportez au fil du temps. Cela vous permet de revenir à d'anciennes versions de vos données ou d'examiner la façon dont vos données ont évolué. De ce point de vue, beaucoup de gens se représentent un système de gestion de versions comme une sorte de « machine à remonter le temps ».
Subversion peut fonctionner en réseau, ce qui lui permet d'être utilisé par des personnes travaillant sur des ordinateurs différents. D'une certaine manière, la possibilité offerte à plusieurs personnes de modifier et de gérer le même ensemble de données depuis différents sites favorise la collaboration. Les choses progressent plus vite quand on évite d'avoir un canal unique à travers lequel toutes les modifications doivent passer. Et comme les modifications sont suivies en versions, pas d'inquiétude à avoir, l'absence d'un tel canal n'a pas pour contrepartie une perte de qualité : si des changements inadéquats sont appliqués aux données, il suffit de les annuler.
Certains systèmes de gestion de versions sont aussi des systèmes de gestion de configuration logicielle (GCL). Ces systèmes sont spécialement conçus pour gérer des arborescences de code source et possèdent de nombreuses fonctionnalités propres au développement logiciel, comme la reconnaissance des langages de programmation ou des outils de construction/compilation de logiciel. Subversion, cependant, ne fait pas partie de cette catégorie. C'est un système généraliste qui peut être utilisé pour gérer n'importe quel ensemble de fichiers. Pour vous ce sera peut-être du code source ; pour d'autres ça ira de de la liste de courses jusqu'aux vidéos des vacances et bien au-delà.
Si, en tant qu'utilisateur ou administrateur système, vous réfléchissez à la mise en place de Subversion, la première question à vous poser est :« Est-ce que c'est l'outil adéquat pour ce que je veux faire ? » Subversion est un marteau fantastique, mais il faut faire attention à ne pas assimiler tout problème à un clou.
Si vous avez besoin d'archiver de vieilles versions de vos fichiers et dossiers, éventuellement de les ressusciter, ou d'examiner les journaux détaillant leurs évolutions, Subversion est l'outil idéal pour vous. Si vous avez besoin de travailler sur des documents en collaboration avec d'autres personnes (habituellement via un réseau) et de conserver la trace de qui a apporté quelles modifications, Subversion fera également l'affaire. C'est pourquoi Subversion est souvent utilisé dans des environnements de développement logiciel ; travailler au sein d'une équipe de développement est par nature une activité sociale et Subversion rend très facile la collaboration entre programmeurs. Bien sûr il existe aussi un coût lié à l'utilisation de Subversion en termes d'administration système. Vous devrez gérer un dépôt de données qui stockera les informations ainsi que tout leur historique et vous assurer qu'il est bien sauvegardé. En travaillant au jour le jour avec les données, vous ne pourrez pas copier, déplacer, renommer ou supprimer des fichiers de la façon dont vous le faisiez auparavant. À la place, vous devrez accomplir tout ceci via Subversion.
En supposant que cette quantité de travail supplémentaire ne vous pose pas de problème, vous devriez quand même vérifier que vous n'allez pas utiliser Subversion pour résoudre un problème que d'autres outils pourraient résoudre de manière bien plus efficace. Par exemple, parce que Subversion fournit une copie des données à tous les utilisateurs concernés, une erreur courante est de le traiter comme un système de distribution générique. Les gens utilisent parfois Subversion pour partager d'immenses collections de photos, de musique numérique ou de packs logiciels. Le problème est que ce type de donnée ne change en général jamais. La collection grandit au fil du temps, mais les fichiers individuels à l'intérieur de la collection ne changent pas. Dans ce cas, utiliser Subversion est « disproportionné ». [3] Il existe des outils plus simples, capables de copier des données efficacement sans s'embarrasser de toute la gestion du suivi des modifications, tels que rsync ou unison.
Au début des années 2000, CollabNet, Inc.(http://www.collab.net) commença à rechercher des développeurs pour écrire un remplaçant à CVS. CollabNet fournit une suite logicielle collaborative appelée « CollabNet Enterprise Edition (CEE) » dont l'un des composants est la gestion de versions. Même si CEE utilisait CVS comme système de gestion de versions initial, les limitations de celui-ci étaient évidentes depuis le début, et CollabNet savait qu'il lui faudrait au final trouver quelque chose de mieux. Malheureusement, CVS était devenu le standard de fait dans le monde du logiciel libre, essentiellement parce qu'il n'y avait rien de mieux, en tout cas sous licence libre. Donc CollabNet décida d'écrire un nouveau système de gestion de versions ex nihilo, en conservant les idées de base de CVS, mais sans ses bogues ni ses limitations fonctionnelles.
En février 2000, CollabNet contacta Karl Fogel, l'auteur de Open Source Development with CVS (Coriolis, 1999), et lui demanda s'il aimerait travailler sur ce nouveau projet. Il se trouve qu'au même moment Karl ébauchait la conception d'un nouveau système de gestion de versions avec son ami Jim Blandy. En 1995, ils avaient créé ensemble Cyclic Software, une société fournissant des contrats de support pour CVS, et bien qu'ils aient plus tard revendu la société, ils utilisaient toujours CVS quotidiennement dans leur travail. Leurs frustrations à propos de CVS avaient conduit Jim à élaborer mentalement de meilleures façons de gérer les données suivies en versions. Il avait déjà non seulement trouvé le nom de « Subversion », mais aussi les principes de base du stockage de données de Subversion. Quand CollabNet les appela, Karl accepta immédiatement de travailler sur le projet et Jim obtint de son employeur, Red Hat Software, qu'il le délègue au projet pour une durée indéterminée. CollabNet embaucha Karl et Ben Collins-Sussman, et le travail de conception détaillée commença en mai. Grâce à des coups de pouce efficaces de Brian Behlendorf et Jason Robbins de CollabNet, et de Greg Stein (qui travaillait alors en tant que développeur indépendant, et participait aux spécifications du projet WebDAV/DeltaV), Subversion attira rapidement une communauté de développeurs actifs. Il s'avéra que beaucoup d'entre eux avaient eu les mêmes expériences frustrantes avec CVS, et ils saisirent l'opportunité de pouvoir enfin y faire quelque chose.
L'équipe d'origine se mit d'accord sur quelques objectifs simples. Ils ne voulaient pas inventer de nouvelles méthodes de gestion de versions, ils voulaient juste corriger ce qui n'allait pas dans CVS. Ils décidèrent que Subversion reprendrait les fonctionnalités de CVS et préserverait son modèle de développement, mais ne reproduirait pas ses faiblesses les plus évidentes. Malgré le fait que Subversion devait pouvoir avoir ses propres spécificités, il devait être suffisamment semblable à CVS pour que n'importe lequel de ses utilisateurs puisse facilement passer à Subversion.
Le 31 août 2001, après 14 mois de codage, Subversion devint « auto-hébergeant ». Ce qui veut dire que les développeurs de Subversion cessèrent d'utiliser CVS pour gérer le propre code source de Subversion, et commencèrent à utiliser Subversion à la place.
Bien que CollabNet ait initié le projet, et qu'ils subventionnent encore une grosse partie du travail (en payant les salaires complets de quelques développeurs de Subversion), Subversion fonctionne comme la plupart des projets de logiciel libre, dirigé par un ensemble de règles vagues et transparentes qui encouragent la méritocratie. La licence CollabNet est parfaitement conforme aux principes du logiciel libre selon Debian (« Debian Free Software Guidelines » en anglais). Autrement dit, chacun est libre de télécharger, modifier et redistribuer Subversion comme il le veut ; aucune autorisation de CollabNet ou de quiconque n'est nécessaire.
La Figure 1, « Architecture de Subversion » donne une vue d'ensemble du schéma de conception de Subversion.
D'un côté, nous avons un dépôt Subversion qui contient toutes vos données suivies en versions. De l'autre côté, il y a votre programme client Subversion, qui gère des versions locales (appelées « copies de travail ») de certaines de ces données suivies en versions. Entre ces deux extrêmes, il y a des chemins variés utilisant différentes couches d'accès au dépôt. Certains de ces chemins passent par des réseaux informatiques et des serveurs réseau avant d'atteindre le dépôt. D'autres court-circuitent complètement le réseau et accèdent directement au dépôt.
Une fois installé, Subversion est constitué de nombreux composants. Ce qui suit est un survol rapide de ce que vous obtenez. Ne vous inquiétez pas si certaines de ces brèves descriptions vous laissent dubitatif ; ce livre contient de nombreuses pages destinées à dissiper toute confusion.
- svn
-
Le programme client en ligne de commande.
- svnversion
-
Un programme permettant d'examiner l'état d'une copie de travail (en termes de révisions des éléments présents).
- svnlook
-
Un outil qui permet d'examiner directement un dépôt Subversion.
- svnadmin
-
Un outil destiné à la création, la modification ou la réparation d'un dépôt Subversion.
- mod_dav_svn
-
Un greffon pour le serveur HTTP Apache, utilisé pour rendre votre dépôt disponible à d'autres personnes à travers un réseau.
- svnserve
-
Un serveur autonome créé sur mesure pour Subversion, pouvant fonctionner comme un processus démon ou pouvant être invoqué par SSH ; une autre façon de rendre votre dépôt accessible à d'autres personnes à travers un réseau.
- svndumpfilter
-
Un programme qui permet de filtrer les flux d'exports de l'historique de vos dépôts.
- svnsync
-
Un programme capable de synchroniser de manière incrémentale un dépôt avec un autre dépôt à travers un réseau.
La première édition de ce livre a été publiée en 2004, peu après que Subversion ait atteint la version 1.0. Durant les quatre années qui suivirent, cinq nouvelles versions majeures de Subversion sont sorties, corrigeant des bogues et ajoutant de nouvelles fonctionnalités majeures. Bien que nous ayons réussi à tenir à jour la version en ligne de ce livre jusqu'à aujourd'hui, nous sommes ravis que la seconde édition de O'Reilly traite jusqu'à la version 1.5, qui correspond à une étape très importante du projet. Voici un résumé rapide des changements majeurs qui ont eu lieu depuis Subversion 1.0. Cette liste n'est pas exhaustive ; pour tous les détails, merci de vous rendre sur le site web de Subversion à l'adresse http://subversion.tigris.org.
- Subversion 1.1 (septembre 2004)
-
En version 1.1 fut introduit FSFS qui permet de stocker le dépôt sous forme de fichiers textes. Bien que les bases Berkeley DB soient toujours très utilisées et supportées par la communauté, FSFS est devenu le choix par défaut pour la création de nouveaux dépôts, grâce à sa prise en main facile et à ses besoins minimes en termes de maintenance. Dans cette version ont également été ajoutées les possibilités de suivre en versions des liens symboliques et de prendre en compte automatiquement des URLs, ainsi qu'une interface utilisateur régionalisée.
- Subversion 1.2 (mai 2005)
-
La version 1.2 introduisit la possibilité de créer des verrous sur les fichiers côté serveur, sérialisant ainsi l'accès des propagations à certaines ressources. Bien que Subversion soit toujours fondamentalement un système de gestion de versions à accès simultanés, certains types de fichiers binaires (par exemple des images de synthèse) ne peuvent pas être fusionnés. Le mécanisme de verrouillage répond aux besoins de suivi en versions et de protection de ces données. Avec le verrouillage est également apparue une implémentation complète de l'auto-versionnement WebDAV, permettant aux dépôts Subversion d'être accessibles sous la forme de dossiers partagés sur le réseau. Enfin, Subversion 1.2 commença à utiliser un nouvel algorithme plus rapide de différenciation de données binaires pour compresser et récupérer de vieilles versions de fichiers.
- Subversion 1.3 (décembre 2005)
-
Avec la version 1.3, le serveur svnserve sait contrôler les droits en fonction des chemins, ce qui correspondait à une fonctionnalité existant uniquement à cette époque dans le serveur Apache. Cependant, le serveur Apache bénéficia lui-même de nouvelles fonctionnalités de journalisation et les API de connexion entre Subversion et d'autres langages firent également de grands pas en avant.
- Subversion 1.4 (septembre 2006)
-
En version 1.4 fut introduit un tout nouvel outil, svnsync, permettant la réplication, dans une seule direction, d'un dépôt via le réseau. Des parties importantes des métadonnées des copies de travail changèrent de format afin de ne plus utiliser XML (avec pour conséquence des gains en rapidité côté client), tandis que le gestionnaire de base de données des dépôts Berkeley DB acquit la capacité de rétablir les bases automatiquement suite à un crash du serveur.
- Subversion 1.5 (juin 2008)
-
Sortir la version 1.5 prit beaucoup plus de temps que les autres versions, mais la fonctionnalité vedette était titanesque : le suivi semi-automatisé des branches et des fusions. Ce fut une véritable bénédiction pour les utilisateurs et propulsa Subversion bien au-delà des possibilités de CVS, le plaçant à la hauteur de ses concurrents commerciaux tels que Perforce et Clearcase. En version 1.5 tout un tas d'autres fonctionnalités axées sur l'utilisateur furent introduites, telles que la résolution interactive des conflits entre fichiers, les extractions partielles, la gestion des listes de modifications côté client, une nouvelle syntaxe très puissante pour les définitions externes et le support par le serveur svnserve de l'authentification par SASL.