Vous êtes sur la page 1sur 388

Version Control with Subversion

For Subversion 1.5 (Compiled from Revision3825)

Ben Collins-Sussman Brian W. Fitzpatrick C. Michael Pilato

Version Control with Subversion: For Subversion 1.5: (Compiled from Revision3825)
par Ben Collins-Sussman, Brian W. Fitzpatrick, et C. Michael Pilato Date de publication (TBA) Copyright 2002, 2003, 2004, 2005, 2006, 2007, 2008 Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato
This work is licensed under the Creative Commons Attribution License. To view a copy of this license, visit http://creativecommons.org/licenses/by/2.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Table des matires


Avant-propos .......................................................................................................................................... xi Prface ................................................................................................................................................. xiii Public vis .................................................................................................................................... xiii Comment lire ce livre ...................................................................................................................... xiii Conventions utilises dans ce livre .................................................................................................... xiv Organisation de ce livre .................................................................................................................... xv Ce livre est libre ............................................................................................................................. xvi Remerciements .............................................................................................................................. xvi De Ben Collins-Sussman ........................................................................................................ xvii De Brian W. Fitzpatrick ......................................................................................................... xvii De C. Michael Pilato .............................................................................................................. xvii Qu'est-ce que Subversion ? ............................................................................................................ xviii Subversion est-il l'outil appropri ? .......................................................................................... xviii L'histoire de Subversion ........................................................................................................ xviii L'architecture de Subversion .................................................................................................... xix Les composantes de Subversion ................................................................................................ xxi Ce qui a chang dans Subversion ............................................................................................... xxi 1. Notions fondamentales ............................................................................................................................ 1 Le dpt .......................................................................................................................................... 1 Modles de gestion de versions ............................................................................................................ 2 Problmatique du partage de fichiers ............................................................................................. 2 Modle verrouiller-modifier-librer .............................................................................................. 3 Modle copier-modifier-fusionner ................................................................................................ 5 Subversion en action .......................................................................................................................... 8 URL des dpts Subversion ........................................................................................................ 8 Copies de travail ....................................................................................................................... 9 Rvisions ............................................................................................................................... 12 Les copies de travail suivent l'volution du dpt .......................................................................... 14 Copies de travail mixtes, rvisions mlanges ............................................................................ 15 Rsum ......................................................................................................................................... 16 2. Utilisation de base ................................................................................................................................ 17 l'aide ! ....................................................................................................................................... 17 Enregistrement de donnes dans votre dpt ......................................................................................... 17 svn import ............................................................................................................................. 18 Organisation conseille de votre dpt ........................................................................................ 18 Extraction initiale ............................................................................................................................ 18 Interdiction de la mise en cache du mot de passe ........................................................................... 20 Authentification sous un autre nom ............................................................................................. 20 Cycle de travail de base .................................................................................................................... 20 Mettre jour votre copie de travail ............................................................................................. 21 Apporter des modifications votre copie de travail ........................................................................ 21 Examiner les changements apports ............................................................................................ 23 Annuler des changements sur la copie de travail ............................................................................ 26 Rsoudre les conflits (fusionner des modifications) ........................................................................ 27 Propager vos modifications ....................................................................................................... 32 Utilisation de l'historique .................................................................................................................. 33 Affichage de l'historique ........................................................................................................... 33 Dtail des modifications passes ................................................................................................ 35 Navigation dans le dpt .......................................................................................................... 36 Anciennes versions d'un dpt ................................................................................................... 37 Parfois, il suffit de faire le mnage ..................................................................................................... 38 Se dbarrasser d'une copie de travail ........................................................................................... 38 Reprendre aprs une interruption ................................................................................................ 38 Rsum ......................................................................................................................................... 38 3. Sujets avancs ..................................................................................................................................... 40 Identifiants de rvision ..................................................................................................................... 40 Mots-cls de rvision ............................................................................................................... 40 iv

Version Control with Subversion

Dates de rvision ..................................................................................................................... 41 Proprits ...................................................................................................................................... 42 Utilisation des proprits .......................................................................................................... 43 Manipulation des proprits ...................................................................................................... 44 Les proprits et le cycle de travail Subversion ............................................................................. 46 Configuration automatique des proprits .................................................................................... 47 Portabilit des fichiers ...................................................................................................................... 48 Type de contenu des fichiers ..................................................................................................... 48 Fichiers excutables ou non ....................................................................................................... 49 Caractres de fin de ligne .......................................................................................................... 50 Occultation des lments non suivis en versions .................................................................................... 51 Substitution de mots-cls .................................................................................................................. 54 Rpertoires clairsems ..................................................................................................................... 57 Verrouillage ................................................................................................................................... 60 Cration d'un verrou ................................................................................................................ 61 Identification d'un verrou .......................................................................................................... 63 Cassage et vol d'un verrou ........................................................................................................ 64 Communication par l'intermdiaire des verrous ............................................................................. 66 Dfinition de rfrences externes ........................................................................................................ 67 Piquets de rvisions et rvisions oprationnelles .................................................................................... 70 Listes de modifications ..................................................................................................................... 73 Cration et modification d'une liste de modifications ...................................................................... 74 Listes de modifications : des filtres pour vos oprations .................................................................. 75 Limitations des listes de modifications ........................................................................................ 77 Modle de communication rseau ....................................................................................................... 77 Requtes et rponses ................................................................................................................ 77 Mise en cache des lments d'authentification du client .................................................................. 78 Rsum ......................................................................................................................................... 80 4. Gestion des branches ............................................................................................................................ 81 Qu'est-ce qu'une branche ? ................................................................................................................ 81 Utilisation des branches .................................................................................................................... 82 Cration d'une branche ............................................................................................................. 84 Travail sur votre branche .......................................................................................................... 86 Gestion des branches par Subversion : notions cl ......................................................................... 88 Fusions : pratiques de base ................................................................................................................ 88 Ensembles de modifications ...................................................................................................... 89 Comment garder une branche synchronise .................................................................................. 89 Mergeinfo et aperus ............................................................................................................... 93 Retour en arrire sur des modifications ........................................................................................ 94 Rsurrection des lments effacs .............................................................................................. 95 Fusions : pratiques avances .............................................................................................................. 96 Slection la main .................................................................................................................. 97 Syntaxe de la fusion : pour tout vous dire ..................................................................................... 98 Fusions sans mergeinfo ............................................................................................................ 99 Plus de dtails sur les conflits lis aux fusions ..............................................................................100 Blocage de modifications .........................................................................................................101 Historiques et annotations tenant compte des fusions passes ..........................................................101 Prise en compte ou non de l'ascendance ......................................................................................103 Fusions, copies et renommages .................................................................................................104 Blocage des clients qui ne prennent pas en compte les fusions ........................................................104 Recommandations finales sur le suivi des fusions .........................................................................105 Parcours des branches .....................................................................................................................105 tiquettes .....................................................................................................................................107 Cration d'une tiquette simple .................................................................................................107 Cration d'une tiquette complexe .............................................................................................108 Maintenance des branches ...............................................................................................................108 Agencement du dpt .............................................................................................................108 Dure de vie des donnes .........................................................................................................109 Modles courants de gestion des branches ...........................................................................................110 Branches de publication ..........................................................................................................110 Branches fonctionnelles ...........................................................................................................111 Branches fournisseur ......................................................................................................................112 Procdure gnrale de gestion des branches fournisseur .................................................................112 v

Version Control with Subversion

svn_load_dirs.pl .....................................................................................................................114 Rsum ........................................................................................................................................115 5. Administration d'un dpt ....................................................................................................................117 Dfinition d'un dpt Subversion ......................................................................................................117 Stratgies de dploiement d'un dpt ..................................................................................................118 Stratgies d'organisation d'un dpt ...........................................................................................118 Stratgies d'hbergement d'un dpt ...........................................................................................120 Choix du magasin de donnes ...................................................................................................120 Cration et configuration d'un dpt ..................................................................................................123 Cration d'un dpt .................................................................................................................124 Mise en place des procdures automatiques .................................................................................124 Configuration de la base de donnes Berkeley DB ........................................................................126 Maintenance d'un dpt ...................................................................................................................126 Bote outils de l'administrateur ...............................................................................................126 Correction des messages de propagation .....................................................................................129 Gestion de l'espace disque ........................................................................................................130 Rtablissement de bases de donnes Berkeley DB ........................................................................132 Migration des donnes d'un dpt ..............................................................................................133 Filtrage de l'historique d'un dpt ..............................................................................................137 Rplication d'un dpt .............................................................................................................140 Sauvegarde d'un dpt ............................................................................................................145 Gestion des identifiants uniques (UUID) des dpts ......................................................................146 Dplacement et suppression d'un dpt ...............................................................................................147 Rsum ........................................................................................................................................147 6. Configuration du serveur ......................................................................................................................148 Prsentation gnrale ......................................................................................................................148 Choix d'une configuration serveur .....................................................................................................149 Serveur svnserve ....................................................................................................................149 svnserve sur SSH ...................................................................................................................149 Serveur HTTP Apache ............................................................................................................150 Recommandations ..................................................................................................................150 svnserve, un serveur sur mesure ........................................................................................................151 Dmarrage du serveur .............................................................................................................151 Authentification et contrle d'accs intgrs ................................................................................153 Utilisation de svnserve avec SASL ............................................................................................155 Encapsulation de svnserve dans un tunnel SSH ............................................................................157 Astuces de configuration de SSH ..............................................................................................159 httpd, le serveur HTTP Apache .........................................................................................................160 Prrequis ..............................................................................................................................160 Configuration Apache de base ..................................................................................................161 Options d'authentification ........................................................................................................162 Options de contrle d'accs ......................................................................................................166 Fonctionnalits bonus .............................................................................................................169 Contrle d'accs bas sur les chemins .................................................................................................175 Accs au dpt par plusieurs mthodes ...............................................................................................178 7. Personnalisation de Subversion .............................................................................................................181 Zone de configuration des excutables ...............................................................................................181 Agencement de la zone de configuration .....................................................................................181 Configuration via la base de registre Windows .............................................................................182 Options de configuration .........................................................................................................183 Localisation ..................................................................................................................................187 Gnralits sur la localisation ...................................................................................................187 Utilisation des paramtres rgionaux par Subversion .....................................................................188 Utilisation d'diteurs externes ...........................................................................................................189 Utilisation des outils externes de comparaison et de fusion .....................................................................190 Programme externe de comparaison ...........................................................................................190 Programme externe de comparaison de trois fichiers .....................................................................191 Rsum ........................................................................................................................................193 8. Intgration de Subversion .....................................................................................................................194 Organisation des bibliothques en couches successives ..........................................................................194 Couche dpt ........................................................................................................................195 Couche d'accs au dpt ..........................................................................................................199 Couche client ........................................................................................................................200 vi

Version Control with Subversion

Au cur de la zone d'administration de la copie locale ..........................................................................201 Le fichier entries ...............................................................................................................201 Copies originales et proprits des fichiers ..................................................................................201 Utiliser les API ..............................................................................................................................202 APR, la bibliothque Apache de portabilit des excutables ...........................................................202 Prrequis pour les URL et les chemins .......................................................................................203 Utiliser d'autres langages que C et C++ ......................................................................................203 Exemples de code ..................................................................................................................204 Rsum ........................................................................................................................................209 9. Rfrences compltes de Subversion ......................................................................................................210 Le client Subversion en ligne de commande : svn .................................................................................210 Options de svn .......................................................................................................................210 Sous-commandes svn ..............................................................................................................214 svnadmin ......................................................................................................................................280 svnadmin Options .................................................................................................................280 svnadmin Subcommands .........................................................................................................281 svnlook ........................................................................................................................................300 Options de svnlook .................................................................................................................300 svnlook Subcommands ............................................................................................................301 svnsync ........................................................................................................................................318 svnsync Options .....................................................................................................................318 svnsync Subcommands ...........................................................................................................319 svnserve .......................................................................................................................................323 Options de svnserve ................................................................................................................324 svndumpfilter ................................................................................................................................325 svndumpfilter Options .............................................................................................................325 svndumpfilter Subcommands ....................................................................................................325 svnversion ....................................................................................................................................328 mod_dav_svn ................................................................................................................................330 mod_authz_svn ..............................................................................................................................333 Proprits dans Subversion ..............................................................................................................334 Proprits gres en versions ....................................................................................................334 Proprits non gres en versions ..............................................................................................335 Procdures automatiques du dpt .....................................................................................................335 A. Guide de dmarrage rapide avec Subversion ............................................................................................345 Installer Subversion ........................................................................................................................345 Tutoriel rapide ...............................................................................................................................346 B. Guide Subversion l'usage des utilisateurs de CVS ..................................................................................348 Les numros de rvisions sont diffrents .............................................................................................348 Suivi de versions des rpertoires .......................................................................................................348 Davantage d'oprations en mode dconnect .......................................................................................349 Distinction entre les commandes status et update ..................................................................................349 svn status ..............................................................................................................................350 svn update ............................................................................................................................351 Branches et tiquettes .....................................................................................................................351 Proprits des mta-donnes .............................................................................................................351 Rsolution des conflits ....................................................................................................................351 Fichiers binaires et conversions .........................................................................................................351 Gestion de versions des modules .......................................................................................................352 Authentification .............................................................................................................................352 Conversion d'un dpt CVS vers Subversion .......................................................................................352 C. WebDAV et la gestion de versions automatique .......................................................................................353 propos de WebDAV ....................................................................................................................353 Gestion de versions automatique .......................................................................................................354 Interoprabilit des clients ...............................................................................................................355 Applications WebDAV autonomes ............................................................................................356 Greffons WebDAV pour explorateur de fichiers ...........................................................................357 Implmentations de WebDAV en systme de fichiers ....................................................................359 D. Copyright .........................................................................................................................................360 Index ...................................................................................................................................................365

vii

Liste des illustrations


1. Architecture de Subversion ................................................................................................................... xix 1.1. Un authentique systme client/serveur ..................................................................................................... 1 1.2. La situation viter ............................................................................................................................. 2 1.3. Modle verrouiller-modifier-librer ........................................................................................................ 3 1.4. Modle copier-modifier-fusionner .......................................................................................................... 5 1.5. Modle copier-modifier-fusionner (suite) ................................................................................................. 6 1.6. Systme de fichiers du dpt ............................................................................................................... 10 1.7. Le dpt .......................................................................................................................................... 13 4.1. Branches de dveloppement ................................................................................................................ 81 4.2. Structure initiale du dpt ................................................................................................................... 82 4.3. Dpt avec nouvelle copie .................................................................................................................. 84 4.4. Historique des branches d'un fichier ...................................................................................................... 86 8.1. Fichiers et rpertoires en deux dimensions ............................................................................................196 8.2. Prise en compte du temps la troisime dimension de la gestion de versions ! ............................................197

viii

Liste des tableaux


1.1. URL d'accs au dpt ........................................................................................................................... 9 4.1. Commandes de gestion des branches et des fusions .................................................................................115 5.1. Comparaison des magasins de donnes de dpts ...................................................................................121 6.1. Comparaison des fonctionnalits des serveurs Subversion ........................................................................148 C.1. Principaux clients WebDAV ..............................................................................................................355

ix

Liste des exemples


5.1. txn-info.sh (lister les transactions inacheves) ........................................................................................131 5.2. Procdure automatique pre-revprop-change du dpt miroir .....................................................................141 5.3. Procdure automatique start-commit du dpt miroir ...............................................................................141 6.1. Exemple-type de configuration : accs anonyme ....................................................................................167 6.2. Exemple-type de configuration : accs authentifi ..................................................................................168 6.3. Exemple-type de configuration : accs mixte authentifi/anonyme .............................................................168 6.4. Dsactiver compltement les contrles sur les chemins ............................................................................169 7.1. Exemple de fichier de modification de la base de registre (.reg) .................................................................182 7.2. interface-diff.py ...............................................................................................................................191 7.3. interface-diff.bat ..............................................................................................................................191 7.4. interface-diff3.py .............................................................................................................................192 7.5. interface-diff3.bat .............................................................................................................................192 8.1. Utilisation de la couche dpt .............................................................................................................204 8.2. Utilisation de la couche dpt en Python ...............................................................................................206 8.3. Une version de status en Python ..........................................................................................................208

Avant-propos
Karl Fogel Chicago, le 14 mars 2004. Une mauvaise FAQ est compose non pas des questions que posent les utilisateurs, mais de celles que l'auteur de la FAQ voudrait qu'on lui pose. Peut-tre avez-vous rencontr ce type de FAQ : Q : Comment peut-on utiliser Glorbosoft XYZ pour maximiser la productivit de nos quipes ? R : Beaucoup de nos clients veulent savoir comment maximiser la productivit avec notre nouvelle suite bureautique brevete. La rponse est simple : cliquez sur le menu Fichier, puis trouvez Amliorer la productivit plus bas, ensuite Le problme avec de telles FAQ, c'est qu'elles ne sont pas du tout, au sens propre, des FAQ. Personne n'a appel le support technique et demand Comment pouvons-nous amliorer la productivit ? Au lieu de a, les gens posent des questions trs prcises, telles que Comment pouvons-nous configurer le systme de calendrier pour envoyer les rappels deux jours en avance au lieu de 24 heures ? etc. Hlas, il est tellement plus facile d'imaginer des questions que de trouver celles qui sont vraiment frquemment poses. Rdiger une vraie FAQ requiert un effort continu et une bonne organisation : tout au long de la vie du logiciel, les questions poses ainsi que leurs rponses doivent tre suivies de prs, puis rassembles et organises de faon claire et cohrente dans un tout qui doit reflter l'exprience des utilisateurs. Cela ncessite d'tre patient et observateur, tel un naturaliste. Ici, pas de grandes thories ni de discours visionnaires, ce qu'il faut avant tout, c'est ouvrir les yeux et prendre des notes. Ce que j'aime propos de ce livre, c'est qu'il a t cr en suivant ce procd, ce qui se ressent chacune de ses pages. C'est le rsultat direct de la rencontre des auteurs et des utilisateurs. Tout a commenc lorsque Ben Collins-Sussman remarqua que les gens posaient constamment les mmes questions de base sur la liste de diffusion de Subversion : Quelles sont les procdures pour travailler avec Subversion ? Est-ce que les branches et les tiquettes fonctionnent comme dans les autres systmes de gestion de versions ? Comment est-ce que je peux trouver qui a fait telle ou telle modification ? Frustr de voir revenir les mmes questions jour aprs jour, Ben travailla d'arrache-pied pendant un mois durant l't 2002 pour crire The Subversion Handbook, un manuel de soixante pages couvrant toutes les bases de Subversion. Le manuel ainsi crit n'avait pas la prtention d'tre complet, mais il fut distribu avec Subversion pour aider les utilisateurs faire leurs premiers pas dans l'apprentissage de Subversion. Quand O'Reilly and Associates dcidrent de publier un livre complet sur Subversion, la voie la plus facile tait la plus vidente : simplement amliorer The Subversion Handbook. Une opportunit inhabituelle se prsenta donc aux trois co-auteurs de ce nouveau livre. Officiellement, leur tche tait d'crire un livre acadmique , en partant d'une table des matires et d'une premire bauche. Mais ils avaient aussi accs un flux constant, une quantit incontrlable en fait, de ractions en provenance des utilisateurs. Subversion tait dj entre les mains de quelques milliers d'utilisateurs prcoces, et ces derniers envoyaient des tonnes de commentaires, pas seulement sur Subversion, mais aussi sur sa documentation d'alors. Pendant que Ben, Mike et Brian crivaient ce livre, ils surveillrent sans relche la liste de diffusion et les salons de discussion de Subversion, notant consciencieusement les problmes que rencontraient les utilisateurs dans la ralit. Assurer le suivi de ces retours d'expriences faisait de toutes faons partie intgrante de leur travail CollabNet, et cela leur donna un norme avantage quand ils commencrent rdiger la documentation de Subversion. Le livre qu'ils ont crit repose sur un socle d'exprience pratique, pas sur une liste abstraite de bonnes intentions ; il possde la fois les qualits du mode d'emploi et de la FAQ. Cette dualit ne saute pas immdiatement aux yeux. Lu dans l'ordre, de la premire la dernire page, ce livre dcrit de manire simple un logiciel. Il y a la vue d'ensemble, l'incontournable visite guide, le chapitre sur la configuration et l'administration, quelques sujets avancs, et bien videmment une liste complte des commandes ainsi qu'un guide de dbogage. Mais c'est quand on revient chercher dans ce livre une rponse un problme spcifique qu'on ralise son authenticit, faite de dtails rvlateurs ne pouvant provenir que de cas concrets et inattendus, d'exemples tirs de situations relles, et par-dessus tout de l'attention porte aux besoins et aux remarques des utilisateurs. Bien sr, personne ne peut affirmer que ce livre rpondra toutes vos questions sur Subversion. De temps en temps, la prcision avec laquelle il anticipe vos questions vous semblera presque tlpathique ; mais d'autres fois, vous tomberez sur une lacune dans le savoir de la communaut, et vous rentrerez bredouille. Quand cela arrive, le mieux que vous puissiez faire est d'envoyer un courrier lectronique <users@subversion.tigris.org> (en anglais si possible) en y dcrivant votre problme. Les auteurs sont toujours l, l'afft, et il ne s'agit pas seulement des trois personnes cites sur la couverture du livre, mais aussi de beaucoup d'autres contributeurs ayant apport corrections et amliorations. Pour la communaut, rsoudre xi

Avant-propos

votre problme est une composante agrable d'un projet bien plus vaste, celui de peaufiner petit petit ce livre, et finalement Subversion lui-mme, pour encore mieux coller l'utilisation que les gens en ont. Les auteurs sont trs enthousiastes l'ide de communiquer avec vous, pas seulement parce qu'ils peuvent vous aider, mais aussi parce que vous pouvez les aider. Avec Subversion, comme avec tous les projets de logiciels libres en activit, vous n'tes pas seul. Ce livre est votre premier compagnon.

xii

Prface
Il est important de ne pas laisser la perfection devenir l'ennemi du bien, mme lorsque vous pouvez tre d'accord sur ce qu'est la perfection. Encore plus lorsque vous ne le pouvez pas. Aussi dplaisant qu'il soit d'tre pig par les erreurs du pass, vous ne pouvez pas faire de progrs en ayant peur de votre propre ombre pendant la conception. Greg Hudson, dveloppeur de Subversion Dans le monde du logiciel libre, le logiciel Concurrent Versions System (CVS) fut l'outil de choix pour la gestion des versions pendant de nombreuses annes. Et juste titre. CVS tait lui-mme open source et son mode de fonctionnement nonrestrictif coupl son support des oprations rseau permettait des dizaines de programmeurs disperss aux quatre coins du monde de partager leur travail. Cela collait trs bien la nature collaborative de l'open source. CVS et son modle de dveloppement semi-chaotique sont depuis devenus des pierres angulaires de la culture du logiciel libre. Mais CVS n'tait pas parfait et simplement corriger ses dfauts promettait d'tre un norme effort. C'est ici que Subversion entre en jeu. Les crateurs de Subversion l'ont cr pour tre un successeur de CVS et l'ont fait de faon gagner le cur des utilisateurs de CVS de deux faons : en concevant une interface similaire CVS et en tentant d'viter la plupart des dfauts majeurs de CVS. Bien que le rsultat ne soit pas forcment la prochaine volution majeure dans les systmes de gestion de versions, Subversion est trs puissant, parfaitement utilisable et trs flexible. Et la plupart des nouveaux projets en logiciel libre choisissent Subversion au lieu de CVS. Ce livre est crit pour documenter les versions 1.5 du systme de gestion de versions Subversion. Nous avons tent au maximum d'tre complet dans cet ouvrage. Cependant, Subversion a une communaut prospre et dynamique ; il y a donc dj un certain nombre de fonctionnalits et d'amliorations prvues pour des versions futures de Subversion qui peuvent modifier quelques commandes ou rendre caduques certaines notes spcifiques de ce livre.

Public vis
Ce livre est crit pour les personnes dsirant utiliser Subversion pour grer leurs donnes. Subversion fonctionne sur un grand nombre de systmes d'exploitation et son interface premire est en ligne de commande. Ce programme (svn) et certains programmes auxiliaires sont le sujet de ce livre. Par souci de cohrence, les exemples du livre supposent que le lecteur utilise un systme de type Unix et qu'il est relativement l'aise avec ce systme ainsi qu'avec les interfaces en ligne de commande. Cela dit, le programme svn fonctionne galement sur les systmes qui ne sont pas bass sur Unix, tel que Microsoft Windows. Avec quelques petites exceptions, telles que l'utilisation d'anti-slashs (\) au lieu de slashs (/) dans les chemins, les entres et sorties de ce programme sous Windows sont identiques leurs quivalents Unix. La plupart des lecteurs sont probablement des programmeurs ou des administrateurs systmes qui ont besoin de suivre les changements faits du code source. C'est l'utilisation la plus courante de Subversion et c'est ce que l'on supposera tout au long des exemples du livre. Cependant, Subversion peut tre utilis pour grer les changements pour toutes sortes de donnes : images, musique, bases de donnes, documentation, etc Pour Subversion, toutes les donnes sont justes des donnes. Bien que ce livre soit crit en supposant que le lecteur n'a jamais utilis un systme de gestion de versions, nous avons aussi essay de rendre facile le passage de CVS (et autres systmes) Subversion. De temps en temps, quelques encadrs mentionnent d'autres systmes de gestion de versions et une annexe particulire rsume la plupart des diffrences entre CVS et Subversion. Notez galement que les exemples de code source prsents au cours du livre ne sont que des exemples. Mme s'ils compileront avec les commandes de compilation adquates, ils n'ont pour but que d'illustrer une situation particulire et ne sont pas ncessairement de bons exemples de style ou techniques de programmation.

Comment lire ce livre


Les manuels techniques doivent toujours faire face au dilemme suivant : choisir une approche d'apprentissage descendante ou ascendante pour le lecteur ? Un adepte de l'approche descendante prfrera lire ou survoler la documentation, pour obtenir une vision globale du fonctionnement du systme ; partir de ce moment seulement, il commence utiliser le logiciel. Un adepte de l'approche ascendante est plus un autodidacte, il se jette directement dans le logiciel et en comprend au fur et mesure les xiii

Prface

fonctionnalits, se rfrant au manuel en tant que de besoin. La plupart des livres sont crits pour un certain type de lecteur et celui-ci est indubitablement orient pour les adeptes de l'approche descendante (d'ailleurs, si vous lisez ce chapitre, c'est que vous tes probablement dans cette catgorie !). Mais si vous tes autodidacte, ne fuyez pas. Bien que le livre puisse tre vu comme un large survol des fonctionnalits de Subversion, le contenu de chaque paragraphe est gorg d'exemples et d'exercices pratiques. Pour les plus impatients, rendez-vous directement l'Annexe A, Guide de dmarrage rapide avec Subversion. Quelle que soit votre manire d'apprendre, ce livre se veut utile pour des gens ayant des parcours et des comptences trs varis, depuis le novice en gestion de versions jusqu' l'administrateur systme expriment. En fonction de votre exprience, certains chapitres vous sembleront plus ou moins importants. Nous proposons ci-dessous un parcours adapt diffrents types de lecteurs : Administrateur systme expriment Nous supposons dans ce cas que vous avez dj utilis un systme de gestion de versions et que vous voulez monter un serveur Subversion le plus rapidement possible. Le Chapitre 5, Administration d'un dpt et le Chapitre 6, Configuration du serveur expliquent comment crer votre premier dpt et le mettre disposition sur le rseau. Ceci fait, le Chapitre 2, Utilisation de base et l'Annexe B, Guide Subversion l'usage des utilisateurs de CVS sont le plus court chemin pour apprendre utiliser le client Subversion. Novice Votre administrateur vient probablement de mettre en place Subversion et vous devez apprendre utiliser le client. Si vous n'avez jamais utilis de systme de gestion de versions, alors le Chapitre 1, Notions fondamentales est une introduction indispensable aux concepts de la gestion de versions. Le Chapitre 2, Utilisation de base est un tour du propritaire du client Subversion. Utilisateur avanc Que vous soyez utilisateur ou administrateur, votre projet va finir par prendre de l'importance. Il vous faudra apprendre comment effectuer des oprations plus pointues avec Subversion, comme par exemple utiliser des branches ou effectuer des fusions (Chapitre 4, Gestion des branches), utiliser les proprits des objets Subversion (Chapitre 3, Sujets avancs), configurer les options d'excution (Chapitre 7, Personnalisation de Subversion) et d'autres choses encore. Ces chapitres ne sont pas indispensables au dbut, mais pensez bien les lire une fois que vous vous sentirez l'aise avec les bases. Dveloppeur Vous tes certainement dj habitu Subversion et vous voulez prsent tendre ses fonctionnalits ou dvelopper un nouveau logiciel utilisant ses nombreuses API. Le Chapitre 8, Intgration de Subversion est l pour vous. Le livre se termine par le Chapitre 9, Rfrences compltes de Subversion. C'est le guide de rfrence pour toutes les commandes de Subversion, les annexes couvrant certaines notions particulirement utiles. Ce sont certainement les chapitres vers lesquels vous retournerez une fois la premire lecture termine.

Conventions utilises dans ce livre


Les conventions typographiques suivantes sont utilises dans ce livre : Largeur fixe Utilise pour la forme littrale des commandes, les rsultats de commandes et les paramtres des commandes. Italique Utilise pour les noms de programmes et de sous-commandes d'outils Subversion, les noms de fichier et de rpertoire et les termes nouveaux. Largeur fixe italique Utilise pour les lments remplacer dans le texte et le code. Nous avons galement plac des lments d'information particulirement utiles ou importants en vidence, de faon ce qu'ils soient faciles trouver ( des emplacements cohrents avec le contexte). Cherchez les icnes suivantes au fur et mesure de la lecture :

xiv

Prface

Cette icne indique un point particulier digne d'intrt.

Cette icne indique un conseil utile ou une bonne pratique .

Cette icne indique un avertissement. Accordez-lui une grande attention pour viter tout problme.

Organisation de ce livre
Les chapitres qui suivent, ainsi que leur contenu, sont lists ci-dessous : Chapitre 1, Notions fondamentales Explique les bases du contrle de versions et des diffrents modles de gestion de versions, ainsi que les dpts Subversion, les copies de travail et les rvisions. Chapitre 2, Utilisation de base Une balade dans l'utilisation quotidienne de Subversion. Ce chapitre explique comment rcuprer, modifier et propager des donnes l'aide du client Subversion. Chapitre 3, Sujets avancs Ce chapitre couvre des fonctionnalits plus complexes, que les utilisateurs rguliers seront amens manipuler, comme les mtadonnes suivies en versions, le verrouillage de fichiers et les piquets de rvisions. Chapitre 4, Gestion des branches Ce chapitre traite des branches, des fusions et des tiquettes, y compris les bonnes pratiques pour la gestion et la fusion de branches, des cas d'cole, comment revenir en arrire sur des modifications et comment passer facilement d'une branche une autre. Chapitre 5, Administration d'un dpt Ce chapitre dcrit les bases d'un dpt Subversion, comment le crer, le configurer et en assurer la maintenance. Il prsente galement les outils disponibles pour toutes ces actions. Chapitre 6, Configuration du serveur Ce chapitre explique comment configurer votre serveur Subversion et prsente diffrentes manires d'accder votre dpt : HTTP, le protocole svn et l'accs au disque en local. Il couvre aussi l'authentification, les autorisations et les accs anonymes. Chapitre 7, Personnalisation de Subversion Ce chapitre explore les fichiers de configuration du client Subversion, dcrit la prise en compte des contenus internationaux et montre comment utiliser des programmes externes conjointement avec Subversion. Chapitre 8, Intgration de Subversion Ce chapitre dcrit l'architecture interne de Subversion, le systme de fichiers associ et les zones administratives des copies de travail, du point de vue du programmeur. Il montre comment utiliser les API publiques pour crire un programme qui utilise Subversion et, surtout, comment contribuer au dveloppement de Subversion. Chapitre 9, Rfrences compltes de Subversion Ce chapitre explique de manire trs dtaille chacune des sous-commandes svn, svnadmin et svnlook avec tout un tas d'exemples pour contenter l'ensemble de la famille ! Annexe A, Guide de dmarrage rapide avec Subversion Pour les impatients, l'installation de Subversion et son utilisation en moins de deux minutes chrono. Vous tes prvenu. Annexe B, Guide Subversion l'usage des utilisateurs de CVS Cette annexe couvre les similitudes et les diffrences entre Subversion et CVS, avec des suggestions pour perdre les mauvaises habitudes que vous avez acquises durant des annes d'utilisation de CVS. Cela comprend les descriptions des numros de rvision de Subversion, les rpertoires suivis en versions, les oprations sans connexion rseau, la distinction xv

Prface

entre status et update, les branches, les tiquettes, les mtadonnes, la rsolution de conflits et l'authentification. Annexe C, WebDAV et la gestion de versions automatique Cette annexe dcrit en dtail WebDAV et DeltaV ; elle explique comment configurer votre dpt Subversion pour qu'il puisse tre mont en lecture/criture par des clients DAV. Annexe D, Copyright Cette annexe contient une copie de la Licence Creative Commons dont ce livre fait l'objet.

Ce livre est libre


Ce livre est parti de quelques morceaux de documentation crits par les dveloppeurs du projet Subversion, qui furent alors fusionns en un seul travail et rcrits. En tant que tel, il a toujours t sous licence libre (cf. l'Annexe D, Copyright). En fait, le livre a t crit sous le regard du public, faisant au dpart partie intgrante du projet Subversion. Cela veut dire deux choses : Vous trouverez toujours la version la plus rcente de ce livre dans le propre dpt Subversion du livre. Vous pouvez modifier ce livre et le redistribuer comme vous le voulez, il est sous licence libre. Votre seule obligation est de conserver correcte l'attribution du copyright aux auteurs d'origine. Bien sr, nous prfrerions que vous envoyiez vos commentaires et vos correctifs la communaut des dveloppeurs Subversion, plutt que de distribuer votre version prive de ce livre. Le portail internet de dveloppement de ce livre, et de la plupart de ses traductions, est accessible l'adresse : http://code.google.com/p/svnbook/ 1 . Vous y trouverez des liens sur les dernires parutions et les versions tiquetes du livre dans diffrents formats, ainsi que des instructions pour accder au dpt Subversion du livre (o se trouve son code source XML DocBook). Vos ractions sont les bienvenues et mme encourages. Prire de soumettre tous vos commentaires, rclamations et correctifs concernant les sources du livre <svnbook-dev@red-bean.com>.

Remerciements
Ce livre n'aurait pas t possible (ni trs utile) si Subversion n'existait pas. Pour cela, les auteurs tiennent remercier Biran Behlendorf et CollabNet pour avoir vu l'intrt et avoir os investir dans un nouveau projet de logiciel libre aussi risqu et ambitieux ; Jim Blandy pour le nom et le design original de Subversion, on t'aime Jim ; et Karl Fogel pour tre, surtout, un si bon ami et, ensuite, un grand leader pour la communaut. 2 Merci O'Reilly et nos diffrents diteurs : Chuck Toporek, Linda Mui, Tatiana Apandi, Mary Brady et Mary Treseler. Leur patience et leur soutien ont t extraordinaires. Enfin, nous aimerions remercier un nombre incalculable de personnes qui ont contribu ce livre par des relectures informelles, des suggestions et des corrections. Bien qu'il ne s'agisse sans doute pas d'une liste complte, ce livre aurait t incomplet et incorrect sans leur aide : Bhuvaneswaran A, David Alber, C. Scott Ananian, David Anderson, Ariel Arjona, Seth Arnold, Jani Averbach, Charles Bailey, Ryan Barrett, Francois Beausoleil, Brian R. Becker, Yves Bergeron, Karl Berry, Jennifer Bevan, Matt Blais, Jim Blandy, Phil Bordelon, Sietse Brouwer, Tom Brown, Zack Brown, Martin Buchholz, Paul Burba, Sean Callan-Hinsvark, Branko Cibej, Archie Cobbs, Jason Cohen, Ryan Cresawn, John R. Daily, Peter Davis, Olivier Davy, Robert P. J. Day, Mo DeJong, Brian Denny, Joe Drew, Markus Dreyer, Nick Duffek, Boris Dusek, Ben Elliston, Justin Erenkrantz, Jens M. Felderhoff, Kyle Ferrio, Shlomi Fish, Julian Foad, Chris Foote, Martin Furter, Vlad Georgescu, Peter Gervai, Dave Gilbert, Eric Gillespie, David Glasser, Marcel Gosselin, Lieven Govaerts, Steve Greenland, Matthew Gregan, Tom Gregory, Maverick Grey, Art Haas, Mark E. Hamilton, Eric Hanchrow, Liam Healy, Malte Helmert, Michael Henderson, yvind A. Holm, Greg Hudson, Alexis Huxley, Auke Jilderda, Toby Johnson, Jens B. Jorgensen, Tez Kamihira, David Kimdon, Mark Benedetto King, Robert Kleemann, Erik Kline, Josh Knowles, Andreas J. Koenig, Axel Kollmorgen, Nuutti Kotivuori, Kalin Kozhuharov, Matt Kraai, Regis Kuckaertz, Stefan Kueng, Steve Kunkee, Scott Lamb, Wesley J. Landaker, Benjamin Landsteiner, Vincent Lefevre, Morten Ludvigsen, Dennis Lundberg, Paul Lussier, Bruce A. Mah, Jonathon Mah, Karl Heinz Marbaise, Philip Martin, Feliciano Matias, Neil Mayhew, Patrick Mayweg, Gareth McCaughan, Craig McElroy, Simon McKenna, Christophe Meresse, Jonathan Metillon, Jean-Francois Michaud, Jon Middleton, Robert Moerland, Marcel

1 NDT: 2

ceci correspond l'adresse jour. Et puis merci, Karl, d'tre trop occup pour rdiger ce livre toi-mme.

xvi

Prface

Molina Jr., Tim Moloney, Alexander Mueller, Tabish Mustufa, Christopher Ness, Roman Neuhauser, Mats Nilsson, Greg Noel, Joe Orton, Eric Paire, Dimitri Papadopoulos-Orfanos, Jerry Peek, Chris Pepper, Amy Lyn Pilato, Kevin Pilch-Bisson, Hans Polak, Dmitriy Popkov, Michael Price, Mark Proctor, Steffen Prohaska, Daniel Rall, Srinivasa Ramanujan, Jack Repenning, Tobias Ringstrom, Jason Robbins, Garrett Rooney, Joel Rosdahl, Christian Sauer, Ryan Schmidt, Jochem Schulenklopper, Jens Seidel, Daniel Shahaf, Larry Shatzer, Danil Shopyrin, Erik Sjoelund, Joey Smith, W. Snyder, Stefan Sperling, Robert Spier, M. S. Sriram, Russell Steicke, David Steinbrunner, Sander Striker, David Summers, Johan Sundstroem, Ed Swierk, John Szakmeister, Arfrever Frehtes Taifersar Arahesis, Robert Tasarz, Michael W. Thelen, Mason Thomas, Erik van der Kolk, Joshua Varner, Eric Wadsworth, Chris Wagner, Colin Watson, Alex Waugh, Chad Whitacre, Andy Whitcroft, Josef Wolf, Luke Worth, Hyrum Wright, Blair Zajac, Florian Zumbiehl, et la communaut Subversion toute entire.

De Ben Collins-Sussman
Merci ma femme Frances, qui, pendant de longs mois, a entendu : Mais chrie, je n'ai pas fini de travailler sur le livre , au lieu de l'habituel Mais chrie, je n'ai pas fini d'envoyer des mails . Je ne sais pas d'o elle tire toute cette patience ! Elle est mon contrepoids parfait. Merci toute ma famille et tous mes amis pour leurs encouragements sincres, malgr leur absence totale d'intrt pour le sujet (vous savez, ceux qui disent, Oh oh, tu cris un livre ? et qui, lorsque vous leur dites qu'il s'agit d'un livre d'informatique, ne sont plus du tout intresss). Merci tous mes amis proches, qui ont fait de moi un homme trs riche. Ne me regardez pas comme a, vous savez qui vous tes. Merci mes parents pour le formatage bas niveau qui tait parfait et pour avoir t d'incroyables modles. Merci mon fils pour avoir eu l'opportunit de lui transmettre cela.

De Brian W. Fitzpatrick
Un immense merci ma femme Marie pour avoir t incroyablement comprhensive, pour m'avoir soutenu et, le plus important, pour avoir t aussi patiente. Merci toi ric, mon frre, qui fut le premier me faire dcouvrir la programmation UNIX il y a bien longtemps. Merci ma maman et ma grand-mre pour tout leur soutien, sans parler de ce Nol o je suis rentr la maison et ai immdiatement plong la tte dans mon portable pour travailler sur le livre. Pour Mike et Ben : cela a t un plaisir de travailler avec vous sur ce livre. Bon sang, c'est un plaisir de travailler avec vous au boulot ! A toute la communaut Subversion et l'Apache Software Foundation, merci de me considrer comme l'un des vtres. Il n'y a pas un jour o je n'apprends pas au moins une chose grce l'un d'entre vous. Enfin, merci mon grand-pre qui me disait toujours que Libert gale Responsabilit. Je suis tellement d'accord avec lui.

De C. Michael Pilato
Merci en particulier Amy, ma meilleure amie et ma femme depuis neuf incroyables annes, pour son amour et son soutien patient, pour avoir support les nuits tardives et pour avoir gracieusement support le processus de gestion de versions que je lui ai fait endurer. Ne t'en fais pas chrie, tu vas devenir un gourou de TortoiseSVN en un rien de temps ! Gavin, tu es maintenant capable de lire par toi-mme la moiti des mots de ce livre ; malheureusement, c'est l'autre moiti qui contient les concepts cl. Et dsol Aidan, je n'ai pas russi inclure les personnages de Disney/Pixar dans ce texte. Mais Papa vous aime tous les deux et est impatient de vous apprendre programmer. Maman et Papa, merci pour votre soutien constant et votre enthousiasme. Belle-Maman et Beau-Papa, merci pour la mme chose, plus votre fabuleuse fille. Chapeau bas Shep Kendall, travers qui le monde des ordinateurs s'est ouvert moi pour la premire fois ; Ben CollinsSussman, mon guide dans le monde du logiciel libre ; Karl Fogel, tu es mon .emacs ; Greg Stein, pour avoir laiss transpirer sa connaissance pratique de la programmation ; Brian FitzPatrick, pour avoir partag avec moi cette exprience d'criture. Aux nombreuses personnes de qui je rcupre constamment de nouvelles connaissances, continuez les partager ! Enfin, Celle, l'unique, qui incarne parfaitement l'excellence crative, merci.

xvii

Prface

Qu'est-ce que Subversion ?


Subversion est un logiciel libre de gestion de versions. Cela veut dire que Subversion gre les fichiers et les rpertoires, ainsi que les changements que vous y apportez au fil du temps. Cela vous permet de revenir d'anciennes versions de vos donnes ou d'examiner la faon dont vos donnes ont volu. De ce point de vue, beaucoup de gens se reprsentent un systme de gestion de versions comme une sorte de machine remonter le temps . Subversion peut fonctionner en rseau, ce qui lui permet d'tre utilis par des personnes travaillant sur des ordinateurs diffrents. D'une certaine manire, la possibilit offerte plusieurs personnes de modifier et de grer le mme ensemble de donnes depuis diffrents 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'inquitude avoir, l'absence d'un tel canal n'a pas pour contrepartie une perte de qualit : si des changements inadquats sont appliqus aux donnes, il suffit de les annuler. Certains systmes de gestion de versions sont aussi des systmes de gestion de configuration logicielle (GCL). Ces systmes sont spcialement conus pour grer des arborescences de code source et possdent de nombreuses fonctionnalits propres au dveloppement logiciel, comme la reconnaissance des langages de programmation ou des outils de construction/compilation de logiciel. Subversion, cependant, ne fait pas partie de cette catgorie. C'est un systme gnraliste qui peut tre utilis pour grer 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 vidos des vacances et bien au-del.

Subversion est-il l'outil appropri ?


Si, en tant qu'utilisateur ou administrateur systme, vous rflchissez la mise en place de Subversion, la premire question vous poser est : Est-ce que c'est l'outil adquat pour ce que je veux faire ? Subversion est un marteau fantastique, mais il faut faire attention ne pas assimiler tout problme 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 dtaillant leurs volutions, Subversion est l'outil idal pour vous. Si vous avez besoin de travailler sur des documents en collaboration avec d'autres personnes (habituellement via un rseau) 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 dveloppement logiciel ; travailler au sein d'une quipe de dveloppement est par nature une activit sociale et Subversion rend trs facile la collaboration entre programmeurs. Bien sr il existe aussi un cot li l'utilisation de Subversion en termes d'administration systme. Vous devrez grer un dpt de donnes 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 donnes, vous ne pourrez pas copier, dplacer, renommer ou supprimer des fichiers de la faon dont vous le faisiez auparavant. la place, vous devrez accomplir tout ceci via Subversion. En supposant que cette quantit de travail supplmentaire ne vous pose pas de problme, vous devriez quand mme vrifier que vous n'allez pas utiliser Subversion pour rsoudre un problme que d'autres outils pourraient rsoudre de manire bien plus efficace. Par exemple, parce que Subversion fournit une copie des donnes tous les utilisateurs concerns, une erreur courante est de le traiter comme un systme de distribution gnrique. Les gens utilisent parfois Subversion pour partager d'immenses collections de photos, de musique numrique ou de packs logiciels. Le problme est que ce type de donne ne change en gnral jamais. La collection grandit au fil du temps, mais les fichiers individuels l'intrieur de la collection ne changent pas. Dans ce cas, utiliser Subversion est disproportionn . 3 Il existe des outils plus simples, capables de copier des donnes efficacement sans s'embarrasser de toute la gestion du suivi des modifications, tels que rsync ou unison.

L'histoire de Subversion
Au dbut des annes 2000, CollabNet, Inc.(http://www.collab.net) commena rechercher des dveloppeurs pour crire un remplaant CVS. CollabNet fournit une suite logicielle collaborative appele CollabNet Enterprise Edition (CEE) dont l'un des composants est la gestion de versions. Mme si CEE utilisait CVS comme systme de gestion de versions initial, les limitations de celui-ci taient videntes depuis le dbut, 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 dcida d'crire un nouveau systme de gestion de versions ex nihilo, en conservant les ides de base de CVS, mais sans ses bogues ni ses limitations fonctionnelles. En fvrier 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 mme moment Karl bauchait la conception d'un
3

Ou comme le dit un de mes amis, c'est tuer les mouches coup de canon .

xviii

Prface

nouveau systme de gestion de versions avec son ami Jim Blandy. En 1995, ils avaient cr ensemble Cyclic Software, une socit fournissant des contrats de support pour CVS, et bien qu'ils aient plus tard revendu la socit, ils utilisaient toujours CVS quotidiennement dans leur travail. Leurs frustrations propos de CVS avaient conduit Jim laborer mentalement de meilleures faons de grer les donnes suivies en versions. Il avait dj non seulement trouv le nom de Subversion , mais aussi les principes de base du stockage de donnes de Subversion. Quand CollabNet les appela, Karl accepta immdiatement de travailler sur le projet et Jim obtint de son employeur, Red Hat Software, qu'il le dlgue au projet pour une dure indtermine. CollabNet embaucha Karl et Ben Collins-Sussman, et le travail de conception dtaille commena en mai. Grce des coups de pouce efficaces de Brian Behlendorf et Jason Robbins de CollabNet, et de Greg Stein (qui travaillait alors en tant que dveloppeur indpendant, et participait aux spcifications du projet WebDAV/DeltaV), Subversion attira rapidement une communaut de dveloppeurs actifs. Il s'avra que beaucoup d'entre eux avaient eu les mmes expriences 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 mthodes de gestion de versions, ils voulaient juste corriger ce qui n'allait pas dans CVS. Ils dcidrent que Subversion reprendrait les fonctionnalits de CVS et prserverait son modle de dveloppement, mais ne reproduirait pas ses faiblesses les plus videntes. Malgr le fait que Subversion devait pouvoir avoir ses propres spcificits, il devait tre suffisamment semblable CVS pour que n'importe lequel de ses utilisateurs puisse facilement passer Subversion. Le 31 aot 2001, aprs 14 mois de codage, Subversion devint auto-hbergeant . Ce qui veut dire que les dveloppeurs de Subversion cessrent d'utiliser CVS pour grer le propre code source de Subversion, et commencrent 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 dveloppeurs de Subversion), Subversion fonctionne comme la plupart des projets de logiciel libre, dirig par un ensemble de rgles vagues et transparentes qui encouragent la mritocratie. 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 tlcharger, modifier et redistribuer Subversion comme il le veut ; aucune autorisation de CollabNet ou de quiconque n'est ncessaire.

L'architecture de Subversion
La Figure 1, Architecture de Subversion donne une vue d'ensemble du schma de conception de Subversion.

Figure 1. Architecture de Subversion

xix

Prface

xx

Prface

D'un ct, nous avons un dpt Subversion qui contient toutes vos donnes suivies en versions. De l'autre ct, il y a votre programme client Subversion, qui gre des versions locales (appeles copies de travail ) de certaines de ces donnes suivies en versions. Entre ces deux extrmes, il y a des chemins varis utilisant diffrentes couches d'accs au dpt. Certains de ces chemins passent par des rseaux informatiques et des serveurs rseau avant d'atteindre le dpt. D'autres court-circuitent compltement le rseau et accdent directement au dpt.

Les composantes de Subversion


Une fois install, Subversion est constitu de nombreux composants. Ce qui suit est un survol rapide de ce que vous obtenez. Ne vous inquitez pas si certaines de ces brves descriptions vous laissent dubitatif ; ce livre contient de nombreuses pages destines 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 rvisions des lments prsents). svnlook Un outil qui permet d'examiner directement un dpt Subversion. svnadmin Un outil destin la cration, la modification ou la rparation d'un dpt Subversion. mod_dav_svn Un greffon pour le serveur HTTP Apache, utilis pour rendre votre dpt disponible d'autres personnes travers un rseau. svnserve Un serveur autonome cr sur mesure pour Subversion, pouvant fonctionner comme un processus dmon ou pouvant tre invoqu par SSH ; une autre faon de rendre votre dpt accessible d'autres personnes travers un rseau. svndumpfilter Un programme qui permet de filtrer les flux d'exports de l'historique de vos dpts. svnsync Un programme capable de synchroniser de manire incrmentale un dpt avec un autre dpt travers un rseau.

Ce qui a chang dans Subversion


La premire dition de ce livre a t publie en 2004, peu aprs que Subversion ait atteint la version 1.0. Durant les quatre annes qui suivirent, cinq nouvelles versions majeures de Subversion sont sorties, corrigeant des bogues et ajoutant de nouvelles fonctionnalits majeures. Bien que nous ayons russi 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 trs importante du projet. Voici un rsum rapide des changements majeurs qui ont eu lieu depuis Subversion 1.0. Cette liste n'est pas exhaustive ; pour tous les dtails, 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 dpt sous forme de fichiers textes. Bien que les bases Berkeley DB soient toujours trs utilises et supportes par la communaut, FSFS est devenu le choix par dfaut pour la cration de nouveaux dpts, grce sa prise en main facile et ses besoins minimes en termes de maintenance. Dans cette version ont galement t ajoutes les possibilits de suivre en versions des liens symboliques et de prendre en compte automatiquement des URLs, ainsi qu'une interface utilisateur rgionalise. Subversion 1.2 (mai 2005) La version 1.2 introduisit la possibilit de crer des verrous sur les fichiers ct serveur, srialisant ainsi l'accs des propagations certaines ressources. Bien que Subversion soit toujours fondamentalement un systme de gestion de versions accs simultans, certains types de fichiers binaires (par exemple des images de synthse) ne peuvent pas tre fusionns. Le mcanisme de verrouillage rpond aux besoins de suivi en versions et de protection de ces donnes. Avec le xxi

Prface

verrouillage est galement apparue une implmentation complte de l'auto-versionnement WebDAV, permettant aux dpts Subversion d'tre accessibles sous la forme de dossiers partags sur le rseau. Enfin, Subversion 1.2 commena utiliser un nouvel algorithme plus rapide de diffrenciation de donnes binaires pour compresser et rcuprer de vieilles versions de fichiers. Subversion 1.3 (dcembre 2005) Avec la version 1.3, le serveur svnserve sait contrler les droits en fonction des chemins, ce qui correspondait une fonctionnalit existant uniquement cette poque dans le serveur Apache. Cependant, le serveur Apache bnficia luimme de nouvelles fonctionnalits 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 rplication, dans une seule direction, d'un dpt via le rseau. Des parties importantes des mtadonnes des copies de travail changrent de format afin de ne plus utiliser XML (avec pour consquence des gains en rapidit ct client), tandis que le gestionnaire de base de donnes des dpts Berkeley DB acquit la capacit de rtablir 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 vritable bndiction pour les utilisateurs et propulsa Subversion bien au-del des possibilits de CVS, le plaant la hauteur de ses concurrents commerciaux tels que Perforce et Clearcase. En version 1.5 tout un tas d'autres fonctionnalits axes sur l'utilisateur furent introduites, telles que la rsolution interactive des conflits entre fichiers, les extractions partielles, la gestion des listes de modifications ct client, une nouvelle syntaxe trs puissante pour les dfinitions externes et le support par le serveur svnserve de l'authentification par SASL.

xxii

Chapitre 1. Notions fondamentales


Ce chapitre est une introduction rapide Subversion. Si vous ne connaissez rien la gestion de versions, ce chapitre est coup sr pour vous. Nous allons commencer par une prsentation des notions gnrales de la gestion de versions, puis tudier plus prcisment les ides particulires qui se cachent derrire Subversion et enfin donner quelques exemples simples d'utilisation de Subversion. Mme si les exemples de ce chapitre mettent en scne des personnes partageant du code source, gardez l'esprit que Subversion peut grer n'importe quel type d'ensemble de fichiers, il n'est pas rserv aux programmeurs.

Le dpt
Subversion est un systme centralis fait pour partager l'information. Le dpt constitue le cur de ce systme, en tant que lieu de stockage central des donnes. Les informations y sont organises sous la forme d'une arborescence de fichiers, c'est--dire une hirarchie classique de fichiers et de rpertoires. Un certain nombre de clients se connectent au dpt, et parcourent ou modifient ces fichiers. En modifiant des donnes, un client rend ces informations disponibles d'autres personnes ; en lisant des donnes, le client reoit les informations des autres personnes. La Figure 1.1, Un authentique systme client/serveur illustre cela.

Figure 1.1. Un authentique systme client/serveur

Quel est l'intrt ? Jusque l, cela ressemble la dfinition d'un serveur de fichiers classique. En fait, le dpt est bien une sorte de serveur de fichiers, mais d'un type particulier. Ce qui rend le dpt Subversion spcial, c'est qu'il se souvient de toutes les modifications qui ont t apportes : chaque modification de chaque fichier, ainsi que les modifications de l'arborescence-mme des rpertoires, comme l'ajout, la suppression ou la rorganisation de fichiers et de rpertoires. 1

Notions fondamentales

Quand un client parcourt le dpt, il consulte gnralement la dernire version de l'arborescence du systme de fichiers. Mais le client est galement capable de visualiser des tats antrieurs du systme de fichiers. Par exemple, un client peut poser des questions concernant l'historique des donnes, comme Que contenait ce rpertoire mercredi dernier ? ou Quelle est la dernire personne qui a modifi ce fichier, et quels changements a-t-elle effectu ? . C'est le genre de questions qui est au cur de tout logiciel de gestion de versions, logiciel conu pour conserver l'historique des modifications des donnes au cours du temps.

Modles de gestion de versions


La mission essentielle d'un logiciel de gestion de versions est de permettre l'dition collaborative et le partage de donnes. Mais il existe diffrentes stratgies pour arriver cette fin. Comprendre ces diffrentes stratgies est important pour plusieurs raisons. Tout d'abord, cela vous aidera comparer et diffrencier les logiciels de gestion de versions existants, au cas o vous rencontriez d'autres logiciels similaires Subversion. Ensuite, cela vous aidera galement utiliser plus efficacement Subversion, puisque Subversion lui-mme autorise diffrentes faons de travailler.

Problmatique du partage de fichiers


Tous les logiciels de gestion de versions doivent rsoudre le mme problme fondamental : comment le logiciel va-t-il permettre aux utilisateurs de partager l'information, tout en les empchant de se marcher mutuellement sur les pieds par accident ? Il est vraiment trop facile pour les utilisateurs d'craser malencontreusement les changements effectus par d'autres dans le dpt. Observons le scnario dcrit la Figure 1.2, La situation viter . Supposons que nous ayons deux collaborateurs, Harry et Sally. Ils dcident tous les deux d'diter au mme moment le mme fichier dans le dpt. Si Harry sauvegarde ses modifications dans le dpt en premier, il est possible que, quelques instants plus tard, Sally les crase avec sa propre version du fichier. Bien que la version de Harry ne soit pas perdue pour toujours, car le systme se souvient de tous les changements, aucune des modifications effectues par Harry ne sera prsente dans la nouvelle version du fichier de Sally, car elle n'aura jamais vu les changements raliss par Harry. De fait, le travail de Harry est perdu ou, du moins, perdu dans la version finale du fichier, et ceci probablement par accident. Il s'agit prcisment d'une situation que nous voulons tout prix viter !

Figure 1.2. La situation viter

Notions fondamentales

Modle verrouiller-modifier-librer
De nombreux logiciels de gestion de versions utilisent le modle verrouiller-modifier-librer pour rsoudre le problme de plusieurs auteurs annihilant le travail des autres. Dans ce modle, le dpt ne permet qu' une seule personne de modifier un fichier un instant donn. Cette politique exclusive est gre grce des verrous ( lock en anglais). Harry doit verrouiller un fichier avant de commencer le modifier. Si Harry a verrouill un fichier, alors Sally ne pourra pas le verrouiller et ne pourra donc faire aucun changement dessus. Tout ce qu'elle pourra faire sera de lire le fichier et d'attendre que Harry ait fini ses changements puis libr le verrou. Aprs que Harry ait libr le fichier, Sally pourra son tour le verrouiller et l'diter. La Figure 1.3, Modle verrouiller-modifier-librer illustre cette solution trs simple.

Figure 1.3. Modle verrouiller-modifier-librer

Notions fondamentales

Le problme avec le modle verrouiller-modifier-librer est qu'il est relativement restrictif et devient souvent un barrage pour les utilisateurs : Le verrouillage peut crer des problmes d'administration. Parfois, Harry va verrouiller un fichier et oublier qu'il l'a fait. Pendant ce temps, Sally, qui est encore en train d'attendre pour diter le fichier, est bloque. Puis Harry part en vacances. Sally doit alors aller trouver un administrateur pour librer le verrou de Harry. La situation finit par gnrer beaucoup de dlais inutiles et de temps perdu. Le verrouillage peut crer une srialisation inutile. Que se passe-t-il lorsque Harry veut diter le dbut d'un fichier texte et que Sally veut simplement diter la fin de ce mme fichier ? Ces changements ne se chevauchent pas du tout. Ils pourraient aisment diter le fichier simultanment et il n'y aurait pas beaucoup de dgts, en supposant que les changements soient correctement fusionns. Dans cette situation, il n'est pas ncessaire de les forcer diter le fichier chacun leur tour. Le verrouillage peut crer un faux sentiment de scurit. Supposons que Harry verrouille et dite le fichier A, alors qu'au 4

Notions fondamentales

mme moment Sally verrouille et dite le fichier B. Que se passe-t-il si A et B dpendent l'un de l'autre et que les changements faits chacun sont incompatibles d'un point de vue smantique ? A et B ne fonctionnent soudainement plus ensemble. Le systme de verrouillage a t incapable d'empcher ce problme, bien qu'il ait d'une certaine manire instill un faux sentiment de scurit. Il est facile pour Harry et Sally d'imaginer qu'en verrouillant les fichiers, chacun commence une tche isole, sans danger et donc que ce n'est pas la peine de discuter l'avance de leurs modifications incompatibles. Verrouiller devient souvent un substitut une relle communication.

Modle copier-modifier-fusionner
Subversion, CVS et beaucoup d'autres logiciels de gestion de versions utilisent le modle copier-modifier-fusionner comme alternative au verrouillage. Dans ce modle, chaque utilisateur contacte le dpt du projet via son client et cre une copie de travail personnelle, une sorte de version locale des fichiers et rpertoires du dpt. Les utilisateurs peuvent alors travailler, simultanment et indpendamment les uns des autres, et modifier leurs copies prives. Pour finir, les copies prives sont fusionnes au sein d'une nouvelle version finale. Le logiciel de gestion de versions fournit de l'aide afin de raliser cette fusion, mais au final la responsabilit de s'assurer que tout se passe bien incombe un tre humain. Voici un exemple. Supposons que Harry et Sally aient cr chacun des copies de travail du mme projet, copies partir du dpt. Ils travaillent simultanment et effectuent sur leur copie des modifications du mme fichier A. Sally sauvegarde ses changements dans le dpt en premier. Lorsque Harry essaie par la suite de sauvegarder ses modifications, le dpt l'informe que son fichier A est prim. En d'autres termes, le fichier A du dpt a chang, d'une faon ou d'une autre, depuis la dernire fois qu'il l'avait copi. Harry demande donc son client de fusionner tous les changements en provenance du dpt dans sa copie de travail du fichier A. Il y a des chances que les modifications de Sally n'empitent pas sur les siennes ; une fois qu'il a intgr les changements provenant des deux cts, il sauvegarde sa copie de travail dans le dpt. La Figure 1.4, Modle copier-modifier-fusionner et la Figure 1.5, Modle copier-modifier-fusionner (suite) illustrent ce processus.

Figure 1.4. Modle copier-modifier-fusionner

Notions fondamentales

Figure 1.5. Modle copier-modifier-fusionner (suite)

Notions fondamentales

Mais que se passe-t-il quand les modifications de Sally empitent sur celles de Harry ? Que fait-on dans ce cas-l ? Cette situation est appele un conflit et ne constitue pas, en gnral, un gros problme. Lorsque Harry demande son logiciel client de fusionner les changements les plus rcents du dpt dans sa copie de travail, sa copie du fichier est en quelque sorte marque comme tant dans un tat de conflit : il a la possibilit de voir les deux ensembles de changements entrant en conflit et de choisir manuellement entre les deux. Notez bien qu'un logiciel ne peut pas rsoudre automatiquement les conflits ; seuls les humains sont capables de comprendre et de faire les choix intelligents ncessaires. Une fois que Harry a manuellement rsolu les modifications se chevauchant, par exemple aprs une discussion avec Sally, il peut sauvegarder le fichier fusionn en toute scurit dans le dpt. Le modle copier-modifier-fusionner peut sembler un peu chaotique mais, en pratique, il fonctionne de faon trs fluide. Les utilisateurs peuvent travailler en parallle, sans jamais devoir s'attendre les uns les autres. Lorsqu'ils travaillent sur les mmes fichiers, il s'avre que la plupart des changements raliss en parallle ne se chevauchent pas du tout ; les conflits sont rares. Et le temps ncessaire la rsolution des conflits est en gnral bien infrieur au temps gaspill par un systme de verrouillage. Au final, tout revient un facteur critique : la communication entre les utilisateurs. Lorsque les utilisateurs communiquent mal, 7

Notions fondamentales

les conflits syntaxiques et smantiques augmentent. Aucun systme ne peut forcer les utilisateurs communiquer parfaitement et aucun systme ne peut dtecter les conflits smantiques. Il n'y a donc aucun intrt se laisser endormir par un faux sentiment de scurit selon lequel un systme de verrouillage permettrait d'viter les conflits ; en pratique, le verrouillage semble limiter la productivit plus qu'aucun autre facteur. Le verrouillage est parfois ncessaire Mme si le modle verrouiller-modifier-librer est en gnral considr comme pnalisant pour la collaboration, il y a quand mme des cas o le verrouillage est appropri. Le modle copier-modifier-fusionner est bas sur l'hypothse que les fichiers sont contextuellement fusionnables, c'est--dire que la majorit des fichiers d'un dpt sont des fichiers textes (comme le code source d'un programme). Mais pour les fichiers binaires, tels que des images ou du son, il est souvent impossible de fusionner les modifications en conflit. Dans ces cas-l, il est rellement ncessaire que les utilisateurs ne modifient le fichier qu' tour de rle. Sans accs srialis, quelqu'un finirait par perdre du temps sur des modifications qui seraient finalement perdues. Bien que Subversion soit avant tout un systme copier-modifier-fusionner, il reconnat toutefois la ncessit du verrouillage pour certains fichiers et fournit donc un mcanisme pour cela. Cette fonctionnalit est traite plus tard dans ce livre, dans la section intitule Verrouillage .

Subversion en action
Il est temps de passer de l'abstrait au concret. Dans cette section, nous vous montrons des exemples rels d'utilisation de Subversion.

URL des dpts Subversion


Tout au long de ce livre, Subversion utilise des URL pour identifier des fichiers et des rpertoires suivis en version au sein de dpts Subversion. Pour la plupart, ces URL utilisent la syntaxe standard, permettant de spcifier les noms des serveurs et les numros de port l'intrieur mme de l'URL : $ svn checkout http://svn.exemple.com:9834/depot Mais il existe quelques nuances dans la gestion des URL par Subversion qui doivent tre notes. Par exemple, les URL ayant pour mthode d'accs file:// (utilise pour les dpts locaux) doivent possder, en accord avec les conventions, soit un nom de serveur localhost , soit pas de nom de serveur du tout : $ svn checkout file:///var/svn/depot $ svn checkout file://localhost/var/svn/depot D'autre part, les utilisateurs du procd file:// sur les plateformes Windows doivent se servir d'une syntaxe qui est un standard officieux pour accder leurs dpts se trouvant sur la mme machine mais sur un disque diffrent du disque de travail habituel du client. Les deux syntaxes de chemin d'URL suivantes fonctionnent, X tant le disque sur lequel le dpt se trouve : C:\> svn checkout file:///X:/var/svn/depot C:\> svn checkout "file:///X|/var/svn/depot" Dans la seconde syntaxe, vous devez entourer l'URL de guillemets pour viter que la barre verticale ne soit interprte comme un symbole de redirection (un pipe ). De plus, remarquez qu'une URL utilise des barres obliques (/) alors que la forme 8

Notions fondamentales

native (non-URL) d'un chemin sous Windows utilise des barres obliques inverses (\). Les URL Subversion file:// ne peuvent pas tre utilises dans un navigateur web classique de la mme faon qu'une URL file:// habituelle. Lorsque vous essayez de visualiser une URL file:// dans un navigateur web classique, il lit et affiche le contenu du fichier situ cet emplacement en interrogeant directement le systme de fichiers. Cependant, les ressources de Subversion existent dans un systme de fichier virtuel (cf. la section intitule Couche dpt ) et votre navigateur ne comprend pas comment interagir avec ce systme de fichiers. Enfin, il faut noter que le client Subversion encode automatiquement les URL en cas de besoin, exactement comme le fait un navigateur web. Par exemple, si une URL contient un espace ou un caractre ASCII spcial, comme dans ce qui suit : $ svn checkout "http://hote/chemin avec espace/projet/espaa" alors Subversion banalise les caractres spciaux et se comporte comme si vous aviez tap : $ svn checkout http://hote/chemin%20avec%20espace/projet/espa%C3%B1a Si l'URL contient des espaces, prenez bien soin de la placer entre guillemets, pour que votre shell traite le tout comme un unique argument du programme svn. URL du dpt On peut accder aux dpts Subversion de nombreuses manires diffrentes, sur un disque local ou travers diffrents protocoles rseau, en fonction de la faon dont votre administrateur a mis les choses en place pour vous. L'emplacement d'un dpt, toutefois, est toujours une URL. Le Tableau 1.1, URL d'accs au dpt dcrit les diffrents procds d'accs et les mthodes d'accs correspondantes.

Tableau 1.1. URL d'accs au dpt


Procd file:/// http:// https:// svn:// svn+ssh:// Mthode d'accs Accs direct au dpt (sur un disque local). Accs via le protocole WebDAV un serveur Apache configur pour Subversion. Identique http://, mais avec chiffrement SSL. Accs via un protocole personnalis un serveur svnserve. Identique svn://, mais travers un tunnel SSH.

Pour plus d'informations sur la faon dont Subversion analyse les URL, reportez-vous la section intitule URL des dpts Subversion . Pour plus d'informations sur les diffrents types de serveurs rseau disponibles pour Subversion, reportez-vous au Chapitre 6, Configuration du serveur.

Copies de travail
Vous avez dj dcouvert ce que sont les copies de travail ; nous allons maintenant vous expliquer comment le client Subversion les cre et les utilise. Une copie de travail Subversion est une arborescence classique de rpertoires de votre systme local, contenant un ensemble de fichiers. Vous pouvez diter ces fichiers comme vous le voulez et, s'il s'agit de code source, vous pouvez compiler votre programme partir de ceux-ci de la faon habituelle. Votre copie de travail est votre espace de travail personnel priv : Subversion n'y incorporera jamais les changements d'autres personnes ni ne rendra jamais disponibles vos propres changements d'autres personnes tant que vous ne lui demanderez pas explicitement de le faire. Vous pouvez mme avoir 9

Notions fondamentales

plusieurs copies de travail d'un mme projet. Aprs que vous ayez apport quelques modifications aux fichiers de votre copie de travail et vrifi qu'elles fonctionnent correctement, Subversion vous fournit des commandes pour publier vos changements vers les autres personnes qui travaillent avec vous sur votre projet (en les transmettant au dpt). Si d'autres personnes publient leurs propres modifications, Subversion vous fournit des commandes pour fusionner ces changements dans votre copie de travail (en les obtenant du dpt). Une copie de travail contient galement quelques fichiers supplmentaires, crs et grs par Subversion, pour l'aider effectuer ces oprations. En particulier, chaque rpertoire de votre copie de travail contient un sous-rpertoire appel .svn, aussi appel rpertoire administratif de votre copie de travail. Les fichiers de chacun de ces rpertoires administratifs permettent Subversion d'identifier quels fichiers contiennent des modifications non-publies et quels fichiers sont prims vis--vis du travail des autres personnes. Un dpt Subversion contient bien souvent les fichiers (ou code source) de plusieurs projets ; habituellement, chaque projet est un sous-rpertoire de l'arborescence du systme de fichiers du dpt. Dans cette situation, la copie de travail d'un utilisateur correspond une sous-arborescence particulire du dpt. Par exemple, supposons que votre dpt contienne deux projets logiciels, paint et calc. Chaque projet rside dans son propre sous-rpertoire racine, comme indiqu dans la Figure 1.6, Systme de fichiers du dpt .

Figure 1.6. Systme de fichiers du dpt

10

Notions fondamentales

Pour obtenir une copie de travail, vous devez extraire une sous-arborescence du rpertoire (le terme extraire , check out en anglais, peut vous faire penser que cela a quelque chose voir avec verrouiller ou rserver des ressources, mais ce n'est pas le cas ; cela cre simplement pour vous une copie prive du projet). Par exemple, si vous extrayez /calc, vous obtenez une copie de travail qui ressemble ceci : $ svn checkout http://svn.exemple.com/depot/calc A calc/Makefile A calc/entier.c A calc/bouton.c 11

Notions fondamentales

Rvision 56 extraite. $ ls -A calc Makefile entier.c bouton.c .svn/

Les lettres A qui s'affichent dans la marge de gauche indiquent que Subversion est en train d'ajouter des lments dans votre copie de travail. Vous avez dsormais votre copie personnelle du rpertoire /calc du dpt, avec une entre supplmentaire, .svn, qui contient des informations complmentaires ncessaires Subversion, comme voqu prcdemment. Supposons que vous fassiez des modifications bouton.c. Comme le rpertoire .svn se souvient de la date de modification et du contenu du fichier original, Subversion peut en dduire que vous avez modifi le fichier. Nanmoins, Subversion ne rend pas vos modifications publiques tant que vous ne lui dites pas de le faire. L'action de publication de vos modifications est plus communment appele propagation ( commit ou check in en anglais et, parfois, archivage ou livraison en franais) des modifications au sein du dpt. Pour rendre publiques vos modifications, vous pouvez utiliser la commande Subversion svn commit : $ svn commit bouton.c -m "Coquille corrige dans bouton.c." Ajout bouton.c Transmission des donnes . Rvision 57 propage. prsent, vos modifications de bouton.c ont t propages au sein du dpt, avec un commentaire dcrivant ces changements ( vous avez corrig une coquille ). Si un autre utilisateur extrait une copie de travail de /calc/, il va voir vos modifications dans la dernire version du fichier. Supposons que vous ayez une collaboratrice, Sally, qui a extrait une copie de travail de /calc en mme temps que vous. Lorsque vous propagez votre modification de bouton.c, la copie de travail de Sally reste inchange ; Subversion ne modifie les copies de travail qu' la demande des utilisateurs. Pour mettre son projet jour, Sally peut demander Subversion de mettre jour ( update en anglais) sa copie de travail, en utilisant la commande svn update. Cela va intgrer vos modifications dans sa copie de travail, ainsi que celles qui ont t envoyes par d'autres personnes depuis qu'elle l'avait extraite. $ pwd /home/sally/calc $ ls -A Makefile bouton.c entier.c .svn/ $ svn update U bouton.c Actualis la rvision 57. En sortie, la commande svn update indique que Subversion a mis jour le contenu de bouton.c. Remarquez que Sally n'a pas eu besoin de spcifier quels fichiers devaient tre mis jour ; Subversion utilise les informations contenues dans le rpertoire .svn, ainsi que d'autres informations en provenance du dpt, pour dcider quels fichiers doivent tre mis jour.

Rvisions
Une opration svn commit publie les modifications d'un nombre quelconque de fichiers et de rpertoires en une seule opration atomique. Dans votre copie de travail, vous pouvez modifier le contenu des fichiers : crer, supprimer, renommer et copier fichiers et rpertoires ; puis propager un ensemble de modifications en une seule transaction atomique. Par transaction atomique , on entend simplement ceci : soit toutes les modifications sont propages dans le dpt, soit aucune ne l'est. Subversion tente de conserver cette atomicit aussi bien face des plantages de programmes, de systmes d'exploitation ou de rseau, que face aux actions des autres utilisateurs. Chaque fois que le dpt accepte une propagation, ceci cre un nouvel tat de l'arborescence du systme de fichiers, appel rvision. Un numro unique est associ chaque rvision, correspondant au numro de la rvision prcdente augment de 1. 12

Notions fondamentales

La rvision initiale d'un dpt frachement cr porte le numro 0 et ne consiste en rien d'autre qu'un rpertoire racine vide. La Figure 1.7, Le dpt offre une vue intressante du dpt. Imaginez un tableau de numros de rvisions, commenant 0 et s'tirant de la gauche vers la droite. Chaque numro de rvision correspond une arborescence de systme de fichiers situe en-dessous de lui et chaque arborescence est une photo, un instantan ( snapshot en anglais) du dpt prise aprs une propagation.

Figure 1.7. Le dpt

Numros de rvision globaux Contrairement la plupart des logiciels de gestion de versions, les numros de rvision de Subversion s'appliquent l'arborescence toute entire et non chaque fichier individuellement. chaque numro de rvision correspond une arborescence toute entire, un tat particulier du dpt aprs une propagation. Une autre faon de voir cela est de considrer que la rvision N reprsente l'tat du systme de fichiers du dpt aprs la N-ime propagation. Quand des utilisateurs de Subversion parlent de la rvision 5 de truc.c , ils veulent en fait parler de truc.c tel qu'il apparat dans la rvision 5 . Remarquez bien qu'en rgle gnrale, les rvisions N et M d'un fichier ne sont pas forcment diffrentes ! De nombreux autres logiciels de gestion de versions grent les numros de rvision fichier par fichier ; ce concept peut donc sembler inhabituel premire vue (les anciens utilisateurs de CVS peuvent se rfrer l'Annexe B, Guide Subversion l'usage des utilisateurs de CVS pour plus de dtails).

Il est important de noter que les copies de travail ne correspondent pas toujours une unique rvision du dpt ; elles peuvent contenir des fichiers provenant de plusieurs rvisions diffrentes. Par exemple, supposons que vous extrayiez une copie de travail d'un dpt dont la rvision la plus rcente est la numro 4 : calc/Makefile:4 integer.c:4 button.c:4 13

Notions fondamentales

cet instant, le rpertoire de travail correspond exactement la rvision 4 du dpt. Nanmoins, supposons que vous modifiiez bouton.c et que vous propagiez cette modification. En supposant qu'aucune autre propagation n'a eu lieu, votre propagation cre la rvision 5 du dpt et votre copie de travail ressemble maintenant ceci : calc/Makefile:4 entier.c:4 bouton.c:5 Supposons maintenant qu' ce moment prcis, Sally propage une modification d'entier.c, crant la rvision 6. Si vous utilisez svn update pour mettre jour votre copie de travail, elle ressemble alors ceci : calc/Makefile:6 entier.c:6 bouton.c:6 Les modifications apportes par Sally entier.c apparaissent dans votre copie de travail et vos modifications sont toujours prsentes dans bouton.c. Dans cet exemple, le texte de Makefile est identique dans les rvisions 4, 5 et 6 mais Subversion marque votre copie de travail de Makefile comme tant la rvision 6 pour indiquer qu'elle est jour. Ainsi, quand vous effectuez une mise jour au niveau de la racine de votre copie de travail, celle-ci correspond en gnral une rvision donne du dpt.

Les copies de travail suivent l'volution du dpt


Pour chaque fichier d'un rpertoire de travail, Subversion enregistre deux informations essentielles dans la zone administrative .svn/ : la rvision sur laquelle votre fichier de travail est bas (qui est appele la rvision de travail du fichier) et la date et l'heure de la dernire mise jour de la copie locale depuis le dpt partir de ces informations, en dialoguant avec le dpt, Subversion est capable de dterminer dans lequel des quatre tats suivants se trouve un fichier de travail : Inchang et jour Le fichier est inchang dans le rpertoire de travail et aucune modification de ce fichier n'a t propage vers le dpt depuis sa rvision de travail. Un appel svn commit sur le fichier ne fera rien, un appel svn update sur le fichier ne fera rien non plus. Modifi localement et jour Le fichier a t modifi dans le rpertoire de travail et aucune modification du fichier n'a t propage dans le dpt depuis la dernire mise jour. Il existe des modifications locales qui n'ont pas t propages vers le dpt, donc un appel svn commit sur le fichier permettra de publier vos modifications et un appel svn update ne fera rien. Inchang et prim Le fichier n'a pas t modifi dans le rpertoire de travail mais a chang dans le dpt. Le fichier devra tre mis jour un moment ou un autre, pour l'amener au niveau de la dernire rvision publique. Un appel svn commit sur le fichier ne fera rien et un appel svn update incorporera les dernires modifications dans votre copie de travail. Modifi localement et prim Le fichier a t modifi la fois dans le rpertoire de travail et dans le dpt. Un appel svn commit sur le fichier va chouer, renvoyant comme erreur Prim ( out-of-date en anglais). Le fichier doit d'abord tre mis jour ; un appel svn update va tenter de fusionner les modifications publiques avec les modifications locales. Si Subversion ne parvient pas raliser automatiquement cette fusion de manire crdible, il va laisser l'utilisateur la tche de rsoudre le conflit.

14

Notions fondamentales

Tout ceci peut sembler compliqu grer mais la commande svn status vous indique dans quel tat se trouve n'importe quel lment de votre copie de travail. Pour plus d'informations sur cette commande, rfrez-vous la section intitule Avoir une vue d'ensemble des changements effectus .

Copies de travail mixtes, rvisions mlanges


Un principe gnral de Subversion est d'tre aussi flexible que possible. Un type particulier de flexibilit est la capacit d'avoir une copie de travail contenant des fichiers et des rpertoires avec un mlange de diffrents numros de rvision. Malheureusement, cette flexibilit a tendance embrouiller un certain nombre de nouveaux utilisateurs. Si l'exemple prcdent contenant des rvisions mixtes vous laisse perplexe, voici une amorce d'explication la fois sur les raisons pour lesquelles cette fonctionnalit existe et sur la faon de l'utiliser.

Mise jour et propagation sont deux choses distinctes


Une des rgles fondamentales de Subversion est que l'action de pousser ne dclenche pas une action de tirer , ni l'inverse. Le simple fait que vous soyez prt soumettre vos nouvelles modifications au dpt ne veut pas dire que vous tes prts recevoir les modifications d'autres personnes. Et si vous avez de nouvelles modifications encore en cours, alors svn update fusionne lgamment les changements du dpt avec les vtres, plutt que de vous forcer les publier. Le principal effet secondaire de cette rgle est que la copie de travail a de la comptabilit supplmentaire effectuer pour suivre les mlanges de rvision et galement tre tolrante vis--vis de l'ensemble. Cela est rendu encore plus difficile par le fait que les rpertoires eux-mmes sont suivis en versions. Par exemple, supposons que vous ayez une copie de travail qui soit intgralement la rvision 10. Vous ditez le fichier truc.html et ralisez ensuite un svn commit qui cre la rvision 15 dans le dpt. Aprs que la propagation ait russi, nombreux sont ceux parmi les nouveaux utilisateurs qui s'attendraient ce que toute la copie de travail soit la rvision 15, mais ce n'est pas le cas ! Un certain nombre de modifications ont pu avoir lieu dans le dpt entre les rvisions 10 et 15. Le client ne sait rien de ces changements qui ont t apports au dpt, puisque vous n'avez pas encore excut la commande svn update et la commande svn commit ne rcupre pas les nouvelles modifications. D'un autre ct, si la commande svn commit tlchargeait automatiquement les modifications les plus rcentes, alors il serait possible d'avoir toute la copie de travail la rvision 15 mais, dans ce cas, nous enfreindrions la rgle fondamentale selon laquelle pousser et tirer doivent demeurer des actions distinctes. Ainsi, la seule chose que le client Subversion peut faire en toute scurit est de marquer le fichier truc.html, et lui seulement, comme tant la rvision 15. Le reste de la copie de travail reste la rvision 10. Seule l'excution de la commande svn update permet de rcuprer les dernires modifications et de marquer la copie de travail comme tant la rvision 15.

Des rvisions mlanges sont normales


Le fait est qu' chaque fois que vous excutez la commande svn commit, votre copie de travail se retrouve compose d'un mlange de rvisions. Les lments que vous venez juste de propager sont marqus comme ayant un numro de rvision plus lev que tous les autres. Aprs plusieurs propagations (sans mise jour entre-temps), votre copie de travail va contenir tout un mlange de rvisions. Mme si vous tes la seule personne utiliser le dpt, vous constaterez quand mme ce phnomne. Pour tudier votre propre mlange de rvisions de travail, utilisez la commande svn status avec l'option --verbose (voir la section intitule Avoir une vue d'ensemble des changements effectus pour plus d'informations). Souvent, les nouveaux utilisateurs n'ont pas du tout conscience que leur copie de travail contient des rvisions mlanges. Cela peut tre droutant car beaucoup de commandes client sont sensibles la rvision de travail de l'lment qu'elles examinent. Par exemple, la commande svn log est utilise pour afficher l'historique des modifications d'un fichier ou d'un rpertoire (cf. la section intitule Affichage de l'historique ). Lorsque l'utilisateur appelle cette commande sur un objet de la copie de travail, il s'attend obtenir l'historique complet de celui-ci. Mais si la rvision de travail de l'objet est assez ancienne (souvent parce que svn update n'a pas t lanc depuis un certain temps), alors c'est l'historique de l'ancienne version de l'objet qui est affich.

Un mlange de rvisions est utile


Si votre projet est suffisamment complexe, vous allez dcouvrir qu'il est parfois pratique d'effectuer un retour en arrire forc (c'est--dire de faire une mise jour vers une version plus ancienne que celle que vous avez dj) sur certaines parties de votre copie de travail vers des rvisions plus anciennes ; vous apprendrez comme le faire dans le Chapitre 2, Utilisation de base. Vous avez peut-tre envie de tester une version prcdente d'un sous-module contenu dans un sous-rpertoire ou bien de comprendre comment un bogue est apparu pour la premire fois dans un fichier donn. C'est le ct machine voyager dans le temps d'un logiciel de gestion de versions, la fonctionnalit qui vous permet de dplacer n'importe quelle partie de votre 15

Notions fondamentales

copie de travail en avant ou en arrire dans le temps.

Les mlanges de rvisions ont des limites


Quelle que soit la faon dont vous utilisez les mlanges de rvision dans votre copie de travail, il existe des limites cette flexibilit. Premirement, vous ne pouvez pas propager la suppression d'un fichier ou d'un rpertoire qui n'est pas compltement jour. Si une version plus rcente de l'lment existe dans le dpt, votre tentative de suppression est rejete, afin de vous empcher de dtruire accidentellement des modifications dont vous n'aviez pas encore connaissance. Deuximement, vous ne pouvez propager la modification des mtadonnes d'un rpertoire que si celui-ci est compltement jour. Vous apprendrez comment associer des proprits des lments dans le Chapitre 3, Sujets avancs. La rvision de travail d'un rpertoire dfinit un ensemble prcis d'entres et de proprits et propager la modification d'une proprit d'un rpertoire prim risquerait de dtruire des proprits dont vous n'aviez pas encore connaissance.

Rsum
Nous avons couvert un certain nombre de concepts fondamentaux de Subversion dans ce chapitre : Nous avons introduit les notions de dpt central, de copie de travail du client et d'ensemble des rvisions de l'arborescence du dpt. Nous avons vu quelques exemples simples de la faon dont deux collaborateurs peuvent utiliser Subversion pour publier et recevoir des modifications en provenance l'un de l'autre, en utilisant le modle copier-modifier-fusionner . Nous avons voqu la faon dont Subversion suit et gre les informations dans une copie de travail. prsent, vous avez probablement une bonne ide gnrale de la faon dont Subversion fonctionne. Arm de cette connaissance, vous devez dsormais tre prt passer au chapitre suivant qui traite en dtail des commandes et des fonctionnalits de Subversion.

16

Chapitre 2. Utilisation de base


Nous allons maintenant voir plus en dtail l'utilisation de Subversion. Quand vous aurez termin ce chapitre, vous serez capable d'effectuer toutes les tches ncessaires une utilisation quotidienne de Subversion. Nous allons commencer par enregistrer nos fichiers dans Subversion, puis extraire notre code. Ensuite, nous expliquons comment modifier des fichiers et examiner ces changements. Nous voyons aussi comment faire pour intgrer les changements venant d'autres personnes dans notre copie de travail, les examiner et rsoudre les conflits qui pourraient apparatre. Notez que ce chapitre ne doit pas tre vu comme une liste complte de toutes les commandes de Subversion, mais plutt comme une introduction conviviale aux oprations Subversion les plus courantes que vous tes susceptible de rencontrer. Ici, nous supposons que vous avez lu et compris le Chapitre 1, Notions fondamentales et que vous tes familier avec le modle gnral de Subversion. Pour une liste complte de toutes les commandes, reportez-vous au Chapitre 9, Rfrences compltes de Subversion.

l'aide !
Avant de poursuivre la lecture, voici la commande la plus importante de Subversion : svn help. Le client en ligne de commande de Subversion inclut sa propre documentation : tout moment, un rapide svn help sous-commande vous renvoie la syntaxe, les options et le comportement de la sous-commande. $ svn help import import: Charge un fichier ou une arborescence non versionne dans un dpt. usage : import [CHEMIN] URL Charge rcursivement une copie de CHEMIN vers URL. Si CHEMIN est omis, '.' est utilis. Les rpertoires parents sont crs si ncessaire dans le dpt. Si CHEMIN est un rpertoire, son contenu est ajout directement sous l'URL. Les objects non versionnables tels les priphriques ou les pipes sont ignors si l'option '--force' est spcifie. Options valides: -q [--quiet] -N [--non-recursive] --depth ARG : n'affiche rien, ou seulement des informations rsumes : obsolte : essayer --depth=files ou --depth=immediates : limite l'opration cette profondeur (depth empty/files/immediates/infinity) en argument

Options, slecteurs, drapeaux Doux Jsus ! Le client en ligne de commande de Subversion possde de nombreux modificateurs de commandes (que nous appelons options), mais il existe deux types d'options distincts : les options courtes sont constitues d'un unique tiret suivi d'une unique lettre, tandis que les options longues sont formes de deux tirets suivis d'un certain nombre de lettres (c'est--dire respectivement -s et --ceci-est-une-option-longue). Chaque option possde une option longue, mais seules certaines options ont aussi un format court (ce sont gnralement des options qui sont utilises trs souvent). Par souci de clart, nous utilisons gnralement la forme longue dans les exemples de code, mais lorsque nous dcrivons les options, s'il existe une forme courte, nous donnons la fois la forme longue (pour plus de clart) et la forme courte (car plus facile retenir). Utilisez la forme qui vous convient le mieux, mais n'essayez pas d'utiliser les deux.

Enregistrement de donnes dans votre dpt


Deux moyens sont votre disposition pour enregistrer de nouveaux fichiers dans votre dpt Subversion : svn import et svn add. Nous abordons ici la commande svn import et, plus loin dans le chapitre, la commande svn add, lorsque nous passerons en revue une journe typique avec Subversion. 17

Utilisation de base

svn import
La commande svn import est un moyen rapide de copier une arborescence non-suivie en versions dans le dpt, crant des dossiers intermdiaires si ncessaire. svn import ne ncessite pas de copie de travail et vos fichiers sont immdiatement propags dans le dpt. Ce moyen est utilis essentiellement quand vous avez une arborescence dont vous voulez suivre les changements dans votre dpt Subversion. Par exemple : $ svnadmin create /var/svn/nouveau-depot $ svn import mon-arborescence file:///var/svn/nouveau-depot/un/projet \ -m "Import initial" Ajout mon-arborescence/truc.c Ajout mon-arborescence/machin.c Ajout mon-arborescence/sous-repertoire Ajout mon-arborescence/sous-repertoire/bidule.h L'exemple prcdent copie le contenu du dossier mon-arborescence dans le dossier un/projet dans le dpt : $svn list file:///var/svn/nouveau-depot/un/projet truc.c machin.c sous-repertoire/ Notez qu'aprs la fin de l'import, l'arborescence d'origine n'est pas transforme en copie de travail. Pour commencer travailler, vous devez extraire grce svn checkout une copie de travail toute frache de l'arborescence.

Organisation conseille de votre dpt


Bien que Subversion vous permette d'organiser votre dpt de la manire dont vous le voulez, nous vous recommandons de crer un dossier appel trunk pour stocker la ligne principale du dveloppement, un autre dossier branches qui contiendra les copies alternatives (ou branches) et un dossier tags pour les versions tiquetes. Par exemple : $ svn list file:///var/svn/depot /trunk /branches /tags Vous en apprendrez plus sur les tiquettes et les branches dans le Chapitre 4, Gestion des branches. Pour plus de dtails et pour voir comment grer plusieurs projets, reportez-vous la section intitule Agencement du dpt , et la section intitule Stratgies d'organisation d'un dpt pour en savoir plus sur les rpertoires racines d'un projet.

Extraction initiale
En gnral, vous commencerez utiliser un dpt Subversion en faisant une extraction ( checkout en anglais) de votre projet. Extraire un projet d'un dpt cre sur votre ordinateur une copie de travail de ce projet. Cette copie contient la version HEAD (la dernire rvision) du dpt que vous indiquez dans la ligne de commande : $ svn checkout http://svn.apache.org/repos/asf/subversion/ A subversion/trunk A subversion/trunk/NOTICE A subversion/trunk/LICENSE A subversion/trunk/Makefile.in A subversion/trunk/build.conf Rvision 8810 extraite.

18

Utilisation de base

Qu'y a-t-il dans un nom ? Subversion essaie au maximum de ne pas limiter le type de donnes que vous placez en suivi de versions. Le contenu des fichiers et les valeurs des proprits sont stocks et transmis en tant que donnes binaires, la section intitule Type de contenu des fichiers vous explique comment indiquer Subversion que des oprations textuelles n'ont pas de sens pour un fichier particulier. Il existe toutefois quelques cas pour lesquels Subversion dfinit des limitations sur les informations qu'il stocke. Subversion gre en interne certaines parties des donnes au format Unicode UTF-8, par exemple les noms de proprits, les noms de chemins et les messages de trace. Cela ne veut toutefois pas dire que toutes vos interactions avec Subversion doivent faire intervenir l'UTF-8. En rgle gnrale, les clients Subversion vont grer de faon transparente les conversions entre l'UTF-8 et le systme de codage utilis par votre ordinateur, si cela a un sens de faire une telle conversion (ce qui est le cas pour les codages les plus courants utiliss de nos jours). Dans les changes WebDAV ainsi que dans des anciennes versions de certains fichiers de gestion interne de Subversion, les chemins sont utiliss en tant que valeurs d'attribut XML et les noms de proprits en tant que noms de tags XML. Cela veut dire que les chemins ne peuvent contenir que des caractres XML (1.0) valides et que les noms de proprits sont encore plus limits, ne pouvant contenir que des caractres ASCII. Subversion interdit galement les caractres TAB (tabulation), CR et LF (caractres de fin de ligne) dans les noms de chemins pour empcher les chemins d'tre coups en deux lors des comparaisons ou dans les sorties de commandes comme svn log ou svn status. Bien que cela fasse beaucoup de choses se rappeler, ces limitations sont rarement un problme en pratique. Tant que vos paramtres locaux sont compatibles avec UTF-8 et que vous n'utilisez pas de caractres de contrle dans les chemins, vous ne devriez pas avoir de problme pour communiquer avec Subversion. Le client en ligne de commande apporte un peu d'aide supplmentaire : afin de crer des versions valides pour un usage interne, il banalise automatiquement, si ncessaire, les caractres illgaux contenus dans les chemins d'URL que vous tapez.

Alors que l'exemple prcdent extraie le rpertoire de base trunk, vous pouvez tout aussi facilement extraire un sousrpertoire situ n'importe quelle profondeur dans le dpt en spcifiant le sous-rpertoire dans l'URL d'extraction : $ svn checkout \ http://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/ A cmdline/cat_tests.py A cmdline/revert_tests.py A cmdline/entries_tests.py A cmdline/svneditor.bat A cmdline/import_tests.py Rvision 8810 extraite. Comme Subversion utilise le modle copier-modifier-fusionner la place du modle verrouiller-modifier-librer (voir la section intitule Modles de gestion de versions ), vous pouvez commencer immdiatement modifier les fichiers et les rpertoires de votre copie de travail. Votre copie de travail n'est qu'un ensemble de fichiers et de rpertoires comme les autres dans votre systme. Vous pouvez y diter des fichiers, la modifier, la dplacer, vous pouvez mme supprimer toute votre copie de travail et l'oublier dfinitivement. Bien que votre copie de travail n'est qu'un ensemble de fichiers et de rpertoires comme les autres dans votre systme , vous pouvez diter vos fichiers comme vous le voulez, mais vous devez signaler Subversion toutes vos autres oprations. Par exemple, si vous voulez copier ou dplacer un lment dans votre copie de travail, vous devez utiliser svn copy ou svn move la place des commandes de copie ou de dplacement fournies par votre systme d'exploitation. Nous aborderons plus en dtail ces commandes plus loin dans ce chapitre. moins que vous ne soyez prt propager l'ajout d'un nouveau fichier ou d'un nouveau rpertoire ou la modification d'un fichier ou rpertoire existant, il n'est pas ncessaire d'informer davantage le serveur Subversion que vous avez fait quelque chose. propos du rpertoire .svn ? 19

Utilisation de base

Chaque rpertoire dans une copie de travail contient une zone administrative, un sous-rpertoire nomm .svn. Habituellement, les commandes d'affichage du contenu des rpertoires ne font pas apparatre ce sous-rpertoire, mais il s'agit tout de mme d'un rpertoire important. Quoique vous fassiez, ne supprimez ni ne changez rien dans la zone administrative ! Subversion dpend d'elle pour grer votre copie de travail. Si vous supprimez accidentellement le sous-rpertoire .svn, la faon la plus facile de rgler le problme est de supprimer entirement le rpertoire qui le contenait (via une suppression classique du systme, pas un appel svn delete), puis de lancer svn update depuis un rpertoire parent. Le client Subversion tlchargera alors le rpertoire que vous avez supprim, en incluant galement une nouvelle zone .svn.

Certes, vous pouvez extraire une copie de travail avec l'URL du dpt comme seul argument, mais vous pouvez galement spcifier un rpertoire aprs l'URL du dpt. Cela place votre copie de travail dans le nouveau rpertoire indiqu. Par exemple : $ svn checkout http://svn.apache.org/repos/asf/subversion/trunk subv A subv/NOTICE A subv/LICENSE A subv/Makefile.in A subv/build.conf Rvision 8810 extraite. Ceci place votre copie de travail dans un rpertoire nomm subv au lieu d'un rpertoire nomm trunk comme nous l'avions fait prcdemment. Le rpertoire subv est cr s'il n'existait pas auparavant.

Interdiction de la mise en cache du mot de passe


Lorsque vous ralisez une opration Subversion qui ncessite une authentification, Subversion met par dfaut en cache sur le disque vos lments d'authentification. Il fait cela par commodit, pour que vous ne soyez pas oblig de r-entrer constamment votre mot de passe pour les oprations suivantes. Si la mise en cache des mots de passe Subversion vous drange1, vous pouvez dsactiver la mise en cache de faon permanente ou au cas par cas. Pour dsactiver la mise en cache du mot de passe pour un appel donn d'une commande particulire, passez l'option -no-auth-cache sur la ligne de commande. Pour dsactiver de faon permanente la mise en cache, vous pouvez ajouter la ligne store-passwords = no votre fichier de configuration Subversion sur votre machine locale. Voir la section intitule Mise en cache des lments d'authentification du client pour plus de dtails.

Authentification sous un autre nom


Puisque Subversion met en cache par dfaut les lments d'authentification ( la fois le nom d'utilisateur et le mot de passe), il se souvient commodment de qui vous tiez la dernire fois que vous avez modifi votre copie de travail. Mais parfois, cela n'aide pas, en particulier si vous travaillez sur une copie de travail partage, comme par exemple un rpertoire de configuration systme, ou le rpertoire racine des documents d'un serveur Web. Dans ce cas, il suffit de passer l'option --username la ligne de commande et Subversion essaie alors de vous authentifier en tant que cet utilisateur, vous demandant votre mot de passe si ncessaire.

Cycle de travail de base


Subversion dispose de nombreuses fonctionnalits, d'options, d'avertissements et de garde-fous. Mais dans une utilisation au jour le jour, vous n'utilisez qu'un petit nombre d'entre eux. Dans cette section, nous passons en revue l'utilisation quotidienne de Subversion.

Bien sr, cela ne vous inquite pas outre mesure : d'abord parce que vous savez qu'on ne peut jamais rien effacer rellement avec Subversion, et ensuite parce que votre mot de passe Subversion n'est pas le mme que les trois millions d'autres mots de passe que vous avez dj, pas vrai ? Pas vrai ?

20

Utilisation de base

Le cycle de travail typique ressemble ceci : 1. Mettre jour votre copie de travail. svn update 2. Faire des changements. svn add svn delete svn copy svn move 3. Examiner les changements effectus. svn status svn diff 4. ventuellement annuler des changements. svn revert 5. Rsoudre les conflits (fusionner les modifications). svn update svn resolve 6. Propager les changements. svn commit

Mettre jour votre copie de travail


Si vous travaillez en quipe sur un projet donn, vous voulez mettre jour votre copie locale pour recevoir toutes les modifications qui ont pu tre faites par les autres dveloppeurs du projet depuis votre dernire mise jour. Utilisez svn update pour synchroniser votre copie de travail avec la dernire version prsente dans le dpt : $ svn update U truc.c U machin.c Actualis la rvision 2. Dans cet exemple, il se trouve que quelqu'un a apport des modifications truc.c ainsi qu' machin.c depuis votre dernire mise jour et Subversion vient de rpercuter ces modifications dans votre copie de travail. Lorsque le serveur envoie des modifications vers votre copie de travail via svn update, un code, sous forme de lettre, est affich cot de chaque lment pour vous permettre de savoir quelles actions Subversion a effectues pour mettre votre copie de travail jour. Pour en savoir plus sur le sens de ces lettres, excutez svn help update.

Apporter des modifications votre copie de travail


Vous pouvez prsent vous mettre au travail et apporter des modifications votre copie de travail. Il est plus commode, habituellement, de dmarrer par une modification (ou un ensemble de modifications) prcise, comme par exemple crire une nouvelle fonctionnalit, corriger un bogue, etc. Les commandes Subversion dont vous vous servez pour cela sont svn add, svn 21

Utilisation de base

delete, svn copy et svn mkdir. Cependant, si vous ne faites qu'diter des fichiers qui sont dj dans Subversion, vous n'avez besoin d'aucune de ces commandes jusqu' ce que vous propagiez vos modifications. Vous pouvez apporter deux types de modifications votre copie de travail : des modifications de fichier et des modifications d'arborescence. Vous n'avez pas besoin de signaler Subversion que vous allez modifier un fichier ; faites vos changements en utilisant votre diteur de texte, un logiciel de traitement de texte, un logiciel de graphisme, ou n'importe quel autre outil que vous utilisez d'habitude. Subversion dtecte automatiquement quels fichiers ont t modifis et, en plus, il traite les fichiers binaires tout aussi facilement et tout aussi efficacement que les fichiers textes. Pour les modifications d'arborescence, vous pouvez demander Subversion de marquer les fichiers et rpertoires afin de programmer leur suppression, ajout, copie ou renommage. Bien que ces modifications soient immdiatement rpercutes sur votre copie de travail, aucun ajout et aucune suppression ne sera rpercut sur le dpt avant que vous ne les propagiez. Grer des liens symboliques Dans des environnements non-Windows, Subversion est capable de suivre en versions les fichiers de type lien symbolique (ou symlink ). Un symlink est un fichier qui agit comme une sorte de rfrence transparente vers un autre objet du systme de fichiers, permettant des programmes de consulter et de modifier ces objets de faon indirecte en effectuant les oprations sur le symlink lui-mme. Quand un symlink est propag vers un dpt Subversion, Subversion enregistre que ce fichier tait en fait un symlink et note l'objet vers lequel il pointait . Quand ce symlink est extrait vers une autre copie de travail sur un systme nonWindows, Subversion reconstruit un vritable lien symbolique, au niveau du systme de fichiers, partir du symlink enregistr. Mais ceci ne limite en aucune faon l'usage des copies de travail sur des systmes tels que Windows, qui ne possdent pas d'implmentation des symlinks. Sur de tels systmes, Subversion se contente de crer un fichier texte ordinaire, qui contient le chemin vers lequel le symlink pointait l'origine. Bien que ce fichier ne puisse tre utilis comme un symlink sur un systme Windows, il n'empche pas les utilisateurs de Windows d'effectuer leurs autres oprations Subversion.

Voici un aperu des cinq sous-commandes Subversion les plus utilises pour faire des modifications sur l'arborescence : svn add truc Marque le fichier, le rpertoire ou le lien symbolique truc pour ajout. Lors de la prochaine propagation, truc devient un fils de son rpertoire parent. Notez que si truc est un rpertoire, tout ce qui se trouve l'intrieur de truc est marqu pour ajout. Si vous ne dsirez ajouter que truc lui-mme, passez l'option --depth empty. svn delete truc Marque le fichier, le rpertoire ou le lien symbolique truc pour suppression. Si truc est un fichier ou un lien, il est immdiatement supprim de votre copie de travail. Si truc est un rpertoire, il n'est pas supprim, mais Subversion le marque pour suppression. Quand vous propagez vos modifications, truc est compltement supprim de votre copie de travail et du dpt. 2 svn copy truc bidule Cre un nouvel lment bidule par duplication de truc et marque automatiquement bidule pour ajout. Lorsque bidule est ajout au dpt, lors de la prochaine propagation, son historique est enregistr (comme ayant t cr partir de truc). svn copy ne cre pas de rpertoires intermdiaires, moins que vous ne lui passiez l'option --parents. svn move truc bidule Cette commande quivaut exactement svn copy truc bidule; svn delete truc. C'est--dire que bidule est marqu pour ajout en tant que copie de truc et que truc est marqu pour suppression. svn move ne cre pas de rpertoires intermdiaires, moins que vous ne lui passiez l'option --parents. svn mkdir blort Cette commande quivaut exactement mkdir blort; svn add blort. C'est--dire qu'un nouveau rpertoire nomm blort est cr et marqu pour ajout.

Bien sr, rien n'est jamais totalement supprim du dpt seulement de la rvision HEAD du dpt. Vous pouvez rcuprer tout ce que vous avez supprim en extrayant (ou en mettant jour votre copie de travail ) une rvision prcdente de celle dans laquelle vous avez fait la suppression. Lisez galement la section intitule Rsurrection des lments effacs .

22

Utilisation de base

Modifier le dpt sans copie de travail Dans certains cas, les modifications d'arborescence sont propages immdiatement vers le dpt. Cela n'arrive que quand une sous-commande opre directement sur une URL et non sur le chemin d'une copie de travail. En particulier, certains usages de svn mkdir, svn copy, svn move et svn delete peuvent fonctionner avec des URL (et n'oubliez pas que svn import agit toujours sur une URL). Les oprations sur les URL se comportent de cette manire parce que les commandes qui oprent sur une copie de travail peuvent utiliser la copie de travail comme une sorte de zone de transit pour y prparer vos modifications avant de les propager vers le dpt. Les commandes qui oprent sur des URL ne disposent pas d'un tel luxe, donc quand vous oprez directement sur une URL, toute action mentionne ci-dessus est propage immdiatement.

Examiner les changements apports


Une fois vos modifications apportes, vous devez les intgrer au dpt. Avant de le faire, il est souvent utile de jeter un coup d'il sur ces modifications pour savoir exactement ce que vous avez chang. En examinant les modifications avant de les intgrer au dpt, le commentaire associ la propagation sera souvent plus pertinent. ventuellement, vous verrez que vous avez modifi un fichier par inadvertance et cela vous donne une chance de revenir sur ces modifications avant de les propager au dpt. En outre, c'est une bonne occasion de passer en revue et d'examiner les modifications avant de les publier. Vous pouvez obtenir une vue d'ensemble des modifications que vous avez faites en utilisant svn status et voir le dtail de ces changements en utilisant svn diff. Regardez a : pas besoin de rseau ! Vous pouvez utiliser les commandes svn status, svn diff, et svn revert sans aucun accs rseau mme si votre dpt est distant. C'est ainsi plus facile de grer vos changements lorsque vous tes isol, dans un avion, dans un train de banlieue ou mme sur la plage3. En effet, Subversion garde en cache des copies prives des versions originales de chaque fichier suivi en version dans les zones administratives .svn. Cela lui permet d'afficher (et ventuellement d'annuler) les modifications faites localement ces fichiers, sans le moindre accs rseau. Ce cache (appel la base texte ) permet galement Subversion, lors d'une propagation, de n'envoyer au dpt, sous forme de delta, que les modifications (compresses) faites par l'utilisateur. Disposer d'un tel cache est un norme avantage, mme dans le cas d'une connexion Internet haut dbit, car il est beaucoup plus rapide d'envoyer des diffrences sur un fichier plutt que l'ensemble du fichier au serveur.

Subversion a t optimis pour vous aider dans cette tche et il est capable de faire beaucoup de choses sans communiquer avec le dpt. En particulier, votre copie de travail conserve, dans le rpertoire .svn, la copie de l'original de chaque fichier suivi en versions. C'est pour a que Subversion peut vous indiquer rapidement en quoi vos fichiers ont chang, ou mme vous permettre d'annuler vos changements sans contacter le dpt.

Avoir une vue d'ensemble des changements effectus


Pour avoir une vue d'ensemble des changements que vous avez effectus, utilisez la commande svn status. C'est certainement la commande que vous utiliserez le plus. Utilisateurs de CVS : attention la commande update ! Vous avez certainement l'habitude d'utiliser cvs update pour visualiser les changements que vous avez effectus sur votre copie de travail. svn status vous donne toutes les informations utiles ce propos, sans accs au dpt et sans incorporer les changements effectus par d'autres utilisateurs. Dans Subversion, svn update ne s'occupe que de la mise jour : il met jour votre copie de travail avec tous les changements propags dans le dpt depuis votre dernire mise jour. Il faut vous dbarrasser de l'habitude d'utiliser la commande update pour visualiser les modifications que vous avez effectues sur votre copie de travail locale.

Et que vous n'avez pas de carte Wifi. Vous ne croyiez tout de mme pas nous avoir aussi facilement ?

23

Utilisation de base

Si vous lancez svn status sans argument la racine de votre copie de travail, Subversion dtecte toutes les modifications effectues sur les fichiers et sur l'arborescence. Voici quelques exemples de codes que la commande svn status affiche (notez que le texte aprs # n'est pas affich par svn status). ? A C D M gribouillage.c bazar/pognon/machin.h bazar/pognon/tas.c bazar/poisson.c truc.c # le fichier n'est pas suivi en versions # le fichier sera Ajout # le fichier entre en Conflit avec une mise jour # le fichier sera supprim (Deletion en anglais) # le contenu de truc.c a subi des Modifications

Dans ce format d'affichage, svn status affiche six colonnes de caractres, suivis par plusieurs espaces, suivis par un nom de fichier ou de rpertoire. La premire colonne indique le statut du fichier ou du rpertoire et/ou son contenu. Les codes sont : A lment Le fichier, rpertoire ou lien symbolique lment est marqu pour ajout au dpt. C lment Le fichier lment est dans un tat de conflit. C'est--dire que des modifications ont eu lieu dans le dpt depuis votre dernire mise jour et ces modifications interfrent avec les modifications que vous avez effectues sur votre copie de travail (et la mise jour n'a pas rsolu ce conflit). Vous devez rsoudre ce conflit avant de propager vos changements vers le dpt. D lment Le fichier, rpertoire ou lien symbolique lment est marqu pour suppression ( Deletion en anglais). M lment Le contenu du fichier lment a t modifi. Si vous spcifiez un chemin svn status, vous obtenez uniquement les informations relatives ce chemin : $ svn status bazar/poisson.c D bazar/poisson.c svn status possde aussi une option --verbose (-v) pour le rendre plus verbeux : il affiche alors le statut de tous les lments de votre copie de travail, mme ceux qui n'ont pas subi de modification : $ svn status -v M 44 44 M 44 44 44 D 44 44 A 0 44

23 30 20 18 35 19 21 ? 36

sally sally harry ira harry ira sally ? harry

LISEZMOI INSTALL truc.c bazar bazar/truite.c bazar/poisson.c bazar/divers bazar/divers/machin.h bazar/divers/bidule.c

C'est la version longue de l'affichage de svn status. Les lettres de la premire colonne ont la mme signification que prcdemment, mais la deuxime colonne indique le numro de rvision de travail de l'lment. Les troisime et quatrime colonnes indiquent le numro de la rvision dans laquelle a eu lieu le changement le plus rcent et qui l'a effectu. Aucune des commandes cites ci-dessus n'induit de connexion vers le dpt : elles comparent les mtadonnes du rpertoire .svn avec la copie de travail. Enfin, il y a l'option --show-updates (-u) qui effectue une connexion au dpt et ajoute les informations sur les lments prims :

24

Utilisation de base

$ svn status -u -v M * 44 23 M 44 20 * 44 35 D 44 19 A 0 ? tat par rapport la rvision

sally harry harry ira ? 46

LISEZMOI truc.c bazar/truite.c bazar/poisson.c bazar/divers/machin.h

Notez les deux astrisques : si vous lanciez la commande svn update, vous recevriez les changements relatifs LISEZMOI et truite.c. Cela vous procure des informations particulirement intressantes : vous devez faire une mise jour et rcuprer les changements effectus sur LISEZMOI avant de propager les vtres, sinon le dpt rejettera votre propagation en la considrant comme prime (le sujet est approfondi plus tard). svn status peut afficher beaucoup plus d'informations sur les fichiers et rpertoires de votre copie de travail que ce que nous venons de voir ici. Pour obtenir une description exhaustive de svn status et de ses modes d'affichage, reportez-vous svn status.

Voir en dtail les modifications que vous avez effectues


La commande svn diff offre une autre faon d'examiner vos changements. Vous pouvez retrouver exactement ce que vous avez modifi en lanant la commande svn diff sans argument : elle affiche les changements au format diff unifi. $ svn diff Index: truc.c =================================================================== --- truc.c (rvision 3) +++ truc.c (copie de travail) @@ -1,7 +1,12 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <unistd.h> + +#include <stdio.h> int main(void) { - printf("Soixante-quatre tranches de fromage...\n"); + printf("Soixante-cinq tranches de fromage...\n"); return 0; } Index: LISEZMOI =================================================================== --- LISEZMOI (rvision 3) +++ LISEZMOI (copie de travail) @@ -193,3 +193,4 @@ +Pense-bte : passer au pressing. Index: bazar/poisson.c =================================================================== --- bazar/poisson.c (rvision 1) +++ bazar/poisson.c (copie de travail) -Bienvenue dans le fichier 'poisson'. -Plus d'informations seront disponibles prochainement. Index: bazar/divers/machin.h ================================================================== --- bazar/divers/machin.h (rvision 8) +++ bazar/divers/machin.h (copie de travail) +Voici un nouveau fichier pour +crire sur les machins. La commande svn diff produit ces lignes en comparant vos fichiers de travail aux copies originales en cache dans la zone .svn. Les fichiers marqus pour ajout sont affichs comme toute section de texte ajoute, et les fichiers marqus pour suppression sont affichs comme toute section de texte supprime. L'affichage est conforme au format diff unifi. C'est--dire que les lignes supprimes commencent par le signe - et que les lignes ajoutes commencent par le signe +. svn diff affiche galement le nom du fichier et la localisation dans le fichier, 25

Utilisation de base

l'intention du programme patch. Vous pouvez ainsi crer des correctifs en redirigeant la sortie de svn diff vers un fichier : $ svn diff > fichier-correctif Vous pouvez, par exemple, envoyer par mail le fichier correctif un autre dveloppeur pour relecture ou test avant de le propager vers le dpt. Subversion utilise son propre moteur de calcul de diffrences, qui produit par dfaut des rsultats au format diff unifi. Si vous dsirez obtenir les diffrences dans un autre format, spcifiez un programme de comparaison externe en utilisant l'option -diff-cmd et en fournissant les paramtres que vous voulez l'aide de l'option --extensions (-x). Par exemple, pour obtenir les diffrences entre votre version locale du fichier et l'original de truc.c au format contexte et en ignorant la casse des caractres, vous pouvez lancer la commande svn diff --diff-cmd /usr/bin/diff --extensions 'i' truc.c.

Annuler des changements sur la copie de travail


Supposons qu'en examinant la sortie de svn diff, vous vous rendiez compte que tous les changements effectus sur un fichier donn sont errons. Peut-tre auriez-vous d laisser le fichier tel quel, ou bien peut-tre qu'il serait plus facile de reprendre les changements depuis le dbut. C'est l'occasion idale pour utiliser svn revert : $ svn revert LISEZMOI 'LISEZMOI' rinitialis Subversion ramne le fichier dans son tat d'avant les modifications en le remplaant par la copie de l'original stocke dans la zone .svn. Mais notez aussi que svn revert peut annuler n'importe quelle opration. Par exemple, vous pouvez dcider que, aprs tout, vous ne voulez pas ajouter tel fichier : $ svn status truc ? truc $ svn add truc A truc $ svn revert truc 'truc' rinitialis $ svn status truc ? truc

svn revert element produit exactement le mme effet qu'effacer element de votre copie de travail puis de lancer la commande svn update -r BASE element. Toutefois, si vous voulez revenir une version antrieure d'un fichier, svn revert a un comportement notablement diffrent : il n'a pas besoin de contacter le dpt pour restaurer le fichier. Ou que vous avez peut-tre effac un fichier par mgarde : $ svn status LISEZMOI $ svn delete LISEZMOI D LISEZMOI $ svn revert LISEZMOI 'LISEZMOI' rinitialis $ svn status LISEZMOI 26

Utilisation de base

Rsoudre les conflits (fusionner des modifications)


Nous avons dj vu que svn status -u est capable de prvoir les conflits. Supposons que vous lanciez svn update et que le rsultat suivant apparaisse : $ svn update U INSTALL G LISEZMOI Conflit dcouvert dans 'machin.c'. Slectionner : (p) report, (df) diff complet, (e) dite, (h) aide pour plus d'options : Les codes U et G ne doivent pas vous inquiter, les fichiers correspondants ayant absorb sans problme les modifications venant du dpt. Les fichiers nots U (pour Updated ) ne contenaient aucun changement local mais ont t mis jour partir de changements prsents dans le dpt. Le G (pour merGed ) signifie fusionn, ce qui veut dire que le fichier avait subi des changements localement et que les changements en provenance du dpt ont pu tre appliqus sans affecter les changements locaux. Mais les deux lignes suivantes font partie d'une fonctionnalit (apparue dans Subversion 1.5) appele rsolution interactive des conflits. Cela signifie que les changements du dpt interfrent avec les vtres et que vous avez la possibilit de rsoudre ce conflit. Les options les plus utilises sont affiches, mais vous pouvez voir toutes les options possibles en tapant h : (p) (df) (e) (r) (mf) (tf) (l) (h)

report diff-complet dite rsolu mien complet autre complet lance aide

marque ce conflit pour rsolution ultrieure montre toutes les diffrences du fichier fusionn rsout manuellement le conflit avec un diteur utilise la version fusionne utilise ma version (ignore les autres ditions) prends la version du dpt (perds mes ditions) utilise un outil externe pour rsoudre le conflit affiche cette liste

Regardons brivement ce que recle chaque option avant de les dtailler : (p) report laisser le fichier en tat de conflit, conflit que vous devrez rsoudre aprs la fin de la mise jour. (df) diff-complet afficher les diffrences entre la rvision de base et le fichier en conflit au format diff unifi. (e) dite ouvrir le fichier en conflit avec votre diteur de texte favori, qui est spcifi dans la variable d'environnement EDITOR. (r) rsolu aprs dition du fichier, indiquer Subversion que vous avez rsolu les conflits l'intrieur du fichier et qu'il doit accepter son contenu actuel ; en bref, vous avez rsolu le conflit. (mf) mien complet ignorer les changements envoys par le serveur et utiliser uniquement votre version locale pour le fichier concern. (tf) autre complet ignorer vos changements sur le fichier concern et utiliser la version envoye par le serveur. (l) lance lancer un programme externe pour rsoudre le conflit. Ceci ncessite un peu de prparation en amont. (h) aide 27

Utilisation de base

afficher la liste de toutes les commandes que vous pouvez utiliser dans la rsolution interactive des conflits. Nous allons maintenant passer en revue chaque commande, en les classant par fonctionnalit.

Voir les lignes en conflit de faon interactive


Avant de dcider comment rsoudre un conflit de manire interactive, il est probable que vous vouliez examiner le dtail des lignes en conflit. La commande diff (d) est faite pour a : Slectionner : (p) report, (df) diff-complet, (e) dite, (h) aide pour plus d'options : d --- .svn/text-base/sandwich.txt.svn-base mar. 11 dc. 2007, 21:33:57 +++ .svn/tmp/tempfile.32.tmp mar. 11 dc. 2007, 21:34:33 @@ -1 +1,5 @@ -Achte-moi un sandwich. +<<<<<<< .mien +Va chercher un hamburger. +======= +Apporte moi un taco ! +>>>>>>> .r32 La premire ligne du diff correspond ce que contenait la copie de travail dans l'ancienne version (la rvision BASE), la ligne suivante correspond vos modifications et la dernire ligne contient les modifications reues du serveur (la rvision HEAD la plupart du temps). Une fois en possession de ces informations, vous tes prts pour la suite.

Rsoudre les conflits en mode interactif


Il y a quatre faons de rsoudre un conflit avec l'interface interactive : deux d'entre elles vous permettent de fusionner et d'adapter les modifications de manire interactive, alors que les deux autres vous permettent simplement de choisir une version du fichier parmi celles proposes et de passer la suite. Si vous dsirez choisir une combinaison de vos modifications locales, vous pouvez utiliser la commande dite (e) pour modifier manuellement le fichier avec des marqueurs indiquant les conflits dans un diteur de texte (dtermin par la valeur de la variable d'environnement EDITOR). L'dition manuelle de ce fichier avec votre diteur prfr peut sembler quelque peu bas de gamme (voir la section intitule Rsoudre les conflits la main pour une description dtaille), c'est pourquoi certains prfrent utiliser des outils graphiques plus volus et spcialiss dans la fusion de documents. Pour utiliser un outil de fusion, vous devez soit configurer la variable d'environnement SVN_MERGE, soit dfinir l'option merge-tool-cmd dans votre fichier de configuration Subversion (voir la section intitule Options de configuration pour plus de dtails). Subversion passera quatre arguments l'outil de fusion : le fichier dans sa rvision BASE, la version du fichier envoye par le serveur lors de la mise jour, une copie du fichier contenant vos propres modifications et une copie fusionne du fichier (contenant des marqueurs de conflits). Si votre outil attend les arguments dans un ordre ou un format diffrents, vous devrez crire un script de transformation que Subversion appellera. Aprs avoir dit le fichier, si vous tes satisfait de vos changements, vous pouvez indiquer Subversion que le fichier n'est plus en conflit en utilisant la commande rsolu (r). Si vous dcidez qu'il n'y a pas lieu d'effectuer de fusion et si choisir l'une ou l'autre des versions proposes du fichier vous convient, vous pouvez soit opter pour vos changements (c'est--dire mien ) en utilisant la commande mien complet (mf) ou opter pour la version des autres collaborateurs en utilisant la commande autre complet (tf).

Remettre plus tard la rsolution d'un conflit


Le titre peut laisser penser un paragraphe sur l'amlioration des relations conjugales, mais il s'agit bien toujours de Subversion, voyez plutt. Si, lorsque vous effectuez une mise jour, Subversion soulve un conflit que vous n'tes pas prt rsoudre, vous pouvez, fichier par fichier, taper p, pour remettre plus tard la rsolution du conflit. Si, lors de votre mise jour, vous ne voulez rsoudre aucun conflit, vous pouvez passer l'option --non-interactive svn update et les fichiers en conflit seront automatiquement marqus C. Le C indique un conflit, c'est--dire que les changements sur le serveur interfrent avec les vtres et vous devez donc choisir manuellement entre les diffrentes modifications aprs la fin de la procdure de mise jour. Quand vous repoussez plus tard 28

Utilisation de base

la rsolution d'un conflit, Subversion va accomplir trois actions qui vous aideront reprer et rsoudre ce conflit : Subversion affiche un C pendant la mise jour et enregistre que le fichier est dans un tat de conflit. Si Subversion considre que le fichier peut tre fusionn, il place dans le fichier des marqueurs de conflit (des chanes de caractres spciales qui dnotent les contours des conflits) pour mettre en exergue les zones de conflit (Subversion utilise la proprit svn:mime-type pour dterminer si un fichier peut subir une fusion contextuelle ligne par ligne ; voir la section intitule Type de contenu des fichiers pour en apprendre davantage). Pour chaque fichier en conflit, Subversion place trois fichiers supplmentaires non-suivis en versions dans votre copie de travail : nom_du_fichier.mine C'est votre fichier tel qu'il tait dans votre copie de travail avant la mise jour, c'est--dire sans les marqueurs de conflits. Ce fichier ne comporte que vos derniers changements (si Subversion considre que le fichier ne peut pas tre fusionn, le fichier .mine n'est pas cr, car il serait identique la version de travail). nom_du_fichier.rANCIENNE_REVISION C'est le fichier tel qu'il tait la rvision BASE, avant la mise jour de votre copie de travail. C'est donc le fichier que vous avez extrait avant de faire vos dernires modifications. nom_du_fichier.rNOUVELLE_REVISION C'est le fichier que vous venez de recevoir du serveur quand vous avez effectu la mise jour. Ce fichier correspond la rvision HEAD du dpt. Ici, ANCIENNE_REVISION est le numro de rvision du fichier dans votre rpertoire .svn et NOUVELLE_REVISION est le numro de rvision de HEAD dans le dpt. Par exemple, Sally effectue un changement sur le fichier sandwich.txt mais elle ne propage pas immdiatement ses modifications. Pendant ce temps, Harry propage des changements sur ce mme fichier. Sally met jour sa copie de travail avant d'effectuer la propagation et un conflit apparat, dont elle remet la rsolution plus tard : $ svn update Conflit dcouvert dans 'sandwich.txt'. Slectionner : (p) report, (df) diff-complet, (e) dite, (h) aide pour plus d'options : d C sandwich.txt Actualis la rvision 2. $ ls -1 sandwich.txt sandwich.txt.mine sandwich.txt.r1 sandwich.txt.r2 partir de l, Subversion n'autorisera pas Sally propager le fichier sandwich.txt avant que les trois fichiers temporaires ne soient effacs : $ svn commit -m "Quelques petits ajouts" svn: chec de la propagation (commit), dtails : svn: Arrt de la propagation : '/home/sally/travail-svn/sandwich.txt' demeure en conflit Si vous avez remis plus tard la rsolution d'un conflit, vous devez le rsoudre pour que Subversion vous autorise propager vos changements. Vous pouvez le faire avec la commande svn resolve et l'option --accept suivie d'un argument. Si vous choisissez la version du fichier que vous avez extraite avant de faire vos changements, utilisez l'argument base. Si vous choisissez la version qui contient uniquement vos changements, utilisez l'argument mine-full. Si vous choisissez la version la plus rcente venant du serveur (et donc abandonnez tous vos changements), utilisez l'argument 29

Utilisation de base

theirs-full. Cependant, si vous comptez effectuer un mlange de vos modifications et des modifications rapatries du serveur, fusionnez le fichier en conflit la main (examinez et ditez les marqueurs de conflit dans le fichier) puis utilisez l'argument working. svn resolve supprime les trois fichiers temporaires et retient la version du fichier que vous avez spcifi avec l'option -accept. Subversion considre ds lors que le fichier n'est plus dans un tat de conflit : $ svn resolve --accept working sandwich.txt Conflit sur 'sandwich.txt' rsolu

Rsoudre les conflits la main


Rsoudre les conflits la main peut paratre quelque peu intimidant la premire fois. Mais avec un peu de pratique, un enfant de cinq ans y arriverait. Prenons un exemple. Par manque de communication entre Sally (votre collaboratrice) et vous-mme, vous ditez en mme temps le fichier sandwich.txt. Sally propage ses changements et, quand vous mettez jour votre copie de travail, un conflit apparat, que vous devez rsoudre en ditant sandwich.txt. Jetons un il ce fichier : $ cat sandwich.txt Tranche de pain suprieure Mayonnaise Laitue Tomate Comt <<<<<<< .mine Saucisson Mortadelle Jambon ======= Choucroute Poulet rti >>>>>>> .r2 Moutarde Tranche de pain infrieure Les suites de caractres infrieur- (<), gal(=) ou suprieur- (>) sont des marqueurs de conflit, il ne font pas partie des donnes elles-mmes. Vous devrez en gnral vous assurer qu'elles ont disparu du fichier avant de propager vos modifications. Le texte entre les deux premiers marqueurs est constitu des modifications que vous avez apportes dans la zone de conflit : <<<<<<< .mine Saucisson Mortadelle Jambon ======= Le texte entre le deuxime et le troisime marqueur est celui du fichier propag par Sally : ======= Choucroute Poulet rti >>>>>>> .r2 Normalement, vous n'allez pas juste supprimer les marqueurs et les changements effectus par Sally (elle sera affreusement due quand on lui apportera un sandwich diffrent de ce qu'elle a command). Vous dcrochez donc le tlphone, ou vous traversez le bureau, pour expliquer Sally qu'on ne met pas de choucroute dans un sandwich. 4 Aprs vous tre mis d'accord
4

Et si vous commandez a, on vous chassera de la ville coup de baguette rassie.

30

Utilisation de base

sur les changements enregistrer, ditez votre fichier et enlevez les marqueurs de conflit. Tranche de pain suprieure Mayonnaise Laitue Tomate Comt Saucisson Mortadelle Jambon Moutarde Tranche de pain infrieure Maintenant utilisez svn resolve et vous tes par pour propager vos changements : $ svn resolve --accept working sandwich.txt Conflit sur 'sandwich.txt' rsolu $ svn commit -m "Va pour mon sandwich et au diable celui de Sally !" Notez que svn resolve, contrairement la plupart des autres commandes que nous prsentons dans ce chapitre, requiert que vous listiez explicitement les noms de tous les fichiers concerns. Dans tous les cas, soyez prudent et ne lancez svn resolve qu'une fois certain que vous avez rsolu le conflit dans votre fichier (une fois les fichiers temporaires effacs, Subversion vous laisse propager le fichier mme s'il contient toujours des marqueurs de conflit). Si jamais vous tes perdu lors de l'dition du fichier en conflit, vous pouvez toujours consulter les trois fichiers que Subversion a cr pour vous dans votre copie de travail, y compris le fichier tel qu'il tait avant que vous ne lanciez la mise jour. Vous pouvez mme utiliser un outil externe interactif spcialis dans les fusions pour examiner ces trois fichiers.

Abandonner vos modifications au profit de la rvision la plus rcente


Si vous faites face un conflit et que vous dcidez d'abandonner vos changements, vous pouvez lancer svn resolve -accept theirs-full CHEMIN-DU-CONFLIT, et Subversion abandonne vos modifications et supprime les fichiers temporaires : $ svn update Conflit dcouvert dans 'machin.c'. Slectionner : (p) report, (df) diff complet, (e) dite, (h) aide pour plus d'options : C sandwich.txt Actualis la rvision 2. $ ls sandwich.* sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1 $ svn resolve --accept theirs-full sandwich.txt Conflit sur 'sandwich.txt' rsolu

Revenir en arrire : utiliser svn revert


Si vous faites face un conflit et qu'aprs examen de la situation, vous dcidez d'abandonner vos changements et de repartir de zro (peu importe en fait que ce soit aprs un conflit ou n'importe quel autre moment), contentez-vous de revenir en arrire sur vos changements : $ svn revert sandwich.txt 'sandwich.txt' rinitialis $ ls sandwich.* sandwich.txt Notez que quand vous revenez en arrire sur un fichier en conflit, vous n'avez pas besoin de lancer svn resolve.

31

Utilisation de base

Propager vos modifications


Enfin ! Vos modifications sont termines, vous les avez fusionnes avec celles du serveur et vous tes prt les propager vers le dpt. La commande svn commit envoie vos changements au dpt. Quand vous propagez un changement, vous devez l'accompagner d'un message de propagation qui dcrit ce changement. Votre message est associ la nouvelle rvision que vous crez. Si votre message est bref, vous pouvez le passer en ligne de commande en utilisant l'option --message (ou -m) : $ svn commit -m "J'ai corrig le nombre de tranches de fromage." Envoi sandwich.txt Transmission des donnes . Rvision 3 propage. Cependant, si vous avez rdig votre message au fur et mesure, vous souhaitez srement indiquer Subversion de rcuprer le message dans un fichier en lui donnant le nom du fichier avec l'option --file (-F) : $ svn commit -F message_de_propagation Envoi sandwich.txt Transmission des donnes . Rvision 4 propage. Si vous ne spcifiez ni l'option --message ni l'option --file, Subversion lance automatiquement votre diteur de texte favori (voir les dtails de editor-cmd dans la section intitule Fichier config ) pour que vous rdigiez le message de propagation. Si, au moment o vous rdigez votre message de propagation, vous dcidez d'annuler la propagation, vous n'avez qu' quitter l'diteur de texte sans sauvegarder les changements. Si vous avez dj sauvegard le message, effacez le texte, sauvegardez nouveau puis choisissez d'annuler : $ svn commit Attente de Emacs...Fait Entre du journal non modifi ou non prcis a)nnule, c)ontinue, e)dite a $

Le dpt ne sait pas si vos changements ont un sens ou pas (d'ailleurs, il s'en fiche) ; il vrifie seulement que personne n'a modifi, pendant que vous aviez le dos tourn, un des fichiers que vous-mme avez modifi. Si c'est le cas, la propagation toute entire choue, affichant un message vous informant qu'un ou plusieurs de vos fichiers ne sont plus jour : $ svn commit -m "Ajout d'une autre rgle" Envoi regles.txt svn: Echec de la propagation (commit), dtails : svn: Fichier '/regles.txt' obsolte Notez que le phras exact de ce message d'erreur dpend du protocole rseau et du serveur que vous utilisez, mais l'ide reste la mme. Maintenant, vous devez lancer svn update, traiter les fusions ou conflits qui apparaissent et retenter une propagation. Nous en avons termin avec le cycle d'utilisation de base de Subversion. Subversion offre beaucoup d'autres fonctionnalits pour grer votre dpt et votre copie de travail, mais l'utilisation quotidienne de Subversion ne requiert pratiquement que les commandes que nous venons de voir dans ce chapitre. Intressons-nous quand mme quelques commandes supplmentaires 32

Utilisation de base

utilises relativement souvent.

Utilisation de l'historique
Votre dpt Subversion est comme une machine remonter le temps. Il garde une trace de tous les changements jamais propags et permet de parcourir cet historique en examinant aussi bien les versions prcdentes des fichiers et des rpertoires que les mtadonnes associes. D'une simple commande Subversion, vous pouvez extraire (ou restaurer) une copie de travail du dpt tel qu'il tait n'importe quelle date ou numro de rvision passe. Cependant, vous voulez parfois juste sonder le pass sans y retourner. Plusieurs commandes renvoient des informations sur l'historique des donnes prsentes dans le dpt : svn log fournit beaucoup d'informations : les messages de propagation avec la date et l'auteur de la rvision ainsi que les chemins qui ont t modifis chaque rvision. svn diff affiche les dtails, ligne par ligne, d'un changement donn. svn cat rcupre le fichier tel qu'il existait une rvision donne et l'affiche l'cran. svn list liste les fichiers contenus dans un rpertoire une rvision donne.

Affichage de l'historique
Pour connatre l'historique d'un fichier ou d'un rpertoire, utilisez la commande svn log. Elle affiche la liste des gens qui ont modifi le fichier ou le rpertoire en question, le numro de chaque rvision o il a chang, l'heure et la date de cette rvision et, s'il y en avait un, le message associ la propagation : $ svn log -----------------------------------------------------------------------r3 | sally | 2008-05-15 23:09:28 -0500 (jeu. 15 Mai 2008) | 1 ligne Ajout des lignes include et correction du nombre de tranches de fromage. -----------------------------------------------------------------------r2 | harry | 2008-05-14 18:43:15 -0500 (mer. 14 Mai 2008) | 3 lignes Ajout des mthodes main(). -----------------------------------------------------------------------r1 | sally | 2008-05-10 19:50:31 -0500 (sam. 10 Mai 2008) | 1 ligne Import initial -----------------------------------------------------------------------Notez que, par dfaut, l'historique est affich en ordre chronologique inverse. Si vous voulez afficher un intervalle de rvisions donn dans un ordre particulier ou juste une seule rvision, ajoutez l'option --revision (-r) : $ svn log -r 5:19 $ svn log -r 19:5 # affiche l'historique a partir de la rvision 5 # jusqu' la rvision 19 dans l'ordre chronologique # affiche l'historique partir de la rvision 5 # jusqu' la rvision 19 dans l'ordre # chronologique inverse # affiche l'historique de la rvision 8

$ svn log -r 8

33

Utilisation de base

Vous pouvez aussi afficher l'historique d'un fichier ou d'un rpertoire particulier. Par exemple : $ svn log machin.c $ svn log http://machin.com/svn/trunk/code/machin.c Ceci n'affiche le contenu de l'historique que pour les rvisions dans lesquelles le fichier de travail (ou l'URL) a chang. Pourquoi svn log n'affiche-t-il pas ce que je viens de propager ? Si vous effectuez une propagation puis tapez immdiatement svn log sans argument, vous remarquerez peut-tre que votre propagation la plus rcente est absente de l'historique obtenu. Ceci est d une combinaison de deux facteurs : la faon dont fonctionne svn commit et le fonctionnement par dfaut de svn log. Tout d'abord, quand vous propagez des modifications vers le dpt, Subversion ne rcupre que la rvision des fichiers (et rpertoires) qu'il propage, donc le rpertoire parent demeure gnralement l'ancienne rvision (voir la section intitule Mise jour et propagation sont deux choses distinctes pour savoir pourquoi). La commande svn log ne rcupre ensuite par dfaut que l'historique du rpertoire la rvision actuelle et n'affiche donc pas les modifications propages dernirement. La solution ce problme consiste soit mettre jour votre copie de travail soit fournir explicitement svn log un numro de rvision grce l'option --revision (-r).

Si vous voulez obtenir plus d'informations sur un fichier ou un rpertoire, svn log accepte galement l'option --verbose (-v). Comme Subversion autorise les dplacements et les copies de rpertoires et de fichiers, il est important de pouvoir tracer ces modifications de chemin dans le systme de fichiers. Ainsi, en mode verbeux, svn log affiche la liste des dplacements au cours de la rvision concerne : $ svn log -r 8 -v -----------------------------------------------------------------------r8 | sally | 2008-05-21 13:19:25 -0500 (mer. 21 Mai 2008) | 1 ligne Chemins modifis : M /trunk/code/machin.c M /trunk/code/bidule.h A /trunk/code/doc/LISEZMOI Machination du bidule. -----------------------------------------------------------------------svn log accepte aussi l'option --quiet (-q), qui permet de ne pas afficher le contenu du message de propagation. En combinaison avec --verbose, svn log n'affiche que les noms des fichiers qui ont chang. Pourquoi svn log me donne-t-il une rponse vide ? Aprs un certain temps de pratique de Subversion, la plupart des utilisateurs sont confronts un affichage de ce genre : $ svn log -r 2 -----------------------------------------------------------------------$ Au premier abord, cela ressemble une erreur. Mais rappelez-vous que chaque rvision concerne l'ensemble du dpt et que svn log n'opre que sur une arborescence l'intrieur du dpt. Si vous ne passez pas d'argument pour le chemin, Subversion utilise le rpertoire courant par dfaut. En consquence, si vous tes dans un sous-rpertoire de votre copie de travail et que vous demandez voir l'historique d'une rvision pour laquelle aucun changement n'a eu lieu sur lesdits fichiers et rpertoires, Subversion affiche un historique vierge. Si vous voulez connatre tous les changements relatifs cette rvision, invoquez svn log avec l'URL du rpertoire racine de votre dpt, par exemple svn log -r 840076 http://svn.apache.org/repos/asf/subversion/. 34

Utilisation de base

Dtail des modifications passes


Nous avons dj vu la commande svn diff, qui affiche les diffrences entre fichiers au format diff unifi ; nous l'avons utilise pour afficher les modifications locales effectues sur notre copie de travail avant de les propager vers le dpt. En fait, il y a trois faons diffrentes d'utiliser svn diff : Examiner des modifications locales. Comparer votre copie de travail au dpt. Comparer des rvisions du dpt.

Modifications locales
Comme nous l'avons vu prcdemment, svn diff, s'il est invoqu sans option, compare les fichiers de votre copie de travail leurs versions originales gardes en cache dans la zone .svn : $ svn diff Index: regles.txt =================================================================== --- regles.txt (rvision 3) +++ regles.txt (copie de travail) @@ -1,4 +1,5 @@ tre attentif envers les autres Libert = Responsabilit Tout dans la modration -Mcher la bouche ouverte +Mcher la bouche ferme +couter quand les autres parlent $

Comparaison d'une copie de travail au dpt


Si un seul numro de rvision est fourni l'option --revision (-r), votre copie de travail est compare la rvision spcifie du dpt : $ svn diff -r 3 regles.txt Index: regles.txt =================================================================== --- regles.txt (rvision 3) +++ regles.txt (copie de travail) @@ -1,4 +1,5 @@ tre attentif envers les autres Libert = Responsabilit Tout dans la modration -Mcher la bouche ouverte +Mcher la bouche ferme +couter quand les autres parlent $

Comparaison de rvisions du dpt


Si deux numros de rvision sont fournis l'option --revision (-r), spars par le caractre deux-points (:), les deux rvisions sont directement compares : $ svn diff -r 2:3 regles.txt Index: regles.txt =================================================================== 35

Utilisation de base

--- regles.txt (rvision 2) +++ regles.txt (rvision 3) @@ -1,4 +1,4 @@ tre attentif envers les autres -Libert = Glace Au Chocolat +Libert = Responsabilit Tout dans la modration Mcher la bouche ouverte $ Une autre faon de comparer une rvision la prcdente, plus conviviale, est d'utiliser l'option --change (-c) : $ svn diff -c 3 regles.txt Index: regles.txt =================================================================== --- regles.txt (rvision 2) +++ regles.txt (rvision 3) @@ -1,4 +1,4 @@ tre attentif envers les autres -Libert = Glace Au Chocolat +Libert = Responsabilit Tout dans la modration Mcher la bouche ouverte $ Enfin, vous pouvez comparer des rvisions du dpt mme si vous n'avez pas de copie de travail en local sur votre ordinateur, simplement en incluant l'URL approprie sur la ligne de commande : $ svn diff -c 5 http://svn.exemple.com/depot/exemple/trunk/texte/regles.txt $

Navigation dans le dpt


Grce aux commandes svn cat et svn list, vous pouvez afficher des rvisions varies des fichiers et rpertoires sans changer la rvision de votre copie de travail. En fait, vous n'avez mme pas besoin d'avoir une copie de travail pour les utiliser.

svn cat
Si vous voulez examiner une version antrieure d'un fichier et pas ncessairement les diffrences entre deux fichiers, vous pouvez utiliser svn cat : $ svn cat -r 2 regles.txt tre attentif envers les autres Libert = Glace Au Chocolat Tout dans la modration Mcher la bouche ouverte $ Vous pouvez galement rediriger la sortie de svn cat directement dans un fichier : $ svn cat -r 2 regles.txt > regles.txt.v2 $

svn list
La commande svn list liste les fichiers prsents dans le dpt sans pour autant les tlcharger : 36

Utilisation de base

$ svn list http://svn.apache.org/repos/asf/subversion/ README branches/ developer-resources/ mk.xiv/ site/ svn-logos/ tags/ trunk/ Si vous dsirez une liste plus dtaille, passez l'option --verbose (-v) et vous obtenez alors quelque chose comme ceci : $ svn list -v http://svn.apache.org/repos/asf/subversion/ 904709 hwright 30 janv., 03:06 ./ 880872 cmpilato 5362 16 nov., 18:49 README 904644 danielsh 29 janv., 23:05 branches/ 861356 lgo 27 aot 2006 developer-resources/ 868798 brane 02 janv. 2008 mk.xiv/ 904663 cmpilato 30 janv., 00:19 site/ 863801 anonymou 02 sept. 2002 svn-logos/ 901971 cmpilato 22 janv., 04:39 tags/ 904709 hwright 30 janv., 03:06 trunk/ Les colonnes vous indiquent la rvision laquelle le fichier ou le rpertoire a t modifi pour la dernire fois, qui est l'auteur de ce changement, la taille du fichier si c'en est un, la date de dernire modification et le nom de l'lment. La commande svn list sans argument prend pour cible l'URL du dpt correspondant au rpertoire local en cours, pas le rpertoire en cours de la copie de travail. Aprs tout, si vous voulez voir le contenu de votre rpertoire local, vous pouvez utiliser ls, tout simplement (ou l'quivalent sur votre systme non-Unix).

Anciennes versions d'un dpt


En plus de toutes les commandes cites prcdemment, vous pouvez utiliser svn update et svn checkout avec l'option -revision pour ramener une copie de travail complte dans le pass : 5 $ svn checkout -r 1729 # extrait une nouvelle copie de travail # la rvision r1729 $ svn update -r 1729 # met jour une copie de travail existante # la rvision r1729

Beaucoup de nouveaux utilisateurs de Subversion essaient d'utiliser svn update comme dans l'exemple prcdent pour annuler des changements propags, mais a ne marche pas, puisque vous ne pouvez pas propager des changements obtenus en ramenant une vieille version une copie de travail, si les fichiers modifis ont subi des modifications depuis. Voir la section intitule Rsurrection des lments effacs pour une description de la manire d' annuler une propagation. Enfin, si vous tes en train de raliser une version officielle et que vous voulez extraire vos fichiers de Subversion sans avoir ces satans rpertoires .svn, vous pouvez utiliser svn export pour crer une copie locale de tout ou partie de votre dpt sans les rpertoires .svn. De mme que pour svn update et svn checkout, vous pouvez passer l'option --revision svn export :

Vous voyez, on vous avait bien dit que Subversion tait une machine remonter le temps.

37

Utilisation de base

$ svn export http://svn.exemple.com/svn/depot1 # Exporte la dernire rvision $ svn export http://svn.exemple.com/svn/depot1 -r 1729 # Exporte la rvision r1729

Parfois, il suffit de faire le mnage


Maintenant que nous avons trait les tches quotidiennes pour lesquelles vous utiliserez Subversion, nous allons passer en revue quelques tches administratives lies votre copie de travail.

Se dbarrasser d'une copie de travail


Subversion ne conserve sur le serveur aucune trace de l'tat ni de l'existence des copies de travail, il n'y a donc aucun impact ct serveur si des copies de travail tranent un peu partout. De la mme faon, pas besoin de prvenir le serveur quand vous effacez une copie de travail. Si vous envisagez de rutiliser une copie de travail, a ne pose aucun problme de la laisser sur le disque jusqu' ce que vous soyez prts l'utiliser nouveau et, le moment venu, il suffit de lancer svn update pour la mettre jour et ainsi la rendre utilisable. Cependant, si vous tes certain de ne plus utiliser une copie de travail, vous pouvez la supprimer entirement, mais vous seriez bien inspirs d'y jeter un il au cas o des fichiers non-suivis en versions s'y trouveraient encore. Pour trouver ces fichiers, lancez svn status et examinez tous les fichiers marqus d'un ? pour vous assurer qu'ils ne sont d'aucune importance. Une fois cet examen termin, vous pouvez supprimer votre copie de travail en toute scurit.

Reprendre aprs une interruption


Quand Subversion modifie votre copie de travail (ou toute information dans .svn), il essaie de le faire de la manire la plus sre possible. Avant de modifier votre copie de travail, Subversion inscrit ses intentions dans un fichier de traces. Ensuite, il excute les commandes du fichier de traces pour appliquer les modifications demandes, en plaant un verrou sur la partie concerne de la copie de travail pendant cette opration (pour empcher d'autres clients Subversion d'accder cette copie de travail au beau milieu des changements). Pour finir, Subversion supprime le fichier de traces. D'un point de vue architectural, c'est le mme fonctionnement qu'un systme de fichiers journalis. Si une opration Subversion est interrompue (c'est--dire le processus est tu ou la machine plante), le fichier de traces reste sur le disque. En excutant de nouveau le fichier de traces, Subversion peut terminer l'opration en cours et votre copie de travail retrouve un tat cohrent. C'est exactement ce que fait la commande svn cleanup : elle trouve et excute les fichiers de traces restant dans votre copie de travail, en enlevant les verrous au passage. Si un beau jour Subversion vous indique qu'une partie de votre copie de travail est verrouille ( locked en anglais), c'est la commande qu'il faut lancer. Par ailleurs, svn status affiche un L devant les lments verrouills : $ svn status L un-repertoire M un-repertoire/machin.c $ svn cleanup $ svn status M un-repertoire/machin.c Ne confondez pas ces verrous agissant sur la copie de travail avec les verrous ordinaires que les utilisateurs de Subversion crent quand ils utilisent le modle de gestion de versions parallles verrouiller-modifier-librer ; voir l'encadr Les trois types de verrous pour des claircissements.

Rsum
Nous en avons maintenant termin avec la plupart des commandes du client Subversion. Les exceptions notables concernent les branches et la fusion (voir le Chapitre 4, Gestion des branches) ainsi que les proprits (voir le Chapitre 9, Rfrences 38

Utilisation de base

compltes de Subversion). Cependant, prenez le temps de parcourir le Chapitre 9, Rfrences compltes de Subversion pour vous faire une ide de toutes les commandes de Subversion et de la manire dont vous pouvez les utiliser pour rendre votre travail plus convivial.

39

Chapitre 3. Sujets avancs


Si vous lisez ce livre chapitre par chapitre, du dbut la fin, vous avez acquis maintenant suffisamment de connaissance du fonctionnement de Subversion pour effectuer les oprations les plus courantes de gestion de versions. Vous savez comment extraire une copie de travail du dpt Subversion. Vous n'avez aucune difficult propager vos modifications et recevoir des mises jour en utilisant les commandes svn commit et svn update. Vous avez probablement acquis le rflexe, presque inconscient, de lancer la commande svn status. Bref, vous tes apte utiliser Subversion dans un environnement normal pour tout type de projet. Mais les fonctionnalits de Subversion ne s'arrtent pas aux oprations courantes de gestion de versions . Il possde d'autres atouts, en plus de permettre le partage de fichiers et de rpertoires depuis un dpt central. Ce chapitre dvoile certaines fonctionnalits de Subversion qui, bien qu'importantes, ne sont pas d'une utilisation quotidienne pour un utilisateur normal. Nous supposons que vous tes familier avec les possibilits de base de gestion de versions sur les fichiers et rpertoires. Sinon, reportez-vous au Chapitre 1, Notions fondamentales et au Chapitre 2, Utilisation de base. Une fois que vous matriserez ces bases et que vous aurez assimil ce chapitre, vous serez un super-utilisateur de Subversion !

Identifiants de rvision
Comme vous avez pu le constater dans la section intitule Rvisions , les numros de rvision dans Subversion sont d'une grande simplicit, formant une suite d'entiers incrments au fur et mesure des changements propags dans le dpt. Nanmoins, il ne faudra pas longtemps avant que vous ne puissiez plus vous rappeler exactement quel changement correspond quelle rvision. Heureusement, le fonctionnement normal de Subversion ne requiert pas souvent que vous fournissiez explicitement un numro de rvision pour une opration. Pour les oprations qui ncessitent vraiment un numro de rvision, vous pouvez fournir un numro de rvision que vous avez vu soit dans un mail de propagation, soit dans la sortie d'une autre opration Subversion, soit dans un autre contexte o ce numro possdait une signification particulire. Occasionnellement, vous avez besoin d'identifier un moment prcis pour lequel vous n'avez pas de numro de rvision en tte ou sous la main. C'est pourquoi, en plus des numros de rvision, svn accepte galement en entre d'autres formats d'appellations pour les rvisions : les mots-cls de rvision et les dates de rvision. Les diffrentes formes d'appellations pour les rvisions peuvent tre mlanges et compares pour dfinir des intervalles de rvisions. Par exemple, vous pouvez spcifier -r REV1:REV2 o REV1 est un mot-cl de rvision et REV2 est un numro de rvision, ou bien o REV1 est une date et REV2 est un numro de rvision. Comme chaque appellation de rvision est value indpendamment, vous pouvez placer n'importe quel type d'appellation de chaque ct du symbole deux-points.

Mots-cls de rvision
Le client Subversion accepte une grande varit de mots-cls de rvision. En tant qu'argument de l'option --revision (-r) ces mots-cls peuvent tre utiliss en lieu et place des numros et sont remplacs par les numros correspondants par Subversion : HEAD La dernire (c'est--dire la plus rcente) rvision prsente dans le dpt. BASE Le numro de rvision d'un lment de la copie de travail. Si l'lment a t modifi localement, la version BASE fait rfrence l'lment tel qu'il tait sans ces modifications locales. COMMITTED La rvision la plus rcente avant (ou gale ) BASE, dans laquelle un lment a chang. PREV La rvision prcdant immdiatement la dernire rvision dans laquelle un lment a chang. Techniquement, cela revient COMMITTED#1.

40

Sujets avancs

Comme vous pouvez le deviner d'aprs leur description, les mots-cls de rvision PREV, BASE et COMMITTED ne sont utiliss que pour faire rfrence un chemin dans la copie de travail ; ils ne s'appliquent pas des URL du dpt. En revanche, HEAD peut tre utilis avec les deux types de chemin (local ou URL du dpt). Vous trouvez ci-dessous des exemples de l'utilisation de ces mots-cls : $ svn diff -r PREV:COMMITTED machin.c # affiche le dernier changement propag concernant machin.c $ svn log -r HEAD # affiche le message associ la dernire propagation dans le dpt. $ svn diff -r HEAD # compare votre copie de travail (avec tous ses changements locaux) # la dernire version de l'arborescence correspondante du dpt. $ svn diff -r BASE:HEAD machin.c # compare la version non modifie localement de machin.c avec la dernire # version de machin.c dans le dpt. $ svn log -r BASE:HEAD # affiche, pour le rpertoire suivi en versions courant, les messages # de propagation depuis la dernire mise jour (svn update). $ svn update -r PREV machin.c # revient une version en arrire pour le fichier machin.c. Ceci diminue # de un la rvision de la version de travail du fichier machin.c. $ svn diff -r BASE:14 machin.c # compare la version non modifie localement de machin.c avec # la version de ce fichier la rvision 14.

Dates de rvision
Les numros de rvision n'ont aucune signification en dehors du systme de gestion de versions. Cependant, parfois, vous avez besoin d'associer une date relle un moment prcis de l'historique des versions. cette fin, l'option --revision (-r) accepte comme argument une date place entre accolades ({ et }). Subversion accepte les dates et les heures aux formats dfinis dans le standard ISO-8601 ainsi que quelques autres formats. Voici quelques exemples (n'oubliez pas de mettre les dates qui contiennent des espaces entre guillemets) : $ $ $ $ $ $ $ $ $ $ $ svn svn svn svn svn svn svn svn svn svn svn checkout checkout checkout checkout checkout checkout checkout checkout checkout checkout checkout -r -r -r -r -r -r -r -r -r -r -r {2006-02-17} {15:30} {15:30:00.200000} {"2006-02-17 15:30"} {"2006-02-17 15:30 +0230"} {2006-02-17T15:30} {2006-02-17T15:30Z} {2006-02-17T15:30-04:00} {20060217T1530} {20060217T1530Z} {20060217T1530-0500}

Quand vous spcifiez une date, Subversion convertit cette date vers le numro de rvision le plus rcent du dpt la date spcifie. Puis, il continue son travail avec ce numro de rvision : $ svn log -r {2006-11-28} -----------------------------------------------------------------------r12 | ira | 2006-11-27 12:31:51 -0600 (lun. 27 nov. 2006) | 6 lignes 41

Sujets avancs

Subversion retarde-t-il d'une journe ? Si vous spcifiez une date de rvision sans prciser l'heure (par exemple 2006-11-27), vous pourriez penser que Subversion vous donne la dernire rvision qui a eu lieu le 27 novembre. En fait, vous aurez une rvision datant du 26, voire mme avant. Souvenez-vous que Subversion renvoie la rvision la plus rcente du dpt la date spcifie. Si vous spcifiez une date sans prciser l'heure, comme 2006-11-27, Subversion utilise alors 00h00 comme heure et la recherche de la plus rcente rvision ne renvoit donc pas de rsultat correspondant au 27 novembre. Si vous voulez inclure le 27 dans votre recherche, vous pouvez soit spcifier une heure ({"2006-11-27 23:59"}), soit simplement spcifier le jour suivant ({2006-11-28}).

Vous pouvez galement utiliser des intervalles de dates. Subversion trouve alors les rvisions incluses entre ces deux dates : $ svn log -r {2006-11-20}:{2006-11-29}

Puisque l'horodatage d'une rvision est stock comme une proprit modifiable et non suivie en versions de la rvision (reportez-vous la section intitule Proprits ), les horodatages peuvent tre changs et ne pas reflter la chronologie relle. Ils peuvent mme tre tous supprims. Or la capacit de Subversion convertir correctement les dates en numros de rvision dpend des horodatages de rvisions et de leur ordonnancement correct dans le temps : une rvision antrieure correspond un horodatage antrieur. Si cet ordonnancement n'est pas maintenu, il y a de grandes chances que l'utilisation des dates pour spcifier des intervalles de rvisions dans votre dpt ne fournisse pas les rsultats attendus.

Proprits
Nous avons vu en dtail comment Subversion stocke et rcupre les diffrentes versions des fichiers et rpertoires dans le dpt. Des chapitres entiers ont dcrit cette fonctionnalit fondamentale de l'outil. Et si la gestion de versions se limitait a, Subversion couvrirait dj compltement les besoins attendus. Mais ce n'est pas tout. En plus de grer les versions de vos rpertoires et de vos fichiers, Subversion fournit une interface pour ajouter, modifier et supprimer des mta-donnes suivies en versions pour chacun de vos rpertoires et de vos fichiers. On appelle ces mta-donnes des proprits. Elles peuvent tre penses comme des tableaux deux colonnes, qui associent des noms de proprits des valeurs arbitraires, pour chaque lment de votre copie de travail. En termes simples, vous pouvez assigner n'importe quel nom et n'importe quelle valeur vos proprits, la seule condition que le nom soit un texte lisible par un humain. Et l'atout principal de ces proprits rside dans le fait qu'elles sont galement suivies en versions, tout comme le contenu textuel de vos fichiers. Vous pouvez modifier, propager et revenir en arrire sur les proprits aussi facilement que sur le contenu des fichiers. L'envoi et la rception des changements concernant les proprits intervient lors de vos propagations et mises jour : vous n'avez pas changer vos habitudes pour les utiliser. Subversion a rserv pour son propre usage les proprits dont le nom commence par svn:. Bien qu'il n'y en ait seulement que quelques unes d'utilises actuellement, vous ne devez pas crer vos propres proprits avec un nom commenant par ce prfixe. Sinon, vous courez le risque qu'une future version de Subversion dfinisse une proprit ayant le mme nom mais un usage tout autre. Les proprits sont aussi prsentes ailleurs dans Subversion. De la mme manire que pour les fichiers et rpertoires, chaque rvision en tant que telle peut avoir des proprits arbitraires associes. Les mmes contraintes s'appliquent : nom lisible par un humain et valeur arbitraire, ventuellement binaire. La diffrence principale est que les proprits des rvisions ne sont pas suivies en versions. Autrement dit, si vous changez la valeur ou si vous supprimez une proprit d'une rvision, il n'y a pas moyen, en utilisant Subversion, de revenir la valeur prcdente. Subversion ne fournit pas de recommandation prcise quant l'utilisation des proprits. Il demande seulement de ne pas utiliser de nom de proprit qui commence par le prfixe svn:. C'est l'espace de noms qu'il garde pour son propre usage. Et 42

Sujets avancs

Subversion utilise bien lui-mme les proprits, suivies en versions ou pas. Certaines proprits suivies en versions ont une signification particulire ou des effets particuliers quand elles font rfrence un fichier ou un rpertoire, ou stockent des informations relatives la rvision laquelle elles font rfrence. Certaines proprits de rvision sont automatiquement rattaches une rvision par la procdure de propagation et stockent des informations relatives cette rvision. La plupart de ces proprits sont mentionnes ailleurs dans ce chapitre ou dans d'autres chapitres comme faisant partie de sujets plus gnraux. Pour une liste exhaustive des proprits pr-dfinies de Subversion, rfrez-vous la section intitule Proprits dans Subversion . Dans cette section, nous examinons l'utilit des proprits, la fois pour l'utilisateur et pour Subversion lui-mme. Vous apprendrez les sous-commandes svn relatives aux proprits et comment la modification des proprits change votre manire habituelle d'utiliser Subversion.

Utilisation des proprits


l'instar de Subversion, qui utilise les proprits pour stocker des mta-donnes sur les fichiers, les rpertoires et les rvisions qu'il gre, vous pouvez faire une utilisation similaire des proprits. Vous pouvez trouver utile d'avoir un endroit, prs de vos donnes suivies en versions, pour stocker des mta-donnes relatives vos donnes. Imaginons que vous vouliez crer un site Web qui hberge beaucoup de photos et qui les affiche avec une lgende et une date. D'accord, mais votre collection de photos change constamment, donc vous voulez automatiser le plus possible la gestion du site. Ces photos peuvent tre relativement volumineuses et vous voulez pouvoir fournir des miniatures vos visiteurs, comme c'est gnralement le cas sur ce genre de site. Certes, vous pouvez le faire en utilisant des fichiers traditionnels. C'est--dire que vous avez votre image123.jpg et une image123-thumbnail.jpg cte cte dans un rpertoire. Ou, si vous voulez garder les mmes noms de fichier, vous placez vos miniatures dans un rpertoire diffrent, comme thumbnails/image123.jpg. Vous pouvez galement stocker vos lgendes et dates de la mme faon, spares encore une fois du fichier image original. Mais le problme est que votre collection de fichiers s'agrandit de plusieurs fichiers chaque nouvelle photo ajoute au site. Maintenant, considrons le mme site Web conu en utilisant les proprits des fichiers fournies par Subversion. Imaginez un simple fichier image, image123.jpg, et un ensemble de proprits relatives ce fichier nommes lgende, date et mme miniature. prsent, le rpertoire de votre copie de travail se gre beaucoup plus facilement ; en fait, vu du navigateur, il semble ne contenir que des images. Mais vos scripts d'automatisation vont plus loin : ils savent qu'ils peuvent utiliser les commandes svn (ou mieux, ils peuvent utiliser les connecteurs spcifiques au langage utilis, voir la section intitule Utiliser les API ) pour extraire les informations dont votre site a besoin sans avoir lire un fichier d'index ou jouer avec des chemins de fichiers. Bien que Subversion n'impose que peu de restrictions sur les noms et les valeurs des proprits, il n'a pas t conu pour grer de faon optimale des valeurs de proprits de grande taille ou un grand nombre de proprits sur un fichier ou un rpertoire donn. Subversion garde souvent en mmoire en mme temps tous les noms et valeurs de proprits associs un lment, ce qui peut engendrer des problmes de performance lors de l'utilisation de trs gros ensembles de proprits. On utilise galement frquemment des proprits de rvisions personnalises. Une utilisation classique est d'avoir une proprit qui contient un identifiant en provenance d'un autre outil de gestion et de l'associer une rvision. Par exemple, l'outil de gestion est utilis pour suivre les bogues et la rvision corrige le bogue associ l'identifiant. Il s'agit parfois aussi d'utiliser des noms plus conviviaux pour les rvisions : il peut tre difficile de se remmorer que la rvision 1935 correspond une rvision qui a subi la totalit des tests, alors qu'une proprit resultat-des-tests avec la valeur tout ok est autrement plus utile. Retrouver ses petits (ou savoir ne pas utiliser les proprits) Bien que trs utiles, les proprits Subversion, ou plus exactement les interfaces disponibles pour y accder, ont une lacune majeure : alors qu'il est trs simple de dfinir une proprit personnalise, la retrouver plus tard est une toute autre affaire. Trouver une proprit de rvision personnalise implique gnralement d'effectuer un parcours linaire de toutes les rvisions du dpt, en demandant chacune : Avez-vous la proprit que je cherche ? . Trouver une proprit personnalise suivie en versions est galement difficile et implique souvent un appel rcursif svn propget sur toute une copie de travail. Dans votre situation, c'est peut-tre moins pire que le parcours linaire de toutes les rvisions. Mais cela 43

Sujets avancs

laisse certainement beaucoup dsirer en termes de performance et de probabilit de russite, surtout si, pour votre recherche, il faut une copie de travail de la racine de votre dpt. C'est pourquoi vous pouvez choisir, en particulier pour ce qui concerne les proprits de rvisions, de simplement ajouter les mta-donnes au message de propagation. Par exemple, utilisez une politique de formatage (idalement applique automatiquement par un script) conue pour tre rapidement analyse partir de la sortie de svn log. Ainsi, il est assez frquent de voir dans Subversion des messages de propagation qui ressemblent : Problme(s): IZ2376, IZ1919 Corrig par: sally Corrige un mchant plantage dans la fonction machin bidule Mais hlas, cela ne rsout pas tout. Subversion ne fournit pas encore de mcanisme pour grer des modles de messages associs aux propagations, ce qui aiderait pourtant beaucoup les utilisateurs respecter le format des mta-donnes qu'ils placent dans les messages de rvision.

Manipulation des proprits


La commande svn offre diffrentes possibilits pour ajouter ou modifier des proprits sur les fichiers et les rpertoires. Pour les proprits avec des valeurs courtes, lisibles par un humain, la solution la plus simple est srement de spcifier le nom de la proprit et sa valeur en ligne de commande avec la sous-commande svn propset : $ svn propset copyright '(c) 2006 Red-Bean Software' calc/bouton.c Proprit 'copyright' dfinie sur 'calc/bouton.c' $ Mais nous avons vant la souplesse de Subversion pour spcifier les valeurs des proprits. Ainsi, si vous envisagez d'avoir des valeurs de plusieurs lignes de texte, ou mme une valeur binaire, la passer en ligne de commande ne vous convient pas. La sous-commande svn propset accepte donc l'option --file (-F) pour spcifier le nom d'un fichier qui contient la nouvelle valeur de la proprit. $ svn propset licence -F /chemin/vers/LICENCE calc/bouton.c Proprit 'licence' dfinie sur 'calc/bouton.c' $ Il y a quelques restrictions sur les noms de proprits. Un nom de proprit doit commencer par une lettre, le caractre deux points (:), ou le caractre soulign (_) ; ensuite, vous pouvez utiliser des chiffres, des tirets (-) et des points (.) 1. En plus de la commande propset, svn dispose de la commande propedit. Cette commande utilise l'diteur de texte prconfigur (reportez-vous la section intitule Fichier config ) pour ajouter ou modifier des proprits. Quand vous excutez la commande, svn lance votre diteur de texte avec un fichier temporaire qui contient la valeur actuelle de la proprit (ou un contenu vierge si vous ajoutez une nouvelle proprit). Vous pouvez alors modifier la valeur dans l'diteur de texte pour y placer votre nouvelle valeur, sauvegarder le fichier temporaire et quitter l'diteur. Si Subversion dtecte que la valeur a effectivement chang, il la prend en compte. Si vous quittez l'diteur sans faire de changement, la proprit n'est pas modifie : $ svn propedit copyright calc/bouton.c ### sortez de l'diteur sans faire de modification Pas de modification de la proprit 'copyright' sur 'calc/bouton.c' $ Vous pouvez noter que, l'instar des autres commandes svn, celles relatives aux proprits fonctionnent aussi sur des chemins multiples. Vous pouvez ainsi modifier les proprits d'un ensemble de fichiers en une seule commande. Par exemple, nous
1

Pour ceux qui connaissent le XML, c'est peu prs le sous-ensemble ASCII pour la syntaxe du champ "Name" en XML.

44

Sujets avancs

aurions pu taper : $ svn propset copyright '(c) 2006 Proprit 'copyright' dfinie sur Proprit 'copyright' dfinie sur Proprit 'copyright' dfinie sur $ Red-Bean Software' calc/* 'calc/Makefile' 'calc/bouton.c' 'calc/entier.c'

Toutes ces manipulations de proprits ne seraient pas vraiment utiles si vous ne pouviez pas rcuprer facilement la valeur d'une proprit. Subversion propose donc deux sous-commandes pour afficher les noms et les valeurs des proprits associes aux fichiers et rpertoires. La commande svn proplist fournit la liste des noms de proprits qui existent dans un chemin. Une fois que vous connaissez les noms des proprits d'un lment, vous pouvez obtenir les valeurs correspondantes avec la commande svn propget. Cette commande affiche sur la sortie standard la valeur de la proprit dont le nom et le chemin (ou l'ensemble des chemins) ont t passs en paramtres. $ svn proplist calc/bouton.c Proprits sur 'calc/bouton.c': copyright licence $ svn propget copyright calc/bouton.c (c) 2006 Red-Bean Software $ Il y a mme une variante de la commande proplist qui liste la fois le nom et la valeur de toutes les proprits. Ajoutez simplement l'option --verbose (-v) la commande : $ svn proplist -v calc/bouton.c Proprits sur 'calc/bouton.c': copyright : (c) 2006 Red-Bean Software license : ================================================================ Copyright (c) 2006 Red-Bean Software. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the recipe for Fitz's famous red-beans-and-rice. La dernire sous-commande relative aux proprits est propdel. Puisque Subversion vous autorise stocker des proprits avec une valeur vide, vous ne pouvez pas supprimer une proprit en utilisant svn propedit ou svn propset. Par exemple, la commande suivante ne fournit pas le rsultat escompt : $ svn propset licence calc/bouton.c Proprit 'licence' dfinie sur 'calc/bouton.c' $ svn proplist -v calc/bouton.c Proprits sur 'calc/bouton.c': copyright : (c) 2006 Red-Bean Software licence : $ Vous devez utiliser la sous-commande propdel pour supprimer compltement une proprit. La syntaxe est similaire aux autres commandes sur les proprits : $ svn propdel license calc/bouton.c Proprit 'licence' supprime de 'calc/bouton.c'. 45

Sujets avancs

$ svn proplist -v calc/bouton.c Proprits sur 'calc/bouton.c': copyright : (c) 2006 Red-Bean Software $ Vous souvenez-vous des proprits de rvision non suivies en versions ? Vous pouvez les modifier elles-aussi en utilisant les mmes sous-commandes svn que nous venons de dcrire. Il suffit juste d'ajouter l'option --revprop la ligne de commande et de spcifier la rvision laquelle s'applique la modification. Puisque les numros de rvisions s'appliquent l'ensemble de l'arborescence, vous n'avez pas besoin d'indiquer un chemin pour ces commandes, du moment que vous tes dans une copie de travail du dpt contenant la rvision dont vous voulez modifier la proprit. Autrement, vous pouvez simplement fournir n'importe quelle URL du dpt en question (y compris l'URL racine). Par exemple, imaginons que vous vouliez remplacer le message associ la propagation d'une rvision prcdente 2. Si le rpertoire actuel fait partie de votre copie de travail du dpt, vous pouvez simplement lancer la commande svn propset sans spcifier de chemin : $ svn propset svn:log '* bouton.c: Corrige un avertissement du compilateur.' -r11 --revprop Nouvelle valeur dfinie pour la proprit 'svn:log' la rvision du dpt '11' $ Et mme si vous n'avez pas extrait de copie de travail du dpt, vous pouvez toujours modifier la proprit en indiquant l'URL racine du dpt : $ svn propset svn:log '* bouton.c: Corrige un avertissement du compilateur.' -r11 --revprop \ http://svn.exemple.com/depot/projet Nouvelle valeur dfinie pour la proprit 'svn:log' la rvision du dpt '11' $ Notez que le droit de modifier cette proprit non suivie en versions doit tre explicitement ajout par l'administrateur du dpt (voir la section intitule Correction des messages de propagation ). En effet, la proprit n'tant pas suivie en versions, vous risquez une perte d'informations si vous la modifiez tort et travers. L'administrateur du dpt peut mettre en place des protections contre ce type d'incident et, par dfaut, la modification de proprits non suivies en versions est dsactive. Dans la mesure du possible, il est recommand d'utiliser svn propedit au lieu de svn propset. Bien que le rsultat soit identique, la premire permet de visualiser la valeur actuelle de la proprit que l'on veut modifier, ce qui aide vrifier que l'on fait bien ce que l'on pense faire. C'est particulirement vrai dans le cas des proprits non suivies en versions. Il est aussi beaucoup plus facile de modifier un texte de plusieurs lignes dans un diteur de texte qu'en ligne de commande.

Les proprits et le cycle de travail Subversion


Maintenant que vous tes familier avec toutes les sous-commandes svn relatives aux proprits, voyons comment la modification des proprits change le cycle habituel d'utilisation de Subversion. Comme mentionn prcdemment, les proprits des fichiers et rpertoires sont suivies en versions, l'instar du contenu des fichiers. En consquence, Subversion offre les mmes possibilits pour fusionner (proprement ou quand apparaissent des conflits) vos modifications avec celles des autres collaborateurs. De mme que pour le contenu des fichiers, les modifications de proprits sont locales. Elles ne deviennent permanentes que quand vous les propagez dans le dpt via svn commit. Vos modifications sur les proprits peuvent aussi tre annules facilement : la commande svn revert restaure vos fichiers et rpertoires dans leur tat d'avant les modifications, y compris pour les proprits. Vous pouvez galement obtenir des informations intressantes sur l'tat des proprits de vos fichiers et rpertoires en utilisant les commandes svn status et svn diff. $ svn status calc/bouton.c
2

Corriger les fautes d'orthographe, les erreurs de grammaire et les informations simplement errones au sein des messages de propagation est peut-tre l'usage le plus courant de l'option --revprop.

46

Sujets avancs

M calc/bouton.c $ svn diff calc/bouton.c Modification de proprits sur calc/bouton.c ___________________________________________________________________ Ajout: copyright + (c) 2006 Red-Bean Software $

Remarquez que la sous-commande status place le M dans la deuxime colonne plutt que dans la premire. C'est parce que nous avons modifi les proprits de calc/bouton.c, mais pas son contenu. Si nous avions chang les deux, nous aurions vu le M dans la premire colonne galement (reportez-vous la section intitule Avoir une vue d'ensemble des changements effectus ). Conflits sur les proprits De la mme manire que pour le contenu des fichiers, les modifications locales effectues sur les proprits peuvent entrer en conflit avec les changements effectus par d'autres collaborateurs. Si vous faites une mise jour de votre copie de travail et que vous recevez un changement incompatible avec vos propres modifications d'une proprit d'un objet suivi en versions, Subversion vous indique que l'objet est dans un tat de conflit. % svn update calc M calc/Makefile.in C calc/bouton.c la rvision 143. $ Subversion cre galement, dans le mme rpertoire que l'objet en conflit, un fichier avec l'extension .prej qui contient les dtails du conflit. Vous devez examiner le contenu de ce fichier pour dcider comment rsoudre le conflit. Tant que le conflit n'est pas rsolu, la sortie de svn status affiche un C dans la deuxime colonne pour cet objet et vos tentatives de propagation chouent. $ svn status calc C calc/bouton.c ? calc/bouton.c.prej $ cat calc/bouton.c.prej prop 'nombre_lignes': user set to '1256', but update set to '1301'. $ Pour rsoudre les conflits sur les proprits, assurez-vous simplement que les proprits en question contiennent bien les valeurs qu'elle doivent contenir, puis utilisez la commande svn resolved pour indiquer Subversion que vous avez rsolu le problme manuellement.

Vous avez peut-tre remarqu que Subversion affiche les diffrences au niveau des proprits d'une manire non standard. Certes, vous pouvez toujours rediriger la sortie de svn diff pour crer un fichier correctif utilisable : le programme patch ignore ce qui concerne les proprits (comme il ignore tout ce qu'il ne comprend pas). Malheureusement, cela signifie aussi que pour appliquer intgralement un correctif gnr par svn diff, les modifications concernant les proprits doivent tre faites la main.

Configuration automatique des proprits


Les proprits constituent une fonctionnalit trs puissante de Subversion et sont un lment central de nombreuses fonctionnalits de Subversion prsentes ailleurs dans ce chapitre ainsi que dans les autres chapitres : comparaisons et fusions textuelles, substitution de mots-cls, transformation des retours la ligne, etc. Mais pour profiter pleinement des proprits, il faut les placer sur les rpertoires et fichiers adquats. Malheureusement, cette tape peut passer la trappe dans le train-train quotidien, d'autant plus qu'oublier de configurer une proprit n'engendre gnralement pas une erreur qui saute aux yeux (du moins comparativement oublier d'ajouter un fichier dans la gestion de versions). Pour vous aider placer vos proprits au 47

Sujets avancs

bon endroit, Subversion propose deux fonctionnalits simples mais nanmoins utiles. Au moment d'introduire un fichier en suivi de versions l'aide de la commande svn add ou svn import, Subversion essaie de vous aider en configurant automatiquement certaines proprits communes des fichiers. D'abord, sur les systmes d'exploitation dont le systme de fichiers utilise un bit excutable , Subversion ajoute automatiquement la proprit svn:executable aux nouveaux fichiers, ajouts ou imports, qui ont ce bit activ (voir la section intitule Fichiers excutables ou non pour plus de dtails sur cette proprit). Ensuite, Subversion essaie de dterminer le type MIME du fichier. Si vous avez configur le paramtre mimetypes-files, Subversion essaie de trouver un type MIME correspondant l'extension du nom de fichier. Si un tel type MIME existe, il dfinit automatiquement la proprit svn:mime-type avec la valeur du type trouv. S'il ne trouve pas de type MIME correspondant ou s'il n'existe pas de fichier dfinissant les correspondances, Subversion applique une heuristique trs basique pour dterminer si le contenu du fichier est lisible par un humain. Si le rsultat est ngatif, Subversion ajoute automatiquement la proprit svn:mime-type ce fichier avec la valeur application/octet-stream (type MIME gnrique indiquant une suite d'octets ). Bien sr, si Subversion se trompe ou si vous voulez indiquer un type plus prcis (par exemple image/png ou application/x-shockwave-flash), vous pouvez toujours supprimer ou modifier cette proprit (pour d'avantage d'informations sur la gestion des types MIME par Subversion, reportez vous la section intitule Type de contenu des fichiers plus loin dans ce chapitre). Subversion fournit galement, via sa zone de configuration (voir la section intitule Zone de configuration des excutables ), une fonction de renseignement automatique des proprits, plus flexible, qui vous permet de crer des associations entre, d'une part, des motifs de noms de fichiers et, d'autre part, des noms de proprits / valeurs de proprits. L encore, ces associations modifient le comportement des commandes add et import, pouvant non seulement passer outre la dcision prise par dfaut d'attribution d'une proprit de type MIME mais pouvant aussi dfinir d'autres proprits, qu'elles soient utilises par Subversion ou personnalises. Par exemple, vous pouvez crer une association qui, chaque ajout d'un fichier JPEG (c'est--dire dont le nom est du type *.jpg), fixe la proprit svn:mime-type de ce fichier la valeur image/jpeg. Ou alors affecte tout fichier de type *.cpp la proprit svn:eol-style avec la valeur native et la proprit svn:keywords avec la valeur Id. L'affectation automatique de proprits est srement l'outil de manipulation des proprits le plus commode de tout Subversion. Reportez-vous la section intitule Fichier config pour plus d'informations sur la configuration de cette fonction.

Portabilit des fichiers


Heureusement pour les utilisateurs de Subversion qui travaillent sur diffrents ordinateurs et systmes d'exploitation, le comportement du programme en ligne de commande est pratiquement identique sur tous les systmes. Si vous vous dbrouillez avec svn sur un systme, vous devriez vous en sortir sur n'importe quel systme. Cependant, ce n'est pas toujours le cas pour d'autres types de logiciels ou pour les fichiers que vous grez dans Subversion. Par exemple, sur un systme Windows, la dfinition d'un fichier texte est similaire la dfinition de Linux, mais avec une diffrence notable pour ce qui concerne les retours la ligne. Il y a aussi d'autres diffrences. Les plateformes Unix (et Subversion) supportent la notion de lien symbolique ; Windows non. Les plateformes Unix utilisent les permissions du fichier pour dterminer si un fichier est excutable ; Windows utilise l'extension du fichier. Subversion n'a pas la possibilit d'unifier toutes ces dfinitions et ces implmentations. Tout ce qu'il peut faire, c'est aider au maximum l'utilisateur qui travaille sur plusieurs systmes et plusieurs ordinateurs. Cette section dcrit comment Subversion s'y prend.

Type de contenu des fichiers


Subversion fait partie des nombreuses applications qui reconnaissent et utilisent les types MIME (Multipurpose Internet Mail Extensions). Ainsi, la valeur de la proprit svn:mime-type permet, en plus de stocker le type de contenu d'un fichier, de changer le comportement de Subversion lui-mme. Identification des types de fichiers Beaucoup de programmes sur les systmes d'exploitation modernes font des suppositions sur le type et le format du contenu d'un fichier partir de son nom, notamment son extension. Par exemple, les fichiers qui se terminent par .txt sont gnralement considrs comme lisibles par un tre humain, aptes tre compris pratiquement tels quels, sans ncessiter un processus de dcodage compliqu. Les fichiers dont le nom se termine par .png, en revanche, sont considrs comme des fichiers du type "Portable Network Graphics", illisibles pour un tre humain, et utilisables 48

Sujets avancs

uniquement au travers d'un logiciel capable de comprendre le format PNG et de l'afficher en tant qu'image matricielle. Malheureusement, certaines de ces extensions ont chang de sens au fil du temps. Au dbut des ordinateurs personnels, un fichier LISEZMOI.DOC aurait certainement t un simple fichier texte, comme aujourd'hui les fichiers .txt. Mais, rendu au milieu des annes 1990, vous pouviez parier que ce fichier ne serait plus un simple fichier texte, mais un document "Microsoft Word", format propritaire et illisible pour un tre humain. Ce changement n'a pas eu lieu du jour au lendemain et il y a eu une priode de confusion pour les utilisateurs qui, lorsqu'ils tombaient sur un fichier .doc, ne savaient pas trop de quel type tait ce fichier 3. L'essor des rseaux informatiques n'a fait qu'ajouter la confusion sur la relation entre le nom d'un fichier et son contenu. Avec l'information circulant travers les rseaux, souvent gnre dynamiquement par des programmes sur les serveurs, il n'y avait plus de fichier en tant que tel et donc plus de nom de fichier. Les serveurs Web, par exemple, avaient besoin d'un autre moyen pour indiquer au navigateur quel type de contenu il tlcharge afin qu'il puisse appliquer un traitement cohrent cette information : soit afficher les donnes l'aide d'un programme qui sait traiter ce type de contenu, soit demander l'utilisateur o stocker les donnes tlcharges. Finalement, un standard est apparu pour, entre autres, dcrire le contenu d'un flux de donnes. En 1996 tait publie la RFC2045, la premire des cinq RFC dcrire le format MIME. Elle dcrit le concept de types de mdia et de sous-types et recommande une syntaxe pour reprsenter ces types. Aujourd'hui, les types de mdia MIME (ou simplement types MIME) sont utiliss de manire pratiquement universelle par les clients de messagerie, les serveurs Web et autres logiciels, pour dterminer de manire sre le type de contenu d'un fichier.

Par exemple, un avantage fourni par cette reconnaissance de type par Subversion est la possibilit de fusion contextuelle, ligne par ligne, des changements reus lors d'une mise jour. En revanche, pour les fichiers contenant autre chose que du texte, il n'y a souvent pas de concept de ligne . En consquence, pour les fichiers suivis en versions dont la proprit svn:mime-type contient une valeur de type MIME non textuel (gnralement un intitul qui ne commence pas par text/, bien qu'il y ait des exceptions), Subversion ne tente pas de fusion contextuelle pendant la mise jour. la place, chaque fois que vous avez modifi localement un fichier binaire qui a t mis jour sur le dpt, Subversion ne touche pas votre fichier mais cre deux nouveaux fichiers. Un fichier avec l'extension .oldrev qui contient la version du fichier la rvision BASE. Un autre fichier avec l'extension .newrev qui contient la version jour du fichier. Ce comportement est dict par la volont d'viter que l'utilisateur ne tente d'effectuer une fusion qui chouerait parce que les fichiers ne peuvent tout simplement pas tre fusionns. La proprit svn:mime-type, si elle n'est pas correctement dfinie une valeur qui indique un contenu non textuel, peut causer des comportements inattendus. Par exemple, comme la fin de ligne n'a pas de sens dans un fichier binaire, Subversion vous empche de dfinir la proprit svn:eol-style sur ces fichiers. Cela saute aux yeux quand vous travaillez sur un seul fichier et que svn propset gnre une erreur. C'est beaucoup moins vident si vous effectuez une opration rcursive, o Subversion omet silencieusement les fichiers qu'il considre inappropris pour une proprit donne. Depuis Subversion 1.5, les utilisateurs peuvent configurer un nouveau paramtre mime-types-file dans la zone de configuration qui identifie un fichier de correspondance des types MIME. Subversion consulte ce fichier pour dterminer le type MIME de tout nouveau fichier ajout ou import. Par ailleurs, si la proprit svn:mime-type est dfinie, alors le greffon Apache pour Subversion utilise cette valeur pour renseigner le champ Content-type: de l'en-tte HTTP en rponse une requte GET. Cela fournit au navigateur Web une indication trs importante pour pouvoir afficher correctement le fichier, quand vous l'utilisez pour parcourir le contenu du dpt Subversion.

Fichiers excutables ou non


Sur beaucoup de systmes d'exploitation, la capacit de rendre un fichier excutable dpend d'un bit dit excutable . Habituellement, ce bit est dsactiv par dfaut et doit tre explicitement activ par l'utilisateur pour chaque fichier concern. Ce serait une perte de temps norme d'avoir se rappeler exactement quel fichier, parmi ceux que l'on vient d'extraire du dpt, doit avoir le bit excutable positionn et ensuite de devoir le faire manuellement. C'est pourquoi Subversion fournit la proprit svn:executable pour spcifier que le bit excutable doit tre activ pour le fichier concern. Subversion s'occupe lui-mme de cette tche quand il rapatrie de tels fichiers dans la copie de travail locale.
3

Ca vous semble dur ? Et bien, la mme priode, WordPerfect utilisait aussi .DOC comme extension prfre de son format de fichier propritaire !

49

Sujets avancs

Cette proprit n'a aucun effet sur les systmes de fichiers qui ne possdent pas le concept du bit excutable, tels que FAT32 et NTFS 4. Par ailleurs, bien qu'elle n'ait pas de valeurs dfinies, Subversion lui attribue la valeur * lorsqu'il active cette proprit. Enfin, cette proprit n'est valide que sur des fichiers, pas sur des rpertoires.

Caractres de fin de ligne


Pour tout fichier suivi en versions, Subversion considre que le contenu est lisible par un humain sauf si la proprit svn:mime-type indique le contraire. En rgle gnrale, Subversion utilise cette information pour dterminer s'il est possible d'effectuer une comparaison contextuelle pour ce fichier. Sinon, pour Subversion, les octets sont des octets. Cela veut dire que par dfaut, Subversion ne s'intresse pas au type de caractre utilis pour marquer les fins de lignes ( EOL en anglais, pour End Of Line ). Malheureusement, des conventions diffrentes sont utilises suivant les systmes d'exploitation pour indiquer une fin de ligne de texte dans un fichier. Par exemple, les logiciels sous Windows utilisent gnralement une paire de caractres de contrle ASCII : un retour chariot (CR, carriage return ) suivi par un saut de ligne (LF, line feed ). Les logiciels Unix, cependant, utilisent uniquement le caractre LF pour indiquer les fins de lignes. Tous les programmes ne savent pas grer les fichiers utilisant un marqueur de fin de ligne exogne au systme d'exploitation sur lequel ils tournent. Ainsi, il n'est pas rare de voir les programmes Unix traiter le marqueur CR des fichiers Windows comme un caractre normal (en affichant l'cran un ^M) et les programmes Windows combiner en une seule ligne immense un fichier Unix parce qu'ils n'y ont pas trouv la combinaison retour chariot-passage la ligne (CR-LF). Cette incapacit de traiter correctement les marqueurs de fin de ligne d'autres plates-formes peut tre assez frustrante pour ceux qui partagent des fichiers entre diffrents systmes d'exploitation. Prenons l'exemple d'un fichier de code source qui est dit par des dveloppeurs la fois sous Windows et sous Unix. Si tous les dveloppeurs utilisent des outils qui se plient la convention utilise par le fichier, pas de problme. Mais, en pratique, de nombreux outils largement utiliss soit ne parviennent pas lire correctement un fichier utilisant une convention diffrente pour les fins de ligne, soit ils convertissent les fins de lignes au format local lors de la sauvegarde. Dans le premier cas, le dveloppeur doit utiliser des outils externes (tels que dos2unix et son compagnon unix2dos) pour prparer le fichier avant l'dition. Dans le deuxime cas, pas besoin de prparation. Mais dans les deux cas, le fichier rsultant diffre de l'original littralement pour toutes les lignes ! Avant de propager ses changements, l'utilisateur a deux choix. Soit il utilise un utilitaire de conversion pour revenir la mme convention qu'avant l'dition. Soit il propage le fichier avec la nouvelle convention de fin de ligne. Au final, les deux hypothses conduisent une perte de temps et des modifications inutiles sur les fichiers propags. La perte de temps est dj pnible. Mais si en plus la propagation change chaque ligne du fichier, trouver quelle ligne a effectivement chang devient non trivial. quel endroit ce bogue a-t-il rellement t corrig ? Dans quelle ligne y avait-il cette erreur de syntaxe ? La solution ce problme est la proprit svn:eol-style (eol pour "End Of Line"). Quand cette proprit possde une valeur valide, Subversion l'utilise pour dterminer quel traitement il doit appliquer pour que le fichier ne change pas de convention chaque propagation provenant d'un systme d'exploitation diffrent. Les valeurs valides sont : native Ceci force le fichier adopter la convention utilise par le systme d'exploitation sur lequel s'excute Subversion. En d'autres termes, si un utilisateur d'une machine Windows rcupre une copie de travail d'un fichier dont la proprit svn:eol-style vaut native, ce fichier contiendra le marqueur CRLF pour indiquer les fins de ligne. Un utilisateur Unix qui rcupre une copie de travail qui contient le mme fichier verra simplement LF pour indiquer les fins de ligne sur sa copie. Notez que Subversion stocke en fait le fichier dans le dpt en utilisant le marqueur standard LF indpendamment du systme d'exploitation. Cela reste toutefois tout fait transparent pour l'utilisateur. CRLF Le fichier contiendra le marqueur CRLF pour indiquer les fins de ligne, quel que soit le systme d'exploitation. LF Le fichier contiendra le marqueur LF pour indiquer les fins de ligne, quel que soit le systme d'exploitation. CR
4

Les systmes de fichiers Windows utilisent les extensions des fichiers (telles que .EXE, .BAT et .COM) pour indiquer que les fichiers sont excutables.

50

Sujets avancs

Le fichier contiendra le marqueur CR pour indiquer les fins de ligne, quel que soit le systme d'exploitation. Ce marqueur de fin de ligne n'est pas trs courant. Il tait utilis sur les vieux Macintosh (machines sur lesquelles Subversion ne tourne mme pas).

Occultation des lments non suivis en versions


Dans n'importe quelle copie de travail, il y a de grandes chances que les fichiers et rpertoires suivis en versions ctoient d'autres fichiers et rpertoires non suivis en versions ou qui n'ont pas lieu de l'tre. Les diteurs de texte remplissent les rpertoires avec des fichiers de sauvegarde. Les compilateurs crent des fichiers intermdiaires (ou mme des fichiers finaux) que vous ne voudrez pas suivre en versions. Et les utilisateurs eux-mmes dposent des fichiers et des rpertoires o bon leur semble, souvent dans des copies de travail locales. Il est ridicule de penser que les copies de travail Subversion chappent ce type de mli-mlo. En fait, Subversion prend en compte (c'est une fonctionnalit) ds le dbut que les copies de travail sont des rpertoires comme les autres, comme ceux qui ne sont pas suivis en versions. Mais ces fichiers et rpertoires qui-n-ont-pas-vocation--tre-suivis-en-versions peuvent perturber les utilisateurs de Subversion. Par exemple, comme les commandes svn add et svn import sont rcursives par dfaut et ne savent pas quels fichiers de l'arborescence vous voulez suivre ou non en versions, il est relativement facile d'ajouter au suivi de versions des lments que vous ne vouliez pas suivre. Et comme la commande svn status liste, par dfaut, tous les lments intressants de la copie de travail, y compris les fichiers et rpertoires non suivis en versions, son affichage devient rapidement confus avec de tels imbroglios. C'est pourquoi Subversion fournit deux mthodes pour lui indiquer quels fichiers vous souhaitez ignorer. La premire implique l'utilisation de la zone de configuration (voir la section intitule Zone de configuration des excutables ) et, par consquent, s'applique toutes les oprations Subversion qui utilisent cette zone de configuration, gnralement toutes celles de l'ordinateur ou d'un utilisateur particulier de l'ordinateur. L'autre mthode utilise les proprits Subversion des rpertoires et est plus lie l'arborescence suivie en versions elle-mme. Par consquent, elle affecte tous ceux qui possdent une copie de travail de cette arborescence. Les deux mcanismes utilisent des motifs de noms de fichiers (des chaines de caractres simples ou des jokers pour trouver des correspondances avec les noms de fichiers). La zone de configuration de Subversion propose une option, global-ignores, dont la valeur est un ensemble de motifs de noms de fichiers (appels aussi globs) spars par des espaces. Le client Subversion compare ces motifs aux noms des fichiers que l'on tente d'ajouter au suivi de versions, ainsi qu'aux noms des fichiers non suivis en versions dtects par la commande svn status. Si un nom de fichier correspond au motif, Subversion ignore totalement ce fichier. C'est particulirement utile pour les fichiers que vous ne voulez jamais suivre en versions, comme les fichiers de sauvegarde crs par les diteurs de texte (par exemple, les fichiers *~ et .*~ crs par Emacs). Les motifs de noms de fichiers dans Subversion Les motifs de noms de fichiers (galement appels globs ou motifs de filtrages du shell) sont des chanes de caractres destines tre compares des noms de fichiers, en gnral dans le but de slectionner rapidement un sous-ensemble de fichiers similaires au sein d'un ensemble plus large, sans avoir nommer explicitement chaque fichier. Les motifs contiennent deux types de caractres : les caractres standard, qui sont compars explicitement aux noms de fichiers, et les caractres spciaux (aussi nomms quantificateurs), qui sont interprts diffremment. Il y a diffrents types de syntaxe de motifs, mais Subversion utilise celle qui est la plus rpandue sur les systmes Unix, implmente dans la fonction fnmatch. Elle reconnat les caractres spciaux suivants, dcrits ici titre d'information : ? Correspond n'importe quel caractre unique. * Correspond n'importe quelle chane de caractres, y compris la chane vide. [ Marque le dbut de la dfinition d'une classe de caractres, se terminant par ], utilise pour dcrire un sous-ensemble de caractres. Vous pouvez observer ce mme filtrage de motifs l'invite de commandes d'un shell Unix. Voici des exemples de motifs utiliss pour diffrentes choses : 51

Sujets avancs

$ ls ### les sources du livre appa-quickstart.xml ch06-server-configuration.xml appb-svn-for-cvs-users.xml ch07-customizing-svn.xml appc-webdav.xml ch08-embedding-svn.xml book.xml ch09-reference.xml ch00-preface.xml ch10-world-peace-thru-svn.xml ch01-fundamental-concepts.xml copyright.xml ch02-basic-usage.xml foreword.xml ch03-advanced-topics.xml images/ ch04-branching-and-merging.xml index.xml ch05-repository-admin.xml styles.css $ ls ch* ### les chapitres du livre ch00-preface.xml ch06-server-configuration.xml ch01-fundamental-concepts.xml ch07-customizing-svn.xml ch02-basic-usage.xml ch08-embedding-svn.xml ch03-advanced-topics.xml ch09-reference.xml ch04-branching-and-merging.xml ch10-world-peace-thru-svn.xml ch05-repository-admin.xml $ ls ch?0-* ### les chapitres du livre dont le numro se termine par 0 ch00-preface.xml ch10-world-peace-thru-svn.xml $ ls ch0[3578]-* ### les chapitres du livre dont Mike est responsable ch03-advanced-topics.xml ch07-customizing-svn.xml ch05-repository-admin.xml ch08-embedding-svn.xml $ Le filtrage par motif de fichiers est un peu plus complexe que ce que nous avons dcrit ici, mais ce niveau d'utilisation semble suffire la majorit des utilisateurs de Subversion.

Pour un rpertoire suivi en versions, la proprit svn:ignore est suppose contenir une liste de motifs de noms de fichiers (un motif par ligne) que Subversion utilise pour dterminer quels objets ignorer dans le rpertoire concern. Ces motifs ne remplacent pas les motifs inscrits dans la directive global-ignores de la zone de configuration, mais s'ajoutent cette liste. Veuillez galement noter que, contrairement la directive global-ignores, les motifs de la proprit svn:ignore s'appliquent uniquement au rpertoire pour lequel la proprit est dfinie et pas ses sous-rpertoires. La proprit svn:ignore est utile pour indiquer Subversion d'ignorer les fichiers susceptibles d'tre prsents dans la copie de travail de ce rpertoire chez chaque utilisateur comme par exemple les fichiers produits par les compilateurs ou, pour citer un exemple plus appropri ce livre, les fichiers HTML, PDF ou PostScript gnrs par la conversion des fichiers sources DocBook XML vers un format de fichier plus lisible. Le support des motifs de fichiers ignorer dans Subversion s'applique uniquement la procdure d'ajout de fichiers et rpertoires non suivis en versions vers la gestion de versions. Une fois que l'objet est suivi en versions par Subversion, les mcanismes permettant d'ignorer certains fichiers selon des motifs prdfinis ne s'appliquent plus. Autrement dit, ne pensez pas que Subversion ne propagera pas les changements que vous avez faits un fichier suivi en versions simplement parce que son nom correspond un motif ignorer : Subversion prend toujours en compte l'ensemble des objets qu'il gre.

Motifs de fichier ignorer pour les utilisateurs de CVS La syntaxe et le fonctionnement de la proprit svn:ignore de Subversion sont trs similaires ceux du fichier .cvsignore de CVS. Si vous migrez une copie de travail CVS vers Subversion, vous pouvez migrer directement les motifs ignorer en utilisant le fichier .cvsignore comme entre la commande svn propset : $ svn propset svn:ignore -F .cvsignore . Proprit 'svn:ignore' dfinie sur '.' $ Il y a quand mme quelques diffrences entre CVS et Subversion concernant les motifs ignorer. Les deux systmes n'utilisent pas les motifs au mme moment et il y a quelques lgres divergences sur ce sur quoi ils s'appliquent. 52

Sujets avancs

D'ailleurs, Subversion ne reconnat pas le motif ! pour revenir une situation o aucun motif n'est ignor.

La liste globale des motifs ignorer est une affaire de got, devant plus s'intgrer la collection d'outils d'un utilisateur particulier que rpondre aux besoins d'une copie de travail particulire. C'est pourquoi le reste de cette section s'attache dcrire l'utilisation de la proprit svn:ignore. Prenons par exemple le rsultat suivant de la commande svn status : $ svn status calc M calc/bouton.c ? calc/calculatrice ? calc/donnees.c ? calc/debug_log ? calc/debug_log.1 ? calc/debug_log.2.gz ? calc/debug_log.3.gz Dans cet exemple, des modifications ont t faites sur les proprits de bouton.c et il y a aussi des fichiers non suivis en versions : le programme calculatrice (rsultat de votre dernire compilation du code source), un fichier source donnees.c et un ensemble de fichiers de traces pour le dbogage. Vous tes conscient du fait que compiler votre code engendre chaque fois la cration du programme calculatrice 5. Vous savez galement que vous avez toujours des fichiers de traces qui tranent. On peut faire ce constat pour toutes les copies de travail locales de ce projet, pas seulement la vtre. Et vous savez que cela ne vous intresse pas et que cela n'intresse trs probablement aucun autre dveloppeur, de voir ces fichiers apparatre chaque commande svn status. Vous allez donc utiliser svn propedit svn:ignore calc pour ajouter des motifs ignorer pour le rpertoire calc. Par exemple, vous pouvez ajouter ce qui suit comme nouvelle valeur de la proprit svn:ignore : calculatrice debug_log* Aprs avoir ajout cette proprit, vous avez une proprit modifie localement dans votre rpertoire calc. Mais notez les autres diffrences sur le rsultat de la commande svn status : $ svn status M calc M calc/bouton.c ? calc/donnees.c Maintenant, tout le superflu a disparu ! Bien sr, votre programme compil et les fichiers de trace sont toujours prsents dans votre copie locale. Subversion ne vous prsente pas ces fichiers prsents mais non suivis en versions, c'est tout. Et maintenant que ces parasites sont supprims de l'affichage, il ne vous reste plus que les lments intressants, tels que le fichier source donnees.c que vous avez probablement oubli d'ajouter au suivi de versions. Bien videmment, ce compte-rendu plus succinct de l'tat de votre copie de travail locale n'est pas le seul possible. Si vous voulez voir les fichiers ignors dans le compte-rendu, vous pouvez ajouter l'option --no-ignore la commande Subversion : $ svn status --no-ignore M calc M calc/bouton.c I calc/calculatrice ? calc/donnees.c I calc/debug_log I calc/debug_log.1 I calc/debug_log.2.gz
5

N'est-ce pas prcisment la finalit d'un systme de compilation ?

53

Sujets avancs

calc/debug_log.3.gz

Comme mentionn auparavant, la liste des motifs de fichiers ignorer est aussi utilise par svn add et svn import. Ces deux oprations demandent Subversion de grer un ensemble de fichiers et de rpertoires. Plutt que de forcer l'utilisateur choisir dans l'arborescence quels fichiers il souhaite suivre en versions, Subversion utilise les motifs de fichiers ignorer, la fois la liste globale et ceux dfinis par rpertoire, pour dterminer quels fichiers suivre (ou ne pas suivre) en versions dans sa procdure rcursive d'ajout ou d'import. L encore, vous pouvez utiliser l'option --no-ignore pour indiquer Subversion d'ignorer ces listes et de d'agir effectivement sur tous les fichiers et rpertoires prsents. Mme si svn:ignore est dfini, vous risquez de rencontrer des problmes si vous utilisez des caractres spciaux du shell dans une commande. Les caractres spciaux sont remplacs par une liste explicite de cibles avant que Subversion n'agisse sur eux et donc lancer svn SOUS-COMMANDE * revient lancer svn SOUSCOMMANDE fichier1 fichier2 fichier3 . Dans le cas de la commande svn add, ceci a un effet similaire l'option --no-ignore. Par consquent, au lieu d'utiliser un caractre spcial, utilisez plutt svn add --force . pour marquer d'un seul coup les lments non suivis en versions pour ajout. La cible explicite permet de s'assurer que le rpertoire en cours ne sera pas nglig car dj suivi en versions et l'option --force force Subversion parcourir ce rpertoire, ajoutant les fichiers non suivis en versions, tout en respectant la proprit svn:ignore et la variable global-ignores de la zone de configuration. Pensez rajouter l'option --depth files la commande svn add si vous ne voulez pas que la recherche de fichiers ajouter au suivi de versions ne parcoure le rpertoire de faon rcursive.

Substitution de mots-cls
Subversion a la capacit de substituer des mots-cls dans les fichiers suivis en versions par des informations dynamiques et utiles. Les mots-cls fournissent gnralement des indications sur les dernires modifications faites au fichier. Comme ces informations changent chaque fois que le fichier change et, plus spcifiquement, juste aprs que le fichier change, c'est compliqu pour tout processus, except pour le systme de gestion de versions, de garder les donnes jour. Sans outil automatique, adieu la pertinence de ces informations ! Par exemple, prenons un document dont vous voulez afficher la date de dernire modification. Vous pouvez charger chaque contributeur du document de renseigner le champ correspondant juste avant de propager ses changements. Mais un jour ou l'autre, quelqu'un oubliera de le faire. Demandez plutt Subversion de substituer le mot-cl LastChangedDate. Vous contrlez o est insr le mot-cl dans votre document en plaant un signet l'endroit voulu dans le fichier. Ce signet est juste une chane de caractres formate comme ceci : $NomDuMotCle$. Tous les mots-cls sont sensibles la casse des caractres quand ils apparaissent en tant que signets : vous devez placer les majuscules aux bons endroits pour que le mot-cl soit effectivement remplac. Vous devez aussi considrer que la valeur de la proprit svn:keywords est sensible la casse ( case-sensitive en anglais) : certains mots-cls seront reconnus indpendamment de la casse, mais ce comportement est obsolte. Subversion dfinit la liste des mots-cls disponibles pour les substitutions. Cette liste contient les cinq mots-cls suivants (certains d'entre eux ont des alias que vous pouvez aussi utiliser) : Date Ce mot-cl indique la date du dernier changement connu dans le dpt. Il est de la forme $Date: 2006-07-22 21:42:37 -0700 (sam. 22 juil. 2006) $. Il peut galement tre spcifi en tant que LastChangedDate. Contrairement au mot-cl Id, qui utilise l'heure UTC, le mot-cl Date affiche la date et l'heure locales. Revision Ce mot-cl indique la dernire rvision connue pour laquelle le fichier a chang dans le dpt. Il fournit une rponse du type $Revision: 144 $. Il peut aussi tre spcifi en tant que LastChangedRevision ou Rev. Author Ce mot-cl indique le dernier utilisateur qui a chang le fichier dans le dpt et retourne une valeur du type $Author: harry $. Il peut aussi tre spcifi en tant que LastChangedBy. HeadURL Ce mot-cl dcrit l'URL complte de la dernire version du fichier dans le dpt et ressemble $HeadURL: 54

Sujets avancs

http://svn.apache.org/repos/asf/subversion/trunk/README $. Il peut tre abrg en URL. Id Ce mot-cl est une combinaison abrge des autres mots-cls. Sa substitution donne quelque chose comme $Id: calc.c 148 2006-07-28 21:30:43Z sally $, que l'on interprte comme suit : Le fichier calc.c a t modifi en dernier par l'utilisateur sally lors de la rvision 148 le 28 juillet 2006 au soir. La date et l'heure affiches sont en heure UTC, contrairement au mot-cl Date qui utilise l'heure locale. Une bonne partie des dfinitions qui prcdent utilisent la locution dernire connue ou quelque chose d'quivalent. Rappelez-vous que la substitution des mots-cls est une opration effectue ct client et que votre client ne connat pas les changements qui ont eu lieu dans le dpt depuis votre dernire mise jour. Si vous ne mettez jamais jour de votre copie de travail locale, vos mots-cls restent figs la mme valeur mme si des changements ont lieu rgulirement dans le dpt. Ajouter des signets dans votre fichier ne fait rien de spcial. Subversion n'essaie jamais d'effectuer la substitution dans votre fichier tant que vous ne le lui demandez pas explicitement. Aprs tout, vous crivez peut-tre un document 6 sur la manire d'utiliser les mots-cls et vous ne voulez pas que Subversion substitue vos beaux exemples de signets non substitus leur valeur relle ! Pour indiquer Subversion de substituer ou pas les mots-cls d'un fichier particulier, nous utilisons une fois de plus les commandes sur les proprits. La proprit svn:keywords, quand elle est active pour un fichier, contrle quels mots-cls doivent tre substitus dans ce fichier. Elle doit contenir une liste de mots-cls ou d'alias cits prcdemment, spars par des espaces. Par exemple, pour un fichier nomm meteo.txt qui ressemble ceci : Voici les dernires prvisions de nos spcialistes : $LastChangedDate$ $Rev$ Les cumulus sont de plus en plus nombreux au fur et mesure que l't approche. Sans la proprit svn:keywords active sur ce fichier, Subversion ne fait rien de spcial. prsent, si nous activons les substitutions pour le mot-cl LastChangedDate : $ svn propset svn:keywords "Date Author" meteo.txt property 'svn:keywords' set on 'meteo.txt' $ Vous venez d'effectuer une modification locale des proprits du fichier meteo.txt. Vous ne verrez aucun changement dans le contenu du fichier ( moins d'avoir fait des modifications avant d'activer la proprit). Notez que le fichier contenait un signet pour le mot-cl Rev et que nous n'avons pas inclus ce mot-cl dans la valeur de la proprit. Subversion ignore simplement les requtes de substitutions de mots-cls qui ne sont pas prsents dans le fichier et ne substitue pas de mot-cl qui ne soit pas prsent dans la valeur de la proprit svn:keywords. Immdiatement aprs avoir propag ces modifications de proprit, Subversion met jour votre copie de travail avec le nouveau texte substitu. Au lieu de voir votre signet $LastChangedDate$, vous voyez le rsultat de la substitution. Ce rsultat contient aussi le nom du mot-cl et est toujours entour par des caractres dollar ($). Comme prvu, le mot-cl Rev n'a pas t substitu parce que nous n'avons pas demand qu'il le soit. Notez galement que la substitution s'est bien passe alors que nous avons indiqu Date Author comme valeur de proprit svn:keywords et que le signet utilisait l'alias $LastChangedDate$ : Voici les dernires prvisions de nos spcialistes : $LastChangedDate: 2006-07-22 21:42:37 -0700 (sam. 22 juil. 2006) $ $Rev$ Les cumulus sont de plus en plus nombreux au fur et mesure que l't approche. Si quelqu'un d'autre propage une modification de meteo.txt, votre copie de ce fichier continue afficher la mme valeur
6

ou mme peut-tre un paragraphe de ce livre

55

Sujets avancs

substitue de mot-cl, jusqu' ce que vous mettiez jour votre copie de travail. Aux mots-cls de meteo.txt seront alors nouveau substitues les informations qui se rapportent la plus rcente propagation du fichier. O est pass $GlobalRev$ ? Les nouveaux utilisateurs sont parfois surpris par le fonctionnement du mot-cl $Rev$. Puisque le dpt a un numro de rvision la fois unique, global et croissant, beaucoup de gens pensent que c'est par ce numro qu'est remplac le motcl $Rev$. Mais $Rev$ indique la dernire rvision dans laquelle le fichier a chang, pas la rvision de la dernire mise jour. Le malentendu est ainsi dissip, mais peut-tre pas la frustration de ne pas avoir automatiquement le numro global de la dernire rvision dans vos fichiers, n'est-ce pas ? Pour l'obtenir, vous avez besoin d'un outil externe. Subversion est livr avec un outil appel svnversion, qui a t conu spcifiquement pour cela. svnversion parcourt votre copie de travail et affiche toutes les rvisions qu'il trouve. Vous pouvez utiliser ce programme, avec d'autres outils de traitement, pour insrer l'information de rvision dsire dans vos fichiers. Pour davantage d'information sur svnversion, voir la section intitule svnversion .

Subversion 1.2 introduisit une nouvelle variante pour la syntaxe des mots-cls. Cette syntaxe offre des fonctionnalits supplmentaires et utiles, bien que parfois atypiques. Vous pouvez dsormais demander Subversion de maintenir une longueur constante (en nombre d'octets consomms) pour les mots-cls substitus, longueur que vous dfinissez en utilisant la squence double deux-points (::) aprs le nom du mot-cl, suivie du nombre de caractres espace ( ) voulus. Quand Subversion doit effectuer la substitution du mot-cl par le mot-cl et sa valeur, il ne remplace que ces espaces, laissant la taille du champ inchange. Si la valeur est plus courte que la largeur du champ, il reste des espaces pour combler la fin ; si la valeur est trop longue, elle est tronque avec le caractre dise (#) juste avant le caractre dollar ($) final. Par exemple, pour un document dans lequel vous avez une section avec les mots-cls Subversion dans un tableau, l'utilisation de la syntaxe originale de substitution de Subversion donne quelque chose comme : $Rev$: $Author$: $Date$: Numro de rvision de la dernire propagation Auteur de la dernire propagation Date de la dernire propagation

C'est joli et bien align au dbut. Mais quand vous propagez ce fichier (avec la substitution des mots-cls active, bien videmment), vous obtenez : $Rev: 12 $: Numro de rvision de la dernire propagation $Author: harry $: Auteur de la dernire propagation $Date: 2006-03-15 02:33:03 -0500 (mer. 15 mars 2006) $: Date de la dernire propagation Le rsultat n'est pas trs heureux. Vous tes alors tent de modifier le fichier aprs la substitution pour que le contenu soit mieux align. Mais cette modification ne serait valable que tant que les valeurs des mots-cls gardent la mme taille. Si le numro de dernire rvision change de valeur (par exemple de 99 100), ou si une autre personne avec un nom d'utilisateur plus long modifie le fichier, tout le travail d'alignement est refaire. Cependant, si vous utilisez la version 1.2 (ou plus) de Subversion, vous pouvez utiliser la nouvelle syntaxe et dfinir des largeurs de champs adquates et constantes. Votre fichier ressemble alors ceci : $Rev:: $Author:: $Date:: $: $: $: Numro de rvision de la dernire propagation Auteur de la dernire propagation Date de la dernire propagation

Propagez ce fichier. Cette fois, Subversion prend en compte la syntaxe d'un champ de mot-cl largeur fixe et maintient la largeur de ce champ comme indiqu entre le double deux-points et le signe dollar final. Aprs substitution, la largeur des champs n'a pas chang : les valeurs courtes comme Rev et Author sont combles avec des espaces et le champ Date, trop long, est tronqu par un caractre dise : $Rev:: 13 $Author:: harry $: $: Numro de rvision de la dernire propagation Auteur de la dernire propagation 56

Sujets avancs

$Date:: 2006-03-15 0#$:

Date de la dernire propagation

L'utilisation des mots-cls longueur fixe est particulirement efficace lors de substitutions dans des fichiers aux formats complexes, qui utilisent eux-mmes des champs de donnes de longueur fixe ou qui stockent les donnes dans des champs dont la taille est particulirement difficile changer en dehors de l'application native elle-mme (les documents Microsoft Office en sont un bon exemple). Soyez conscient que, comme la taille d'un mot-cl est mesure en octets, les valeurs utilisant des donnes codes sur plusieurs octets peuvent tre corrompues. Par exemple, un nom d'utilisateur qui contient des caractres au format UTF-8 cods sur plusieurs octets risque d'tre tronqu en plein milieu d'un de ces caractres multi-octets. Cette troncature est valide au niveau du traitement des octets mais rsulte en une chane UTF-8 incorrecte en raison du caractre final tronqu. Il est ainsi possible que certaines applications, au moment de charger le fichier, remarquent que le texte UTF-8 est invalide, considrent tout le fichier comme corrompu et refusent de travailler dessus. En consquence, lorsque vous utilisez les mots-cls longueur fixe, veillez choisir une taille adapte des valeurs pouvant contenir des caractres ventuellement cods sur plusieurs octets.

Rpertoires clairsems
Par dfaut, la plupart des oprations Subversion sur des rpertoires agissent de manire rcursive. Par exemple, svn checkout cre une copie de travail avec tous les fichiers et rpertoires de la zone spcifie du dpt, en descendant rcursivement dans l'arborescence du dpt pour en copier la structure complte sur votre disque local. Subversion 1.5 introduit une nouvelle fonctionnalit appele rpertoires clairsems (ou extractions superficielles) qui permet d'obtenir facilement une copie de travail (ou une simple portion d'une copie de travail) moins profonde que via la rcursion complte, avec la possibilit de n'extraire que plus tard les rpertoires et les fichiers ignors auparavant. Par exemple, imaginons un dpt dont l'arborescence des fichiers et rpertoires est constitue des noms des membres d'une famille et de leurs animaux de compagnie (c'est assurment un exemple bizarre, mais soit). Un svn checkout standard nous donne une copie de travail de l'ensemble de l'arborescence : $ svn checkout file:///var/svn/depot maman A maman/fils A maman/fils/petit-fils A maman/fille A maman/fille/petite-fille1 A maman/fille/petite-fille1/lapinou1.txt A maman/fille/petite-fille1/lapinou2.txt A maman/fille/petite-fille2 A maman/fille/poissonou.txt A maman/minou1.txt A maman/toutou1.txt Rvision 1 extraite. $ Maintenant, extrayons la mme arborescence, mais cette fois en demandant Subversion de nous donner uniquement le rpertoire racine sans les enfants : $ svn checkout file:///var/svn/depot maman-vide --depth empty Rvision 1 extraite. $ Remarquez que nous avons ajout l'option --depth la commande svn checkout originale. Cette option existe pour de nombreuses sous-commandes Subversion et est similaire aux options --non-recursive (-N) et --recursive (-R). En fait, elle combine, amliore, remplace et, terme, rend obsolte ces deux options plus anciennes. Dj, elle permet l'utilisateur de spcifier le niveau de rcursion de faon plus prcise, en ajoutant des niveaux auparavant non supports (ou supports de manire peu satisfaisante). Voici les valeurs de niveau de rcursion que vous pouvez ajouter vos requtes Subversion :

57

Sujets avancs

--depth empty Inclut uniquement la cible immdiate de l'opration, sans aucun fichier ou rpertoire fils. --depth files Inclut la cible immdiate de l'opration et tous les fichiers fils immdiats. --depth immediates Inclut la cible immdiate de l'opration et tous ses sous-rpertoires et fils immdiats. Les rpertoires fils seront eux-mmes vides. --depth infinity Inclut la cible immdiate, les fichiers et rpertoires fils, les fils des fils et ainsi de suite de faon raliser une rcursion complte. Bien sr, la simple combinaison de deux options existantes en une seule ne constitue pas une nouvelle fonctionnalit mritant une section complte de ce livre. Heureusement, il y a plus en dire. Ce concept de profondeur ne s'applique pas uniquement aux oprations ralises avec le client Subversion mais il s'tend aussi la description de la copie de travail elle-mme, en tant que niveau associ de manire permanente par la copie de travail chaque lment. La force de ce concept est cette permanence. La copie de travail se rappelle le niveau de rcursion que vous avez choisi pour chaque lment qui la compose, jusqu' ce que vous en changiez. Par dfaut, les commandes Subversion agissent sur les lments prsents dans la copie de travail, indpendamment de leur niveau de rcursion propre. Vous pouvez vrifier le niveau de rcursion d'une copie de travail en utilisant la commande svn info. Si le niveau de rcursion n'est pas infini, svn info affiche une ligne indiquant le niveau de rcursion : $ svn info maman-immediats | grep '^Profondeur :' Profondeur : immdiates $

Ces premiers exemples comportaient des extractions avec un niveau infini de rcursion (la valeur par dfaut de svn checkout) ou avec un niveau nul. Voyons maintenant des exemples avec d'autres valeurs de niveau de rcursion : $ svn checkout file:///var/svn/depot maman-fichiers --depth files A maman-fichiers/minou1.txt A maman-fichiers/toutou1.txt Rvision 1 extraite. $ svn checkout file:///var/svn/depot maman-immediats --depth immediates A maman-immediats/fils A maman-immediats/fille A maman-immediats/minou1.txt A maman-immediats/toutou1.txt Rvision 1 extraite. $ Comme indiqu, chacun de ces deux niveaux se situe quelque part entre la cible toute simple et la rcursion complte. Nous avons utilis la commande svn checkout pour nos exemples, mais l'option --depth est galement accessible depuis beaucoup d'autres commandes Subversion. Pour ces autres commandes, spcifier un niveau de rcursion est une manire de limiter le rayon d'action d'une opration un niveau, l'instar des vieilles options --non-recursive (-N) et -recursive (-R). Cela veut dire que lorsque vous travaillez sur une copie de travail d'un certain niveau et que vous faites une opration sur un niveau plus faible, l'opration est limite ce niveau faible. En fait, on peut gnraliser ce raisonnement : pour une copie de travail d'un niveau de rcursion arbitraire (ventuellement htrogne) et pour une commande Subversion comportant un niveau de rcursion, la commande conserve le niveau de rcursion associ aux lments de la copie de travail tout en limitant le rayon d'action de l'opration au niveau demand (ou celui par dfaut). En plus de l'option --depth, les sous-commandes svn update et svn switch acceptent une deuxime option relative au niveau de rcursion : --set-depth. C'est cette option qui vous permet de changer le niveau de rcursion associ un 58

Sujets avancs

lment d'une copie de travail. Regardez ce qui se passe aprs avoir extrait notre niveau zro puis graduellement augment le niveau de rcursion en utilisant la commande svn update --set-depth NOUVELLE-PROFONDEUR CIBLE: $ svn update --set-depth files maman-vide A maman-vide/minou1.txt A maman-vide/toutou1.txt Actualis la rvision 1. $ svn update --set-depth immediates maman-vide A maman-vide/fils A maman-vide/fille Actualis la rvision 1. $ svn update --set-depth infinity maman-vide A maman-vide/fils/petit-fils A maman-vide/fille/petite-fille1 A maman-vide/fille/petite-fille1/lapinou1.txt A maman-vide/fille/petite-fille1/lapinou2.txt A maman-vide/fille/petite-fille2 A maman-vide/fille/poissonou1.txt Actualis la rvision 1. $ Au fur et mesure que nous avons augment le niveau de rcursion, le dpt a complt progressivement notre arborescence. Dans notre exemple, nous n'avons agi que sur la racine de notre copie de travail, en changeant la valeur du niveau de rcursion associ. Mais nous pouvons aussi changer de faon indpendante le niveau de rcursion associ chaque sous-rpertoire de la copie de travail. Une utilisation minutieuse de cette option nous permet de rcuprer uniquement certaines portions de la copie de travail, en laissant de ct toutes les autres portions (d'o le nom clairsem de la fonctionnalit). Voici un exemple montrant comment construire une portion d'une branche de notre arbre gnalogique, activer la rcursion totale sur une autre branche et laguer le reste (qui ne sera donc pas sur notre disque dur). $ rm -rf maman-vide $ svn checkout file:///var/svn/depot maman-vide --depth empty Rvision 1 extraite. $ svn update --set-depth empty maman-vide/fils A maman-vide/fils Actualis la rvision 1. $ svn update --set-depth empty maman-vide/fille A maman-vide/fille Actualis la rvision 1. $ svn update --set-depth infinity maman-vide/fille/petite-fille1 A maman-vide/fille/petite-fille1 A maman-vide/fille/petite-fille1/lapinou1.txt A maman-vide/fille/petite-fille1/lapinou2.txt Actualis la rvision 1. $ Heureusement, mme avec diffrents niveaux de rcursion dfinis au sein d'une mme copie de travail, les actions sur la copie de travail ne s'en trouvent pas plus compliques. Vous pouvez toujours effectuer des modifications et les propager, revenir en arrire ou afficher les modifications locales de votre copie de travail sans spcifier d'option particulire (y compris --depth et --set-depth) aux dites commandes. Mme svn update fonctionne normalement quand on ne lui fournit pas de niveau de rcursion spcifique : elle met jour les cibles de la copie de travail qui sont prsentes en tenant compte des niveaux de rcursion qui leur sont associs. Vous devez vous demander : Bien. Mais quand aurais-je besoin d'utiliser a ? Un cas classique est li une architecture du dpt particulire : lorsque de nombreux projets et modules logiciels lis cohabitent au mme niveau dans un dpt (trunk/ projet1, trunk/projet2, trunk/projet3, etc.). Dans de tels scnarios, il est probable que seuls quelques projets vous intressent personnellement, sans doute pas plus d'un projet principal et de quelques autres modules dont il dpend. Vous pouvez extraire une copie de travail pour chacune de ces arborescences, mais ces copies de travail sont spares et, par consquent, il peut tre fastidieux d'effectuer des oprations sur plusieurs ou sur l'ensemble des copies de travail en mme temps. L'autre solution est d'utiliser la fonctionnalit de rpertoires clairsems, en construisant une seule copie de travail qui ne contient que les modules qui vous intressent. Vous partez d'une extraction du rpertoire parent commun aux diffrents projets avec un niveau zro de rcursion (empty-depth), puis vous mettez jour avec un niveau infini de rcursion les lments que vous voulez rcuprer, comme nous l'avons fait dans l'exemple prcdent. Voyez a comme un systme d'inclusion optionnelle 59

Sujets avancs

des lments qui peuplent la copie de travail. L'implmentation des extractions superficielles de Subversion 1.5 est relativement bonne mais il y a deux choses intressantes qu'elle ne permet pas de faire. Premirement, vous ne pouvez pas diminuer le niveau de rcursion d'un lment de la copie de travail. Si vous lancez svn update --set-depth empty sur une copie de travail de niveau de rcursion infini, vous n'aurez pas l'effet attendu, qui serait de supprimer tout sauf le rpertoire racine cela renverra simplement une erreur. Deuximement, il n'y a pas de valeur de rcursion pour indiquer que vous voulez exclure explicitement un lment. Vous devez effectuer une exclusion implicite de l'lment en incluant tous les lments sauf celui-l.

Verrouillage
Le modle copier-modifier-fusionner de gestion de versions de Subversion repose sur ses algorithmes de fusion, notamment sur la manire dont ils grent les conflits quand de multiples collaborateurs modifient le mme fichier simultanment. Subversion lui-mme ne propose qu'un seul algorithme de ce type, un algorithme qui dtecte les modifications par trois mthodes et qui est suffisamment intelligent pour grer les donnes la ligne prs. Subversion vous permet galement d'utiliser en plus des outils externes lors du processus de fusion (comme indiqu dans la section intitule Programme externe de comparaison de trois fichiers ), parfois encore meilleurs que ceux inclus dans Subversion, proposant par exemple une granularit plus fine allant jusqu'au mot, voire au caractre, au lieu de s'arrter la ligne. Mais, en rgle gnrale, ces algorithmes ne fonctionnent que sur des fichiers texte. Le paysage est beaucoup plus sombre lorsque l'on recherche des outils de fusion pour des formats de fichiers non-texte. Et quand vous ne trouvez pas d'outil capable de fusionner de tels fichiers, les limites du modle copier-modifier-fusionner se font vite sentir. Prenons un exemple de la vie relle o ce type de problme apparat. Harry et Sally sont deux graphistes travaillant sur le mme projet (du marketing pour le patron d'un garage). Au cur d'une affiche de ce projet se trouve l'image d'une voiture dont la carrosserie a besoin d'tre rpare, stocke dans un fichier image au format PNG. L'agencement de l'affiche est pratiquement termin, et Harry et Sally sont contents de la photo qu'ils ont choisie pour leur voiture endommage : une Ford Mustang bleue de 1967, avec un gnon sur l'aile avant gauche. C'est alors, comme c'est souvent le cas dans le domaine du graphisme, que des contraintes extrieures imposent de changer la couleur de la voiture. Sally met donc jour sa copie de travail la rvision HEAD, lance son outil d'dition de photos et commence modifier la photo de manire obtenir une voiture rouge cerise. Pendant ce temps, Harry, particulirement inspir ce jour-l, dcide que l'image serait plus percutante si la voiture tait davantage endommage. Lui aussi met jour sa copie de travail la rvision HEAD, puis dessine des fissures sur le pare-brise. Il termine son travail avant que Sally ne termine le sien, admire son chef-d'uvre et propage les changements. Peu aprs, Sally en termine avec la nouvelle couleur de la voiture et essaie de propager ses modifications. Mais, comme prvu, Subversion ne parvient pas valider la propagation et informe Sally que sa version de l'image n'est pas jour. Voil o rsident les difficults : si Harry et Sally avaient effectu leurs changements sur un fichier texte, Sally aurait simplement mis jour sa copie de travail, recevant au passage les modifications de Harry. Dans le pire des cas, ils auraient modifi la mme portion du fichier et Sally aurait eu rsoudre les conflits manuellement. Mais, ici, nous avons affaire des images binaires, pas des fichiers texte. Et s'il est relativement facile de dcrire ce que devrait tre l'image finale, il y a trs peu de chances qu'un logiciel soit suffisamment intelligent pour dtecter les parties communes de l'image sur laquelle les artistes ont travaill, les changements effectus par Harry et les changements effectus par Sally et pour en tirer une image d'une Mustang rouge avec un pare-brise fissur ! Clairement, les choses se seraient mieux passes si Harry et Sally avaient srialis leurs modifications : par exemple, si Harry avait attendu et dessin ses fissures sur la voiture nouvellement rouge de Sally, ou si Sally avait chang la couleur d'une voiture avec un pare-brise dj fissur. Comme indiqu dans la section intitule Modle copier-modifier-fusionner , la plupart de ces problmes disparaissent compltement quand une communication parfaite existe entre Harry et Sally 7. Mais comme un systme de gestion de versions est en fait un mode de communication, il s'ensuit que si ce type de logiciel facilite la srialisation de tches d'dition non paralllisables, c'est plutt une bonne chose. C'est ici que l'implmentation du concept verrouiller-modifier-librer dans Subversion prend tout son sens. Il est temps de parler de la fonctionnalit de verrouillage de Subversion, qui est similaire aux mcanismes permettant de rserver pour modifications des fichiers dans d'autres systmes de gestion de versions. En fin de compte, la fonctionnalit de verrouillage existe afin de minimiser les pertes de temps et les efforts. En autorisant un utilisateur s'arroger logiciellement le droit exclusif de modifier un fichier dans le dpt, cet utilisateur peut tre suffisamment confiant dans le fait que son travail ne sera pas vain la propagation de ses changements russira. Aussi, en signifiant aux autres utilisateurs qu'une srialisation a lieu pour un objet suivi en versions, ces utilisateurs peuvent raisonnablement s'attendre ce que cet objet soit modifi par quelqu'un d'autre. Eux aussi peuvent alors viter de perdre leur temps et leur nergie sur des modifications qui ne pourront pas tre fusionnes en raison d'un problme de mise jour du fichier correspondant.
7

ce propos, un peu de communication n'aurait pas non plus t un mauvais remde pour leurs homonymes hollywoodiens.

60

Sujets avancs

La fonctionnalit de verrouillage de Subversion comporte en fait plusieurs facettes, qui permettent entre autres de verrouiller un fichier suivi en versions 8 (demander le droit exclusif de modification sur le fichier), de le dverrouiller (abandonner le droit exclusif de modification), de voir la liste des fichiers qui sont verrouills et par qui, d'annoter des fichiers pour lesquels le verrouillage est fortement recommand avant dition, etc. Dans cette section, nous abordons toutes les facettes de cette fonctionnalit de verrouillage. Les trois types de verrous Dans cette section, comme pratiquement partout dans ce livre, les mots verrou et verrouillage dcrivent un mcanisme d'exclusion mutuelle entre utilisateurs pour viter des propagations incompatibles. Malheureusement, il existe deux autres sortes de verrous auxquels Subversion et donc ce livre sont confronts. Les premiers sont des verrous des copies de travail, utiliss en interne par Subversion pour viter des collisions entre de multiples instances du client Subversion travaillant sur la mme copie de travail. Ce type de verrou est reprable au L situ dans la troisime colonne de la sortie de svn status et peut tre supprim par la commande svn cleanup, comme indiqu la section intitule Parfois, il suffit de faire le mnage . Ensuite, il y a les verrous des bases de donnes, utiliss en interne par les bases de donnes Berkeley DB pour viter les collisions entre de multiples programmes accdant la base de donnes. C'est le type de verrou qui, s'il est encore prsent notre insu aprs une erreur, peut provoquer un plantage du dpt, comme indiqu dans la section intitule Rtablissement de bases de donnes Berkeley DB . En gnral, vous pouvez faire abstraction de ces autres types de verrous, du moins tant que tout va bien. Si les choses se gtent, vous aurez peut-tre vous y intresser. Dans ce livre, le terme verrou dsigne la fonctionnalit Subversion, sauf si le contexte indique le contraire ou si c'est mentionn explicitement.

Cration d'un verrou


Dans un dpt Subversion, un verrou est une mta-donne qui alloue un utilisateur un accs exclusif en criture sur un fichier. Cet utilisateur est appel dtenteur du verrou. Chaque verrou possde galement un identifiant unique, en gnral une longue chane de caractres, appel jeton de verrouillage. Le dpt gre les verrous en assurant in fine leur cration, leur application et leur suppression. Si une propagation tente de modifier ou effacer un fichier verrouill (ou effacer un rpertoire parent dudit fichier), le dpt demande deux informations : que le client effectuant la propagation s'authentifie en tant que dtenteur du verrou et que le jeton de verrouillage soit fourni lors de la procdure de propagation afin de montrer que le client sait bien quel verrou il utilise. Pour illustrer la cration d'un verrou, reprenons notre exemple de graphistes travaillant sur les mme fichiers image binaires. Harry a dcid de changer cette image JPEG. Pour interdire aux autres collaborateurs d'effectuer des changements sur le fichier pendant qu'il le modifie (et pour les avertir qu'il va modifier ce fichier), il verrouille le fichier dans le dpt en utilisant la commande svn lock : $ svn lock banane.jpg -m "dition du fichier pour la livraison de demain." 'banane.jpg' verrouill par l'utilisateur 'harry'. $ Il y a plusieurs points intressants dans l'exemple ci-dessus : d'abord, notez que Harry utilise l'option --message (-m) de svn lock. Comme svn commit, la commande svn lock accepte des commentaires (soit via --message (-m), soit via --file (F)) pour indiquer la raison du verrouillage du fichier. En revanche, contrairement svn commit, svn lock n'exige pas automatiquement un message en lanant votre diteur de texte prfr. Les commentaires de verrouillage sont optionnels, mais nanmoins recommands pour faciliter la communication entre collaborateurs. Ensuite, la tentative de verrouillage a russi. Cela signifie que le fichier n'tait pas pralablement verrouill et que Harry disposait de la dernire version du fichier. Si la copie de travail de Harry avait t obsolte, le dpt aurait refus la demande, forant Harry effectuer une mise jour (svn update) et relancer ensuite la commande de verrouillage. La commande de verrouillage aurait galement chou si le fichier avait dj t verrouill par quelqu'un d'autre. Comme vous pouvez le constater, la commande svn lock affiche la confirmation que le verrouillage a russi. Ds lors, le
8

Pour l'instant, Subversion ne permet pas de poser de verrou sur un rpertoire.

61

Sujets avancs

verrouillage du fichier apparat dans le rsultat des commandes svn status et svn info : $ svn status K banane.jpg $ svn info banane.jpg Chemin : banane.jpg Nom : banane.jpg URL : http://svn.exemple.com/depot/projet/banane.jpg Racine du dpt : http://svn.exemple.com/depot UUID du dpt : edb2f264-5ef2-0310-a47a-87b0ce17a8ec Revision: 2198 Type de nud : file Tche programme : normale Auteur de la dernire modification : frank Rvision de la dernire modification : 1950 Date de la dernire modification : 2006-03-15 12:43:04 -0600 (mer. 15 mars 2006) Texte mis jour : 2006-06-08 19:23:07 -0500 (jeu. 08 juin 2006) Proprits mis jour : 2006-06-08 19:23:07 -0500 (jeu. 08 juin 2006) Somme de contrle: 3b110d3b10638f5d1f4fe0f436a5a2a5 Nom de verrou : opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e Propritaire du verrou : harry Verrou cr : 2006-06-14 17:20:31 -0500 (mer. 14 juin 2006) Commentaire du verrou (1 ligne): dition du fichier pour la livraison de demain. $

Le fait que la commande svn info, qui ne contacte pas le dpt quand elle porte sur un chemin d'une copie de travail, affiche bien le jeton de verrouillage, rvle une caractristique importante des jetons de verrouillage : ils sont intgrs dans la copie de travail. La prsence du jeton de verrouillage est primordiale. Il authorise la copie de travail utiliser le verrou ultrieurement. Par ailleurs, la commande svn status affiche un K (raccourci pour locKed verrouill en anglais) avant le nom du fichier, indiquant que le jeton de verrouillage est prsent. propos des jetons de verrouillage Un jeton de verrouillage n'est pas un jeton d'authentification mais plutt un jeton d'autorisation. Le jeton n'est pas protg comme un secret. En fait, le jeton de verrouillage peut tre vu par n'importe quel utilisateur qui lance la commande svn info URL. Un jeton de verrouillage n'a de proprit spciale que quand il est plac dans une copie de travail. C'est la preuve que le verrou a t cr dans cette copie de travail et non ailleurs par quelqu'un d'autre. Seulement s'authentifier en tant que propritaire du verrou n'est pas suffisant pour viter les accidents. Par exemple, supposons que vous verrouilliez un fichier avec votre ordinateur au bureau, puis que vous quittiez le travail avant d'avoir fini vos changements sur ce fichier. Il ne doit pas tre possible de propager accidentellement des modifications de ce mme fichier depuis votre ordinateur la maison plus tard dans la soire simplement parce que vous vous tes authentifi en tant que dtenteur du verrou. En d'autres termes, le verrou interdit une instance d'un quelconque client Subversion de saboter le travail d'une autre instance (dans notre exemple, si vous avez rellement besoin de modifier le fichier depuis votre copie de travail la maison, vous devrez casser le verrou puis re-verrouiller le fichier).

Maintenant que Harry a verrouill banane.jpg, Sally ne peut ni modifier ni effacer ce fichier : $ svn delete banane.jpg D banane.jpg $ svn commit -m "Suppression des fichiers inutiles." Suppression banane.jpg svn: chec de la propagation (commit), (dtails): svn: Suppression de '/depot/projet/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/banane.jpg': 423 Verrouill (http://svn.exemple.com) $ 62

Sujets avancs

Mais Harry, aprs avoir fait ses retouches sur sa belle banane jaune, peut propager ses changements sur le fichier. C'est parce qu'il s'authentifie en tant que dtenteur du verrou et aussi parce que sa copie de travail possde le bon jeton de verrouillage : $ svn status M K banane.jpg $ svn commit -m "Rendu la banane plus jaune." Envoi banane.jpg Transmission des donnes . Rvision 2201 propage. $ svn status $ Notez qu'aprs que la propagation est termine, svn status permet de voir que le jeton de verrouillage n'est plus prsent dans la copie de travail. C'est le comportement normal de svn commit : elle recherche dans la copie de travail (ou dans une liste de cibles, si vous fournissez une telle liste) les modifications effectues localement et elle envoie les jetons de verrouillage qu'elle trouve durant sa recherche au serveur, en tant que partie intgrante du processus de propagation. Aprs que la propagation a russi, tous les verrous du dpt qui ont t mentionns sont librs, mme ceux pour lesquels les fichiers n'ont pas t propags. Ce comportement a pour but de dissuader les utilisateurs d'tre ngligents avec leurs verrous ou de garder des verrous trop longtemps. Si Harry verrouille au hasard trente fichiers dans un rpertoire nomm Images parce qu'il n'est pas sr de savoir quels fichiers il doit modifier et qu'il ne modifie finalement que quatre fichiers, alors quand il lance la commande svn commit Images, la procdure libre les trente verrous. Ce mode de fonctionnement (librer automatiquement les verrous) peut tre modifi avec l'option --no-unlock de svn commit. C'est utile quand vous voulez propager des changements mais que vous prvoyez d'effectuer des changements supplmentaires et que donc vous avez toujours besoin des verrous. Vous pouvez galement en faire le fonctionnement par dfaut en rglant l'option no-unlock dans la zone de configuration (voir la section intitule Zone de configuration des excutables ). Bien sr, verrouiller un fichier n'oblige pas l'utilisateur le modifier. Le verrou peut tre libr n'importe quand avec la commande svn unlock : $ svn unlock banane.c 'banane.c' dverrouill.

Identification d'un verrou


Quand une propagation choue parce que quelqu'un d'autre a pos un verrou, il est facile de savoir pourquoi. La commande la plus simple est svn status --show-updates: $ svn status -u M 23 truc.c M O 32 raisin.jpg * 72 machin.h tat par rapport la rvision $

105

Dans cet exemple, Sally peut voir que non seulement sa copie de travail de machin.h n'est plus jour, mais aussi qu'un des deux fichiers qu'elle prvoie de propager est verrouill dans le dpt. La lettre O ( Others autres en anglais) indique qu'un verrou existe sur ce fichier et qu'il a t cr par quelqu'un d'autre. Si elle essayait de lancer svn commit, le verrou sur raisin.jpg l'en empcherait. Sally est laisse dans l'expectative de savoir qui a pos le verrou, quand et pourquoi. L encore, svn info trouve la rponse : $ svn info http://svn.exemple.com/depot/projet/raisin.jpg Chemin : raisin.jpg Nom : raisin.jpg URL: http://svn.exemple.com/depot/projet/raisin.jpg 63

Sujets avancs

UUID du dpt : edb2f264-5ef2-0310-a47a-87b0ce17a8ec Rvision: 105 Type de nud : file Auteur de la dernire modification : sally Rvision de la dernire modification : 32 Texte mis jour : 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006) Nom de verrou : opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b Propritaire du verrou : harry Verrou cr : 2006-02-16 13:29:18 -0500 (jeu. 16 fvr. 2006) Commentaire du verrou (1 ligne): Besoin de faire une retouche rapide sur cette image. $ De la mme manire que svn info peut tre utilise pour examiner les objets de la copie de travail, elle peut tre utilise pour examiner les objets du dpt. Si l'argument principal de svn info est un chemin de la copie de travail, alors toutes les informations stockes localement sont affiches ; toute mention d'un verrou signifie que la copie de travail dtient un jeton de verrouillage (si le fichier est verrouill par un autre utilisateur ou depuis une autre copie de travail, alors lancer svn info sur la copie de travail ne renvoit aucune information relative au verrou). Si l'argument principal de svn info est une URL, alors les informations affiches se rapportent la dernire version de l'objet dans le dpt et toute mention d'un verrou concerne le verrou en cours sur l'objet. Ainsi, dans notre exemple, Sally peut voir que Harry a verrouill le fichier le 16 fvrier pour effectuer une retouche rapide . Comme nous sommes en juin, elle suspecte qu'il a probablement oubli le verrou. Elle pourrait tlphoner Harry pour le lui signaler et lui demander de librer le verrou. S'il n'est pas joignable, elle peut toujours essayer de forcer le verrou elle-mme, ou demander un administrateur de le faire.

Cassage et vol d'un verrou


Un verrou n'est pas quelque chose de sacr : dans la configuration par dfaut de Subversion, les verrous peuvent tre librs non seulement par leur dtenteur, mais aussi par n'importe qui d'autre. Quand quelqu'un d'autre que le dtenteur d'un verrou le libre, nous appelons a casser le verrou. Avec un statut d'administrateur, il est facile de casser un verrou. Les programmes svnlook et svnadmin peuvent afficher et casser les verrous directement dans le dpt (pour plus d'informations sur ces outils, reportez-vous la section intitule Bote outils de l'administrateur ). $ svnadmin lslocks /usr/local/svn/depot Chemin : /projet2/images/banane.jpg Chane UUID : opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923 Propritaire : frank Cr : 2006-06-15 13:29:18 -0500 (jeu. 15 juin 2006) Expire : Commentaire (1 ligne): J'amliore encore la couleur jaune. Chemin : /projet/raisin.jpg Chane UUID : opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b Propritaire : harry Cr : 2006-02-16 13:29:18 -0500 (jeu. 16 fv. 2006) Expire : Commentaire (1 ligne): Besoin de faire une retouche rapide sur cette image. $ svnadmin rmlocks /usr/local/svn/depot/projet/raisin.jpg '/projet/raisin.jpg' dverrouill $ L'option la plus intressante est celle qui permet aux utilisateurs de casser les verrous dtenus par d'autres personnes travers le rseau. Pour ce faire, Sally doit simplement ajouter l'option --force la commande svn unlock : $ svn status -u M 23

truc.c 64

Sujets avancs

32 raisin.jpg * 72 machin.h tat par rapport la rvision 105 $ svn unlock raisin.jpg svn: 'raisin.jpg' n'est pas verrouill dans cette copie de travail $ svn info raisin.jpg | grep URL URL: http://svn.exemple.com/depot/projet/raisin.jpg $ svn unlock http://svn.exemple.com/depot/projet/raisin.jpg svn: Unlock request failed: 403 Forbidden (http://svn.exemple.com) $ svn unlock --force http://svn.exemple.com/depot/projet/raisin.jpg 'raisin.jpg' dverrouill. $ Ainsi, la tentative initiale de Sally pour librer le verrou a chou parce qu'elle a lanc svn unlock directement sur le fichier de sa copie de travail, o aucun jeton de verrouillage n'tait prsent. Pour casser le verrou directement dans le dpt, elle doit passer une URL svn unlock. Son premier essai pour casser le verrou avec l'URL choue car elle ne peut pas s'authentifier comme dtentrice du verrou (et elle n'a pas non plus le jeton de verrouillage). Mais quand elle passe l'option --force, les pr-requis d'authentification et d'autorisation sont ignors et le verrou est cass. Casser le verrou peut ne pas tre suffisant. Dans l'exemple, Sally ne veut pas seulement casser le verrou oubli par Harry, mais galement re-verrouiller le fichier pour son propre usage. Elle peut le faire en lanant svn unlock avec l'option --force puis svn lock la suite, mais il existe une petite chance que quelqu'un d'autre verrouille le fichier entre les deux commandes. La meilleure solution est donc de voler le verrou, ce qui implique de casser et re-verrouiller le fichier en une seule opration atomique. Pour ce faire, Sally passe l'option --force la commande svn lock : $ svn lock raisin.jpg svn: avertissement : chec de la demande de verrou : 423 verrouill (http://svn.exemple.com) $ svn lock --force raisin.jpg 'raisin.jpg' verrouill par l'utilisateur 'sally'. $ Dans tous les cas, que le verrou soit cass ou vol, Harry est bon pour une bonne surprise. La copie de travail de Harry contient toujours le jeton de verrouillage original, mais le verrou n'existe plus. Le jeton de verrouillage est dit dfunt. Le verrou associ au jeton de verrouillage a t soit cass (il n'existe plus dans le dpt) soit vol (remplac par un autre verrou). Quoi qu'il en soit, Harry peut voir ce qu'il en est en demandant svn status de contacter le dpt : $ svn status K raisin.jpg $ svn status -u B 32 $ svn update B raisin.jpg $ svn status $

raisin.jpg

Si le verrou dans le dpt a t cass, alors svn status --show-updates affiche un B (pour Broken cass en anglais) ct du fichier. Si un nouveau verrou existe en lieu et place de l'ancien, alors un T (pour sTolen vol en anglais) est affich. Finalement, svn update dtecte les jetons de verrouillage dfunts et les supprime de la copie de travail. Politiques de verrouillage Il existe diffrentes visions de la rsistance que doit avoir un verrou. Certains considrent que les verrous doivent tre respects tout prix et donc librables uniquement par leur dtenteur ou par un administrateur. Ils affirment que si n'importe qui peut casser un verrou c'est la pagaille et tout le concept de verrouillage est mis par terre. D'autres pensent que les verrous sont d'abord et avant tout un outil de communication. Si les utilisateurs cassent les verrous des autres en permanence, c'est un problme culturel de l'quipe qui ne peut pas tre rsolu par un outil logiciel. Subversion souscrit la version douce mais autorise cependant les administrateurs mettre en place une politique plus stricte via l'utilisation de procdures automatiques. En particulier, les procdures automatiques de pr-verrouillage 65

Sujets avancs

(fichier pre-lock) et de pr-dverrouillage (fichier pre-unlock) permettent aux administrateurs de dcider dans quelles situations la cration ou la libration d'un verrou est autorise. En fonction de l'existence pralable ou non d'un verrou, ces deux procdures automatiques dcident s'il convient ou non d'autoriser tel utilisateur casser ou voler tel verrou. Des procdures automatiques de post-verrouillage (fichier post-lock) et de post-dverrouillage (fichier post-unlock) sont galement disponibles et peuvent tre utilises pour envoyer des emails suite aux actions de verrouillage. Pour en savoir plus sur les procdures automatiques, voir la section intitule Mise en place des procdures automatiques .

Communication par l'intermdiaire des verrous


Nous avons vu comment svn lock et svn unlock peuvent tre utiliss pour poser, librer, casser ou voler des verrous. Cela rsout le problme de la srialisation des accs un fichier. Mais qu'en est-il du problme plus vaste d'viter les pertes de temps ? Par exemple, supposons que Harry verrouille un fichier image et commence l'diter. Pendant ce temps, loin de l, Sally veut faire la mme chose. Elle ne pense pas faire un svn status --show-updates et n'a donc pas la moindre ide que Harry a dj verrouill le fichier. Elle passe des heures modifier le fichier et quand elle tente de propager ses changements, elle dcouvre soit que le fichier est verrouill, soit que son propre fichier n'tait pas jour. Quoi qu'il en soit, ses modifications ne peuvent pas tre fusionnes avec celles de Harry. L'un des deux doit passer ses modifications par pertes et profits, un temps consquent a t gaspill. La solution propose par Subversion ce problme est de fournir un mcanisme pour rappeler aux utilisateurs qu'un fichier devrait tre verrouill avant de faire des modifications. Ce mcanisme est mis en uvre par une proprit spciale : svn:needs-lock. Si cette proprit est associe un fichier (quelle que soit sa valeur, qui n'est pas prise en compte), alors Subversion essaie d'utiliser les permissions du systme de fichiers pour le placer en lecture seule moins, bien sr, que l'utilisateur ait explicitement verrouill le fichier. Quand un jeton de verrouillage est prsent (indiquant que svn lock a t lance), le fichier est plac en lecture-criture. Quand le verrou est libr, le fichier passe de nouveau en lecture seule. La thorie est donc que si le fichier image a cette proprit dfinie, alors Sally remarquera tout de suite quelque chose d'trange l'ouverture du fichier : beaucoup d'applications avertissent l'utilisateur immdiatement quand un fichier en lecture seule est ouvert pour dition et pratiquement toutes l'empcheront de sauvegarder ses modifications dans le fichier. Cela lui rappellera de verrouiller le fichier avant de l'diter, dcouvrant ainsi le verrou pr-existant : $ /usr/local/bin/gimp raisin.jpg gimp: erreur: le fichier est en lecture seule ! $ ls -l raisin.jpg -r--r--r-1 sally sally 215589 juin 8 19:23 raisin.jpg $ svn lock raisin.jpg svn: avertissement : chec de la demande de verrou : 423 verrouill (http://svn.exemple.com) $ svn info http://svn.exemple.com/depot/projet/raisin.jpg | grep errou Nom de verrou : opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b Propritaire du verrou : harry Verrou cr : 2006-06-08 07:29:18 -0500 (jeu. 08 juin 2006) Commentaire de verrouillage (1 ligne): J'effectue quelques retouches. Je le verrouille pour deux heures. $

Les utilisateurs et les administrateurs sont tous encourags positionner la proprit svn:needs-lock sur les fichiers qui ne peuvent pas tre contextuellement fusionns. C'est la technique de base pour favoriser les bonnes habitudes de verrouillage et viter les pertes de temps. Notez que cette proprit est un outil de communication qui fonctionne indpendamment de la politique de verrouillage. Autrement dit, n'importe quel fichier peut tre verrouill, que cette proprit existe ou pas. Et rciproquement, l'existence de cette proprit ne rend pas obligatoire le verrouillage pour pouvoir propager des modifications. Malheureusement, le systme n'est pas parfait. Il est possible que, mme si le fichier possde la proprit, l'avertissement de lecture seule ne marche pas. Quelquefois, les applications ne suivent pas les normes et piratent le fichier en lecture seule, autorisant sans rien dire l'utilisateur modifier et sauvegarder le fichier. Subversion ne peut pas faire grand chose dans ce 66

Sujets avancs genre de cas : au final, rien ne remplace une bonne communication entre les membres d'une quipe 9.

Dfinition de rfrences externes


Parfois il peut tre utile de construire une copie de travail issue de diffrentes extractions. Par exemple, vous pouvez avoir envie d'avoir diffrents sous-rpertoires provenant de diffrents endroits du dpt ou mme carrment de diffrents dpts. Vous pouvez arriver un tel enchevtrement manuellement, en utilisant svn checkout, pour crer le genre de structure voulu pour votre copie de travail. Mais si cette configuration est importante pour tous les utilisateurs de votre dpt, chacun doit effectuer les mmes oprations d'extraction que vous. Heureusement, Subversion supporte les dfinitions de rfrences externes. Une dfinition de rfrence externe est une association entre un rpertoire local et une URL (et idalement un numro de rvision particulier) pour un rpertoire suivi en versions. Dans Subversion, vous dclarez les dfinitions de rfrences externes dans des groupes en utilisant la proprit svn:externals. Vous pouvez crer et modifier cette proprit en utilisant svn propset ou svn propedit (voir la section intitule Manipulation des proprits ). Elle peut tre dfinie sur tous les rpertoires suivis en versions et sa valeur dcrit la fois l'URL du dpt externe et le rpertoire ct client dans lequel est extrait cette URL. L'un des attraits de la proprit svn:externals est qu'une fois qu'elle est dfinie pour un rpertoire suivi en versions, chaque utilisateur qui extrait une copie de travail de ce rpertoire bnficie des dfinitions de rfrences externes. En d'autres termes, une fois qu'un utilisateur a fait l'effort de dfinir la structure de la copie de travail imbrique, tout le monde en bnficie automatiquement : Subversion, lors de l'extraction de la copie de travail originale, extraie galement les copies de travail externes. Les sous-rpertoires cibles des dfinitions de rfrences externes ne doivent pas dj exister sur votre systme ou sur le systmes des autres utilisateurs : Subversion les cre lors de l'extraction des copies de travail externes. Vous bnficiez avec les dfinitions de rfrences externes de tous les avantages lis aux proprits Subversion. Les dfinitions sont suivies en versions. Si vous avez besoin de changer une dfinition de rfrence externe, vous pouvez le faire l'aide des sous-commandes classiques sur les proprits. Quand vous propagez des modifications relatives la proprit svn:externals, Subversion synchronise les lments extraits par rapport la dfinition de rfrences externes modifie ds que vous lancez svn update. Tous ceux qui mettent jour leur copie de travail reoivent vos modifications concernant les dfinitions de rfrences externes. Comme la valeur de la proprit svn:externals est constitue de plusieurs lignes, nous vous recommandons fortement d'utiliser svn propedit plutt que svn propset. Les versions de Subversion antrieure 1.5 utilisent un format de dfinitions externes qui est un tableau sur plusieurs lignes composes de sous-rpertoires (relativement au rpertoire suivi en versions sur lequel est dfinie la proprit), d'indicateurs de rvision optionnels et l'URL, absolue et compltement qualifie, du dpt Subversion. Par exemple : $ svn propget svn:externals calc tierce-partie/sons tierce-partie/themes -r148 tierce-partie/themes/outils -r21

http://svn.exemple.com/depot/sons http://svn.exemple.com/projet-themes http://svn.exemple.com/outils-themes

Quand quelqu'un extrait une copie de travail du rpertoire calc dcrit dans l'exemple ci-dessus, Subversion extrait galement les lments trouvs dans les dfinitions de rfrences externes. $ svn checkout http://svn.exemple.com/depot/calc A calc A calc/Makefile A calc/entier.c A calc/bouton.c Rvision 148 extraite.

part, peut-tre, la fusion mentale vulcaine.

67

Sujets avancs

Rcupration de la rfrence externe dans 'calc/tierce-partie/sons' A calc/tierce-partie/sons/ding.ogg A calc/tierce-partie/sons/dong.ogg A calc/tierce-partie/sons/clang.ogg A calc/tierce-partie/sons/bang.ogg A calc/tierce-partie/sons/twang.ogg Rvision 14 extraite. Rcupration de la rfrence externe dans 'calc/tierce-partie/themes' partir de la version 1.5 de Subversion, un nouveau format de la proprit svn:externals est support. Les rfrences externes sont toujours multi-lignes mais l'ordre et le format des diffrentes informations ont chang. La nouvelle syntaxe ressemble plus l'ordre des arguments que vous passez la commande svn checkout : l'indicateur optionnel de rvision est plac en premier, puis l'URL du dpt Subversion externe et, enfin, le sous-rpertoire local relatif. Notez cependant que cette fois-ci nous n'avons pas indiqu URL absolue et compltement qualifie pour le dpt externe. En effet, le nouveau format accepte les URL relatives et les URL avec des piquets de rvision. L'exemple prcdent sur les rfrences externes donne avec Subversion 1.5 : $ svn propget svn:externals calc http://svn.exemple.com/depot/sons -r148 http://svn.exemple.com/projet-themes -r21 http://svn.exemple.com/outils-themes

tierce-partie/sons tierce-partie/themes tierce-partie/themes/outils

En utilisant la syntaxe avec les piquets de rvision (dcrite en dtail dans la section intitule Piquets de rvisions et rvisions oprationnelles ), il peut aussi tre crit comme ceci : $ svn propget svn:externals calc http://svn.exemple.com/depot/sons http://svn.exemple.com/projet-themes@148 http://svn.exemple.com/outils-themes@21

tierce-partie/sons tierce-partie/themes tierce-partie/themes/outils

Il est particulirement conseill d'utiliser des numros de rvision explicites dans toutes vos rfrences externes. Ainsi, vous conservez la possibilit de dcider quand rapatrier une nouvelle version de vos informations externes et quelle version exacte rapatrier. En plus de vous viter la surprise de recevoir des changements effectus sur des dpts tiers dont vous n'avez pas la matrise, l'utilisation de numros de rvisions explicites signifie aussi que, si vous revenez une version de travail antrieure, vos rfrences externes reviendront elles aussi dans l'tat o elles taient au moment de cette version antrieure. Cela signifie aussi que les copies de travail externes sont actualises pour reflter leur tat au moment de la rvision antrieure. Pour des projets logiciels, cela peut faire la diffrence entre la russite et l'chec de la compilation d'une version antrieure d'un code source complexe. Pour la plupart des dpts, les trois formats de rfrences externes ont le mme effet au final. Ils apportent tous les mmes avantages. Malheureusement, ils possdent aussi les mmes inconvnients. Puisque les rfrences indiques utilisent des URL absolues, dplacer ou copier un rpertoire auquel elles sont rattaches n'affecte pas ce qui est extrait en externe (alors qu'une rfrence relative est, bien videmment, dplace avec le rpertoire). Cela peut vous induire en erreur, voire tre assez frustrant, dans certaines situations. Par exemple, imaginons un rpertoire racine appel mon-projet pour lequel nous avons dfini des rfrences externes dans un sous-rpertoire (mon-projet/un-rep) vers la dernire rvision d'un autre sousrpertoire (mon-projet/rep-externe). $ svn checkout http://svn.exemple.com/projets . A mon-projet A mon-projet/un-rep A mon-projet/rep-externe Rcupration de la rfrence externe dans 'mon-projet/un-rep/sous-rep' Rfrence externe actualise la rvision 11. 68

Sujets avancs

Actualis la rvision 11. $ svn propget svn:externals mon-projet/un-rep sous-rep http://svn.exemple.com/projets/mon-projet/rep-externe $ Maintenant utilisez la commande svn move pour renommer le rpertoire mon-projet. ce moment l, vos dfinitions de rfrences externes pointent toujours vers un chemin sous le rpertoire mon-projet, mme si ce rpertoire n'existe plus. $ svn move -q mon-projet nouveau-projet $ svn commit -m "Renomm mon-projet en nouveau-projet." Suppression mon-projet Ajout nouveau-projet Rvision 12 propage. $ svn update Rcupration de la rfrence externe dans 'nouveau-projet/un-rep/sous-rep' svn: Le dpt http://svn.exemple.com/projets/mon-projet/rep-externe n'existe pas $ De plus, les URL absolues utilises par les rfrences externes peuvent causer des problmes pour les dpts accessibles via plusieurs types d'URL. Par exemple, si votre serveur Subversion est configur pour autoriser tout le monde consulter le dpt via http:// ou https://, mais que les oprations de propagation doivent tre effectues uniquement via https://, vous vous retrouvez bien embt. Si vos rfrences externes pointent vers une URL de type http://, vous ne pouvez pas effectuer de propagation depuis les copies de travail cres via ces rfrences externes. D'un autre ct, si vous utilisez la forme https:// pour les URL, ceux qui voudront effectuer des consultations via http://, parce que leur client ne sait pas traiter le https://, seront incapables de rcuprer les lments externes. Soyez conscient galement que si vous avez besoin de dplacer toute votre copie de travail (avec svn switch et l'option --relocate), les rfrences externes ne seront pas mises jour en consquence. Subversion 1.5 franchit un grand pas dans la rsolution de ces soucis. Comme indiqu prcdemment, les URL utilises dans le nouveau format des dfinitions des rfrences externes peuvent tre relatives. Par ailleurs, Subversion autorise une syntaxe magique pour spcifier plusieurs types d'URL relatives. ../ Relative l'URL du rpertoire sur lequel la proprit svn:externals est dfinie. ^/ Relative la racine du dpt pour lequel la proprit svn:externals est suivie en versions. // Relative au type d'URL du rpertoire sur lequel la proprit svn:externals est dfinie. / Relative l'URL du serveur sur lequel la proprit svn:externals est suivie en versions. Donc, considrons pour la quatrime fois la dfinition de nos rfrences externes de l'exemple prcdent et utilisons la nouvelle syntaxe de diffrentes manire. Nous obtenons : $ svn propget svn:externals calc ^/sons tierce-partie/sons /themes@148 tierce-partie/themes //svn.exemple.com/outils-themes@21 tierce-partie/themes/outils Le support des rfrences externes dans Subversion demeure imparfait. Une dfinition de rfrence externe ne peut pointer que vers des rpertoires et non vers des fichiers. Par ailleurs, le sous-rpertoire local dans la dfinition ne peut pas contenir 69

Sujets avancs

d'indicateur de rpertoire pre (..) ; ainsi, ../../themes/mon-theme est interdit. Et peut-tre encore plus dommage, les copies de travail cres par la dfinition de rfrences externes sont toujours dconnectes de la copie de travail primaire (celle dans laquelle la proprit svn:externals est dfinie sur le rpertoire suivi en versions). Et Subversion ne peut fonctionner pleinement que sur des copies de travail d'un seul tenant. Ainsi, si vous voulez propager des changements que vous avez effectus sur une ou plusieurs de ces copies de travail externes, vous devez lancez svn commit explicitement sur ces copies de travail effectuer une propagation sur la copie de travail primaire ne traite pas rcursivement les copies de travail externes. Nous avons dj mentionn certains dfauts de l'ancien format de svn:externals et comment la version 1.5 de Subversion les corrige. Mais faites attention, en utilisant les nouveaux formats, ne pas pnaliser accidentellement des utilisateurs qui accdent votre dpt avec de vieux clients Subversion. Alors que les clients Subversion 1.5 supportent toujours le format original des dfinitions de rfrences externes, les vieux clients ne sont pas capables d'analyser le nouveau format. En plus des commandes svn checkout, svn update, svn switch et svn export qui grent effectivement les sous-rpertoires disjoints (ou dconnects) o sont extraites les rfrences externes, la commande svn status reconnat galement les dfinitions de rfrences externes. Elle affiche un code de statut X pour les sous-rpertoires externes disjoints et parcourt ces sous-rpertoires pour afficher le statut des lments externes eux-mmes. Vous pouvez passer l'option -ignore-externals n'importe laquelle de ces commandes pour dsactiver le traitement des dfinitions de rfrences externes.

Piquets de rvisions et rvisions oprationnelles


Continuellement, nous copions, dplaons, renommons et remplaons des fichiers et des rpertoires sur nos ordinateurs. Et votre systme de gestion de versions ne doit pas tre un obstacle ces oprations sur les fichiers et rpertoires suivis en versions. La gestion des fichiers par Subversion se fait pratiquement oublier, tant presque aussi flexible pour les fichiers suivis en versions que pour les autres. Mais cette flexibilit signifie qu'au cours de la vie de votre dpt un objet suivi en versions a un certain nombre de chemins et qu'un chemin donn peut reprsenter plusieurs objets suivis en versions tout fait diffrents. Cela ajoute un niveau de complexit supplmentaire dans les actions sur les chemins et les objets. Subversion est plutt adroit pour dtecter les changements d'adresses dans l'historique du suivi de versions d'un objet. Par exemple, si vous demandez l'historique d'un fichier qui a t renomm la semaine dernire, Subversion fournit ce journal (la rvision dans laquelle s'est produit le changement de nom) et les journaux pertinents avant et aprs ce renommage. Ainsi, la plupart du temps, vous n'avez pas vous proccuper de ces oprations. Mais il arrive que Subversion ait besoin de votre aide pour lever des ambiguts. L'exemple correspondant le plus simple est quand un fichier ou un rpertoire est supprim du suivi de versions, puis qu'un nouveau rpertoire ou fichier est cr avec le mme nom et ajout au suivi de versions. L'objet qui a t effac et celui qui a t ajout plus tard ne sont pas les mmes. Ils se trouve qu'ils ont juste le mme chemin (/trunk/objet par exemple). Que signifie alors de demander Subversion l'historique de /trunk/objet ? La question concerne-t-elle l'objet actuellement cet emplacement ou l'objet prcdent qui a t supprim ? Ou encore les oprations sur tous les objets qui ont rsid cet emplacement ? Subversion a besoin de savoir ce que vous demandez rellement. Et, en raison des dplacements, l'historique des objets suivis en versions peut tre beaucoup plus tordu que cela. Par exemple, vous pouvez avoir un rpertoire appel concept, contenant une bauche de projet logiciel sur lequel vous vous tes essay. Il se peut que ce projet mrisse et que l'ide soit pertinente au point que, chose inimaginable, vous dcidiez de donner un nom au projet 10. Imaginons que vous nommiez ce logiciel frabnaggilywort. Il semble alors logique de renommer le rpertoire concept en frabnaggilywort pour reflter le nom du projet. L'eau coule sous les ponts et Frabnaggilywort sort en version 1.0, est tlcharg et utilis quotidiennement par des tonnes de gens qui veulent se faciliter la vie. Quelle belle histoire ! Mais elle ne s'arrte pas l. Comme vous avez une me d'entrepreneur, vous avez dj une autre ide derrire la tte : vous crez donc un nouveau rpertoire concept et la boucle est boucle. En fait, ce cycle recommence plusieurs fois au fil du temps, chaque fois partir de ce vieux rpertoire concept qui, quelquefois, est renomm, quand l'ide plat et, d'autres fois, est effac quand l'ide ne convient pas. En plus, pour tre rellement tordu, vous donnez parfois concept un autre nom temporaire, puis renommez ce mme rpertoire concept pour une raison quelconque. Avec de tels scnarios, demander Subversion d'apprendre travailler avec ces renommages multiples est un peu comme dire un automobiliste de la banlieue de prendre la direction de Paris et de prendre gauche sur la rue du Chteau : il croisera la rue du Chteau Asnires, La Garenne-Colombes, Nanterre, Neuilly, Rueil-Malmaison, et, non, ce n'est pas la mme rue chaque fois. De la mme manire, Subversion a besoin d'un peu plus de prcisions pour travailler correctement.

10

Vous n'tes pas supposs lui donner un nom. Une fois que vous l'avez nomm, vous allez forcment vous y attacher , Bob Razowski (le cyclope de Monstres et Cie).

70

Sujets avancs

Dans sa version 1.1, Subversion a introduit une faon de spcifier de quelle rue du Chteau on parle. Cela s'appelle le piquet de rvision et c'est uniquement destin identifier de manire unique une branche de l'historique. Comme il y a au plus un objet suivi en versions un endroit et un moment donns (ou plus prcisment une rvision donne), la combinaison d'un chemin et d'un piquet de rvision est tout ce dont vous avez besoin pour dsigner une branche spcifique de l'historique. Les piquets de rvision sont indiqus au client Subversion en utilisant la notation at (on l'appelle ainsi parce que la syntaxe de la commande utilise le signe arobase @) suivi du piquet de rvision demand, en fin de chemin. Mais alors qu'en est-il de l'option --revision (-r) dont nous avons tant parl dans ce livre ? Cette rvision (ou ensemble de rvisions) est appele la rvision oprationnelle (ou ensemble de rvisions oprationnelles). Une fois qu'une branche particulire de l'historique a t identifie en utilisant un chemin et un piquet de rvision, Subversion effectue la requte en utilisant la rvision oprationnelle (ou l'ensemble de rvisions oprationnelles). Pour reprendre notre analogie avec les rues franaises, si on vous dit d'aller au 15 de la rue du Chteau Rueil-Malmaison 11, vous pouvez penser que la rue du Chteau est le chemin dans le systme de fichiers et Rueil-Malmaison le piquet de rvision. Ces deux informations identifient de manire unique une route donne et vous vitent de parcourir une autre rue du Chteau la recherche de votre destination finale. Maintenant, vous pouvez rechercher le 15 comme numro de rvision oprationnelle puisque nous savons exactement o aller. Algorithme des piquets de rvision Subversion utilise l'algorithme des piquets de rvision chaque fois qu'il doit rsoudre une ambigut dans les chemins et numros de versions fournis en ligne de commande. Voici un exemple d'une telle ligne de commande : $ svn commande -r REVISION-OPERATIONNELLE element@PIQUET-DE-REVISION Si REVISION-OPERATIONNELLE est plus vieille que PIQUET-DE-REVISION, alors l'algorithme est le suivant : 1. Trouver element dans la rvision identifie par PIQUET-DE-REVISION. Il ne peut y avoir qu'un seul objet. 2. Parcourir l'historique de l'objet l'envers (y compris en tenant compte d'ventuels renommages) jusqu' son anctre dans la rvision REVISION-OPERATIONNELLE. 3. Effectuer la requte sur cet anctre, o qu'il soit et quel que soit son nom (actuel et ce moment l). Mais que se passe-t-il si REVISION-OPERATIONNELLE est plus rcente que PIQUET-DE-REVISION ? Et bien, cela ajoute un peu de complexit la recherche du chemin dans REVISION-OPERATIONNELLE, parce que l'historique du chemin peut avoir bifurqu plusieurs reprises (en raison d'oprations de copie) entre PIQUETDE-REVISION et REVISION-OPERATIONNELLE. Et ce n'est pas tout car, de toute faon, Subversion ne stocke pas suffisamment d'informations pour retracer de faon performante l'historique d'un lment dans le sens chronologique. Donc, dans ce cas, l'algorithme est un peu diffrent : 1. Trouver element dans la rvision identifie par REVISION-OPERATIONNELLE. Il ne peut y avoir qu'un seul objet. 2. Parcourir l'historique de l'objet l'envers (y compris en tenant compte d'ventuels renommages) jusqu' son anctre dans la rvision PIQUET-DE-REVISION. 3. Vrifier que la position de l'objet (son chemin) dans PIQUET-DE-REVISION est la mme que dans REVISIONOPERATIONNELLE. Si c'est le cas, puisque les deux positions sont directement lies, effectuer la requte sur la position dans REVISION-OPERATIONNELLE. Sinon, la relation entre les deux n'tant pas tablie, renvoyer une erreur expliquant qu'aucune position viable n'a t trouve. On peut esprer qu'un jour Subversion sera plus flexible et saura mieux grer ce type de cas. Notez que mme quand vous ne spcifiez pas explicitement de piquet de rvision ni de numro de rvision oprationnelle, ils sont nanmoins prsents. Par dfaut, la valeur du piquet de rvision est BASE pour les lments de la copie de travail et HEAD pour les URL du dpt. Et quand aucune rvision oprationnelle n'est fournie, la valeur par
11

Au 15 de la rue du Chteau Rueil-Malmaison se trouve un muse d'histoire (consacr Josphine, pouse de Napolon). Cela nous a sembl appropri

71

Sujets avancs

dfaut est celle du piquet de rvision.

Supposons que nous ayons cr notre dpt il y a longtemps et que dans la rvision 1 nous ayons ajout notre premier rpertoire concept ainsi qu'un fichier IDEE, situ dans ce rpertoire, contenant la description du concept. Nous avons ensuite ajout et modifi de vritables lignes de code. la rvision 20, nous avons renomm ce rpertoire en frabnaggilywort. Lors de la rvision 27, nous dveloppons un nouveau concept et un nouveau rpertoire concept est cr pour l'hberger, avec un nouveau fichier IDEE pour le dcrire. Cinq ans et vingt mille rvisions passent, comme dans tout bon roman d'amour. A prsent, plusieurs annes plus tard, nous nous demandons quoi ressemblait le fichier IDEE en rvision 1. Mais Subversion a besoin de savoir si nous demandons quoi ressemble le fichier actuel tel qu'il tait lors de la rvision 1 ou si nous demandons le contenu du fichier concept/IDEE (quel qu'il soit) de la rvision 1. Ces questions ont certainement des rponses diffrentes et grce aux piquets de rvisions, nous pouvons poser ces deux questions. Pour obtenir le contenu du fichier IDEE actuel tel qu'il tait dans l'ancienne rvision, tapez : $ svn cat -r 1 concept/IDEE svn: Impossible de trouver la localisation dans le dpt de 'concept/IDEE' pour la rvision 1 Bien sr, dans cet exemple, le fichier IDEE actuel n'existait pas lors de la rvision 1, c'est pourquoi Subversion renvoie une erreur. La commande ci-dessus est un raccourci pour la notation plus longue qui explicite le piquet de rvision. La notation complte est donc : $ svn cat -r 1 concept/IDEE@BASE svn: Impossible de trouver la localisation dans le dpt de 'concept/IDEE' pour la rvision 1 On obtient le rsultat attendu. Le lecteur perspicace est certainement en train de se demander si la syntaxe des piquets de rvision ne pose pas de problmes pour les chemins ou les URL qui comportent dj le signe arobase. Aprs tout, comment svn peut-il savoir si nouveau@11 est le nom d'un rpertoire dans mon arborescence ou juste la syntaxe pour rvision 11 de nouveau ? Dieu merci, alors que svn opte par dfaut pour cette dernire hypothse, il existe une solution de contournement triviale : il suffit juste d'ajouter un signe arobase la fin du chemin, comme ceci : nouveau@11@. svn ne s'intresse qu'au dernier arobase de l'argument et il n'est pas considr comme illgal d'omettre le spcificateur de piquet de rvision aprs cet arobase. Cette solution de contournement s'applique mme aux chemins qui se terminent par arobase (utilisez nom-du-fichier@@ pour dsigner le fichier nom-du-fichier@. Posons maintenant l'autre question : dans la rvision 1, quel tait le contenu du fichier qui occupait l'adresse concept/IDEE ce moment l ? Nous allons utiliser explicitement un piquet de rvision pour nous aider : $ svn cat concept/IDEE@1 L'ide de ce projet est de fournir un logiciel qui peut frabber un naggily wort. Frabber les naggilys worts est particulirement difficile et ne pas le faire correctement aurait des consquences inimaginables. Nous devons donc utiliser des mcanismes de vrification des entres et des donnes du dernier cri. Remarquez que cette fois nous n'avons pas fourni de rvision oprationnelle. C'est parce que, quand aucune rvision oprationnelle n'est spcifie, Subversion considre que le numro de rvision oprationnelle est gal au piquet de rvision. Comme vous pouvez le constater, la rsultat de la commande semble tre correct. Le texte parle mme de "frabber les naggilys worts", ce qui laisse supposer que c'est certainement le fichier dcrivant le logiciel maintenant connu sous le nom de Frabnaggilywort. En fait, on peut le vrifier en combinant un piquet de rvision explicite et un numro de rvision oprationnelle explicite. Nous savons que dans HEAD, le projet Frabnaggilywort se situe dans le rpertoire frabnaggilywort. Nous spcifions donc que nous voulons voir quoi ressemblait le fichier frabnaggilywort/IDEE identifi dans HEAD au moment de la rvision 1. 72

Sujets avancs

$ svn cat -r 1 frabnaggilywort/IDEE@HEAD L'ide de ce projet est de fournir un logiciel qui peut frabber un naggily wort. Frabber les naggilys worts est particulirement difficile et ne pas le faire correctement aurait des consquences inimaginables. Nous devons donc utiliser des mcanismes de vrification des entres et des donnes du dernier cri. Vous pouvez aussi spcifier des piquets de rvision et des rvisions oprationnelles moins triviales. Par exemple, disons que frabnaggilywort a t effac de HEAD, mais nous savons qu'il existait en rvision 20 et nous voulons voir les diffrences entre la rvision 4 et la rvision 10 pour son fichier IDEE. Nous pouvons utiliser le piquet de rvision 20 en conjonction avec l'URL qu'avait le fichier frabnaggilywort/IDEE dans la rvision 20 et utiliser 4 et 10 pour spcifier l'intervalle de rvisions oprationnelles. $ svn diff -r 4:10 http://svn.red-bean.com/projets/frabnaggilywort/IDEE@20 Index: frabnaggilywort/IDEE =================================================================== --- frabnaggilywort/IDEE (rvision 4) +++ frabnaggilywort/IDEE (rvision 10) @@ -1,5 +1,5 @@ -L'ide de ce projet est de fournir un logiciel qui peut frabber un -naggily wort. Frabber les naggilys worts est particulirement difficile -et ne pas le faire correctement aurait des consquences inimaginables. -Nous devons donc utiliser des mcanismes de vrification des -entres et des donnes du dernier cri. +L'ide de ce projet est de fournir un logiciel client-serveur qui peut +frabber un naggily wort de manire distante. Frabber les naggilys worts +est particulirement difficile et ne pas le faire correctement aurait +des consquences inimaginables. Nous devons donc utiliser des mcanismes +de vrification des entres et des donnes du dernier cri. Heureusement, la plupart d'entre vous n'auront pas faire face des situations aussi complexes. Mais si jamais c'est le cas, rappelez-vous que les piquets de rvisions sont les informations complmentaires dont a besoin Subversion pour lever toute ambigut.

Listes de modifications
Il est trs courant pour un dveloppeur d'avoir effectuer, en mme temps, des modifications multiples n'ayant rien voir entre elles sur une portion de code donne. Ce n'est pas ncessairement la preuve d'une mauvaise gestion de son temps, ni d'une forme de masochisme numrique. Un ingnieur de dveloppement repre souvent des bogues annexes lorsqu'il travaille sur un morceau de code particulier. Ou alors c'est une fois rendu mi-chemin d'un changement important qu'il prend conscience que la solution qu'il a choisie serait mieux propage sous la forme de plusieurs units logiques plus petites, ces units pouvant se recouper, affecter des fichiers diffrents d'un mme module ou mme toucher des lignes diffrentes d'un mme fichier. Plusieurs mthodes sont disposition des dveloppeurs pour grer ces ensembles de modifications. Certains dveloppeurs utilisent des copies de travail spares, du mme dpt, pour y conserver les progrs faits pour chaque changement. D'autres dveloppeurs choisissent de crer au sein du dpt des branches fonctionnelles dure de vie trs courte et d'utiliser une unique copie de travail qu'ils feront pointer selon les besoins du moment vers une branche de ce type ou vers une autre. Enfin, d'autres dveloppeurs utilisent les outils diff et patch pour sauvegarder et restaurer des changements non propags sur les fichiers touchs par les modifications. Chacune de ces mthodes a des avantages et des inconvnients et, en gnral, le dtail des changements effectuer influence fortement le choix de la mthode utilise pour les distinguer. Subversion 1.5 a introduit une nouvelle fonctionnalit, les listes de modifications, qui vient s'ajouter aux mthodes mentionnes ci-dessus. Les listes de modifications sont en gros des tiquettes arbitraires (une au plus par fichier pour l'instant) attaches des fichiers de la copie de travail dans le seul but de regrouper plusieurs fichiers ensemble. Les utilisateurs de bon nombre de logiciels fournis par Google sont dj habitus ce concept. Dans Gmail [http://mail.google.com/], vous associez des tiquettes arbitraires des e-mails et plusieurs e-mails peuvent tre considrs comme faisant partie du mme groupe s'ils partagent une tiquette donne. Ds lors, ne voir qu'un groupe d'e-mails portant la mme tiquette n'est plus qu'un simple jeu d'affichage. De nombreux autres sites web 2.0 possdent des mcanismes similaires. Prenez par exemple les tags ( tiquette en anglais) utiliss sur des sites comme YouTube [http://www.youtube.com/] ou Flickr [http://www.flickr.com/], les catgories utilises pour regrouper les articles de blogs, etc. Aujourd'hui les gens ont compris que l'organisation des 73

Sujets avancs

donnes est essentielle et la faon dont ces donnes sont organises doit tre flexible. Le vieux paradigme des rpertoires et des fichiers est bien trop rigide pour certaines applications. Cette fonctionnalit de Subversion vous permet de crer des listes de modifications en tiquetant les fichiers que vous voulez inclure, de supprimer ces tiquettes et de limiter le rayon d'action des sous-commandes aux seuls fichiers qui portent l'tiquette donne. Dans ce paragraphe, nous allons voir en dtails comment accomplir ces actions.

Cration et modification d'une liste de modifications


Vous pouvez crer, modifier et supprimer des listes de modifications en utilisant la commande svn changelist. Plus prcisment, vous pouvez utiliser cette commande pour activer ou dsactiver l'association d'une liste de modifications avec un fichier donn de la copie de travail. La cration d'une liste de modifications a lieu la premire fois que vous tiquetez un fichier avec ce nom de liste ; elle n'est supprime que quand vous effacez l'tiquette du dernier fichier qui la portait. Examinons un cas concret pour illustrer ces notions. Harry est en train de corriger des bogues dans le module de logique mathmatique de l'application calculatrice . Son travail l'amne modifier deux fichiers : $ svn status M entier.c M ops-math.c $ En testant son correctif, Harry s'aperoit que ses modifications lui indiquent qu'un bogue collatral existe au sein de la logique de l'interface utilisateur, situe dans le fichier bouton.c. Harry dcide alors qu'il va aussi corriger ce bogue, dans une propagation spare de ses propres correctifs mathmatiques. Dans une copie de travail de petite taille, ne contenant qu'une poigne de fichiers, et pour juste quelques modifications logiques, Harry pourrait probablement grer mentalement ces deux ensembles logiques de modifications sans le moindre problme. Mais aujourd'hui il a dcid qu'il allait utiliser les listes de modifications de Subversion, pour faire une faveur aux auteurs de ce livre. Harry commence par crer une premire liste de modifications et y associe les deux premiers fichiers qu'il a dj modifi. Pour ce faire, il utilise la commande svn changelist afin d'associer le mme nom arbitraire de liste de modifications aux deux fichiers : $ svn changelist correctifs-maths entier.c ops-math.c Le chemin 'entier.c' fait maintenant partie de la liste de changement 'correctifs-maths'. Le chemin 'ops-math.c' fait maintenant partie de la liste de changement 'correctifs-maths'. $ svn status --- Liste de changements 'correctifs-maths' : M entier.c M ops-math.c $ Comme vous pouvez le constater, le rsultat de svn status reflte bien ce nouvel ensemble. Harry se lance alors dans la correction du problme d'interface graphique collatral. Puisqu'il sait quel fichier il va modifier, il associe galement ce chemin une liste de modifications. Mais malencontreusement Harry associe ce troisime fichier la mme liste de modifications que les deux premiers : $ svn changelist correctifs-maths bouton.c Le chemin 'bouton.c' fait maintenant partie de la liste de changement 'correctifs-maths'. $ svn status --- Liste de changements 'correctifs-maths' : bouton.c M entier.c M ops-math.c 74

Sujets avancs

$ Par chance, Harry prend conscience de son erreur. Deux options se prsentent alors lui. Il peut supprimer l'association de bouton.c avec la liste de modifications, puis lui associer un nouveau nom de liste de modifications : $ svn changelist --remove bouton.c Le chemin 'bouton.c' n'est plus associ une liste de changements. $ svn changelist correctifs-graphiques bouton.c Le chemin 'bouton.c' fait maintenant partie de la liste de changement 'correctifs-graphiques'. $ Ou alors il peut sauter l'tape de suppression et juste associer un nouveau nom de liste de modifications bouton.c. Dans ce cas, Subversion signale Harry que bouton.c va tre supprim de la premire liste de modifications : $ svn changelist correctifs-graphiques bouton.c svn: avertissement : Retrait de 'bouton.c' de la liste de changements (changelist) 'correctifs-maths'. Le chemin 'bouton.c' fait maintenant partie de la liste de changement 'correctifs-graphiques'. $ svn status --- Liste de changements 'correctifs-graphiques' : bouton.c --- Liste de changements 'correctifs-maths' : M entier.c M ops-maths.c $ Harry dispose donc prsent de deux listes de modifications distinctes dans sa copie de travail et svn status prsente ses rsultats en les regroupant par liste de modifications. Notez que bien qu'Harry n'ait pas encore modifi bouton.c, celui-ci est quand mme mentionn par svn status car une liste de modifications lui est associe. Les listes de modifications peuvent tre associes, ou enleves, aux fichiers tout moment, indpendamment du fait que ces fichiers contiennent des modifications locales ou pas. Harry rgle maintenant le problme de l'interface graphique dans bouton.c. $ svn status --- Liste de changements 'correctifs-graphiques': M bouton.c --- Liste de changements 'correctifs-maths': M entier.c M ops-math.c $

Listes de modifications : des filtres pour vos oprations


Le regroupement visuel qu'Harry constate en sortie de svn status, comme indiqu prcdemment, est intressant d'un point de vue esthtique, mais pas vraiment utile. La commande status n'est qu'une des commandes qu'il est susceptible de lancer sur sa copie de travail. Heureusement, bon nombre des autres oprations de Subversion sont capables d'agir sur les listes de modifications grce l'option --changelist. Quand l'option --changelist est prsente, les commandes Subversion limitent leur champ d'action aux fichiers auxquels est associ le nom de liste de modifications donn. Si Harry veut voir quels changements il a effectu sur les fichiers de sa liste correctifs-maths, il peut lister explicitement les fichiers faisant partie de cette liste de modifications avec la commande svn diff. 75

Sujets avancs

$ svn diff entier.c ops-math.c Index: entier.c =================================================================== --- entier.c (rvision 1157) +++ entier.c (copie de travail) Index: ops-math.c =================================================================== --- ops-math.c (rvision 1157) +++ ops-math.c (copie de travail) $ Cette mthode fonctionne correctement pour un petit nombre de fichiers, mais qu'en est-il si Harry a modifi une vingtaine ou une trentaine de fichiers ? Fournir la liste de tous ces fichiers serait assez pnible. Mais puisqu'il utilise les listes de modifications, Harry peut dsormais viter de lister explicitement tous les fichiers et ne donner la place que le nom de la liste de modifications : $ svn diff --changelist correctifs-maths Index: entier.c =================================================================== --- entier.c (rvision 1157) +++ entier.c (copie de travail) Index: ops-math.c =================================================================== --- ops-math.c (rvision 1157) +++ ops-math.c (copie de travail) $ Et au moment de lancer la propagation, Harry peut nouveau se servir de l'option --changelist pour limiter le rayon d'action de la propagation aux fichiers de sa liste de modifications. Par exemple, il peut propager ses changements concernant l'interface graphique en lanant : $ svn ci -m "Corrig un bug de l'interface graphique dcouvert en travaillant sur la logique mathmatique." \ --changelist correctifs-graphiques Envoi bouton.c Transmission des donnes . Rvision 1158 propage. $ En fait, la commande svn commit accepte une deuxime option lie aux listes de modifications : --keep-changelists. Normalement, l'association des listes de modifications avec les fichiers est supprime ds que ceux-ci ont t propags. Mais si l'option --keep-changelists est ajoute sur la ligne de commande, les fichiers propags (qui ne sont donc plus dans l'tat modifi) restent associs aux listes de modifications en question. Dans tous les cas, propager des fichiers faisant partie d'une liste de modification laisse les autres listes de modifications intactes. $ svn status --- Liste de changements 'correctifs-maths': M entier.c M ops-math.c $

76

Sujets avancs

L'option --changelist agit comme un filtre sur les cibles des commandes Subversion et n'ajoute jamais de cible une opration. Par exemple, lors d'une opration de propagation lance via svn commit / chemin/vers/rep, la cible est le rpertoire /chemin/vers/rep et ses fils (avec une profondeur infinie). Si ensuite vous ajoutez une option spcifiant une liste de modifications cette commande, seuls les fichiers se trouvant sous le chemin /chemin/vers/rep et associs cette liste de modifications sont pris en compte en tant que cibles de la propagation ; ne sont pas inclus les fichiers situs ailleurs (tels ceux sous / chemin/vers/autre-rep), quelle que soit la liste de modifications laquelle ils appartiennent, mme s'il font partie de la mme copie de travail que la ou les cibles de l'opration. Mme la commande svn changelist accepte l'option --changelist. Ceci vous permet de renommer ou supprimer facilement une liste de modifications : $ svn changelist bogues-maths --changelist correctifs-maths --depth infinity . svn: avertissement : Retrait de 'entier.c' de la liste de changements (changelist) 'correctifs-maths'. Le chemin 'entier.c' fait maintenant partie de la liste de changement 'bogues-maths'. svn: avertissement : Retrait de 'ops-math.c' de la liste de changements (changelist) 'correctifs-maths'. Le chemin 'ops-math.c' fait maintenant partie de la liste de changement 'bogues-maths'. $ svn changelist --remove --changelist bogues-maths --depth infinity . Le chemin 'entier.c' n'est plus associ une liste de changements. Le chemin 'ops-math.c' n'est plus associ une liste de changements. $ Enfin, vous pouvez spcifier plusieurs instances de l'option --changelist dans une mme ligne de commande. Ceci limite le champ d'action de votre opration aux fichiers faisant partie de toutes les listes de modifications spcifies.

Limitations des listes de modifications


La fonctionnalit de listes de modifications de Subversion est un outil trs pratique pour crer des groupes de fichiers au sein de la copie de travail, mais elle a cependant quelques limitations. Les listes de modifications sont des objets contenus l'intrieur d'une copie de travail, ce qui signifie que les associations entre fichiers et listes de modifications ne peuvent pas tre propages vers le dpt, ni partages avec d'autres utilisateurs. Les listes de modifications ne peuvent tre associes qu' des fichiers, Subversion n'offre pas cette possibilit pour les rpertoires. Enfin, vous pouvez avoir au plus un nom de liste de modifications associ un fichier donn. C'est ici que l'analogie avec les articles de blogs et les services d'tiquetage de photos en ligne part en fume. S'il vous faut associer un fichier plusieurs listes de modifications, vous tes coinc.

Modle de communication rseau


un moment ou un autre, vous aurez besoin de comprendre comment le client Subversion communique avec le serveur. La couche rseau de Subversion est abstraite, c'est--dire que les clients Subversion ont le mme comportement quel que soit le type de serveur auquel ils ont affaire. Qu'ils communiquent via le protocole HTTP (http://) avec un serveur HTTP Apache ou via le protocole Subversion (svn://) avec svnserve, le modle de communication rseau est le mme. Dans cette section, nous expliquons les fondamentaux de ce modle de communication rseau, y compris la faon dont Subversion gre les authentifications et les autorisations.

Requtes et rponses
Le client Subversion passe la plupart de son temps grer des copies de travail. Cependant, quand il a besoin d'informations disponibles dans un dpt distant, il envoie une requte sur le rseau et le serveur lui rpond. Les dtails du protocole rseau sont cachs l'utilisateur : le client essaie d'accder une URL et, suivant le format de cette URL, utilise un protocole particulier pour contacter le serveur (voir URL du dpt). Tapez svn --version pour voir quels types d'URL et de protocoles sont utilisables par votre client.

77

Sujets avancs

Quand le serveur reoit une requte d'un client, il demande souvent au client de s'identifier. Il envoie un dfi d'authentification vers le client et le client rpond en fournissant les lments d'authentification au serveur. Une fois cette authentification termine, le serveur rpond la requte originale du client. Remarquez que ce fonctionnement est diffrent de celui de CVS o le client envoie systmatiquement au pralable ses identifiants de connexion (procdure de log in ), avant mme de formuler la moindre requte. Dans Subversion, le serveur requiert explicitement l'authentification du client (par un dfi d'authentification) au moment appropri, au lieu que ce soit le client qui s'authentifie a priori. Certaines oprations sont donc effectues plus lgamment. Par exemple, si un serveur est configur pour laisser tout le monde accder au dpt en lecture, alors le serveur n'envoie jamais de dfi d'authentification quand un client tente un svn checkout. Si une requte d'un client conduit la cration d'une nouvelle rvision du dpt (par exemple un svn commit), alors Subversion utilise le nom d'utilisateur fourni lors de la phase d'authentification comme auteur de la rvision. C'est--dire que le nom d'utilisateur est stock dans la proprit svn:author de la nouvelle rvision (voir la section intitule Proprits dans Subversion ). Si le client n'a pas t authentifi (en d'autres termes, si le serveur n'a jamais envoy de dfi d'authentification), alors la proprit svn:author de la rvision est vide.

Mise en cache des lments d'authentification du client


Beaucoup de serveurs sont configurs pour demander une authentification chaque requte. Ce serait particulirement pnible pour les utilisateurs s'ils devaient taper leur mot de passe chaque fois. Heureusement, le client Subversion a une solution : la mise en cache sur le disque des lments d'authentification. Par dfaut, si le client en ligne de commande s'authentifie avec succs auprs d'un serveur, le client sauvegarde les lments d'authentification dans une zone prive propre l'utilisateur (~/.subversion/auth/ sur les systmes de type Unix ou %APPDATA%/Subversion/auth/ sur Windows) ; voir la section intitule Zone de configuration des excutables pour plus de dtails). Les lments d'authentification sont mis en cache sur le disque, classs suivant une combinaison du nom, du port et du domaine d'authentification du serveur. Quand le client reoit un dfi d'authentification, il regarde d'abord s'il dispose des lments appropris dans le cache disque de l'utilisateur. Si ce n'est pas le cas, ou si les lments conduisent un chec lors de la tentative d'authentification, le client demande alors (c'est son comportement par dfaut) l'utilisateur les informations ncessaires. Ici, le lecteur soucieux de scurit va immdiatement commencer s'inquiter : Mettre en cache des mots de passe sur le disque ? Quelle horreur ! Jamais ! Les dveloppeurs de Subversion reconnaissent le bien fond du problme et c'est pourquoi Subversion est capable de fonctionner avec les diffrents mcanismes offerts par le systme d'exploitation et l'environnement de travail pour minimiser les risques de fuites d'information. Voici ce que cela veut dire sur les plates-formes les plus courantes : Sur Windows 2000 et ses successeurs, le client Subversion utilise les services cryptographiques standards de Windows pour chiffrer le mot de passe sur le disque. Comme la cl de chiffrement est gre par Windows et qu'elle est associe l'identifiant de connexion de l'utilisateur, lui seul peut dchiffrer le mot de passe en cache. Notez que si le mot de passe de l'utilisateur est rinitialis par un administrateur, tous les mots de passe en cache deviennent indchiffrables. Le client Subversion agit comme s'ils n'existaient pas, en redemandant le mot de passe quand c'est ncessaire. De manire similaire, sur Mac OS X, le client Subversion stocke tous les mots de passe dans le jeton de connexion (gr par le service Keychain ), qui est protg par le mot de passe du compte utilisateur. La configuration des prfrences utilisateur peut imposer une politique plus stricte, comme par exemple demander le mot de passe du compte utilisateur chaque fois qu'un mot de passe Subversion est utilis. Pour les systmes de type Unix, il n'existe pas de standard de service de type Keychain . Cependant, la zone de cache auth/ est toujours protge par les droits systme et seul l'utilisateur (le propritaire) des donnes peut les lire. Les droits sur les fichiers fournis par le systme d'exploitation protgent les mots de passe. Bien sr, si vous tes compltement paranoaque, aucun de ces mcanismes n'est parfait. Ainsi, pour ceux qui sont prts sacrifier le confort d'utilisation au profit de la scurit absolue, Subversion fournit de nombreuses faons de dsactiver le systme de cache d'authentification. Pour dsactiver le systme de cache pour une seule commande, utilisez l'option --no-auth-cache : $ svn commit -F log_msg.txt --no-auth-cache Domaine d'authentification : <svn://hote.exemple.com:3690> exemple de domaine Nom d'utilisateur : paul 78

Sujets avancs

Mot de passe pour 'paul' : Ajout nouveau_fichier Transmission des donnes . Rvision 2324 propage. # le mot de passe n'a pas t mis dans le cache, donc la deuxime propagation # nous redemandera le mot de passe $ svn delete nouveau_fichier $ svn commit -F nouveau_msg.txt Domaine d'authentification : <svn://hote.exemple.com:3690> exemple de domaine Nom d'utilisateur : paul Autrement, si vous voulez dsactiver la mise en cache des lments d'authentification de manire permanente, vous pouvez diter le fichier config de votre zone de configuration et mettre l'option store-auth-creds no. La mise en cache des lments d'authentification est alors dsactive pour toutes les commandes Subversion que vous effectuez sur cet ordinateur. Ceci peut tre tendu l'ensemble des utilisateurs de l'ordinateur en modifiant la configuration globale de Subversion (voir la section intitule Agencement de la zone de configuration ). [auth] store-auth-creds = no Il arrive que les utilisateurs veuillent effacer certains mots de passe du cache disque. Pour ce faire, vous devez vous rendre dans la zone auth/ et effacer manuellement le fichier de cache appropri. Les lments d'authentification sont mis en cache dans des fichiers individuels ; si vous affichez chaque fichier, vous voyez des cls et des valeurs. La cl svn:realmstring dcrit le domaine du serveur auquel est associ le fichier : $ ls ~/.subversion/auth/svn.simple/ 5671adf2865e267db74f09ba6f872c28 3893ed123b39500bca8a0b382839198e 5c3c22968347b390f349ff340196ed39 $ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28 K 8 username V 3 paul K 8 password V 4 blah K 15 svn:realmstring V 45 <https://svn.domaine.com:443> Dpt de Paul END Une fois le bon fichier trouv, effacez-le. Un dernier mot sur la faon dont svn gre l'authentification, avec un zoom sur les options --username et --password. Beaucoup de sous-commandes du client acceptent ces options, mais il est important de comprendre que l'utilisation de ces options n'envoie pas automatiquement les lments d'authentification au serveur. Comme vu prcdemment, le serveur demande explicitement l'authentification au client quand il estime que c'est ncessaire ; le client ne les envoie pas sa convenance. Mme si un nom d'utilisateur et/ou un mot de passe sont passs en option, ils ne sont envoys au serveur que si celui-ci les demande. Ces options sont couramment utilises pour s'authentifier sous un nom d'utilisateur diffrent de celui que Subversion aurait choisi par dfaut (comme votre nom de compte systme), ou quand on ne veut pas de commande interactive (par exemple, utilisation de la commande svn dans un script).

79

Sujets avancs

Une erreur classique consiste mal configurer un serveur de telle sorte qu'il n'envoie jamais de dfi d'authentification. Quand les utilisateurs passent les options --username et --password, ils sont surpris de voir qu'elles ne sont jamais utilises, c'est--dire que les nouvelles rvisions semblent toujours avoir t propages de faon anonyme ! En rsum, voici comment un client Subversion se comporte quand il reoit un dfi d'authentification : 1. D'abord, le client vrifie si l'utilisateur a spcifi explicitement des lments d'authentification dans la ligne de commande (options --username et/ou --password). Si c'est le cas, le client essaie de s'authentifier auprs du serveur avec ces lmnts. 2. Si les lments d'authentification ne sont pas passs en ligne de commande, ou si ceux qui ont t fournis ne sont pas valides, le client regarde dans la zone auth/ s'il trouve le nom, le port et le domaine du serveur pour voir si l'utilisateur a dj les lments d'authentification en cache. Si c'est le cas, il essaie d'utiliser ces lments pour s'authentifier. 3. Finalement, si les mcanismes prcdents ont abouti des checs d'authentification sur le serveur, le client se rsout demander les lments l'utilisateur ( moins qu'il ne lui ait t indiqu de ne pas le faire via l'option -non-interactive ou son quivalent spcifique au client). Si le client russit s'authentifier par l'une ou l'autre de ces mthodes, il essaie de mettre en cache les lments d'authentification sur le disque ( moins que cette fonctionnalit ne soit dsactive, comme indiqu auparavant).

Rsum
Aprs avoir lu ce chapitre, vous devez dsormais avoir une bonne comprhension de certaines fonctionnalits de Subversion qui, bien qu'elles ne servent pas systmatiquement chaque utilisation du systme de gestion de versions, peuvent rendre de grands services. Ne vous arrtez pas l ! Lisez le chapitre suivant, o vous dcouvrirez les branches, les tiquettes et les fusions. Vous aurez alors la matrise quasi-complte du client Subversion. Bien que nos avocats ne nous autorisent pas vous promettre quoi que ce soit, ces connaissances supplmentaires feront dj de vous quelqu'un de bien plus branch. 12

12

Aucun achat ncessaire. Certaines conditions s'appliquent. Aucune garantie, ni explicite ni implicite, n'est fournie. Le kilomtrage peut varier.

80

Chapitre 4. Gestion des branches


#### (C'est sur le Tronc qu'un gentleman travaille.) Confucius La cration, l'tiquetage et la fusion de branches sont des concepts communs tous les systmes de gestion de versions. Si vous n'tes pas familier avec elles, nous fournissons dans ce chapitre une bonne introduction ces ides. Si vous tes familier avec elles, vous devriez, avec un peu de chance, tre intress par la faon dont Subversion les met en pratique. La gestion des branches est un lment fondamental de la gestion de versions. Si vous comptez utiliser Subversion pour grer vos donnes, c'est une fonctionnalit dont vous ne pourrez plus vous passer. Ce chapitre suppose que vous tes dj familier avec les notions de bases de Subversion (Chapitre 1, Notions fondamentales).

Qu'est-ce qu'une branche ?


Supposons que votre travail soit de maintenir un document pour une division de votre entreprise, un manuel par exemple. Un beau jour, une autre division vous demande le mme manuel, mais avec quelques parties modifies spcialement pour elle, puisqu'elle fait les choses lgrement diffremment. Que faites-vous dans cette situation ? Tout naturellement, vous crez une seconde copie du document et commencez maintenir les deux copies sparment. Puis, quand chaque division vous demande de faire des petites modifications, vous les incorporez dans une copie ou dans l'autre. Vous voulez souvent faire la mme modification dans les deux copies. Par exemple, si vous dcouvrez une coquille dans la premire copie, il est trs probable que la mme coquille existe dans la deuxime copie. Les deux documents sont presque identiques, aprs tout ; ils ne diffrent qu'en quelques points mineurs et spcifiques. Voil le concept de branche, c'est--dire une ligne de dveloppement qui existe indpendamment d'une autre ligne, mais partage cependant une histoire commune avec elle, si vous remontez suffisamment loin en arrire dans le temps. Une branche commence toujours sa vie en tant que copie de quelque chose, puis diffre partir de l, selon une histoire qui lui est propre (voir la Figure 4.1, Branches de dveloppement ).

Figure 4.1. Branches de dveloppement

81

Gestion des branches

Subversion possde des commandes pour vous aider maintenir des branches parallles de vos fichiers et rpertoires. Il vous permet de crer des branches en faisant des copies de vos donnes et se souvient que les copies sont lies les unes aux autres. Il vous aide aussi dupliquer les modifications d'une branche vers une autre. Enfin, il permet que des portions de votre copie de travail correspondent diffrentes branches, afin que vous puissiez mlanger diffrentes lignes de dveloppement dans votre travail quotidien.

Utilisation des branches


Rendu ce chapitre, vous devriez avoir compris que chaque propagation cre une arborescence de fichiers entirement nouvelle (appele rvision ) dans le dpt. Si ce n'est pas le cas, retournez vous informer sur les rvisions dans la section intitule Rvisions . Pour ce chapitre, nous reprendrons le mme exemple qu'au Chapitre 1, Notions fondamentales. Souvenez-vous que votre collaboratrice Sally et vous partagez un dpt qui contient deux projets, paint et calc. Notez cependant que dans la Figure 4.2, Structure initiale du dpt , le dossier de chaque projet contient dsormais des sous-dossiers nomms trunk et branches. Les raisons de cette arborescence apparatront bientt clairement.

Figure 4.2. Structure initiale du dpt

82

Gestion des branches

Comme avant, supposons que Sally et vous avez tous deux une copie de travail du projet calc . Plus spcifiquement, vous avez chacun une copie de travail de /calc/trunk. Tous les fichiers du projet sont dans ce sous-dossier plutt que dans / calc lui-mme, parce que votre quipe a dcid que la ligne principale de dveloppement du projet allait se situer dans / calc/trunk. Disons que l'on vous a attribu la tche d'implmenter une fonctionnalit du logiciel qui prendra longtemps crire et touchera tous les fichiers du projet. Le problme immdiat est que vous ne voulez pas dranger Sally, qui est en train de corriger des bogues mineurs ici et l. Elle a besoin que la dernire version du projet (dans /calc/trunk) demeure en permanence utilisable. Si vous commencez propager des changements petit petit, vous allez srement rendre les choses difficiles pour 83

Gestion des branches

Sally (ainsi que pour d'autres membres de l'quipe). Une stratgie possible est de vous isoler : vous pouvez arrter de partager des informations avec Sally pendant une semaine ou deux. C'est--dire commencer modifier et rorganiser les fichiers dans votre copie de travail, mais sans effectuer de propagation ni de mise jour avant que vous n'ayez compltement termin la tche. Cette stratgie comporte certains risques. Premirement, ce n'est pas sans danger. La plupart des gens aiment propager leurs modifications frquemment, au cas o leur copie de travail aurait un accident. Deuximement, ce n'est pas trs flexible. Si vous travaillez sur diffrents ordinateurs (vous avez peut-tre une copie de travail de /calc/trunk sur deux machines diffrentes), vous aurez besoin de transfrer manuellement vos changements entre les deux, ou bien de travailler sur une seule machine. De la mme faon, il est difficile de partager vos changements en cours avec quelqu'un d'autre. Une des bonnes pratiques du monde du dveloppement logiciel est de permettre vos pairs de passer votre travail en revue au fur et mesure. Si personne n'a accs vos propagations intermdiaires, vous vous coupez d'ventuelles critiques et risquez de partir dans une mauvaise direction pendant des semaines avant que quelqu'un ne s'en aperoive. Enfin, quand vous en aurez fini avec tous vos changements, vous pourriez avoir du mal fusionner votre travail avec le code du reste de l'quipe. Sally (et les autres) peuvent avoir apport de nombreux autres changements au dpt, changements qui seront difficiles incorporer dans votre copie de travail, notamment si vous lancez svn update aprs des semaines d'isolation. Une solution bien meilleure est de crer votre propre branche, ou ligne de dveloppement, dans le dpt. Ceci vous permettra de sauvegarder frquemment votre travail un peu boiteux sans interfrer avec vos collaborateurs ; vous pourrez toutefois partager une slection d'informations avec eux. Vous dcouvrirez comment tout cela fonctionne exactement au fur et mesure de ce chapitre.

Cration d'une branche


Crer une branche est trs simple : il s'agit juste de faire une copie du projet dans le dpt avec la commande svn copy. Subversion est capable de copier non seulement de simples fichiers, mais aussi des dossiers entiers. Dans le cas prsent, vous voulez faire une copie du dossier /calc/trunk. O doit rsider la nouvelle copie ? L o vous le dsirez, cette dcision faisant partie de la gestion du projet. Supposons que votre quipe ait pour convention de crer les branches dans la zone / calc/branches du dpt et que vous vouliez nommer votre branche ma-branche-calc. Vous crez alors un nouveau dossier, /calc/branches/ma-branche-calc, qui commence ainsi sa vie en tant que copie de /calc/trunk. Vous avez peut-tre dj utilis svn copy pour copier un fichier vers un autre l'intrieur d'une copie de travail. Mais il peut aussi tre utilis pour effectuer une copie distante entirement l'intrieur du dpt. Il suffit de copier une URL vers une autre : $ svn copy http://svn.exemple.com/depot/calc/trunk \ http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Cration d'une branche prive partir de /calc/trunk." Rvision 341 propage. Cette commande entrane une opration quasi-instantane dans le dpt, crant un nouveau dossier la rvision 341. Ce nouveau dossier est une copie de /calc/trunk, comme l'illustre la Figure 4.3, Dpt avec nouvelle copie 1. Bien qu'il soit aussi possible de crer une branche en utilisant svn copy pour dupliquer un dossier l'intrieur de la copie de travail, cette technique n'est pas recommande. Elle peut s'avrer assez lente, en fait ! Copier un dossier ct client est une opration linaire en terme de dure, puisque chaque fichier et chaque dossier doit tre dupliqu sur le disque local. Copier un dossier sur le serveur, par contre, est une opration dont la dure est constante et c'est ainsi que la plupart des gens crent des branches.

Figure 4.3. Dpt avec nouvelle copie

Subversion n'accepte pas les copies entre des dpts distincts. Quand vous utilisez des URLs avec svn copy et svn move, vous ne pouvez copier que des lments faisant partie du mme dpt.

84

Gestion des branches

Des copies peu coteuses

85

Gestion des branches

Le dpt Subversion a un design particulier. Quand vous copiez un dossier, il n'y a pas s'en faire pour la taille du dpt : en fait Subversion ne duplique aucune donne. Au lieu de a, il cre une nouvelle entre de dossier qui pointe vers une arborescence existante. Si vous tes un utilisateur expriment d'Unix, vous reconnatrez l le concept de lien matriel ( hard link ). Au fur et mesure des modifications faites aux fichiers et dossiers sous le dossier copi, Subversion continue employer ce concept de lien matriel quand il le peut. Il duplique les donnes seulement s'il est ncessaire de lever l'ambigut entre diffrentes versions d'objets. C'est pourquoi vous entendrez souvent les utilisateurs de Subversion parler de copies peu coteuses (cheap copies en anglais). Peu importe la taille du dossier, la dure de la copie est constante et trs faible, tout comme l'espace disque ncessaire. En fait, cette fonctionnalit est la base du fonctionnement des propagations dans Subversion : chaque rvision est une copie peu coteuse de la rvision prcdente, avec juste quelques lments modifis l'intrieur (pour en savoir plus ce sujet, visitez le site web de Subversion et lisez les paragraphes concernant la mthode bubble up dans les documents de conception de Subversion). Bien sr, cette mcanique interne de copie et de partage des donnes est transparente pour l'utilisateur, qui n'y voit que de simples copies d'arborescences. Le point essentiel ici est que les copies sont peu coteuses, aussi bien en temps qu'en espace disque. Si vous crez une branche entirement l'intrieur du dpt (en lanant svn copy URL1 URL2), c'est une opration rapide, dure constante. Crez des branches aussi souvent que vous le souhaitez.

Travail sur votre branche


Maintenant que vous avez cr votre branche du projet, vous pouvez extraire une nouvelle copie de travail et commencer l'utiliser : $ svn checkout http://svn.exemple.com/depot/calc/branches/ma-branche-calc A ma-branche-calc/Makefile A ma-branche-calc/entier.c A ma-branche-calc/bouton.c Rvision 341 extraite. Cette copie de travail n'a rien de spciale ; elle correspond juste un dossier diffrent du dpt. Cependant, quand vous propagerez vos modifications, Sally ne les verra pas quand elle effectuera une mise jour, car sa copie de travail correspond calc/trunk (pensez bien lire la section intitule Parcours des branches plus loin dans ce chapitre : la commande svn switch est une mthode alternative pour crer une copie de travail d'une branche). Imaginons qu'une semaine passe et que les propagations suivantes ont lieu : Vous modifiez /calc/branches/ma-branche-calc/bouton.c, ce qui cre la rvision 342. Vous modifiez /calc/branches/ma-branche-calc/entier.c, ce qui cre la rvision 343. Sally modifie /calc/trunk/entier.c, ce qui cre la rvision 344. prsent, deux lignes de dveloppement indpendantes (voir la Figure 4.4, Historique des branches d'un fichier ) existent pour entier.c.

Figure 4.4. Historique des branches d'un fichier

86

Gestion des branches

Les choses deviennent intressantes quand on regarde l'historique des modifications apportes votre copie de entier.c : $ pwd /home/utilisateur/ma-branche-calc $ svn log -v entier.c -----------------------------------------------------------------------r343 | utilisateur | 2002-11-07 15:27:56 -0600 (jeu. 07 nov. 2002) | 2 lignes Chemins modifis : M /calc/branches/ma-branche-calc/entier.c * entier.c: machin le bidule.

-----------------------------------------------------------------------r341 | utilisateur | 2002-11-03 15:27:56 -0600 (jeu. 07 nov. 2002) | 2 lignes Chemins modifis : A /calc/branches/ma-branche-calc (from /calc/trunk:340) Cration d'une branche prive partir de /calc/trunk. -----------------------------------------------------------------------r303 | sally | 2002-10-29 21:14:35 -0600 (mar. 29 oct. 2002) | 2 lignes Chemins modifis : M /calc/trunk/entier.c * entier.c: modifi une docstring.

-----------------------------------------------------------------------r98 | sally | 2002-02-22 15:35:29 -0600 (ven. 22 fev. 2002) | 2 lignes Chemins modifis : A /calc/trunk/entier.c * entier.c: ajout du fichier dans ce projet. -----------------------------------------------------------------------Notez bien que Subversion reprend tout l'historique du entier.c de votre branche travers le temps, remontant mme au del du point o il a t copi. Il liste la cration d'une branche en tant qu'lment de l'historique, parce qu'entier.c a t copi implicitement lorsque calc/trunk tout entier a t copi. Maintenant regardez ce qui se passe quand Sally lance la 87

Gestion des branches

mme commande sur sa copie du fichier : $ pwd /home/sally/calc $ svn log -v entier.c -----------------------------------------------------------------------r344 | sally | 2002-11-07 15:27:56 -0600 (jeu. 07 nov. 2002) | 2 lignes Chemins modifis : M /calc/trunk/entier.c * entier.c: corrig un ensemble de coquilles.

-----------------------------------------------------------------------r303 | sally | 2002-10-29 21:14:35 -0600 (mar. 29 oct. 2002) | 2 lignes Chemins modifis : M /calc/trunk/entier.c * entier.c: modifi une docstring.

-----------------------------------------------------------------------r98 | sally | 2002-02-22 15:35:29 -0600 (ven. 22 fev. 2002) | 2 lignes Chemins modifis : A /calc/trunk/entier.c * entier.c: ajout du fichier dans ce projet.

-----------------------------------------------------------------------Sally voit la modification due sa propre rvision 344, mais pas le changement que vous avez effectu dans la rvision 343. Pour Subversion, ces deux propagations ont touch des fichiers diffrents dans des dossiers distincts. Nanmoins, Subversion indique bien que les deux fichiers partagent une histoire commune. Avant que la copie de branche n'ait t faite en rvision 341, les fichiers ne faisaient qu'un. C'est pourquoi Sally et vous voyez tous les deux les modifications apportes en rvisions 303 et 98.

Gestion des branches par Subversion : notions cl


Il y a deux leons importantes retenir de ce paragraphe. Premirement, Subversion n'a pas de notion interne de branche il sait seulement faire des copies. Quand vous copiez un dossier, le dossier qui en rsulte n'est une branche que parce que vous le considrez comme tel. Vous aurez beau envisager ce dossier diffremment ou le traiter diffremment, pour Subversion c'est juste un dossier ordinaire auquel sont associes des informations extra-historiques. Deuximement, cause de ce mcanisme de copie, les branches de Subversion existent en tant que dossiers classiques du systme de fichiers du dpt. En cela, Subversion diffre des autres systmes de gestion de versions, o les branches sont dfinies par l'ajout d' tiquettes extra-dimensionnelles des groupes de fichiers. L'emplacement du dossier de votre branche importe peu Subversion. La plupart des quipes ont pour convention de placer toutes les branches dans un dossier / branches, mais vous tes libre d'inventer la convention qui vous plat.

Fusions : pratiques de base


Dsormais, Sally et vous travaillez sur des branches parallles du projet : vous travaillez sur une branche prive et Sally travaille sur le tronc, la branche de dveloppement principale. Pour les projets qui ont un grand nombre de contributeurs, il est d'usage que la plupart des gens aient des copies de travail du tronc. Ds que quelqu'un doit faire des modifications de longue haleine, susceptibles de perturber le tronc, une procdure standard est qu'il cre une branche prive et qu'il y propage les modifications jusqu' ce que tout le travail soit termin. Bref, la bonne nouvelle est que Sally et vous n'empitez pas l'un sur l'autre. La mauvaise nouvelle est qu'il est trs facile de driver chacun de son ct. Rappelez-vous qu'un des problmes li la stratgie d' isolement est que lorsque vous en aurez fini avec votre branche, il risque d'tre quasi impossible de refusionner vos modifications dans le tronc sans avoir faire face un grand nombre de conflits. la place, Sally et vous pourriez continuer de partager vos changements au fur et mesure de votre travail. C'est vous de 88

Gestion des branches

dcider quelles modifications valent la peine d'tre partages ; Subversion vous offre la possibilit de copier slectivement des modifications entre les branches. Et quand vous aurez tout fini dans votre branche, l'ensemble de vos modifications pourra tre recopi en entier vers le tronc. Dans la terminologie Subversion, l'action gnrale de rplication des modifications d'une branche vers une autre s'appelle la fusion et elle s'effectue l'aide de plusieurs excutions de la commande svn merge. Dans les exemples qui suivent, nous supposerons que le client et le serveur Subversion sont tous deux en version 1.5 (ou plus rcente). Si l'un ou l'autre sont en version plus ancienne, les choses sont plus compliques : le systme ne gre pas les changements de faon automatique et vous devrez utiliser des mthodes manuelles pnibles pour obtenir des rsultats similaires. Vous devrez en effet toujours utiliser la syntaxe dtaille de la fusion spcifiant l'ventail des rvisions rpliquer (voir la section intitule Syntaxe de la fusion : pour tout vous dire plus loin dans ce chapitre) et penser garder trace de ce qui a dj t fusionn et de ce qui ne l'a pas encore t. Pour cette raison, nous recommandons fortement de vous assurer que client et serveur sont au moins en version 1.5.

Ensembles de modifications
Avant que nous n'allions plus loin, nous devons vous avertir que les pages suivantes contiennent de nombreuses discussions portant sur les modifications . Beaucoup de gens ayant de l'exprience dans les systmes de gestion de versions utilisent le terme modifications et le terme ensemble de modifications de faon interchangeable et nous allons donc clarifier ce que Subversion entend par ensemble de modifications. Chacun semble avoir sa propre dfinition, variant lgrement, d'un ensemble de modifications, ou tout du moins a une attente diffrente quant leur traitement par le systme de gestion de versions. En ce qui nous concerne, disons qu'un ensemble de modifications n'est qu'un simple regroupement de modifications identifi par un nom unique. Les modifications peuvent inclure des changements textuels du contenu des fichiers, des modifications de l'arborescence ou des ajustements portant sur les mta-donnes. En langage plus courant, un ensemble de modifications n'est qu'un correctif avec un nom auquel vous pouvez vous rfrer. Dans Subversion, un numro de rvision globale N dsigne une arborescence dans le dpt : c'est ce quoi le dpt ressemblait aprs la N-ime propagation. C'est aussi le nom d'un ensemble de modifications implicite : si vous comparez l'arborescence N avec l'arborescence N#1, vous pouvez en dduire exactement le correctif qui a t propag. Pour cette raison, il est facile de se reprsenter une rvision N non seulement comme une arborescence, mais aussi comme un ensemble de modifications. Si vous utilisez un systme de gestion des incidents pour grer vos bogues, vous pouvez utiliser les numros de rvision pour vous rfrer des correctifs particuliers permettant de rsoudre des bogues par exemple, cet incident a t corrig par r9238 . Quelqu'un peut alors lancer svn log -r 9238 pour obtenir le dtail des modifications qui ont corrig le bogue et lancer svn diff -c 9238 pour voir le correctif lui-mme. De plus (comme nous le verrons bientt), la commande svn merge de Subversion est capable d'utiliser les numros de rvision. Vous pouvez fusionner des listes de modifications spcifiques d'une branche une autre en les nommant dans les paramtres de la fusion : donner comme argument -c 9238 svn merge fusionne la liste de modifications r9238 avec votre copie de travail.

Comment garder une branche synchronise


Continuons avec notre exemple prcdent et imaginons qu'une semaine a pass depuis que vous avez commenc travailler sur votre branche prive. Votre nouvelle fonctionnalit n'est pas encore termine, mais en mme temps vous savez que d'autres personnes de votre quipe ont continu faire des modifications importantes sur le /trunk du projet. Vous avez intrt recopier ces modifications dans votre propre branche, juste pour vous assurer qu'elles se combinent bien avec vos propres modifications. En fait, c'est l une bonne pratique : synchroniser frquemment votre branche avec la ligne de dveloppement principale permet d'viter les conflits surprise le jour o vous reversez vos modifications dans le tronc. Subversion connat l'historique de votre branche et sait quel moment elle s'est spare du tronc. Afin de rcuprer les modifications du tronc les plus rcentes et les plus importantes, assurez-vous en premier lieu que votre copie de travail est propre , c'est--dire que svn status ne liste aucune modification locale. Puis lancez juste : $ pwd /home/user/ma-branche-calc $ svn merge http://svn.exemple.com/depot/calc/trunk --- Fusion de r345 r356 dans '.': U bouton.c U entier.c

89

Gestion des branches

La syntaxe de base, svn merge URL, indique Subversion qu'il doit fusionner toutes les modifications rcentes depuis l'URL vers le rpertoire de travail actuel (qui est bien souvent la racine de votre copie de travail). Aprs l'excution de la commande de l'exemple prcdent, la copie de travail de votre branche contient de nouvelles modifications locales, ces changements tant des duplications de toutes les modifications qui ont eu lieu sur le tronc depuis que vous avez cr votre branche : $ svn status M . M bouton.c M entier.c Une fois rendu l, le plus sage est d'examiner attentivement les modifications avec svn diff et ensuite de compiler et de tester votre branche. Notez que le rpertoire de travail actuel ( . ) a aussi t modifi ; svn diff indique que sa proprit svn:mergeinfo a t cre ou modifie. Ceci est une mta-information importante lie la fusion, laquelle vous ne devriez pas toucher, puisqu'elle sera ncessaire aux futures commandes svn merge (nous en apprendrons plus sur cette mtadonne plus loin dans ce chapitre). Aprs avoir effectu la fusion, vous aurez peut-tre aussi besoin de rsoudre des conflits (comme vous le faites pour svn update) ou ventuellement d'effectuer de petites modifications afin que les choses fonctionnent correctement (souvenez-vous, ce n'est pas parce qu'il n'y a pas de conflits syntaxiques qu'il n'y a pas de conflits smantiques !). Si vous rencontrez de graves difficults, vous pouvez toujours annuler les modifications locales en lanant svn revert . -R (qui annule toutes les modifications locales) et entamer avec vos collgues une longue discussion sur le thme Qu'est-ce qui se passe ? . Par contre, si les choses se passent bien, vous pouvez propager ces modifications dans le dpt : $ svn commit -m "Fusionn les dernires modifications de trunk avec ma-branche-calc" Envoi . Envoi bouton.c Envoi entier.c Transmission des donnes .. Rvision 357 propage. prsent, votre branche prive est dsormais synchro avec le tronc, vous pouvez donc vous dtendre, sachant qu'en continuant votre travail en isolation, vous ne driverez pas trop loin de ce que les autres font. Pourquoi ne pas utiliser des correctifs de type patch la place ? Une question vous trotte peut-tre dans la tte, surtout si vous tes un utilisateur d'Unix : pourquoi s'embter utiliser svn merge ? Pourquoi ne pas tout simplement utiliser la commande patch du systme d'exploitation pour accomplir la mme tche ? Par exemple : $ cd ma-branche-calc $ svn diff -r 341:HEAD http://svn.exemple.com/depot/calc/tronc > fichierpatch $ patch -p0 < fichierpatch Patching file entier.c using Plan A... Hunk #1 succeeded at 147. Hunk #2 succeeded at 164. Hunk #3 succeeded at 241. Hunk #4 succeeded at 249. done Dans cet exemple, il n'y a pas vraiment de grande diffrence. Mais svn merge possde des fonctionnalits spcifiques qui surpassent le programme patch. Le format de fichier utilis par patch est assez limit ; il ne sait manipuler que les contenus de fichier. Il n'y a pas moyen de reprsenter des changements dans l'arborescence, tels que l'ajout, la suppression ou le renommage de fichiers ou de dossiers. Le programme patch n'est pas non plus capable de prendre en compte des modifications de proprits. Si Sally avait, par exemple, ajout un nouveau dossier, svn diff ne l'aurait pas mentionn du tout en sortie. Le rsultat de svn diff n'est qu'au format patch , il y a donc des concepts qu'il ne peut tout simplement pas exprimer.

90

Gestion des branches

La commande svn merge, par contre, peut grer des modifications dans l'arborescence et dans les proprits en les appliquant directement votre copie de travail. Et, ce qui est encore plus important, cette commande enregistre les modifications qui ont t dupliques vers votre branche de telle sorte que Subversion sait exactement quelles modifications existent dans chaque endroit (voir la section intitule Mergeinfo et aperus ). C'est une fonctionnalit cruciale qui rend la gestion des branches utilisable ; sans elle, les utilisateurs seraient forcs de conserver des notes manuelles relatant quelles listes de modifications ont t fusionnes (et lesquelles ne l'ont pas t).

Supposons qu'une autre semaine s'est coule. Vous avez propag des modifications supplmentaires dans votre branche et vos camarades ont galement continu amliorer le tronc. Une fois encore, vous aimeriez rpercuter les dernires modifications du tronc vers votre branche et ainsi tre synchro. Lancez juste la mme commande svn merge nouveau ! $ svn merge http://svn.exemple.com/depot/calc/trunk --- Fusion de r357 r380 dans '.': U bouton.c U Makefile A LISEZMOI Subversion sait quelles sont les modifications du tronc que vous avez dj rpercutes vers votre branche, il ne rpercute donc que les modifications que vous n'avez pas encore. Une fois de plus, vous devrez compiler, tester et propager les modifications locales votre branche. Cependant, que se passe-t-il quand vous finissez enfin votre travail ? Votre nouvelle fonctionnalit est termine et vous tes prt fusionner les changements de votre branche avec le tronc (pour que votre quipe puisse bnficier du fruit de votre travail). La procdure est simple. Premirement, synchronisez nouveau votre branche avec le tronc, comme vous le faites depuis le dbut : $ svn merge http://svn.exemple.com/repos/calc/tronc --- Fusion de r381 r385 dans '.': U bouton.c U LISEZMOI $ # compiler, tester, ... $ svn commit -m "Fusion finale des modifications du tronc dans ma-branche-calc." Envoi . Envoi bouton.c Envoi LISEZMOI Transmission des donnes .. Rvision 390 propage. prsent, utilisez svn merge pour rpercuter les modifications de votre branche sur le tronc. Vous avez alors besoin d'une copie de travail de /trunk qui soit jour. Vous pouvez vous la procurer soit en effectuant un svn checkout, soit en reprenant une vieille copie de travail du tronc, soit en utilisant svn switch (voir la section intitule Parcours des branches ). Quelle que soit la manire dont vous obtenez une copie de travail, souvenez-vous qu'une bonne mthode est d'effectuer la fusion dans une copie de travail qui n'a pas t modifie localement et qui a t mise jour rcemment (en d'autres termes, qui n'est pas un mlange de rvisions locales). Si votre copie de travail n'est pas propre comme expliqu l'instant, vous risquez de rencontrer des problmes facilement vitables lis des conflits et svn merge renverra probablement une erreur en retour. Une fois que vous avez une copie de travail propre du tronc, vous tes prt pour y fusionner votre branche : $ pwd /home/user/calc-tronc $ svn update # (s'assurer que la copie de travail est jour) la rvision 390. $ svn merge --reintegrate http://svn.exemple.com/depot/calc/branches/ma-branche-calc --- Fusionne toutes les modifications non fusionnes des URLs sources dans '.': U bouton.c 91

Gestion des branches

U U U

entier.c Makefile .

$ # compiler, tester, vrifier, ... $ svn commit -m "Fusionner ma-branche-calc dans le tronc !" Envoi . Envoi bouton.c Envoi entier.c Envoi Makefile Transmission des donnes .. Rvision 391 propage. Flicitations, votre branche a maintenant rintgr la ligne de dveloppement principale. Notez bien l'utilisation de l'option -reintegrate cette occasion. L'option est essentielle pour rpercuter les modifications d'une branche sur sa ligne de dveloppement d'origine, ne l'oubliez pas ! Elle est ncessaire car ce type de rintgration est un type de tche diffrent de ce que vous avez fait jusqu' prsent. Prcdemment, nous demandions svn merge de faire la liste des modifications ayant eu lieu dans une ligne de dveloppement (le tronc) et de les dupliquer vers une autre (votre branche). C'est assez simple raliser et chaque fois Subversion sait reprendre l o il s'tait arrt. Dans nos exemples prcdents, vous pouvez voir qu'il fusionne en premier les modifications 345:356 du tronc vers la branche ; ensuite il continue en fusionnant le groupe contigu immdiatement suivant, 356:380. Quand il effectue la synchronisation finale, il fusionne le groupe 380:385. Cependant, lors de la rintgration d'une branche dans le tronc, la logique sous-jacente est assez diffrente. Votre branche ddie est prsent un amoncellement de modifications provenant la fois du tronc et de votre branche prive et il n'y a donc pas de groupe de rvisions contigu recopier. En spcifiant l'option --reintegrate, vous demandez explicitement Subversion de ne recopier que les modifications spcifiques votre branche (et en fait il le fait en comparant l'arborescence la plus rcente du tronc avec l'arborescence la plus rcente de la branche : la diffrence qui en rsulte constitue exactement les modifications de votre branche !). Votre branche prive ayant rintgr le tronc, vous voudrez peut-tre la supprimer du dpt : $ svn delete http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Supprime ma-branche-calc." Rvision 392 propage. Mais attendez ! L'historique de votre branche ne possde-t-il pas une certaine valeur ? Et si un beau jour quelqu'un voulait auditer l'volution de votre fonctionnalit et examiner toutes les modifications de votre branche ? Pas la peine de s'inquiter. Souvenez-vous que mme si votre branche n'est plus visible dans le dossier /branches, son existence demeure une partie immuable de l'historique du dpt. Une simple commande svn log applique l'URL /branches vous renverra l'historique complet de votre branche. Votre branche pourrait mme ressusciter un jour ou l'autre, si vous le dsirez (voir la section intitule Rsurrection des lments effacs ). Dans Subversion 1.5, une fois que la fusion d'une branche vers le tronc a t faite avec l'option --reintegrate, la branche n'est plus utilisable. Elle ne peut absorber correctement de nouvelles modifications du tronc, ni tre rintgre nouveau proprement dans le tronc. Pour cette raison, si vous voulez continuer travailler sur la branche de votre fonctionnalit, nous vous recommandons de la dtruire et de la recrer depuis le tronc : $ svn delete http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Supprime ma-branche-calc." Rvision 392 propage. $ svn copy http://svn.exemple.com/depot/calc/trunk \ http://svn.exemple.com/depot/calc/branches/nouvelle-branche -m "Cre une nouvelle branche a partir du tronc." Rvision 393 propage. $ cd ma-branche-calc $ svn switch http://svn.exemple.com/depot/calc/branches/nouvelle-branche la rvision 393.

92

Gestion des branches

La dernire commande de l'exemple prcdent, svn switch, est une faon de mettre jour une copie de travail existante afin qu'elle pointe vers un autre dossier du dpt. Nous en parlerons plus en dtail dans la section intitule Parcours des branches .

Mergeinfo et aperus
Le mcanisme de base que Subversion utilise pour grer les ensembles de modifications, c'est--dire quelles modifications ont t fusionnes dans quelles branches, est l'enregistrement de donnes dans les proprits. Plus prcisment, les informations de fusion sont conserves dans la proprit svn:mergeinfo qui est associe aux fichiers et aux dossiers (si les proprits de Subversion ne vous sont pas familires, c'est le moment de lire la section intitule Proprits ). Vous pouvez examiner cette proprit comme n'importe quelle autre : $ cd ma-branche-calc $ svn propget svn:mergeinfo . /trunk:341-390 Il est dconseill de changer soi-mme la valeur de cette proprit, moins de savoir vraiment ce que vous faites. Cette proprit est manipule automatiquement par Subversion chaque fois que vous lancez svn merge. Sa valeur indique quelles modifications (pour un chemin donn) ont t recopies dans le dossier en question. Dans le cas prsent, le chemin est / trunk et le dossier qui a reu les modifications spcifies est /branches/ma-branche-calc. Il existe galement une sous-commande, svn mergeinfo, qui peut tre utile pour voir non seulement quels ensembles de modifications un dossier a absorbs, mais aussi quels ensembles de modifications il est encore susceptible de recevoir. Ceci donne une sorte d'aperu du prochain ensemble de modifications que svn merge recopiera vers votre branche. $ cd ma-branche-calc # Quelles modifications ont dj t fusionnes du tronc vers la branche ? $ svn mergeinfo http://svn.exemple.com/depot/calc/trunk r341 r342 r343 r388 r389 r390 # Quelles modifications sont encore susceptibles d'tre fusionnes du tronc vers la branche ? $ svn mergeinfo http://svn.exemple.com/depot/calc/trunk --show-revs eligible r391 r392 r393 r394 r395 La commande svn mergeinfo prend en paramtres une URL source (d'o les modifications viennent) et une URL cible optionnelle (vers laquelle les modifications sont fusionnes). Si aucune URL cible n'est fournie, elle suppose que le dossier actuel est la cible. Dans l'exemple prcdent, puisque nous interrogeons la copie de travail de notre branche, la commande suppose que ce qui nous intresse est de recevoir les modifications de l'URL spcifie du tronc vers / branches/ma-branche-calc. Une autre manire d'obtenir un aperu plus prcis d'une opration de fusion est d'utiliser l'option --dry-run : $ svn merge http://svn.exemple.com/depot/calc/trunk --dry-run U entier.c $ svn status # rien ne s'affiche, la copie de travail n'a pas chang. 93

Gestion des branches

L'option --dry-run n'effectue en fait pas de modification locale sur la copie de travail. Elle ne fait qu'indiquer les codes d'tat qui seraient affichs par une vraie fusion. Ceci permet d'obtenir un aperu gnral d'une fusion potentielle, pour les fois o svn diff renvoie trop de dtails. Aprs avoir effectu une opration de fusion, mais avant d'en avoir propag les rsultats, vous pouvez utiliser svn diff --depth=empty /chemin/vers/la/cible/de/la/fusion pour visualiser uniquement les modifications apportes la cible immdiate de votre fusion. Si la cible de la fusion est un dossier, seules les diffrences de proprits sont alors affiches. C'est un moyen trs pratique pour voir les modifications de la proprit svn:mergeinfo enregistres par l'opration de fusion, qui vous rappellera ce que vous venez juste de fusionner. Bien sr, la meilleure faon d'avoir un aperu d'une opration de fusion est tout simplement de la raliser ! Souvenez-vous que lancer svn merge n'est pas une opration risque en soi ( moins que vous ayez effectu des modifications locales dans votre copie de travail, mais nous avons dj soulign que vous ne devriez pas faire de fusion dans un tel environnement). Si les rsultats de la fusion ne vous plaisent pas, lancez juste svn revert . -R pour ter les modifications de votre copie de travail et ressayez la commande avec des options diffrentes. La fusion n'est dfinitive qu'une fois que vous en avez propag les rsultats. Bien qu'il soit parfaitement lgitime de lancer svn merge et svn revert plusieurs reprises pour prparer la fusion, vous risquez de rencontrer quelques obstacles (facilement surmontables). Par exemple, si l'opration de fusion ajoute un nouveau fichier (ou plus exactement programme son ajout), svn revert ne supprime pas le fichier ; il va juste dprogrammer l'ajout. Vous vous retrouvez avec un fichier non suivi en versions. Si ensuite vous tentez nouveau de lancer la fusion, il risque d'y avoir des conflits dus au fichier non suivi en versions rest en travers du chemin . La Solution ? Aprs avoir effectu un retour en arrire l'aide de svn revert, pensez nettoyer la copie de travail et supprimer les fichiers et dossiers non suivis en versions. Il faut que le rsultat de svn status soit le plus propre possible, et dans l'idal vide.

Retour en arrire sur des modifications


Un usage trs rpandu de svn merge est le retour en arrire sur une modification qui a dj t propage. Supposons que vous travaillez tranquillement sur une copie de travail de /calc/trunk et que vous dcouvrez tout coup que la modification faite il y a longtemps lors de la rvision 303, qui affectait entier.c, est compltement incorrecte. Elle n'aurait jamais du tre propage. Vous pouvez utiliser svn merge pour revenir en arrire sur cette modification dans votre copie de travail, puis propager la modification locale au dpt. Il suffit juste de spcifier une diffrence inverse (en indiquant soit --revision 303:302, soit --change -303, les deux se valent). $ svn merge -c -303 http://svn.exemple.com/depot/calc/trunk --- Fusion inverse de r303 dans 'entier.c': U entier.c $ svn status M . M entier.c $ svn diff # vrifier que la modification est supprime $ svn commit -m "Retour en arrire sur la modification propage en r303." Envoi entier.c Transmission des donnes . Rvision 350 propage. Comme nous l'avons signal prcdemment, une faon de se reprsenter une rvision du dpt est de la considrer comme un ensemble de modifications spcifique. En utilisant l'option -r, vous pouvez demander svn merge d'appliquer un ensemble 94

Gestion des branches

de modifications, ou tout un groupe d'ensembles de modifications, votre copie de travail. Dans le cas prsent, pour revenir en arrire, nous demandons svn merge d'appliquer dans le sens inverse l'ensemble de modifications n303 notre copie de travail. Gardez l'esprit que revenir en arrire sur une modification de cette faon est similaire toute autre opration svn merge, vous devez donc ensuite utiliser svn status et svn diff pour vous assurer que votre travail est dans l'tat que vous voulez, puis utiliser svn commit pour propager la version finale au dpt. Aprs la propagation, cet ensemble de modifications particulier n'est plus prsent dans la rvision HEAD. nouveau vous vous dites : bon, ceci n'a pas vraiment annul la propagation, n'est-ce pas ? La modification existe toujours en rvision 303. Si quelqu'un extrait une version du projet calc entre les rvisions 303 et 349, il verra toujours la mauvaise modification, non ? Oui, c'est vrai. Quand nous parlons de supprimer une modification, il s'agit de la supprimer de la rvision HEAD. La modification originale existe toujours dans l'historique du dpt. Dans la plupart des situations, c'est suffisant. La plupart des gens ne s'intressent d'ailleurs qu' la rvision HEAD du projet. Il y a des cas particuliers, cependant, o l'on voudra vraiment dtruire toute preuve de la propagation (quelqu'un a peut-tre accidentellement propag un document confidentiel). Cela ne s'avre pas si facile, parce que Subversion a t conu dlibrment pour ne jamais perdre d'information. Les rvisions sont des arborescences immuables qui sont empiles les unes par dessus les autres. Supprimer une rvision de l'historique crerait un effet domino, engendrant le chaos dans les rvisions ultrieures et invalidant potentiellement toutes les copies de travail 2.

Rsurrection des lments effacs


Ce qu'il y a de formidable dans les systmes de gestion de versions, c'est que les informations ne sont jamais perdues. Mme si vous effacez un fichier ou un dossier, s'il disparat bien de la rvision HEAD, l'objet existe toujours dans les rvisions prcdentes. Une des questions les plus courantes que posent les nouveaux utilisateurs est : Comment est-ce que je rcupre mon ancien fichier ou dossier ? La premire tape est de dfinir exactement quel lment vous essayez de ressusciter. Voici une mtaphore utile : vous pouvez imaginer votre objet dans le dpt comme existant dans une sorte de systme deux dimensions. La premire coordonne est une rvision correspondant une arborescence particulire ; la deuxime coordonne est un chemin l'intrieur de cette arborescence. Ainsi, toute version d'un fichier ou d'un dossier peut tre dfinie par une paire de coordonnes qui lui est propre (souvenez-vous de la syntaxe des piquets de rvisions : machin.c@224, mentionne dans la section intitule Piquets de rvisions et rvisions oprationnelles ). Tout d'abord, vous allez peut-tre avoir besoin de svn log pour identifier prcisment les coordonnes du fichier ou dossier que vous voulez ressusciter. cette fin, une bonne stratgie est de lancer svn log --verbose dans un dossier qui contenait votre lment effac. L'option --verbose (-v) renvoie la liste de tous les lments modifis par chaque rvision ; il vous suffit alors de trouver la rvision dans laquelle vous avez effac le fichier ou le dossier en question. Vous pouvez accomplir cette recherche soit visuellement soit en utilisant un autre outil pour examiner le rsultat de la commande svn log (via grep ou peut-tre via une recherche incrmentale dans un diteur). $ cd dossier-parent $ svn log -v -----------------------------------------------------------------------r808 | paul | 2003-12-26 14:29:40 -0600 (ven. 26 dc 2003) | 3 lignes Chemins modifis : D /calc/trunk/reel.c M /calc/trunk/entier.c Ajout les fonctions des transformes de fourier dans entier.c. Supprim reel.c car code dsormais dans double.c. Dans l'exemple ci-dessus, nous supposons que vous recherchez un fichier effac nomm reel.c. En examinant le journal du dossier parent, vous avez dcouvert que ce fichier a t effac en rvision 808. La dernire version du fichier avoir exist tait donc dans la rvision prcdant celle-ci. Conclusion : vous voulez ressusciter le chemin /calc/trunk/reel.c tel qu'il tait en rvision 807.

Le projet Subversion prvoit nanmoins d'implmenter, un jour, une commande qui accomplirait la tche de supprimer des informations de faon permanente. En attendant, en guise de palliatif, voir la section intitule svndumpfilter .

95

Gestion des branches

Voil, c'tait la partie difficile : la recherche. Maintenant que vous savez ce que vous voulez rcuprer, deux options s'offrent vous. Une possibilit serait d'utiliser svn merge pour appliquer la rvision 808 l'envers (nous avons dj parl de comment revenir sur des modifications dans la section intitule Retour en arrire sur des modifications ). Ceci aurait pour effet de rajouter reel.c en tant que modification locale. Le fichier serait alors programm pour tre ajout et aprs la propagation le fichier existerait nouveau dans HEAD. Cependant, dans cet exemple particulier, ce n'est probablement pas la meilleure stratgie. Appliquer la rvision 808 l'envers programmerait non seulement l'ajout de reel.c, mais le message de propagation indique qu'il reviendrait aussi sur certaines modifications de entier.c, ce que vous ne voulez pas. Vous pourriez certainement fusionner l'envers la rvision 808 et ensuite revenir sur les modifications locales faites dans entier.c, mais cette technique fonctionne mal plus grande chelle. Que dire, si 90 fichiers avaient t modifis en rvision 808 ? Une seconde stratgie plus cible est de ne pas utiliser svn merge du tout, mais plutt d'utiliser la commande svn copy. Copiez juste la rvision et le chemin exacts (vos deux coordonnes ) du dpt vers votre copie de travail : $ svn copy http://svn.exemple.com/depot/calc/trunk/reel.c@807 ./reel.c $ svn status A + reel.c $ svn commit -m "Ressuscit reel.c partir de la rvision 807, /calc/trunk/reel.c." Ajout reel.c Transmission des donnes . Rvision 1390 propage. Le symbole plus dans le rsultat de la commande svn status indique que l'lment n'est pas simplement programm pour ajout, mais programm pour ajout avec son historique . Subversion se souviendra d'o il a t copi. Dans le futur, lancer svn log sur ce fichier parcourra tout son historique en passant par la rsurrection du fichier ainsi que tout ce qui prcdait la rvision 807. En d'autres termes, ce nouveau reel.c n'est pas vraiment nouveau ; c'est un descendant direct du fichier original qui avait t effac. En gnral c'est une bonne chose, dont l'utilit est avre. Si cependant vous vouliez rcuprer le fichier sans conserver de lien historique avec l'ancien fichier, la technique suivante fonctionnerait tout aussi bien : $ svn cat http://svn.exemple.com/depot/calc/trunk/reel.c@807 > ./reel.c $ svn add reel.c A reel.c $ svn commit -m "Recr reel.c partir de la rvision 807." Ajout reel.c Transmission des donnes . Rvision 1390 propage. Bien que notre exemple ne porte que sur la rsurrection d'un fichier, remarquez que ces mmes techniques fonctionnent tout aussi bien pour ressusciter des dossiers effacs. Remarquez aussi que cette rsurrection ne doit pas forcment avoir lieu dans votre copie de travail ; elle peut avoir lieu entirement dans le dpt : $ svn copy http://svn.exemple.com/depot/calc/trunk/reel.c@807 \ http://svn.exemple.com/depot/calc/trunk/ \ -m "Ressuscite reel.c dans la rvision 807." Rvision 1390 propage. $ svn update A reel.c la rvision 1390.

Fusions : pratiques avances


96

Gestion des branches

Ici finit la magie automatise. Tt ou tard, une fois que vous matrisez bien la gestion des branches et les fusions, vous allez vous retrouver demander Subversion de fusionner des modifications spcifiques d'un endroit un autre. Pour faire cela, vous allez devoir commencer passer des paramtres plus compliqus svn merge. Le paragraphe suivant dcrit la syntaxe complte de la commande et aborde un certain nombre de scnarios d'utilisation courants.

Slection la main
De la mme faon que le terme ensemble de modifications est utilis couramment dans les systmes de gestion de versions, le terme slectionner la main pourrait l'tre aussi. Il dsigne l'action de choisir une liste de modifications particulire au sein d'une branche et de la recopier dans une autre. Slectionner la main peut aussi faire rfrence l'action de dupliquer un ensemble de modifications (pas ncessairement contigus !) d'une branche vers une autre. Ceci est en opposition avec des scnarios de fusion plus courants, o l'ensemble de rvisions contigus suivant est dupliqu automatiquement. Pourquoi voudrait-on ne recopier qu'une modification unique ? Cela arrive plus souvent qu'on ne croit. Par exemple, remontons le temps et imaginons que vous n'avez pas encore rintgr votre branche de dveloppement prive dans le tronc. la machine caf, vous apprenez par hasard que Sally a apport une modification intressante entier.c dans le tronc. Vous reportant l'historique des propagations du tronc, vous vous apercevez qu'elle a corrig un bogue crucial en rvision 355, qui impacte directement la fonctionnalit sur laquelle vous tes en train de travailler. Vous n'tes peut-tre pas encore prt fusionner toutes les modifications du tronc dans votre branche, mais vous avez certainement besoin de ce correctif pour continuer votre travail. $ svn diff -c 355 http://svn.exemple.com/depot/calc/trunk Index: entier.c =================================================================== --- entier.c (revision 354) +++ entier.c (revision 355) @@ -147,7 +147,7 @@ case 6: sprintf(info->operating_system, "HPFS (OS/2 ou NT)"); break; case 7: sprintf(info->operating_system, "Macintosh"); break; case 8: sprintf(info->operating_system, "Z-System"); break; case 9: sprintf(info->operating_system, "CP/MM"); + case 9: sprintf(info->operating_system, "CP/M"); break; case 10: sprintf(info->operating_system, "TOPS-20"); break; case 11: sprintf(info->operating_system, "NTFS (Windows NT)"); break; case 12: sprintf(info->operating_system, "QDOS"); break; De la mme faon que vous avez utilis svn diff dans l'exemple prcdent pour examiner la rvision 355, vous pouvez passer le mme paramtre svn merge : $ svn merge -c 355 http://svn.exemple.com/depot/calc/trunk U entier.c $ svn status M entier.c Vous pouvez prsent lancer les procdures habituelles de tests, avant de propager cette modification votre branche. Aprs la propagation, Subversion marque r355 comme ayant t fusionne dans la branche, afin qu'une future fusion magique synchronisant votre branche avec le tronc sache qu'elle doit sauter r355 (fusionner une mme modification dans une mme branche aboutit presque toujours un conflit !). $ cd ma-branche-calc $ svn propget svn:mergeinfo . /trunk:341-349,355 # Remarquez que r355 n'est pas liste comme "ligible" la fusion, # parce qu'elle a dj t fusionne. $ svn mergeinfo http://svn.exemple.com/depot/calc/trunk --show-revs eligible r350 97

Gestion des branches

r351 r352 r353 r354 r356 r357 r358 r359 r360 $ svn merge http://svn.example.com/depot/calc/trunk --- Fusion de r350 r354 dans '.': U . U entier.c U Makefile --- Fusion de r356 r360 dans '.': U . U entier.c U bouton.c Ce type d'utilisation de la copie (ou rtroportage) de correctifs d'une branche une autre est peut-tre la raison la plus rpandue pour slectionner la main des modifications ; le cas se prsente trs souvent, par exemple lorsqu'une quipe gre une branche de production du logiciel (ce thme est dvelopp dans la section intitule Branches de publication ). Avez-vous remarqu la faon dont, dans le dernier exemple, le lancement de la fusion a eu pour effet l'application de deux ensembles distincts de fusions ? La commande svn merge a appliqu deux correctifs indpendants votre copie de travail, afin de sauter l'ensemble de modifications 355, que votre branche contenait dj. Il n'y a rien de mal en soi l-dedans, sauf que a risque de rendre plus dlicate la rsolution des conflits. Si le premier groupe de modifications engendre des conflits, vous devrez les rsoudre de faon interactive pour que la procdure de fusion puisse continuer et appliquer le deuxime groupe de modifications. Si vous remettez plus tard un conflit li la premire vague de modifications, la commande de fusion renverra au final un message d'erreur 3. Avertissement : bien que svn diff et svn merge soient conceptuellement trs similaires, leur syntaxe est diffrente dans de nombreux cas. Pour plus de dtails, reportez-vous au Chapitre 9, Rfrences compltes de Subversion ou consultez svn help. Par exemple, svn merge demande en entre, en tant que cible, le chemin d'une copie de travail, c'est--dire un emplacement o il va appliquer le correctif gnr. Si la cible n'est pas spcifie, il suppose que vous essayez d'excuter l'une des oprations suivantes : Vous voulez fusionner les modifications du dossier dans votre dossier de travail en cours. Vous voulez fusionner les modifications d'un fichier donn dans un fichier du mme nom existant dans votre dossier de travail en cours. Si vous fusionnez un dossier et que vous n'avez pas encore spcifi de cible, svn merge suppose qu'il est dans la premire situation et essaie d'appliquer les modifications dans votre dossier en cours. Si vous fusionnez un fichier et que ce fichier (ou un fichier du mme nom) existe dans votre dossier de travail en cours, svn merge suppose qu'il est dans la seconde situation et essaie d'appliquer les modifications au fichier local du mme nom.

Syntaxe de la fusion : pour tout vous dire


Nous venons de voir des exemples d'utilisation de la commande svn merge et nous allons bientt en voir plusieurs autres. Si vous n'avez pas bien assimil le le fonctionnement des fusions, rassurez-vous, vous n'tes pas un cas isol. De nombreux utilisateurs (en particulier ceux qui dcouvrent la gestion de versions) commencent par une phase de perplexit au sujet de la syntaxe de la commande, ainsi que quand et comment utiliser cette fonctionnalit. Mais, en fait, cette commande est bien plus simple que vous ne le pensez ! Il y a une technique trs simple pour comprendre comment svn merge agit. La raison principale de la confusion est le nom de la commande. Le terme merge indique en quelque sorte que les branches 3 vont tre combines, ou qu'un mystrieux mlange dessont crites.va avoir lieu. Ce sera sans doute amlior dansplusversions futures de Ceci est au vrai pour Subversion 1.5 au moment o ces lignes donnes Ce fonctionnement n'est pas le cas. Un nom les appropri pour
Subversion.

98

Gestion des branches

cette commande aurait pu tre comparer-et-appliquer , car c'est l tout ce qui se passe : deux arborescences sont compares et les diffrences sont appliques une copie de travail. Si vous utilisez svn merge pour effectuer de simples copies de modifications entre branches, elle fait gnralement ce qu'il faut automatiquement. Par exemple, une commande telle que : $ svn merge http://svn.exemple.com/depot/calc/une-branche tente de dupliquer toutes les modifications faites dans une-branche vers votre rpertoire de travail actuel, qui est sans doute une copie de travail partageant des liens historiques avec la branche. La commande est suffisamment intelligente pour ne copier que les modifications que votre copie de travail ne possde pas encore. Si vous rptez cette commande une fois par semaine, elle ne copie que les modifications les plus rcentes qui ont eu lieu depuis la dernire fusion. Si vous choisissez d'utiliser la commande svn merge dans sa version intgrale en lui fournissant les groupes de rvisions spcifiques copier, la commande prend trois paramtres : 1. une arborescence initiale (souvent appele ct gauche de la comparaison) ; 2. une arborescence finale (souvent appele ct droit de la comparaison) ; 3. une copie de travail qui reoit les diffrences en tant que modifications locales (souvent appele cible de la fusion). Une fois ces trois paramtres fournis, les deux arborescences sont compares et les diffrences sont appliques la copie de travail cible en tant que modifications locales. Une fois que la commande s'est termine, le rsultat est le mme que si vous aviez dit les fichiers la main ou lanc diverses commandes svn add ou svn delete vous-mme. Si le rsultat vous plat, vous pouvez le propager. S'il ne vous plat pas, vous pouvez toujours lancer svn revert pour revenir en arrire sur toutes les modifications. La syntaxe de svn merge est assez flexible quant la faon de spcifier les trois paramtres. Voici quelques exemples : $ svn merge http://svn.exemple.com/depot/branche1@150 \ http://svn.exemple.com/depot/branche2@212 \ ma-copie-de-travail $ svn merge -r 100:200 http://svn.exemple.com/depot/trunk ma-copie-de-travail $ svn merge -r 100:200 http://svn.exemple.com/depot/trunk La premire syntaxe liste les trois arguments de faon explicite, spcifiant chaque arborescence sous la forme URL@REV et incluant la copie de travail cible. La deuxime syntaxe peut tre utilise comme raccourci pour les cas o vous comparez des rvisions diffrentes de la mme URL. La dernire syntaxe indique que le paramtre copie de travail est optionnel ; s'il est omis, elle utilise par dfaut le rpertoire en cours. Si le premier exemple donne la syntaxe complte de svn merge, celle-ci doit tre utilise avec grande prudence ; elle peut en effet aboutir des fusions qui n'enregistrent pas la moindre mta-donne svn:mergeinfo. Le paragraphe suivant voque ceci plus en dtail.

Fusions sans mergeinfo


Subversion essaye de gnrer des mtadonnes de fusion ds qu'il le peut, afin de rendre plus intelligentes les invocations suivantes de svn merge. Nanmoins, il reste des situations o les donnes svn:mergeinfo ne sont ni cres ni modifies. Pensez tre prudent avec les scnarios suivants : Fusionner des sources sans lien de parent Si vous demandez svn merge de comparer deux URLs qui n'ont pas de lien entre elles, un correctif est quand mme gnr et appliqu votre copie de travail, mais aucune mtadonne de fusion n'est cre. Il n'y a pas d'historique commun aux deux sources et les futures fusions intelligentes dpendent de cet historique commun.

99

Gestion des branches

Fusionner avec des dpts extrieurs Bien qu'il soit possible de lancer une commande telle que svn merge -r 100:200 http://svn.projetexterieur.com/depot/trunk, le correctif rsultant ne comporte aucune mtadonne historique de fusion. la date d'aujourd'hui, Subversion n'est pas capable de reprsenter des URL de dpts diffrents au sein de la proprit svn:mergeinfo. Utiliser --ignore-ancestry Si ce paramtre est pass svn merge, il force la logique de fusion gnrer les diffrences sans rflchir, de la mme faon que svn diff les gnre, en ignorant toute considration historique. Nous traitons ce point plus loin dans ce chapitre dans la section intitule Prise en compte ou non de l'ascendance . Appliquer des fusions inverses l'historique naturel de la cible Prcdemment dans ce chapitre (dans la section intitule Retour en arrire sur des modifications ), nous avons vu comment utiliser svn merge pour appliquer un correctif invers , comme moyen de revenir en arrire sur des modifications. Si cette technique est utilise pour revenir sur une modification faite l'historique propre d'un objet (par exemple, propager r5 au tronc, puis revenir immdiatement en arrire sur r5 en utilisant svn merge . -c -5), ce type de fusion ne touche pas aux informations de fusion (mergeinfo) enregistres 4.

Plus de dtails sur les conflits lis aux fusions


Tout comme la commande svn update, svn merge applique les modifications votre copie de travail. Elle est donc aussi susceptible de crer des conflits. Cependant, les conflits engendrs par svn merge sont parfois diffrents et ce paragraphe va expliquer ces diffrences. Pour commencer, supposons que votre copie de travail n'a pas de modification locale en cours. Quand vous lancez svn update pour la mettre jour une rvision particulire, les modifications envoyes par le serveur s'appliquent toujours proprement votre copie de travail. Le serveur gnre le delta en comparant deux arborescences : d'une part un instantan virtuel de votre copie de travail, d'autre part l'arborescence de la rvision qui vous intresse. Parce que la partie gauche de la comparaison est parfaitement gale ce que vous avez dj, il est garanti que le delta va convertir correctement votre copie de travail en l'arborescence de droite. Mais svn merge ne dispose pas de telles garanties et peut tre bien plus chaotique : l'utilisateur avanc peut demander au serveur de comparer n'importe quelle paire d'arborescences, mme des arborescences n'ayant aucun rapport avec la copie de travail ! Cela laisse potentiellement beaucoup de place l'erreur humaine. Les utilisateurs vont parfois comparer deux arborescences qui ne sont pas les bonnes, crant ainsi un delta qui ne s'appliquera pas proprement. svn merge fera de son mieux pour appliquer la plus grande partie possible du delta, mais a risque d'tre impossible pour certains morceaux. De la mme faon que la commande Unix patch se plaint parfois de morceaux rats (failed hunks), svn merge se plaint de cibles manquantes omises (skipped targets) : $ svn merge -r 1288:1351 http://svn.exemple.com/depot/branche U truc.c U bidule.c Cible manquante omise : 'baz.c' U blob.c U machin.h Conflit dcouvert dans 'glorb.h'. Slectionner : (p) report, (df) diff complet, (e) dite, (h) aide pour plus d'options : Dans l'exemple prcdent, il est possible que baz.c existe dans les deux instantans de la branche en question et que le delta rsultant tente de modifier le contenu du fichier, mais que le fichier n'existe pas dans la copie de travail. Quoi qu'il en soit, le message Cible manquante omise signifie que l'utilisateur compare probablement les mauvaises arborescences ; c'est le signe classique d'une erreur de l'utilisateur. Quand a arrive, il est facile de revenir en arrire de manire rcursive sur toutes les modifications cres par la fusion (svn revert . --recursive), d'effacer tout fichier ou dossier non suivi en versions restant aprs le retour en arrire et de relancer svn merge avec des paramtres diffrents. Remarquez galement que l'exemple prcdent indique un conflit sur glorb.h. Nous avons dj mentionn que la copie de
4

noter qu'aprs tre revenu en arrire sur une rvision de cette manire, nous ne serions plus capables de r-appliquer cette rvision avec svn merge . c 5, puisque les mergeinfo incluraient dj r5 comme ayant t applique. Nous serions alors obligs d'utiliser l'option --ignore-ancestry pour forcer la commande de fusion ignorer le contenu de mergeinfo !

100

Gestion des branches

travail n'a pas de modifications locales en cours : comment peut-il donc y avoir conflit ? Encore une fois, parce que l'utilisateur peut utiliser svn merge pour dfinir et appliquer n'importe quel vieux delta la copie de travail, ce delta risque de contenir des modifications textuelles qui ne s'appliquent pas proprement un fichier de la copie de travail, mme si ce fichier n'a pas de modifications locales en cours. Une autre petite diffrence entre svn update et svn merge concerne les noms des fichiers textes crs quand un conflit a lieu. Dans la section intitule Rsoudre les conflits (fusionner des modifications) , nous avons vu qu'une mise jour gnre des fichiers appels nomdufichier.mine, nomdufichier.rOLDREV et nomdufichier.rNEWREV. Cependant, quand svn merge cause un conflit, il cre trois fichiers appels nomdufichier.working, nomdufichier.left et nomdufichier.right. Dans ce cas, les termes left et right dcrivent de quel ct de la double comparaison d'arborescences le fichier venait. Dans tous les cas, ces noms de fichiers diffrents vous aideront distinguer les conflits rsultant d'une mise jour de ceux rsultant d'une fusion.

Blocage de modifications
Il peut parfois y avoir un ensemble de modifications particulier dont vous ne voulez pas qu'il soit fusionn automatiquement. Par exemple, peuttre que l'habitude dans votre quipe est d'effectuer tout nouveau travail de dveloppement dans /trunk, mais d'tre plus conservateur en ce qui concerne le rtroportage des modifications vers une branche stable que vous utilisez pour la publication. l'extrme, vous pouvez slectionner la main des ensembles de modifications individuels du tronc porter vers la branche : juste les changements qui sont suffisamment stables pour tre acceptables. Peut-tre que les choses ne sont pas aussi strictes aprs tout ; peut-tre que la plupart du temps vous aimeriez juste laisser svn merge fusionner automatiquement la plupart des modifications du tronc vers la branche. Dans ce cas, il vous faudrait une faon de masquer quelques modifications particulires, c'est--dire d'empcher qu'elles ne soient fusionnes automatiquement. Dans Subversion 1.5, la seule manire de bloquer une liste de modifications est de faire croire au systme que cette modification a dj t fusionne. Pour cela, il est possible de lancer la commande de fusion avec l'option --record-only : $ cd ma-branche-calc $ svn propget svn:mergeinfo . /trunk:1680-3305 # Marquons l'ensemble de modifications r3328 comme dj fusionn. $ svn merge -c 3328 --record-only http://svn.exemple.com/depot/calc/tronc $ svn status M . $ svn propget svn:mergeinfo . /trunk:1680-3305,3328 $ svn commit -m "Empche r3328 d'tre fusionne vers la branche." Cette technique fonctionne, mais elle est un petit peu dangereuse. Le problme principal est que nous ne faisons pas clairement la diffrence entre J'ai dj cette modification et Je n'ai pas cette modification . En fait, nous mentons au systme, en lui faisant croire que la modification a dj t fusionne. Ce qui transfre vers vous, l'utilisateur, la responsabilit de vous rappeler que la modification n'a en fait pas t fusionne, qu'elle n'tait tout simplement pas voulue. Il n'y a pas moyen de demander Subversion la liste des listes de modifications bloques . Si vous voulez en conserver la trace (afin de pouvoir les dbloquer un jour), vous devrez les consigner dans un fichier texte quelque part, ou peut-tre dans une proprit invente de toutes pices pour l'occasion. Dans Subversion 1.5, malheureusement, c'est la seule faon de grer les rvisions bloques ; dans les versions futures il est prvu d'en amliorer l'interface.

Historiques et annotations tenant compte des fusions passes


Une des fonctionnalits principales de tout systme de gestion de versions est de conserver la trace de qui a modifi quoi et quand ils l'ont fait. Les commandes svn log et svn blame sont les outils adapts pour cela : quand on les applique des fichiers individuels, ils renvoient non seulement l'historique des ensembles de modifications qui ont touch le fichier, mais aussi exactement quel utilisateur a crit quelle ligne de code et quand il l'a fait.

101

Gestion des branches

Cependant, quand des modifications commencent tre copies entre des branches, les choses commencent se compliquer. Par exemple, si vous interrogiez svn log sur l'historique de votre branche fonctionnelle, il renverrait exactement toutes les rvisions qui ont touch cette branche : $ cd ma-branche-calc $ svn log -q -----------------------------------------------------------------------r390 | utilisateur | 2002-11-22 11:01:57 -0600 (ven. 22 nov. 2002) | 1 ligne -----------------------------------------------------------------------r388 | utilisateur | 2002-11-21 05:20:00 -0600 (jeu. 21 nov. 2002) | 2 lignes -----------------------------------------------------------------------r381 | utilisateur | 2002-11-20 15:07:06 -0600 (mer. 20 nov. 2002) | 2 lignes -----------------------------------------------------------------------r359 | utilisateur | 2002-11-19 19:19:20 -0600 (mar. 19 nov. 2002) | 2 lignes -----------------------------------------------------------------------r357 | utilisateur | 2002-11-15 14:29:52 -0600 (ven. 15 nov. 2002) | 2 lignes -----------------------------------------------------------------------r343 | utilisateur | 2002-11-07 13:50:10 -0600 (jeu. 07 nov. 2002) | 2 lignes -----------------------------------------------------------------------r341 | utilisateur | 2002-11-03 07:17:16 -0600 (dim. 03 nov. 2002) | 2 lignes -----------------------------------------------------------------------r303 | sally | 2002-10-29 21:14:35 -0600 (mar. 29 oct. 2002) | 2 lignes -----------------------------------------------------------------------r98 | sally | 2002-02-22 15:35:29 -0600 (ven. 22 fev. 2002) | 2 lignes -----------------------------------------------------------------------Mais est-ce bien l une description adquate de tous les changements qui ont eu lieu sur cette branche ? Ce qui manque ici, c'est le fait que les rvisions 390, 381 et 357 rsultaient en fait de fusions en provenance du tronc. Si vous regardez plus en dtail l'historique d'une de ces rvisions, vous ne verrez nulle part les multiples ensembles de modifications du tronc qui ont t reports sur la branche : $ svn log -v -r 390 -----------------------------------------------------------------------r390 | utilisateur | 2002-11-22 11:01:57 -0600 (ven. 22 nov. 2002) | 1 ligne Chemins modifis : M /branches/ma-branche-calc/bouton.c M /branches/ma-branche-calc/LISEZMOI Fusion finale des modifications du tronc dans ma-branche-calc. Il se trouve que nous savons que cette fusion vers la branche n'tait qu'une fusion de modifications du tronc. Comment pouvons-nous galement voir ces modifications du tronc ? La rponse est d'utiliser l'option --use-merge-history (-g). Cette option donne le dtail des modifications filles qui faisaient partie de la fusion. $ svn log -v -r 390 -g -----------------------------------------------------------------------r390 | utilisateur | 2002-11-22 11:01:57 -0600 (ven. 22 nov. 2002) | 1 ligne Chemins modifis : M /branches/ma-branche-calc/bouton.c M /branches/ma-branche-calc/LISEZMOI Fusion finale des modifications du tronc dans ma-branche-calc. -----------------------------------------------------------------------r383 | sally | 2002-11-21 03:19:00 -0600 (jeu. 21 nov. 2002) | 2 lignes Chemins modifis : M /branches/ma-branche-calc/bouton.c Fusion via: r390 Corrige l'erreur d'inversion graphique sur le bouton. -----------------------------------------------------------------------r382 | sally | 2002-11-20 16:57:06 -0600 (mer. 20 nov. 2002) | 2 lignes Chemins modifis : M /branches/ma-branche-calc/LISEZMOI 102

Gestion des branches

Fusion via: r390 Documente mon dernier correctif dans LISEZMOI. En forant l'opration svn log utiliser l'historique des fusions, nous obtenons non seulement la rvision que nous avions demand (r390), mais aussi les deux rvisions qui l'accompagnaient deux modifications du tronc faites par Sally. C'est une image bien plus complte de l'historique ! La commande svn blame accepte galement l'option --use-merge-history (-g). Si cette option est omise, quelqu'un qui regarderait un relev annot ligne par ligne pour bouton.c risquerait d'avoir l'impression errone que vous tes responsable des lignes qui ont corrig une certaine erreur : $ svn blame bouton.c 390 utilisateur 390 utilisateur 390 utilisateur

retval = inverse_func(button, path); return retval; }

Et bien qu'il soit vrai que vous avez propag ces trois lignes lors de la rvision 390, deux d'entre elles ont en fait t crites par Sally auparavant, en rvision 383 : $ svn blame G 383 G 383 390 bouton.c -g sally sally utilisateur retval = inverse_func(button, path); return retval; }

prsent, nous savons qui doit rellement tre tenu responsable pour ces deux lignes de code !

Prise en compte ou non de l'ascendance


Quand vous discutez avec un dveloppeur Subversion, il est trs possible qu'il fasse rfrence au terme d'ascendance. Ce mot est utilis pour dcrire la relation entre deux objets dans un dpt : s'ils sont lis l'un l'autre, un des objets est alors qualifi d'anctre de l'autre. Par exemple, supposons que vous propagiez la rvision 100 qui contient une modification d'un fichier truc.c. Ds lors, truc.c@99 est un anctre de truc.c@100. En revanche, supposons que vous propagiez la suppression de truc.c en rvision 101 et ensuite l'ajout d'un nouveau fichier du mme nom en rvision 102. Dans ce cas, truc.c@99 et truc.c@102 pourraient sembler apparents (ils ont le mme chemin), mais en fait ce sont des objets compltement diffrents au sein du dpt. Ils ne partagent aucun historique ou ascendance . Nous abordons ce point pour mettre en vidence une diffrence importante entre svn diff et svn merge. La premire commande ignore toute ascendance, tandis que la seconde y est particulirement sensible. Par exemple, si vous demandez svn diff de comparer les rvisions 99 et 102 de truc.c, vous obtenez des diffrences bases sur les lignes ; la commande svn diff compare deux chemins l'aveugle. Mais si vous demandez svn merge de comparer les deux mmes objets, il remarque qu'ils ne sont pas lis et essaie d'abord de supprimer l'ancien fichier, puis d'ajouter le nouveau fichier ; le rsultat indique une suppression puis un ajout : D A truc.c truc.c

La plupart des fusions impliquent de comparer des arborescences qui ont une relation d'ascendance de l'une l'autre ; c'est pourquoi svn merge a ce comportement par dfaut. Cependant, l'occasion, vous pourriez vouloir que la commande svn merge compare deux arborescences sans relation d'ascendance entre elles. Par exemple, vous avez peut-tre import deux arborescences de code source reprsentant des publications diffrentes de deux fournisseurs d'un projet logiciel (voir la section intitule Branches fournisseur ). Si vous demandez svn merge de comparer les deux arborescences, vous verrez la 103

Gestion des branches

premire arborescence compltement supprime, puis l'ajout de la seconde arborescence toute entire ! Dans ce genre de situations, vous attendez de svn merge qu'il effectue une comparaison base sur les chemins uniquement, en ignorant toute relation entre les fichiers et les dossiers. Ajoutez l'option --ignore-ancestry votre commande svn merge et elle se comportera comme svn diff (et inversement, l'option --notice-ancestry fera se comporter svn diff comme la commande svn merge).

Fusions, copies et renommages


Il arrive souvent qu'on veuille rorganiser le code source, en particulier dans les projets logiciels en Java. Les fichiers et les rpertoires sont dplacs et renomms, causant souvent de grandes perturbations pour tous ceux qui travaillent sur le projet. Ceci semble tre le cas idal o utiliser une branche, n'est-ce pas ? Crer une branche, rorganiser les choses, et ensuite fusionner la branche vers le tronc, non ? Hlas, ce scnario ne fonctionne pas si bien pour le moment et est mme considr comme l'une des faiblesses de Subversion. Le problme est que la commande svn update de Subversion n'est pas aussi robuste qu'elle le devrait, en particulier en ce qui concerne les oprations de copies et de dplacements. Quand vous utilisez svn copy pour dupliquer un fichier, le dpt se souvient d'o venait le nouveau fichier, mais il ne transmet pas cette information au client qui lance svn update ou svn merge. Au lieu de dire au client Copie ce fichier que tu as dj vers ce nouvel emplacement , il envoie un fichier entirement nouveau. Ceci peut engendrer des problmes, en particulier parce que le fonctionnement est le mme pour les fichiers renomms. Un fait peu connu propos de Subversion est qu'il lui manque de vrais renommages - la commande svn move n'est rien de plus que l'agrgation de svn copy et svn delete. Par exemple, supposons que pendant que vous travaillez sur votre branche prive, vous renommez entier.c en tout.c. Ce faisant, vous avez en fait cr un nouveau fichier dans votre branche, qui est une copie du fichier original, et vous avez supprim le fichier original. Pendant ce temps, dans le tronc, Sally a propag des amliorations d'entier.c. C'est alors que vous dcidez de fusionner votre branche vers le tronc : $ cd calc/trunk $ svn merge --reintegrate http://svn.exemple.com/depot/calc/branches/ma-branche-calc --- Fusion des diffrences des URLs du dpt vers '.' : D entier.c A tout.c U . Ceci n'a pas l'air si mal premire vue, mais ce n'est probablement pas ce quoi Sally ou vous vous attendiez. L'opration de fusion a supprim la version la plus rcente du fichier entier.c (celle qui contenait les dernires modifications de Sally) et a ajout machinalement votre nouveau fichier tout.c, qui est une copie de l'ancien fichier entier.c. Le rsultat final est que la fusion de votre renommage a supprim de la dernire rvision les modifications rcentes de Sally ! Il ne s'agit pas d'une vraie perte de donnes. Les modifications de Sally font toujours partie de l'historique du dpt, mais le droulement exact des vnements n'est peut-tre pas immdiatement vident. La morale de l'histoire est que jusqu' ce que Subversion ne s'amliore, vous devrez faire trs attention aux fusions de copies et de renommages d'une branche une autre.

Blocage des clients qui ne prennent pas en compte les fusions


Si vous venez de mettre niveau votre serveur Subversion la version 1.5 ou plus, il existe un risque significatif que les clients Subversion pr-1.5 sment la pagaille dans votre suivi automatique des fusions. Pourquoi ? Quand un client Subversion pr-1.5 excute svn merge, il ne modifie pas du tout la valeur de la proprit svn:mergeinfo. La propagation qui s'ensuit, bien qu'elle soit le rsultat d'une fusion, n'envoie donc aucune indication au dpt au sujet des modifications dupliques ces informations sont perdues. Par la suite, lorsque des clients qui prennent en compte les fusions tentent d'effectuer une fusion automatique, ils rencontreront probablement toutes sortes de conflits rsultant des fusions rptes. Si votre quipe et vous dpendez des fonctionnalits de suivi des fusions de Subversion, vous voudrez peut-tre configurer votre dpt pour qu'il empche les anciens clients de propager des modifications. La mthode la plus simple est d'examiner le paramtre capabilities dans la procdure automatique de dbut de propagation. Si le client indique tre capable de grer les mergeinfo, la procdure automatique peut l'autoriser commencer la propagation. Si le client n'indique pas en tre capable, la procdure automatique doit lui refuser la propagation. Nous en apprendrons plus sur les procdures automatiques dans le 104

Gestion des branches

chapitre suivant ; voir la section intitule Mise en place des procdures automatiques et start-commit pour les dtails.

Recommandations finales sur le suivi des fusions


En fin de compte, la fonctionnalit de suivi des fusions de Subversion possde une mcanique interne extrmement complexe et la proprit svn:mergeinfo est la seule lorgnette dont l'utilisateur dispose pour observer cette mcanique. Parce que cette fonctionnalit est relativement nouvelle, un certain nombre de cas litigieux et de comportements potentiellement inattendus risquent d'tre rencontrs. Par exemple, mergeinfo sera parfois gnre lors d'une simple commande svn copy ou svn move. Parfois mergeinfo apparatra sur des fichiers dont vous n'auriez pas imagin qu'ils soient touchs par une opration. Parfois mergeinfo ne sera pas du tout gnre, contrairement ce que vous attendiez. De plus, la gestion de la mtadonne mergeinfo a tout un ensemble de taxonomies et de comportements qui lui sont associs, tels que des mergeinfo explicites par opposition implicites , des rvisions oprationnelles par opposition non-oprationnelles , des mcanismes spcifiques d' lision de mergeinfo et mme d' hritage de rpertoires parents sous-rpertoires. Nous avons choisi de ne pas couvrir en dtail ces sujets dans ce livre pour plusieurs raisons. Premirement, l'utilisateur moyen serait totalement submerg par le niveau de dtail disponible. Deuximement, au fur et mesure que Subversion s'amliore, nous estimons que l'utilisateur moyen ne devrait pas avoir comprendre ces concepts ; en tant que dtails d'implmentation agaants, ils finiront par disparatre l'arrire-plan. Malgr tout ce qui vient d'tre dit, si vous apprciez ce genre de choses, vous en trouverez une formidable vue d'ensemble dans un article post sur le site internet de Collabnet : http://www.collab.net/community/subversion/articles/merge-info.html. Pour le moment, si vous voulez rester l'cart des bogues et autres comportements inattendus des fusions automatiques, l'article de Collabnet recommande que vous vous en teniez simplement aux bonnes pratiques suivantes : Pour les branches fonctionnelles courte dure de vie, suivez la procdure simple dcrite dans la section intitule Fusions : pratiques de base . Pour les branches de publication longue dure de vie (comme dcrites dans la section intitule Modles courants de gestion des branches ), ne pratiquez de fusions que sur la racine de la branche, pas sur des sous-rpertoires. Ne pratiquez jamais de fusion vers des copies de travail contenant un mlange de numros de rvisions de travail, ou ayant des sous-rpertoires dports (comme dcrit par la suite dans la section intitule Parcours des branches ). La cible d'une fusion doit tre une copie de travail qui reprsente un emplacement unique un moment unique dans le dpt. Ne modifiez jamais la proprit svn:mergeinfo directement ; utilisez svn merge avec l'option --record-only pour appliquer une modification dsire cette mtadonne (comme expliqu dans la section intitule Blocage de modifications ). Assurez-vous de toujours avoir l'accs complet en lecture toutes vos sources de fusion, et vrifiez que votre copie de travail cible n'a pas de dossiers clairsems.

Parcours des branches


La commande svn switch transforme une copie de travail existante de telle sorte qu'elle pointe vers une branche diffrente. Bien que la connaissance de cette commande ne soit pas absolument ncessaire pour travailler avec des branches, elle fournit un raccourci utile. Dans notre exemple prcdent, aprs avoir cr votre branche prive, vous avez extrait une toute nouvelle copie de travail du nouveau rpertoire du dpt. la place, vous pouvez simplement demander Subversion de modifier votre copie de travail de /calc/trunk pour qu'elle pointe vers l'emplacement de la nouvelle branche : $ cd calc $ svn info | grep URL URL: http://svn.exemple.com/depot/calc/trunk $ svn switch http://svn.exemple.com/depot/calc/branches/ma-branche-calc U entier.c U bouton.c U Makefile 105

Gestion des branches

Actualis la rvision 341. $ svn info | grep URL URL: http://svn.exemple.com/depot/calc/branches/ma-branche-calc Faire pointer (ou dporter ) une copie de travail qui n'a pas de modifications locales vers une branche diffrente a pour rsultat que la copie de travail a exactement le mme aspect que si vous aviez effectu une extraction brute du rpertoire. C'est en gnral plus efficace d'utiliser cette commande, car les diffrences entre les branches sont souvent minimes. Le serveur n'envoie que le minimum de modifications ncessaire pour faire pointer votre copie de travail vers le rpertoire de la branche. La commande svn switch accepte galement l'option --revision (-r), pour que que vous ne soyez pas oblig de faire pointer votre copie de travail vers la rvision HEAD de la branche. Bien sr, la plupart des projets sont plus compliqus que notre exemple calc et contiennent de multiples sous-dossiers. Les utilisateurs de Subversion suivent souvent un algorithme prcis quand ils utilisent des branches : 1. Copier le tronc entier du projet vers une nouvelle branche 2. Ne dporter qu'une partie de la copie de travail du tronc pour qu'elle pointe sur la branche. En d'autres termes, si un utilisateur sait que le travail sur la branche ne doit avoir lieu que sur un sous-dossier donn, il utilise svn switch pour ne faire pointer que ce sous-dossier vers la branche (ou parfois des utilisateurs ne vont faire pointer qu'un unique fichier de travail vers la branche !). De cette faon, l'utilisateur peut continuer recevoir les mises jour normales du tronc vers la plus grande partie de sa copie de travail, mais les portions dportes ne seront pas touches ( moins que quelqu'un ne propage une modification sa branche). Cette fonctionnalit ajoute une dimension compltement nouvelle au concept de copie de travail mixte : les copies de travail peuvent non seulement contenir un mlange de rvisions de travail, mais elles peuvent galement contenir un mlange d'emplacements du dpt. Si votre copie de travail contient un certain nombre de sous-arborescences pointant vers des emplacements varis du dpt, elle continue fonctionner normalement. Quand vous la mettez jour, vous recevez comme il se doit les correctifs pour chaque sous-arborescence. Quand vous effectuez une propagation, vos modifications locales s'appliquent toujours au dpt en tant qu'une unique modification atomique. Remarquez que bien qu'il soit possible pour votre copie de travail de pointer vers une varit d'emplacements du dpt, ces emplacements doivent tous faire partie du mme dpt. Les dpts Subversion ne sont pas encore capables de communiquer entre eux ; cette fonctionnalit est prvue l'avenir 5. Dports et mises jour Avez-vous remarqu que les sorties des commandes svn switch et svn update se ressemblent ? La commande svn switch est en fait une gnralisation de la commande svn update. Quand vous lancez svn update, vous demandez au dpt de comparer deux arborescences. C'est ce qu'il fait, puis il renvoie au client le dtail des diffrences entre les deux. La seule diffrence entre svn switch et svn update est que cette dernire commande compare toujours deux chemins identiques du dpt. C'est--dire que si votre copie de travail pointe vers /calc/trunk, svn update compare automatiquement votre copie de travail de /calc/trunk au /calc/trunk de la rvision HEAD. Si vous faites pointer votre copie de travail vers une branche, svn switch comparera votre copie de travail de /calc/trunk au rpertoire d'une autre branche de la rvision HEAD. En d'autres termes, svn update dplace votre copie de travail travers le temps. svn switch dplace votre copie de travail travers le temps et l'espace.

Parce que svn switch est essentiellement une variante de svn update, elle se comporte de la mme manire ; toute modification locale prsente dans votre copie de travail est prserve lorsque de nouvelles donnes arrivent en provenance du
5

Vous pouvez cependant utiliser svn switch avec l'option --relocate si l'URL de votre serveur change et si vous ne voulez pas abandonner votre copie de travail existante. Reportez-vous svn switch pour des dtails et des exemples.

106

Gestion des branches

dpt. Vous-tes vous dj trouvs dans une situation o vous effectuez des modifications complexes (dans votre copie de travail de /trunk) et ralisez soudainement : Mais, ces modifications ne devraient-elles pas tre dans leur propre branche ? Une excellente technique pour accomplir ceci peut tre rsume en deux tapes : $ svn copy http://svn.exemple.com/depot/calc/trunk \ http://svn.exemple.com/depot/calc/branches/nouvelle-branche \ -m "Cration de la branche 'nouvelle-branche'." Rvision 353 propage. $ svn switch http://svn.exemple.com/depot/calc/branches/nouvelle-branche la rvision 353. La commande svn switch, l'instar de svn update, prserve vos modifications locales. Dsormais, votre copie de travail pointe vers la branche nouvellement cre et la prochaine fois que vous lancerez svn commit vos modifications y seront envoyes.

tiquettes
Un autre concept courant en gestion de versions est l'tiquette (parfois appele tag). Une tiquette n'est qu'un instantan d'un projet un moment donn. Dans Subversion, cette ide semble tre prsente partout. Chaque rvision du dpt est exactement cela : un instantan du systme de fichiers pris aprs chaque propagation. Cependant les gens veulent souvent donner des noms plus conviviaux aux tiquettes, tel que version-1.0. Et ils veulent prendre des instantans de sous-sections plus restreintes du systme de fichiers. Aprs tout, ce n'est pas si facile de se rappeler que la version 1.0 d'un logiciel donn correspond un sous-dossier particulier de la rvision 4822.

Cration d'une tiquette simple


Une fois encore, svn copy vient la rescousse. Si vous voulez crer un instantan de /calc/trunk identique ce qu'il est dans la rvision HEAD, faites-en une copie : $ svn copy http://svn.exemple.com/depot/calc/trunk \ http://svn.exemple.com/depot/calc/tags/version-1.0 \ -m "tiquetage de la version 1.0 du projet 'calc'." Rvision 902 propage. Cet exemple prsuppose qu'un rpertoire /calc/tags existe dj (s'il n'existe pas, vous pouvez le crer en utilisant svn mkdir). Une fois la copie termine, le nouveau dossier version-1.0 sera pour toujours un instantan du dossier /trunk tel qu'il tait en rvision HEAD au moment o vous avez effectu la copie. Bien sr, vous voudriez peut-tre tre plus prcis quant quelle rvision vous copiez, au cas o quelqu'un d'autre aurait propag des modifications au projet pendant que vous regardiez ailleurs. Donc si vous savez que la rvision 901 de /calc/trunk est exactement l'instantan que vous voulez, vous pouvez le spcifier en passant -r 901 la commande svn copy. Mais attendez un moment : cette procdure de cration d'tiquette, n'est-ce pas la mme procdure que nous avons utilis pour crer une branche ? En fait, oui. Dans Subversion, il n'y pas de diffrence entre une tiquette et une branche. Toutes deux ne sont que des rpertoires ordinaires qui sont crs par copie. Comme pour les branches, la seule raison qui fasse qu'un rpertoire copi soit une tiquette est que les humains ont dcid de le traiter de cette faon : aussi longtemps que personne ne propage de modification ce rpertoire, il reste un instantan. Si les gens commencent y propager des choses, il devient une branche. Si vous administrez un dpt, il y a deux approches possibles pour grer les tiquettes. La premire approche est une politique de non-intervention : en tant que convention dfinie pour le projet, vous dcidez o vos tiquettes sont places et vous vous assurez que tous les utilisateurs savent comment traiter les rpertoires qu'ils copient (c'est--dire que vous vous assurez qu'ils savent qu'ils ne doivent rien y propager). La seconde approche est plus paranoaque : vous pouvez utiliser un des contrles d'accs fournis avec Subversion pour empcher que quiconque ne puisse faire autre chose dans la zone des tiquettes que d'y crer de nouvelles copies (voir le Chapitre 6, Configuration du serveur). L'approche paranoaque n'est cependant pas 107

Gestion des branches

ncessaire, en gnral. Si un utilisateur propage accidentellement une modification un rpertoire d'tiquettes, vous pouvez simplement revenir en arrire sur cette modification comme expliqu dans le paragraphe prcdent. C'est a la gestion de versions, aprs tout !

Cration d'une tiquette complexe


Parfois vous voudrez peut-tre que votre instantan soit plus compliqu qu'un simple rpertoire une unique rvision donne. Par exemple, imaginons que votre projet est bien plus vaste que notre exemple calc : supposons qu'il contient un bon nombre de sous-rpertoires et bien plus de fichiers encore. Au cours de votre travail, vous pouvez trs bien dcider que vous avez besoin de crer une copie de travail destine des fonctionnalits particulires et des corrections de bogues. Pour cela vous pouvez antidater de manire slective des fichiers ou dossiers des rvisions donnes (en utilisant gnreusement svn update avec l'option -r), dporter des fichiers et des dossiers vers des branches particulires (au moyen de svn switch) ou mme effectuer manuellement un tas de modifications locales. Quand vous en avez termin, votre copie de travail est un vrai bazar, fait d'emplacements du dpt des rvisions diffrentes. Mais aprs l'avoir teste, vous tes alors certain que c'est l'exacte combinaison de donnes que vous vouliez tiqueter. C'est alors le moment de prendre un clich. Copier une URL vers une autre ne fonctionnera pas cette fois. Dans le cas prsent, vous voulez prendre un clich de l'arrangement exact de votre copie de travail et le placer dans le dpt. Par chance, svn copy possde en fait quatre usages diffrents (au sujet desquels vous pouvez obtenir des informations au Chapitre 9, Rfrences compltes de Subversion), dont la possibilit de copier une arborescence de travail vers le dpt : $ ls ma-copie-de-travail/ $ svn copy ma-copie-de-travail \ http://svn.exemple.com/depot/calc/tags/mon-etiquette \ -m "tiquette l'tat de ma copie de travail existante." Rvision 940 propage. Dsormais il y a un nouveau rpertoire dans le dpt, /calc/tags/mon-etiquette, qui est un instantan exact de votre copie de travail : rvisions mixtes, URL, modifications locales et tout et tout D'autres utilisateurs ont trouv des usages intressants pour cette fonctionnalit. Il y a parfois des situations o votre copie de travail contient un paquet de modifications locales que vous aimeriez montrer un collaborateur. Au lieu de lancer svn diff et d'envoyer un fichier patch (qui ne listera pas les modifications de rpertoires, de liens symboliques ou de proprits), vous pouvez utiliser svn copy pour envoyer votre copie de travail vers une zone prive du dpt. Votre collaborateur peut ensuite soit extraire une copie carbone de votre copie de travail, soit utiliser svn merge pour recevoir exactement vos modifications. Bien que ce soit une jolie mthode pour mettre disposition un instantan rapide de votre copie de travail, remarquez que ce n'est pas une bonne manire de crer une branche initialement. La cration de branche devrait tre un vnement en soi, tandis que cette mthode combine la cration d'une branche avec des modifications supplmentaires apportes aux fichiers, le tout au sein d'une seule rvision. Ceci rend trs difficile ( terme) d'identifier un unique numro de rvision en tant que point de cration de la branche.

Maintenance des branches


ce stade, vous vous tes certainement rendu compte que Subversion est extrmement flexible. Parce qu'il implmente les branches et les tiquettes avec le mme mcanisme sous-jacent (des copies de rpertoires) et parce que les branches et les tiquettes apparaissent au sein de l'espace standard du systme de fichiers, beaucoup de gens trouvent Subversion intimidant. Il est presque trop flexible. Dans ce paragraphe, nous proposons des suggestions pour organiser et grer vos donnes au fil du temps.

Agencement du dpt
Il existe des mthodes standard recommandes pour structurer un dpt. La plupart des gens crent un rpertoire trunk pour la ligne de dveloppement principale (le tronc), un rpertoire branches qui contiendra les copies de branches et un 108

Gestion des branches

rpertoire tags qui contiendra les copies tiquetes. Si un dpt ne comprend qu'un seul projet, les gens crent souvent les dossiers suivants la racine : /trunk /branches /tags Si un dpt contient plusieurs projets, les administrateurs indexent gnralement la structure du dpt par projet (voir la section intitule Stratgies d'organisation d'un dpt pour en savoir plus sur les dossiers racine d'un projet ) : /paint/trunk /paint/branches /paint/tags /calc/trunk /calc/branches /calc/tags Bien sr, vous restez libre d'ignorer ces agencements courants. Vous pouvez crer toutes sortes de variantes, selon ce qui fonctionne le mieux pour vous ou pour votre quipe. Souvenez-vous que quel que soit votre choix, ce n'est pas un engagement dfinitif. Vous pouvez rorganiser votre dpt tout moment. Parce que les branches et les tiquettes sont des rpertoires ordinaires, la commande svn move peut les dplacer ou les renommer selon vos dsirs. Passer d'un agencement un autre consiste juste lancer une srie d'oprations de dplacement ct serveur ; si vous n'aimez pas la faon dont les choses sont organises dans le dpt, modifiez juste leur agencement. Souvenez-vous nanmoins que bien qu'il soit facile de dplacer des dossiers, vous devez aussi rester attentif vos utilisateurs. Vos modifications sont susceptibles de dboussoler ceux qui ont des copies de travail existantes. Si un utilisateur a une copie de travail d'un rpertoire donn du dpt, votre opration svn move risque de supprimer ce chemin de la rvision la plus rcente. Lorsque par la suite l'utilisateur lancera svn update, il se verra annoncer que sa copie de travail reprsente un chemin qui n'existe plus et sera contraint d'effectuer un svn switch vers le nouvel emplacement.

Dure de vie des donnes


Une autre fonctionnalit intressante lie aux principes de fonctionnement de Subversion est que les branches et les tiquettes peuvent avoir des dures de vie limites, tout comme n'importe quel autre lment suivi en versions. Par exemple, supposons que vous avez enfin termin votre travail sur votre branche personnelle du projet calc. Aprs avoir fusionn toutes vos modifications vers /calc/trunk, le rpertoire contenant votre branche prive n'a plus de raison d'exister : $ svn delete http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Suppression d'une branche obsolte du projet calc." Rvision 375 propage. Et maintenant votre branche a disparu. Bien sr, elle n'a pas vraiment disparu : le rpertoire est juste absent de la rvision HEAD, ne gnant plus personne. Si vous utilisez svn checkout, svn switch ou svn list pour examiner une rvision plus ancienne, vous pourrez toujours voir votre vieille branche. Si la navigation dans votre rpertoire supprim ne vous suffit pas, vous pouvez toujours le rcuprer. Ressusciter des donnes est trs facile dans Subversion. S'il y a un dossier (ou un fichier) supprim que vous aimeriez faire rapparatre dans HEAD, utilisez simplement svn copy pour le copier depuis l'ancienne rvision. $ svn copy http://svn.exemple.com/depot/calc/branches/ma-branche-calc@374 \ http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Restaure ma-branche-calc." Rvision 376 propage. Dans notre exemple, votre branche personnelle a eu une dure de vie relativement limite : vous l'aviez peut-tre cre pour corriger un bogue ou implmenter une nouvelle fonctionnalit. Quand votre tche est finie, il en va de mme pour la branche. 109

Gestion des branches

Cependant, en dveloppement logiciel, il est aussi courant d'avoir deux branches principales cte cte pour de trs longues priodes. Par exemple, supposons que le moment est venu de publier une version stable du projet calc pour le public. Vous savez qu'il faudra quelques mois pour liminer les bogues du logiciel. Vous ne voulez pas que les gens ajoutent de nouvelles fonctionnalits au projet, mais vous ne voulez pas non plus dire tous les dveloppeurs d'arrter de programmer. Donc la place, vous crez une branche stable du logiciel qui ne changera pas beaucoup : $ svn copy http://svn.exemple.com/depot/calc/trunk \ http://svn.exemple.com/depot/calc/branches/stable-1.0 \ -m "Cration de la branche stable du projet calc." Rvision 377 propage. Ds lors les dveloppeurs sont libres de continuer ajouter des fonctionnalits de pointe (ou exprimentales) / calc/trunk et vous pouvez poser comme convention pour le projet que seules les corrections de bogues seront propages dans /calc/branches/stable-1.0. C'est--dire qu'au fur et mesure que les gens continueront de travailler sur le tronc, quelqu'un reportera de faon slective les corrections de bogues vers la branche stable. Mme aprs que la branche stable aura t publie, vous continuerez probablement maintenir la branche pendant longtemps, c'est--dire pour aussi longtemps que vous continuerez fournir aux clients un support sur cette version. Nous voquons ceci plus en dtails dans le prochain paragraphe.

Modles courants de gestion des branches


Il existe de nombreux usages pour la cration et la fusion des branches ; ce paragraphe dcrit les plus courants. Le plus souvent, la gestion de versions est utilise pour le dveloppement de logiciels, voici donc un coup d'il rapide deux des modles les plus courants de cration et de fusion de branches utiliss par les quipes de programmeurs. Si vous ne vous servez pas de Subversion pour dvelopper des logiciels, n'hsitez pas sauter ce paragraphe. Si vous tes un dveloppeur de logiciels qui utilise la gestion de versions pour la premire fois, soyez trs attentifs, car ces modles sont souvent considrs comme des bonnes pratiques par les dveloppeurs plus expriments. Ces procdures ne sont pas spcifiques Subversion ; elles sont applicables tout systme de gestion de versions. Nanmoins, les voir explicites en termes Subversion peut aider.

Branches de publication
En gnral un logiciel suit un cycle de vie classique, rptant les trois tapes suivantes en boucle : code, test, publication. Il y a deux problmes avec ce processus. Premirement, les dveloppeurs doivent continuer crire de nouvelles fonctionnalits pendant que les quipes d'assurance qualit prennent le temps de tester des versions supposes stables du logiciel. Les nouveaux dveloppements ne peuvent pas s'arrter pendant que le logiciel est en cours de test. Deuximement, l'quipe doit presque toujours effectuer le support des versions anciennes et publies du logiciel ; si un bogue est dcouvert dans le code le plus rcent, il existe probablement aussi dans les versions qui ont t publies et les clients voudront obtenir le correctif pour ce bogue sans avoir attendre la publication d'une nouvelle version majeure. C'est l o la gestion de versions peut s'avrer utile. La procdure standard ressemble ceci : 1. Les dveloppeurs propagent tout nouveau travail vers le tronc. Les modifications quotidiennes sont propages vers / trunk : nouvelles fonctionnalits, corrections de bogues, etc. 2. Le tronc est copi vers une branche de publication . Lorsque l'quipe estime que le logiciel est prt tre publi (disons en version 1.0), /trunk peut tre copi vers /branches/1.0. 3. Les quipes continuent travailler en parallle. Une quipe commence tester rigoureusement la branche de publication, pendant qu'une autre quipe continue avec les nouvelles tches (disons pour la version 2.0) sur /trunk. Si des bogues sont dcouverts dans l'un ou l'autre des emplacements, les correctifs sont reports de l'un l'autre selon les besoins. Il arrive cependant un moment o mme ce processus s'arrte. La branche est gele pour les tous derniers tests juste avant publication. 4. La branche est tiquete et publie. Quand les tests sont termins, /branches/1.0 est copie vers /tags/1.0.0 en tant que clich de rfrence. L'tiquette est exporte et livre aux clients. 5. La branche est gre au fil du temps. Pendant que le travail continue sur /trunk en vue de la version 2.0, les correctifs de 110

Gestion des branches

bogues continuent tre reports de /trunk /branches/1.0. Lorsque suffisamment de correctifs se sont accumuls, les responsables peuvent dcider de publier une version 1.0.1 : /branches/1.0 est copie vers /tags/1.0.1 et cette tiquette est exporte et publie. Ce processus entier se rpte au fur et mesure que le logiciel gagne en maturit : quand le travail pour la version 2.0 est termin, une nouvelle branche de publication 2.0 est cre, teste, tiquete et finalement publie. Au bout de quelques annes, le dpt finit par avoir un certain nombre de branches de publication en mode maintenance et un certain nombre d'tiquettes reprsentant les versions finales publies.

Branches fonctionnelles
Une branche fonctionnelle est la sorte de branche qui est l'exemple dominant dans ce chapitre (celle sur laquelle vous travailliez pendant que Sally continuait travailler sur /trunk). C'est une branche temporaire cre pour travailler sur un changement complexe sans interfrer avec la stabilit de /trunk. la diffrence des branches de publication (dont le support doit parfois tre prolong trs longtemps), les branches fonctionnelles naissent, sont utilises pendant un temps, sont fusionnes vers le tronc et sont finalement supprimes. Elles ont une utilit limite dans le temps. Encore une fois, les stratgies varient normment au sujet du moment appropri pour crer une branche fonctionnelle. Certains projets n'utilisent jamais de branche fonctionnelle : n'importe qui peut propager des modifications /trunk. L'avantage de ce systme est qu'il est simple : personne n'a besoin d'tre form aux branches ou aux fusions. L'inconvnient est que le code du tronc est souvent instable ou inutilisable. D'autres projets utilisent les branches l'extrme : une modification n'est jamais propage directement dans le tronc. Mme les modifications les plus triviales sont faites au sein d'une branche courte dure de vie, vrifies attentivement, puis fusionnes vers le tronc. La branche est ensuite supprime. Ce systme garantit que le tronc restera exceptionnellement stable et utilisable tout moment, mais aux dpens des cots de gestion lis cette procdure trs lourde. La plupart des projets choisissent une approche mi-chemin entre les deux. Ils insistent gnralement pour qu' tout moment / trunk puisse tre compil et passe avec succs les tests de rgression. Une branche fonctionnelle n'est ncessaire que quand une modification ncessite un grand nombre de propagations susceptibles de dstabiliser le tronc. Une bonne mthode empirique est de se poser la question suivante : si le dveloppeur travaillait pendant plusieurs jours en isolation et ensuite propageait cette grosse modification en une seule fois (afin que /trunk ne soit jamais dstabilis), est-ce que ce serait une modification trop grosse vrifier ? Si la rponse cette question est oui , alors la modification devrait tre dveloppe sur une branche fonctionnelle. Au fur et mesure que le dveloppeur propage ses modifications incrmentales dans la branche, elles peuvent facilement tre vrifies par ses pairs. Finalement, il reste la question de savoir quelle est la meilleure mthode pour garder une branche synchronise avec le tronc au fur et mesure que le travail avance. Comme nous l'avons mentionn prcdemment, il est trs risqu de travailler sur une branche pendant des semaines ou des mois ; le tronc continuera peut-tre recevoir des modifications, au point que les deux lignes de dveloppement risquent de s'loigner tellement l'une de l'autre qu'essayer de fusionner la branche vers le tronc devienne un cauchemar. Le mieux pour viter une telle situation est de fusionner rgulirement les modifications du tronc vers la branche. Faites-en une habitude : une fois par semaine, fusionnez les modifications du tronc de la semaine prcdente vers la branche. Le moment arrivera o vous serez prt fusionner la branche fonctionnelle synchronise vers le tronc. Commencez donc par effectuer une dernire fusion des modifications les plus rcentes du tronc vers la branche. Une fois que c'est fait, les dernires versions de la branche et du tronc sont absolument identiques, mises part vos propres modifications sur la branche. Vous tes alors en mesure de fusionner la branche vers le tronc avec l'option --reintegrate : $ cd copie-de-travail-du-tronc $ svn update la rvision 1910. $ svn merge --reintegrate http://svn.exemple.com/depot/calc/branches/ma-branche --- Fusion des diffrences des URLs du dpt vers '.': U reel.c U entier.c A nouveau-dossier A nouveau-dossier/nouveau-fichier U . 111

Gestion des branches

Une autre faon de concevoir ce modle est d'imaginer que votre synchronisation hebdomadaire du tronc vers la branche est analogue au lancement de svn update dans une copie de travail, tandis que l'tape finale de fusion est analogue au lancement de svn commit depuis une copie de travail. Aprs tout, une copie de travail n'est rien d'autre qu'une branche prive trs superficielle : c'est une branche qui n'est capable de ne contenir qu'une modification la fois.

Branches fournisseur
Comme c'est particulirement le cas en dveloppement logiciel, les donnes que vous grez dans votre systme de gestion de versions ont souvent un lien troit avec les donnes de quelqu'un d'autre, ou en sont peut-tre dpendantes. Gnralement, les besoins de votre projet vous obligeront rester aussi jour que possible avec les donnes fournies par cette entit externe, sans sacrifier la stabilit de votre propre projet. Ce scnario arrive trs souvent, partout o les informations gnres par un groupe de personnes ont un effet direct sur celles qui sont gnres par un autre groupe de personnes. Par exemple, il arrive que des dveloppeurs de logiciel travaillent sur une application qui utilise une bibliothque tierce. Subversion a justement une relation de ce type avec la bibliothque Apache Portable Runtime (APR) (voir la section intitule APR, la bibliothque Apache de portabilit des excutables ). Le code source de Subversion dpend de la bibliothque APR pour tous ses besoins de portabilit. Durant les tapes initiales de dveloppement de Subversion, le projet suivait les changements de l'interface de programmation d'APR de prs, restant toujours la pointe des volutions du code de la bibliothque. Maintenant que APR et Subversion ont tous deux gagn en maturit, Subversion n'essaie de se synchroniser avec l'interface de programmation de l'APR qu' des tapes de publication stables et bien testes. Donc, si votre projet dpend des informations de quelqu'un d'autre, vous pourriez tenter de synchroniser ces informations avec les vtres de plusieurs manires. La plus pnible serait de donner des instructions orales ou crites tous les contributeurs de votre projet, leur demandant de s'assurer qu'ils disposent des bonnes versions de ces informations tierces dont votre projet a besoin. Si les informations tierces sont gres dans un dpt Subversion, vous pourriez aussi utiliser les dfinitions externes de Subversion pour en fait agrafer des versions spcifiques de ces informations un endroit quelconque dans le dossier de votre copie de travail (voir la section intitule Dfinition de rfrences externes ). Mais parfois vous voudrez grer des modifications personnalises de ce code tierce l'intrieur de votre propre systme de gestion de versions. En reprenant l'exemple du dveloppement logiciel, les programmeurs pourraient vouloir apporter des modifications cette bibliothque tierce pour leurs propres besoins. Ces modifications incluraient peut-tre de nouvelles fonctionnalits ou des corrections de bogues, gres en interne seulement jusqu' ce qu'elles soient incluses dans une version officielle de la bibliothque tierce. Ou alors ces changements ne seront peut-tre jamais remonts vers ceux qui grent cette bibliothque, existant seulement en tant qu'optimisations maison permettant de mieux adapter la bibliothque aux besoin des dveloppeurs du logiciel. prsent vous tes face une situation intressante. Votre projet pourrait hberger ses modifications maison des donnes tierces de manire dsordonne, comme par exemple en utilisant des fichiers de patch ou des versions alternatives compltes des fichiers et dossiers. Mais ces mthodes deviennent rapidement de vrais casse-tte grer, ncessitant des mcanismes pour reporter vos modifications maison au code tierce et ncessitant le report de ces modifications chaque version successive du code tierce dont vous dpendez. La solution de ce problme est d'utiliser des branches fournisseur. Une branche fournisseur est une arborescence au sein de votre propre systme de gestion de versions qui contient des informations fournies par une entit tierce, ou fournisseur. Chaque version des donnes du fournisseur que vous dcidez d'incorporer dans votre projet est appele une livraison fournisseur. Les branches fournisseur prsentent deux avantages. Premirement, en incluant la livraison fournisseur actuellement supporte dans votre propre systme de gestion de versions, vous avez la garantie que les membres de votre projet n'auront jamais besoin de se demander s'ils ont la bonne version des donnes du fournisseur. Ils reoivent simplement la bonne version pendant les mises jour usuelles de leur copie de travail. Deuximement, parce que ces donnes font partie de votre propre dpt Subversion, vous pouvez y conserver vos modifications maison : vous n'avez plus besoin d'une mthode automatise (ou pire, manuelle) pour reporter vos propres changements.

Procdure gnrale de gestion des branches fournisseur


La gestion des branches fournisseur fonctionne gnralement de la faon suivante : vous crez d'abord un rpertoire la racine (par exemple /fournisseur) qui contiendra les branches fournisseur. Ensuite vous importez le code tierce dans un sousdossier de ce dossier racine. Vous copiez ensuite ce sous-rpertoire vers l'emplacement appropri de votre branche de 112

Gestion des branches

dveloppement principale (par exemple /trunk). Vous faites bien attention toujours effectuer vos modifications locales dans la branche de dveloppement principale. chaque nouvelle version du code tierce, vous le dposez dans la branche fournisseur et en fusionnez les modifications vers /trunk, en rsolvant les conflits qui apparaissent entre vos modifications locales et les modifications tierces. Un exemple va rendre cet algorithme plus clair. Nous allons utiliser un scnario dans lequel votre quipe de dveloppement cre un programme de calcul qui dpend d'une bibliothque tierce d'arithmtique des nombres complexes, libcomplex. Nous commencerons par la cration initiale de la branche fournisseur et l'import de la premire livraison fournisseur. Nous appellerons notre dossier contenant la branche fournisseur libcomplex et nos livraisons fournisseur iront dans un sousdossier de notre branche fournisseur appel actuel. Et puisque svn import cre tous les dossiers parents intermdiaires dont il a besoin, nous pouvons en fait accomplir ces deux tapes en une seule commande : $ svn import /chemin/vers/libcomplex-1.0 \ http://svn.exemple.com/depot/fournisseur/libcomplex/actuel \ -m 'import initial de la livraison fournisseur 1.0' Nous avons dsormais la version actuelle du code source de libcomplex dans /fournisseur/libcomplex/actuel. prsent, nous tiquetons cette version (voir la section intitule tiquettes ) et ensuite nous la copions dans la branche de dveloppement principale. Cette opration de copie cre un nouveau dossier appel libcomplex au sein du rpertoire de notre projet existant calc. C'est dans cette copie des donnes du fournisseur que nous ferons nos ajustements maison : $ svn copy http://svn.exemple.com/depot/fournisseur/libcomplex/actuel http://svn.exemple.com/depot/fournisseur/libcomplex/1.0 -m 'tiquetage de libcomplex-1.0' $ svn copy http://svn.exemple.com/depot/fournisseur/libcomplex/1.0 \ http://svn.exemple.com/depot/calc/libcomplex \ -m 'amne libcomplex-1.0 dans la branche principale' \ \

Nous extrayons ensuite la branche principale de notre projet, qui inclut dsormais une copie de la premire livraison fournisseur, et nous nous mettons au travail pour personnaliser le code de libcomplex. Avant mme d'en avoir pris conscience, notre version modifie de libcomplex est compltement intgre dans notre programme de calcul 6. Quelques semaines plus tard, les dveloppeurs de libcomplex publient une nouvelle version de leur bibliothque, la version 1.1, qui contient des fonctionnalits dont nous avons besoin. Nous aimerions pouvoir utiliser cette nouvelle version, sans toutefois perdre les volutions que nous avons apportes la version existante. En gros, ce que nous voudrions faire c'est remplacer notre version actuelle de libcomplex, la 1.0, par une copie de libcomplex 1.1 et ensuite r-appliquer les modifications que nous avions effectues prcdemment sur cette bibliothque la nouvelle version. Mais, en fait, nous allons aborder le problme sous un autre angle, en appliquant les changements apports libcomplex entre les versions 1.0 et 1.1 notre copie modifie de celle-ci. Pour effectuer cette mise niveau, nous allons extraire une copie de notre branche fournisseur et remplacer le code du rpertoire actuel par le nouveau code source de libcomplex 1.1. Nous copions en fait littralement de nouveaux fichiers pardessus des fichiers existants, par exemple en extrayant le contenu de l'archive de libcomplex 1.1 l'endroit o se trouvent nos fichiers et dossiers. L'objectif ici est d'aboutir ce que notre rpertoire actuel ne contienne que le code de libcomplex 1.1 et de s'assurer que la totalit de ce code est suivi en versions. Ah, et puis nous voulons faire ceci avec le moins possible de perturbations lies l'historique de la gestion de versions. Aprs avoir remplac le code de la 1.0 par le code de la 1.1, svn status liste les fichiers ayant des modifications locales et peuttre aussi des fichiers non suivis en versions. Si nous avons fait ce que nous tions censs faire, les fichiers non suivis en versions sont uniquement de nouveaux fichiers introduits par la version 1.1 de libcomplex ; nous lanons donc svn add sur ces fichiers pour les inclure dans la gestion de versions. Si le code de la 1.1 ne contient plus certains fichiers qui taient dans l'arborescence de la 1.0, il sera peut-tre difficile de les reprer ; il vous faudrait comparer les deux arborescences avec un outil extrieur et ensuite faire un svn delete sur tous les fichiers prsents en 1.0 mais pas en 1.1 (bien qu'il soit peut-tre parfaitement acceptable de laisser traner ces mmes fichiers, inutiliss, dans l'ombre). Finalement, une fois que notre copie de travail de actuel ne contient plus que le code de libcomplex 1.1, nous pouvons propager les modifications que nous avons faites pour lui donner cet aspect.
6

Et ne contient pas le moindre bogue, cela va de soi !

113

Gestion des branches

Notre branche actuel contient dsormais la nouvelle livraison fournisseur. Nous tiquetons donc la nouvelle version en 1.1 (de la mme faon que nous avions prcdemment tiquet la livraison fournisseur de la version 1.0) et ensuite nous fusionnons les diffrences entre les tiquettes de la version prcdente et de la nouvelle version vers notre branche de dveloppement principale : $ cd copies-de-travail/calc $ svn merge http://svn.exemple.com/depot/fournisseur/libcomplex/1.0 \ http://svn.exemple.com/depot/fournisseur/libcomplex/actuel \ libcomplex # rsoudre tous les conflits entre leurs modifications et nos modifications $ svn commit -m 'fusion de libcomplex-1.1 vers la branche principale' Dans le cas le plus trivial, la nouvelle version de notre outil tierce ressemblerait la version prcdente, du point de vue des fichiers et dossiers. Aucun des fichiers sources de libcomplex n'aurait t effac, renomm, ou dplac ; la nouvelle version ne contiendrait que des modifications textuelles par rapport la prcdente. Dans l'idal, nos modifications s'appliqueraient proprement la nouvelle version de la bibliothque, sans la moindre complication ou conflit. Mais les choses ne sont pas toujours aussi simples et, en fait, il arrive assez frquemment que des fichiers sources changent d'emplacement d'une version l'autre d'un logiciel. Ceci complique la tche de s'assurer que nos modifications sont toujours valides pour la nouvelle version du code, et les choses peuvent rapidement dgnrer, jusqu'au point o nous pouvons tre forcs de reporter manuellement nos volutions maison dans la nouvelle version. Une fois que Subversion connat l'historique d'un fichier source donn, incluant tous ses emplacements prcdents, la procdure pour incorporer la nouvelle version de la bibliothque est assez simple. Mais c'est nous qu'incombe la responsabilit d'indiquer Subversion de quelle manire l'agencement des fichiers sources a chang d'une livraison fournisseur une autre.

svn_load_dirs.pl
Les livraisons fournisseur comportant plus de quelques suppressions, ajouts et dplacements compliquent le processus de mise niveau chaque version successive des donnes tierces. Subversion fournit donc le script svn_load_dirs.pl pour faciliter ce processus. Ce script automatise les tapes importantes que nous avons mentionnes dans la procdure gnrale de gestion des branches fournisseurs afin de minimiser les erreurs. Vous tes toujours responsable de l'utilisation des commandes svn merge pour fusionner les nouvelles versions des donnes tierces vers votre branche de dveloppement principale, mais svn_load_dirs.pl peut vous aider parvenir cette tape plus rapidement et plus facilement. En bref, svn_load_dirs.pl est une version amliore de svn import qui possde plusieurs caractristiques importantes : On peut le lancer n'importe quand, dans le but d'amener un rpertoire existant du dpt reflter exactement un rpertoire extrieur, en effectuant toutes les oprations d'ajouts et de suppressions et, en option, de dplacements. Il prend soin de sries compliques d'oprations entre lesquelles Subversion a besoin d'une propagation intermdiaire, telles qu'avant de renommer un fichier ou un dossier pour la deuxime fois. En option, il peut tiqueter les nouveaux dossiers imports. En option, il peut ajouter des proprits arbitraires aux fichiers et dossiers qui correspondent une expression rgulire. svn_load_dirs.pl prend trois paramtres obligatoires. Le premier paramtre est l'URL du rpertoire de base de Subversion modifier. Ce paramtre est suivi par l'URL, relative au premier paramtre, dans laquelle la livraison fournisseur sera importe. Enfin, le troisime paramtre est le dossier local importer. En utilisant notre exemple prcdent, une excution type de svn_load_dirs.pl donne : $ svn_load_dirs.pl http://svn.exemple.com/depot/fournisseur/libcomplex \ actuel \ /chemin/vers/libcomplex-1.1 Vous pouvez indiquer que vous aimeriez que svn_load_dirs.pl tiquette la nouvelle livraison fournisseur en passant l'option 114

Gestion des branches

t et en spcifiant un nom d'tiquette. Cette tiquette est aussi une URL relative au premier paramtre du programme. $ svn_load_dirs.pl -t libcomplex-1.1 \ http://svn.exemple.com/depot/fournisseur/libcomplex \ actuel \ /chemin/vers/libcomplex-1.1 Lorsque vous lancez svn_load_dirs.pl, il examine le contenu de votre livraison fournisseur existante, actuel, et le compare la nouvelle livraison fournisseur. Dans le cas le plus trivial, aucun fichier n'est prsent dans une version sans l'tre dans l'autre et le script effectue le nouvel import sans incident. Cependant, s'il y a des divergences dans l'agencement des fichiers entre les versions, svn_load_dirs.pl vous demande comment rsoudre ces diffrences. Par exemple, vous avez l'opportunit d'indiquer au script que vous savez que le fichier math.c de la version 1.0 de libcomplex a t renomm en arithmetique.c dans libcomplex 1.1. Toutes les divergences qui ne sont pas lies des renommages sont traites comme des ajouts et des suppressions classiques. Le script peut galement prendre en compte un fichier de configuration spar, permettant de spcifier des proprits sur des fichiers et dossiers, correspondants une expression rgulire, qui vont tre ajouts au dpt. Ce fichier de configuration est indiqu svn_load_dirs.pl en utilisant l'option -p en ligne de commande. Chaque ligne du fichier de configuration est un ensemble de deux ou quatre valeurs dlimites par des espaces : une expression rgulire du style Perl laquelle comparer le chemin ajout, un mot cl de contrle (soit break soit cont) et ensuite, en option, un nom de proprit et une valeur. \.png$ \.jpe?g$ \.m3u$ \.m3u$ .* break break cont break break svn:mime-type svn:mime-type svn:mime-type svn:eol-style svn:eol-style image/png image/jpeg audio/x-mpegurl LF native

Pour chaque chemin ajout, les modifications de proprits configures dont l'expression rgulire correspond au chemin sont appliques dans l'ordre, sauf si le terme de contrle est break (ce qui signifie qu'aucune autre modification de proprit ne doit tre applique ce chemin). Si le terme de contrle est cont (abrviation de continuer), la comparaison continue avec la ligne suivante du fichier de configuration. Toute espace faisant partie de l'expression rgulire, du nom de la proprit ou de la valeur de la proprit doit tre entoure d'apostrophes ou de guillemets. Vous pouvez banaliser les guillemets et apostrophes qui ne sont pas utiliss pour entourer une espace en les faisant prcder d'une barre oblique inverse (ou antislash : \). L'antislash ne banalise que les guillemets et apostrophes pendant le traitement du fichier de configuration, ce n'est donc pas la peine de protger d'autres caractres au-del de ce qui est ncessaire pour l'expression rgulire.

Rsum
Nous avons trait de nombreux sujets dans ce chapitre. Nous avons prsent les concepts d'tiquettes et de branches et montr comment Subversion implmente ces concepts en copiant des rpertoires avec la commande svn copy. Nous avons expliqu comment utiliser svn merge pour copier des modifications d'une branche l'autre ou pour revenir en arrire sur des modifications non-satisfaisantes. Nous avons tudi l'utilisation de svn switch pour crer des copies de travail mixtes, pointant vers des emplacements varis d'un dpt. Et nous avons voqu la faon dont on peut grer l'organisation et le cycle de vie des branches dans un dpt. Tchez de garder en mmoire la devise de Subversion : les branches et les tiquettes ne cotent quasiment rien. Donc n'ayez pas peur de les utiliser quand vous en avez besoin ! En guise de rappel utile de toutes les oprations dont nous avons parl, voici un tableau de rfrence trs pratique, consulter lorsque vous commencerez utiliser des branches.

Tableau 4.1. Commandes de gestion des branches et des fusions


Action Crer une branche ou une tiquette Commande svn copy URL1 URL2 115

Gestion des branches

Action

Commande

Faire pointer une copie de travail vers une branche ou une svn switch URL tiquette Synchroniser une branche avec le tronc Voir l'historique des fusions ou les modifications susceptibles d'tre fusionns Fusionner une branche vers le tronc Fusionner une modification prcise Fusionner un ensemble de modifications Empcher qu'une automatiquement Abandonner une fusion Ressusciter un lment de l'historique Revenir en arrire sur une modification dj propage modification ne soit ensembles svn merge trunkURL; svn commit de svn mergeinfo target --from-source=URL svn merge commit --reintegrate branchURL; svn

svn merge -c REV URL; svn commit svn merge -r REV1:REV2 URL; svn commit fusionne svn merge -c REV --record-only URL; svn commit svn merge URL --dry-run svn revert -R . svn copy URL@REV localPATH svn merge -c -REV URL; svn commit

Prvisualiser une fusion

Examiner l'historique en tenant compte des informations de svn log -g; svn blame -g fusion Crer une tiquette partir d'une copie de travail Rorganiser une branche ou une tiquette Supprimer une branche ou une tiquette svn copy . tagURL svn mv URL1 URL2 svn rm URL

116

Chapitre 5. Administration d'un dpt


Le dpt Subversion est le centre de stockage de toutes vos donnes suivies en versions. Ainsi, il est de facto l'objet de toute l'attention et de tous les soins de l'administrateur. Bien que ce soit un lment ne ncessitant pas normment de maintenance, il est important de comprendre comment le configurer et le surveiller de manire viter d'ventuels problmes et rsoudre proprement ceux qui se prsentent. Dans ce chapitre, nous expliquons comment crer et configurer un dpt Subversion. Nous abordons galement la maintenance du dpt, en donnant des exemples d'utilisation des outils svnlook et svnadmin fournis avec Subversion. Nous tudions quelques questions et erreurs communes et nous donnons des conseils sur l'organisation des donnes dans le dpt. Si vous n'envisagez pas d'utiliser un dpt Subversion autrement qu'en simple utilisateur des donnes (c'est--dire en utilisant un client Subversion), vous pouvez sauter ce chapitre. Cependant, si vous tes (ou si vous tes appel tre) l'administrateur d'un dpt1, ce chapitre est fait pour vous.

Dfinition d'un dpt Subversion


Avant d'aborder le vaste sujet de l'administration d'un dpt, dfinissons plus prcisment ce qu'est un dpt. quoi ressemble-t-il ? Que ressent-il ? Est-ce qu'il prfre son th chaud ou glac, sucr, avec une tranche de citron ? En tant qu'administrateur, vous vous devez de comprendre de quoi est compos un dpt, la fois au niveau du systme d'exploitation ( quoi ressemble le dpt et comment il ragit vis--vis des outils autres que Subversion) et au niveau logique de l'organisation des donnes (comment elles sont reprsentes l'intrieur du dpt). Du point de vue d'un explorateur de fichiers classique (comme Windows Explorer) ou d'un outil de navigation du systme de fichiers en ligne de commande, un dpt Subversion n'est rien d'autre qu'un rpertoire contenant plein de choses. Il y a des sous-rpertoires avec des fichiers de configuration lisibles par un humain, des sous-rpertoires avec des fichiers de donnes binaires dj bien moins lisibles, etc. l'instar d'autres parties de Subversion, la modularit est une proccupation majeure et l'organisation hirarchique prvaut sur le bazar. Un coup d'il rapide dans un dpt ordinaire est suffisant pour obtenir la liste des composants essentiels d'un dpt : $ ls depot conf/ dav/

db/

format

hooks/

locks/

README.txt

Effectuons un survol rapide de ce que nous voyons dans ce rpertoire (ne vous inquitez pas si vous ne comprenez pas tous les termes employs, ils sont expliqus dans ce chapitre ou ailleurs dans ce livre) : conf Un rpertoire contenant des fichiers de configuration. dav Un rpertoire disposition de mod_dav_svn pour y stocker ses informations prives. db Le magasin de donnes pour toutes vos donnes suivies en versions. format Un fichier contenant uniquement le numro de version de l'organisation du dpt. hooks Un rpertoire plein de modles de procdures automatiques (et les procdures automatiques elles-mmes, une fois installes). locks

Cela peut sembler prestigieux et noble, mais il s'agit juste en fait d'une personne intresse par le monde mystrieux qui se cache derrire la copie de travail que chacun dtient.

117

Administration d'un dpt

Un rpertoire fait pour les fichiers de verrous du dpt Subversion, utilis pour grer les accs au dpt. README.txt Un fichier qui ne fait qu'informer son lecteur qu'il est tomb sur un dpt Subversion. Bien sr, quand on y accde via les bibliothques Subversion, cet ensemble de fichiers et de rpertoires se transforme en un systme de fichiers suivis en versions virtuel, complet et comportant une gestion des vnements personnalisable. Ce systme de fichiers possde ses propres notions de rpertoires et de fichiers, trs similaires aux notions des systmes de fichiers rels (tels que NTFS, FAT32, ext3, etc.). Mais c'est un systme de fichiers spcial : il base ces rpertoires et ces fichiers sur les rvisions, conservant l'historique de tous les changements effectus de manire sre et prenne. C'est l que la totalit de vos donnes suivies en versions rside.

Stratgies de dploiement d'un dpt


En grande partie grce la conception pure du dpt Subversion et des technologies sous-jacentes, il est particulirement ais de crer et configurer un dpt. Il y a quelques choix prliminaires faire mais l'essentiel du travail de cration et de configuration d'un dpt Subversion est simple et convivial, facilement reproductible si vous tes amen effectuer des installations multiples. Voici quelques questions se poser avant toute chose : Quelles donnes vont tre hberges dans le dpt (ou les dpts) et quelle en sera l'organisation ? O sera plac le dpt et comment les utilisateurs y accderont-ils ? De quels types de contrle d'accs et de notifications d'vnements avez-vous besoin ? Quel type de magasin de donnes dsirez-vous utiliser ? Dans cette section, nous essayons de vous aider rpondre ces questions.

Stratgies d'organisation d'un dpt


Bien que Subversion vous permette de dplacer des fichiers et des rpertoires suivis en versions sans perte d'information et qu'il fournisse mme des outils pour dplacer des ensembles complets de donnes suivies en version d'un dpt un autre, ces oprations peuvent perturber le travail des autres collaborateurs qui accdent souvent au dpt et qui s'attendent trouver chaque chose sa place. Ainsi, avant de crer un nouveau dpt, essayez de vous projeter un peu dans le futur ; prparez l'avance le passage de vos donnes sous gestion de versions. Cette rflexion sur la manire d'organiser vos donnes dans le dpt vous vitera de futurs et nombreux maux de tte. Supposons qu'en tant qu'administrateur d'un dpt, vous tes responsable de l'administration du systme de gestion de versions pour plusieurs projets. La premire dcision prendre est de choisir entre un seul dpt pour tous les projets et un dpt par projet, ou bien un compromis entre ces deux solutions. Un seul dpt pour tous les projets offre des avantages, ne serait-ce que pour la maintenance unifie. Un seul dpt signifie qu'il n'y a qu'un seul jeu de procdures automatiques, une seule sauvegarde grer, un seul jeu d'oprations de dchargement et de chargement effectuer si la nouvelle version de Subversion est incompatible avec l'ancienne version, etc. Vous pouvez galement dplacer facilement des donnes entre les projets, sans perdre l'historique de ces informations. Les inconvnients utiliser un seul dpt sont que les diffrents projets auront certainement des besoins diffrents en termes de gestion des vnements, comme la notification par e-mail des propagations des listes d'adresses diffrentes ou des dfinitions diffrentes de ce qui constitue une propagation lgitime. Bien sr, ce ne sont pas des problmes insurmontables cela implique juste que vos procdures automatiques doivent tenir compte de l'organisation du dpt dans lequel elles sont invoques plutt que de considrer que l'ensemble du dpt est associ un seul groupe d'utilisateurs. Rappelez-vous galement que Subversion utilise des numros de rvisions globaux au dpt. Bien que ces numros ne possdent pas de pouvoirs magiques particuliers, certaines personnes n'aiment pas voir le numro de rvision augmenter alors qu'elles n'ont pas touch leur propre projet2.
2

Que ce soit par ignorance ou par la dfinition absurde de mtriques de dveloppement, les numros globaux de rvision sont craints alors qu'ils sont bien peu de chose et certainement pas prendre en considration quand vous dcidez de l'agencement de vos projets et de vos dpts.

118

Administration d'un dpt

On peut aussi adopter une approche intermdiaire. Par exemple, les projets peuvent tre regroups par thme. Vous pouvez avoir quelques dpts, avec une poigne de projets dans chaque dpt. Ainsi, les projets susceptibles de partager des donnes le font aisment et les dveloppeurs sont tenus au courant des avances des projets en relation avec les leurs par le biais des nouvelles rvisions du dpt. Une fois l'organisation des dpts dfinie, il faut se proccuper de la hirarchie des rpertoires l'intrieur des dpts euxmmes. Comme Subversion utilise de simples copies de rpertoires pour crer les branches et les tiquettes (voir le Chapitre 4, Gestion des branches), la communaut Subversion recommande de choisir un endroit dans le dpt pour la racine de chaque projet (le rpertoire dont la sous-arborescence contient toutes les donnes relatives un projet) et d'y placer trois sousrpertoires : trunk ( tronc en franais), le rpertoire qui hberge les principaux dveloppements du projet ; branches, le rpertoire dans lequel seront cres les diffrentes variations de la ligne de dveloppement principale ; et tags ( tiquettes en franais), qui contient un ensemble d'instantans de l'arborescence (les instantans sont crs, voire dtruits, mais jamais modifis)3. Par exemple, votre dpt peut ressembler ceci : / calculatrice/ trunk/ tags/ branches/ calendrier/ trunk/ tags/ branches/ tableur/ trunk/ tags/ branches/ Veuillez noter que l'emplacement du projet dans le dpt n'est pas important. Si vous n'avez qu'un seul projet par dpt, il est logique de placer la racine du projet la racine du dpt correspondant. Si vous avez plusieurs projets, vous voulez peut-tre les classer par groupes dans des sous-rpertoires communs du dpt, en fonction des objectifs ou du code partager par exemple, ou tout simplement en les groupant par ordre alphabtique. Voici un exemple : / utilitaires/ calculatrice/ trunk/ tags/ branches/ calendrier/ trunk/ tags/ branches/ bureautique/ tableur/ trunk/ tags/ branches/ Organisez votre dpt comme vous le sentez. Subversion n'a aucune exigence en la matire pour lui, un rpertoire est un rpertoire. L'objectif est d'avoir une organisation qui rponde aux besoins des collaborateurs des diffrents projets. Cependant, par souci de transparence, nous indiquons une autre organisation galement trs rpandue. Dans cette organisation, les rpertoires trunk, tags et branches sont situs la racine du dpt et les projets sont placs dans des sous-rpertoires juste en dessous, comme ceci :
3

Le trio trunk, tags et branches est quelquefois appel les rpertoires TTB (the TTB directories en anglais).

119

Administration d'un dpt

/ trunk/ calculatrice/ calendrier/ tableur/ tags/ calculatrice/ calendrier/ tableur/ branches/ calculatrice/ calendrier/ tableur/ Il n'y a rien d'incorrect dans une telle organisation, mais elle peut ne pas tre trs intuitive pour vos utilisateurs. En particulier dans des situations complexes avec plusieurs projets et un grand nombre d'utilisateurs, dont la plupart ne connaissent qu'un ou deux projets du dpt. Mais cette approche plusieurs projets par branche a tendance favoriser l'ouverture de chaque projet sur les autres et pousse envisager l'ensemble des projets comme une seule entit. Cela reste un problme social. Nous aimons l'organisation suggre au dbut pour des raisons purement pratiques : il est plus facile de faire des requtes (ou des modifications, des migrations) sur l'historique complet d'un projet quand une sous-arborescence du dpt contient l'ensemble des donnes (pass, prsent, tiquettes et branches) de ce projet et elles seules.

Stratgies d'hbergement d'un dpt


Avant de crer votre dpt Subversion, vous devez vous demander o il va rsider. Cette question est fortement lie une myriade d'autres questions telles que : qui sont les utilisateurs (sont-ils l'intrieur de votre rseau interne, derrire le pare-feu de votre entreprise, ou bien s'agit-il de n'importe qui, n'importe o sur Internet ?), comment les utilisateurs accdent au dpt (via un serveur Subversion ou directement), quels autres services vous fournissez autour de Subversion (une interface pour navigateur Web, des notifications par email des propagations, etc.), quelle est votre politique de sauvegarde et ainsi de suite. Le choix et la configuration du serveur sont abords au Chapitre 6, Configuration du serveur, mais nous voulons signaler ds maintenant que certains choix pour l'une ou l'autre de ces questions ont des implications sur l'endroit o implmenter votre serveur. Par exemple, certains scnarios de dploiement ncessitent, pour plusieurs ordinateurs, l'accs au dpt via un systme de fichiers distant et, dans ce cas, le choix du type de magasin de donnes n'en est plus un, puisqu'un seul type de magasin de donnes convient dans ce scnario. Dcrire l'ensemble des possibilits de dploiement de Subversion est impossible et n'est pas l'objectif de ce livre. Nous vous encourageons simplement valuer vos choix avec ces quelques pages ainsi qu'avec d'autres ressources en guise de rfrence afin de planifier correctement les oprations.

Choix du magasin de donnes


Depuis la version 1.1, Subversion offre deux types de stockage interne pour le magasin de donnes4 utilis par le dpt. Un des types de magasin de donnes conserve tout dans une base de donnes Berkeley DB (ou BDB) ; les dpts qui utilisent ce type de magasin sont qualifis de dpts grs par BDB ou dpts BDB . L'autre type de magasin stocke les donnes dans des fichiers ordinaires, en utilisant un format particulier. Les dveloppeurs de Subversion ont pris l'habitude d'appeler ce type de stockage FSFS5 une implmentation d'un systme de fichiers suivis en versions qui utilise le systme de fichiers natif du systme d'exploitation directement plutt que par l'intermdiaire d'une bibliothque de gestionnaire de base de donnes ou toute autre couche d'abstraction. Une comparaison des dpts utilisant Berkeley DB et FSFS fait l'objet du Tableau 5.1, Comparaison des magasins de donnes de dpts .

NdT : souvent dsign par backend en anglais (sans quivalent en franais) ou, ce qui peut tre source de confusion, le systme de fichiers (suivi en versions) 5 Souvent prononc feuzz-feuzz si Jack Repenning en parle (ce livre, cependant, suppose que le lecteur pense eff-ess-eff-ess ).

120

Administration d'un dpt

Tableau 5.1. Comparaison des magasins de donnes de dpts


Catgorie Fiabilit Fonctionnalit Intgrit des donnes Berkeley DB FSFS Trs fiable quand dploy Les vieilles versions avaient correctement ; Berkeley DB quelques bogues (rarement 4.4 apporte l'auto-restauration dmontrs) qui dtruisaient des donnes Forte ; les plantages et les Quasiment insensible problmes de droits peuvent laisser la base de donnes dans un tat instable, ncessitant le recours aux procdures de restauration issues de la journalisation Oui Oui Oui

Sensibilit aux interruptions

Accessibilit

Utilisable depuis un montage Non en lecture seule Stockage indpendant de la Non plate-forme Utilisable sur des systmes de Gnralement non fichiers en rseau

Gestion des droits pour les Sensible aux problmes de Contourne les problmes de groupes umask de l'utilisateur ; c'est umask mieux si un seul utilisateur y accde Extensibilit Utilisation des disques sur le Plus grande (surtout si les Plus faible dpt fichiers de journalisation ne sont pas purgs) Nombre de rvisions Base de donnes, pas de De vieux systmes de fichiers problme fonctionnent moins bien lorsqu'il y a plusieurs milliers d'entres dans un seul rpertoire Plus rapide

Rpertoires avec beaucoup de Plus lent fichiers Performances Extraire la dernire rvision Grosses propagations Globalement plus lent, mais mais cette lenteur est rpartie sur toute la dure de la propagation

Pas de diffrence significative Pas de diffrence significative Globalement plus rapide, mais le dlai de finalisation peut amener le client considrer que sa requte a expir avant qu'il ne reoive la rponse

Chaque type de magasin de donnes a ses avantages et ses inconvnients. Aucun n'est plus officiel que l'autre, mme si le nouveau FSFS est le magasin par dfaut depuis Subversion 1.2. Les deux sont suffisamment fiables pour y stocker vos donnes suivies en versions en toute confiance. Mais comme l'indique le Tableau 5.1, Comparaison des magasins de donnes de dpts , FSFS est un peu plus souple dployer. Plus de souplesse signifie que vous devez y mettre un peu plus du vtre pour faire des erreurs lors du dploiement. C'est pourquoi, en plus du fait que ne pas utiliser Berkeley DB permet de compter un composant de moins dans le systme, aujourd'hui, presque tout le monde utilise FSFS lors de la cration de nouveaux dpts. Heureusement, la plupart des programmes qui accdent aux dpts Subversion ignorent royalement quel type de magasin de donnes est utilis. Et vous n'tes mme pas prisonnier de votre premier choix de magasin : si vous changez d'avis plus tard, Subversion offre diffrentes faons de migrer les donnes de votre dpt dans un autre dpt utilisant un magasin de donnes diffrent. Nous en reparlons plus loin dans ce chapitre. Les paragraphes suivants abordent plus en dtail les diffrents types de magasins de donnes disponibles.

121

Administration d'un dpt

Berkeley DB
Lors de la conception initiale de Subversion, les dveloppeurs ont dcid d'utiliser le gestionnaire de bases de donnes Berkeley DB pour tout un tas de raisons, entre autres sa licence Open Source, son support des transactions, sa fiabilit, ses performances, la simplicit de son interface de programmation (API), le bon support des processus lgers (threads), le support des curseurs, etc. Le gestionnaire de bases de donnes Berkeley DB apporte un support rel des transactions (c'est peut-tre sa fonctionnalit la plus puissante). Si de nombreux processus accdent en mme temps au dpt, ils n'ont pas se soucier d'ventuelles corruptions de donnes de la part des autres processus. L'isolement cr par le systme de transaction est tel que, pour une opration donne, Subversion voit une base de donnes statique pas une base de donnes en perptuel changement en raison des autres processus et peut donc prendre des dcisions partir de cette perspective. Si la dcision entrane un conflit avec ce que fait un autre processus, l'opration complte est annule, tout se passe comme si elle n'avait jamais eu lieu et Subversion essaie une nouvelle fois son opration sur la base de donnes mise jour (qui apparat toujours statique). Une autre fonctionnalit phare du gestionnaire de bases de donnes Berkeley DB est la sauvegarde chaud la capacit de sauvegarder l'environnement de la base de donnes sans la couper du rseau. Nous voyons comment raliser une sauvegarde de votre dpt plus loin dans ce chapitre (dans la section intitule Sauvegarde d'un dpt ), mais le bnfice de pouvoir faire des copies oprationnelles de vos dpts sans interruption de service doit vous sauter aux yeux. Le gestionnaire de bases de donnes Berkeley DB est aussi trs fiable quand il est utilis correctement. Subversion utilise les fonctions de journalisation du gestionnaire de bases de donnes Berkeley DB, ce qui veut dire que la base de donnes consigne d'abord dans un fichier de journalisation situ sur disque chaque modification qu'elle s'apprte effectuer, puis effectue la modification elle-mme. Cela garantit que si quelque chose se passe mal, le gestionnaire de base de donnes peut revenir un point de contrle prcdent un point prcis des fichiers de journalisation dont il sait qu'il n'est pas corrompu et rejouer les transactions jusqu' ce que les donnes soient dans un tat oprationnel. Voir la section intitule Gestion de l'espace disque plus loin dans ce chapitre pour plus de dtails sur les fichiers de journalisation Berkeley DB. Mais chaque mdaille son revers et nous devons vous avertir de quelques limitations du gestionnaire de bases de donnes Berkeley DB. Premirement, les environnements du gestionnaire de bases de donnes Berkeley DB ne sont pas portables. Vous ne pouvez pas simplement copier un dpt Subversion qui a t cr sur un systme Unix vers un systme Windows et esprer qu'il fonctionne. Bien que la majeure partie de la base de donnes Berkeley DB soit indpendante de l'architecture, d'autres aspects de l'environnement ne le sont pas. Deuximement, Subversion utilise le gestionnaire de bases de donnes Berkeley DB de telle faon que cela ne fonctionne pas sur un systme Windows 95/98 : si vous avez besoin d'hberger un dpt gr par BDB sur une machine Windows, adoptez Windows 2000 ou plus. Alors que le gestionnaire de bases de donnes Berkeley DB prtend fonctionner correctement sur un systme de fichiers en rseau, pour peu que celui-ci respecte des caractristiques particulires6, la plupart des systmes de fichiers en rseau et des systmes ddis n'atteignent pas ces pr-requis. Et en aucun cas il ne vous est possible de partager ce dpt sur un systme de fichiers en rseau entre plusieurs clients (alors que c'est quand mme l'intrt principal d'un dpt accessible sur un partage rseau). Si vous tentez d'utiliser le gestionnaire de bases de donnes Berkeley DB sur un systme de fichiers en rseau non compatible, les rsultats sont imprvisibles : vous vous apercevrez peut-tre immdiatement de mystrieuses erreurs, mais il se peut qu'il se passe des mois avant que vous ne dcouvriez que votre base de donnes de dpt est corrompue. Songez srieusement utiliser un magasin FSFS pour les dpts qui doivent tre hbergs sur un partage rseau. Finalement, parce que la bibliothque du gestionnaire de bases de donnes Berkeley DB est directement incluse dans Subversion, elle est plus sensible aux interruptions qu'une base de donnes relationnelle classique. La plupart des systmes SQL, par exemple, disposent d'un processus serveur ddi qui coordonne tous les accs aux tables. Si un programme qui accde aux tables plante pour une raison ou une autre, le processus serveur de la base de donnes s'en aperoit et fait le mnage. Et comme le processus serveur est le seul processus accdant rellement aux tables, les applications n'ont pas se soucier des conflits de droits. Cependant, ce n'est pas le cas avec le gestionnaire de bases de donnes Berkeley DB. Subversion (et les programmes utilisant les bibliothques de Subversion) accdent aux tables directement, ce qui veut dire que le plantage d'un programme peut laisser la base de donnes dans un tat temporairement incohrent et inaccessible. Quand cela arrive, un administrateur doit demander au gestionnaire de bases de donnes Berkeley DB de revenir un point de contrle, ce qui est assez ennuyeux. D'autres incidents peuvent faire planter la base de donnes, comme des conflits entre programmes pour la
6

Berkeley DB requiert que le systme de fichiers sous-jacent implmente strictement la smantique POSIX sur les verrous et, plus important encore, la possibilit de projeter les fichiers directement en mmoire vive.

122

Administration d'un dpt

possession ou les droits sur les fichiers de la base de donnes. La version 4.4 du gestionnaire de bases de donnes Berkeley DB permet Subversion (version 1.4 ou plus) de restaurer un environnement Berkeley DB automatiquement et de manire transparente en cas de besoin. Quand un processus Subversion se greffe sur l'environnement d'un dpt Berkeley DB, il utilise un mcanisme d'enregistrement pour dtecter d'ventuels problmes de dconnexion antrieurs , effectue les restaurations ncessaires puis passe la suite comme si de rien n'tait. Cela n'limine pas compltement les plantages du dpt, mais les actions humaines ncessaires pour revenir une situation normale sont considrablement rduites. Ainsi, bien qu'un dpt Berkeley DB soit rapide et capable de monter en puissance, il faut privilgier une utilisation par un seul processus serveur tournant avec une identit unique (comme les serveurs Apache httpd ou svnserve : voir le Chapitre 6, Configuration du serveur) un accs par de nombreux utilisateurs via des URL file:// ou svn+ssh://. Si de multiples utilisateurs doivent avoir accs un dpt Berkeley DB, lisez la section intitule Accs au dpt par plusieurs mthodes plus loin dans ce chapitre.

FSFS
Mi-2004, un deuxime type de stockage pour le dpt, qui ne fait pas appel une base de donnes, a fait son apparition. Un dpt FSFS stocke les changements associs une rvision dans un fichier unique, ce qui fait que l'ensemble des rvisions du dpt se trouvent dans un seul sous-rpertoire rempli de fichiers numrots. Les transactions sont cres, en tant que fichiers individuels, dans des sous-rpertoires spars. Une fois la transaction termine, le fichier de transaction est renomm et plac dans le rpertoire des rvisions, ce qui garantit l'atomicit des propagations. Et puisqu'un fichier de rvision est permanent et non modifiable, le dpt peut galement tre sauvegard chaud comme un dpt BDB. Les fichiers de rvision FSFS dcrivent, pour une rvision donne, la structure des rpertoires, le contenu des fichiers et les deltas entre les fichiers et les autres arborescences de rvisions. Contrairement une base de donnes Berkeley DB, le format de stockage est portable, transfrable entre diffrents systmes d'exploitation et n'est pas sensible l'architecture CPU. Comme il n'y a pas de journalisation ou de fichiers en mmoire partage, le dpt est accessible sans risque via un partage de fichiers sur le rseau ou depuis un environnement en lecture seule. L'absence des en-ttes lis une base de donnes rduit aussi quelque peu la taille globale du dpt. FSF diffre galement du point de vue des performances. Quand vous propagez un rpertoire comptant un nombre de fichiers trs lev, FSFS est capable d'ajouter plus rapidement les lments du rpertoire. D'un autre ct, FSFS crit la dernire version d'un fichier sous forme de delta par rapport la version prcdente, par consquent une extraction de l'arborescence la plus rcente est un peu plus lente que l'obtention des fichiers entiers stocks dans la rvision HEAD d'une base de donnes Berkeley DB. FSFS est galement plus long lors de la fin de la propagation, ce qui peut amener le client considrer, dans des cas extrmes, que sa requte a expir avant qu'il ne reoive la rponse. La diffrence la plus importante reste quand mme la rsistance aux plantages lorsque quelque chose va mal. Si un processus qui utilise une base de donnes Berkeley DB rencontre un problme de droits ou plante soudainement, la base de donnes risque de se retrouver dans un tat instable jusqu' ce qu'un administrateur la restaure. Si la mme chose arrive un processus utilisant un dpt FSFS, le dpt n'est en rien affect. Au pire, quelques donnes de transaction sont gares. Le seul vritable argument contre FSFS est sa relative immaturit face Berkeley DB. Berkeley DB a une histoire de plusieurs annes, avec une quipe de dveloppement ddie et, aujourd'hui, il est adoss la toute-puissante marque Oracle7. FSFS est de conception plus rcente. Avant la version 1.4 de Subversion apparaissaient de temps en temps quelques bogues assez srieux concernant l'intgrit des donnes qui, bien que n'arrivant que dans de trs rares cas, taient bien rels. Ceci dit, FSFS est rapidement devenu le magasin de donnes de rfrence pour quelques-uns des plus vastes dpts Subversion publics et privs et il promet de rendre globalement plus facile le passage Subversion.

Cration et configuration d'un dpt


Dans ce chapitre (dans la section intitule Stratgies de dploiement d'un dpt ), nous avons pass en revue quelques dcisions importantes prendre avant de crer et de configurer votre dpt Subversion. Maintenant nous allons enfin mettre les mains dans le cambouis ! Dans cette section, nous voyons comment crer un dpt Subversion et comment le configurer pour qu'il effectue des actions personnalises lorsque certains vnements ont lieu.

Oracle a achet Sleepycat et son logiciel vedette, Berkeley DB, le jour de la Saint Valentin 2006.

123

Administration d'un dpt

Cration d'un dpt


La cration d'un dpt Subversion est une tche incroyablement simple. L'utilitaire svnadmin, fourni avec Subversion, dispose d'une sous-commande qui est justement destine cela (svnadmin create) : $ # Crer un dpt $ svnadmin create /var/svn/depot $ Cette commande cre un dpt dans le rpertoire /var/svn/depot avec le magasin de donnes par dfaut. Avant la version 1.2 de Subversion, le choix par dfaut tait l'utilisation d'une base de donnes Berkeley DB ; maintenant c'est FSFS. Vous pouvez choisir explicitement le type de systme de fichiers avec l'option --fs-type qui accepte comme argument soit fsfs, soit bdb. $ # Crer un dpt FSFS $ svnadmin create --fs-type fsfs /var/svn/depot $

$ # Crer un dpt Berkeley DB $ svnadmin create --fs-type bdb /var/svn/depot $ Aprs l'excution de cette simple commande, vous disposez d'un dpt Subversion. Le chemin en argument de svnadmin est juste un chemin classique du systme de fichiers, pas une URL comme celles que le client svn utilise pour spcifier un dpt. Les commandes svnadmin et svnlook sont toutes les deux considres comme des utilitaires cot serveur : elles sont utilises sur la machine qui hberge le dpt pour examiner ou modifier certains aspects du dpt et ne sont pas capables d'effectuer des actions via le rseau. Une erreur classique des nouveaux utilisateurs de Subversion est d'essayer de passer une URL (mme locale comme file://) ces deux programmes. Dans le sous-rpertoire db/ de votre dpt, vous trouvez l'implmentation du systme de fichiers suivi en versions. Le nouveau systme de fichiers suivi en versions de votre dpt commence sa vie la rvision 0, qui est dfinie comme contenant le rpertoire racine (/) et lui seul. Initialement, la rvision 0 possde une seule proprit de rvision, svn:date, dont la valeur est la date de cration du dpt. Maintenant que vous disposez d'un dpt, il est temps de le personnaliser. Alors que certaines parties d'un dpt Subversion sont conues pour tre examines et modifies la main (comme les fichiers de configuration et les procdures automatiques), vous ne devez pas (et vous ne devriez pas avoir besoin de) modifier les autres parties la main . L'outil svnadmin est cens tre suffisant pour toutes les modifications apporter votre dpt, mais vous pouvez galement vous servir d'outils tiers (comme la suite d'outils Berkeley DB) pour configurer les parties adquates du dpt. Ne tentez surtout pas de manipuler manuellement l'historique du suivi de versions en touchant aux fichiers du magasin de donnes du dpt !

Mise en place des procdures automatiques


Une procdure automatique (hook en anglais) est un programme activ par certains vnements du dpt, comme la cration d'une nouvelle rvision ou la modification d'une proprit non suivie en versions. Certaines procdures automatiques (appeles pre hooks ) sont dclenches avant l'opration sur le dpt et permettent la fois de rendre compte de ce qui va se passer et d'empcher que cela se passe. D'autres procdures automatiques (appeles post hooks ) sont dclenches aprs la fin d'un vnement et servent effectuer des tches de surveillance (mais pas de modification) du dpt. Chaque procdure automatique reoit suffisamment d'informations pour dterminer la nature de l'vnement, les modifications proposes (ou effectues) du dpt et le nom d'utilisateur de la personne qui a dclench l'vnement. 124

Administration d'un dpt

Le sous-rpertoire hooks contient, par dfaut, des modles pour diverses procdures automatiques : $ ls depot/hooks/ post-commit.tmpl post-lock.tmpl post-revprop-change.tmpl $

post-unlock.tmpl pre-commit.tmpl pre-lock.tmpl

pre-revprop-change.tmpl pre-unlock.tmpl start-commit.tmpl

Il y a un modle pour chaque type de procdure automatique que le dpt Subversion sait prendre en charge ; en examinant le contenu de ces modles de scripts, vous pouvez voir ce qui dclenche le script et quelles donnes sont passes en paramtres. Vous trouvez galement dans beaucoup de ces scripts des exemples d'utilisation permettant de raliser des tches rcurrentes utiles, en conjonction avec d'autres programmes fournis avec Subversion. Concrtement, pour activer une procdure automatique, il suffit de placer dans le rpertoire depot/hooks un programme ou un script excutable, qui sera invoqu via le nom de la procdure automatique (comme start-commit pour le dbut d'une propagation ou post-commit pour la fin d'une propagation). Sur les plates-formes Unix, cela veut dire fournir un programme ou un script (pouvant tre un script shell, un programme Python, l'excutable binaire d'un programme en C ou tout un tas d'autres choses) dont le nom est exactement le nom de la procdure automatique. Bien sr, les modles qui sont fournis ne le sont pas juste titre d'information. Le moyen le plus facile pour mettre en place une procdure automatique sur les plates-formes Unix consiste tout simplement copier le fichier du modle adquat vers un nouveau fichier qui n'aura pas l'extension .tmpl, d'adapter son contenu votre environnement et de vous assurer qu'il est excutable. Sous Windows, comme l'extension du fichier dtermine s'il est excutable ou non, vous devez fournir un programme dont la base du nom est le nom de la procdure automatique et dont l'extension est l'une de celles reconnue comme excutable par Windows, comme .exe pour les programmes ou .bat pour les fichiers batch. Pour des raisons de scurit, le dpt Subversion excute les procdures automatiques avec un environnement vide c'est--dire sans aucune variable d'environnement dfinie, mme pas $PATH (ou %PATH% sous Windows). C'est ainsi que de nombreux administrateurs sont perplexes lorsque leurs programmes fonctionnent correctement la main mais pas dans Subversion. Assurez-vous de dfinir explicitement toutes les variables d'environnement ncessaires dans votre procdure automatique et/ou d'utiliser des chemins absolus vers les programmes. Les procdures automatiques de Subversion sont lances par l'utilisateur propritaire du processus ayant accs au dpt Subversion. La plupart du temps, on accde au dpt via un serveur Subversion, donc cet utilisateur est le mme que celui qui fait tourner le processus serveur sur le systme. Les procdures automatiques elles-mmes doivent tre configures pour tre excutables, au niveau du systme d'exploitation, par ledit utilisateur. Cela implique galement que tout programme ou fichier (y compris le dpt Subversion) utilis directement ou indirectement par la procdure automatique l'est par ledit utilisateur. En d'autres termes, faites bien attention aux problmes de droits d'excution qui peuvent empcher les scripts d'effectuer correctement les tches pour lesquelles ils ont t conus. Il y a plusieurs procdures automatiques implmentes dans le dpt Subversion et vous pouvez obtenir des dtails sur chacune d'elles dans la section intitule Procdures automatiques du dpt . En tant qu'administrateur du dpt, vous devez dcider quelles procdures automatiques vous voulez mettre en uvre (c'est--dire les nommer correctement et leur donner les droits appropris) et de quelle manire. Lorsque vous prennez cette dcision, gardez l'esprit l'architecture de votre dpt. Par exemple, si vous vous servez de la configuration du serveur pour dterminer les droits de propagation sur votre dpt, vous n'avez pas besoin de mettre en place un contrle d'accs de ce style via les procdures automatiques. Les exemples de procdures automatiques librement accessibles sont lgions, fournis par la communaut Subversion ellemme ou par d'autres. Ces scripts couvrent une large varit de besoins tels que le contrle d'accs basique, le contrle de cohrence, l'intgration avec les outils de suivis de bogues, les notifications de propagation par e-mail ou flux RSS, etc. Sinon, si vous voulez crire votre propre programme, penchez-vous sur le Chapitre 8, Intgration de Subversion. Bien que les procdures automatiques soient capables de faire tout et n'importe quoi, leurs auteurs devraient faire preuve de modration dans un domaine prcis : ne modifiez pas une transaction de propagation en utilisant une procdure automatique. Bien que cela soit tentant de corriger automatiquement certaines erreurs, raccourcis ou violations de politique constates dans les fichiers propags, cela peut causer des problmes. Subversion conserve en cache, ct client, certaines parties des donnes du dpt et si vous modifiez une transaction de propagation de cette faon, ces caches seront prims sans que cela ne puisse tre dtect. De telles incohrences peuvent aboutir des comportements surprenants et inattendus. Au lieu de modifier la transaction, contentez-vous de vrifier la 125

Administration d'un dpt

transaction dans la procdure automatique pre-commit et rejetez-la si elle ne remplit pas les conditions ncessaires. Entre autre avantages, vos utilisateurs prendront ainsi des habitudes de travail empreintes de respect des procdures et de qualit.

Configuration de la base de donnes Berkeley DB


Un environnement Berkeley DB peut encapsuler une ou plusieurs bases de donnes, fichiers de journalisation, de rgion et de configuration. L'environnement Berkeley DB a un ensemble propre de valeurs configures par dfaut comme par exemple le nombre de verrous autoriss un instant donn, la taille maximum des fichiers de journalisation, etc. La logique du systme de fichiers Subversion ajoute des valeurs par dfaut pour diffrentes options de configuration du gestionnaire Berkeley DB. Cependant, il se peut que votre dpt ncessite une configuration diffrente en raison de l'architecture de vos donnes et des mthodes d'accs. Les concepteurs du gestionnaire de bases de donnes Berkeley DB comprennent que les besoins varient entre les diffrentes applications et environnements de bases de donnes, c'est pourquoi ils fournissent des mcanismes pour modifier, l'excution, une grande partie des valeurs des options de configuration. BDB vrifie la prsence d'un fichier nomm DB_CONFIG dans le rpertoire d'environnement ( savoir le sous-rpertoire db du dpt) et en extrait les valeurs des options. Subversion cre ce fichier lorsqu'il cre le reste du dpt. Le fichier contient initialement des options par dfaut ainsi que des pointeurs vers la documentation en ligne de Berkeley DB afin de vous renseigner sur l'utilisation de ces options. Bien sr, vous tes libre d'ajouter n'importe quelle option prise en compte par Berkeley DB dans votre fichier DB_CONFIG. Soyez juste attentif au fait que, bien que Subversion n'essaie jamais de lire ou interprter le contenu de ce fichier et qu'il n'en utilise pas directement la configuration, les changements induits dans le comportement de Berkeley DB ne doivent pas aller l'encontre du comportement attendu par Subversion. Par ailleurs, les changements effectus dans DB_CONFIG ne sont pris en considration qu'aprs avoir effectu une restauration de l'environnement de la base de donnes avec la commande svnadmin recover.

Maintenance d'un dpt


Assurer la maintenance d'un dpt Subversion peut tre intimidant, certainement parce que les systmes qui comprennent une base de donnes sont complexes. Il faut pour cela connatre les outils ceux dont on dispose, quand les utiliser et comment. Cette section vous prsente les outils fournis par Subversion pour assurer l'administration du dpt et dcrit leur maniement pour raliser des oprations telles que migrations de donnes, mises jour, sauvegardes et nettoyages.

Bote outils de l'administrateur


Subversion fournit une poigne d'utilitaires pour crer, inspecter, modifier et rparer votre dpt. tudions de plus prs chacun de ces outils. Ensuite, nous abordons rapidement quelques utilitaires inclus dans le gestionnaire de bases de donnes Berkeley DB qui fournissent des fonctionnalits spcifiques au magasin de donnes de votre dpt qui ne sont pas assures par les propres outils de Subversion.

svnadmin
Le programme svnadmin est le meilleur ami de l'administrateur de dpts. En plus de fournir la possibilit de crer des dpts Subversion, ce programme vous permet d'effectuer de nombreuses oprations de maintenance sur ces dpts. La syntaxe de svnadmin est similaire celle des autres programmes en ligne de commande de Subversion : $ svnadmin help usage gnral : svnadmin SOUS_COMMANDE DPT [ARGS & OPTIONS ...] Entrer 'svnadmin help <sous-commande>' pour une aide spcifique. Entrer 'svnadmin --version' pour avoir la version et les modules de stockages. Sous-commandes disponibles : crashtest create deltify Au dbut de ce chapitre (dans la section intitule Cration d'un dpt ), nous vous avons prsent la sous-commande 126

Administration d'un dpt

svnadmin create. La plupart des autres sous-commandes svnadmin sont couvertes plus loin dans ce chapitre. Vous pouvez galement consulter la section intitule svnadmin pour une liste complte des sous-commandes et des fonctionnalits qu'elles apportent.

svnlook
svnlook est un outil de Subversion pour examiner les diffrentes rvisions et transactions (qui sont des rvisions en cours de cration) dans un dpt. Aucune modification n'est faite au dpt par cet outil. svnlook est gnralement utilis par les procdures automatiques du dpt pour signaler les changements qui vont tre propags (dans le cas de la procdure automatique pre-commit) ou qui viennent d'tre propags (dans le cas de la procdure automatique post-commit). Un administrateur peut tre amen utiliser cet outil des fins de diagnostic. La syntaxe de svnlook est particulirement simple : $svnlook help usage gnral : svnlook SOUS_COMMANDE CHEMIN_DPT [ARGS & OPTIONS...] Note : Quand --revision ou --transaction ne sont pas prcises, les souscommandes qui en ont besoin utilisent la rvision la plus rcente. Entrer 'svnlook help <sous-commande>' pour une aide spcifique. Entrer 'svnlook --version' pour avoir la version et les modules de stockage. La plupart des sous-commandes svnlook peuvent tre appliques soit une rvision soit une arborescence de transaction, affichant les informations propos de l'arborescence elle-mme ou les diffrences par rapport la rvision prcdente du dpt. Pour spcifier quelle rvision ou quelle transaction examiner, utilisez respectivement les options --revision (-r) et --transaction (-t). En l'absence des options --revision (-r) ou --transaction (-t), svnlook examine la rvision la plus rcente (la rvision HEAD) du dpt. Ainsi, les deux commandes suivantes font exactement la mme chose si la rvision la plus rcente du dpt situ l'emplacement /var/svn/depot porte le numro 19 : $ svnlook info /var/svn/depot $ svnlook info /var/svn/depot -r 19 Signalons une exception ces rgles concernant les sous-commandes : la sous-commande svnlook youngest ne prend aucune option et affiche simplement le numro de la rvision la plus rcente du dpt : $ svnlook youngest /var/svn/depot 19 $

Gardez l'esprit que les seules transactions que vous pouvez examiner sont celles qui n'ont pas t propages. La plupart des dpts ne comportent pas de transactions de ce type parce que les transactions sont habituellement soit propages (auquel cas vous devriez y avoir accs sous la forme de rvisions via l'option --revision (-r)), soit annules et supprimes. La sortie de svnlook est conue pour tre la fois lisible par un humain et analysable par une machine. Prenons, par exemple, la sortie de la sous-commande svnlook info : $ svnlook info /var/svn/depot sally 2002-11-04 09:29:13 -0600 (lun. 04 nov. 2002) 27 J'ai ajout le traditionnel Arbre grec. $ La sortie de svnlook info est constitue des lments suivants, par ordre d'apparition : 127

Administration d'un dpt

1. L'auteur, suivi d'un passage la ligne. 2. La date, suivie d'un passage la ligne. 3. Le nombre de caractres du message de propagation, suivi d'un passage la ligne. 4. Le message de propagation lui-mme, suivi d'un passage la ligne. Cette sortie est lisible par un humain, ce qui veut dire que les lments tels que la date sont reprsents par du texte simple au lieu d'un obscur code (comme le nombre de nanosecondes depuis le passage aux nouveaux francs). Mais cette sortie est aussi analysable par une machine parce que le message de propagation peut comporter plusieurs lignes et n'est pas limit en taille, svnlook affiche la longueur du message avant le message lui-mme. Cela permet aux scripts et autres utilitaires faisant appel cette commande de prendre des dcisions opportunes propos du message de propagation, comme savoir combien de mmoire allouer pour le message ou au moins savoir combien d'octets sauter dans le cas o les donnes affiches par svnlook ne sont pas les dernires donnes du flux. svnlook peut rpondre un tas d'autres requtes : afficher des sous-ensembles des informations prcdemment cites, lister rcursivement les arborescences suivies en versions des rpertoires, lister les chemins modifis lors de telle rvision ou transaction, afficher les diffrences de contenu et de proprits pour les fichiers et rpertoires, etc. Reportez-vous la section intitule svnlook pour la liste complte des fonctionnalits offertes par svnlook.

svndumpfilter
Bien que ce ne soit pas l'outil le plus utilis mis disposition de l'administrateur, svndumpfilter fournit une fonctionnalit d'un genre trs particulier qui est d'une grande utilit : la possibilit de modifier rapidement et facilement des flux de l'historique du dpt Subversion en agissant en tant que filtre sur les chemins. La syntaxe de svndumpfilter est la suivante : $ svndumpfilter help usage gnral : svndumpfilter SOUS_COMMANDE [ARGS & OPTIONS ...] Entrer 'svndumpfilter help <sous-commande>' pour l'aide spcifique. Entrer 'svndumpfilter --version' pour avoir le numro de version du programme. Sous-commandes disponibles : exclude include help (?, h) Il n'y a que deux sous-commandes intressantes : svndumpfilter exclude et svndumpfilter include. Elles vous permettent de choisir entre l'inclusion implicite et l'inclusion explicite des chemins dans le flux. Vous en saurez plus sur ces sous-commandes et sur l'utilit si particulire de svndumpfilter plus loin dans ce chapitre, dans la section intitule Filtrage de l'historique d'un dpt .

svnsync
Le programme svnsync, apparu dans la version 1.4 de Subversion, fournit toutes les fonctionnalits requises pour faire fonctionner un miroir en lecture seule d'un dpt Subversion. Ce programme a une et une seule fonction : transfrer l'historique d'un dpt vers un autre dpt. Et, bien qu'il y ait diffrentes manires de faire, sa force rside dans sa capacit de travailler distance : les dpts source et destination peuvent tre sur deux ordinateurs diffrents et svnsync sur un troisime. Comme vous vous en doutez, svnsync possde une syntaxe trs proche des autres programmes dj mentionns dans ce chapitre : $svnsync help usage gnral : svnsync SOUS_COMMANDE DPT [ARGS & OPTIONS ...] Entrer 'svnsync help <sous-commande>' pour une aide spcifique. Entrer 'svnsync --version' pour la version et les modules d'accs (RA). Sous-commandes disponibles : 128

Administration d'un dpt

initialize (init) synchronize (sync) copy-revprops help (?, h) $ Nous revenons en dtail sur la rplication de dpts avec svnsync plus loin dans ce chapitre (voir la section intitule Rplication d'un dpt ).

fsfs-reshard.py
Bien qu'il ne fasse pas officiellement partie des outils Subversion, le script fsfs-reshard.py (situ dans le rpertoire tools/ server-side du code source de Subversion) est un outil particulirement utile l'administrateur pour optimiser les performances de dpts Subversion utilisant un magasin de donnes FSFS. Les dpts FSFS contiennent des fichiers qui dcrivent les changements apports dans une seule rvision et des fichiers qui contiennent les proprits de rvision associes une seule rvision. Les dpts crs avec Subversion avant la version 1.5 conservent ces fichiers dans deux rpertoires : un pour chaque type de fichiers. Au fur et mesure des rvisions propages dans le dpt, Subversion dpose de plus en plus de fichiers dans ces deux rpertoires au bout d'un certain temps, le nombre de fichiers dans chaque rpertoire peut devenir particulirement lev. On a pu constater dans cette situation des problmes de performances sur certains systmes de fichiers en rseau. Subversion 1.5 cre les dpts FSFS en utilisant un schma lgrement diffrent pour lequel ces deux rpertoires sont rpartis (sharded en anglais, d'o le nom du script) dans plusieurs sous-rpertoires. Cela peut rduire de faon drastique le temps de recherche d'un de ces fichiers et, en consquence, amliorer la performance globale de Subversion pour la lecture du dpt. Le nombre de sous-rpertoires utiliss pour hberger ces fichiers est d'ailleurs configurable et c'est l qu'intervient le script fsfsreshard.py. Le script remanie la structure du dpt pour se conformer au nombre de sous-rpertoires demands. C'est particulirement utile pour convertir un vieux dpt Subversion vers le nouveau schma rparti de Subversion 1.5 (ce que Subversion ne fait pas automatiquement pour vous) ou pour modifier cette valeur dans un dpt dj rparti.

Utilitaires Berkeley DB
Si vous utilisez un dpt avec une base Berkeley DB, la fois les donnes et la structure de votre systme de fichiers suivis en version rsident dans un ensemble de tables de la base de donnes qui sont situes dans le sous-rpertoire db/ de votre dpt. Ce sous-rpertoire est un rpertoire d'environnement classique de base de donnes Berkeley DB et n'importe quel outil de base de donnes Berkeley, gnralement fourni avec la distribution Berkeley, peut y tre utilis. Pour un usage quotidien, ces outils ne sont pas ncessaires. La plupart des fonctionnalits dont les dpts Subversion ont besoin ont t dupliques dans l'outil svnadmin. Par exemple, svnadmin list-unused-dblogs et svnadmin list-dblogs fournissent un sous-ensemble des fonctionnalits offertes par l'utilitaire db_archive de Berkeley DB et svnadmin recover reproduit les utilisations courantes de l'utilitaire db_recover. Cependant, il reste quelques utilitaires Berkeley DB que vous pourriez trouver utiles. Les programmes db_dump et db_load fonctionnent avec, pour la lecture et l'criture respectivement, un format de fichier personnalis qui dcrit les cls et les valeurs d'une base de donnes Berkeley DB. Puisque les bases de donnes Berkeley DB ne sont pas portables d'une architecture de machine une autre, ce format est utile pour transfrer les bases de donnes entre deux machines, indpendamment de l'architecture et du systme d'exploitation. Comme nous le dcrivons plus loin dans ce chapitre, vous pouvez aussi utiliser svnadmin dump et svnadmin load pour faire la mme chose, mais db_dump et db_load peuvent accomplir certaines tches tout aussi bien et beaucoup plus vite. Ils peuvent aussi tre utiles si un expert Berkeley DB, pour une raison ou pour une autre, doit manipuler les donnes directement dans la base de donnes d'un dpt BDB (les utilitaires Subversion ne le vous permettent pas). De plus, l'utilitaire db_stat peut fournir des informations utiles sur l'tat de votre environnement Berkeley DB, y compris des statistiques dtailles concernant les sous-systmes de verrouillage et de stockage. Pour davantage d'informations sur la suite d'outils Berkeley DB, consultez la documentation en ligne sur le site Internet d'Oracle, dans la section Berkeley DB : http://www.oracle.com/technology/documentation/berkeley-db/db/ (ce site est en anglais).

Correction des messages de propagation


Parfois un utilisateur se trompe dans son message de propagation (une faute d'orthographe ou une coquille, par exemple). Si le dpt est configur (en utilisant la procdure automatique pre-revprop-change, voir la section intitule Mise en place des procdures automatiques ) pour accepter les modifications de ce message aprs la fin de la propagation, l'utilisateur peut 129

Administration d'un dpt

corriger son message distance en utilisant svn propset (voir svn propset). Cependant, en raison de la possibilit de perte d'information irrmdiable, les dpts Subversion ne sont pas configurs, par dfaut, pour autoriser les modifications de proprits non suivies en versions sauf de la part d'un administrateur. Si un administrateur est amen changer un message de propagation, il peut le faire avec svnadmin setlog. Cette commande change le message de propagation (la proprit svn:log) d'une rvision donne du dpt, la nouvelle valeur tant lue dans un fichier. $ echo "Voici le nouveau message de propagation, en version corrige" > nouveau-message.txt $ svnadmin setlog mon-depot nouveau-message.txt -r 388 La commande svnadmin setlog, par dfaut, possde les mmes garde-fous pour empcher de modifier des proprits non suivies en versions qu'un client distant les procdures automatiques pre- et post-revprop-change sont toujours actives et doivent donc tre configures afin d'accepter ce type de changement. Mais un administrateur peut contourner ces protections en passant l'option --bypass-hooks la commande svnadmin setlog. Souvenez-vous cependant que, en contournant les procdures automatiques, vous tes susceptible de ne pas activer certaines actions telles que la notification par email du changement des proprits, la sauvegarde par les systmes qui surveillent les proprits non suivies en versions, etc. En d'autres termes, faites particulirement attention aux changements que vous apportez et la manire dont vous le faites.

Gestion de l'espace disque


Bien que le cot de stockage ait diminu de manire drastique ces dernires annes, l'utilisation de l'espace disque reste une des proccupations de l'administrateur qui doit suivre en versions de grandes quantits de donnes. Chaque lment de l'historique de chaque donne stocke dans un dpt actif doit tre sauvegard ailleurs, peut-tre mme de nombreuses fois dans le cas de sauvegardes tournantes. Il est utile de savoir quelles donnes d'un dpt Subversion doivent rester sur le site de production, lesquelles doivent tre sauvegardes et lesquelles peuvent tre supprimes sans risque.

conomie d'espace disque


Pour garder un dpt petit, Subversion utilise la diffrenciation (ou stockage diffrentiel ) l'intrieur du dpt lui-mme. La diffrenciation implique l'encodage de la reprsentation d'un groupe de donnes sous la forme d'un ensemble de diffrences avec un autre groupe de donnes. Si les deux groupes de donnes sont trs similaires, la diffrenciation conomise de l'espace pour le groupe diffrenci au lieu de prendre le mme espace que les donnes originales, le groupe occupe juste l'espace ncessaire pour dire : je ressemble l'autre groupe de donnes l-bas, sauf pour les deux ou trois changements qui suivent . Au final, l'espace occup par l'ensemble des donnes du dpt c'est--dire le contenu des fichiers suivis en versions est beaucoup plus petit que la reprsentation textuelle originale de ces donnes. Et pour les dpts crs avec Subversion en version 1.4 ou plus, l'espace conomis est encore plus important les reprsentations textuelles des fichiers sont prsent elles-mmes compresses. Comme toutes les donnes sujettes diffrenciation dans un dpt BDB sont stockes dans un unique fichier de la base de donnes, rduire la taille des donnes stockes ne rduit pas instantanment la taille du fichier de base de donnes lui-mme. Le gestionnaire de base de donnes Berkeley DB garde nanmoins une trace des zones non-utilises du fichier de base de donnes et utilise ces zones avant d'augmenter la taille du fichier de base de donnes. Ainsi, mme si la diffrenciation n'conomise pas immdiatement de la place, cela ralentit de faon drastique la croissance de la base de donnes.

Suppression des transactions mortes


Bien que rares, il y a des circonstances dans lesquelles le droulement d'une propagation Subversion peut mal se terminer, laissant derrire elle dans le dpt des restes de cette tentative de propagation : une transaction inacheve et toutes les modifications de fichiers et de rpertoires associes. Il peut y avoir plusieurs raisons cet chec : l'utilisateur a peut-tre brutalement interrompu l'opration ct client ou bien une coupure rseau s'est peut-tre produite au milieu de l'opration. Quoi qu'il en soit, des transactions mortes peuvent apparatre. Elles ne sont pas dangereuses mais elles consomment inutilement de l'espace disque. Un administrateur consciencieux se doit nanmoins de les supprimer. 130

Administration d'un dpt

Vous pouvez utiliser la commande svnadmin lstxns pour obtenir la liste des noms des transactions non encore rgles : $ svnadmin lstxns mon-depot 19 3a1 a45 $ Chaque lment de la sortie de cette commande peut tre pass en argument de svnlook (avec l'option --transaction (-t)) pour dterminer qui est l'origine de la transaction, quand elle a eu lieu et quels types de changements ont t effectus ces informations sont trs utiles pour savoir si on peut supprimer la transaction sans arrire pense ! Si vous dcidez effectivement de supprimer la transaction, son nom peut tre pass svnadmin rmtxns qui fera le nettoyage adquat. En fait, svnadmin rmtxns peut directement prendre en entre la sortie de svnadmin lstxns ! $ svnadmin rmtxns mon-depot `svnadmin lstxns mon-depot` $ Si vous utilisez ces deux sous-commandes ainsi, vous devriez envisager de rendre votre dpt temporairement indisponible pour les clients. De cette manire, personne ne peut initier une transaction lgitime avant que le nettoyage n'ait commenc. L'exemple Exemple 5.1, txn-info.sh (lister les transactions inacheves) contient quelques lignes de script shell qui peuvent produire les informations relatives chaque transaction inacheve de votre dpt.

Exemple 5.1. txn-info.sh (lister les transactions inacheves)


#!/bin/sh ### Produit les informations relatives toutes les transactions ### inacheves d'un dpt Subversion DEPOT="${1}" if [ "x$DEPOT" = x ] ; then echo "utilisation: $0 CHEMIN_VERS_LE_DEPOT" exit fi for TXN in `svnadmin lstxns ${DEPOT}`; do echo "---[ Transaction ${TXN} ]-------------------------------------------" svnlook info "${DEPOT}" -t "${TXN}" done

La sortie produite par ce script est, en bref, la concatnation des diffrents groupes d'informations fournis par svnlook info (voir la section intitule svnlook ) et ressemble ceci : $ txn-info.sh mon-depot ---[ Transaction 19 ]------------------------------------------sally 2001-09-04 11:57:19 -0500 (mar. 04 sep. 2001) 0 ---[ Transaction 3a1 ]------------------------------------------harry 2001-09-10 16:50:30 -0500 (lun. 10 sep. 2001) 39 Tentative de propagation dans un rseau pourri ---[ Transaction a45 ]------------------------------------------sally 2001-09-12 11:09:28 -0500 (mer. 12 sep. 2001) 0 131

Administration d'un dpt

$ Une transaction initie depuis longtemps correspond en gnral une propagation qui a t interrompue ou qui a chou. L'horodatage de la transaction peut fournir des informations intressantes par exemple, quelle est la probabilit qu'une transaction commence il y a neuf mois soit toujours active ? En rsum, la dcision de supprimer une transaction ne doit pas tre prise la lgre. D'autres sources d'informations comme les journaux d'Apache sur les erreurs et les accs, les journaux oprationnels de Subversion, l'historique des rvisions Subversion, etc. peuvent aider la prise de dcision. Et bien sr, l'administrateur peut toujours entrer en contact (par email, par exemple) avec l'auteur d'une transaction qui semble abandonne pour vrifier que c'est bien le cas.

Purge des fichiers de journalisation inutiliss de Berkeley DB


Jusqu' il y a peu, les plus gros consommateurs d'espace disque pour les dpts Subversion bass sur BDB taient les fichiers de journalisation dans lesquels le gestionnaire Berkeley DB effectue les pr-critures avant de modifier la base de donnes elle-mme. Ces fichiers recensent toutes les actions menes pour modifier la base de donnes, tape par tape ; alors que les fichiers de la base de donnes, un instant donn, ne refltent qu'un tat particulier, les fichiers de journalisation contiennent l'ensemble de tous les changements oprs entre chaque tat successif. Ainsi, ils peuvent grossir assez rapidement. Heureusement, partir de la version 4.2 de Berkeley DB, l'environnement de la base de donnes est capable de supprimer ses propres fichiers non utiliss automatiquement. Tout dpt cr en utilisant svnadmin compil avec la version 4.2 de Berkeley DB (ou suivantes) est configur pour supprimer automatiquement les fichiers de journalisation. Si vous ne voulez pas activer cette fonctionnalit, passez simplement l'option --bdb-log-keep la commande svnadmin create. Si vous oubliez de le faire ou si vous changez d'avis plus tard, ditez simplement le fichier DB_CONFIG qui se trouve dans le rpertoire db de votre dpt, commentez la ligne qui contient la directive set_flags DB_LOG_AUTOREMOVE puis lancez svnadmin recover sur votre dpt pour que le changement de configuration prenne effet. Reportez-vous la section intitule Configuration de la base de donnes Berkeley DB pour plus d'informations sur la configuration du gestionnaire de bases de donnes. Sans suppression automatique des fichiers de journalisation, les journaux vont s'accumuler au fur et mesure de l'utilisation de votre dpt. Cela peut tre considr comme une fonctionnalit du gestionnaire de bases de donnes vous devez tre capable de recrer entirement votre base de donnes en utilisant uniquement vos fichiers de journalisation, c'est pourquoi ceux-ci sont utiles pour le rtablissement de la base aprs une catastrophe. Mais en gnral, vous voudrez archiver les fichiers de journalisation qui ne sont plus utiliss par la base de donnes et ensuite les enlever du disque pour conserver de l'espace libre. Utilisez la commande svnadmin list-unused-dblogs pour avoir la liste des fichiers de journalisation inutiliss : $ svnadmin list-unused-dblogs /var/svn/depot /var/svn/depot/log.0000000031 /var/svn/depot/log.0000000032 /var/svn/depot/log.0000000033 $ rm `svnadmin list-unused-dblogs /var/svn/depot` ## espace disque rcupr !

Les dpts BDB qui utilisent les fichiers de journalisation pour les sauvegardes ou les rtablissements aprs incident ne doivent pas activer la suppression automatique des fichiers de journalisation. La reconstruction des donnes d'un dpt partir des fichiers de journalisation ne peut tre effectue que si tous les fichiers de journalisation sont accessibles. Si quelques fichiers de journalisation sont supprims du disque avant que le systme de sauvegarde n'ait pu les copier ailleurs, l'ensemble incomplet des fichiers de journalisation est totalement inutile.

Rtablissement de bases de donnes Berkeley DB


Comme indiqu dans la section intitule Berkeley DB , un dpt Berkeley DB peut se retrouver bloqu s'il n'est pas arrt proprement. Quand cela arrive, un administrateur doit faire revenir la base de donnes en arrire jusque dans un tat cohrent. Ceci ne concerne cependant que les dpts BDB si vous utilisez FSFS, vous n'tes pas concern. Et pour ceux qui utilisent Subversion 1.4 avec Berkeley DB version 4.4 ou plus, vous constaterez que Subversion est devenu beaucoup plus rsilient face ce type de problme. Certes, mais des plantages de dpts Berkeley DB arrivent encore et un administrateur doit savoir comment ragir dans de telles circonstances. 132

Administration d'un dpt

Pour protger les donnes du dpt, le gestionnaire Berkeley DB utilise un mcanisme de verrouillage. Ce mcanisme s'assure que les lments de la base de donnes ne sont pas modifis en mme temps par plusieurs utilisateurs et que chaque processus voit les donnes dans un tat cohrent lors de la lecture de la base de donnes. Quand un processus a besoin de modifier quelque chose dans la base de donnes, il vrifie d'abord l'existence d'un verrou sur les donnes concernes. Si les donnes ne sont pas verrouilles, le processus les verrouille, effectue les changements qu'il veut puis dverrouille les donnes. Les autres processus sont obligs d'attendre que le verrou soit libr avant d'tre autoriss accder aux donnes de cette zone (ceci n'a rien voir avec les verrous que vous, utilisateur, pouvez appliquer sur les fichiers suivis en versions dans le dpt ; nous essayons de lever l'ambigut cre par l'emploi de cette terminologie commune dans l'encadr Les trois types de verrous .) Au cours de l'utilisation de votre dpt Subversion, des erreurs fatales ou des interruptions peuvent empcher un processus de supprimer des verrous qu'il a placs dans la base de donnes. Cela conduit des plantages du magasin de donnes. Lorsque cela arrive, toutes les tentatives d'accs au dpt se soldent par un chec (puisque chaque nouvel arrivant attend que le verrou se libre, ce qui n'est pas prt d'arriver). Si cela arrive votre dpt, ne paniquez pas. Le systme de fichiers Berkeley DB tire parti des transactions de la base de donnes, des points de contrle et de la journalisation pralable toute criture pour garantir que seuls les vnements les plus catastrophiques8 soient mme de dtruire dfinitivement un environnement de base de donnes. Un administrateur suffisamment paranoaque conserve des sauvegardes des donnes du dpt dans un endroit distinct, mais attendez un peu avant de vous diriger vers l'armoire de rangement des sauvegardes. Appliquez plutt la recette suivante pour tenter de faire repartir votre dpt : 1. Assurez-vous qu'aucun processus n'accde au dpt (ou ne tente de le faire). Pour les dpts en rseau, cela implique d'arrter le serveur HTTP Apache ou le dmon svnserve. 2. Prenez l'identit de l'utilisateur qui possde et gre le dpt. C'est important, puisque rtablir un dpt avec un autre utilisateur peut modifier les droits d'accs des fichiers du dpt de telle manire que votre dpt soit toujours inaccessible mme aprs la remise en service. 3. Lancez la commande svnadmin recover /var/svn/depot. Vous devriez obtenir une sortie du genre : Verrou du dpt acquis. Patientez ; le rtablissement du dpt peut tre long... Fin du rtablissement. La dernire rvision du dpt est 19 Cette commande peut durer plusieurs minutes. 4. Redmarrez le processus serveur. Cette procdure fonctionne dans presque tous les cas de plantage. Faites attention ce qu'elle soit lance par l'utilisateur qui possde et gre la base de donnes, pas par root. La procdure de rtablissement peut impliquer de rcrer en partant de zro certains fichiers de la base de donnes (de la mmoire partage, par exemple). Un rtablissement par root crerait ces fichiers avec root comme propritaire, ce qui veut dire que mme aprs que vous ayez rtabli l'accs votre dpt, les utilisateurs de base n'y auront pas accs. Si la procdure prcdente, pour une raison ou pour une autre, ne fait pas repartir votre dpt, vous devez faire deux choses. D'abord, mettez de ct votre rpertoire de dpt cass (par exemple en le renommant depot.CASSE) puis restaurez la dernire sauvegarde de votre dpt. Ensuite, envoyez un email la liste de diffusion des utilisateurs de Subversion (<users@subversion.tigris.org>) et dcrivez votre problme en dtail. L'intgrit des donnes fait partie des sujets trs haute priorit pour les dveloppeurs Subversion.

Migration des donnes d'un dpt


Un systme de fichiers Subversion a ses donnes rparties dans les fichiers du dpt d'une manire que seuls les dveloppeurs Subversion eux-mmes comprennent (et s'y intressent). Il peut cependant y avoir des circonstances qui obligent copier ou
8

Par exemple, disque dur + gros aimant ct = dsastre.

133

Administration d'un dpt

dplacer l'ensemble (ou une partie) des donnes d'un dpt un autre. Subversion fournit cette fonctionnalit par le biais des flux de dchargement du dpt. Un flux de dchargement de dpt ( fichier dump ou dump file en anglais, quand il est stock dans un fichier sur le disque) est un format de fichier portable, contenant des donnes brutes, qui dcrit les diffrentes rvisions de votre dpt ce qui a t modifi, par qui, quand, etc. Ce fichier dump est le principal mcanisme utilis pour rorganiser des historiques de versions en partie ou en totalit, avec ou sans modification entre des dpts. Et Subversion fournit les outils ncessaires la cration et au chargement de ces fichiers dump : les sous-commandes svnadmin dump et svnadmin load respectivement. Bien que le format des fichiers dump de Subversion contienne des parties lisibles par les humains et une structure familire (elle ressemble au format dcrit par la RFC 822, utilis pour la plupart des emails), ce n'est pas un format de fichier purement textuel. C'est un format de fichier binaire, trs sensible aux modifications faites son contenu. Par exemple, de nombreux diteurs de textes corrompent le fichier en convertissant les caractres de fin de ligne. Il existe de nombreuses raisons de dcharger et recharger les donnes d'un dpt Subversion. Aux premiers temps de Subversion, la principale raison tait l'volution de Subversion lui-mme. Au fur et mesure que Subversion gagnait en maturit, des changements faits sur les schmas des magasins de donnes sous-jacents entranaient des problmes de compatibilit avec les versions prcdentes du dpt, ce qui obligeait les utilisateurs dcharger les donnes de leurs dpts en utilisant la version prcdente de Subversion puis recharger ces donnes dans un dpt tout neuf cr avec la nouvelle version de Subversion. Il n'y a pas eu de changement de schma de ce type depuis la version 1.0 de Subversion et les dveloppeurs ont promis de ne pas forcer les utilisateurs dcharger et recharger leurs dpts lors du passage d'une version mineure une autre (comme par exemple entre la version 1.3 et la version 1.4) de Subversion. Mais il existe nanmoins des raisons de dcharger et recharger ses donnes, comme le redploiement d'un dpt Berkeley DB sur un nouveau systme d'exploitation ou sur une architecture CPU diffrente, la migration du magasin de donnes de Berkeley DB FSFS et rciproquement ou (comme nous le voyons dans ce chapitre la section intitule Filtrage de l'historique d'un dpt ) la purge de donnes suivies en version de l'historique du dpt. Le format de dchargement des dpts Subversion ne dcrit que l'volution des lments suivis en version. Il ne contient pas d'information sur les transactions inacheves, les verrous utilisateurs sur les chemins du systme de fichiers, la configuration personnalise du dpt ou du serveur (y compris les procdures automatiques) et ainsi de suite. Quelle que soit la raison pour laquelle vous voulez migrer votre historique de dpt, l'utilisation des sous-commandes svnadmin dump et svnadmin load est simplissime. svnadmin dump affiche un intervalle de rvisions du dpt, chacune utilisant le format des fichiers dump Subversion. Le fichier dump est envoy sur la sortie standard tandis que les messages d'information sont envoys sur la sortie d'erreur. Ceci vous permet de rediriger le flux standard vers un fichier tout en visualisant ce qui se passe dans votre terminal. Par exemple : $svnlook youngest mon-depot 26 $ svnadmin dump mon-depot > fichier-dump * Rvision 0 dcharge. * Rvision 1 dcharge. * Rvision 2 dcharge. * Rvision 25 dcharge. * Rvision 26 dcharge. A la fin de la procdure, vous obtiendrez un fichier unique (fichier-dump dans l'exemple prcdent) qui contient toutes les donnes stockes dans votre dpt pour l'intervalle de rvisions demand. Notez que svnadmin dump lit les arborescences des rvisions du dpt de la mme manire que tout autre processus lecteur (par exemple svn checkout), vous pouvez donc sans risque lancer cette commande n'importe quel moment. La commande jumelle, svnadmin load, recherche dans l'entre standard la structure d'un fichier dump Subversion puis insre les rvisions dcharges dans le dpt de destination spcifi. Elle fournit elle aussi des informations sur le droulement de l'opration, cette fois en utilisant la sortie standard :

134

Administration d'un dpt

$ svnadmin load nouveau-depot < fichier-dump <<< Dbut d'une nouvelle transaction base sur la rvision 1 * ajout de : A ... fait. * ajout de : A/B ... fait. ------- Rvision 1 propage (commit) >>> <<< Dbut d'une nouvelle transaction base sur la rvision 2 * dition de : A/mu ... fait. * dition de : A/D/G/rho ... fait. ------- Rvision 2 propage (commit) >>> <<< Dbut d'une nouvelle transaction base sur la rvision 25 * dition de : A/D/gamma ... fait. ------- Rvision 25 propage (commit) >>> <<< Dbut d'une nouvelle transaction base sur la rvision 26 * ajout de : A/Z/zeta ... fait. * dition de : A/mu ... fait. ------- Rvision 26 propage (commit) >>> Le rsultat d'un chargement est l'ajout de nouvelle rvisions un dpt comme si vous faisiez des propagations vers ce dpt avec un client Subversion classique. De la mme manire que pour une propagation, vous pouvez utiliser les procdures automatiques pour effectuer des actions particulires avant et aprs chaque propagation faite par la procdure de chargement. En passant les options --use-pre-commit-hook et --use-post-commit-hook (respectivement) svnadmin load, vous demandez Subversion d'excuter les procdures automatiques pr-propagation et post-propagation (respectivement) pour chaque rvision charge. Un exemple d'utilisation de ces options est de s'assurer que les rvisions charges passent par les mmes tapes de validation qu'une propagation normale. Bien sr, utilisez ces options avec prudence si votre script postpropagation envoie des emails une liste de diffusion pour chaque nouvelle propagation, vous ne voulez peut-tre pas envoyer des centaines voire des milliers d'emails de notification la suite vers cette liste ! Vous pouvez en apprendre davantage sur l'utilisation des procdures automatiques dans la section intitule Mise en place des procdures automatiques . Notez que puisque svnadmin utilise l'entre et la sortie standards pour le dchargement et le rechargement, les administrateurs les plus intrpides peuvent tenter des choses du genre (peut-tre mme en utilisant diffrentes versions de svnadmin de chaque ct de la barre verticale |) : $ svnadmin create nouveau-depot $ svnadmin dump vieux-depot | svnadmin load nouveau-depot Par dfaut, le fichier dump prend beaucoup de place beaucoup plus que le dpt lui-mme. C'est parce que, par dfaut, chaque version de chaque fichier est crite en entier dans le fichier dump. C'est le comportement le plus simple et le plus rapide et cela convient bien si vous redirigez le flux de donnes directement vers un autre processus (comme un programme de compression, de filtrage ou de chargement). Mais si vous crez un fichier dump dans une optique de stockage long terme, vous voudrez sans doute conomiser de l'espace disque en utilisant l'option --deltas. Avec cette option, les rvisions successives des fichiers sont crites en tant que diffrences binaires et compresses de la mme manire que pour le stockage des fichiers dans le dpt. Cette option ralentit le processus mais le fichier rsultant a une taille beaucoup plus proche de celle du dpt original. Nous avons mentionn auparavant que svnadmin dump affiche un intervalle de rvisions. Pour spcifier une rvision unique ou un intervalle dcharger, utilisez l'option --revision (-r). Si vous omettez cette option, toutes les rvisions existantes sont affiches : $ svnadmin dump mon-depot -r 23 > rev-23.fichier-dump $ svnadmin dump mon-depot -r 100:200 > revs-100-200.fichier-dump

135

Administration d'un dpt

Au fur et mesure que Subversion dcharge chaque nouvelle rvision, il n'affiche que le minimum d'informations ncessaire un futur chargement pour re-gnrer la rvision partir de la prcdente. En d'autres termes, pour n'importe quelle rvision du fichier dump, seuls les lments ayant subi une modification dans cette rvision apparaissent dans le fichier dump. La seule exception cette rgle est la premire rvision qui est dcharge par la commande svnadmin dump courante. Par dfaut, Subversion n'exprime pas la premire rvision dcharge sous forme de diffrences appliquer la rvision prcdente. En effet, il n'y a pas de rvision prcdente dans le fichier dump ! Et puis Subversion ne peut pas connatre l'tat du dpt dans lequel les donnes vont tre charges (si jamais elles le sont). Pour s'assurer que la sortie de chaque excution de svnadmin dump est suffisante, la premire rvision dcharge est, par dfaut, une reprsentation complte de chaque rpertoire, de chaque fichier et de chaque proprit de cette rvision du dpt. Vous pouvez toujours modifier ce comportement par dfaut. Si vous ajoutez l'option --incremental quand vous dchargez le dpt, svnadmin compare la premire rvision dcharge la rvision prcdente du dpt de la mme manire qu'il traite toutes les autres rvisions qui sont dcharges. Il affiche alors la premire rvision de la mme manire que le reste des rvisions dans l'intervalle demand en ne mentionnant que les changements contenus dans cette rvision. L'avantage est que vous pouvez crer plusieurs petits fichiers dump qui peuvent tre chargs les uns la suite des autres au lieu d'un unique gros fichier. Par exemple : $ svnadmin dump mon-depot -r 0:1000 > fichier-dump1 $ svnadmin dump mon-depot -r 1001:2000 --incremental > fichier-dump2 $ svnadmin dump mon-depot -r 2001:3000 --incremental > fichier-dump3 Ces fichiers dump peuvent maintenant tre chargs dans un nouveau dpt avec la squence de commandes suivante : $ svnadmin load nouveau-depot < fichier-dump1 $ svnadmin load nouveau-depot < fichier-dump2 $ svnadmin load nouveau-depot < fichier-dump3 Une autre astuce consiste utiliser l'option --incremental pour ajouter un nouvel intervalle de rvisions un fichier dump existant. Par exemple, vous pouvez avoir une procdure automatique post-commit qui ajoute simplement un fichier dump le contenu de la rvision qui a dclench la procdure. Ou alors vous pouvez avoir un script qui tourne la nuit pour ajouter un fichier dump les donnes de toutes les rvisions qui ont eu lieu depuis le dernier lancement du script. Ainsi, svnadmin dump est une manire de raliser des sauvegardes des changements de votre dpt au fil du temps, dans l'ventualit d'un plantage systme ou de toute autre vnement catastrophique. Les fichiers dump peuvent aussi tre utiliss pour fusionner le contenu de diffrents dpts en un seul dpt. En utilisant l'option --parent-dir de svnadmin load, vous pouvez spcifier un nouveau rpertoire racine virtuel pour la procdure de chargement. Ainsi, si vous avez des fichiers dump pour trois dpts disons fichier-dump-calc, fichierdump-cal et fichier-dump-tab vous pouvez commencer par crer un nouveau dpt pour les hberger tous : $ svnadmin create /var/svn/projets $ Ensuite, crez dans le dpt les nouveaux rpertoires qui vont encapsuler le contenu de chacun des trois dpts prcdents : $ svn mkdir -m "Racines initiales des projets" \ file:///var/svn/projets/calc \ file:///var/svn/projets/calendrier \ file:///var/svn/projets/tableur Rvision 1 propage. $ Enfin, chargez chaque fichier dump dans le rpertoire correspondant du nouveau dpt : $ svnadmin load /var/svn/projets --parent-dir calc < fichier-dump-calc $ svnadmin load /var/svn/projets --parent-dir calendrier < fichier-dump-cal 136

Administration d'un dpt

$ svnadmin load /var/svn/projets --parent-dir spreadsheet < fichier-dump-tab $ Mentionnons une dernire faon d'utiliser les fichiers dump de Subversion la conversion depuis un systme de stockage diffrent ou depuis un autre systme de gestion de versions. Comme le format des fichiers dump est, pour sa plus grande partie, lisible par un humain, il devrait tre relativement facile de dcrire des ensembles de modifications chaque ensemble constituant une nouvelle rvision en utilisant ce format de fichier. En fait, l'utilitaire cvs2svn (voir la section intitule Conversion d'un dpt CVS vers Subversion ) utilise le format dump pour reprsenter le contenu d'un dpt CVS, de manire pouvoir copier ce contenu dans un dpt Subversion.

Filtrage de l'historique d'un dpt


Puisque Subversion stocke votre historique du suivi de versions en utilisant, au minimum, des algorithmes de diffrenciation binaire et de la compression de donnes (le tout, en option, dans un systme de gestion de bases de donnes compltement opaque). Il est maladroit, et en tous cas fortement dconseill, d'essayer de le modifier manuellement, sachant qu'en plus c'est assez difficile. Et une fois que des donnes ont t stockes dans votre dpt, Subversion ne fournit gnralement pas de moyen simple pour enlever ces donnes9. Mais, invitablement, il y a des cas o vous voulez manipuler l'historique de votre dpt. Par exemple pour supprimer tous les occurrences d'un fichier qui a t accidentellement ajout au dpt (alors qu'il ne devrait pas y tre)10. Ou bien lorsque vous avez plusieurs projets qui partagent le mme dpt et que vous dcidez de leur attribuer chacun le leur. Pour accomplir ce genre de tches, les administrateurs ont besoin d'une reprsentation des donnes de leurs dpts plus souple et plus facile grer : les fichiers dump Subversion. Comme indiqu prcdemment dans la section intitule Migration des donnes d'un dpt , le format des fichiers dump Subversion est une reprsentation lisible par les humains des modifications apportes au cours du temps aux donnes suivies en versions. Utilisez la commande svnadmin dump pour extraire les donnes et svnadmin load pour les charger dans un nouveau dpt. Le gros atout de l'aspect lisible par les humains des fichiers dump est que, si vous y tenez, vous pouvez en inspecter le contenu et le modifier. Bien sr, la contrepartie est que, si vous avez un fichier dump d'un dpt actif depuis plusieurs annes, cela vous prendra un certain temps pour en inspecter manuellement le contenu et le modifier, un temps certain mme. C'est l qu'intervient svndumpfilter. Ce programme agit comme un filtre sur les chemins pour les flux de dchargement/ chargement d'un dpt. Vous n'avez qu' lui fournir une liste de chemins que vous voulez conserver ou une liste de chemins que vous voulez liminer et ensuite rediriger le flux de dump de vos donnes travers ce filtre. Vous obtenez un flux modifi qui ne contient que les donnes suivies en versions des chemins que vous avez demands (explicitement ou implicitement). Prenons un exemple concret d'utilisation de ce programme. Prcdemment dans ce chapitre (voir la section intitule Stratgies d'organisation d'un dpt ), nous avons dcrit le processus de dcision permettant de choisir l'organisation des donnes de votre dpt (utiliser un dpt par projet ou les combiner, comment organiser les rpertoires au sein du dpt, etc.). Mais il peut arriver qu'aprs un certain nombre de rvisions vous repensiez votre organisation et vouliez la modifier. Une modification classique est de dplacer plusieurs projets qui partagent le mme dpt vers des dpts propres chacun d'eux. Notre dpt imaginaire contient trois projets : calc, calendrier et tableur. Ils se trouvent cte cte comme ceci : / calc/ trunk/ branches/ tags/ calendrier/ trunk/ branches/ tags/ tableur/ trunk/ branches/ tags/
9 C'est 10

d'ailleurs pour cela que vous utilisez un systme de gestion de versions, non ? Des suppressions dlibres et avises de donnes suivies en versions peuvent effectivement tre justifies par des cas d'utilisation rels. C'est pourquoi une fonctionnalit d'oblitration est une des fonctionnalits les plus demandes pour Subversion et les dveloppeurs de Subversion esprent pouvoir la fournir bientt.

137

Administration d'un dpt

Pour placer ces trois projets dans leur dpts propres, nous commenons par dcharger tout le dpt : $ * * * * $ svnadmin Rvision Rvision Rvision Rvision dump /var/svn/depot > fichier-dump-depot 0 dcharge. 1 dcharge. 2 dcharge. 3 dcharge.

Ensuite, nous passons ce fichier dump travers le filtre, en n'incluant chaque fois qu'un seul rpertoire racine. Nous obtenons trois nouveaux fichiers dump : $ svndumpfilter include calc < fichier-dump-depot > fichier-dump-calc $ svndumpfilter include calendrier < fichier-dump-depot > fichier-dump-cal $ svndumpfilter include tableur < fichier-dump-depot > fichier-dump-tab $ C'est le moment de prendre une dcision. Chacun de vos fichiers dump gnrera un dpt valide, mais il conservera les chemins exactement comme ils taient dans le dpt original. Cela veut dire que mme si vous obtenez un dpt propre votre projet calc ce dpt aura toujours un rpertoire racine calc. Si vous voulez que les rpertoires trunk, tags et branches soient placs la racine de votre dpt, vous devez alors diter les fichiers dump, en modifiant les en-ttes Node-path et Node-copyfrom-path pour qu'ils ne contiennent plus de rfrence au rpertoire calc/. Vous devez galement supprimer la section des donnes qui cre le rpertoire calc. Elle ressemble ceci : Node-path: calc Node-action: add Node-kind: dir Content-length: 0

Si vous envisagez d'diter la main le fichier dump pour enlever un rpertoire la racine, assurez-vous que votre diteur n'est pas configur pour convertir les caractres de fin de ligne vers le format natif (par exemple de \r\n vers \n), sinon le contenu ne serait plus conforme aux mtadonnes. Cela corromprait le fichier dump de manire irrversible. Tout ce qu'il reste faire prsent, c'est de crer vos trois nouveaux dpts et de charger chaque fichier dump dans le bon dpt, en ignorant l'UUID contenu dans chaque flux dump : $ svnadmin create calc $ svnadmin load --ignore-uuid calc < fichier-dump-calc <<< Dbut d'une nouvelle transaction base sur la rvision 1 * ajout de : Makefile ... fait. * ajout de : bouton.c ... fait. $ svnadmin create calendrier $ svnadmin load --ignore-uuid calendrier < fichier-dump-cal <<< Dbut d'une nouvelle transaction base sur la rvision 1 * ajout de : Makefile ... fait. * ajout de : cal.c ... fait. $ svnadmin create tableur $ svnadmin load --ignore-uuid tableur < fichier-dump-tab 138

Administration d'un dpt

<<< Dbut d'une nouvelle transaction base sur la rvision 1 * ajout de : Makefile ... fait. * ajout de : tableur.c ... fait. $ Les deux sous-commandes svndumpfilter possdent des options pour dcider comment traiter les rvisions vides . Si une rvision donne ne contient que des modifications concernant des chemins qui ont t filtrs, cette rvision dornavant vide peut tre considre comme inintressante voire indsirable. Pour permettre l'utilisateur de dcider que faire de telles rvisions, svndumpfilter propose les options suivantes : --drop-empty-revs Ne gnrer aucune rvision vide ; elles sont tout simplement ignores. --renumber-revs Si les rvisions vides sont ignores (avec l'option --drop-empty-revs), changer les numros de rvision restants pour qu'il n'y ait pas de trous dans la squence de numrotation. --preserve-revprops Si les rvisions vides ne sont pas ignores, garder les proprits de la rvision (message de propagation, auteur, date, proprits personnalises, etc.) pour ces rvisions vides. Autrement les rvisions vides ne contiennent que l'horodatage original et un message expliquant que c'est cause de svndumpfilter que cette rvision est vide. Alors que svndumpfilter peut s'avrer trs utile et permet de gagner normment de temps, il est affubl malheureusement de deux chausse-trappes. D'abord, cet utilitaire est extrmement sensible la smantique des chemins. Prtez attention la manire dont sont spcifis les chemins dans votre fichier dump, avec ou sans barre oblique (/) initiale. Regardez pour cela les en-ttes Node-path et Node-copyfrom-path. Node-path: tableur/Makefile Si les chemins ont une barre oblique initiale, vous devez inclure des barres obliques au dbut de chaque chemin que vous indiquez svndumpfilter include et svndumpfilter exclude (et s'ils n'en ont pas, n'incluez pas de barre oblique au dbut). Pour aller plus loin, si votre fichier dump contient la fois des chemins avec et des chemins sans barre oblique initiale, pour quelque raison que ce soit11, vous devrez probablement normaliser les chemins en adoptant une des deux conventions. En outre, les chemins qui ont t copis peuvent vous donner quelques soucis. Subversion supporte les oprations de copie dans le dpt, c'est--dire quand un nouveau chemin est cr par la copie d'un autre chemin qui existe dj. Il est possible qu' un certain moment de la vie de votre dpt, vous ayez copi un fichier ou un rpertoire d'un endroit que svndumpfilter a exclu vers un endroit qui est inclus. Pour rendre les donnes du dump cohrentes, svndumpfilter doit bien inclure l'ajout du nouveau chemin y compris le contenu de tous les fichiers crs par la copie mais en tant que copie d'un chemin source qui n'existe pas dans le flux des donnes filtres. Mais puisque le format dump de Subversion ne contient que ce qui a t modifi dans chaque rvision, le contenu de la source de la copie risque de ne pas tre disponible. Si vous tes susceptible d'avoir la moindre copie de ce type dans votre dpt, vous devrez peut-tre repenser votre ensemble de chemins inclure/exclure, pour y inclure aussi les chemins qui ont servi de sources des oprations de copie qui vous posent problme. Enfin, svndumpfilter effectue un filtrage des chemins pour le moins littral. Si vous essayez de copier l'historique d'un projet dont la racine est trunk/mon-projet et de le dplacer dans son propre dpt, vous utiliserez videmment la commande svndumpfilter include pour conserver tous les changements dans et sous trunk/mon-projet. Mais le fichier dump rsultant ne fait aucune hypothse sur le dpt dans lequel vous allez charger ces donnes. En particulier, les donnes dcharges peuvent commencer par la rvision qui a ajout le rpertoire trunk/mon-projet mais ne pas contenir les directives pour crer le rpertoire trunk lui-mme (parce que trunk ne correspond pas au filtre utilis). Vous devez vous assurer que tous les rpertoires la prsence desquels le flux de donnes dcharges s'attend existent rellement dans le dpt destination, avant d'essayer de charger le flux de donnes l'intrieur.

11

Bien que svnadmin dump ait une politique cohrente concernant la barre oblique initiale (aussi appele slash il ne l'inclut pas), d'autres programmes qui gnrent des fichiers dump sont susceptibles de ne pas tre aussi cohrents.

139

Administration d'un dpt

Rplication d'un dpt


Divers scnarios montrent l'intrt d'avoir un dpt Subversion dont l'historique des versions est exactement le mme que celui d'un autre dpt. Le plus vident est probablement celui de maintenir un dpt de secours, utilis quand le dpt principal est inaccessible en raison d'un problme matriel, d'une coupure rseau ou de tout autre souci de ce type. D'autres scnarios comprennent le dploiement de dpts redondants pour distribuer la charge sur plusieurs serveurs, les mises niveau transparentes et d'autres encore. Depuis la version 1.4, Subversion fournit un programme pour grer de tels scnarios : svnsync. Il fonctionne essentiellement en demandant au serveur Subversion de rejouer les rvisions, une par une. Il utilise ces informations sur les rvisions pour rpter une propagation identique sur un autre dpt. Aucun des deux dpts n'a besoin d'tre accessible localement sur la machine o svnsync tourne : ses paramtres sont des URL de dpt et tout le travail est effectu via les interfaces d'accs au dpt (Repository Access en anglais, ou RA) de Subversion. Tout ce dont il a besoin est un accs en lecture au dpt source et un accs en lecture/criture au dpt de destination. Quand vous utilisez svnsync sur un dpt source distant, le serveur Subversion de ce dpt doit tre en version 1.4 ou suprieure. Supposons que vous voulez raliser un miroir d'un de vos dpts ; il vous faut alors disposer d'un dpt destination vide qui servira de miroir. Ce dpt cible peut utiliser n'importe quel magasin de donnes disponible (voir la section intitule Choix du magasin de donnes ), mais il ne doit comporter aucun historique. Le protocole utilis par svnsync pour transmettre les informations de rvision est particulirement sensible aux divergences entre les historiques suivies en versions de la source et de la destination. Pour cette raison, bien que svnsync ne puisse pas exiger que le dpt destination soit en lecture seule12, autoriser des modifications d'historique sur le dpt destination par un mcanisme externe autre que le processus de rplication mne droit au dsastre. Ne modifiez pas le dpt miroir de sorte que son historique de version diffre de celui du dpt source. Les seules propagations et modifications de proprits de rvisions qui doivent avoir lieu sur ce dpt miroir sont celles effectues par l'outil svnsync. Une autre exigence concernant le dpt destination est que le processus svnsync doit tre autoris modifier les proprits de rvision. Comme svnsync fonctionne dans le cadre du systme des procdures automatiques du dpt, l'tat par dfaut du dpt (qui consiste interdire les modifications des proprits de rvision, voir pre-revprop-change) n'est pas suffisant. Vous devez activer explicitement la procdure automatique pre-revprop-change et votre script doit autoriser svnsync dfinir et modifier les proprits de rvision. Une fois ces dispositions prises, vous tes pars pour commencer la rplication des rvisions du dpt. Il est de bon ton de mettre un place un contrle d'accs pour autoriser le processus de rplication de votre dpt faire ce qu'il a faire tout en interdisant aux autres utilisateurs de modifier le contenu de votre dpt miroir. Examinons maintenant l'utilisation de svnsync dans un scnario classique de rplication. Nous saupoudrons le discours de quelques recommandations pratiques que vous tes libre d'ignorer si elles ne sont pas ncessaires ou pas applicables votre environnement. Pour rendre service aux excellents dveloppeurs de notre systme de gestion de versions favori, nous allons rpliquer le dpt public qui contient le code source de Subversion et mettre ce miroir disposition sur Internet, sur une machine diffrente de celle qui hberge le dpt original. Cet hte distant possde une configuration globale qui autorise les accs anonymes en lecture mais requiert une authentification pour modifier les dpts (pardonnez-nous de passer rapidement sur les dtails de la configuration du serveur Subversion pour le moment, mais ces aspects sont traits en profondeur dans le Chapitre 6, Configuration du serveur.). Et pour rendre l'exemple plus intressant, et uniquement pour cela, nous piloterons la rplication depuis une troisime machine en l'occurrence, celle que nous sommes en train d'utiliser. Dans un premier temps, nous allons crer le dpt qui servira de miroir. Cette tape et les deux suivantes requirent l'accs la ligne de commande de la machine sur laquelle le miroir sera hberg. Toutefois, une fois que ce dpt sera compltement configur, nous n'aurons plus besoin d'y avoir accs directement.

12

En fait, le dpt ne peut pas tre compltement en lecture seule, sinon svnsync lui-mme aurait du mal y copier l'historique des rvisions.

140

Administration d'un dpt

$ ssh admin@svn.exemple.com \ "svnadmin create /var/svn/miroir-svn" admin@svn.exemple.com's password: ******** $ ce stade, nous disposons d'un dpt et, en raison de la configuration de notre serveur, ce dpt est accessible directement depuis Internet. Maintenant, puisque nous ne voulons pas que quoi que ce soit modifie notre dpt en dehors du processus de rplication, nous devons trouver un moyen de distinguer ce processus des autres prtendants aux propagations. Pour ce faire, nous utilisons un identifiant d'utilisateur ddi notre processus. Seules les propagations et les modifications de proprits de rvisions effectues par l'identifiant spcial id-sync sont autorises. Nous allons utiliser le systme de procdures automatiques du dpt la fois pour autoriser le processus de rplication faire ce qu'il doit faire et pour garantir qu'il soit le seul le faire. Nous implmentons donc deux des procdures automatiques du dpt : pre-revprop-change et start-commit. Le script pre-revprop-change est prsent dans l'Exemple 5.2, Procdure automatique pre-revprop-change du dpt miroir et, pour rsumer, vrifie que l'utilisateur qui essaie de modifier les proprits est bien notre utilisateur id-sync. Si c'est bien le cas, la modification est autorise ; sinon, elle est refuse.

Exemple 5.2. Procdure automatique pre-revprop-change du dpt miroir


#!/bin/sh USER="$3" if [ "$USER" = "id-sync" ]; then exit 0; fi echo "Seul l'utilisateur id-sync est autoris modifier les proprits de rvision." >&2 exit 1

Voil pour les modifications des proprits de rvision. Maintenant nous devons nous assurer que seul l'utilisateur id-sync est autoris propager de nouvelles rvisions dans le dpt. Ce que nous allons faire en utilisant une procdure automatique start-commit telle que celle prsente dans l'Exemple 5.3, Procdure automatique start-commit du dpt miroir .

Exemple 5.3. Procdure automatique start-commit du dpt miroir


#!/bin/sh USER="$2" if [ "$USER" = "id-sync" ]; then exit 0; fi echo "Seul l'utilisateur id-sync est autoris effectuer des propagations." >&2 exit 1

Aprs avoir install nos procdures automatiques et s'tre assur qu'elles sont excutables par le serveur Subversion, nous en avons termin avec l'installation de notre dpt miroir. Maintenant, nous allons effectivement lancer la rplication. La premire chose faire avec svnsync est d'enregistrer dans notre dpt destination le fait qu'il sera un miroir du dpt source. Nous utilisons donc la sous-commande svnsync initialize. Nous fournissons des URL qui pointent vers les rpertoires racines des dpts destination et source, respectivement. Dans Subversion 1.4, c'est obligatoire seule la rplication de dpts complets est permise. Dans Subversion 1.5, cependant, vous pouvez aussi utiliser svnsync pour rpliquer uniquement des sous-arborescences du dpt.

141

Administration d'un dpt

$ svnsync help init initialize (init): usage : svnsync initialize DEST_URL SOURCE_URL Initialise un dpt destination pour tre synchronis partir d'un autre dpt. $ svnsync initialize http://svn.exemple.com/miroir-svn \ http://svn.collab.net/repos/svn \ --sync-username id-sync --sync-password mdp-sync Proprits copies pour la rvision 0. $ Notre dpt destination se rappelle maintenant qu'il est un miroir du dpt public du code source Subversion13. Notez que nous avons fourni un identifiant et un mot de passe en arguments svnsync c'tait exig par la procdure automatique prerevprop-change de notre dpt miroir. Dans Subversion 1.4, les valeurs assignes aux options --username et --password de svnsync taient utilises pour l'authentification la fois par le dpt source et par le dpt destination. Cela posait des problmes quand ces valeurs n'taient pas exactement les mmes pour les deux dpts, particulirement quand le mode noninteractif tait utilis (avec l'option --non-interactive). Ce problme a t rsolu dans la version 1.5 de Subversion avec l'introduction de deux nouvelles paires d'options. Utilisez --source-username et --source-password pour vous authentifier auprs du dpt source ; utilisez --sync-username et --sync-password pour vous authentifier auprs du dpt destination (les vieilles options --username et --password existent encore pour assurer la compatibilit mais nous en dconseillons l'usage). Abordons maintenant la partie amusante. En une seule sous-commande, nous pouvons demander svnsync de copier toutes les rvisions qui n'ont pas encore t rpliques du dpt source vers le dpt destination14. La sous-commande svnsync synchronize fouille dans les proprits de rvision spciales du dpt destination pour dterminer aussi bien de quel dpt source il est le miroir que la dernire rvision qui a t rplique, en l'occurrence la rvision 0. Ensuite, elle interroge le dpt source pour savoir quelle est la dernire rvision propage dans ce dpt. Enfin, elle demande au dpt source de commencer envoyer toutes les rvisions entre la rvision 0 et la dernire rvision. Au moment o svnsync reoit la rponse du dpt source, elle commence la retransmission des rvisions vers le dpt destination en tant que nouvelles propagations. $ svnsync help synchronize synchronize (sync): usage : svnsync synchronize URL_DEST Transfre toutes les rvisions en attente vers la destination, partir de la source avec laquelle elle a t initialise. $ svnsync synchronize http://svn.exemple.com/miroir-svn Transmission des donnes ........................................ Rvision 1 propage. Proprits copies pour la rvision 1. Transmission des donnes .. Rvision 2 propage. Proprits copies pour la rvision 2. Transmission des donnes ..... Rvision 3 propage. Proprits copies pour la rvision 3. Transmission des donnes .. Rvision 23406 propage. Proprits copies pour la rvision 23406. Transmission des donnes . Rvision 23407 propage. Proprits copies pour la rvision 23407. Transmission des donnes ....
13 NdT 14

: il s'agit ici de l'ancienne adresse du dpt Subversion. Nous avertissons le lecteur que, bien qu'il lui suffise de quelques secondes pour lire ce paragraphe et l'exemple qui suit, le temps ncessaire pour raliser une opration de rplication est, disons, un peu plus long.

142

Administration d'un dpt

Rvision 23408 propage. Proprits copies pour la rvision 23408. $ Il est intressant de noter ici que, pour chaque rvision rplique, il y a d'abord propagation de la rvision dans le dpt destination, puis des changements de proprits ont lieu. C'est parce que la propagation initiale est effectue par (et donc attribue ) l'utilisateur id-sync et qu'elle est horodate lors de la cration de la nouvelle rvision. Et aussi parce que les interfaces d'accs au dpt Subversion n'autorisent pas la dfinition de proprits de rvision au sein d'une propagation. C'est pourquoi svnsync fait suivre la rplication par une srie de modifications de proprits qui copient dans le dpt destination toutes les proprits de rvision trouves dans le dpt source pour cette rvision. Cela a galement pour effet de corriger l'auteur et l'horodatage de la rvision pour tre cohrent avec le dpt source. Notez galement que svnsync documente tout ce qu'il fait en dtail, afin de pouvoir tre interrompu ou redmarr sans remettre en cause l'intgrit des donnes rpliques. Si une panne rseau survient pendant la rplication d'un dpt, relancez simplement la commande svnsync synchronize et elle reprendra tranquillement l o elle s'tait arrte. En fait, au fur et mesure que de nouvelles rvisions apparaissent dans le dpt source, c'est prcisment ce qu'il faut faire pour conserver votre miroir jour. Proprits propres svnsync svnsync a besoin de pouvoir dfinir et modifier des proprits de rvision dans le dpt miroir car ces proprits font partie intgrante des donnes rpliquer. Au fur et mesure que ces proprits changent dans le dpt source, ces changements doivent galement tre rpliqus dans le dpt miroir. Mais svnsync utilise aussi un ensemble de proprits de rvision qui lui sont propres stockes dans la rvision 0 du dpt miroir ses propres fins de journalisation. Ces proprits contiennent des informations telles que l'URL et l'UUID du dpt source, ainsi que quelques informations supplmentaires sur l'tat du miroir. Une de ces informations sur l'tat du miroir est un drapeau indiquant qu' il y a une synchronisation en cours . Il est utilis pour viter que de multiples processus svnsync entrent en collision en essayant de rpliquer les donnes vers le mme dpt destination. Quoi qu'il en soit, vous n'aurez gnralement pas vous soucier de ces proprits spciales (elles commencent toutes par le prfixe svn:sync-). Cependant, il peut arriver qu'une synchronisation choue accidentellement et que Subversion n'ait pas l'occasion d'enlever ce drapeau indiquant l'tat de la synchronisation. Cela fait chouer toute nouvelle tentative de synchronisation, puisque le drapeau indique qu'une synchronisation est en cours, alors que ce n'est pas le cas. Heureusement, pour sortir de cette situation, il suffit de supprimer la proprit svn:sync-lock de la rvision 0 du dpt miroir (c'est le fameux drapeau) : $ svn propdel --revprop -r0 svn:sync-lock http://svn.exemple.com/miroir-svn Proprit 'svn:sync-lock' supprime de la rvision 0 du dpt $ Le fait que svnsync stocke l'URL du dpt source dans une proprit qui lui est ddie au sein du dpt destination est la raison pour laquelle vous n'avez renseigner cette URL qu'une seule fois, au moment de svnsync init. Les oprations suivantes de synchronisation de ce miroir se contentent de consulter la proprit svn:sync-from-url stocke dans le dpt miroir lui-mme pour dterminer la source de la synchronisation. Notez bien que cette valeur est utilise telle quelle par le processus de synchronisation. Ainsi, depuis l'intrieur du rseau CollabNet vous pouvez peut-tre accder notre URL source http://svn/depot/svn (parce que le premier svn se voit ajouter .collab.net par la magie du serveur DNS), mais, si vous devez mettre jour le miroir plus tard depuis une machine en dehors du rseau CollabNet, la synchronisation risque d'chouer (parce que le nom de machine svn est ambigu). Pour cette raison, il est prfrable d'utiliser le nom complet pour l'URL du dpt source lors de l'initialisation de votre dpt miroir plutt que simplement le nom de machine ou l'adresse IP (qui peut varier au cours du temps). L encore, si vous devez changer l'URL de la source (ayant le mme contenu) d'un dpt miroir existant, vous pouvez changer la proprit de journalisation qui stocke cette information : $ svn propset --revprop -r0 svn:sync-from-url NOUVELLE-URL-SOURCE \ http://svn.exemple.com/miroir-svn Proprit 'svn:sync-from-url' dfinie la rvision 0 du dpt $ Un autre point intressant concernant ces proprits lies la synchronisation est que svnsync n'essaie pas de rpliquer 143

Administration d'un dpt

ces proprits s'il les trouve dans le dpt source. La raison en est probablement vidente mais est due en rsum au fait que svnsync n'est pas capable de distinguer les proprits spciales qu'il n'a fait que copier partir du dpt source de celles qu'il doit consulter et tenir jour pour ses propres besoins. Cette situation peut arriver si, par exemple, vous hbergez le miroir d'un miroir d'un dpt. Quand svnsync voit ses propres proprits de synchronisation dans la rvision 0 du dpt source, il les ignore purement et simplement.

Le procd est cependant peu lgant. Comme les proprits des rvisions Subversion peuvent tre modifies n'importe quand dans la vie du dpt et comme elles ne conservent pas de trace des modifications effectues, les processus de rplication doivent faire particulirement attention ces proprits. Si vous avez dj rpliqu les quinze premires rvisions d'un dpt et que quelqu'un modifie une proprit de rvision concernant la rvision 12, svnsync ne sait pas qu'il faut revenir en arrire et modifier la copie de la rvision 12. Vous devez le lui indiquer manuellement en utilisant la sous-commande svnsync copyrevprops (ou l'aide d'autres outils), ce qui re-rplique toutes les proprits de rvision pour une rvision particulire ou un ensemble de rvisions. $ svnsync help copy-revprops copy-revprops: usage: svnsync copy-revprops URL_DEST [REV[:REV2]] Copie les proprits de rvision pour l'intervalle donn vers la destination partir de la source avec laquelle elle a t initialise. $ svnsync copy-revprops http://svn.exemple.com/miroir-svn 12 Proprits copies pour la rvision 12. $ C'en est fini pour la prsentation rapide de la rplication de dpt. Vous voudrez srement automatiser un certain nombre de choses autour de ce processus. Par exemple, alors que notre exemple prsentait une mise en place tirer-et-pousser , vous tes susceptible de vouloir que ce soit le dpt source qui pousse les modifications vers un ou plusieurs miroirs prdfinis lors de l'excution des procdures automatiques post-commit et post-revprop-change. Ceci permettrait au miroir d'tre jour presque en temps rel. En outre, et bien que ce ne soit pas trs utilis, svnsync sait rpliquer des dpts pour lesquels l'identifiant qu'il utilise pour s'authentifier n'a que des droits partiels en lecture. Il copie simplement les parties du dpt qu'il est autoris voir. Un tel miroir n'est clairement pas une bonne solution de sauvegarde. Avec Subversion 1.5, svnsync a acquis la capacit de rpliquer uniquement un sous-ensemble d'un dpt plutt que le dpt entier. La procdure pour configurer et assurer la maintenance d'un tel miroir est exactement la mme que pour rpliquer un dpt entier, except lors du passage de l'URL du dpt source svnsync init : vous spcifiez l'URL d'un sous-rpertoire l'intrieur du dpt. La synchronisation du miroir ne copie que les modifications relatives l'arborescence sous le rpertoire indiqu. Notez quand mme quelques restrictions sur cette fonction : premirement, vous ne pouvez pas rpliquer plusieurs sous-rpertoires disjoints du dpt source vers un unique dpt miroir vous devez dans ce cas rpliquer un rpertoire parent qui est commun tous les rpertoires que vous voulez rpliquer ; deuximement, la logique de filtrage est entirement base sur le chemin d'accs donc, si le sous-rpertoire que vous rpliquez a t renomm par le pass, votre miroir ne contiendra que les rvisions depuis lesquelles il a le nom indiqu dans l'URL que vous avez spcifie. Et, de la mme manire, si le sousrpertoire source est renomm dans le futur, le processus de synchronisation ne rpliquera plus les donnes partir du moment o l'URL que vous avez spcifie ne sera plus valide. En ce qui concerne les interactions entre les utilisateurs et les dpts ainsi que les miroirs, il est possible d'avoir une seule copie de travail qui interagisse avec un dpt et son miroir, mais vous devez faire quelques manipulations pour y arriver. D'abord, vous devez vous assurer que le dpt source et le dpt miroir ont bien le mme identifiant unique UUID (ce qui n'est pas le cas par dfaut). Reportez-vous la section intitule Gestion des identifiants uniques (UUID) des dpts plus loin dans ce chapitre pour plus de dtails ce sujet. Une fois que les deux dpts ont le mme identifiant unique, vous pouvez utiliser svn switch avec l'option --relocate pour faire pointer votre copie de travail vers le dpt de votre choix ; cette procdure est dcrite dans svn switch. Cette manuvre est potentiellement dangereuse si le miroir et le dpt original ne sont pas troitement synchroniss : une copie de travail jour, pointant vers le dpt source, que l'on ferait pointer vers un miroir non jour, est perdue devant l'absence soudaine de rvisions qu'elle s'attend trouver et elle renvoie des erreurs dans ce sens. Si cela arrive, vous pouvez refaire pointer votre copie de travail vers le dpt original et soit attendre que le dpt miroir se mette jour, soit faire revenir en arrire votre copie de travail jusqu' un numro de rvision dont vous savez qu'il est prsent dans le dpt miroir, puis retenter le changement de dpt. 144

Administration d'un dpt

Enfin, soyez conscient que la rplication fournie par svnsync, base sur les rvisions, n'est rien de plus que de la simple rplication de rvisions. Seules les informations incluses dans le format de fichier dump des dpts Subversion peuvent tre rpliques. Ainsi, svnsync possde les mmes limitations que les flux de chargement/dchargement Subversion et n'inclut donc pas les procdures automatiques, la configuration du dpt et du serveur, les transactions inacheves ni les informations relatives aux verrous poss par les utilisateurs sur les chemins du dpt.

Sauvegarde d'un dpt


En dpit des nombreux progrs de la technologie depuis l'avnement de l'informatique moderne, une chose reste certaine : le pire n'est jamais trs loin. L'alimentation lectrique tombe en panne, les rseaux subissent des coupures, les mmoires vives crament, les disques durs flanchent, et ce mme pour le plus consciencieux des administrateurs. Nous en venons donc maintenant un sujet trs important : comment raliser des copies de sauvegarde des donnes de votre dpt. Les administrateurs de dpts Subversion disposent de deux mthodes de sauvegarde : la complte et l'incrmentale. Une sauvegarde complte d'un dpt implique de rcuprer d'un seul coup toutes les informations ncessaires pour reconstruire compltement ce dpt dans le cas d'une catastrophe. Habituellement, cela consiste dupliquer, littralement, la totalit du rpertoire du dpt (ce qui inclut l'environnement Berkeley DB ou FSFS). Les sauvegardes incrmentales sont plus restreintes : elles ne sauvegardent que les donnes du dpt qui ont chang depuis la sauvegarde prcdente. Pour ce qui concerne les sauvegardes compltes, l'approche nave pourrait sembler satisfaisante. Mais moins d'interdire temporairement tout accs au dpt, une simple copie rcursive du rpertoire risque de crer une sauvegarde corrompue. Dans le cas d'une base de donnes Berkeley DB, la documentation dcrit un certain ordre de copie des fichiers qui garantit une copie de sauvegarde valide. Un ordre similaire existe avec les donnes FSFS. Mais vous n'avez pas implmenter ces algorithmes vous-mme, puisque l'quipe de dveloppement de Subversion l'a dj fait pour vous. La commande svnadmin hotcopy prend soin de tout a afin de raliser une copie chaud de votre dpt. Et son invocation est aussi triviale que la commande Unix cp ou qu'une copie sous Windows : $ svnadmin hotcopy /var/svn/depot /var/svn/depot-sauvegarde La sauvegarde gnre est un dpt Subversion totalement fonctionnel, capable de prendre immdiatement la place de votre dpt en production si les choses tournent au vinaigre. Lors de la copie d'un dpt Berkeley DB, vous pouvez mme ordonner svnadmin hotcopy de purger les fichiers de journalisation inutiliss (voir la section intitule Purge des fichiers de journalisation inutiliss de Berkeley DB ) du dpt original une fois la copie termine. Ajoutez simplement l'option --clean-logs la ligne de commande : $ svnadmin hotcopy --clean-logs /var/svn/depot-bdb /var/svn/depot-bdb-sauvegarde Des outils additionnels existent galement autour de cette commande. Le rpertoire tools/backup du code source de Subversion contient le script hot-backup.py. Ce script ajoute de la gestion de sauvegardes par-dessus svnadmin hotcopy, permettant de ne garder que les dernires sauvegardes (le nombre de sauvegardes conserver est configurable) de chaque dpt. Il gre automatiquement les noms des rpertoires sauvegards pour viter les collisions avec les prcdentes sauvegardes et limine par rotation les sauvegardes les plus anciennes. Mme si vous ralisez aussi des sauvegardes incrmentales, cette commande vous servira peut-tre rgulirement. Par exemple, vous pouvez utiliser hot-backup.py dans un outil permettant le lancement diffr de commandes (tel que cron sur les systmes Unix) afin de le lancer toutes les nuits (ou tout autre intervalle de temps qui vous convient mieux). Quelques administrateurs utilisent un autre mcanisme de sauvegarde bas sur la gnration et le stockage de flux dump des dpts. Nous avons dcrit dans la section intitule Migration des donnes d'un dpt comment utiliser svnadmin dump avec l'option --incremental pour raliser une sauvegarde incrmentale d'une rvision ou d'un intervalle de rvisions donn. Et bien sr, vous pouvez raliser une sauvegarde complte en omettant l'option --incremental dans la commande. Cette mthode comporte certains avantages, entre autres que le format de vos informations sauvegardes est flexible (il n'est pas li une plate-forme, un type de magasin de donnes ou une version particulire de Subversion ou de Berkeley DB). Mais cette flexibilit a un cot, savoir le temps de restauration des donnes, qui en plus augmente avec chaque nouvelle rvision propage dans le dpt. Aussi, comme c'est le cas pour un tas d'autres mthodes de sauvegarde, les modifications sur les proprits de rvision qui sont effectues aprs une sauvegarde de ladite rvision ne sont pas prises en compte par l'utilisation de flux de dump incrmentaux ne se chevauchant pas. C'est pourquoi nous recommandons de ne pas se reposer uniquement sur le type de sauvegarde bas sur les fichiers dump. 145

Administration d'un dpt

Comme vous pouvez le constater, chaque type de sauvegarde a ses avantages et ses inconvnients. La mthode la plus facile est de loin la sauvegarde chaud complte, qui fournit toujours une copie conforme et fonctionnelle de votre dpt. En cas d'accident sur votre dpt de production, vous pouvez effectuer une restauration partir de votre sauvegarde par une simple copie rcursive de rpertoire. Malheureusement, si vous maintenez plusieurs sauvegardes de votre dpt, chaque sauvegarde consomme autant d'espace disque que votre dpt en production. Les sauvegardes incrmentales, en revanche, sont plus rapides raliser et prennent moins de place. Mais le processus de restauration peut s'avrer pnible, avec souvent plusieurs sauvegardes incrmentales appliquer. D'autres mthodes ont leurs propres bizarreries. Les administrateurs doivent trouver le juste milieu entre le cot des sauvegardes et le cot de la restauration. Le programme svnsync (voir la section intitule Rplication d'un dpt ) fournit en fait une approche mdiane assez pratique. Si vous synchronisez rgulirement un miroir en lecture seule avec votre dpt principal, ce miroir en lecture seule se rvle tre un bon candidat pour prendre le relais du dpt dfaillant en cas de besoin. Le principal inconvnient de cette mthode est que seules les donnes suivies en versions sont synchronises les fichiers de configuration du dpt, les verrous utilisateurs sur les chemins ou d'autres lments stocks physiquement dans le rpertoire du dpt mais pas dans le systme de fichiers virtuel du dpt ne sont pas pris en charge par svnsync. Quelle que soit la mthode de sauvegarde utilise, les administrateurs doivent savoir comment les modifications des proprits non suivies en versions des rvisions sont prises en compte (ou pas). Puisque ces modifications elles-mmes ne crent pas de nouvelles rvisions, elles n'activent pas les procdures automatiques post-commit ni mme ventuellement les procdures automatiques pre-revprop-change et post-revprop-change15. Et puisque vous pouvez modifier les proprits de rvision sans respecter l'ordre chronologique (vous pouvez changer n'importe quelle proprit de rvision n'importe quel moment), une sauvegarde incrmentale des dernires rvisions pourrait ne pas intgrer la modification d'une proprit de rvision qui faisait partie d'une sauvegarde prcdente. En rgle gnrale, seuls les plus paranoaques ont besoin de sauvegarder le dpt entier, disons, chaque propagation. Cependant, en considrant qu'un dpt donn possde des mcanismes de redondance autres avec une certaine granularit (tels que des e-mails envoys chaque propagation ou des fichiers dumps incrmentaux), raliser une copie chaud de la base de donnes, dans le cadre des sauvegardes nocturnes quotidiennes des systmes, est une bonne pratique d'administration. Ce sont vos donnes, protgez-les autant que vous le voulez. Bien souvent, la meilleure approche de sauvegarde d'un dpt consiste ne pas mettre tous ses ufs dans le mme panier, en utilisant une combinaison des mthodes dcrites ici. Les dveloppeurs Subversion, par exemple, sauvegardent le code source de Subversion chaque nuit en utilisant hot-backup.py et effectuent une copie distante par rsync de ces sauvegardes compltes ; ils conservent plusieurs archives de tous les emails de notification des propagations et des changements de proprits ; ils ont galement des miroirs maintenus par divers volontaires qui utilisent svnsync. Votre solution peut ressembler cela, mais elle doit tre adapte vos besoins et maintenir l'quilibre entre commodit et paranoa. Et quoi que vous fassiez, vrifiez la validit de vos sauvegardes de temps en temps ( quoi servirait une roue de secours creve ?). Bien que tout ceci n'empche pas votre matriel de subir les affres du destin16, cela vous aidera certainement vous sortir de ces situations dlicates.

Gestion des identifiants uniques (UUID) des dpts


Chaque dpt Subversion possde un identifiant unique (Universally Unique IDentifier en anglais ou UUID). Cet UUID est utilis par les clients Subversion pour vrifier l'identit d'un dpt quand les autres formes de vrification ne sont pas satisfaisantes (telles que l'URL du dpt qui peut varier avec le temps). La plupart des administrateurs de dpt n'ont jamais (ou trs rarement) se proccuper des UUID autrement que comme d'un dtail d'implmentation bas niveau de Subversion. Parfois, cependant, il faut prter attention ce dtail. En rgle gnrale, les UUID de vos dpts de production doivent tre uniques. C'est le but, aprs tout, des UUID. Mais il y a des cas o vous voulez que les UUID de deux dpts soient identiques. Par exemple, quand vous faites une copie de sauvegarde d'un dpt, vous voulez que cette sauvegarde soit une rplique exacte de l'original afin que dans le cas o vous restaureriez la sauvegarde pour remplacer le dpt de production, ceci soit transparent pour les utilisateurs. Quand vous dchargez et chargez l'historique d'un dpt (comme dcrit prcdemment dans la section intitule Migration des donnes d'un dpt ), vous devez dcider si vous incluez l'UUID dans le flux de donnes dcharges (le fichier dump) qui va dans le nouveau dpt. Les circonstances vous imposeront la marche suivre. Il y a plusieurs faons de faire pour attribuer (ou modifier) un UUID un dpt, le cas chant. Avec Subversion 1.5, il suffit d'utiliser la commande svnadmin setuuid. Si vous fournissez un UUID explicite cette sous-commande, elle valide le format de l'UUID et fixe l'identifiant unique du dpt cette valeur. Si vous omettez l'UUID, un nouvel UUID est gnr
15 La 16

commande svnadmin setlog peut tre utilise de manire contourner les procdures automatiques. Vous savez, le fameux concours de circonstances , celui auquel vous tes arriv premier.

146

Administration d'un dpt

automatiquement pour votre dpt. $ svnlook uuid /var/svn/depot cf2b9d22-acb5-11dc-bc8c-05e83ce5dbec $ svnadmin setuuid /var/svn/depot # crer un nouvel UUID $ svnlook uuid /var/svn/depot 3c3c38fe-acc0-11dc-acbc-1b37ff1c8e7c $ svnadmin setuuid /var/svn/depot \ cf2b9d22-acb5-11dc-bc8c-05e83ce5dbec # restaure l'ancien UUID $ svnlook uuid /var/svn/depot cf2b9d22-acb5-11dc-bc8c-05e83ce5dbec $ Pour ceux qui utilisent une version de Subversion antrieure 1.5, ces tches sont un peu plus compliques. Vous pouvez attribuer explicitement un UUID en redirigeant le flux d'un fichier dump qui comporte le nouvel UUID avec la commande svnadmin load --force-uuid CHEMIN-DU-DEPOT. $ svnadmin load --force-uuid /var/svn/depot <<EOF SVN-fs-dump-format-version: 2 UUID: cf2b9d22-acb5-11dc-bc8c-05e83ce5dbec EOF $ svnlook uuid /var/svn/depot cf2b9d22-acb5-11dc-bc8c-05e83ce5dbec $ Faire gnrer un nouvel UUID une ancienne version de Subversion n'est pas aussi simple. La meilleure faon de faire est certainement de trouver un moyen de gnrer un UUID puis d'affecter explicitement cet UUID au dpt.

Dplacement et suppression d'un dpt


Les donnes d'un dpt Subversion sont toutes contenues dans l'arborescence du rpertoire du dpt. Ainsi, vous pouvez dplacer un dpt Subversion vers un autre endroit du disque, renommer un dpt, copier un dpt ou effacer un dpt entier en utilisant les outils de votre systme d'exploitation pour manipuler les rpertoires mv, cp -a et rm -r pour les platesformes Unix ; copy, move et rmdir /s /q sous Windows ; cliquodrome avec de nombreux explorateurs graphiques, etc. Bien sr, il y a souvent d'autres choses faire lors de ce genre de manipulations. Par exemple, vous voulez peut-tre mettre jour la configuration de votre serveur Subversion pour le faire pointer vers le nouveau chemin du dpt dplac ou pour supprimer les lments de configuration relatifs un dpt ayant t effac. Si vous avez des processus automatiques qui publient des informations partir de vos dpts, ou qui leur sont relatives, ils doivent srement tre mis jour. La configuration des procdures automatiques a peut-tre besoin d'tre modifie. Les utilisateurs doivent tre informs. La liste est longue, mais vous avez srement des procdures d'exploitation et des rgles d'administration de votre dpt Subversion qui vous indiquent ce qu'il faut faire. Dans le cas d'un dpt copi, vous devez aussi prendre en compte le fait que Subversion utilise l'identifiant unique UUID pour distinguer les dpts. Si vous copiez un dpt en utilisant la commande typique de copie rcursive de votre interprteur de commande, vous vous retrouvez avec deux dpts absolument identiques, y compris en ce qui concerne l'UUID. Dans certains cas, c'est ce que l'on cherche. Dans d'autres cas, non. Vous devez alors gnrer un nouvel UUID pour l'un des deux dpts identiques. Lisez la section intitule Gestion des identifiants uniques (UUID) des dpts pour plus d'informations sur la gestion des UUID.

Rsum
prsent vous devez avoir une comprhension de base de la cration, la configuration et l'administration des dpts Subversion. Nous vous avons prsent les diffrents outils qui vous assistent dans ces tches. Tout au long de ce chapitre, nous avons identifi quelques chausse-trappes d'administration et propos quelques solutions pour les viter. Tout ce qui vous reste faire est de dcider quelles donnes passionnantes vous allez hberger dans votre dpt et, finalement, comment les mettre disposition sur un rseau. Le prochain chapitre est entirement consacr au travail en rseau.

147

Chapitre 6. Configuration du serveur


Un dpt Subversion hberg sur une machine donne est accessible simultanment par des clients fonctionnant sur cette mme machine en utilisant la mthode file://. Mais la configuration typique de Subversion consiste en une machine serveur unique laquelle accdent des clients tournant sur les ordinateurs de tout le bureau ou, peut-tre, de partout dans le monde. Ce chapitre dcrit comment rendre visible votre dpt Subversion en dehors de la machine hte pour qu'il soit utilisable par des clients distants. Nous couvrons les mcanismes serveurs disponibles actuellement pour Subversion, leur configuration et leur utilisation. la fin de ce chapitre, vous devriez tre apte dcider quelle configuration rseau convient vos besoins et comprendre comment mettre en place cette configuration sur votre machine hte.

Prsentation gnrale
Subversion a t conu avec une couche rseau abstraite. Cela signifie que l'on peut accder de faon automatise un dpt par toute sorte de protocoles client/serveur, et que l'interface (l'API) d'accs au dpt du client permet aux programmeurs d'crire des greffons implmentant les protocoles rseaux appropris. En thorie, Subversion peut utiliser un nombre infini d'implmentations rseau. En pratique, il n'existe ce jour que deux serveurs. Apache est un serveur web extrmement populaire ; en utilisant le module mod_dav_svn, Apache a accs au dpt et peut le rendre accessible aux clients via le protocole WebDAV/DeltaV, qui est une extension d'HTTP. Comme Apache est un serveur trs complet, il inclut un grand nombre de fonctionnalits gratuites , telles que : communications chiffres par SSL, journalisation, intgration avec bon nombre de systmes d'authentification tiers et navigation web limite des dpts. l'oppos vous trouvez svnserve : un petit programme serveur, lger, qui communique via un protocole sur mesure avec les clients. Parce que ce protocole a t conu spcialement pour Subversion et possde la notion d'tats ( la diffrence d'HTTP), il offre des oprations significativement plus rapides, certes aux dpens de certaines fonctionnalits. Bien qu'il sache utiliser SASL pour offrir toute une gamme d'options d'authentification et de chiffrement, il ne possde ni journalisation ni navigation web intgre. Il est nanmoins trs facile mettre en place et constitue souvent le meilleur choix pour de petites quipes dbutant avec Subversion. Une troisime option consiste utiliser svnserve encapsul dans une connexion SSH. Mme si ce scnario utilise toujours svnserve, il diffre quelque peu, en termes de fonctionnalits, d'un dploiement svnserve traditionnel. SSH sert chiffrer toutes les communications. Par ailleurs, l'authentification utilise exclusivement SSH, ce qui ncessite des comptes utilisateurs au niveau systme sur le serveur hte ( la diffrence de svnserve simple , qui possde ses propres comptes utilisateurs privs). Enfin, avec ce type de dploiement, un processus svnserve temporaire priv est cr pour chaque utilisateur qui se connecte, ce qui quivaut (du point de vue des permissions) permettre un groupe d'utilisateurs locaux d'accder au dpt via des URL file://. Les autorisations d'accs bases sur des chemins n'ont donc aucun sens, puisque chaque utilisateur accde directement aux fichiers de la base de donnes du dpt. Le Tableau 6.1, Comparaison des fonctionnalits des serveurs Subversion prsente un rsum rapide des trois types courants de dploiements de serveurs.

Tableau 6.1. Comparaison des fonctionnalits des serveurs Subversion


Fonctionnalit Authentification Apache + mod_dav_svn Authentification HTTP(S) de base, certificats X.509, LDAP, NTLM, ou tout autre mcanisme compatible avec Apache. svnserve svnserve sur SSH CRAM-MD5 par dfaut ; SSH. LDAP, NTLM, ou tout autre mcanisme compatible avec SASL.

Comptes utilisateurs

Fichiers privs ou tout autre Fichiers privs ou tout autre Comptes utilisateurs systmes. mcanisme compatible avec mcanisme compatible avec Apache (LDAP, SQL, etc.). SASL (LDAP, SQL, etc.). L'accs en lecture/criture peut tre autoris sur le dpt tout entier ou restreint des chemins spcifis. L'accs en lecture/criture L'accs en lecture/criture ne peut tre autoris sur le dpt peut tre autoris que sur le tout entier ou restreint des dpt tout entier. chemins spcifis.

Contrle d'accs

148

Configuration du serveur

Fonctionnalit Chiffrement

Apache + mod_dav_svn Disponible via SSL (option).

svnserve

svnserve sur SSH

Disponible via les Inhrent toute connexion fonctionnalits optionnelles de SSH. SASL. Pas de journaux.

Journalisation

Journaux Apache complets de Pas de journaux. chaque requte HTTP et, en option, la journalisation de haut niveau des oprations ct client.

Interoprabilit Accs via une interface Web

Accessible par tout client Ne peut communiquer qu'avec Ne peut communiquer qu'avec WebDAV. des clients svn. des clients svn. Support intgr limit ou via Uniquement via des outils Uniquement via des outils des outils tiers tels que tierces tels que ViewVC. tierces tels que ViewVC. ViewVC.

Rplication serveur de type Possibilit d'un mandataire Possibilit de crer seulement Possibilit de crer seulement matre-esclave transparent pour l'criture (de des serveurs esclaves en des serveurs esclaves en l'esclave vers le matre). lecture seule. lecture seule. Vitesse Mise en place Relativement plus lent. Relativement complexe. Relativement plus rapide. Extrmement simple. Relativement plus rapide. Moyennement simple.

Choix d'une configuration serveur


Et alors, quel serveur vous faut-il ? Quel est le meilleur ? Bien videmment, il n'y a pas de bonne rponse cette question. Chaque quipe a des besoins propres et les diffrents serveurs reprsentent des compromis diffrents. Le projet Subversion lui-mme ne recommande pas un serveur plus qu'un autre, ni ne considre qu'un serveur est plus officiel qu'un autre. Voici quelques argumentaires qui vous aideront choisir entre un dploiement et un autre, ainsi que quelques raisons de ne pas choisir l'un d'entre eux.

Serveur svnserve
Les bonnes raisons de l'utiliser : facile et rapide mettre en place ; le protocole rseau possde la notion d'tats et est significativement plus rapide que WebDAV ; pas besoin de crer des comptes utilisateurs systme sur le serveur ; le mot de passe ne circule pas sur le rseau. Pourquoi l'viter : par dfaut, seule une mthode d'authentification est disponible, le protocole rseau n'est pas chiffr et le serveur enregistre les mots de passe en clair (tous ces lments peuvent tre modifis en configurant SASL, mais cela requiert un peu plus de travail) ; aucune journalisation, de quelque sorte que ce soit, n'est disponible, ni mme celle des erreurs ; pas de navigation web intgre (il vous faut installer un serveur web spar et un logiciel de navigation du dpt pour ajouter cette fonctionnalit).

svnserve sur SSH


149

Configuration du serveur

Les bonnes raisons de l'utiliser : le protocole rseau possde la notion d'tats et est significativement plus rapide que WebDAV ; vous pouvez tirer parti des comptes SSH existants et de l'infrastructure dj mise en place pour les utilisateurs ; tout le trafic rseau est chiffr. Pourquoi l'viter : il n'y a qu'un seul choix possible de mthode d'authentification ; aucune journalisation, de quelque sorte que ce soit, n'est disponible, ni mme celle des erreurs ; les utilisateurs doivent tre membres du mme groupe systme ou utiliser une cl SSH partage ; mal utilis, il peut aboutir des problmes de droits sur les fichiers.

Serveur HTTP Apache


Les bonnes raisons de l'utiliser : il permet Subversion d'utiliser n'importe lequel des nombreux systmes d'authentification dj intgrs dans Apache ; pas besoin de crer des comptes systme sur le serveur ; journalisation Apache complte disponible ; le trafic rseau peut tre chiffr par SSL ; HTTP(S) fonctionne gnralement mme derrire des pare-feu d'entreprise ; la possibilit de parcourir le dpt avec un navigateur Web est disponible nativement ; le dpt peut tre mont en tant que lecteur rseau des fins de gestion de versions transparente (voir la section intitule Gestion de versions automatique ). Pourquoi l'viter : significativement plus lent que svnserve, car HTTP est un protocole sans tat et ncessite plus d'allers et retours rseau ; la mise en place initiale peut s'avrer complexe.

Recommandations
En gnral, les auteurs de ce livre recommandent une installation ordinaire de svnserve aux petites quipes qui dbutent avec Subversion ; c'est le plus simple installer et celui qui pose le moins de problmes de maintenance. Vous pouvez toujours passer au dploiement d'un serveur plus complexe au fur et mesure que vos besoins voluent. Voici quelques recommandations et astuces gnrales, bases sur des annes de support aux utilisateurs : si vous essayez de mettre en place le serveur le plus simple possible pour votre groupe, une installation ordinaire de svnserve est la voie la plus sre et la plus rapide. Notez cependant que les donnes de votre dpt circuleront en clair sur le rseau. Si votre dploiement se situe entirement l'intrieur du LAN ou du VPN de votre compagnie, ce n'est pas un problme. Si le dpt est accessible sur Internet, il serait bon de vous assurer que son contenu n'est pas sensible (c'est--dire qu'il ne contient que du code open source), ou alors de faire l'effort supplmentaire de configurer SASL pour chiffrer les communications rseau ;

150

Configuration du serveur

si vous devez vous insrer au sein de systmes d'authentification dj en place (LDAP, Active Directory, NTLM, X.509, etc.), il vous faudra utiliser soit le serveur bas sur Apache, soit svnserve configur avec SASL. Si vous avez un besoin absolu de journaux des erreurs ct serveur ou de journaux des activits ct client, le serveur bas sur Apache est le seul choix possible ; que vous ayez dcid d'utiliser Apache ou un banal svnserve, crez un utilisateur svn unique sur votre systme et utilisez-le pour faire tourner le processus serveur. Assurez-vous galement que la totalit du rpertoire du dpt est la proprit de cet utilisateur. Du point de vue de la scurit, les donnes du dpt restent ainsi englobes et protges par l'application des droits grs par le systme de fichiers du systme d'exploitation et sont modifiables uniquement par le processus serveur Subversion lui-mme ; si vous avez une infrastructure existante base principalement sur des comptes SSH et si vos utilisateurs possdent dj des comptes systme sur la machine qui sert de serveur, il est logique de dployer une solution svnserve sur SSH. Dans le cas contraire, nous ne recommandons gnralement pas cette option au public. Il est considr comme plus sr de donner l'accs au dpt vos utilisateurs au moyen de comptes (imaginaires) grs par svnserve ou Apache plutt que par de vritables comptes systme. Si vous voulez vraiment chiffrer les communications, nous vous recommandons d'utiliser Apache avec chiffrement SSL ou svnserve avec chiffrement SASL la place ; ne vous laissez pas sduire par l'ide trs simple de donner l'accs un dpt tous vos utilisateurs directement via des URL file://. Mme si le dpt est accessible tous sur un lecteur rseau, c'est une mauvaise ide. Elle te toutes les couches de protection entre les utilisateurs et le dpt : les utilisateurs peuvent corrompre accidentellement (ou intentionnellement) la base de donnes du dpt, il est difficile de mettre le dpt hors ligne pour inspection ou pour mise niveau et vous risquez d'aboutir de graves problmes de droits sur les fichiers (voir la section intitule Accs au dpt par plusieurs mthodes ). Remarquez que c'est aussi une des raisons pour laquelle nous dconseillons d'accder aux dpts via des URL svn+ssh:// : du point de vue de la scurit, c'est en fait comme si les utilisateurs locaux y accdaient via file://, ce qui peut entraner exactement les mmes problmes si l'administrateur ne fait pas preuve de prudence.

svnserve, un serveur sur mesure


Le programme svnserve est un serveur lger, capable de dialoguer avec des clients sur un rseau TCP/IP en utilisant un protocole ddi avec gestion des tats. Les clients contactent le serveur svnserve en utilisant une URL qui commence par svn:// ou svn+ssh://. Cette section explique diffrentes mises en uvre de svnserve, l'authentification des clients sur le serveur et la configuration d'un contrle d'accs appropri pour vos dpts.

Dmarrage du serveur
Il existe diffrentes faons de dmarrer le programme svnserve : lancer svnserve en tant que serveur autonome, l'coute de requtes ; utiliser le dmon Unix inetd pour lancer une instance temporaire de svnserve quand une requte arrive sur un port dtermin ; utiliser SSH pour lancer une instance temporaire de svnserve dans un tunnel chiffr ; lancer svnserve en tant que service Microsoft Windows.

svnserve en serveur autonome


Le plus facile est de dmarrer svnserve en tant que serveur autonome. Pour ce faire, utilisez l'option -d (d pour daemon qui est l'appellation consacre pour les serveurs Unix) : $ svnserve -d $

# svnserve est maintenant actif, en coute sur le port 3690

Lorsque vous lancez svnserve en serveur autonome, vous pouvez utiliser les options --listen-port et --listen-host pour spcifier le port et l'adresse voulus pour couter . 151

Configuration du serveur

Une fois le serveur dmarr de cette manire, tous les dpts prsents sur votre machine seront accessibles par le rseau. Un client doit spcifier un chemin absolu dans l'URL du dpt. Par exemple, si un dpt est situ sous /var/svn/projet-1, un client l'atteindra par svn://hote.exemple.com/var/svn/projet-1. Pour renforcer la scurit, vous pouvez passer l'option -r svnserve afin de restreindre l'export aux dpts situs sous le chemin indiqu. Par exemple : $ svnserve -d -r /var/svn L'utilisation de l'option -r modifie le chemin que le serveur considre comme la racine du systme de fichiers exporter. Les clients utiliseront alors des URL ne comportant pas cette portion du chemin (ce qui rend les URL plus courtes et plus discrtes) : $ svn checkout svn://hote.exemple.com/projet-1

svnserve via inetd


Si vous dsirez que inetd lance le processus, il vous faudra passer l'option -i (--inetd). Dans l'exemple suivant, nous montrons le rsultat de la commande svnserve -i, mais notez bien que ce c'est pas de cette manire que l'on dmarre le serveur ; reportez-vous aux paragraphes qui suivent l'exemple pour savoir comment configurer inetd pour qu'il dmarre svnserve. $ svnserve -i ( success ( 1 2 ( ANONYMOUS ) ( edit-pipeline ) ) ) Quand on l'invoque avec l'option --inetd, svnserve tente de communiquer avec un client Subversion via l'entre et la sortie standards (stdin et stdout) en utilisant un protocole spcifique. C'est le comportement habituel de tout programme lanc par inetd. L'IANA a rserv le port 3690 pour le protocole Subversion ; sur un systme Unix vous pouvez donc ajouter au fichier /etc/services les lignes suivantes (si elles n'existent pas dj) : svn svn 3690/tcp 3690/udp # Subversion # Subversion

Si votre systme utilise un serveur inetd classique de type Unix, vous pouvez ajouter la ligne suivante /etc/inetd.conf : svn stream tcp nowait proprio-svn /usr/bin/svnserve svnserve -i Assurez-vous que l'utilisateur proprio-svn possde des droits d'accs appropris pour vos dpts. Ds lors, quand une connexion client arrive sur le port 3690, inetd va crer un processus svnserve pour lui rpondre. Bien sr, vous pouvez galement ajouter l'option -r cette ligne de configuration, pour prciser quels dpts doivent tre exports.

svnserve encapsul dans un tunnel


Le mode tunnel est une troisime faon de lancer svnserve, via l'option -t. Ce mode prsuppose qu'un programme de connexion distance tel que rsh ou ssh a permis un utilisateur de s'authentifier avec succs et lance alors un processus priv svnserve pour le compte de cet utilisateur (remarquez qu'en tant qu'utilisateur vous aurez rarement, sinon jamais, l'occasion de lancer svnserve avec l'option -t en ligne de commande ; c'est le serveur SSH qui le fait votre place). Le programme svnserve se comporte alors normalement (utilisation des entres/sorties stdin et stdout) et suppose que le trafic est redirig automatiquement vers le client par un tunnel. Quand svnserve est lanc par un gestionnaire de tunnel comme ici, soyez sans crainte : l'utilisateur authentifi possdera les droits de lecture et d'criture sur les fichiers de la base de donnes. C'est essentiellement la mme chose que quand un utilisateur local accde au dpt via des URL file://. Cette option est dcrite en dtail plus loin dans ce chapitre, dans la section intitule Encapsulation de svnserve dans un tunnel 152

Configuration du serveur

SSH .

svnserve en tant que service Windows


Si votre systme Windows est un descendant de Windows NT (2000, 2003, XP ou Vista), vous pouvez lancer svnserve en tant que service Windows. C'est gnralement une mthode bien plus plaisante que de le lancer en dmon indpendant via l'option (-d). Utiliser le mode dmon ncessite de lancer une console, de taper une commande et ensuite de laisser la fentre de la console tourner indfiniment. Un service Windows, au contraire, tourne l'arrire-plan, peut tre lanc automatiquement au dmarrage et peut tre dmarr ou arrt l'aide de la mme interface d'administration que les autres services Windows. Vous devrez dfinir le nouveau service en utilisant l'outil en ligne de commande SC.EXE. De faon analogue la ligne de configuration inetd, il vous faudra fournir la commande de lancement prcise de svnserve pour que Windows le lance au dmarrage : C:\> sc create svn binpath= "C:\svn\bin\svnserve.exe --service -r C:\depot" displayname= "Serveur Subversion" depend= Tcpip start= auto Ceci dfinit un nouveau service Windows nomm svn , qui excute une commande particulire svnserve.exe quand il dmarre (dont la racine est, dans ce cas, C:\depot). Il y a toutefois un certain nombre de prcautions prendre avec cet exemple. Premirement, remarquez que le programme svnserve.exe doit toujours tre lanc avec l'option --service. Toute autre option de svnserve doit ensuite tre spcifie sur la mme ligne, mais vous ne pouvez pas ajouter d'options qui seraient en conflit avec celle-ci, telles que --daemon (-d), --tunnel, ou --inetd (-i). D'autres options, comme -r ou -listen-port ne posent pas de problme. Deuximement, faites attention aux espaces quand vous tapez la commande SC.EXE : les groupes cl= valeur ne doivent pas comporter d'espace dans cl= et doivent comporter exactement une espace avant valeur. Enfin, faites attention aux espaces prsentes dans la ligne de commande que vous indiquez. Si le nom d'un rpertoire contient des espaces (ou tout autre caractre qui ait besoin d'tre banalis), placez l'ensemble du contenu de binpath entre guillemets, qui doivent eux-mmes tre banaliss : C:\> sc create svn binpath= "\"C:\program files\svn\bin\svnserve.exe\" --service -r C:\depot" displayname= "Serveur Subversion" depend= Tcpip start= auto Notez aussi que le terme binpath prte confusion : sa valeur est une ligne de commande, pas le chemin d'accs un excutable. C'est pourquoi vous devez l'entourer de guillemets s'il contient des espaces. Une fois que le service a t cre, il peut tre arrt, dmarr ou interrog l'aide des outils standards de l'interface graphique (le programme Services des outils d'administration) ou de la ligne de commande : C:\> net stop svn C:\> net start svn Le service peut aussi tre dsinstall (c'est--dire supprim) en effaant sa dfinition : sc delete svn. Prenez soin d'arrter le service auparavant ! Le programme SC.EXE possde de nombreuses autres sous-commandes ; tapez sc /? en ligne de commande pour en savoir plus.

Authentification et contrle d'accs intgrs


Lorsqu'un client se connecte au processus svnserve, les choses suivantes se passent : Le client slectionne un rpertoire particulier.

153

Configuration du serveur

Le serveur analyse le fichier conf/svnserve.conf de ce dpt et commence suivre les politiques d'authentification et de contrle d'accs qui y sont dcrites. Selon les politiques dfinies, une des choses suivantes a lieu : Le client est autoris lancer des requtes anonymes, sans jamais recevoir le moindre dfi d'authentification. Le client peut recevoir un dfi d'authentification tout instant. Si l'on est en mode tunnel, le client dclare lui-mme avoir dj satisfait une authentification externe (gnralement par SSH). Le serveur svnserve ne sait envoyer, par dfaut, que des dfis d'authentification CRAM-MD51. Plus prcisment, le serveur envoie une petite quantit de donnes aux clients. Le client utilise l'algorithme de hachage MD5 pour crer une empreinte combinant les donnes et le mot de passe, puis renvoie l'empreinte en guise de rponse. Le serveur effectue le mme calcul avec le mot de passe enregistr pour vrifier que le rsultat est identique. Le mot de passe ne circule ainsi jamais en clair sur le rseau. Si votre serveur svnserve a t compil en incluant le support de SASL, non seulement il sait comment envoyer des dfis CRAM-MD5, mais il connat aussi probablement un grand nombre d'autres mcanismes d'authentification. Consultez la section intitule Utilisation de svnserve avec SASL plus loin dans ce chapitre pour savoir comment configurer l'authentification et le chiffrement avec SASL. Le client peut bien sr aussi tre authentifi en externe par un gestionnaire de tunnel tel que ssh. Dans ce cas, le serveur se contente de prendre l'identifiant par lequel il a t lanc et de s'en servir comme utilisateur authentifi. Pour plus de dtails, reportez-vous plus loin la section intitule Encapsulation de svnserve dans un tunnel SSH . Vous avez srement dj devin que le fichier svnserve.conf est le mcanisme central qui contrle les politiques d'authentification et de contrle d'accs. Ce fichier a le mme format que d'autres fichiers de configuration (voir la section intitule Zone de configuration des excutables ) : les noms de paragraphes sont entours de crochets ([ et ]), les lignes de commentaires commencent par des dises (#) et chaque paragraphe contient des variables spcifiques qui peuvent tre dfinies (variable = valeur). Examinons ces fichiers et apprenons les utiliser.

Cration d'un fichier utilisateurs et d'un domaine d'authentification


Pour ce qui suit, la section [general] de svnserve.conf contient toutes les variables dont vous avez besoin. Commencez par modifier les valeurs de toutes les variables : choisissez un nom pour le fichier qui contiendra vos noms d'utilisateur ainsi que vos mots de passe et choisissez un domaine d'authentification : [general] password-db = fichier-utilisateurs realm = exemple de domaine Le domaine (realm dans le fichier de configuration) est un nom que vous dfinissez. Il indique aux clients quelle sorte d' espace de noms ils se connectent ; le client Subversion l'affiche dans l'invite d'authentification et l'utilise comme cl (en combinaison avec le nom de machine et le port du serveur) pour mettre en cache les lments d'authentification sur le disque (voir la section intitule Mise en cache des lments d'authentification du client ). La variable password-db pointe vers un fichier spar qui contient une liste de noms d'utilisateurs et de mots de passe, utilisant le mme format usuel. Par exemple : [users] harry = motdepassemachin sally = motdepassebidule La valeur de password-db peut correspondre un chemin absolu ou un chemin relatif pour le fichier des utilisateurs. Pour de nombreux administrateurs, conserver le fichier dans la zone conf/, aux cts de svnserve.conf, est une solution simple et facile. D'un autre ct, il se pourrait que deux dpts, voire plus, doivent partager le mme fichier ; dans ce cas, le fichier devrait sans doute tre situ dans un rpertoire plus accessible. Les dpts partageant le mme fichier utilisateurs
1

Voir la RFC 2195.

154

Configuration du serveur

devraient aussi tre configurs de sorte qu'ils soient dans le mme domaine, puisque la liste des utilisateurs dfinit, par essence, un domaine d'authentification. Quel que soit l'emplacement du fichier, faites attention positionner les droits en lecture/ criture de faon approprie. Si vous savez sous quel nom d'utilisateur svnserve fonctionnera, restreignez l'accs au fichier utilisateurs en consquence.

Mise en place du contrle d'accs


Il y a deux variables supplmentaires dfinir dans le fichier svnserve.conf : elles dterminent ce que les utilisateurs nonauthentifis (anonymes) et les utilisateurs authentifis ont le droit de faire. Les variables anon-access et auth-access peuvent contenir les valeurs none, read, ou write. Choisir la valeur none empche la fois lecture et criture ; read autorise l'accs en lecture seule au dpt et write autorise l'accs complet en lecture/criture au dpt. Par exemple : [general] password-db = fichier-utilisateurs realm = exemple de domaine # les utilisateurs anonymes ne peuvent accder au dpt qu'en lecture anon-access = read # les utilisateurs authentifis peuvent la fois lire et crire auth-access = write Les lignes prsentes dans le fichier contiennent en fait les valeurs par dfaut des variables, au cas o vous oublieriez de les dfinir. Si vous voulez tre encore plus prudent, vous pouvez compltement interdire les accs anonymes : [general] password-db = fichier-utilisateurs realm = exemple de domaine # les utilisateurs anonymes ne sont pas autoriss anon-access = none # les utilisateurs authentifis peuvent la fois lire et crire auth-access = write Le processus serveur sait interprter non seulement ce contrle d'accs gnrique, mais aussi des restrictions d'accs plus fines associes des fichiers et rpertoires spcifiques du dpt. Pour utiliser cette fonctionnalit, vous devez dfinir un fichier contenant des rgles plus dtailles, puis faire pointer la variable authz-db vers ce fichier : [general] password-db = fichier-utilisateurs realm = exemple de domaine # Rgles d'accs propres certains emplacements authz-db = fichier-authz Nous tudions la syntaxe du fichier authz plus loin dans ce chapitre, dans la section intitule Contrle d'accs bas sur les chemins . Notez que la variable authz-db n'est pas mutuellement exclusive avec les variables anon-access et authaccess ; si toutes les variables sont dfinies en mme temps, toutes les rgles doivent tre satisfaites pour que l'accs soit autoris.

Utilisation de svnserve avec SASL


L'authentification par CRAM-MD5 suffit aux besoins de bon nombre d'quipes. Cependant, si votre serveur (et vos clients Subversion) ont t compils avec la bibliothque Cyrus Simple Authentication and Security Layer (SASL), vous avez votre disposition un certain nombre d'options d'authentification et de chiffrement. Qu'est-ce que SASL ?

155

Configuration du serveur

Cyrus Simple Authentication and Security Layer (ce qui signifie Couche d'authentification et de scurit simple ) est un logiciel libre qui a t crit par l'universit Carnegie Mellon. Il ajoute des possibilits d'authentification et de chiffrement n'importe quel protocole rseau et, partir de la version 1.5 de Subversion, le serveur svnserve ainsi que le client svn sont tous les deux capables de se servir de cette bibliothque. Elle peut ne pas tre votre disposition : si vous compilez Subversion vous-mme, il vous faut au minimum la version 2.1 de SASL d'installe sur votre systme et vous devez vous assurer qu'elle est bien prise en compte durant le processus de compilation de Subversion. Si vous utilisez un paquet binaire prcompil de Subversion, vous devez vrifier auprs de celui qui maintient ce paquet si SASL a t inclus la compilation. SASL est fourni avec de nombreux modules optionnels qui reprsentent diffrents systmes d'authentification : Kerberos (GSSAPI), NTLM, One-Time-Passwords (OTP), DIGEST-MD5, LDAP, SecureRemote-Password (SRP) et d'autres encore. Certains mcanismes seront disponibles, d'autres pas ; pensez vrifier quels modules sont inclus. Vous pouvez tlcharger Cyrus SASL ( la fois le code source et la documentation) l'adresse http://asg.web.cmu.edu/sasl/sasl-library.html.

Normalement, quand un client Subversion se connecte svnserve, le serveur envoie un message de bienvenue qui liste les fonctionnalits qu'il supporte et le client rpond avec une liste similaire. Si le serveur est configur pour exiger une authentification, il envoie ensuite un dfi listant les mcanismes d'authentification disponibles ; le client rpond en choisissant un des mcanismes et l'authentification se droule ensuite par quelques changes de messages. Mme quand SASL n'est pas prsent dans la liste, le client et le serveur sont capables d'utiliser les mcanismes CRAM-MD5 et ANONYMOUS (voir la section intitule Authentification et contrle d'accs intgrs ). Si le serveur et le client ont t compils pour inclure SASL, un certain nombre d'autres mcanismes d'authentification sont ventuellement disponibles. Nanmoins, vous devez configurer explicitement SASL sur le serveur pour qu'ils soient proposs.

Authentification par SASL


Pour activer les mcanismes spcifiques SASL sur le serveur, il faut faire deux choses. D'abord, crez un paragraphe [sasl] dans le fichier svnserve.conf de votre dpt avec le couple cl/valeur initial : [sasl] use-sasl = true Ensuite, crez le fichier principal de configuration de SASL, appel svn.conf, un endroit o la bibliothque SASL saura le trouver gnralement dans un rpertoire o sont situs les greffons SASL. Vous devez localiser le rpertoire des greffons de votre systme, tel que /usr/lib/sasl2/ ou /etc/sasl2/ (notez qu'il ne s'agit pas l du fichier svnserve.conf qui rside dans votre dpt !). Sur un serveur Windows vous devez aussi diter la base de registre ( l'aide d'un outil tel que regedit) pour indiquer SASL les emplacements o chercher. Crez une cl nomme [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library] et placez-y deux cls : l'une appele SearchPath (dont la valeur est le chemin du rpertoire contenant les bibliothques de greffons SASL sasl*.dll) et l'autre appele ConfFile (dont la valeur est le chemin du rpertoire parent contenant le fichier svn.conf que vous avez cr). Parce que SASL fournit de trs nombreux mcanismes d'authentification, il serait insens (et bien au-del du cadre de ce livre) d'essayer de dcrire toutes les configurations serveurs possibles. Nous vous recommandons plutt de lire la documentation fournie dans le sous-rpertoire doc/ du code source de SASL. Elle dcrit en dtail chaque mcanisme, ainsi que la manire de configurer le serveur correctement pour chacun d'entre eux. Dans ce paragraphe, nous nous contentons de donner un exemple simple de configuration du mcanisme DIGEST-MD5. Par exemple, si votre fichier subversion.conf (ou svn.conf) contient ce qui suit : pwcheck_method: auxprop auxprop_plugin: sasldb sasldb_path: /etc/ma_bdd_sasl mech_list: DIGEST-MD5 vous demandez SASL de proposer le mcanisme DIGEST-MD5 aux clients et de comparer les mots de passe des utilisateurs une base de mots de passe prive situe l'emplacement /etc/ma_bdd_sasl. Un administrateur systme pourra ensuite 156

Configuration du serveur

utiliser le programme saslpasswd2 pour ajouter ou modifier les noms d'utilisateurs et les mots de passe contenus dans cette base de donnes : $ saslpasswd2 -c -f /etc/ma_bdd_sasl -u domaine utilisateur Quelques consignes de prudence : tout d'abord, l'argument domaine qui est pass saslpasswd2 doit correspondre au mme domaine que celui que vous avez dfini dans le fichier svnserve.conf ; s'ils ne correspondent pas, l'authentification chouera. En outre, cause d'une limitation de SASL, ce domaine commun doit tre une chane sans espace. Enfin, si vous dcidez d'utiliser la base de donnes standard de mots de passe SASL, assurez-vous que le programme svnserve a accs en lecture ce fichier (et ventuellement aussi en criture, si vous utilisez un mcanisme tel que OTP). Ceci est une manire simple de configurer SASL. De nombreux autres mcanismes d'authentification sont disponibles et les mots de passe peuvent tre conservs dans des conteneurs diffrents, par exemple des annuaires LDAP ou des bases de donnes SQL. Reportez-vous la documentation complte de SASL pour plus de dtails. Souvenez-vous que si vous configurez votre serveur pour qu'il n'autorise que certains mcanismes d'authentification SASL, tous les clients qui se connectent ont l'obligation de supporter SASL. Tout client Subversion compil sans SASL (ce qui inclut tous les clients antrieurs la version 1.5) est incapable de se connecter. D'un autre ct, ce type de restriction est peut-tre exactement ce que vous recherchez ( Mes clients doivent tous utiliser Kerberos ! ). Nanmoins, si vous voulez permettre des clients non-SASL de se connecter, pensez bien inclure le mcanisme CRAM-MD5 dans les choix possibles. Tous les clients savent utiliser CRAM-MD5, qu'ils aient des fonctionnalits SASL ou pas.

Chiffrement SASL
SASL est galement capable d'effectuer le chiffrement des donnes si un mcanisme particulier le supporte. Le mcanisme intgr CRAM-MD5 ne supporte pas le chiffrement, mais DIGEST-MD5 le supporte et d'autres mcanismes tels que SRP requirent l'utilisation de la bibliothque OpenSSL. Pour activer ou dsactiver diffrents niveaux de chiffrement, vous pouvez dfinir deux variables dans le fichier svnserve.conf de votre dpt : [sasl] use-sasl = true min-encryption = 128 max-encryption = 256 Les variables min-encryption et max-encryption contrlent le niveau de chiffrement exig par le serveur. Pour dsactiver compltement le chiffrement, mettez les deux valeurs 0. Pour activer une simple somme de contrle sur les donnes (par exemple pour empcher toute manipulation douteuse et garantir l'intgrit des donnes sans chiffrement), mettez les deux valeurs 1. Si vous voulez autoriser le chiffrement, sans que ce soit obligatoire, mettez 0 pour la valeur minimale et un nombre de bits donn pour la valeur maximale. Pour exiger un chiffrement inconditionnel, mettez les deux valeurs un nombre plus grand que 1. Dans l'exemple prcdent, nous obligeons les clients utiliser au moins un chiffrement 128 bits et au plus un chiffrement 256 bits.

Encapsulation de svnserve dans un tunnel SSH


L'authentification intgre (ainsi que SASL) peuvent tre trs pratiques, car ils vitent d'avoir crer de vritables comptes systmes. D'un autre ct, certains administrateurs ont dj des systmes d'authentification bien tablis en place. Dans ce cas, tous les utilisateurs du projet possdent dj des comptes systmes et peuvent se connecter au serveur par SSH. Utiliser SSH en conjonction avec svnserve est facile. Le client utilise juste une URL svn+ssh:// pour se connecter : $ whoami harry $ svn list svn+ssh://hote.exemple.com/depot/projet harryssh@hote.exemple.com's password: ***** truc machin bidule 157

Configuration du serveur

Dans cet exemple, le client Subversion lance un processus local ssh, se connecte hote.exemple.com, s'authentifie en tant que harryssh (en accord avec la configuration SSH des utilisateurs) puis un processus svnserve priv est gnr automatiquement sur la machine distante, processus dont le propritaire est l'utilisateur harryssh. La commande svnserve est lance en mode tunnel (-t) et son protocole rseau est encapsul dans la connexion chiffre par ssh, le gestionnaire de tunnel. Si le client effectue une propagation, l'auteur de la nouvelle rvision sera l'utilisateur authentifi (harryssh). Ce qu'il est important de comprendre ici est que le client Subversion ne se connecte pas un serveur svnserve fonctionnant en permanence. Cette mthode d'accs ne requiert pas la prsence d'un dmon, ni ne vrifie s'il y en a un qui tourne. Elle se base entirement sur la capacit de ssh gnrer un processus svnserve temporaire, qui ensuite se termine une fois la connexion SSH close. Quand vous utilisez des URL svn+ssh:// pour accder un dpt, souvenez-vous que c'est le programme ssh qui envoie l'invite d'authentification, pas le client svn. Ce qui signifie qu'il n'y a pas de mise en cache automatique de mots de passe (voir la section intitule Mise en cache des lments d'authentification du client ). Le fonctionnement du client Subversion fait qu'il accde souvent au dpt par des connexions multiples, bien que les utilisateurs ne s'en rendent habituellement pas compte grce la fonctionnalit de mise en cache du mot de passe. Lorsque vous utilisez des URL svn+ssh://, les utilisateurs risquent de trouver a pnible que ssh demande le mot de passe de faon rptitive pour toute connexion vers l'extrieur. La solution est d'utiliser un outil spar de mise en cache du mot de passe, tel que ssh-agent sur Unix ou pageant sur Windows. Quand le trafic passe par un tunnel, les accs sont contrls principalement par les droits sur les fichiers de la base de donnes lis au systme d'exploitation ; c'est quasiment pareil que si Harry accdait au dpt directement via une URL file://. Si plusieurs utilisateurs systmes accdent au dpt directement, il est de bon ton de les placer dans un mme groupe et vous devez faire attention aux umasks (prenez soin de lire la section intitule Accs au dpt par plusieurs mthodes plus loin dans ce chapitre). Mais mme dans le cas de l'encapsulation, vous pouvez toujours utiliser le fichier svnserve.conf pour bloquer l'accs, en spcifiant juste auth-access = read ou auth-access = none2. Vous vous attendez ce que cette histoire d'encapsulation SSH se termine ici, mais ce n'est pas le cas. Subversion vous permet de crer des comportements d'encapsulation personnaliss dans votre fichier de configuration (voir la section intitule Zone de configuration des excutables ). Par exemple, supposons que vous vouliez utiliser RSH au lieu de SSH3. Dans le paragraphe [tunnels] de votre fichier config, dfinissez-le comme ceci : [tunnels] rsh = rsh prsent vous pouvez utiliser cette nouvelle dfinition d'encapsulation par le biais d'un schma d'URL qui correspond au nom de votre nouvelle variable : svn+rsh://hote/chemin. Lorsqu'il utilise le nouveau type d'URL, le client Subversion lance en fait en arrire-plan la commande rsh hote svnserve -t. Si vous incluez un nom d'utilisateur dans l'URL (par exemple svn+rsh://nomdutilisateur@hote/chemin), le client va l'inclure dans sa commande (rsh nomdutilisateur@hote svnserve -t). Mais vous pouvez dfinir des schmas d'encapsulation bien plus volus : [tunnels] joessh = $JOESSH /opt/alternate/ssh -p 29934 Cet exemple illustre plusieurs choses. D'abord, il indique comment faire pour que le client Subversion lance un excutable d'encapsulation particulier (celui situ l'emplacement /opt/alternate/ssh) avec des options particulires. Dans ce cas, se connecter une URL svn+joessh:// lance un excutable SSH particulier avec les arguments -p 29934 (utile si vous voulez que le programme d'encapsulation se connecte un port non standard). Ensuite, il indique comment dfinir une variable d'environnement personnalise capable de remplacer le nom du programme d'encapsulation. Configurer la variable d'environnement SVN_SSH est un moyen simple de modifier le programme d'encapsulation par dfaut. Mais s'il vous faut diffrents programmes d'encapsulation pour diffrents serveurs, chacun se connectant par exemple un port diffrent ou passant des options diffrentes SSH, vous pouvez utiliser le mcanisme illustr dans cet exemple. Concrtement, si nous donnons une valeur la variable d'environnement JOESSH, cette valeur remplacera la totalit de la valeur de la variable d'encapsulation $JOESSH serait excut au lieu de /opt/alternate/ssh -p 29934.
2 Notez 3

qu'utiliser le moindre contrle d'accs avec svnserve ne sert strictement rien ; l'utilisateur ayant dj directement accs la base de donnes. Nous ne le recommandons pas, car RSH est significativement moins scuris que SSH.

158

Configuration du serveur

Astuces de configuration de SSH


Il est possible de contrler non seulement la manire dont le client lance ssh, mais aussi le comportement de sshd sur votre machine. Dans ce paragraphe, nous indiquons comment contrler la commande svnserve prcise qui est excute par sshd, ainsi que comment faire pour que plusieurs utilisateurs partagent un mme compte systme.

Mise en uvre initiale


Pour commencer, localisez le rpertoire home du compte utilisateur que vous utilisez pour lancer svnserve. Assurez-vous que ce compte possde un bi-cl de cls publique/prive et que l'utilisateur peut se connecter en s'authentifiant par la mthode cl publique. L'authentification par mot de passe ne fonctionnera pas, puisque toutes les astuces SSH qui suivent consistent utiliser le fichier authorized_keys. S'il n'existe pas dj, crez le fichier authorized_keys (sur Unix, c'est gnralement ~/.ssh/authorized_keys). Chaque ligne de ce fichier dcrit une cl publique autorise se connecter. Ces ligne sont gnralement de la forme : ssh-dsa AAAABtce9euch utilisateur@exemple.com Le premier champ dcrit le type de cl, le second champ est la cl elle-mme, encode en base 64, et le troisime champ est un commentaire. Cependant, c'est un fait moins connu que la ligne toute entire peut tre prcde par un champ command : command="programme" ssh-dsa AAAABtce9euch utilisateur@exemple.com Quand le champ command est prsent, le serveur SSH va lancer le programme indiqu en lieu et place de l'habituel svnserve en mode tunnel que le client Subversion a demand. En dcoulent un certain nombre d'astuces ct serveur. Dans les exemples suivants, nous abrgeons les lignes du fichier par : command="programme" TYPE CL COMMENTAIRE

Contrle de la commande excuter


Comme nous pouvons spcifier la commande excute ct serveur, il devient facile de dsigner un excutable svnserve spcifique et d'y passer des arguments supplmentaires : command="/chemin/vers/svnserve -t -r /racine/virtuelle" TYPE CL COMMENTAIRE Dans cet exemple, /chemin/vers/svnserve peut tre un script personnalis construit autour de svnserve qui spcifie le umask utiliser (voir la section intitule Accs au dpt par plusieurs mthodes ). Il indique aussi comment ancrer svnserve dans un rpertoire racine virtuel, ce qui est aussi trs souvent utilis quand svnserve fonctionne en tant que dmon. Le but est soit de restreindre l'accs certaines parties du systme, soit simplement d'viter que l'utilisateur ait taper un chemin absolu dans l'URL svn+ssh://. Il est galement possible d'avoir plusieurs utilisateurs partageant un compte utilisateur unique. Au lieu de crer un compte systme distinct pour chaque utilisateur, gnrez plutt un bi-cl de cls publique/prive pour chaque personne. Placez ensuite chaque cl publique dans le fichier authorized_users, une par ligne, et utilisez l'option --tunnel-user : command="svnserve -t --tunnel-user=harry" TYPE1 CL1 harry@exemple.com command="svnserve -t --tunnel-user=sally" TYPE2 CL2 sally@exemple.com Cet exemple permet la fois Harry et Sally de se connecter au mme compte utilisateur avec l'authentification via leur cl publique. Chacun d'eux doit excuter une commande qui lui est propre ; l'option --tunnel-user signale svnserve que l'argument fourni doit tre considr comme le nom de l'utilisateur authentifi. Sans --tunnel-user, toutes les propagations sembleraient venir du mme compte utilisateur partag.

159

Configuration du serveur

Finalement, un dernier avertissement : autoriser l'accs d'un utilisateur au serveur via une cl publique dans un compte partag n'empche pas forcment d'autres formes d'accs SSH, mme si vous avez spcifi une valeur pour le champ command dans le fichier authorized_keys. Par exemple, l'utilisateur aura toujours accs au shell via SSH, il sera capable d'effectuer de la redirection X11 ou de la redirection d'un port quelconque de votre serveur. Pour accorder le moins de droits possibles l'utilisateur, vous pouvez spcifier des options de restriction immdiatement aprs la commande du champ command : command="svnserve -t --tunnel-user=harry",no-port-forwarding,no-agent-for warding,no-X11-forwarding,no-pty TYPE1 CL1 harry@exemple.com Notez bien que tout ceci doit tenir sur une seule ligne, vraiment sur une seule ligne, car les fichiers SSH authorized_keys n'autorisent mme pas le caractre habituel de continuation de ligne (\). L'unique raison pour laquelle nous avons rajout une coupure est pour que cela tienne dans le format physique d'un livre.

httpd, le serveur HTTP Apache


Le serveur HTTP Apache est un serveur rseau tout faire que Subversion sait exploiter. Via un module adapt, httpd rend les dpts Subversion accessibles aux clients par le protocole WebDAV/DeltaV, qui est une extension de HTTP 1.1 (voir http://www.webdav.org/ pour plus d'informations). Ce protocole se base sur HTTP, le protocole omniprsent la base du World Wide Web, lui ajoute des fonctionnalits d'criture et, en particulier, d'criture avec gestion de versions. Le rsultat est un systme robuste et standardis qui est inclus dans le logiciel Apache 2.0, support par de nombreux systmes d'exploitation et outils tiers, et qui ne demande pas aux administrateurs rseaux d'ouvrir un port rseau supplmentaire4. Bien qu'un serveur Apache-Subversion ait plus de fonctionnalits que svnserve, il est aussi plus difficile mettre en place. La flexibilit a bien souvent pour contrepartie la complexit. Une grande partie de ce qui va suivre fait rfrence des directives de configuration d'Apache. Bien que l'utilisation de ces directives soit illustre par quelques exemples, les dcrire compltement va bien au-del du sujet de ce chapitre. L'quipe Apache tient jour une documentation excellente, disponible publiquement sur leur site web l'adresse http://httpd.apache.org. Par exemple, le guide de rfrence complet des directives de configuration est situ l'adresse http://httpd.apache.org/docs-2.0/mod/directives.html. En outre, au fur et mesure des changements que vous apporterez votre configuration d'Apache, il est probable que vous commettrez des erreurs. Si vous n'tes pas dj familier avec le sous-systme de journalisation d'Apache, vous devrez apprendre le connatre. Dans votre fichier httpd.conf, des directives spcifient l'emplacement sur le disque des journaux d'accs et d'erreurs gnrs par Apache (les directives CustomLog et ErrorLog respectivement). Le module mod_dav_svn de Subversion utilise galement l'interface de journalisation des erreurs d'Apache. Pensez naviguer dans ces fichiers lorsque vous recherchez des informations susceptibles de vous aider trouver l'origine d'un problme. propos d'Apache 2 Si vous tes un administrateur systme, il est trs probable que vous utilisiez dj le serveur web Apache et que vous en ayez une exprience pralable. l'heure o ces lignes sont crites, Apache 1.3 est la version la plus populaire d'Apache. Le passage de la communaut Apache 2 est assez lent, pour diverses raisons : certains ont peur du changement, en particulier quand il s'agit de toucher quelque chose d'aussi essentiel qu'un serveur web. D'autres dpendent de greffons qui ne fonctionnent qu'avec l'interface (l'API) de Apache 1.3 et attendent qu'ils soient ports vers Apache 2. Quelle qu'en soit la raison, beaucoup de gens commencent s'inquiter quand ils dcouvrent que le module Apache de Subversion a t crit spcifiquement pour l'API d'Apache 2. Mais ne vous inquitez pas ! Il est facile de faire fonctionner Apache 1.3 et Apache 2 cte cte ; il suffit de les installer dans des endroits spars et d'utiliser Apache 2 en tant que serveur ddi fonctionnant sur un port autre que le port 80. Les clients peuvent ds lors accder au dpt en indiquant le numro de port dans l'URL : $ svn checkout http://hote.exemple.com:7382/depot/projet

Prrequis
4

C'est une chose qu'ils dtestent faire.

160

Configuration du serveur

Pour mettre disposition votre dpt sur le rseau par HTTP, il vous faut quatre composants, disponibles dans deux paquets. Il vous faut Apache httpd 2.0, le module DAV mod_dav fourni avec, Subversion et le module mod_dav_svn implmentant le systme de fichiers, qui est fourni avec Subversion. Une fois que vous avez tous ces composants, la procdure de mise en rseau de votre dpt est aussi simple que : faire fonctionner httpd 2.0 avec le module mod_dav ; installer le module mod_dav_svn derrire mod_dav (mod_dav_svn utilise les bibliothques Subversion pour accder au dpt) ; configurer le fichier httpd.conf pour exporter (ou exposer ) le dpt. Vous pouvez accomplir les deux premires tches ci-dessus soit en compilant httpd et Subversion partir du code source, soit en installant les paquets binaires prcompils correspondants sur votre systme. Les informations les plus rcentes sur la faon de compiler Subversion dans le cadre d'une utilisation en conjonction avec le serveur HTTP Apache, sur la compilation et sur la configuration d'Apache lui-mme dans cet objectif, sont consultables dans le fichier INSTALL situ la racine de l'arborescence du code source de Subversion.

Configuration Apache de base


Une fois que les composants requis sont installs sur votre systme, il ne reste plus qu' configurer Apache au moyen de son fichier httpd.conf. Indiquez Apache de charger le module mod_dav_svn grce la directive LoadModule. Cette directive doit prcder tout autre lment de configuration li Subversion. Si votre serveur Apache a t install avec la configuration par dfaut, votre module mod_dav_svn devrait avoir t install dans le sous-rpertoire modules du rpertoire d'installation d'Apache (souvent /usr/local/apache2). La directive LoadModule a une syntaxe trs simple, faisant correspondre un nom de module l'emplacement sur le disque d'une bibliothque partage : LoadModule dav_svn_module modules/mod_dav_svn.so

Notez que si mod_dav a aussi t compil sous forme de bibliothque partage (et non par une dition de liens statiques qui le place alors directement dans l'excutable httpd), il vous faudra une directive LoadModule pour celui-ci. Assurez-vous qu'elle est place avant la ligne mod_dav_svn : LoadModule dav_module LoadModule dav_svn_module modules/mod_dav.so modules/mod_dav_svn.so

Plus loin dans votre fichier de configuration, vous devez indiquer Apache l'endroit o rside votre dpt (ou vos dpts) Subversion. La directive Location possde une syntaxe de type XML, qui commence par une balise de dbut, se termine par une balise de fin et contient diverses autres directives de configuration au milieu. Le sens de la directive Location est de faire faire Apache quelque chose de spcial quand il traite les requtes adresses une URL donne ou une de ses filles. Dans le cas de Subversion, il faut qu'Apache fasse traiter par la couche DAV les URL pointant vers les ressources suivies en versions. Vous pouvez indiquer Apache de dlguer le traitement de toutes les URL dont la partie chemin d'accs (la partie de l'URL qui suit le nom du serveur et le numro de port optionnel) commence par /depot/ un gestionnaire de DAV dont le dpt est situ l'adresse /var/svn/mon-depot en utilisant la syntaxe httpd.conf suivante : <Location /depot> DAV svn SVNPath /var/svn/mon-depot </Location> Si vous avez l'intention de grer plusieurs dpts Subversion rsidant dans le mme rpertoire parent sur votre disque local, vous pouvez utiliser une directive alternative, SVNParentPath, pour faire tat de ce rpertoire parent commun. Par exemple, si vous savez que vous allez crer plusieurs dpts Subversion dans le rpertoire /var/svn, auxquels on accdera par des URL telles que http://mon.serveur.com/svn/depot1, http://mon.serveur.com/svn/depot2, etc., vous pouvez utiliser la syntaxe de configuration de httpd.conf de l'exemple suivant : 161

Configuration du serveur

<Location /svn> DAV svn # toute URL "/svn/truc" correspond un dpt /var/svn/truc SVNParentPath /var/svn </Location> Par cette syntaxe, Apache va dlguer le traitement de toutes les URL dont le chemin d'accs commence par /svn/ au gestionnaire DAV de Subversion, qui ensuite supposera que tous les lments du rpertoire spcifi dans la directive SVNParentPath sont en fait des dpts Subversion. C'est une syntaxe particulirement pratique dans le sens o, la diffrence de celles utilisant la directive SVNPath, vous n'avez pas besoin de redmarrer Apache pour crer et mettre disposition sur le rseau de nouveaux dpts. Vrifiez bien que, quand vous dfinissez votre nouvelle directive Location, elle n'interfre pas avec d'autres emplacements exports. Par exemple, si votre DocumentRoot (c'est--dire le rpertoire racine des fichiers qu'Apache expose sur le web) principal est export vers /www, n'exportez pas de dpt Subversion vers <Location /www/depot>. Si une requte arrivait pour l'URI /www/depot/machin.c, Apache ne saurait pas s'il doit chercher un fichier depot/machin.c dans son DocumentRoot ou s'il doit dlguer mod_dav_svn la tche de renvoyer machin.c qui se trouve dans le dpt Subversion. Ceci aboutit souvent une erreur du serveur de la forme 301 Moved Permanently. Noms de serveur et requtes COPY Subversion se sert du type de requte COPY pour effectuer des copies de fichiers et de rpertoires ct serveur. Les modules Apache vrifient que la source de la copie est bien situe sur la mme machine que la destination. Pour satisfaire cette exigence, vous aurez peut-tre besoin de dclarer mod_dav le nom d'hte de votre serveur. En gnral, la directive ServerName du fichier httpd.conf peut tre utilise cette fin. ServerName svn.exemple.com Si vous faites usage du support des htes virtuels d'Apache via la directive NameVirtualHost, la directive ServerAlias vous permettra de spcifier des noms additionnels dsignant votre serveur. Encore une fois, reportezvous la documentation Apache pour plus de dtails.

prsent, il nous faut examiner srieusement la question des droits d'accs. Si vous utilisez Apache depuis un certain temps en tant que serveur web principal, vous hbergez certainement pas mal de contenu : des pages web, des scripts, etc. Ces lments ont dj t configurs avec un ensemble de droits qui leur permet de fonctionner avec Apache, ou plus exactement qui permet Apache de travailler avec ces fichiers. Apache, quand on l'utilise en tant que serveur Subversion, a aussi besoin de droits d'accs corrects pour lire et crire dans votre dpt. Vous devez mettre en place les droits d'accs qui satisfont les besoins de Subversion sans mettre mal l'installation des pages web et scripts pr-existants. Ceci implique peut-tre de modifier les droits d'accs de votre dpt Subversion pour qu'ils correspondent ceux utiliss par les autres lments qu'Apache gre, ou bien utiliser les directives User et Group du fichier httpd.conf pour spcifier qu'Apache doit fonctionner avec l'identifiant et le groupe qui est propritaire de votre dpt Subversion. Il n'y a pas une faon unique de mettre en place les droits d'accs et chaque administrateur a ses propres raisons pour faire les choses d'une manire ou d'une autre. Soyez juste conscient que les problmes lis aux droits d'accs sont peuttre le point le plus nglig lors de la configuration d'un dpt avec Apache.

Options d'authentification
ce stade, si vous avez configur httpd.conf avec quelque chose du style : <Location /svn> DAV svn SVNParentPath /var/svn </Location>

162

Configuration du serveur

votre dpt est prsent accessible anonymement au reste du monde. Jusqu' ce que configuriez des politiques d'authentification et de contrle d'accs, les dpts Subversion que vous rendez disponibles via la directive Location sont gnralement accessibles tous. En d'autres termes : N'importe qui peut utiliser un client Subversion pour extraire une copie de travail d'une URL du dpt (ou de n'importe lequel de ses sous-rpertoires). N'importe qui peut naviguer interactivement dans la dernire rvision du dpt rien qu'en allant avec un navigateur web l'URL du dpt. N'importe qui peut effectuer des propagations vers le dpt. Bien sr, vous avez peut-tre dj mis en place une procdure automatique pre-commit pour empcher les propagations (voir la section intitule Mise en place des procdures automatiques ). Mais en progressant dans la lecture de ce chapitre, vous verrez qu'il est galement possible d'utiliser les mthodes intgres dans Apache pour restreindre les accs de faon spcifique.

Mise en place de l'authentification HTTP


La manire la plus facile d'authentifier un client est le mcanisme d'authentification Basic de HTTP, qui utilise juste un nom d'utilisateur et un mot de passe pour vrifier que l'utilisateur est bien celui qu'il prtend tre. Apache fournit un utilitaire htpasswd pour grer la liste des noms d'utilisateurs et mots de passe accepts. Accordons le droit de propager Sally et Harry. D'abord, il faut les ajouter au fichier des mots de passe : $ ### Premire fois : utilisez -c pour crer le fichier $ ### Ajoutez -m pour MD5 afin de chiffrer le mot de passe et ainsi le rendre plus sr $ htpasswd -cm /etc/fichier-auth-svn harry New password: ***** Re-type new password: ***** Adding password for user harry $ htpasswd -m /etc/fichier-auth-svn sally New password: ******* Re-type new password: ******* Adding password for user sally $ Ensuite, vous devez ajouter des directives dans le bloc Location du fichier httpd.conf pour indiquer Apache comment se servir du nouveau fichier des mots de passe. La directive AuthType spcifie le type d'authentification que l'on veut utiliser. Dans notre cas, nous voulons utiliser le mode Basic . La directive AuthName permet de donner un nom arbitraire au domaine d'authentification. La plupart des navigateurs affichent ce nom dans la bote de dialogue (pop-up) qui demande le nom d'utilisateur et le mot de passe. Enfin, utilisez la directive AuthUserFile pour spcifier le chemin du fichier des mots de passe que vous venez de crer avec la commande htpasswd. Aprs avoir ajout ces trois directives, votre bloc <Location> devrait ressembler ceci : <Location /svn> DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Depot Subversion" AuthUserFile /etc/fichier-auth-svn </Location> Ce bloc <Location> n'est pas encore complet et il ne sert pas grand chose pour l'instant. Il indique juste Apache que, lorsqu'un contrle d'accs est requis, Apache doit demander un nom d'utilisateur et un mot de passe au client Subversion. Ce qui manque ici, cependant, ce sont les directives qui indiquent Apache quelles sortes de requtes client requirent un contrle d'accs. Ds que le contrle d'accs est demand, Apache exige galement l'authentification. La chose la plus simple faire est de protger toutes les requtes. Ajouter Require valid-user signale Apache que, pour toutes les requtes, l'utilisateur 163

Configuration du serveur

doit tre authentifi : <Location /svn> DAV svn SVNParentPath /var/svn AuthType Basic AuthName "Depot Subversion" AuthUserFile /etc/fichier-auth-svn Require valid-user Prenez bien soin de lire la section intitule Options de contrle d'accs qui suit pour plus de dtails sur la directive Require et sur les autres manires de mettre en uvre des politiques de contrle d'accs. Un petit avertissement : les mots de passe de la mthode HTTP Basic Auth circulent pratiquement en clair sur le rseau et ne sont donc pas du tout scuriss. Une autre possibilit est de ne pas utiliser la mthode d'authentification Basic mais d'utiliser la mthode d'authentification Digest la place. L'authentification Digest permet au server de vrifier l'identit du client sans envoyer le mot de passe en clair sur le rseau. En supposant que le client et le serveur connaissent tous les deux le mot de passe de l'utilisateur, ils peuvent vrifier que le mot de passe est le mme en l'utilisant pour appliquer une fonction de hachage une donne cre pour l'occasion. Le serveur envoie au client une chane plus ou moins alatoire de petite taille ; le client se sert du mot de passe de l'utilisateur pour crer un condensat (hash en anglais) de cette chane ; le serveur examine ensuite si le condensat correspond ses attentes. Configurer Apache pour la mthode d'authentification Digest est galement assez facile et ne comporte qu'une petite variation par rapport notre exemple prcdent. Prenez soin de consulter la documentation complte d'Apache pour plus de dtails. <Location /svn> DAV svn SVNParentPath /var/svn AuthType Digest AuthName "Depot Subversion" AuthDigestDomain /svn/ AuthUserFile /etc/fichier-auth-svn Require valid-user </Location> Si vous recherchez la scurit maximale, la cryptographie cl publique est la meilleure solution. Il est sans doute mieux d'utiliser du chiffrement SSL afin que les clients s'authentifient via https:// au lieu de http:// ; le minimum minimorum consiste alors configurer Apache pour qu'il utilise un certificat serveur auto-sign5. Consultez la documentation Apache (et la documentation OpenSSL) pour savoir comment faire.

Gestion des certificats SSL


Les entreprises qui ont besoin de rendre leur dpts disponibles au-del du pare-feu primtrique de leur socit doivent tre conscientes que des entits non-autorises auront la possibilit d' couter leur trafic rseau. SSL permet de diminuer le risque que cette coute conduise des fuites de donnes sensibles. Si un client Subversion est compil pour utiliser OpenSSL, il obtient la possibilit de communiquer avec le serveur Apache via des URL https://. La bibliothque Neon utilise par le client Subversion est non seulement capable de vrifier les certificats du serveur, mais aussi de renvoyer des certificats clients quand on le lui demande. Une fois que le client et le serveur ont chang des certificats SSL et se sont authentifis mutuellement avec succs, tous les changes qui s'ensuivent sont chiffrs par une cl de session. Expliquer comment gnrer des certificats clients et serveurs ou comment configurer Apache pour les utiliser s'loigne trop du sujet de ce livre. De nombreux autres livres, dont la documentation Apache elle-mme, expliquent comment le faire. Mais nous pouvons quand mme traiter ici la question de la gestion des certificats clients et serveurs partir d'un client Subversion ordinaire.
5

Bien que les certificats serveurs auto-signs soient vulnrables aux attaques du type man-in-the-middle ( attaque de l'homme du milieu en franais), une telle attaque est bien plus difficile excuter pour un observateur occasionnel que de juste espionner les mots de passe qui passent en clair sur le rseau.

164

Configuration du serveur

Quand il communique avec Apache via https://, un client Subversion peut recevoir deux types d'informations diffrentes : un certificat serveur ; une demande de certificat client. Si le client reoit un certificat serveur, il doit vrifier que ce certificat est digne de confiance : le serveur est-il bien celui qu'il prtend tre ? La bibliothque OpenSSL effectue cette vrification en examinant le signataire du certificat serveur, aussi nomm autorit de certification (AC, ou CA en anglais). Si OpenSSL n'est pas capable de faire confiance automatiquement l'autorit de certification, ou si un autre problme apparat (tel que l'expiration du certificat ou des noms d'htes divergents), le client en ligne de commande de Subversion vous demande si vous voulez faire confiance au certificat serveur malgr tout : $ svn list https://hote.exemple.com/depot/projet Erreur de validation du certificat du serveur pour 'https://hote.exemple.com:443' : - Le certificat n'est pas sign pas une autorit de confiance. Valider le certificat manuellement ! Informations du certificat : - nom d'hte : hote.exemple.com - valide de Jan 30 19:23:56 2004 GMT Jan 30 19:23:56 2006 GMT - signataire : CA, exemple.com, Sometown, California, US - empreinte : 7d:e1:a9:34:33:39:ba:6a:e9:a5:c4:22:98:7b:76:5c:92:a0:9c:7b (R)ejet, acceptation (t)emporaire ou (p)ermanente ? Cette question devrait vous tre familire ; c'est probablement la mme que vous avez dj d voir pose par votre navigateur web (qui n'est rien d'autre qu'un client HTTP comme Subversion). Si vous choisissez l'option (p)ermanente, le certificat du serveur sera mis en cache dans votre zone prive auth/ de la mme faon que le nom d'utilisateur et le mot de passe y sont conservs (voir la section intitule Mise en cache des lments d'authentification du client ). S'il est en cache, Subversion fera automatiquement confiance ce certificat dans les changes futurs. Votre fichier servers dans la zone de configuration vous permet galement d'indiquer au client Subversion qu'il doit automatiquement faire confiance certaines autorits de certification spcifiques, soit globalement, soit en tenant compte de la machine hte. Il suffit d'attribuer la variable ssl-authority-files une liste de certificats d'autorits de certification au format PEM, spars par des points-virgules : [global] ssl-authority-files = /chemin/vers/certAC-1.pem;/chemin/vers/certAC-2.pem De nombreuses installations d'OpenSSL possdent par dfaut une liste prdfinie d'autorits de certification auxquelles il est fait confiance de manire quasi-universelle. Pour que le client Subversion fasse confiance ces autorits de certification automatiquement, mettez la variable ssl-trust-default-ca true. Quand il communique avec Apache, un client Subversion peut galement recevoir une demande (un dfi) de certificat client. Apache demande au client de s'authentifier : le client est-il bien celui qu'il prtend tre ? Si tout se passe bien, le client Subversion renvoie un certificat (public) sign par une autorit de certification en laquelle Apache a confiance ainsi qu'une preuve que le client possde bien la cl prive associe au certificat (la rponse au dfi). La cl prive, ainsi que le certificat public, sont habituellement enregistrs dans un conteneur (un fichier .p12 , fichier au format PKCS#12) sur le disque, la cl prive tant chiffre l'aide d'un mot de passe. Quand Subversion reoit ce dfi, il vous demande le chemin d'accs au conteneur ainsi que le mot de passe qui protge la cl prive : $ svn list https://hote.exemple.com/depot/projet Domaine d'authentification : https://hote.exemple.com:443 Fichier du certificat client : /chemin/vers/mon/cert.p12 Phrase de passe pour '/chemin/vers/mon/cert.p12' : ********

165

Configuration du serveur

Pour utiliser un certificat client avec Subversion, il doit tre dans un conteneur au format PKCS#12, qui est un standard portable. La plupart des navigateurs web sont dj capables d'importer et d'exporter des certificats dans ce format. Une autre option est d'utiliser les outils en ligne de commande d'OpenSSL pour convertir les certificats existants en PKCS#12. Encore une fois, le fichier servers de la zone de configuration vous permet d'automatiser la rponse ces demandes en tenant compte de la machine hte. L'une ou l'autre des informations, ou bien les deux, peuvent tre dcrites dans les variables de configuration : [groups] exemple-d-hote = hote.exemple.com [exemple-d-hote] ssl-client-cert-file = /chemin/vers/mon/cert.p12 ssl-client-cert-password = un-mot-de-passe Une fois que vous avez dfini les variables ssl-client-cert-file et ssl-client-cert-password, le client Subversion peut rpondre automatiquement une demande de certificat client sans la moindre interaction de votre part6.

Options de contrle d'accs


ce stade, vous avez configur l'authentification mais pas le contrle d'accs. Apache est capable d'envoyer des dfis aux clients afin de confirmer leur identit mais on ne lui a pas encore dit comment autoriser ou restreindre les accs en fonction de l'utilisateur. Ce paragraphe dcrit deux stratgies pour contrler les accs au dpt.

Contrle d'accs gnrique


La forme la plus simple de contrle d'accs est d'autoriser des utilisateurs donns accder un dpt en lecture seule ou en lecture/criture. Vous pouvez restreindre l'accs toutes les oprations du dpt en ajoutant la directive Require valid-user votre bloc <Location>. Pour poursuivre dans la veine de notre exemple prcdent, cela signifie que seuls les clients disant tre harry ou sally et qui ont fourni le bon mot de passe pour leur nom d'utilisateur respectif ont l'autorisation d'effectuer des actions sur le dpt Subversion : <Location /svn> DAV svn SVNParentPath /var/svn # comment authentifier un utilisateur AuthType Basic AuthName "Depot Subversion" AuthUserFile /chemin/vers/fichier/utilisateurs # seuls les utilisateurs authentifis ont le droit d'accs au dpt Require valid-user </Location> Parfois vous n'aurez pas besoin d'tre aussi strict. Par exemple, le propre dpt du code source de Subversion, situ l'adresse http://svn.apache.org/repos/asf/subversion/ autorise toute personne effectuer des oprations de lecture du dpt (comme extraire des copies de travail ou naviguer dans le dpt avec un navigateur web) mais restreint toutes les oprations d'criture aux utilisateurs authentifis. Pour accomplir ce type de restriction slective, vous pouvez utiliser les directives de configuration Limit et LimitExcept. Tout comme la directive Location, ces blocs doivent dbuter et finir par des balises et vous devez les imbriquer dans votre bloc <Location>. Les paramtres prsents dans les directives Limit et LimitExcept sont des types de requtes HTTP qui sont concerns par ce bloc. Par exemple, si voulez dsactiver tout accs au dpt except pour les oprations de lecture dj supportes, utilisez la directive LimitExcept, en lui passant les paramtres de type de requtes GET, PROPFIND, OPTIONS et REPORT. Ensuite
6

Les administrateurs qui attachent le plus d'importance la scurit peuvent ne pas vouloir stocker le mot de passe du certificat client dans le fichier servers de la zone de configuration.

166

Configuration du serveur

placez la directive Require valid-user mentionne prcdemment l'intrieur du bloc <LimitExcept> au lieu de la mettre juste l'intrieur du bloc <Location>. <Location /svn> DAV svn SVNParentPath /var/svn # comment authentifier un utilisateur AuthType Basic AuthName "Depot Subversion" AuthUserFile /chemin/vers/fichier/utilisateurs # Pour toute autre opration que celles-ci, exiger un utilisateur authentifi. <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> </Location> Ce ne sont l que quelques exemples simples. Pour des informations plus pousses sur le contrle d'accs d'Apache et la directive Require, jetez un il la section Security du recueil des didacticiels de la documentation Apache l'adresse http://httpd.apache.org/docs-2.0/misc/tutorials.html (site en anglais).

Contrle d'accs par rpertoire


On peut galement mettre en place des droits d'accs avec une granularit plus fine en utilisant un second module Apache httpd, mod_authz_svn. Ce module se saisit des diverses URL opaques qui transitent entre le client et le serveur, demande mod_dav_svn de les dcoder et ensuite met ventuellement son veto certaines requtes en se basant sur les politiques d'accs dfinies dans un fichier de configuration. Si vous avez compil Subversion partir du code source, mod_authz_svn est automatiquement inclus et install aux cts de mod_dav_svn. De nombreux excutables distribus l'installent automatiquement aussi. Pour vrifier qu'il est install correctement, assurez-vous qu'il vient juste aprs la directive LoadModule de mod_dav_svn dans le fichier httpd.conf : LoadModule dav_module LoadModule dav_svn_module LoadModule authz_svn_module modules/mod_dav.so modules/mod_dav_svn.so modules/mod_authz_svn.so

Pour activer ce module, vous devez configurer votre bloc Location pour qu'il utilise la directive AuthzSVNAccessFile ; elle spcifie quel fichier contient les politiques de contrle d'accs aux chemins de vos dpts (nous allons tudier le format de ce fichier). Apache est flexible, vous avez donc la possibilit de configurer votre bloc selon une mthode choisir parmi trois. Pour commencer, choisissez une des mthodes de configuration de base (les exemples suivants sont trs simples ; reportez-vous la documentation Apache qui contient beaucoup plus de dtails sur les options d'authentification et de contrle d'accs d'Apache). Le bloc le plus simple consiste donner l'accs tout le monde. Dans ce scnario, Apache n'envoie jamais de dfi d'authentification, tous les utilisateurs sont donc traits en tant qu' anonymes (voir l'Exemple 6.1, Exemple-type de configuration : accs anonyme ).

Exemple 6.1. Exemple-type de configuration : accs anonyme


<Location /depot> DAV svn SVNParentPath /var/svn # notre politique de contrle d'accs AuthzSVNAccessFile /chemin/vers/fichier/acces </Location>

167

Configuration du serveur

l'oppos sur l'chelle de la paranoa, vous pouvez configurer votre bloc de telle sorte qu'il exige que tout le monde s'authentifie. Ici, tous les clients doivent fournir un mot de passe pour prouver leur identit. Votre bloc exige l'authentification inconditionnelle via la directive Require valid-user et dfinit le moyen de s'authentifier (voir l'Exemple 6.2, Exemple-type de configuration : accs authentifi ).

Exemple 6.2. Exemple-type de configuration : accs authentifi


<Location /depot> DAV svn SVNParentPath /var/svn # notre politique de contrle d'accs AuthzSVNAccessFile /chemin/vers/fichier/acces # seuls les utilisateurs authentifis ont accs au dpt Require valid-user # comment authentifier un utilisateur AuthType Basic AuthName "Depot Subversion" AuthUserFile /chemin/vers/fichier/utilisateurs </Location>

Une troisime mthode largement pratique consiste autoriser la fois des accs anonymes et des accs authentifis. Par exemple, de nombreux administrateurs dsirent autoriser les utilisateurs anonymes lire certains rpertoires dans les dpts mais ne veulent voir que des utilisateurs authentifis accder en lecture (ou en criture) dans des zones plus sensibles. Dans cette configuration, tous les utilisateurs commencent par accder au dpt de faon anonyme. Si votre politique de contrle d'accs exige un vritable nom d'utilisateur un moment ou un autre, Apache demandera au client de s'authentifier. Pour ce faire, vous devez utiliser la fois la directive Satisfy Any et la directive Require valid-user (voir l'Exemple 6.3, Exemple-type de configuration : accs mixte authentifi/anonyme ).

Exemple 6.3. Exemple-type de configuration : accs mixte authentifi/anonyme


<Location /depot> DAV svn SVNParentPath /var/svn # notre politique de contrle d'accs AuthzSVNAccessFile /chemin/vers/fichier/acces # essayer d'abord un accs anonyme, # ne demander une vritable authentification # que si ncessaire Satisfy Any Require valid-user # comment authentifier un utilisateur AuthType Basic AuthName "Depot Subversion" AuthUserFile /chemin/vers/fichier/utilisateurs </Location>

Une fois l'un de ces modles mis en place dans votre fichier httpd.conf, vous devez crer un fichier contenant les rgles d'accs particulires pour chaque chemin de votre dpt. Nous en parlons plus en dtails plus loin dans ce chapitre, la section intitule Contrle d'accs bas sur les chemins . 168

Configuration du serveur

Dsactivation du contrle sur les chemins


Le module mod_dav_svn se donne beaucoup de peine pour assurer que les donnes que vous avez dsignes comme interdites ne soient pas divulgues accidentellement. Cela veut dire qu'il doit surveiller troitement tous les chemins d'accs et tous les contenus des fichiers renvoys par des commandes telles que svn checkout et svn update. Si ces commandes tombent sur un chemin qui n'est pas lisible cause d'une politique de contrle d'accs, le chemin est gnralement totalement omis. Dans le cas d'une recherche d'historique ou de renommage, par exemple une commande telle que svn cat -r ANCIENNE_REVISION truc.c sur un fichier qui a t renomm il y a longtemps, le suivi des renommages va simplement s'arrter si un des anciens noms de l'objet se rvle tre en accs restreint en lecture. Ces contrles sur les chemins peuvent parfois tre assez coteux, tout particulirement dans le cas de svn log. Quand il demande une liste de rvisions, le serveur examine chaque chemin modifi dans chaque rvision et vrifie qu'il a le droit d'tre lu. Si un chemin interdit est dcouvert, il est omis de la liste des chemins modifis par la rvision (obtenue habituellement par l'option --verbose) et le message de propagation est entirement supprim. Il va sans dire que ceci peut prendre un certain temps pour les rvisions qui ont touch un grand nombre de fichiers. C'est le cot de la scurit : mme si vous n'avez pas du tout configur de module tel que mod_authz_svn, le module mod_dav_svn va quand mme demander httpd Apache de vrifier les droits d'accs pour chaque chemin. Le module mod_dav_svn n'est pas au courant de la liste des modules qui ont t installs, donc tout ce qu'il peut faire est de demander Apache de lancer n'importe quel contrle qui soit prsent. D'un autre ct, il existe une sorte d'chappatoire qui vous permet de faire un compromis entre les fonctions de scurit et la vitesse. Si vous ne mettez pas en uvre de contrle d'accs sur les chemins (c'est--dire, si vous n'utilisez ni mod_authz_svn ni un module similaire), vous pouvez dsactiver tous ces contrles sur les chemins. Dans votre fichier httpd.conf, utilisez la directive SVNPathAuthz comme illustr dans l'Exemple 6.4, Dsactiver compltement les contrles sur les chemins .

Exemple 6.4. Dsactiver compltement les contrles sur les chemins


<Location /depot> DAV svn SVNParentPath /var/svn SVNPathAuthz off </Location>

La directive SVNPathAuthz est active ( on ) par dfaut. Quand on la dsactive ( off ), tous les contrles d'accs bass sur les chemins sont dsactivs ; mod_dav_svn arrte de contrler chaque chemin qu'il traite.

Fonctionnalits bonus
Nous avons trait la plupart des options d'authentification et de contrle d'accs pour Apache et mod_dav_svn. Mais Apache fournit quelques autres fonctionnalits sympathiques.

Navigation dans les dpts


Un des avantages les plus frappants d'avoir une configuration Apache/WebDAV pour votre dpt Subversion est que les rvisions les plus rcentes de vos fichiers et rpertoires suivis en versions sont immdiatement consultables l'aide d'un navigateur web classique. Puisque Subversion utilise des URL pour identifier les ressources suivies en versions, ces URL utilises pour accder aux dpts via HTTP peuvent tre tapes directement dans un navigateur web. Votre navigateur enverra une requte HTTP GET pour cette URL ; selon que cette URL reprsente ou non un fichier ou un rpertoire suivi en versions, mod_dav_svn renverra soit la liste des lments du rpertoire, soit le contenu du fichier. Comme les URL ne contiennent pas d'informations concernant la version de la ressource qui vous intresse, mod_dav_svn renverra toujours la version la plus rcente. Cette fonctionnalit a un merveilleux effet secondaire : vous pouvez partager avec vos pairs des URL Subversion en guise de rfrences des documents et ces URL pointeront toujours vers la dernire version des documents. Bien sr, vous pouvez aussi utiliser ces URL en tant que liens hypertextes dans d'autres sites web.

169

Configuration du serveur

Puis-je consulter d'anciennes rvisions ? Avec un navigateur web classique ? En un mot : non. Ou, du moins, pas avec mod_dav_svn pour seul outil. Votre navigateur web ne sait communiquer qu'en langage HTTP ordinaire. Ce qui signifie qu'il sait seulement obtenir, par requte GET, des URL publiques, qui reprsentent les versions les plus rcentes des fichiers et rpertoires. D'aprs la spcification de WebDAV/DeltaV, chaque serveur dfinit une syntaxe prive d'URL pour les anciennes versions des ressources et cette syntaxe est incomprhensible pour les clients. Pour obtenir une ancienne version d'un fichier, un client doit suivre une procdure spcifique pour dcouvrir l'URL approprie ; cette procdure ncessite d'envoyer une srie de requtes WebDAV PROPFIND et de comprendre les concepts DeltaV. C'est quelque chose que votre navigateur web n'est pas capable de faire. Donc, pour rpondre la question, une mthode vidente permettant de consulter d'anciennes versions de fichiers et de rpertoires est de passer l'argument --revision (-r) aux commandes svn list et svn cat. Pour naviguer dans les anciennes rvisions avec votre navigateur web, vous pouvez utiliser des logiciels tiers. Un bon exemple en est ViewVC (http://viewvc.tigris.org/). ViewVC a t crit l'origine dans le but d'afficher des dpts CVS sur le web7 et les dernires versions sont galement capables de travailler avec les dpts Subversion.

Types MIME appropris


Quand il consulte un dpt Subversion, le navigateur web obtient un indice pour savoir comment rendre le contenu d'un fichier en examinant l'entte Content-Type: qui fait partie de la rponse envoye par Apache la requte HTTP GET. La valeur de cet entte est en quelque sorte un type MIME. Par dfaut, Apache va indiquer aux navigateurs web que tous les fichiers du dpt sont du type MIME par dfaut, en gnral text/plain. Cela peut s'avrer assez frustrant, si un utilisateur dsire visualiser les fichiers du dpt de manire plus approprie par exemple, un fichier truc.html du dpt sera bien plus lisible s'il est rendu dans le navigateur en tant que fichier HTML. Pour rendre ceci possible, il suffit de vous assurer que vos fichiers portent bien la proprit svn:mime-type. Plus de dtails sur ce sujet sont disponibles dans la section intitule Type de contenu des fichiers et vous pouvez mme configurer votre dpt pour qu'il associe automatiquement la valeur de svn:mime-type approprie aux fichiers qui arrivent dans le dpt pour la premire fois ; reportez-vous la section intitule Configuration automatique des proprits . Donc, dans notre exemple, si quelqu'un attribuait la valeur text/html la proprit svn:mime-type du fichier truc.html, Apache indiquerait avec justesse votre navigateur web de rendre le fichier comme une page HTML. On pourrait aussi associer des proprits ayant des valeurs image/* appropries aux fichiers d'images et, en fin de compte, faire qu'un site web entier soit consultable directement travers un dpt ! Ceci ne pose en gnral pas de problme, du moment que le site web ne possde pas de contenu gnr dynamiquement.

Personnalisation de l'aspect
En gnral, vous utiliserez principalement des URL de fichiers suivis en versions ; aprs tout c'est l que le contenu intressant rside. Mais vous aurez peut-tre l'occasion de naviguer dans le contenu d'un rpertoire Subversion et vous remarquerez rapidement que le code HTML gnr pour afficher la liste des lments du rpertoire est trs rudimentaire, et certainement pas conu pour tre agrable d'un point de vue esthtique (ni mme intressant). Afin d'activer la personnalisation de l'affichage de ces rpertoires, Subversion fournit une fonctionnalit d'index XML. La prsence d'une directive SVNIndexXSLT dans le bloc Location du fichier httpd.conf de votre dpt conduira mod_dav_svn gnrer un rsultat en XML quand il affiche la liste des lments d'un rpertoire et faire rfrence la feuille de style XSLT de votre choix : <Location /svn> DAV svn SVNParentPath /var/svn SVNIndexXSLT "/index-svn.xsl" </Location> A l'aide de la directive SVNIndexXSLT et d'une feuille de style XSLT faisant preuve de crativit, vous pouvez adapter les
7

A l'poque, il s'appelait ViewCVS.

170

Configuration du serveur

listes de contenus de rpertoires aux schmas de couleur et d'imagerie utiliss dans d'autres parties de votre site web. Ou, si vous prfrez, vous pouvez utiliser les exemples de feuilles de style fournis dans le rpertoire tools/xslt/ du code source de Subversion. Gardez l'esprit que le chemin d'accs fourni au rpertoire SVNIndexXSLT est en fait une URL les navigateurs de chemins doivent tre capables de lire vos feuilles de style pour les utiliser !

Affichage de la liste des dpts


Si vous desservez un ensemble de dpts partir d'une URL unique via la directive SVNParentPath, il est possible de faire afficher par Apache tous les dpts disponibles dans un navigateur web. Il suffit d'activer la directive SVNListParentPath : <Location /svn> DAV svn SVNParentPath /var/svn SVNListParentPath on </Location> Si un utilisateur pointe son navigateur web l'URL http://hote.exemple.com/svn/, il verra une liste de tous les dpts Subversion situs dans /var/svn. videmment, ceci peut poser des problmes de scurit ; cette fonctionnalit est donc dsactive par dfaut.

Journalisation Apache
Comme Apache est avant tout un serveur HTTP, il contient des fonctionnalits de journalisation d'une flexibilit fantastique. Dtailler toutes les faons dont la journalisation peut tre configure sort du cadre de ce livre, mais nous voulons quand mme vous faire remarquer que mme le fichier httpd.conf le plus gnrique conduit Apache crer deux fichiers de journalisation : error_log et access_log. Ces journaux peuvent apparatre diffrents endroits, mais sont en gnral crs dans la zone de journalisation de votre installation Apache (sur Unix, ils rsident souvent dans / usr/local/apache2/logs/). Le fichier error_log dcrit toutes les erreurs internes qu'Apache rencontre au cours de son fonctionnement. Le fichier access_log enregistre toutes les requtes HTTP reues par Apache. Ceci permet de voir facilement, par exemple, de quelles adresses IP les clients Subversion se connectent, quelle frquence un client donn utilise le serveur, quels utilisateurs se sont authentifis correctement et quelles requtes ont chou ou russi. Malheureusement, parce qu'HTTP est un protocole sans notion d'tat, mme la plus simple opration du client Subversion gnre plusieurs requtes rseau. Il est donc trs difficile d'examiner le fichier access_log et d'en dduire ce que le client faisait la plupart des oprations se prsentent sous la forme de sries de requtes PROPPATCH, GET, PUT et REPORT nigmatiques. Pour couronner le tout, de nombreuses oprations du client envoient des sries de requtes quasi-identiques, il est donc encore plus difficile de les distinguer. Cependant, mod_dav_svn peut venir votre rescousse. En activant la fonctionnalit de journalisation oprationnelle , vous pouvez demander mod_dav_svn de crer un fichier spar dcrivant quelles sortes d'oprations de haut niveau vos clients effectuent. Pour ce faire, vous devez utiliser la directive CustomLog d'Apache (qui est explique en dtail dans la documentation Apache). Prenez soin de placer cette directive en dehors de votre bloc Location de Subversion : <Location /svn> DAV svn </Location> CustomLog logs/journal-svn "%t %u %{SVN-ACTION}e" env=SVN-ACTION Dans cet exemple, nous demandons Apache de crer un fichier journal spcial, journal-svn, dans le rpertoire habituel de journaux d'Apache (logs). Les variables %t et %u sont remplaces par l'horodatage et le nom d'utilisateur de la requte, respectivement. Les points importants sont les deux instances de SVN-ACTION. Quand Apache trouve cette variable, il lui substitue la valeur de la variable d'environnement SVN-ACTION, modifie automatiquement par mod_dav_svn quand il dtecte une action haut-niveau du client. 171

Configuration du serveur

Ainsi, au lieu d'avoir interprter un fichier access_log traditionnel qui ressemble : [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/vcc/default HTTP/1.1" 207 398 [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc/!svn/bln/59 HTTP/1.1" 207 449 [26/Jan/2007:22:25:29 -0600] "PROPFIND /svn/calc HTTP/1.1" 207 647 [26/Jan/2007:22:25:29 -0600] "REPORT /svn/calc/!svn/vcc/default HTTP/1.1" 200 607 [26/Jan/2007:22:25:31 -0600] "OPTIONS /svn/calc HTTP/1.1" 200 188 [26/Jan/2007:22:25:31 -0600] "MKACTIVITY /svn/calc/!svn/act/e6035ef7-5df0-4ac0-b811-4be7c823f998 HTTP/1.1" 201 227 vous pouvez vous contenter de parcourir le fichier journal-svn qui est bien plus intelligible : [26/Jan/2007:22:24:20 [26/Jan/2007:22:24:27 [26/Jan/2007:22:25:29 [26/Jan/2007:22:25:31 -0600] -0600] -0600] -0600] - get-dir /tags r1729 props - update /trunk r1729 depth=infinity send-copyfrom-args - status /trunk/machin r1729 depth=infinity sally commit r1730

Pour une liste exhaustive de toutes les actions journalises, reportez-vous la section intitule Journalisation de haut niveau .

Mandataire en criture
Un des avantages notables d'Apache comme serveur Subversion est qu'il peut tre configur pour effectuer de la rplication. Par exemple, imaginez que votre quipe soit rpartie sur quatre sites dans diffrents coins du globe. Le dpt Subversion ne peut exister que sur un de ces sites, ce qui signifie que les trois autres sites n'auront pas un accs trs satisfaisant ils devront sans doute faire avec un trafic plus lent et des temps de rponse plus longs lors des mises jour et des propagations. Une solution trs puissante est de mettre en place un systme constitu d'un serveur Apache matre et de plusieurs serveurs Apache esclaves. Si vous placez un serveur esclave sur chacun des sites, les utilisateurs peuvent extraire une copie de travail de l'esclave qui est le plus proche d'eux. Toutes les requtes de lecture vont au serveur esclave local. Les requtes d'criture sont automatiquement routes vers l'unique serveur matre. Lorsque la propagation se termine, le matre pousse la nouvelle rvision vers chaque serveur esclave en utilisant l'outil de rplication svnsync. Cette configuration permet une immense amlioration de la vitesse perue par les utilisateurs, car le trafic d'un client Subversion est gnralement constitu 80 - 90 % de requtes de lecture. Et ces requtes tant traites par un serveur local, le gain est norme. Dans ce paragraphe, nous vous accompagnons dans la mise en place standard de ce systme comportant un matre unique et plusieurs esclaves. Cependant, gardez l'esprit que vos serveurs doivent faire tourner au moins Apache 2.2.0 (avec le module mod_proxy charg) et Subversion 1.5 (mod_dav_svn).

Configuration des serveurs


Pour commencer, configurez le fichier httpd.conf de votre serveur matre de la faon habituelle. Mettez le dpt disposition un certain emplacement URI et configurez l'authentification ainsi que le contrle d'accs comme vous le souhaitez. Une fois que c'est fait, configurez chacun de vos serveurs esclaves exactement de la mme manire, mais ajoutez la directive SVNMasterURI au bloc : <Location /svn> DAV svn SVNPath /var/svn/depot SVNMasterURI http://maitre.exemple.com/svn </Location> Cette nouvelle directive indique un serveur esclave de rediriger toutes les requtes d'criture vers le matre (ce qui est accompli automatiquement par le module mod_proxy d'Apache). Les requtes ordinaires de lecture, cependant, sont toujours traites par les esclaves. Assurez-vous que vos serveurs matre et esclaves ont tous des configurations identiques d'authentification et de contrle d'accs ; s'ils ne peuvent plus se synchroniser, cela peut engendrer beaucoup d'ennuis. 172

Configuration du serveur

Ensuite nous devons nous occuper du problme de la rcursion infinie. Avec la configuration actuelle, imaginez ce qui se va se passer quand un client Subversion va effectuer une propagation vers le serveur matre. Une fois la propagation termine, le serveur utilise svnsync pour rpliquer la nouvelle rvision vers chaque esclave. Mais comme svnsync ne se prsente que comme un simple client en train d'effectuer une propagation, l'esclave va immdiatement tenter d'envoyer vers le matre la requte d'criture qui vient d'arriver ! Et l, patatras ! La solution consiste s'arranger pour que le matre pousse les rvisions vers un emplacement <Location> distinct au sein des dpts esclaves. Cet emplacement est configur non pas pour servir de mandataire pour les requtes d'criture mais pour accepter les propagations normales en provenance de l'adresse IP du matre (et seulement de lui) : <Location /svn-proxy-sync> DAV svn SVNPath /var/svn/depot Order deny,allow Deny from all # Ne laisse que le serveur ayant l'adresse indique accder cet emplacement : Allow from 10.20.30.40 </Location>

Mise en place de la rplication


Une fois que vous avez configur les blocs Location du matre et des esclaves, vous devez configurer le matre pour que la rplication vers les esclaves fonctionne. Ceci se fait de la manire habituelle, en utilisant svnsync. Si vous n'tes pas familier avec cet outil, reportez-vous la section intitule Rplication d'un dpt pour plus de dtails. Tout d'abord, assurez-vous que chaque dpt esclave a une procdure automatique pre-revprop-change qui autorise les modifications de proprits de rvisions distance (cette tape fait partie de la procdure standard pour un serveur qui reoit les rvisions de svnsync). Ensuite, connectez-vous au serveur matre et configurez l'URI de chaque dpt esclave pour qu'il reoive les donnes en provenance du dpt matre sur le disque local : $ svnsync init http://esclave1.exemple.com/svn-proxy-sync file://var/svn/depot Proprits copies pour la rvision 0. $ svnsync init http://esclave2.exemple.com/svn-proxy-sync file://var/svn/depot Proprits copies pour la rvision 0. $ svnsync init http://esclave3.exemple.com/svn-proxy-sync file://var/svn/depot Proprits copies pour la rvision 0. # Effectue la rplication initiale $ svnsync sync http://esclave1.exemple.com/svn-proxy-sync Transmission des donnes ........................................ Rvision 1 propage. Proprits copies pour la rvision 1. Transmission des donnes .. Rvision 2 propage. Proprits copies pour la rvision 2. $ svnsync sync http://esclave2.exemple.com/svn-proxy-sync Transmission des donnes ........................................ Rvision 1 propage. Proprits copies pour la rvision 1. Transmission des donnes .. Rvision 2 propage. Proprits copies pour la rvision 2. $ svnsync sync http://esclave3.exemple.com/svn-proxy-sync Transmission des donnes ........................................ Rvision 1 propage. Proprits copies pour la rvision 1. Transmission des donnes .. Rvision 2 propage. 173

Configuration du serveur

Proprits copies pour la rvision 2. Une fois que c'est fait, nous configurons la procdure automatique post-propagation (post-commit) du serveur matre pour qu'elle lance svnsync sur chaque serveur esclave : #!/bin/sh # Procdure post-propagation pour rpliquer les rvisions nouvellement propages vers les esclaves svnsync sync http://esclave1.exemple.com/svn-proxy-sync > /dev/null 2>&1 svnsync sync http://esclave2.exemple.com/svn-proxy-sync > /dev/null 2>&1 svnsync sync http://esclave3.exemple.com/svn-proxy-sync > /dev/null 2>&1 Les symboles en plus la fin de chaque ligne ne sont pas ncessaires, mais constituent un moyen astucieux d'autoriser svnsync lancer des commandes qui fonctionneront l'arrire-plan, de telle sorte que le client Subversion ne se retrouvera pas attendre indfiniment que la propagation se termine. En plus de cette procdure post-propagation (post-commit), vous aurez galement besoin d'une procdure post-revprop-change pour que, disons, quand un utilisateur modifie un message de propagation, les serveurs esclaves reoivent aussi cette modification : #!/bin/sh # Procdure post-revprop-change pour rpliquer les modifications # des proprits de rvisions vers les esclaves REV=${2} svnsync copy-revprops http://esclave1.exemple.com/svn-proxy-sync ${REV} > /dev/null 2>&1 svnsync copy-revprops http://esclave2.exemple.com/svn-proxy-sync ${REV} > /dev/null 2>&1 svnsync copy-revprops http://esclave3.exemple.com/svn-proxy-sync ${REV} > /dev/null 2>&1 La seule chose que nous n'avons pas dtaill concerne les verrous. Comme les verrous sont grs strictement par le serveur matre (le seul endroit o des propagations ont lieu), nous n'avons en thorie pas besoin de faire quoi que ce soit. De nombreuses quipes n'utilisent pas du tout les fonctionnalits de verrouillage de Subversion, il s'agit donc peut-tre pour vous d'un faux problme. Cependant, si les modifications de verrous ne sont pas rpliques du matre vers les esclaves, cela signifie que les clients ne seront pas capables d'interroger l'tat des verrous (par exemple, svn status -u ne donne aucune information sur les verrous du dpt). Si cela vous embte, vous pouvez crire des procdures automatiques post-lock et post-unlock qui lancent svn lock et svn unlock sur les serveurs esclaves, vraisemblablement l'aide d'une mthode de connexion distance telle que SSH. Nous laissons ceci au lecteur en guise d'exercice !

Piges viter
Votre systme de rplication matre/esclave doit prsent tre prt l'emploi. Cependant, quelques consignes de prudence sont de mise. Souvenez-vous que la rplication n'est pas totalement robuste en ce qui concerne les plantages machine ou rseau. Par exemple, si l'une des commandes svnsync automatises demeure inacheve, pour quelque raison que ce soit, les esclaves vont commencer tre dcals. Par exemple, vos utilisateurs distants verront qu'ils ont propag la rvision 100, mais quand ils excuteront svn update, leur serveur local leur indiquera que la rvision 100 n'existe pas encore ! Bien sr, le problme se rglera automatiquement ds qu'une autre propagation aura lieu et que la commande svnsync qui s'ensuit aura fonctionn cette synchronisation rpliquera toutes les rvisions en attente. Nanmoins, vous pouvez dcider de mettre en place une surveillance des dcalages, vrifiant le bon fonctionnement de la synchronisation et qui, en cas de problme, dclenche une nouvelle excution de svnsync. Pouvons-nous mettre en place la rplication avec svnserve ? Si vous utilisez svnserve au lieu d'Apache comme serveur, vous pouvez tout fait configurer les procdures automatiques de votre dpt pour qu'elles lancent svnsync comme nous l'avons expliqu ici, lanant ainsi la rplication automatique du matre vers les esclaves. Malheureusement, l'heure o nous crivons ces lignes, il n'y a pas moyen de s'assurer que des serveurs esclaves svnserve envoient automatiquement les requtes d'criture vers le serveur matre. 174

Configuration du serveur

Cela veut dire que vos utilisateurs ne pourraient pas extraire des copies de travail en lecture seule des serveurs esclaves. Il vous faudrait configurer vos serveurs esclaves pour qu'ils refusent compltement tout accs en criture. Cela peut tre utile pour crer des miroirs en lecture seule de projets open source populaires, mais il ne s'agit alors plus d'un systme de mandataire d'criture transparent.

Autres fonctionnalits d'Apache


Il y a galement plusieurs fonctionnalits fournies par Apache, en tant que serveur web robuste, dont on peut tirer profit pour amliorer les fonctionnalits ou la scurit de Subversion. Le client Subversion est capable d'utiliser SSL (Secure Socket Layer, le protocole de scurisation des changes sur internet, prsent auparavant). Si votre client Subversion a t compil en incluant le support de SSL, il peut accder votre serveur Apache en utilisant des URL https:// et bnficier d'une session rseau avec un chiffrement de grande qualit. D'autres fonctionnalits de la relation Apache/Subversion sont galement tout aussi utiles, comme par exemple la possibilit de spcifier un port personnalis (au lieu du port HTTP par dfaut, 80) ou un nom de domaine virtuel par lequel accder au dpt Subversion ou la possibilit d'accder au dpt via un serveur mandataire HTTP. Enfin, comme mod_dav_svn se sert d'un sous-ensemble du protocole WebDAV/DeltaV pour communiquer, il est possible d'accder au dpt depuis des clients DAV tiers. La possibilit de monter un serveur DAV en tant que dossier partag rseau standard est intgre dans la plupart des systmes d'exploitation modernes (Win32, OS X et Linux). C'est un sujet compliqu, mais merveilleux une fois mis en place. Pour plus de dtails, consultez l'Annexe C, WebDAV et la gestion de versions automatique. Notez qu'il y a un certain nombre d'autres petits bricolages que l'on peut faire autour de mod_dav_svn qui sont trop obscurs pour tre mentionns dans ce chapitre. Pour voir la liste complte de toutes les directives httpd.conf auxquelles mod_dav_svn obit, reportez-vous la section intitule Directives .

Contrle d'accs bas sur les chemins


Apache et svnserve sont tous deux capables d'accorder ou de refuser l'accs aux utilisateurs. Gnralement c'est gr globalement au niveau du dpt : un utilisateur peut accder (ou pas) au dpt en lecture et il peut accder (ou pas) au dpt en criture. Il est pourtant aussi possible de dfinir des rgles d'accs possdant une granularit plus fine. Un ensemble d'utilisateurs peut alors obtenir le droit d'crire dans certains rpertoires du dpt mais pas dans d'autres ; paralllement, un autre rpertoire peut trs bien ne pas tre accessible en lecture pour la majorit des utilisateurs. Les deux types de serveurs utilisent un format de fichier commun pour dcrire les rgles d'accs bases sur les chemins. Dans le cas d'Apache, il faut charger le module mod_authz_svn puis ajouter la directive AuthzSVNAccessFile (dans le fichier httpd.conf) pointant vers votre propre fichier de rgles (pour l'explication complte, voir la section intitule Contrle d'accs par rpertoire ). Si vous utilisez svnserve, vous devez faire pointer la variable authz-db (dans le fichier svnserve.conf) vers votre fichier de rgles. Avez-vous vraiment besoin d'un contrle d'accs bas sur les chemins ? De nombreux administrateurs qui mettent en place Subversion pour la premire fois ont tendance se lancer dans le contrle d'accs bas sur les chemins sans trop y rflchir. L'administrateur sait en gnral quelles quipes travaillent sur quel projet, il est ds lors facile de dmarrer en accordant l'accs pour certains rpertoires certaines quipes et pas d'autres. Ceci peut sembler assez naturel, et assouvir le dsir de l'administrateur de contrler le dpt de trs prs. Notez cependant qu'il y a souvent des cots invisibles (et visibles !) associs cette fonctionnalit. Dans la catgorie visible, le serveur doit faire beaucoup de travail pour s'assurer que l'utilisateur a le droit de lire ou d'crire sur chaque chemin spcifi ; dans certaines situations, il y a une chute trs significative des performances. Dans la catgorie invisible, rflchissez la culture que vous crez. La plupart du temps, mme si certains utilisateurs ne devraient pas propager de modifications dans certaines parties du dpt, ce contrat social n'a pas besoin de solution technologique pour tre respect. Les quipes peuvent parfois collaborer spontanment entre elles ; quelqu'un peut vouloir aider quelqu'un d'autre en effectuant une propagation dans une zone qui n'est pas celle o il travaille habituellement. En interdisant ce genre de choses au niveau du serveur, vous mettez en place une barrire la collaboration. Vous crez aussi tout un tas de rgles qui doivent tre gres au fur et mesure que les projets se dveloppent, que de nouveaux utilisateurs sont ajouts, etc. C'est une quantit de travail supplmentaire fournir.

175

Configuration du serveur

Souvenez-vous que c'est un systme de gestion de versions ! Mme si quelqu'un propageait accidentellement une modification l o il n'aurait pas du, revenir en arrire reste trs facile. Et si un utilisateur propage au mauvais endroit de faon intentionnelle, c'est un problme social qui doit tre rgl, de toute manire, en dehors de Subversion. Bref, avant que vous ne commenciez restreindre les droits d'accs des utilisateurs, demandez-vous si cela correspond un vritable besoin ou si c'est juste quelque chose qui plat l'administrateur. Demandez-vous si a vaut la peine de sacrifier de la vitesse ct serveur et souvenez-vous que les risques associs sont trs minimes ; ce n'est pas une bonne ide d'attendre de la technologie qu'elle rsolve les problmes sociaux8. En guise d'exemple mditer, prenez le cas du projet Subversion lui-mme, au sein duquel il a toujours t clairement dfini quel utilisateur avait le droit d'effectuer des propagations quel endroit, rgles qui ont toujours t appliques socialement. C'est un bon modle de confiance dans la communaut, en particulier pour les projets open source. Bien sr, il peut parfois y avoir de vritables besoins lgitimant un contrle d'accs bas sur les chemins ; dans les grandes entreprises, par exemple, certaines donnes sont sensibles et l'accs ces donnes doit vraiment tre restreint un petit groupe de personnes.

Une fois que votre serveur sait o trouver votre fichier de rgles, il est temps de dfinir ces rgles. La syntaxe du fichier est la mme syntaxe que celle utilise dans svnserve.conf et dans les fichiers de configuration. Les lignes commenant par un dise (#) sont ignores. Dans la forme la plus simple, chaque section dsigne un dpt et un chemin l'intrieur de celui-ci et les noms d'utilisateurs authentifis sont les noms des options l'intrieur de chaque section. La valeur de chaque option dcrit le niveau d'accs de l'utilisateur au chemin du dpt : soit r (lecture seule), soit rw (lecture/criture). Si l'utilisateur ne figure pas dans la section, l'accs n'est pas autoris. Plus prcisment, la valeur des noms de section est soit de la forme [nom-du-depot:chemin], soit de la forme [chemin]. Si vous utilisez la directive SVNParentPath, il est important de spcifier les noms des dpts dans vos sections. Si vous les omettez, une section telle que [/un/repertoire] correspondra au chemin /un/repertoire de tous les dpts. Cependant, si vous utilisez la directive SVNPath, ne dfinir que des chemins dans vos sections est acceptable aprs tout, il n'y a qu'un seul dpt. [calc:/branches/calc/bogue-142] harry = rw sally = r Dans ce premier exemple, l'utilisateur harry a les droits d'accs complets en lecture/criture au rpertoire / branches/calc/bogue-142 du dpt calc, alors que l'utilisateur sally n'a que l'accs en lecture. Tous les autres utilisateurs sont bloqus et ne peuvent pas accder ce rpertoire. Bien videmment, les droits d'accs sont hrits d'un rpertoire parent ses fils. Ce qui signifie que nous pouvons spcifier un sous-rpertoire avec une politique d'accs diffrente pour Sally : [calc:/branches/calc/bogue-142] harry = rw sally = r # donne sally les droits d'criture sur le sous-rpertoire "test" [calc:/branches/calc/bogue-142/test] sally = rw Maintenant Sally peut crire dans le sous-rpertoire test de la branche, mais ne peut toujours que lire les autres parties. Harry, en attendant, continue avoir les droits d'accs complets en lecture criture sur toute la branche. Il est aussi possible d'interdire explicitement l'accs quelqu'un grce aux rgles d'hritage, en attribuant la valeur vide un nom d'utilisateur : [calc:/branches/calc/bogue-142]
8

Un thme rcurrent dans ce livre !

176

Configuration du serveur

harry = rw sally = r [calc:/branches/calc/bogue-142/secret] harry = Dans cet exemple, Harry a les droits de lecture/criture sur l'arborescence bogue-142 toute entire, mais n'a absolument pas accs au rpertoire secret contenu dans celle-ci. Ce qu'il faut retenir est que le chemin le plus spcifique est choisi en premier. Le serveur tente de trouver une correspondance avec le chemin lui-mme, puis avec son chemin parent, puis avec le parent du parent, etc. Le rsultat est que tout chemin spcifi dans le fichier des accs prendra le pas sur les droits hrits de ses rpertoires parents. Par dfaut, personne n'a accs au dpt. Cela signifie que si vous dmarrez avec un fichier vide, vous voudrez probablement au moins donner les droits de lecture sur la racine du dpt tous les utilisateurs. Vous pouvez accomplir ceci en utilisant la variable astrisque (*), qui dsigne tous les utilisateurs : [/] * = r C'est une configuration trs rpandue ; notez qu'aucun nom de dpt n'est mentionn dans le nom de la section. Ceci rend tous les dpts accessibles en lecture tous les utilisateurs. Une fois que tous les utilisateurs ont l'accs en lecture aux dpts, vous pouvez accorder des droits d'criture (rw) explicites certains utilisateurs sur des sous-rpertoires spcifiques l'intrieur de dpts spcifiques. La variable astrisque (*) a aussi ceci de spcial qu'elle est le seul symbole qui puisse correspondre un utilisateur anonyme. Si vous avez configur votre serveur pour qu'il autorise un mlange d'accs anonymes et authentifis, tous les utilisateurs peuvent commencer y accder anonymement. Le serveur cherche une valeur * dfinie pour le chemin d'accs demand ; s'il n'en trouve pas, il demande au client de s'authentifier. Le fichier des accs vous permet aussi de dfinir des groupes entiers d'utilisateurs, la faon du fichier Unix /etc/group : [groups] developpeurs-calc = harry, sally, joe developpeurs-paint = frank, sally, jane tout-le-monde = harry, sally, joe, frank, sally, jane Les droits d'accs peuvent tre accords aux groupes de la mme faon qu' de simples utilisateurs. Il faut juste les mettre en vidence par le prfixe at (@) : [calc:/projets/calc] @developpeurs-calc = rw [paint:/projets/paint] jane = r @developpeurs-paint = rw Un autre fait notable est que la premire rgle vrifie est celle qui sera applique l'utilisateur. Dans l'exemple prcdent, mme si jane est membre du groupe dveloppeurs-paint (qui a les droits de lecture/criture), la rgle jane = r sera lue et vrifie avant la rgle du groupe, refusant ainsi Jane l'accs en criture. Les groupes peuvent aussi contenir d'autres groupes : [groups] developpeurs-calc = harry, sally, joe 177

Configuration du serveur

developpeurs-paint = frank, sally, jane tout-le-monde = @developpeurs-calc, @developpeurs-paint Subversion 1.5 introduit une autre fonctionnalit utile pour la syntaxe du fichier des accs : les alias. Certains systmes d'authentification attendent et utilisent des noms d'utilisateurs relativement courts tels que ceux que nous avons dcrits ici harry, sally, joe, etc. Mais d'autres systmes d'authentification, comme par exemple ceux qui utilisent des bases LDAP ou des certificats clients SSL, peuvent utiliser des noms d'utilisateurs beaucoup plus complexes. Par exemple, le nom d'utilisateur d'Harry dans un systme protg par LDAP pourrait trs bien tre : CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com. Avec des noms d'utilisateurs de ce type, le fichier des accs devient rapidement illisible, avec des noms d'utilisateurs longs ou obscurs qui peuvent facilement tre mal orthographis. Heureusement, les alias vous permettent de n'avoir taper le nom d'utilisateur complexe entier qu'une seule fois, au sein d'un paragraphe qui lui attribue un alias bien plus digeste. [aliases] harry = CN=Harold Hacker,OU=Engineers,DC=red-bean,DC=com sally = CN=Sally Swatterbug,OU=Engineers,DC=red-bean,DC=com joe = CN=Gerald I. Joseph,OU=Engineers,DC=red-bean,DC=com Une fois dfini votre ensemble d'alias, vous pouvez faire rfrence ces utilisateurs en d'autres endroits du fichier par leurs alias, partout l o vous auriez sinon entr leur vritables noms d'utilisateurs. Il faut juste ajouter une esperluette (&) juste avant l'alias pour le distinguer des noms d'utilisateurs classiques : [groups] developpeurs-calc = &harry, &sally, &joe developpeurs-paint = &frank, &sally, &jane tout-le-monde = @developpeurs-calc, @developpeurs-paint

Vous pouvez aussi choisir d'utiliser des alias si les noms de vos utilisateurs changent souvent. Ainsi vous n'aurez que la table des alias mettre jour quand des modifications de noms d'utilisateurs auront lieu, au lieu d'avoir effectuer des oprations de recherches-et-remplacements-globaux sur la totalit du fichier. Accs partiel en lecture et extractions Si vous utilisez Apache en tant que serveur Subversion et que vous avez rendu certains sous-rpertoires de votre dpt inaccessibles en lecture certains utilisateurs, vous devez tre au courant d'un comportement potentiellement nonoptimal de la commande svn checkout. Quand le client lance une requte de mise jour ou d'extraction via HTTP, il envoie une requte unique au serveur et reoit du serveur une rponse unique (dont la taille peut tre assez importante). Quand le serveur reoit la requte, c'est la seule opportunit dont dispose Apache pour demander l'utilisateur de s'authentifier. Ceci a des effets secondaires assez tonnants. Par exemple, si un certain sous-rpertoire du dpt n'est accessible en lecture qu' l'utilisateur Sally et qu'Harry extrait un rpertoire parent, son client rpondra la demande d'authentification initiale en tant que Harry. Au fur et mesure que le serveur gnre la rponse, il n'a aucun moyen de renvoyer un dfi d'authentification quand il atteint le sous-rpertoire spcial ; ainsi le sous-rpertoire tout entier est omis, plutt que de demander l'utilisateur de se r-authentifier en tant que Sally le moment venu. De mme, si la racine du dpt est accessible en lecture anonymement, l'extraction se fera entirement sans authentification, omettant, encore une fois, le rpertoire non-lisible, plutt que d'envoyer une demande d'authentification au cours de l'opration.

Accs au dpt par plusieurs mthodes


Vous venez de voir diffrentes mthodes d'accs un dpt. Est-il possible et sans danger d'accder simultanment un dpt par diffrentes mthodes ? La rponse est oui, condition d'tre un petit peu prvoyant. un instant donn, les processus suivants peuvent avoir besoin de l'accs en lecture ou en criture au dpt : 178

Configuration du serveur

des utilisateurs classiques du systme se connectant l'aide d'un client Subversion des URL file:// ; des utilisateurs classiques du systme se connectant des processus svnserve privs gnrs par SSH (dont le propritaire est l'utilisateur lui-mme) et accdant au dpt ; un processus svnserve soit un serveur autonome, soit un processus lanc par inetd dont le propritaire est un utilisateur ddi ; un processus httpd Apache, dont le propritaire est un utilisateur ddi. Les problmes les plus courants rencontrs par les administrateurs sont des problmes de droits et de proprit pour le dpt. Chaque processus de la liste prcdente a-t-il les droits de lecture et d'criture sur les fichiers sous-jacents du dpt ? En supposant que vous ayez un systme d'exploitation de type Unix, une approche nave de ce problme serait de placer chaque utilisateur potentiel du dpt dans un groupe svn unique et de faire possder le dpt tout entier par ce groupe. Mais cela ne suffit mme pas, car un processus risque de modifier les fichiers de la base de donnes en utilisant un umask inadapt qui va interdire l'accs aux autres utilisateurs. L'tape suivante consiste donc, aprs avoir mis en place un groupe commun pour les utilisateurs du dpt, forcer tout processus qui accde au dpt utiliser un umask correct. Pour les utilisateurs qui accdent directement au dpt, vous pouvez envelopper le programme svnserve dans un script (wrapper en anglais) qui commence par lancer la commande umask 002 et qui, seulement ensuite, appelle le vritable programme client svn. Vous pouvez galement crire un script similaire pour le programme svnserve et ajouter la commande umask 002 au script de dmarrage d'Apache, apachectl. Par exemple : $ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/le-vrai-svn "$@"

Sur les systmes de type Unix, on rencontre souvent un autre problme classique. Si vous avez un dpt Berkeley DB, par exemple, il cre de temps en temps de nouveaux fichiers pour la journalisation. Mme si le dpt Berkeley DB est entirement possd par le groupe svn, ces nouveaux journaux ne seront pas ncessairement possds par le mme groupe, ce qui cre des problmes de droits supplmentaires pour vos utilisateurs. Une bonne faon de contourner ce problme est d'activer le bit SUID du groupe sur le rpertoire db du dpt, ce qui a pour rsultat que tous les nouveaux fichiers journaux crs ont le mme propritaire que le rpertoire parent. Une fois ces manipulations effectues, vos dpts devraient tre accessibles par tous les processus ncessaires. Tout ceci peut sembler un petit peu confus et compliqu, mais les problmes d'accs en criture par plusieurs utilisateurs des fichiers partags sont des problmes trs classiques, qui ne sont pas souvent rsolus avec lgance. Heureusement, la plupart des administrateurs n'auront jamais besoin d'une configuration aussi complexe. Les utilisateurs qui dsirent accder aux dpts rsidant sur une mme machine ne sont pas limits aux URL d'accs file:// ils peuvent gnralement contacter le serveur http Apache ou le serveur svnserve en utilisant localhost comme nom de serveur dans leurs URL http:// ou svn://. Et assurer la maintenance de plusieurs processus serveurs pour vos dpts Subversion vous crera plus de soucis qu'autre chose. Nous vous recommandons de choisir un seul serveur (celui qui correspond le mieux vos besoins) et de vous y tenir ! Serveur svn+ssh:// : les points vrifier Partager un dpt entre des utilisateurs qui ont des comptes SSH sans avoir de problme de droits d'accs peut tre assez pineux. Si l'ensemble des tches mener par l'administrateur d'un systme de type Unix est encore un peu confus pour vous, voici la liste des choses vrifier qui rcapitule les points abords dans cette section : Tous vos utilisateurs SSH doivent tre capables de lire et d'crire dans le dpt, donc mettez tous les utilisateurs SSH dans un mme groupe ;

179

Configuration du serveur

Faites de ce dpt l'entire proprit de ce groupe. Mettez les droits d'accs de ce groupe lecture/criture. Vos utilisateurs doivent utiliser un umask correct quand ils accdent au dpt, donc assurez-vous que svnserve (/ usr/bin/svnserve ou le chemin vers lequel $PATH pointe) est en fait un script qui excute umask 002 avant de lancer le vritable excutable svnserve. Prenez des mesures similaires quand vous utilisez svnlook et svnadmin : soit vous les lancez avec un umask correct, soit vous les enveloppez dans un script comme nous venons de l'expliquer.

180

Chapitre 7. Personnalisation de Subversion


La gestion de versions est un sujet complexe, au moins autant un art qu'une science, qui offre une myriade de faons d'accomplir chaque tche. En lisant ce livre, vous avez expriment les sous-commandes Subversion en ligne de commande et les options pour modifier leur comportement. Dans ce chapitre, nous passons en revue les moyens de personnaliser le fonctionnement de Subversion : la configuration des options d'excution, l'utilisation d'applications externes pour faciliter certains traitements, les interactions de Subversion avec la configuration des paramtres rgionaux du systme d'exploitation, etc.

Zone de configuration des excutables


Subversion permet l'utilisateur de contrler finement son comportement. Beaucoup d'options ont vocation s'appliquer l'ensemble des oprations de Subversion. Ainsi, plutt que de forcer les utilisateurs se souvenir d'arguments en ligne de commande pour spcifier ces options et de les utiliser chaque invocation, Subversion utilise des fichiers de configuration, tenus l'cart dans une zone de configuration spcifique Subversion. La zone de configuration Subversion consiste en une hirarchie deux niveaux constitue de noms d'options et de leurs valeurs. Habituellement, cela se traduit par un rpertoire ddi qui contient les fichiers de configuration (le premier niveau) : des fichiers texte au format standard INI (dont les sections constituent le deuxime niveau). Vous pouvez facilement diter ces fichiers l'aide de votre diteur de texte favori (tel qu'Emacs ou vi). Ils contiennent des directives lues par le client Subversion afin de dterminer le comportement par dfaut choisi par l'utilisateur.

Agencement de la zone de configuration


La premire fois que le client svn en ligne de commande est excut, il cre une zone de configuration propre l'utilisateur. Sur les systmes de type Unix, cette zone est un rpertoire nomm .subversion dans le rpertoire personnel de l'utilisateur. Sur les systmes Windows, Subversion cre un dossier nomm Subversion, gnralement dans la zone Application Data du rpertoire qui contient le profil de l'utilisateur (qui est habituellement, au passage, un rpertoire cach). Cependant, sur cette plate-forme, l'emplacement exact du profil utilisateur varie d'un systme l'autre et est dict par la base de registre Windows 1. Nous nous rfrerons cette zone de configuration propre l'utilisateur en utilisant son nom Unix : .subversion. En plus de la zone de configuration propre l'utilisateur, Subversion reconnat l'existence d'une zone de configuration globale pour le systme. Cela permet aux administrateurs du systme d'tablir une configuration par dfaut pour l'ensemble des utilisateurs d'une machine donne. Notez que la zone de configuration globale seule ne fixe pas de politique dfinitive : les rglages de l'utilisateur sont prioritaires par rapport aux rglages globaux et les options de la ligne de commande ont toujours le dernier mot. Sur les plate-formes de type Unix, la zone de configuration globale doit se trouver dans le rpertoire / etc/subversion ; sur les machines Windows, Subversion cherche un rpertoire Subversion dans le dossier commun Application Data (l encore, l'endroit exact dpend de la base de registre Windows). Au contraire de la zone propre l'utilisateur, le programme svn ne tente pas de crer la zone de configuration globale. La zone de configuration propre l'utilisateur contient actuellement trois fichiers : deux fichiers de configuration (config et servers) et un fichier README.txt qui dcrit le format INI. Lors de leur cration, ces fichiers contiennent les valeurs par dfaut de toutes les options supportes par Subversion, gnralement mises en commentaire et groupes avec une description textuelle de l'effet de la cl sur le fonctionnement de Subversion. Pour modifier un comportement prcis, il suffit de charger le fichier de configuration dans un diteur de texte et de changer la valeur de l'option correspondante. Si, par la suite, vous voulez rtablir les valeurs par dfaut, vous n'avez qu' supprimer ou renommer votre rpertoire de configuration puis lancer une commande svn inoffensive, telle que svn --version. Un nouveau rpertoire de configuration sera cr, qui contiendra les valeurs par dfaut. La zone de configuration propre l'utilisateur contient galement un cache pour les donnes d'authentification. Le rpertoire auth hberge un ensemble de sous-rpertoires qui contiennent des informations mises en cache, relatives aux diffrentes mthodes d'authentification utilises par Subversion. Ce rpertoire est cr de telle manire que seul l'utilisateur ait accs son contenu.
1

La variable d'environnement APPDATA pointe vers la zone Application Data, vous pouvez donc toujours faire rfrence ce dossier en utilisant %APPDATA%\Subversion.

181

Personnalisation de Subversion

Configuration via la base de registre Windows


En plus de la zone de configuration classique contenant les fichiers INI, les clients Subversion qui tournent sur une plate-forme Windows peuvent aussi utiliser la base de registre Windows pour stocker leurs donnes de configuration. Les noms des options et leurs valeurs sont les mmes que dans les fichiers INI. La hirarchie fichier/section est galement prsente, bien que traite de manire lgrement diffrente : dans ce cas, les fichiers et les sections sont juste des niveaux dans l'arborescence des cls de registres. Subversion cherche les valeurs de configuration applicables tout le systme sous la cl HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion. Par exemple, l'option global-ignores, qui se trouve dans la section miscellany du fichier de configuration, est situe dans HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Config\Miscellany\global-ignores. Les valeurs propres un utilisateur doivent tre stockes sous HKEY_CURRENT_USER\Software\Tigris.org\Subversion. Les options de configuration de la base de registre sont analyses avant les options des fichiers INI ; elles sont donc supplantes par les valeurs trouves dans les fichiers de configuration. En d'autres termes, Subversion cherche les options de configuration dans l'ordre suivant sur un systme Windows (les plus prioritaires sont cites en premier) : 1. les options en ligne de commande ; 2. les fichiers INI propres l'utilisateur ; 3. les valeurs de la base de registre propres l'utilisateur ; 4. les fichiers INI applicables l'ensemble du systme ; 5. les valeurs de la base de registre applicables l'ensemble du systme. Par ailleurs, la base de registre Windows ne supporte pas vraiment la notion de mise en commentaire . Cependant, Subversion ignorera toute cl dont le nom commence par le caractre dise (#). Cela vous permet de mettre en commentaire efficacement une option Subversion sans avoir effacer entirement la cl de la base de registre, ce qui simplifie manifestement la procdure de restauration de l'option. Le client en ligne de commande svn n'crit jamais dans la base de registre et ne tentera pas d'y crer une zone de configuration par dfaut. Vous pouvez crer les cls dont vous avez besoin en utilisant le programme REGEDIT. Une autre alternative consiste crer un fichier .reg (tel que celui donn dans l'Exemple 7.1, Exemple de fichier de modification de la base de registre (.reg) ) puis double-cliquer sur l'icne de ce fichier dans l'explorateur Windows afin d'appliquer les modifications votre base de registre.

Exemple 7.1. Exemple de fichier de modification de la base de registre (.reg)


REGEDIT4 [HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\groups] [HKEY_LOCAL_MACHINE\Software\Tigris.org\Subversion\Servers\global] "#http-proxy-host"="" "#http-proxy-port"="" "#http-proxy-username"="" "#http-proxy-password"="" "#http-proxy-exceptions"="" "#http-timeout"="0" "#http-compression"="yes" "#neon-debug-mask"="" "#ssl-authority-files"="" "#ssl-trust-default-ca"="" "#ssl-client-cert-file"="" "#ssl-client-cert-password"=""

182

Personnalisation de Subversion

[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auth] "#store-passwords"="yes" "#store-auth-creds"="yes" [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\helpers] "#editor-cmd"="notepad" "#diff-cmd"="" "#diff3-cmd"="" "#diff3-has-program-arg"="" [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\tunnels] [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany] "#global-ignores"="*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store" "#log-encoding"="" "#use-commit-times"="" "#no-unlock"="" "#enable-auto-props"="" [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props]

L'exemple prcdent prsente le contenu d'un fichier .reg qui contient quelques unes des options les plus communment utilises et leurs valeurs par dfaut. Notez la prsence de rglages propres l'utilisateur (notamment l'diteur de texte et le stockage des mots de passe) ainsi que de rglages applicables l'ensemble du systme (comme les options relatives au mandataire rseau). Notez galement que toutes les options sont mises en commentaire. Il ne vous reste qu' supprimer le caractre dise (#) initial des noms d'options et leur affecter la valeur que vous souhaitez.

Options de configuration
Dans cette section, nous allons nous intresser aux options de configuration des programmes supportes par la version actuelle de Subversion.

Fichier servers
Le fichier servers contient les options de configuration relatives aux couches rseau. Il y a deux sections spciales dans ce fichier : groups et global. La section groups n'est rien d'autre qu'un tableau de rfrences croises. Les cls de cette section sont les noms des autres sections du fichier ; ses valeurs sont des globs (des reprsentations textuelles qui peuvent contenir des caractres joker) qui sont compars aux noms des machines auxquelles des requtes Subversion sont envoyes. [groups] serveurs-red-beans = *.red-bean.com collabnet = svn.collab.net [serveurs-red-beans] [collabnet] Quand vous utilisez Subversion en rseau, il essaie de faire correspondre le nom du serveur auquel il tente de se connecter avec un nom de groupe de la section groups. Si une correspondance existe, Subversion vrifie alors s'il existe dans le fichier servers une section dont le nom est le nom du groupe correspondant. Le cas chant, il tire de cette section la configuration rseau appliquer. La section global contient la configuration appliquer tous les serveurs qui ne correspondent aucun glob de la section groups. Les options disponibles dans cette section sont exactement les mmes que pour les autres sections du fichier (excepte bien sr la section spciale groups) et sont : http-proxy-exceptions Cette option contient une liste de motifs (spars par des virgules) de noms de machines qui doivent tre contactes 183

Personnalisation de Subversion

directement, sans passer par le mandataire. La syntaxe des motifs est la mme que celle utilise par le shell Unix pour les noms de fichiers. L'accs aux dpts d'une machine dont le nom correspond l'un de ces motifs se fera sans passer par un mandataire. http-proxy-host Cette option contient le nom de la machine mandataire pour les requtes HTTP de Subversion. La valeur par dfaut est vide, ce qui signifie que Subversion ne tentera pas de faire passer ses requtes par un mandataire mais essaiera de contacter la machine de destination directement. http-proxy-port Cette option contient le numro du port utiliser sur la machine mandataire. Par dfaut, la valeur est vide. http-proxy-username Cette option contient le nom d'utilisateur fournir la machine mandataire. Par dfaut, la valeur est vide. http-proxy-password cette option contient le mot de passe fournir la machine mandataire. Par dfaut, la valeur est vide. http-timeout Cette option contient la dure maximum, en secondes, pendant laquelle Subversion attend la rponse du serveur. Si vous rencontrez des problmes d'oprations Subversion qui expirent cause d'une connexion rseau trop lente, vous devez augmenter cette valeur. Par dfaut, la valeur est 0, ce qui conduit la bibliothque HTTP sous-jacente (Neon) utiliser sa propre valeur par dfaut. http-compression Cette option indique si oui ou non Subversion doit essayer de compresser les requtes rseaux destination de serveurs DAV. La valeur par dfaut est yes. Notez que la compression ne sera effective que si la couche rseau a t compile avec le support de la compression. Mettez no pour ne pas activer la compression, par exemple lorsque vous analysez les transmissions rseaux. http-library Subversion est fourni avec deux modules d'accs aux dpts qui utilisent le protocole rseau WebDAV. Le module originel, fourni avec Subversion 1.0, est libsvn_ra_neon (bien qu'en ce temps-l, il s'appelait libsvn_ra_dav). Les nouvelles versions de Subversion fournissent galement libsvn_ra_serf, qui utilise une implmentation sousjacente diffrente et qui vise supporter certains des concepts HTTP les plus rcents. Actuellement, libsvn_ra_serf est toujours considre en version exprimentale, bien qu'elle semble fonctionner correctement dans les cas usuels. Afin d'inciter les gens l'essayer, Subversion fournit l'option de configuration httplibrary pour permettre aux utilisateurs de dfinir (globalement ou par groupe de serveurs) quel module d'accs WebDAV ils veulent utiliser : neon ou serf. http-auth-types Cette option liste les mthodes d'authentification (spares par des points-virgules) supportes par les module d'accs aux dpts WebDAV bass sur Neon. Les valeurs valides sont : basic, digest et negotiate. neon-debug-mask Cette option contient un entier qui reprsente un masque que la bibliothque HTTP sous-jacente (Neon) utilise pour choisir quel type d'affichage de dbogage autoriser. La valeur par dfaut est 0, ce qui interdit tout affichage de dbogage. Pour plus d'informations sur l'utilisation de Neon par Subversion, reportez-vous au Chapitre 8, Intgration de Subversion. ssl-authority-files Cette option contient une liste de chemins (spars par des points-virgules) vers les fichiers contenant les certificats des autorits de certifications (AC) qui doivent tre reconnues comme de confiance par le client Subversion lors des accs aux dpts en HTTPS. ssl-trust-default-ca Mettez cette variable yes si vous voulez que Subversion fasse automatiquement confiance l'ensemble des autorits de certification livres par dfaut avec OpenSSL. ssl-client-cert-file Si un hte (ou un ensemble d'htes) demande un certificat SSL au client, vous serez sollicit pour fournir le chemin de votre certificat. Ds que cette variable contient ce chemin, Subversion sera capable de trouver automatiquement votre certificat et ne vous sollicitera pas. Il n'existe pas d'emplacement standard pour stocker un certificat utilisateur sur le disque ; Subversion va le chercher l'endroit que vous lui spcifiez. 184

Personnalisation de Subversion

ssl-client-cert-password Si votre certificat client SSL est protg par une phrase de passe, Subversion vous la demandera chaque fois que le certificat est utilis. Si vous trouvez cela pnible (et que cela ne vous drange pas que cette phrase de passe soit stocke dans le fichier servers), vous pouvez placer dans cette variable la phrase de passe de votre certificat. Vous ne serez plus sollicit.

Fichier config
Le fichier config contient le reste des options du programme Subversion disponibles actuellement, c'est--dire celles qui ne se rapportent pas au rseau. Au moment o ces lignes sont crites, seules quelques options sont utilises, mais elles sont quand mme regroupes en sections en prvision d'ajouts futurs. La section auth contient les paramtres relatifs l'authentification et au contrle d'accs de Subversion pour les dpts. Elle comprend les options suivantes : store-passwords Cette option demande Subversion de garder en cache (ou non) les mots de passe qui sont taps par l'utilisateur en rponse aux demandes d'authentification des serveurs. La valeur par dfaut est yes. Remplacez cette valeur par no pour dsactiver la mise en cache sur le disque. Vous pouvez outrepasser cette option pour un appel donn d'une commande svn en utilisant l'option de ligne de commande --no-auth-cache (pour les sous-commandes qui acceptent cette option). Pour plus d'informations, consultez la section intitule Mise en cache des lments d'authentification du client . store-auth-creds cette option est quivalente store-passwords sauf qu'elle applique la mise en cache sur le disque (ou non) l'ensemble des informations d'authentification : identifiants, mots de passe, certificats serveur et tout autre type d'lment pouvant tre mis en cache. La section helpers dfinit quelles sont les applications externes utilises par Subversion pour accomplir ses tches. Les options valides dans cette section sont : editor-cmd Cette option indique le programme utilis par l'utilisateur auquel Subversion demande d'entrer des mta-donnes textuelles ou de rsoudre les conflits de manire interactive. Consultez la section intitule Utilisation d'diteurs externes pour plus de dtails sur l'utilisation d'un diteur de texte externe avec Subversion. diff-cmd Cette option contient le chemin absolu du programme de comparaison qui est utilis lorsque Subversion doit afficher l'utilisateur plusieurs fichiers comparer (par exemple lors de l'utilisation de la commande svn diff). Par dfaut, Subversion utilise une bibliothque interne de comparaison. Dfinir cette option le forcera utiliser un programme externe pour effectuer cette tche. Consultez la section intitule Utilisation des outils externes de comparaison et de fusion pour plus de dtails sur l'utilisation de tels programmes. diff3-cmd Cette option contient le chemin absolu d'un programme de comparaison trois entres. Subversion utilise ce programme pour fusionner les changements effectus par l'utilisateur avec ceux en provenance du dpt. Par dfaut, Subversion utilise une bibliothque interne de comparaison. Dfinir cette option le forcera utiliser un programme externe pour effectuer cette tche. Consultez la section intitule Utilisation des outils externes de comparaison et de fusion pour plus de dtails sur l'utilisation de tels programmes. diff3-has-program-arg Ce drapeau doit tre mis true si le programme spcifi par l'option diff3-cmd accepte l'option --diff-program en ligne de commande. merge-tool-cmd Cette option contient le programme que Subversion utilise pour effectuer les oprations de fusion trois sources sur vos fichiers suivis en versions. Consultez la section intitule Utilisation des outils externes de comparaison et de fusion pour plus de dtails sur l'utilisation de tels programmes.

185

Personnalisation de Subversion

La section tunnels vous permet de dfinir de nouveaux tunnels utiliser avec les connexions clientes svnserve et svn://. Pour plus de dtails, consultez la section intitule Encapsulation de svnserve dans un tunnel SSH . La section miscellany rcolte tout ce qui n'a pas sa place ailleurs 2 Dans cette section, vous trouvez : global-ignores Quand vous excutez la commande svn status, Subversion affiche la liste des fichiers et rpertoires non suivis en versions avec ceux qui sont suivis en versions, en les marquant d'un caractre ? (voir la section intitule Avoir une vue d'ensemble des changements effectus ). Parfois, ces lments inutiles et non suivis en version ne font que rendre l'affichage plus confus, par exemple dans le cas des fichiers objets gnrs par les compilations. L'option globalignores contient une liste de globs spars par des espaces qui dcrivent les noms de fichiers et de rpertoires que Subversion ne doit pas afficher, sauf s'ils sont suivis en versions. La valeur par dfaut est *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store. Tout comme svn status, les commandes svn add et svn import ignorent les fichiers qui entrent en correspondance avec la liste lors du parcours d'un rpertoire. Vous pouvez bloquer ce comportement pour une instance donne de ces commandes en spcifiant explicitement le nom de fichier ou en utilisant l'option --no-ignore en ligne de commande. Vous pouvez trouvez des informations pour contrler plus finement les lments ignors dans la section intitule Occultation des lments non suivis en versions . enable-auto-props Cette option demande Subversion d'ajouter automatiquement des proprits sur les fichiers nouvellement ajouts ou imports. La valeur par dfaut est no, vous devez donc lui affecter la valeur yes pour activer cette fonctionnalit. La section auto-props de ce fichier spcifie quelles proprits doivent tre dfinies sur quels fichiers. log-encoding Cette option dfinit la valeur par dfaut du codage des caractres des messages de propagation. C'est le pendant permanent de l'option --encoding (voir la section intitule Options de svn ). Le dpt Subversion stocke les messages de propagation en UTF-8 et suppose que votre message est crit en utilisant le codage dfini par votre systme d'exploitation. Vous devez spcifier un codage diffrent si vos messages de propagation sont rdigs avec un autre codage. use-commit-times Normalement, les fichiers de votre copie de travail sont dats de manire indiquer la dernire fois qu'ils ont t manipuls par n'importe quel processus, que ce soit votre diteur de texte ou une sous-commande svn. C'est le comportement attendu gnralement par les dveloppeurs de logiciels, puisque les systmes de compilation examinent souvent ces dates pour dcider quels fichiers doivent tre recompils. Dans d'autres situations, cependant, il est prfrable d'avoir une date qui indique la dernire fois que le fichier a t modifi dans le dpt. La commande svn export marque la date de la dernire propagation sur les arborescences qu'elle produit. En mettant cette variable de configuration yes, les commandes svn checkout, svn update, svn switch et svn revert marqueront galement les fichiers qu'elles modifient avec la date de dernire propagation. mime-types-file Cette option est apparue dans Subversion 1.5. Elle spcifie le chemin d'un fichier de correspondance pour les types MIME, de la mme manire que le fichier mime.types fourni par le serveur HTTP Apache. Subversion utilise ce fichier pour associer des types MIME aux nouveaux fichiers ajouts ou imports. Consultez la section intitule Configuration automatique des proprits et la section intitule Type de contenu des fichiers pour plus d'informations sur la dtection et l'utilisation des types de fichiers par Subversion. preserved-conflict-file-exts La valeur de cette option est une liste d'extensions de fichiers (spares par des espaces) que Subversion doit prserver quand il gnre des noms de fichiers lors des conflits. Par dfaut, cette liste est vide. C'est une nouvelle option apparue dans Subversion 1.5. Quand Subversion dtecte des conflits dans les modifications effectues sur un fichier, il soumet la rsolution de ces conflits l'utilisateur. Pour aider l'utilisateur les rsoudre, Subversion garde une copie originale des diffrentes versions en lice du fichier dans la copie de travail. Par dfaut, ces fichiers ont des noms construits en ajoutant au nom de fichier original une extension particulire telle que .mine ou .REV (o REV est un numro de rvision). Ceci peut tre gnant sur les systmes d'exploitation qui utilisent les extensions de noms de fichiers pour dterminer l'application par dfaut
2

En clair, c'est un joyeux fourre-tout.

186

Personnalisation de Subversion

utiliser pour ouvrir et diter le fichier, le fichier avec la nouvelle extension n'tant plus automatiquement ouvert dans l'application prvue. Par exemple, si le fichier NotesDeVersion.pdf est en conflit, les fichiers gnrs risquent de s'appeler NotesDeVersion.pdf.mine ou NotesDeVersion.pdf.r4231. Bien que votre systme soit peut-tre configur pour ouvrir les fichiers .pdf ave Acrobat Reader, il n'existe srement pas d'application prconfigure pour ouvrir les fichiers avec l'extension .r4231. Vous pouvez arranger cela en utilisant cette option de configuration. Pour les fichiers dont l'extension est spcifie, Subversion ajoutera au nom des fichiers gnrs l'extension particulire lie au conflit, mais il rajoutera aussi la suite l'extension originale. Dans l'exemple prcdent, en supposant que pdf est une des extensions configure dans la liste cidessus, les noms des fichiers gnrs pour NotesDeVersion.pdf vont tre NotesDeVersion.pdf.mine.pdf et NotesDeVersion.pdf.r4231.pdf. Comme chaque fichier se termine par .pdf, l'application approprie sera utilise pour les visualiser. interactive-conflicts Cette option est une option boolenne qui indique si Subversion doit essayer de rsoudre les conflits de manire interactive. Si la valeur est yes (qui est la valeur par dfaut), Subversion demandera l'utilisateur comment grer les conflits, comme indiqu dans la section intitule Rsoudre les conflits (fusionner des modifications) . Autrement, il marquera simplement qu'il existe un conflit et continuera l'opration en cours, remettant sa rsolution plus tard. no-unlock Cette option boolenne correspond l'option --no-unlock de svn commit. Elle indique Subversion de ne pas librer les verrous poss sur les fichiers que vous venez de propager. Si cette option est positionne yes, Subversion ne librera jamais aucun verrou automatiquement, vous laissant le faire explicitement avec svn unlock. La valeur par dfaut est no. La section auto-props contrle la possibilit par le client Subversion de positionner automatiquement certaines proprits sur les fichiers qui sont ajouts ou imports. Elle contient un nombre arbitraire de paires cl-valeur au format MOTIF = NOM_PROPRIETE=VALEUR[;NOM_PROPRIETE=VALEUR ...], o MOTIF est un motif de nom de fichier qui correspond un ou plusieurs noms de fichiers et le reste de la ligne est une liste d'affectations (spares par des pointsvirgules) de valeurs des proprits. Si un nom de fichier correspond plusieurs motifs, autant de proprits seront positionnes ; cependant, il n'y a aucune garantie que les auto-props seront appliques dans l'ordre dans lequel elles apparaissent dans le fichier config ; il ne faut donc pas dfinir de rgles susceptibles d'en craser d'autres. Vous pouvez trouver de nombreux exemples d'utilisation d'auto-props dans le fichier config. Enfin, n'oubliez pas de positionner enable-auto-props yes dans la section miscellany si vous voulez activer auto-props.

Localisation
La localisation (aussi appele rgionalisation) consiste modifier le comportement d'un programme pour qu'il agisse d'une manire propre une rgion. Quand un programme formate les nombres et les dates d'une faon particulire pour votre rgion du monde ou quand il affiche des messages (ou accepte des entres) dans votre langue maternelle, le programme est dit localis. Cette section dcrit les tapes qu'a franchi Subversion pour tre localisable.

Gnralits sur la localisation


La plupart des systmes d'exploitation modernes intgrent la notion de paramtres rgionaux courants (current locale en anglais), c'est--dire la rgion ou le pays dont les conventions sont appliques. Ces conventions, gnralement choisies par un mcanisme de configuration pour la dure du fonctionnement d'un programme sur l'ordinateur, affectent la faon dont les donnes sont prsentes l'utilisateur ainsi que la faon dont les entres de l'utilisateur sont traites. Sur la majorit des systmes de type Unix, vous pouvez vrifier la valeur des paramtres rgionaux en cours en lanant la commande locale : $ locale LANG= LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL="C" $ 187

Personnalisation de Subversion

L'affichage comprend une liste de variables d'environnement relatives des conventions locales et leur valeurs. Dans cet exemple, toutes les variables possdent la valeur par dfaut C, mais les utilisateurs peuvent modifier ces valeurs et leur affecter des valeurs propres leur pays ou leur langue. Par exemple, si quelqu'un fixe la valeur de la variable LC_TIME fr_CA, les programmes sauront qu'il doivent afficher les dates et les heures conformment aux attentes des canadiens francophones. Et si quelqu'un fixe la valeur de la variable LC_MESSAGES zh_TW, les programmes sauront qu'il doivent afficher les messages destination de l'utilisateur en chinois traditionnel. Modifier la variable LC_ALL quivaut donner toutes les variables de paramtres rgionaux la valeur choisie pour LC_ALL. La valeur de la variable LANG est utilise par dfaut pour toute variable de paramtre rgional qui n'a pas de valeur attribue. Pour voir la liste de toutes les variables de paramtres rgionaux sur un systme Unix, lancez la commande locale -a. Sous Windows, la configuration des paramtres rgionaux s'effectue par l'intermdiaire de l'lment Options rgionales, date, heure et langue du panneau de configuration. Vous pouvez y voir et y slectionner les valeurs de chacune des variables disponibles, voire personnaliser les conventions d'affichage de nombreux paramtres ( un niveau de dtail presque maladif).

Utilisation des paramtres rgionaux par Subversion


Le client Subversion, svn, utilise la configuration courante des paramtres rgionaux de deux manires. D'abord, il prend en compte la valeur de la variable LC_MESSAGES et essaie d'afficher tous les messages dans la langue indique. Par exemple : $ export LC_MESSAGES=de_DE $ svn help cat cat: Gibt den Inhalt der angegebenen Dateien oder URLs aus. Aufruf: cat ZIEL[@REV]... Ce comportement est identique sur les systmes Unix et Windows. Notez cependant que, bien que votre systme d'exploitation puisse supporter certaines valeurs de paramtres rgionaux, Subversion ne parle peut-tre pas toutes ces langues. Afin d'afficher ces messages localiss, des volontaires (humains) doivent fournir des traductions dans chaque langue. Les traductions sont crites en utilisant le paquetage GNU gettext, ce qui produit des modules de traduction dont l'extension du nom de fichier est .mo. Par exemple, le fichier des traductions allemandes s'appelle de.mo. Ces fichiers de traductions sont installs quelque part sur votre systme. Sous Unix, ils sont gnralement placs dans /usr/share/locale/, alors que sous Windows on les trouve souvent dans le dossier \share\locale\ de la zone d'installation de Subversion. Une fois install, un module est renomm d'aprs le programme pour lequel il fournit des traductions. Par exemple, le fichier de.mo sera peut-tre finalement install en tant que /usr/share/locale/de/LC_MESSAGES/subversion.mo. En parcourant les fichiers .mo installs, vous pouvez voir quelles langues le client Subversion parle. La prise en compte des paramtres rgionaux se fait aussi au niveau de la faon dont svn interprte vos entres. Le dpt stocke tous les chemins, noms de fichiers et messages de propagation en Unicode, plus exactement en UTF-8. En ce sens, le dpt est international, c'est--dire que le dpt peut accepter des entres en n'importe quelle langue. Cela signifie cependant que le client Subversion ne doit envoyer vers le dpt que des noms de fichiers et des messages de propagation en UTF-8. Pour ce faire, il doit convertir les donnes depuis les paramtres rgionaux courants vers l'UTF-8. Par exemple, supposons que vous crez un fichier nomm caff.txt et qu'ensuite, lorsque vous propagez ce fichier, vous fournissez le message de propagation suivant : Adesso il caff pi forte . Le nom du fichier et le message de propagation contiennent tous deux des caractres non-ASCII, mais puisque vos paramtres rgionaux sont it_IT, le client Subversion sait qu'il doit les interprter comme de l'italien. Il utilise alors un jeu de caractres italiens pour convertir ces donnes en UTF-8 avant de les envoyer au dpt. Remarquez que bien que le dpt exige des noms de fichiers et des messages de propagation au format UTF-8, il ne s'intresse pas au contenu du fichier. Subversion traite le contenu des fichiers comme des chanes d'octets opaques ; ni le client ni le serveur ne tentent de comprendre le jeu de caractres ou le codage du contenu d'un fichier. Erreurs de conversion des jeux de caractres Lors de l'utilisation de Subversion, vous tes susceptible d'tre confront des erreurs de conversion des jeux de caractres :

188

Personnalisation de Subversion

svn: Impossible de convertir la chane de l'encodage natif vers 'UTF-8' : svn: Impossible de convertir la chane de 'UTF-8' vers l'encodage natif : De telles erreurs surviennent gnralement quand un client Subversion reoit une chane UTF-8 du dpt et que certains caractres de cette chane ne peuvent pas tre reprsents dans le jeu de caractres local. Par exemple, si vos paramtres rgionaux sont en_US et qu'un collaborateur a propag un nom de fichier en japonais, alors il y a de grandes chances que cette erreur apparaisse lors de la rception du fichier pendant l'excution de svn update. La solution consiste soit configurer vos paramtres rgionaux de manire pouvoir traiter n'importe quelles donnes au format UTF-8, soit modifier le nom de fichier ou le message de propagation dans le dpt (et n'oubliez pas de taper sur les doigts de votre collaborateur : les projets doivent dcider en amont des langues utiliser, de manire ce que l'ensemble des collaborateurs utilisent les mmes paramtres rgionaux).

Utilisation d'diteurs externes


La manire la plus vidente d'entrer des donnes dans Subversion consiste ajouter des fichiers sous gestion de versions, propager des changements sur ces fichiers, etc. Mais d'autres informations existent dans le dpt Subversion ct des donnes constitues par les simples fichiers suivis en versions. Certaines de ces informations les messages de propagation, les commentaires sur les verrous et les valeurs de certaines proprits ont naturellement tendance tre textuelles et sont explicitement fournies par les utilisateurs. La plupart de ces informations peuvent tre fournies Subversion l'aide du client en ligne de commande en utilisant les options --message (-m) et --file (-F) dans le cadre des sous-commandes appropries. Chacune de ces options a des avantages et des inconvnients. Par exemple, quand vous effectuez une propagation, l'option -file (-F) fonctionne bien si vous avez dj prpar un fichier texte qui contient votre message de propagation. Si vous ne l'avez pas fait, vous pouvez toujours utiliser l'option --message (-m) pour stipuler votre message en ligne de commande. Malheureusement, composer un message de plus d'une ligne en ligne de commande peut tre assez dlicat. Les utilisateurs veulent plus de flexibilit : ils veulent pouvoir crire un message de propagation multi-ligne, sans contrainte de format et la demande. Subversion rpond cette attente en vous permettant de spcifier un diteur de texte externe qui sera lanc au besoin, vous offrant ainsi un moyen plus puissant pour entrer des mta-donnes textuelles. Il y a plusieurs manires d'indiquer Subversion quel diteur vous voulez utiliser. Subversion vrifie les choses suivantes, dans l'ordre spcifi, avant de lancer un tel diteur : 1. l'option en ligne de commande --editor-cmd 2. la variable d'environnement SVN_EDITOR 3. l'option de configuration editor-cmd 4. la variable d'environnement VISUAL 5. la variable d'environnement EDITOR 6. ventuellement, une valeur par dfaut spcifie dans une des bibliothques de Subversion (non prsente dans les distributions officielles) La valeur de n'importe laquelle de ces options ou variables est le dbut de la ligne de commande qui sera excute par le shell. Subversion ajoute cette ligne de commande un espace et le chemin vers un fichier temporaire diter. Ainsi, pour tre utilis avec Subversion, l'diteur spcifi ou configur doit pouvoir tre appel avec pour dernier argument de sa ligne de commande le fichier diter, il doit tre capable de sauvegarder le fichier au mme endroit et il doit retourner zro comme code de retour, pour indiquer la russite de l'opration. Comme indiqu, les diteurs externes peuvent tre utiliss pour fournir les messages de propagation n'importe quelle souscommande de propagation (telle que svn commit ou svn import, svn mkdir ou svn delete quand vous fournissez une URL cible, etc.) et Subversion essaie de lancer l'diteur automatiquement si vous ne spcifiez ni l'option --message (-m) ni 189

Personnalisation de Subversion

l'option --file (-F). La commande svn propedit est presque entirement construite autour de l'utilisation d'un diteur de texte externe. partir de la version 1.5, Subversion utilise galement l'diteur de texte externe configur quand l'utilisateur demande le lancement d'un diteur lors de la rsolution interactive de conflits. Bizarrement, il ne semble pas y avoir de moyen d'utiliser un diteur externe pour fournir un commentaire de verrouillage de manire interactive.

Utilisation des outils externes de comparaison et de fusion


L'interface entre Subversion et les outils de comparaison (de deux ou trois fichiers) remonte l'poque o Subversion, pour afficher les diffrences de manire contextuelle, utilisait directement la suite d'outils GNU de comparaison, plus prcisment les utilitaires diff et diff3. Pour obtenir le comportement dsir par Subversion, l'appel ces programmes se faisait avec une ribambelle d'options et de paramtres dont la plupart taient spcifiques ces utilitaires. Plus tard, Subversion s'est dot de sa propre bibliothque de comparaison et, afin de conserver la possibilit de choisir, les options --diff-cmd et -diff3-cmd ont t ajoutes au client en ligne de commande pour que les utilisateurs allergiques la nouvelle bibliothque puissent indiquer facilement leur souhait de se servir des utilitaires GNU diff et diff3. Si ces options taient utilises, Subversion ignorait purement et simplement sa bibliothque interne de comparaison et appelait alors ces programmes externes, avec leurs listes d'arguments longue comme un jour sans pain et leurs autres spcificits. Les choses sont restes en l'tat. Il n'a pas fallu longtemps pour que les adeptes de Subversion comprennent que si l'on pouvait utiliser les utilitaires GNU diff et diff3 situs un endroit prcis du disque, on pouvait alors aussi utiliser ce mcanisme pour utiliser d'autres outils de comparaison. Aprs tout, Subversion ne vrifiait pas que les programmes qu'il lanait faisaient bien partie de la suite des outils GNU de comparaison. Mais la seule chose que l'on peut configurer dans l'utilisation de programmes externes est leur emplacement sur le disque ; pas les options, ni l'ordre des paramtres, ni le reste. Subversion continue envoyer toutes les options des utilitaires GNU votre programme de comparaison, indpendamment du fait que votre programme en tienne compte ou non. Et c'est l que la plupart des utilisateurs ne comprennent pas la logique de la chose. La cl pour utiliser des outils externes de comparaison de deux ou trois fichiers (autres que les programmes GNU diff et diff3 bien sr) avec Subversion est de crer des scripts d'interface qui convertissent les donnes fournies par Subversion en donnes comprhensibles par l'outil de comparaison que vous utilisez, puis de convertir les sorties de votre outil vers le format attendu par Subversion : le format que les outils GNU auraient utilis. Les sections suivantes dtaillent les spcificits de ce qu'attend Subversion. La dcision de lancer une comparaison entre deux ou trois fichiers dans le cadre d'une opration Subversion est entirement du ressort de Subversion et est conditionne, en autres, au fait que les fichiers soient lisibles par un humain comme indiqu par leur proprit svn:mime-type. Cela signifie, par exemple, que mme si vous avez le plus formidable outil de l'univers, capable de comparer et fusionner des documents Microsoft Word, il ne sera jamais appel par Subversion tant que le type MIME des documents Word suivis en versions indiquera qu'ils ne sont pas lisibles par un humain (tel que application/msword). Pour plus d'informations sur la configuration des types MIME, voir la section intitule Type de contenu des fichiers Subversion 1.5 introduit la rsolution interactive des conflits (dcrite dans la section intitule Rsoudre les conflits (fusionner des modifications) ) et l'une des options proposes l'utilisateur est de lancer un outil de fusion externe. Si cette action est choisie, Subversion consultera l'option merge-tool-cmd de la zone de configuration des excutables, susceptible de contenir le nom d'un outil externe de fusion et, s'il en trouve un, lancera cet outil avec les fichiers appropris en paramtres. Il y a deux diffrences notables avec l'outil de comparaison de trois fichiers. D'abord, l'outil de comparaison est toujours utilis pour afficher les diffrences entre trois fichiers alors que l'outil de fusion est employ uniquement quand l'application de comparaison a dtect un conflit. Ensuite, l'interface est beaucoup plus propre votre outil de fusion a seulement besoin d'accepter comme paramtres en ligne de commande les chemins des quatre fichiers suivants : le fichier de rfrence, le leur (qui contient les modifications en provenance du dpt), le mien (qui contient les modifications locales) et le fichier dans lequel sera plac le contenu final stocker.

Programme externe de comparaison


Subversion appelle les programmes externes de comparaison avec des paramtres compatibles avec la suite d'outils de comparaison GNU et s'attend ce que le programme renvoie un code d'erreur signifiant la russite de la comparaison. Pour la plupart des programmes de comparaison alternatifs, seuls les sixime et septime arguments, indiquant les chemins vers les fichiers comparer, respectivement placs gauche et droite, sont intressants. Notez que Subversion lance le programme de comparaison pour chaque fichier concern par l'opration Subversion, ce qui peut vous amener avoir plusieurs instances simultanment si votre programme fonctionne de manire asynchrone (ou s'il est plac en arrire-plan). Enfin, Subversion 190

Personnalisation de Subversion

s'attend ce que votre programme retourne un code d'erreur de 1 s'il a dtect des diffrences ou 0 sinon. Tout autre code d'erreur est considr comme une erreur fatale 3. L'Exemple 7.2, interface-diff.py et l' Exemple 7.3, interface-diff.bat sont des modles de scripts d'interface pour un outil externe de comparaison, respectivement en langage Python et en langage de script Windows :

Exemple 7.2. interface-diff.py


#!/usr/bin/env python import sys import os # Indiquez ici le chemin de votre outil de comparaison favori. DIFF = "/usr/local/bin/mon-diff-perso" # Subversion fournit les chemins voulus dans les deux derniers arguments. GAUCHE = sys.argv[-2] DROITE = sys.argv[-1] # Appelons la commande de comparaison (modifiez la ligne suivante # en accord avec votre programme de comparaison). cmd = [DIFF, '--left', GAUCHE, '--right', DROITE] os.execv(cmd[0], cmd) # # # # Le code d'erreur renvoy doit tre : 0 si aucune diffrence n'est dtecte, 1 s'il y a des diffrences. Tout autre code est trait comme une erreur fatale.

Exemple 7.3. interface-diff.bat


@ECHO OFF REM Indiquez ici le chemin de votre outil de comparaison favori. SET DIFF="C:\Program Files\Super Progs\Mon Diff Perso.exe" REM REM REM SET SET Subversion fournit les chemins voulus dans les deux derniers arguments. Ce sont les paramtres 6 et 7 (sauf si vous utilisez svn diff -x, auquel cas tout est possible). GAUCHE=%6 DROITE=%7

REM Appelons la commande de comparaison (modifiez la ligne suivante REM en accord avec votre programme de comparaison). %DIFF% --left %GAUCHE% --right %DROITE% REM REM REM REM Le code d'erreur renvoy doit tre : 0 si aucune diffrence n'est dtecte, 1 s'il y a des diffrences. Tout autre code est trait comme une erreur fatale.

Programme externe de comparaison de trois fichiers


Subversion appelle les programmes externes de fusion avec des paramtres compatibles avec l'outil GNU diff3 et s'attend ce
3

Le manuel du diff GNU indique : Un code de retour valant 0 signifie qu'aucune diffrence n'a t trouve, 1 signifie que des diffrences sont apparues, 2 indique une erreur .

191

Personnalisation de Subversion

que le programme externe retourne un code d'erreur correct et que le fichier rsultant de l'opration de fusion soit envoy vers la sortie standard (de faon ce que Subversion puisse le rediriger vers le fichier suivi en versions appropri). Pour la plupart des programmes de fusion alternatifs, seuls les neuvime, dixime et onzime arguments (les chemins des fichiers qui contiennent les versions mien , original et leur respectivement) sont intressants. Notez que puisque Subversion utilise la sortie de votre programme de fusion, votre script d'interface ne doit pas se terminer avant que la sortie n'ait t fournie Subversion. Quand il se termine, il doit retourner un code d'erreur de 0 si la fusion s'est correctement droule ou de 1 si des conflits non rsolus persistent dans la sortie. Tout autre code d'erreur est considr comme une erreur fatale. L'Exemple 7.4, interface-diff3.py et l'Exemple 7.5, interface-diff3.bat sont des modles pour des scripts d'interface vers un programme externe de fusion en langage Python et script Windows respectivement.

Exemple 7.4. interface-diff3.py


#!/usr/bin/env python import sys import os # Indiquez ici le chemin de votre outil de fusion favori. DIFF3 = "/usr/local/bin/mon-outil-de-fusion" # Subversion fournit les chemins voulus dans les trois derniers arguments. MIEN = sys.argv[-3] VIEUX = sys.argv[-2] LEUR = sys.argv[-1] # Appelons la commande de fusion (modifiez la ligne suivante # en accord avec votre outil de fusion). cmd = [DIFF3, '--older', VIEUX, '--mine', MIEN, '--yours', LEUR] os.execv(cmd[0], cmd) # # # # # # # Aprs avoir effectu la fusion, le script doit envoyer le contenu du fichier rsultant vers la sortie standard (stdout) Faites le votre convenance. Le code d'erreur renvoy doit tre : 0 si la fusion a bien fonctionn, 1 s'il reste des conflits non rsolus. Tout autre code est trait comme une erreur fatale.

Exemple 7.5. interface-diff3.bat


@ECHO OFF REM Indiquez ici le chemin de votre outil de fusion favori. SET DIFF3="C:\Program Files\Super Progs\Mon Outil De Fusion.exe" REM Subversion fournit les chemins voulus dans les trois derniers arguments. REM Ce sont les paramtres 9, 10 et 11. Mais nous n'avons accs qu' REM neuf paramtres en mme temps, nous effectuons donc deux dcalages REM pour obtenir les paramtres manquants. SHIFT SHIFT SET MIEN=%7 SET VIEUX=%8 SET LEUR=%9 REM Appelons la commande de fusion (modifiez la ligne suivante REM en accord avec votre outil de fusion). %DIFF3% --older %VIEUX% --mine %MIEN% --yours %LEUR% 192

Personnalisation de Subversion

REM REM REM REM REM REM REM

Aprs avoir effectu la fusion, le script doit envoyer le contenu du fichier rsultant vers la sortie standard (stdout) Faites le votre convenance. Le code d'erreur renvoy doit tre : 0 si la fusion a bien fonctionn, 1 s'il reste des conflits non rsolus. Tout autre code est trait comme une erreur fatale.

Rsum
Quelquefois il n'y a qu'une faon de bien faire les choses, quelquefois il en existe plusieurs. Les dveloppeurs de Subversion comprennent que bien que le plus souvent son comportement est acceptable par la plupart des utilisateurs, il y a des fonctionnalits pour lesquelles il n'existe pas de consensus. Dans ces situations, Subversion permet l'utilisateur de spcifier le comportement qu'il dsire voir appliquer. Dans ce chapitre, nous avons examin le systme de configuration des excutables de Subversion ainsi que d'autres mcanismes permettant de contrler le comportement de certaines actions. Si vous tes dveloppeur, le prochain chapitre vous emmnera un cran plus loin. Il dcrit comment vous pouvez personnaliser davantage Subversion en crivant vos propres programmes en remplacement des bibliothques Subversion.

193

Chapitre 8. Intgration de Subversion


Subversion est conu de manire modulaire : il est constitu d'un ensemble de bibliothques crites en langage C. Chaque bibliothque a un but et une interface de programmation (API, application programming interface en anglais) bien dfinis ; cette interface est disponible non seulement pour le propre usage de Subversion mais aussi pour n'importe quel programme qui souhaite inclure ou piloter Subversion d'une manire ou d'une autre. De plus, l'API Subversion est non seulement disponible pour les programmes crits en langage C, mais aussi pour les programmes crits dans des langages de plus haut niveau tels que Python, Perl, Java et Ruby. Ce chapitre est destin ceux qui souhaitent interagir avec Subversion au moyen de son API publique ou d'une de ses nombreuses interfaces avec d'autres langages. Si vous souhaitez crire des scripts robustes qui encapsulent les fonctionnalits de Subversion afin de vous rendre la vie plus facile, si vous essayez de dvelopper des intgrations plus pousses entre Subversion et d'autres logiciels ou si vous tes juste intress par les nombreux modules de Subversion et ce qu'ils ont offrir, ce chapitre est fait pour vous. Si, par contre, vous ne vous voyez pas participer Subversion ce niveau, vous pouvez sauter ce chapitre sans la moindre crainte pour vos comptences en tant qu'utilisateur de Subversion.

Organisation des bibliothques en couches successives


Chaque bibliothque au sein de Subversion peut tre classe dans une des trois couches principales : la couche dpt, la couche d'accs au dpt (RA pour Repository Access en anglais) et la couche client (voir la Figure 1, Architecture de Subversion de la prface). Nous allons examiner ces trois couches rapidement mais, d'abord, passons brivement en revue les diffrentes bibliothques de Subversion. Pour des raisons de cohrence, nous nous rfrons ces bibliothques par leurs noms Unix sans extension (libsvn_fs, libsvn_wc, mod_dav_svn, etc.). libsvn_client interface principale pour les programmes clients ; libsvn_delta routines de recherche de diffrences pour les arborescences et les flux d'octets ; libsvn_diff routines de recherche de diffrences et de fusions contextuelles ; libsvn_fs chargeur de modules et outils communs pour le systme de fichiers ; libsvn_fs_base gestion du magasin de donnes Berkeley DB ; libsvn_fs_fs gestion du magasin de donnes natif FSFS ; libsvn_ra outils communs pour l'accs au dpt et chargeur de modules ; libsvn_ra_local module d'accs au dpt en local ; libsvn_ra_neon module d'accs au dpt par WebDAV ; libsvn_ra_serf autre module (exprimental) d'accs au dpt par WebDAV ; libsvn_ra_svn modle d'accs au dpt par le protocole Subversion ; libsvn_repos 194

Intgration de Subversion

interface du dpt ; libsvn_subr diverses routines utiles ; libsvn_wc bibliothque pour la gestion de la copie de travail locale ; mod_authz_svn module Apache d'authentification pour les accs aux dpts Subversion par WebDAV ; mod_dav_svn module Apache de correspondance entre les oprations WebDAV et les oprations Subversion. Le fait que le mot divers n'apparaisse qu'une seule fois dans la liste prcdente est plutt un bon signe. L'quipe de dveloppement de Subversion est particulirement soucieuse de placer les fonctionnalits dans les couches et bibliothques appropries. Un des plus grands avantages de cette conception modulaire, du point de vue du dveloppeur, est srement l'absence de complexit. En tant que dveloppeur, vous pouvez vous forger rapidement une image mentale de cette architecture et ainsi trouver relativement facilement l'emplacement des fonctionnalits qui vous intressent. Un autre avantage de la modularit est la possibilit de remplacer un module par une autre bibliothque qui implmente la mme API sans affecter le reste du code. Dans un certain sens, c'est ce qui se passe dj dans Subversion. Les bibliothques libsvn_ra_local, libsvn_ra_neon, libsvn_ra_serf et libsvn_ra_svn implmentent toutes la mme interface et fonctionnent comme des greffons pour libsvn_ra. Et toutes les quatre communiquent avec la couche dpt libsvn_ra_local se connectant directement au dpt, les trois autres le faisant travers le rseau. libsvn_fs_base et libsvn_fs_fs sont un autre exemple de bibliothques qui implmentent les mmes fonctionnalits de diffrentes manires les deux sont des greffons pour la bibliothque commune libsvn_fs. Le client lui-mme illustre galement les avantages de la modularit dans l'architecture de Subversion. La bibliothque libsvn_client est un point d'entre unique pour la plupart des fonctionnalits ncessaires la conception d'un client Subversion fonctionnel (voir la section intitule Couche client ). Ainsi, bien que la distribution Subversion fournisse seulement le programme en ligne de commande svn, de nombreux programmes tiers fournissent diffrents types d'IHM. Ces interfaces graphiques utilisent la mme API que le client en ligne de commande fourni en standard. Depuis le dbut, cette modularit joue un rle majeur dans la prolifration des diffrents clients Subversion, sous la forme de clients autonomes ou greffs dans des environnements de dveloppement intgrs (IDE en anglais) et, par extension, dans l'adoption formidablement rapide de Subversion lui-mme.

Couche dpt
Quand nous faisons rfrence la couche dpt de Subversion, nous parlons gnralement de deux concepts de base : l'implmentation du systme de fichiers suivi en versions (auquel on a accs via libsvn_fs et qui est support par les greffons associs libsvn_fs_base et libsvn_fs_fs) et la logique du dpt qui l'habille (telle qu'elle est implmente dans libsvn_repos). Ces bibliothques fournissent les mcanismes de stockage et de comptes-rendus pour les diffrentes rvisions de vos donnes suivies en versions. Cette couche est connecte la couche client via la couche d'accs au dpt et est, du point de vue de l'utilisateur de Subversion, le truc l'autre bout de la ligne . Le systme de fichiers Subversion n'est pas un systme de fichiers de bas niveau que vous pourriez installer sur votre systme d'exploitation (tels que NTFS ou ext2 pour Linux) mais un systme de fichiers virtuel. Plutt que de stocker les fichiers et rpertoires comme des fichiers et des rpertoires rels (du type de ceux dans lesquels vous naviguez avec votre navigateur de fichiers), il utilise un des deux magasins de donnes abstraits disponibles : soit le systme de gestion de bases de donnes Berkeley DB, soit une reprsentation dans des fichiers ordinaires, dite plat (pour en apprendre plus sur les deux magasins de donnes, reportez-vous la section intitule Choix du magasin de donnes ). La communaut de dveloppement Subversion a mme exprim le souhait que les futures versions de Subversion puissent utiliser d'autres magasins de donnes, peut-tre travers un mcanisme tel que ODBC (Open Database Connectivity , standard ouvert de connexion des bases de donnes). En fait, Google a fait quelque chose de semblable avant de lancer le service Google Code Project Hosting (Hbergement de code source de projets) : ils ont annonc mi-2006 que les membres de leur quipe open source avaient crit un nouveau greffon propritaire de systme de fichiers pour Subversion, qui utilisait leur base de donnes Google ultrascalable Bigtable comme magasin de donnes. L'API du systme de fichiers, mise disposition par libsvn_fs, contient les fonctionnalits que vous pouvez attendre de n'importe quel autre systme de fichiers : vous pouvez crer et supprimer des fichiers et des rpertoires, les copier et les dplacer, modifier le contenu d'un fichier, etc. Elle possde galement des caractristiques peu communes comme la capacit 195

Intgration de Subversion

d'ajouter, modifier et supprimer des mta-donnes ( proprits ) sur chaque fichier ou rpertoire. En outre, le systme de fichiers Subversion est un systme de fichiers suivi en versions, ce qui veut dire que si vous faites des modifications dans votre arborescence, Subversion se souvient de l'tat de votre arborescence avant les modifications. Et il se souvient aussi de l'tat avant les modifications prcdentes, et de l'tat encore antrieur, et ainsi de suite. Vous pouvez ainsi remonter le temps (c'est--dire les versions) jusqu'au moment o vous avez commenc ajouter des lments dans le systme de fichiers. Toutes les modifications faites sur l'arborescence ont pour contexte les transactions de propagation de Subversion. Ce qui suit est la dmarche gnrale simplifie de modification du systme de fichiers : 1. commencer une transaction de propagation de Subversion ; 2. effectuer les modifications (ajouts, suppressions, modifications de proprits, etc.) ; 3. clore la transaction. Une fois que la transaction est termine, les modifications du systme de fichiers sont stockes de faon permanente en tant qu'lments de l'historique. Chacun de ces cycles gnre une nouvelle rvision de l'arborescence et chaque rvision est accessible pour toujours sous la forme d'un clich, immuable, de l'tat de l'arborescence un moment prcis. Digression sur les transactions La notion de transaction Subversion peut tre facilement confondue avec la notion de transaction concernant le magasin de donnes sous-jacent, en particulier cause de la proximit du code des transactions Subversion dans libsvn_fs_base et du code du gestionnaire de bases de donnes Berkeley DB. Ces deux types de transactions assurent l'atomicit et l'isolation. En d'autres termes, les transactions vous permettent d'effectuer un ensemble d'actions avec une logique tout-ou-rien (soit toutes les actions de l'ensemble se terminent avec succs, soit c'est comme si aucune n'avait eu lieu), ce qui permet de ne pas interfrer avec les autres processus qui travaillent sur les donnes. Les transactions dans les bases de donnes comprennent gnralement de petites oprations relatives la modification de donnes dans la base elle-mme (comme changer le contenu d'une ligne dans une table). Les transactions Subversion ont un champ d'action plus large, elles comprennent des oprations de plus haut niveau telles que modifier un ensemble de fichiers et de rpertoires qui doivent tre stocks dans la prochaine rvision de l'arborescence suivie en versions. Pour ajouter la confusion, Subversion utilise une transaction de base de donnes pendant la cration d'une transaction Subversion (ainsi, si la cration de la transaction Subversion choue, la base de donnes sera telle que si la demande de cration n'avait jamais eu lieu) ! Heureusement pour les utilisateurs de l'API du systme de fichiers, la notion de transaction du systme de gestion de bases de donnes lui-mme est presque entirement masque (comme on peut s'y attendre dans une architecture modulaire bien construite). C'est seulement si vous commencez fouiller dans l'implmentation du systme de fichiers que de telles choses deviennent visibles (ou intressantes).

La majeure partie des fonctionnalits offertes par l'interface du systme de fichiers traite d'actions relatives un chemin unique du systme de fichiers. C'est--dire que, vu de l'extrieur du systme de fichiers, le mcanisme de base pour dcrire et accder une rvision donne d'un fichier ou d'un rpertoire utilise des chemins classiques tels que /machin/bidule, de la mme manire que quand vous indiquez un fichier ou un rpertoire dans votre interface en ligne de commande favorite. Vous ajoutez de nouveaux fichiers ou rpertoires en passant leur futur chemin la fonction idoine de l'API. Vous faites des requtes sur ces lments avec le mme mcanisme. Cependant, contrairement la plupart des systmes de fichiers, le chemin n'est pas une information suffisante pour identifier un fichier ou un rpertoire dans Subversion. Reprsentez-vous l'arborescence des rpertoires comme un systme deux dimensions, o l'on atteint les frres d'un nud en se dplaant horizontalement, droite ou gauche, et o la navigation dans les sous-rpertoires de ce nud peut tre assimile un mouvement vers le bas. La Figure 8.1, Fichiers et rpertoires en deux dimensions illustre ce concept pour une arborescence classique.

Figure 8.1. Fichiers et rpertoires en deux dimensions

196

Intgration de Subversion

Ici, la diffrence est que le systme de fichiers Subversion possde une lgante troisime dimension que la plupart des systmes de fichiers n'ont pas : le temps1. Dans l'interface du systme de fichiers, presque chaque fonction qui demande un argument de type chemin attend galement un argument de type racine (dnomm en fait svn_fs_root_t). Cet argument dcrit soit une rvision, soit une transaction (qui est en fait la gense d'une rvision) et fournit la troisime dimension, l'lment de contexte indispensable pour diffrencier /machin/bidule dans la rvision 32 et le mme chemin dans la rvision 98. La Figure 8.2, Prise en compte du temps la troisime dimension de la gestion de versions ! prsente l'historique des rvisions comme une dimension supplmentaire de l'univers du systme de fichiers Subversion.

Figure 8.2. Prise en compte du temps la troisime dimension de la gestion de versions !

Nous comprenons que cela puisse tre un choc norme pour les amateurs de science-fiction, qui ont longtemps cru que le Temps tait en fait la quatrime dimension. Nous nous excusons pour le traumatisme psychologique caus par l'affirmation de cette thorie divergente.

197

Intgration de Subversion

Comme nous l'avons dj mentionn, l'API de libsvn_fs ressemble s'y mprendre celle de n'importe quel autre systme de fichiers, sauf qu'on y a ajout la formidable capacit de gestion des versions. Elle a t conue pour tre utilisable par n'importe quel programme ayant besoin d'un systme de fichiers suivi en versions. Et ce n'est pas un hasard si Subversion luimme est intress par une telle fonctionnalit. Mais, bien que cette API soit suffisante pour effectuer une gestion de versions basique des fichiers et des rpertoires, Subversion en demande plus, et c'est l que libsvn_repos entre en scne. La bibliothque du dpt Subversion (libsvn_repos) se situe (logiquement parlant) au-dessus de l'API libsvn_fs et elle fournit des fonctionnalits supplmentaires allant au-del de la logique sous-jacente du systme de fichiers suivi en versions. Elle ne masque pas entirement chaque fonction du systme de fichiers seules certaines tapes importantes dans le cycle gnral de l'activit du systme de fichiers sont encapsules par l'interface du dpt. Parmi les fonctions encapsules, on peut citer la cration et la propagation des transactions Subversion et la modification des proprits de rvisions. Ces actions particulires sont encapsules par la couche dpt parce qu'elles ont des procdures automatiques associes. Le systme des procdures automatiques du dpt n'est pas strictement concomitant l'implmentation d'un systme de fichiers suivi en versions, c'est pourquoi il rside dans la bibliothque d'encapsulation du dpt. Le mcanisme des procdures automatiques n'est pas l'unique raison qui a conduit sparer logiquement la bibliothque du dpt du reste du code du systme de fichiers. L'API de libsvn_repos fournit Subversion un certain nombre d'autres possibilits intressantes. Parmi elles, on peut citer : crer, ouvrir, dtruire et effectuer des actions de restauration sur un dpt Subversion et le systme de fichiers inclus dans ce 198

Intgration de Subversion

dpt ; dcrire les diffrences entre deux arborescences ; obtenir les messages de propagation associs toutes les rvisions (ou certaines) qui ont modifi un ensemble de fichiers du systme de fichiers ; gnrer des images ( dumps ) du systme de fichiers lisibles par l'utilisateur ces images tant des reprsentations compltes des rvisions du systme de fichiers ; analyser ces images et les charger dans un autre dpt Subversion. Comme Subversion continue voluer, la bibliothque du dpt grandit avec la bibliothque du systme de fichiers pour offrir davantage de fonctionnalits et des options configurables.

Couche d'accs au dpt


Si la couche Dpt de Subversion est l'autre bout de la ligne , la couche d'accs au dpt (RA pour repository access en anglais) est la ligne en tant que telle. Charge d'organiser les donnes entre les bibliothques client et le dpt, cette couche inclut la bibliothque de chargement du module libsvn_ra, les modules RA eux-mmes (qui incluent l'heure actuelle libsvn_ra_neon, libsvn_ra_local, libsvn_ra_serf et libsvn_ra_svn) et toute bibliothque supplmentaire requise par un ou plusieurs de ces modules RA (par exemple, le module Apache mod_dav_svn ou le serveur de libsvn_ra_svn, svnserve). Comme Subversion utilise les URL pour identifier les dpts contacter, la partie de l'URL qui indique le protocole (habituellement file://, http://, https://, svn:// ou svn+ssh://) est utilise pour dterminer quel module RA gre les communications. Chaque module indique la liste des protocoles qu'il connat afin que le chargeur RA puisse dterminer, l'excution, quel module utiliser pour la tche en cours. Vous pouvez obtenir la liste des modules RA disponibles pour votre client Subversion en ligne de commande, ainsi que les protocoles qu'ils prennent en charge, en lanant la commande svn --version : $ svn --version svn, version 1.5.0 (r31699) compil Jun 18 2008, 09:57:36 Copyright (C) 2000-2008 CollabNet. Subversion est un logiciel libre, cf http://subversion.tigris.org/ Il inclut du logiciel dvelopp par CollabNet (http://www.Collab.Net/). Les modules d'accs un dpt (RA) suivants sont disponibles : * ra_neon : Module d'accs un dpt via le protocole WebDAV avec Neon. - gre le schma d'URL 'http' - gre le schma d'URL 'https' * ra_svn : Module d'accs un dpt avec le protocole rseau propre de svn. - avec authentification Cyrus SASL - gre le schma d'URL 'svn' * ra_local : Module d'accs un dpt sur un disque local. - gre le schma d'URL 'file' * ra_serf : Module d'accs un dpt via le protocole WebDAV avec serf. - gre le schma d'URL 'http' - gre le schma d'URL 'https' L'API publique exporte par la couche RA contient les fonctionnalits ncessaires pour envoyer des donnes suivies en versions vers le dpt et pour en recevoir. Chacun des greffons RA disponibles est capable d'effectuer ces tches en utilisant un protocole particulier : libsvn_ra_dav utilise le protocole HTTP/WebDAV (avec chiffrement SSL en option) pour communiquer avec un serveur HTTP Apache sur lequel tourne le module serveur Subversion mod_dav_svn ; libsvn_ra_svn utilise un protocole rseau propre Subversion pour communiquer avec le programme svnserve, et ainsi de suite. Ceux qui dsirent accder un dpt Subversion en utilisant un autre protocole comprendront rapidement pourquoi la couche d'accs au dpt est modulaire ! Les dveloppeurs peuvent tout simplement crire une nouvelle bibliothque qui implmente 199

Intgration de Subversion

l'interface RA d'un ct et qui communique avec le dpt de l'autre. Votre nouvelle bibliothque peut utiliser des protocoles rseaux existants ou vous pouvez en inventer de nouveaux. Vous pouvez ainsi utiliser les communications inter-processus (IPC pour interprocess communication en anglais) ou mme, soyons fou, implmenter un protocole bas sur l'email. Subversion apporte les API, vous d'apporter la crativit.

Couche client
Ct client, tout se passe dans la copie de travail Subversion. Le gros des fonctionnalits implmentes par les bibliothques client existe dans le seul but de grer les copies de travail locales des rpertoires pleins de fichiers et d'autres sousrpertoires qui sont une sorte de copie locale et modifiable d'un ou plusieurs dpts et de propager les changements vers et depuis la couche d'accs au dpt. La bibliothque de Subversion pour la copie de travail, libsvn_wc, est directement responsable de la gestion des donnes dans les copies de travail. Pour ce faire, la bibliothque stocke dans un sous-rpertoire spcial des donnes d'administration concernant chaque rpertoire suivi en versions. Ce sous-rpertoire, nomm .svn, est prsent dans chaque rpertoire d'une copie de travail ; il contient tout un tas de fichiers et de rpertoires qui enregistrent l'tat du rpertoire suivi en versions et fournit un espace priv pour les actions d'administration. Pour les habitus de CVS, ce sous-rpertoire .svn a des objectifs similaires aux rpertoires administratifs CVS que l'on trouve dans les copies de travail CVS. Pour plus d'informations sur la zone d'administration .svn, reportez-vous la section intitule Au cur de la zone d'administration de la copie locale plus loin dans ce chapitre. La bibliothque client de Subversion, libsvn_client, est celle qui a le plus de responsabilits : son rle est de mlanger les fonctionnalits de la bibliothque de la copie de travail avec celles de la couche d'accs au dpt (RA) afin de fournir l'API de plus haut niveau, utilisable par n'importe quelle application qui voudrait effectuer des actions gnrales de gestion de versions. Par exemple, la fonction svn_client_checkout() prend une URL en argument. Elle passe cette URL la couche RA et ouvre une session authentifie avec le dpt concern. Elle demande ensuite au dpt l'arborescence requise, envoie cette arborescence la bibliothque de la copie de travail, qui crit alors une copie de travail complte sur le disque (les rpertoires .svn et tout le reste). La bibliothque client est conue pour tre utilise par n'importe quelle application. Alors que le code source de Subversion inclut un client standard en ligne de commande, le but recherch est qu'il soit trs facile d'crire un nombre quelconque de clients dots d'un environnement graphique (GUI en anglais) par-dessus cette bibliothque client. Il n'y a pas de raison que les nouveaux environnements graphiques (ou les nouveaux clients en fait) pour Subversion ne soient que des sur-couches au client en ligne de commande : ils ont un accs total, via l'API libsvn_client, aux mmes fonctionnalits, donnes et autres mcanismes que le client en ligne de commande utilise. En fait, le code source de Subversion contient un petit programme en C (que vous pouvez trouver dans tools/examples/minimal_client.c) qui montre comment utiliser en pratique l'API Subversion pour crer un programme client simple. Un mot sur la pertinence d'utiliser directement les bibliothques Pourquoi utiliser directement libsvn_client pour votre interface graphique plutt que d'encapsuler le programme en ligne de commande ? Non seulement c'est plus efficace, mais c'est aussi plus pertinent. Un programme en ligne de commande (tel que celui fourni avec Subversion) qui utilise la bibliothque client a besoin de traduire effectivement des requtes et des rponses contenues dans des variables en C en un affichage lisible par l'utilisateur. Ce type de traduction peut induire des pertes. C'est--dire que le programme n'affiche peut-tre pas l'ensemble des informations qu'il a obtenues de l'API ou qu'il combine peut-tre certaines informations pour obtenir une reprsentation plus compacte. Si vous encapsulez le programme en ligne de commande avec un autre programme, cette sur-couche n'a accs qu' des informations dj interprtes (et, comme nous venons de le mentionner, potentiellement incompltes) et elle doit une nouvelle fois traduire ces informations vers son propre format de reprsentation des donnes. chaque couche d'encapsulation supplmentaire, l'intgrit des donnes originales s'effrite un peu plus, la manire d'une copie de copie (de copie ) d'une cassette audio ou vido. Mais l'argument dcisif quant l'utilisation directe des API plutt que d'encapsuler d'autres programmes est que le projet Subversion assure la compatibilit vis--vis de ses API. Lors des changements de version mineure des API (comme par exemple entre la version 1.3 et 1.4), aucun prototype de fonction ne change. En d'autres termes, vous n'tes pas forc de mettre jour le code source de votre programme simplement parce que vous avez mis jour votre version de Subversion. Certaines fonctions seront peut-tre obsoltes, mais elles fonctionneront toujours. Ainsi, cela vous laisse de la marge pour ventuellement adopter les nouvelles API. Ce type de promesse de compatibilit n'existe pas pour les sorties du programme Subversion en ligne de commande, qui sont susceptibles de changer chaque version.

200

Intgration de Subversion

Au cur de la zone d'administration de la copie locale


Comme nous l'avons dj mentionn, chaque rpertoire d'une copie de travail Subversion contient un sous-rpertoire spcial nomm .svn qui hberge les donnes administratives concernant le rpertoire de la copie de travail. Subversion utilise .svn pour grer des informations telles que : quel emplacement du dpt les fichiers et les sous-rpertoires du rpertoire de la copie de travail font rfrence ; quelle rvision de chacun de ces fichiers et rpertoires est prsente dans la copie de travail ; toute proprit dfinie et associe par l'utilisateur ces fichiers et rpertoires ; une copie locale originale des fichiers de la copie de travail. L'agencement et le contenu de la zone d'administration de la copie de travail Subversion sont considrs comme des dtails de l'implmentation non-destins tre exploits par les utilisateurs. Nous encourageons les dveloppeurs utiliser les API publiques ou les outils fournis avec Subversion pour accder aux donnes de la copie de travail et pour les manipuler, plutt que de lire et modifier directement ces fichiers. Les formats de fichiers employs par la bibliothque de la copie de travail pour grer les donnes administratives changent de temps en temps et l'API publique ralise un gros travail pour que l'utilisateur moyen ne s'en rende pas compte. Dans cette section, nous abordons crment certains dtails de l'implmentation pour satisfaire votre insatiable curiosit.

Le fichier entries
Le fichier entries est srement LE fichier le plus important du rpertoire .svn. Il contient l'essentiel des informations administratives concernant les lments suivis en versions du rpertoire de la copie de travail. Ce fichier contient l'URL du dpt, le numro de rvision original, les sommes de contrle des fichiers, les horodatages des copies originales et des proprits, les informations d'tat sur les conflits et les actions planifies, les dernires informations connues sur les propagations (auteur, numro de rvision et horodatage) et l'historique de la copie locale : pratiquement tout ce qui intresse un client Subversion propos d'un lment suivi (ou suivre) en versions ! Les lecteurs familiers avec les rpertoires administratifs de CVS auront tout de suite reconnu que le fichier .svn/entries a les mmes objectifs, entre autres choses, que l'ensemble des fichiers CVS/Entries, CVS/Root et CVS/Repository combins. Le format du fichier .svn/entries a chang au cours du temps. Au dpart, c'tait un fichier XML ; aujourd'hui, il utilise un format personnalis mais toujours lisible par l'utilisateur. Le choix d'XML tait particulirement adapt pour les premiers dveloppeurs de Subversion qui dboguaient frquemment le contenu du fichier (et le comportement associ de Subversion). Cependant, le besoin de dbogage a diminu au fur et mesure que Subversion devenait plus mature et le besoin de performance au profit de l'utilisateur a alors pris le dessus. Soyez conscient que la bibliothque Subversion de la copie de travail met automatiquement niveau les copies de travail d'un format un autre elle comprend les vieux formats et utilise pour l'criture le nouveau format ce qui vous pargne l'effort d'extraire une nouvelle copie de travail mais peut aussi compliquer certaines situations : lorsque diffrentes versions de Subversion essaient de partager la mme copie de travail.

Copies originales et proprits des fichiers


Comme mentionn auparavant, le rpertoire .svn contient aussi les copies originales (avant modification locale) des fichiers : les versions de base (text-base versions en anglais). Vous pouvez les trouver dans le rpertoire .svn/text-base. Ces copies originales offrent tout un tas d'avantages identification des diffrences et des modifications, retour en arrire sur les fichiers modifis ou supprims, tout cela sans faire appel au rseau ; changes plus performants avec le serveur mais au prix d'avoir chaque fichier stock au moins en double sur le disque. De nos jours, c'est pratiquement ngligeable pour la majorit des fichiers. Cependant, la situation se dtriore mesure que vos fichiers suivis en versions grossissent. Nous tudions dornavant la possibilit de rendre optionnelle la prsence de ces versions de base . Cependant, c'est justement quand vos fichiers suivis en versions grossissent que l'existence des versions de base devient cruciale : qui a envie de transmettre un norme fichier travers le rseau juste parce qu'il veut propager une petite modification ? Dans le mme esprit que les fichiers versions de base , nous avons les fichiers de proprits qui, eux aussi, possdent leurs 201

Intgration de Subversion

copies originales proprits en version de base , situs respectivement dans .svn/props et .svn/prop-base. Comme les rpertoires aussi peuvent avoir des proprits, il existe galement des fichiers .svn/dir-props et .svn/dir-prop-base.

Utiliser les API


Dvelopper des applications utilisant les API des bibliothques Subversion est plutt simple. Subversion est d'abord un ensemble de bibliothques en langage C, avec des fichiers d'en-ttes (.h) situs dans le rpertoire subversion/include de l'arborescence des sources. Ces en-ttes sont copis dans votre arborescence systme (par exemple / usr/local/include) quand vous compilez et installez Subversion partir des sources. Ces en-ttes contiennent l'ensemble des fonctions et des types censs tre accessibles aux utilisateurs des bibliothques Subversion. La communaut des dveloppeurs Subversion apporte beaucoup d'attention la disponibilit et la qualit de la documentation des API publiques reportez-vous directement aux fichiers d'en-ttes pour cette documentation. Quand vous examinez les fichiers d'en-tte publics, la premire chose que vous remarquez est que les types de donnes et les fonctions ont un espace de nommage rserv. Cela veut dire que tous les noms de symboles Subversion publics commencent par svn_, suivi d'un code indiquant la bibliothque dans laquelle le symbole est dfini (par exemple wc, client, fs, etc.), suivi d'un unique caractre soulign (_) puis du reste du nom du symbole. Les fonctions semi-publiques (utilises par plusieurs fichiers au sein d'une bibliothque mais pas par du code extrieur cette bibliothque, on peut les trouver au sein des rpertoires de la bibliothque) suivent une rgle de nommage lgrement diffrente dans le sens o, au lieu d'un unique caractre soulign aprs le code indiquant la bibliothque, elles utilisent deux caractres soulign conscutifs (_ _). Les fonctions qui sont propres un fichier source (c'est--dire prives) n'ont pas de prfixe particulier et sont dclares avec le motcl static. Bien sr, un compilateur n'a que faire de ces conventions de nommage, mais elles sont une aide prcieuse pour clarifier la porte d'une fonction ou d'un type de donnes particuliers. Une autre bonne source d'informations sur la programmation avec les API Subversion est constitue par les bonnes pratiques de programmation au sein du projet lui-mme, que vous pouvez trouver l'adresse suivante http://subversion.apache.org/docs/community-guide/ (pages en anglais). Ce document contient des informations particulirement utiles qui, bien que destines aux dveloppeurs (ou aux personnes dsireuses de le devenir) de Subversion luimme, peuvent galement servir tous ceux qui dveloppent des applications utilisant Subversion comme bibliothque tierce 2 .

APR, la bibliothque Apache de portabilit des excutables


ct des types de donnes propres Subversion, vous trouverez de nombreuses rfrences des types de donnes qui commencent par apr_ : ce sont les symboles de la bibliothque pour la portabilit d'Apache (Apache Portable Runtime en anglais, soit APR). APR est un jeu de bibliothques Apache, originellement extraites du code source du serveur pour essayer de sparer ce qui dpendait du systme d'exploitation de ce qui n'en dpendait pas. Au final, on obtient une bibliothque qui fournit une API permettant d'effectuer des oprations qui changent un peu (ou beaucoup) en fonction du systme d'exploitation. Alors que le serveur HTTP Apache tait le premier utilisateur (et pour cause) de la bibliothque APR, les dveloppeurs Subversion ont immdiatement peru les avantages qu'il y a utiliser APR. Cela signifie qu'il n'y a pratiquement aucun code spcifique un systme d'exploitation dans Subversion en tant que tel. Cela veut aussi dire que le client Subversion peut tre compil et excut partout o un serveur Apache peut l'tre. Actuellement, cette liste comprend toutes les variantes d'Unix, Win32, BeOS, OS/2 et Mac OS X. En plus de fournir des implmentations fiables des appels systmes qui diffrent d'un systme d'exploitation l'autre 3, APR fournit Subversion un accs direct de nombreux types de donnes personnaliss tels que les tableaux dynamiques et les tables de hachage. Subversion utilise abondamment ces types de donnes et le type de donnes APR le plus utilis, que l'on retrouve dans presque tous les prototypes de l'API Subversion, est apr_pool_t le rservoir de mmoire (memory pool en anglais) APR. Subversion utilise les rservoirs de mmoire en interne pour tous ses besoins d'allocation mmoire ( moins qu'une bibliothque externe ne require un autre mcanisme de gestion de la mmoire pour les donnes transmises via son API) 4 et, bien qu'une personne qui utilise l'API Subversion ne soit pas oblige d'en faire autant, elle doit fournir des rservoirs aux fonctions de l'API qui en ont besoin. Cela implique que les utilisateurs de l'API Subversion doivent galement inclure l'APR lors de l'dition de liens, doivent appeler apr_initialize() pour initialiser le sous-systme APR et doivent ensuite crer et grer des rservoirs de mmoire pour les appels l'API Subversion, gnralement en utilisant svn_pool_create(), svn_pool_clear() et svn_pool_destroy().

2 Aprs tout, Subversion utilise aussi les API Subversion. 3 Subversion utilise les appels systme et les types de donnes 4

ANSI autant que possible.

Neon et Berkeley DB par exemple.

202

Intgration de Subversion

Programmer avec les rservoirs de mmoire Presque tous les dveloppeurs qui ont essay le langage C se sont heurts la tche dantesque de gestion de la mmoire. Allouer suffisamment de mmoire pour l'excution, garder une trace de ces allocations, librer la mmoire quand elle n'est plus utilise ces tches peuvent devenir particulirement complexes. Et, bien sr, si cette gestion est mal faite, cela peut conduire un plantage du programme, voire de l'ordinateur. Les langages de plus haut niveau, quant eux, soit vous dbarrassent compltement de cette tche, soit vous laissent jouer avec uniquement quand vous faites des optimisations particulirement pointues de votre programme. Des langages tels que Java ou Python utilisent un ramasse-miettes (garbage collector en anglais) qui alloue de la mmoire aux objets en cas de besoin et la libre automatiquement quand l'objet n'est plus utilis. APR fournit une approche mi-chemin appele gestion de mmoire par rservoir. Cela permet au dveloppeur de contrler l'utilisation de la mmoire une rsolution plus faible par morceau (dit rservoir ) de mmoire au lieu d'une gestion par objet. Plutt que d'utiliser malloc() et compagnie pour allouer la mmoire un objet donn, vous demandez APR d'allouer de la mmoire l'intrieur d'un rservoir de mmoire. Quand vous avez fini d'utiliser les objets que vous avez crs dans un rservoir, vous dtruisez le rservoir tout entier, ce qui libre effectivement la mmoire consomme par tous les objets allous. Ainsi, plutt que de grer individuellement la mmoire qui doit tre alloue et libre pour chaque objet, votre programme n'a plus qu' se proccuper de la dure de vie globale des objets et alloue ces objets dans un rservoir dont la dure de vie (le temps entre la cration et la suppression du dit rservoir) correspond aux besoins des objets.

Prrequis pour les URL et les chemins


Subversion a t conu pour effectuer distance des oprations de gestion de versions. ce titre, les possibilits d'internationalisation (i18n) ont fait l'objet d'une attention toute particulire. Aprs tout, distance peut vouloir dire depuis un ordinateur situ dans le mme bureau , mais aussi l'autre bout de la plante . Pour faciliter cette prise en compte, toutes les interfaces publiques de Subversion qui acceptent des chemins comme argument s'attendent ce que ces chemins soient rendus canoniques la faon la plus facile de le faire tant de les passer en argument la fonction svn_path_canonicalize() et cods dans le format UTF-8. Cela signifie, par exemple, que tout nouveau programme client qui pilote l'interface libsvn_client doit d'abord convertir les chemins depuis le codage local vers UTF-8 avant de fournir ces chemins la bibliothque Subversion, puis doit reconvertir tout chemin renvoy par Subversion vers le codage local avant d'utiliser ce chemin des fins externes Subversion. Heureusement, Subversion fournit un ensemble de fonctions (voir subversion/include/svn_utf.h) que tout programme peut utiliser pour raliser ces conversions. De plus, les API Subversion demandent que toutes les URL passes en paramtres respectent le format URI. Ainsi, au lieu de dsigner par file:///home/utilisateur/Mon fichier.txt l'URL d'un fichier nomm Mon fichier.txt situ dans le rpertoire home/utilisateur, vous devez utiliser file:///home/utilisateur/Mon%20fichier.txt. L encore, Subversion fournit des fonctions utiles votre application svn_path_uri_encode() et svn_path_uri_decode() pour coder et dcoder, respectivement, des URI.

Utiliser d'autres langages que C et C++


Si vous dsirez utiliser les bibliothques Subversion partir d'un autre langage que le C (par exemple un programme Python ou Perl), Subversion offre cette possibilit via le gnrateur simplifi d'interface et d'encapsulation (Simplified Wrapper and Interface Generator ou SWIG en anglais). Les interfaces SWIG de Subversion sont situes dans le rpertoire subversion/ bindings/swig. Elles sont toujours en cours d'volution mais sont utilisables. Elles vous permettent d'appeler les fonctions de l'API Subversion indirectement, en utilisant des interfaces qui traduisent les types de donnes natifs de votre langage de programmation vers les types de donnes utiliss par les bibliothques C de Subversion. Des efforts significatifs ont t fournis pour produire des interfaces SWIG pleinement fonctionnelles pour Python, Perl et Ruby. D'une certaine manire, le travail effectu pour raliser les interfaces vers ces langages est rutilisable pour produire des interfaces vers d'autres langages supports par SWIG (ce qui inclut, entre autres, des versions de C#, Guile, Java, MzScheme, OCaml, PHP et Tcl). Cependant, vous aurez besoin d'un peu de programmation supplmentaire pour aider SWIG faire les traductions entre les langages pour les API complexes. Pour plus d'informations sur SWIG lui-mme, visitez le site Web du projet l'adresse suivante : http://www.swig.org/ (site en anglais). Subversion fournit galement une interface vers le langage Java. L'interface javahl (situe dans subversion/ 203

Intgration de Subversion

bindings/java dans l'arborescence des sources Subversion) n'est pas base sur SWIG mais est un mlange de Java et de JNI cod la main. Javahl couvre le plus gros des API du client Subversion et se destine principalement aux dveloppeurs d'environnements de dveloppement intgrs (IDE) et de clients Subversion en Java. Les interfaces Subversion vers les langages de programmation ne sont pas suivies avec le mme niveau d'exigence que les modules du cur de Subversion, mais peuvent gnralement tre utilises en production. De nombreuses applications, de nombreux scripts, des clients graphiques alternatifs et des outils tiers utilisent aujourd'hui sans problme les interfaces vers les langages de programmation afin d'intgrer les fonctionnalits de Subversion. Veuillez tout de mme noter qu'il existe d'autres options pour s'interfacer avec Subversion dans d'autres langages : les interfaces pour Subversion qui ne sont pas fournies par la communaut de dveloppement Subversion. Vous pouvez trouver des liens vers ces interfaces alternatives sur la page de liens externes du projet Subversion ( l'adresse http://subversion.tigris.org/links.html) et, en particulier, nous accordons une mention spciale deux d'entre elles. D'abord, l'interface PySVN de Barry Scott (http://pysvn.tigris.org/) est une interface reconnue vers Python. PySVN se targue d'une interface plus pythonique que les API orientes C fournies par l'interface standard de Subversion vers Python. Et si vous recherchez une implmentation 100 % Java de Subversion, jetez un il SVNKit (http://svnkit.com/), qui est une rcriture complte de Subversion en Java. SVNKit ou javahl ? En 2005, une petite entreprise du nom de TMate annonait la sortie de la version 1.0.0 de JavaSVN une implmentation 100 % Java de Subversion. Depuis, le projet a t renomm en SVNKit (disponible sur le site http://svnkit.com/) et connat un grand succs en tant intgr dans de nombreux clients Subversion, IDE ou autres outils tiers. La bibliothque SVNKit est intressante dans le sens o, contrairement la bibliothque javahl, elle ne se contente pas d'encapsuler les bibliothques officielles du cur de Subversion. En fait, elle ne partage aucun code avec Subversion. Cependant, bien qu'il soit facile de confondre SVNKit et javahl, et mme encore plus facile de ne pas savoir laquelle de ces bibliothques vous utilisez, vous devez tre conscient que SVNKit diffre de javahl sur certains points particulirement importants. D'abord, SVNKit n'est pas un logiciel libre et il semble qu'il ne soit dvelopp que par une quipe de quelques personnes. La licence de SVNKit est aussi plus restrictive que celle de Subversion. Enfin, en voulant tre une bibliothque Subversion crite uniquement en Java, SVNKit est limit dans sa capacit cloner les fonctionnalits de Subversion au fur et mesure de la sortie de nouvelles versions de ce dernier. Ce problme est dj apparu une fois : SVNKit ne peut pas accder des dpts Subversion utilisant une base de donnes BDB via le protocole file:// car il n'existe pas d'implmentation 100 % Java de Berkeley DB qui soit compatible avec le format de fichier de l'implmentation native de cette bibliothque. Ceci dit, SVNKit est unanimement reconnu pour sa fiabilit. Et une solution 100 % Java est beaucoup plus robuste vis-vis des erreurs de programmation : un bogue dans SVNKit gnre une exception Java que vous pouvez intercepter, tandis qu'un bogue dans une bibliothque du cur de Subversion utilise par javahl peut mettre par terre tout votre environnement d'excution Java. En conclusion, pesez le pour et le contre avant de choisir une implmentation en Java de Subversion.

Exemples de code
L'Exemple 8.1, Utilisation de la couche dpt contient un bout de code (crit en C) qui illustre plusieurs concepts que nous venons d'aborder. Il utilise la fois l'interface du dpt et celle du systme de fichiers (comme dnot par les prfixes svn_repos_ et svn_fs_ des noms de fonctions) pour crer une nouvelle rvision da