Subversion, un outil de gestion de version Florent Guilleux, Comité Réseau des Universités TutoJRES 01, Juin 2006 Présentation pratique de Subversion à l’intention des débutants en gestion de version et des utilisateurs de CVS. Je n’aborde que les aspects clients. Ce n’est pas une présentation exhaustive des possibilités de Subversion, mais une présentation des concepts les plus importants et des bonnes pratiques les plus utiles. L’idée est découvrir rapidement les fonctionnalités offertes par Subversion et leur utilisation concrète pour de la gestion de version. Je commence par une introduction non technique.

Le développement de logiciel est une tâche complexe Mode de développement ouvert : contributeurs extérieurs relations à distance (mail, IRC, etc.) Gestion des diffusions (releases, correctifs de sécurité, etc.) Dépendances multiples (bibliothèques) … Depuis toujours (cf. le nombre de bogues qui ne semble pas décroître et l’insatisfaction des clients). Le développement de logiciel a été simplifié par l’apparition de nouveaux langages plus haut niveau, l’utilisation de méthode formelle de développement, etc. mais a aussi été en même temps complexifié par l’évolution de l’environnement informatique.

De nombreux outils à l’aide du développeur Les IDE L’automatisation de tests Les gestionnaires de bogues, de demandes de fonctionnalités Les générateurs de documentation Les systèmes de gestion de version

Le versionning apporte de nombreux gains Retours en arrière et corrections toujours possibles Historique de toutes les opérations Indispensable pour le travail en équipe Travaux en parallèle sur plusieurs branches Pour du code mais aussi un site web, de la doc… Dans le reste de la présentation, je présente Subversion dans le contexte du développement logiciel. Je parle donc de développeurs

… qui justifient l’effort de prise en main trunk patch commit version modules diff merge tag branches BASE repository update conflict HEAD check out

Subversion est un outil fiable et puissant CVS sans les défauts + de nouvelles fonctionnalités Prise en main aisée, excellentes documentations Open source, disponible sur de nombreuses plate formes Éprouvé et fiable Subversion gère son propre code depuis septembre 2001 et la version 1.O a été diffusée en septembre 2004. Subversion est utilisé par la fondation Apache (pour tous ses projets), KDE, GCC, Python, Samba, Zope, Plone…

À qui profite la Subversion ? Pour les développeurs utilisation complète Pour les utilisateurs « avancés » (ou impatients) du produit export, récupération de patchs Pour les utilisateurs finaux du produit pas d’utilisation de Subversion

Pour les utilisateurs de CVS les commits sont atomiques les numéros de révision sont différents les répertoires et méta données sont versionnés une vraie commande move status, diff et revert sont des opérations déconnectées … http://svnbook.red-bean.com/en/1.0/apa.html Les commits sont atomiques : ils s’appliquent intégralement dans le référentiel ou pas. Il n’y a pas d’état intermédiaire ou un commit serait à moitié appliqué par exemple. Un numéro de révision une arborescence complète dans le référentiel. La commande move permet de renommer un fichier sans perdre son historique.

Concepts et opérations de base Travailler à plusieurs avec Subversion Gérer les diffusions : étiquettes et branches Opérations avancées Divers

Un référentiel central et une copie de travail trunk/ 1 2 3 svn checkout svn commit svn commit Copie de travail d’Alice Je travaille en local, dans une copie de travail. Pour obtenir une copie de travail, j’utilise la commande checkout pour récupérer le contenu du dépôt central. Je peux ensuite reporter les modifications que j’ai faites dans ma copie de travail dans le dépôt central avec la commande commit. Les commits sont atomiques : soit ils sont appliqués, soit ils ne le sont pas, on est jamais dans un état intermédiaire non désiré. Au niveau du dépôt est créée une nouvelle révision, à laquelle est affecté un numéro de révision. Ce numérotage permet d’identifier les versions successives stockées au cours du temps dans le dépôt. Il est possible d’effectuer un commit pour un fichier ou un ensemble de fichiers. Un numéro de version désigne l’ensemble du dépôt, et non pas un fichier individuel. (différence avec CVS). La révision n est l’état du dépôt après n modifications qui y ont été affectées. Un fichier peut donc être identique entre deux révisions. Dans les clients graphiques (TortoiseSVN, Subclipse…) n’apparaissent pas explicitement les noms de commandes mentionnés dans cette présentation. Ils sont « cachés » sous la forme de menus. alice$work > svn co http://subversion.example.com/myProject/trunk myProject alice$work > svn commit myProject alice$work > svn commit myProject/file1.pl

Que faut-il enregistrer dans un référentiel ? tout ce qui peut est susceptible de changer au cours du temps le code + ce qui sert au déploiement de l’appli (scripts d’installation par exemple) la documentation du produit sauf ce qui peut être généré automatiquement (JavaDoc par exemple) éviter ce qui peut être généré automatiquement (JavaDoc par exemple) sauf si cela affranchit les utilisateurs d’installer un outil pour genérer ces élements

Récupérer n’importe quelle révision : svn checkout Par un numéro de révision alice$work > svn co –r 2 http://subversion.example.com/myProject myProject A myProject/trunk/file1.pl A myProject/trunk/file2.pl Checkout revision 2. Par une date alice$work > svn co –r {2006-01-15} http://subversion.example.com/myProject A myProject/trunk/file1.pl A myProject/trunk/file2.pl Checkout revision 1. Mettre à jour une copie locale : svn update Pour récupérer une copie de travail : svn checkout URL. Par défaut on récupère la dernière révision du référentiel. Il est possible de récupérer une révision donnée, ou à une date donnée. Attention quand on spécifie une date, le serveur Subversion va rendre la dernière révision précédant la date. Toutes les commandes acceptant l’option –r permettent l’utilisation d’une date. Cette commande checkout rapatrie des méta données qui permettront de manipuler la copie locale avec un client Subversion. La commande export permet de récupérer une révision dans un état « épuré », sans les méta information Subversion. alice$work > svn update myProject U myProject/file1.pl U myProject/file2.pl Updated to revision 3.

Connaître l’origine de sa copie locale : svn info alice$work > svn info myProject Path: myProject URL: http://subversion.example.com/myProject/trunk Repository UUID: d6959e13-b0o4-0673-7u654-a2v3e0b6c323 Revision: 2 Node Kind: directory Schedule: normal Last Changed Author: alice Last Changed Rev: 2 Last Changed Date: 2006-02-14 12:07:15 […]

Les autres opérations sur le référentiel svn add, copy, delete, move Référentiel trunk/ 3 4 svn checkout svn add svn commit Copie de travail d’Alice Un référentiel Subversion enregistre les versions successives d’une arborescence de fichiers (i.e. des fichiers et des répertoires). Il est possible de d’ajouter, copier, supprimer, déplacer et renommer des éléments (fichiers, répertoires) dans une copie de travail avec les commandes add, copier, delete, mkdir, move (ou rename). Un fichier modifié n’a pas besoin d’être signalé à Subversion qui le détecte automatiquement. On applique ces modifications dans le référentiel avec un commit car toutes ces opérations sont versionnées. Tout ce qui modifie le référentiel produit une nouvelle révision. On peut appliquer ces opérations directement sur le référentiel en spécifiant des URL en argument, dans ce cas pas besoin de commit ensuite. Différence avec CVS : svn add et delete fonctionne sur les répertoires et les fichiers, et conservent l’historique des modifications, tout comme move alice$work > svn delete http://subversion.example.com/myProject/trunk/file2.pl alice$work > svn add myProject/file3.pl alice$work > svn commit myProject/file3.pl

Quand faut-il faire des commit ? Souvent Après avoir testé et validé ses modifications En groupant dans un commit les modifications qui correspondent à une même fonctionnalité Il ne faut pas hésiter à effectuer des commit régulier (c’est une opération peu coûteuse, seulement un diff des modifications est propagé vers le serveur). Cela permet de simplifier la gestion des conflits quand on travaille à plusieurs, et les développeurs peuvent mieux suivre l’activité des uns des autres. Il est souhaitable qu’un commit corresponde à une modification précise et limitée, et qui a un sens fonctionnel du point de vue de l’application.

Connaître l’état de sa copie locale : svn status alice$work > svn status myProject M myProject/file1.pl D + myProject/file2.pl A + myProject/file4.pl ? myProject/file5.pl ! myProject/file3.pl Référentiel trunk/ 3 Copie de travail d’Alice svn checkout 1 2 3 1 4 5 svn delete 4 svn add svn status permet de voir quels changements ont été appliqués à sa copie de travail depuis sa récupération. C’est utile avant d’appliquer un commit. Le signe + dans la quatrième colonne indique que l’ajout et la suppression de ces fichiers est prévu dans le prochain commit. ? désigne un élément qui n’était pas dans la copie de travail lors de son checkout ! désigne un élément qui manque alors qu’il était présent dans la copie de travail Différence avec CVS : la sortie de status est lisible, donc à préférer à un update -n.

Les messages de journal (logs) A chaque commit est associé un message de journal alice$work > svn commit –m ‘chgt de $regexp’ myProject/file1.pl Le message doit indiquer pourquoi cette modification a été appliquée À chaque modification du référentiel (commit) doit être associé un message de journal (via l’appel d’un éditeur ou en option dans l’appel en ligne de commande) Un message de journal doit permettre de comprendre pourquoi cette modification a été faite. Il est inutile de dire ce qui changé car Subversion nous permettra de le retrouver. S’il s’agit d’une correction de bug, on peut référencer le numéro du bug report dans le message de journal. -m ‘Désormais on whitelist le format des paramètres CGI’

Connaître l’historique des modifications : svn log alice$work > svn log myProject/file1.pl ------------------------------------------------------ r3 | Alice | 2006-03-09 16:43:22 (Thu, 9 Mar 2006) Ajout de la gestion des sessions r2 | Alice | 2006-02-01 09:34:12 (Wed, 01 Feb 2006) Désormais on whitelist le format des paramètres CGI r1 | Alice | 2006-01-10 09:34:12 (Tue, 10 Jan 2006) Import initial alice$work > svn log –r 2 –v myProject/file1.pl ------------------------------------------------------ r2 | Alice | 2006-02-01 09:34:12 (Wed, 01 Feb 2006) Changed paths: M myProject/file1.pl M myProject/file2.pl Désormais on whitelist le format des paramètres CGI svn log renvoie tous les messages de journaux. Il est possible de spécifier une révision donnée, un intervalle entre deux révisions. L’option verbose indique quels sont les fichiers modifiés (ou ajoutés, supprimés, etc.) pour chaque révision

Connaître les modifications : svn diff Adresses Jean jean@example.com David david@example.com Email Jean jean@example.com Contacts.txt Contacts.txt (copie de travail) 1 svn diff Contacts.txt Index: Contacts.txt ================ --- Contacts.txt (revision 1) +++ Contacts.txt (working copy) @@ -1,2 +1,3 @@ - Email + Adresses Jean jean@example.com + David david@example.com svn diff donne les différences entre deux révisions du référentiel. On peut spécifier aussi des dates ou utiliser des mots clés.

HEAD, BASE, COMMITED, PREV Référentiel HEAD trunk/ 1 2 3 4 5 PREV COMMITED svn checkout Copie de travail d’Alice BASE Ce sont des mots clés pour désigner les révisions. HEAD correspond à la dernière révision du référentiel. BASE, COMMITED et PREV n’ont de sens que dans une copie locale. svn diff –r BASE montre les modifications effectuées depuis le checkout svn diff –r BASE:HEAD file1.pl montre les différences entre la révision du checkout et la version actuelle du référentiel svn diff –r PREV:COMMITED file1.pl montre la dernière modification apportée à file1.pl enregistrée par commit alice$myProject > svn diff –r PREV:COMMITED file1.pl alice$myProject > svn diff –r BASE:HEAD file1.pl alice$myProject > svn diff file1.pl

svn diff permet de créer des patch dave$myProject > svn diff file1.pl > Dave.patch alice$myProject > patch –p0 -i Dave.patch Parfois on a pas les droits en écriture sur un référentiel. Pour reporter des modifications au référentiel et à son propriétaire, on utilise la commande diff pour générer un patch. Il utilisera la commande patch pour appliquer les modifications et éventuellement les commiter dans le référentiel

Annuler des modifications dans la copie de travail Référentiel trunk/ 1 2 svn checkout svn commit Copie de travail d’Alice svn revert svn revert permet d’annuler les modifications apportées à sa copie locale : svn revert file.txt Pour l’appliquer à l’ensemble de sa copie locale : svn revert --recursive . alice$work > svn revert myProject/File1.pl Reverted ‘File1.pl’

Annuler des modifications dans le référentiel trunk/ 419 svn commit 215 216 418 svn checkout svn merge Cette opération de merge n’est qu’un outil technique qui ne peut pas résoudre des problèmes complexes : elle n’affranchit pas de la réflexion pour identifier précisément quelles révisions il faut fusionner pour annuler quelque chose dans le réferentiel. svn merge –r216:215 File1.pl svn log File1.pl ; svn diff –r 215:216 File1.pl

Concepts et opérations de base Travailler à plusieurs sur un référentiel Gérer les diffusions : étiquettes et branches Opérations avancées Divers

Des conflits peuvent survenir Copie de travail de Bob svn commit svn checkout Référentiel 2 trunk/ 1 svn checkout svn commit Copie de travail d’Alice Deux personnes peuvent avoir récupéré des copies locales du référentiel, y apporter des modifications et les reporter dans le référentiel. Ces modifications concerner les mêmes fichiers et peuvent donc être incompatibles. Or Subversion ne permet pas* à un utilisateur de verrouiller des éléments du référentiel. Comment s’organiser pour gérer ces conflits potentiels, et que nous propose Subversion pour nous aider dans cette tâche ? Différence avec CVS : Subversion ne permet pas de commiter un fichier noté en conflit. Il faut d’abord explicitement lui signaler la résolution du conflit avec la commande svn resolved. * en fait si, Subversion 1.2 le permet

Résolution des conflits Copie de travail de Bob svn update svn commit svn checkout Référentiel trunk/ 1 2 svn checkout svn commit Copie de travail d’Alice Quand on veut commiter un fichier qui a changé dans le référentiel depuis son checkout, l’opération échoue : « commit failed » en indiquant que notre fichier local n’était plus à jour avec la version du référentiel. Il faut mettre à jour son fichier avec la version du référentiel avec la commande svn update*. Cette dernière fait un merge entre notre version locale et celle du référentielle. Il y a alors deux cas de figures : Subversion a réussi à fusionner les deux versions car les modifications ne concernaient pas les mêmes lignes (état «Merged ») Subversion n’a pas réussi à fusionner les deux versions car les modifications concernaient les mêmes lignes (état « conflict ») * Attention pour les utilisateurs de CVS : ne plus utiliser update pour visualiser les changements apportés en local, mais svn status. Svn update met à jour le référentiel et n’affiche pas les modifications locales. bob$myProject > svn commit File1.pl Sending File1.pl svn: commit failed (details follow): svn: Out of date: ‘/myProject/File1.pl’ in transaction ‘4’ bob$myProject > svn update File1.pl G File1.pl Updated to revision 2

Si les modifications concernent des lignes différentes État « merGed » : G Bob Zéro Un Deux Trois Quatre Zéro Un Deux Trois QUATRE svn commit svn update Zéro Un Deux Trois QUATRE Un Deux Trois Quatre Un Deux Trois QUATRE [enchaînement des commandes à réaliser] Alice

Si les modifications concernent les mêmes lignes État « Conflict » : C Un <<<< .mine Two ==== Dos >>>> .r2 Deux Trois QUATRE Un Two Trois Quatre svn update Un Deux Trois Quatre Un Dos Trois QUATRE File1.pl File1.pl.mine File1.pl.r2 File1.pl.r1 Subversion n’est pas capable de déterminer quelle fusion réaliser quand les modifications concernent les mêmes lignes. Les développeurs concernés doivent communiquer entre eux pour résoudre à la main dans le fichier les éléments qui sont en conflit. Si l’on considère que le conflit peut être résolu seul, on peut utiliser les fichiers .mine, .r2, .r1 pour écraser le fichier courant.

Si les modifications concernent les mêmes lignes Un <<<< .mine Two ==== Dos >>>> .r2 Trois QUATRE Un Two Trois QUATRE Un Two Trois QUATRE résolution manuelle svn resolved svn commit Un Two Trois QUATRE État « Conflict » : C Subversion n’est pas capable de déterminer quelle fusion réaliser quand les modifications concernent les mêmes lignes. Les développeurs concernés doivent communiquer entre eux pour résoudre à la main dans le fichier les éléments qui sont en conflit. La commande resolved indique à Subversion que le conflit est résolu.

Cycle de travail typique 1. Mettre à jour sa copie de travail svn update 5. Enregistrer ses modifications svn commit 2. Apporter des modifications svn add / copy / delete / move 4. Fusionner les modifications svn merge / resolved 3. Visualiser les modifications svn status (-u) / diff / revert Le premier update permet de mettre à jour sa copie de travail pour y inclure les dernières modifications des autres développeurs. Des éléments peuvent avoir été modifiés (U), ajoutés (A), supprimés (D), remplacés (R), fusionnés (G), ou être en conflits (C). Ensuite on peut travailler dans sa copie locale pour ajouter une nouvelle fonctionnalité, corriger une bogue, etc. Il est préférable de choisir avant de commencer ce que l’on va faire exactement. On peut éditer des fichiers, en ajouter, supprimer, changer l’arborescence, etc. Avant de commiter ces modifications, il est bon de revoir ce que l’on a fait. La commande status permet de voir tout ce qui a été modifié, et diff les modifications exactes. Revert permet de corriger des erreurs. Ces commandes ne consultent pas le référentiel, car la copie de travail a un cache de la version BASE. On a ainsi la possibilité de travailler sur les étapes 2 et 3 en mode déconnecté (c’est une différence avec CVS). Cela permet aussi au commit de n’être qu’une transmission des différences et non de l’ensemble de la copie locale. svn status –u permet de voir le status de sa copie locale par rapport au serveur et de détecter des éléments qui ne seraient déjà plus à jour par rapport au référentiel. Les commandes update et resolved permettent de résoudre les conflits potentiels (voir les diapos précédentes). Enfin svn commit permet d’enregistrer dans le référentiel ses modifications.

Concepts et opérations de base Travailler à plusieurs sur un référentiel Gérer les diffusions : étiquettes et branches Opérations avancées Divers Différence avec CVS : la gestion des branches et étiquettes de Subversion est complètement différente de CVS. Ce sont en effet des répertoires ordinaires dans le référentiel. C’est sûrement le changement le plus difficile à assimiler pour un utilisateur de CVS, mais ce mode de fonctionnement est au final bien plus simple !

Une étiquette est un nom donné à une révision Référentiel REL-0.9 trunk/ 215 345 418 482 … … … Étiquettes REL-1.1a Les numéros de révision sont incrémentaux et à eux seuls ne permettent pas de distinguer les versions majeures d’un développement. Ils sont utiles pour les développeurs mais pas pour les utilisateurs finaux du produit. Une étiquette (ou tag) permet de nommer une révision avec un nom humainement lisible. On peut ainsi récupérer une révision du référentiel en utilisant l’étiquette. Une étiquette peut aussi désigner l’aggrégation de plusieurs parties du référentiel dans des révisions différentes (par exemple être le paquetage de plusieurs modules dans des états d’avancement différents). On récupère une étiquette comme une révision, à priori avec la commande export puisqu’on ne veut pas en faire une copie de travail.

Une étiquette est stockée comme une copie Référentiel trunk/ 418 482 215 345 … … … tags/REL-0.9 346 tags/ tags/REL-1.1a 483 On distingue souvent dans un référentiel Subversion plusieurs répertoires à la racine : trunk, tags et branches. Trunk stocke les révisions successives de la branche de développement principale. Tags stocke les différentes étiquettes qui sont des copies de révisions contenues dans trunk. Les étiquettes sont des instantanées du référentiel à certaines révisions, elles n’ont pas vocation à être modifiées : on n’effectue pas de commit dans tags. Elles sont stockées dans le référentiel comme des cheap copies, i.e. est réellement stockée uniquement ce qui diffère de l’original. On peut donc faire autant de tags que l’on souhaite, sans craindre pour l’espace disque du serveur. Une étiquette a un numéro de révision. Différence avec CVS : quand on veut récupérer la branche de développement principale, il faut spécifier trunk dans l’URL svn copy –r 345 http://subversion.example.com/myProject/trunk http://subversion.example.com/myProject/tags/REL-O.9 svn export http://subversion.example.com/myProject/tags/REL-0.9 svn mkdir http://subversion.example.com/myProject/tags

Exemple de diffusion d’une release 1. Utiliser la commande svn export (pas de méta données) svn export http://subversion.example.com/myProject/tags/REL-0.9 myProject 2. Faire un tar.gz du répertoire myProject 3. Le publier (web, FTP, etc.)

Empêcher les commit dans tags souvent inutile, convention entre les développeurs si nécessaire utiliser un « script associé » parfois des exceptions, par exemple une étiquette latest-build Il est possible de définir un script associé (voir plus loin) pour empêcher les commit dans tags, afin que les étiquettes ne soient plus modifiées après leur création. Mais souvent c’est inutile car un accord entre les développeurs suffit pour s’assurer que personne ne fasse de commit dans tags. Il peut exister des étiquettes qui seront modifiées au cours du temps, comme par exemple une étiquette contenant la dernière version compilée et testée.

Une branche est une autre ligne de développement Branche de correction de bogue BUG-2561 RB-O.8 Branche de diffusion trunk TRY-new_cache Ligne principale Une branche est une ligne de développement additionnelle, parallèle à la ligne principale (le trunk). De multiples utilisations des branches sont possibles : - Branche de diffusion : à l’approche de la publication d’une nouvelle version, une partie des développeurs finalise et stabilise la version, tandis que les autres développeurs continuent l’ajout de fonctionnalités dans le trunk. Branche de correction de bug : une branche peut être crée uniquement pour corriger un bug complexe. Elle sera ensuite mergée avec la branche de release correspondante et le trunk. Des tags marquant le début et la fin de la branche sont créés pour faciliter la fusions. Branche d’expérimentation : un développeur peut travailler profondément sur le code, pour introduire de nouvelles fonctionnalités ou modifier son architecture. Il lui faut une branche qui fasse office de « bac à sable » pour ne pas casser la ligne de développement principale. Les modifications apportées dans une branche peuvent être reportées dans une autre branche ou le trunk. Branche d’expérimentation

Une branche est stockée comme une copie Référentiel trunk/ 482 215 345 418 … … … … 216 217 branches/ RB-0.8 314 315 tags/ REL-0.8 Par convention les branches sont stockées dans le répertoire du référentiel branches. Une branche est une cheap copy du trunk ou d’une autre branche. On peut créer autant de branches que l’on souhaite. On utilise svn copy pour créer une branche. Comme pour une étiquette, cela incrémente le numéro de révision du référentiel. L’opération de copie conserve tout l’historique de l’arborescence d’où est issue la branche. Contrairement à une étiquette une branche a vocation à être modifiée. On utilise les mêmes commandes : svn checkout / update / commit / add etc. que dans le trunk. Tout s’applique dans la branche et non dans le trunk. Pour diffuser cette branche, il suffit d’en faire une copie dans tags. svn copy http://subversion.example.com/myProject/branches/RB-O.8 http://subversion.example.com/myProject/tags/REL-0.8 svn copy http://subversion.example.com/myProject/trunk http://subversion.example.com/myProject/branches/RB-0.8 svn co http://subversion.example.com/myProject/branches/RB-0.8

Le quotidien du subversif Camenbert non contractuel Camembert non contractuel

Propager la correction d’un bogue simple 1. Faire un checkout de la branche où le bogue a été détecté svn co http://subversion.example/myProject/branches/RB-0.8 […] Checked out revision 219 2. Corriger le bogue, tester le correctif 3. Enregistrer la correction dans le référentiel svn commit –m « correction du bogue #735 » […] Committed revision 220 4. Faire un checkout de la branche où appliquer le correctif svn co http://subversion.example/myProject/trunk 5. Y fusionner le correctif Un bogue corrigé dans une branche a souvent vocation à être reporté dans d’autres branches. Si le correctif est simple (i.e. réalisable en une opération commit), sa propagation dans d’autres branches aussi. svn merge -r 219:220 http://subversion.example/myProject/branches/RB-O.8 6. Appliquer le résultat dans le référentiel avec svn commit

Propager la correction d’un bogue complexe Créer une branche de correction de bug BUG-865 Créer une étiquette à partir de cette nouvelle branche, PRE-865. Corriger le bug dans BUG-865. Plusieurs commit sont possibles. Quand le bug est corrigé dans BUG-865, créer une étiquette POST-865. Faire un checkout (ou update) de la branche à corriger Utiliser PRE-865 et POST-865 pour fusionner le correctif dans la branche à corriger : svn merge http://subversion.example/myProject/tags/PRE-865 http://subversion.example/myProject/tags/POST-865 7. Faire le commit pour appliquer la correction dans la branche

Concepts et opérations de base Travailler à plusieurs sur un référentiel Gérer les diffusions : étiquettes et branches Opérations avancées Divers Différence avec CVS : les opérations avancées présentées ici n’étaient pas possibles avec CVS (à confirmer ?)

Les propriétés

Les propriétés sont des méta données Associées à un fichier ou un répertoire Propriété = un nom + un contenu Définies et manipulées par les développeurs Elles sont versionnées Une propriété est une méta données associée à un fichier, répertoire ou une version. C’est un nom (une chaîne de caractère) associée à un contenu (de n’importe quel type, binaire par exemple). Elle permet d’enrichir le contenu d’un référentiel en associant des informations supplémentaires à ses éléments.

Exemples de propriétés Fichier vignette legende Picture1.jpg Coucher de soleil Picture2.jpg Forêt enneigée Picture3.jpg Collines brumeuses Si l’on gère le contenu d’un site Internet avec Subversion, on peut souhaiter associer à des photos des légendes et des vignettes. On peut le faire en stockant ces informations dans des fichiers séparés, pour lesquels il faudra trouver un moyen de garder l’association avec chaque fichier de photos correspondants (par exemple selon une convention de nommage sur les noms de fichier). L’exemple illustre le fait que l’on peut définir toutes les propriétés que l’on souhaite. Elles peuvent être exploitées par des commandes svn ou des bibliothèques de Subversion dans différents langages. Autre exemple de propriété : le nom du dernier relecteur d’un fichier de code

Manipuler des propriétés svn propset legende ‘Coucher de soleil’ Picture1.jpg property ‘legende’ set on Picture1.jpg svn propset vignette -F vignette1.jpg Picture1.jpg property ‘vignette’ set on Picture1.jpg svn status Picture1.jpg M Picture1.jpg svn proplist Picture1.jpg properties on ‘Picture1.jpg’ legende vignette svn propget legende Picture1.jpg Coucher de soleil Différentes commandes permettent de manipuler les propriétés d’un élément. La commande svn status indique en deuxième colonne si un élément a une nouvelle propriété ou une propriété modifiée. La commande propedit permettent de modifier une propriété, propdel d’en supprimer. Il faut effectuer un commit pour enregistrer une propriété dans le référentiel. Cela incrémente le numéro de révision du référentiel. Les propriétés de fichiers et répertoires sont versionnées : leur historique est consultable. Elles peuvent être l’objet de conflits tout comme la modification d’un fichier. svn propdel vignette Picture1.jpg propertuy ‘vignette’ deleted from ‘Pitcture1.jpg’ svn commit Picture1.jpg

Les propriétés particulières : svn:* svn:executable svn:mime-type text/xml, image/jpg, application/msword… svn:eof-style svn:keywords svn:ignore Les propriétés particulières ont un effet spécial sur le comportement de Subversion. Leur espace de nommage est svn: , il ne faut donc pas l’utiliser pour ses propres propriétés. svn:executable force le bit d’exécution sur les fichiers qui ont cette propriété (quelle que soit sa valeur) quand ils sont « check outer » (pas utile sous Windows). svn:mime-type indique quel est le type de contenu d’un fichier. Subversion n’affiche pas les diff des fichiers dont le svn:mime-type ne commence pas par text/ car il considère que ce sont des binaires. Il n’effectue pas non plus un merge quand on fait un update sur ces fichiers mais renomme votre version en .orig. Cette propriété est aussi utilisée par Apache quand on navigue avec un navigateur dans un référentiel Subversion. svn:eof facilite la gestion des fins de ligne différente entre différents systèmes d’exploitation. svn:keyword permet de substituer automatiquement des mots clés dans les fichiers par des valeurs. Svn:ignore permet à Subversion d’ignorer certains fichiers lors des commandes add ou status par exemple. Ainsi on peut ignorer les fichiers que l’on ne veut pas enregistrer dans le référentiel comme des fichiers temporaires, du code compilé, des fichiers de logs… Cette commande s’applique à un répertoire mais n’est pas récursive. svn propedit svn:ignore lib/ // en spécifiant par exemple la valeur *.bak

Définir automatiquement une propriété au niveau des clients, dans le fichier de configuration Subversion : enable-auto-props = yes [auto-props] *.jpg = svn:mime-type=image/jpg *.cpp = svn:eof-type=native pour ignorer des types de fichier : global-ignores = *.log

Les propriétés de transactions et révisions svn:log svn:date svn:author Elles sont éditables (mais pas par défaut) : svn propset --revprop –r 491 svn:log ‘correction bug #323’’ http://subversion.example.com/myProject property ‘svn:log’ set on repository revision ‘491’ Elles ne sont pas versionnées

Partage de code entre plusieurs projets

Un référentiel peut inclure du code d’un autre référentiel serveur Subversion common/ myProject/ trunk/ trunk/ doc/ doc/ lib/ svn:externals doc/ src/ lib/ common/ Au sein d’une institution plusieurs projets peuvent partager du code en commun, par exemple une bibliothèque. Plutôt que de dupliquer le code de cette bibliothèque dans les référentiels des différents projets (ce qui obligerait à synchroniser régulièrement ces copies), il est possible de le référencer (à la manière des liens symboliques d’un système d’exploitation). On utiliser pour cela la propriété svn:externals. Il est possible de référencer un référentiel hébergé sur un autre serveur.

Méthode pour utiliser svn:external svn co http://subversion.example/myProject/trunk myProject svn propset svn:externals ‘common http://subversion.exemple.com/common/trunk’ myProject property ‘svn:externals’ set on ‘myProject’ svn update myProject Fetching external item into ‘common’ A common/doc A common/lib Updated external to revision 21 Un svn status indique X pour les éléments insérés par un svn:external Attention : un commit sur une copie de travail incluant des externals ne met pas à jour ces externals s’ils ont été modifiés. Il faut faire un commit explicite sur les externals inclus dans la copie de travail. svn commit myProject

Les scripts associés

Un script associé est une action liée à un évènement enrichit le comportement de Subversion déclenchable lors d’une action sur le référentiel avant, pendant ou après un commit configuré au niveau du serveur Subversion

Exemples de scripts associés envoi d’un email de notification après chaque commit interdire les messages de journaux vides obliger à mentionner un numéro de bogue pour les messages de journaux d’une certaine branche enrichir les règles de contrôle d’accès déclencher une copie de sauvegarde du référentiel après chaque commit permettre la modification d’un message de journal sauvegarder les valeurs des propriétés non versionnées … Des modèles de scripts associés sont fournis dans la distribution de Subversion. Un script peut obtenir en entrée plusieurs données : auteur de la transaction, chemin d’accès au référentiel, message de journal, numéro de la révision créée, etc. La valeur de retour peut conditionner le succès ou non de l’opération déclenchant l’activation du script associé.

Le verrouillage dans Subversion

Ce verrouillage « optimiste » est souvent suffisant Les conflits sont rares dans la vie « réelle » Différents développeurs peuvent travailler sur les mêmes fichiers mais normalement pas sur les mêmes parties Différents développeurs peuvent travailler sur les mêmes fichiers mais normalement pas sur les mêmes parties : l’optimistic locking de Subversion est dans ce cas suffisant. Le strict locking engendre souvent des blocages inutiles, des retards et nécessitent du dialogue fastidieux entre développeurs pour obtenir le déverouillage de fichiers.

Le verrouillage dans Subversion 1.2 commande svn lock un fichier verrouillé a le status ‘K’ ou ‘O’ un commit réussi retire tous les verrous svn unlock est utilisable par tous les développeurs Subversion 1.2 permet à un utilisateur de de verrouiller un élément (fichier, répertoire) d’un référentiel. Cet élement ne pourra pas être modifié dans le référentiel par d’autres développeurs tant que le développeur initial ne l’a pas explicitement déverrouillé. C’est la notion de reserved checkout. Cela peut être utile dans certains cas : fichier binaire à manipuler, prévenir une tentative simultanée de correction de bug. On ne peut verrouiller qu’un fichier, pas une arborescence. Svn lock permet de verrouiller un fichier, on doit fournir un message de journal lors de cette opération. Un commit Svn status retourne pour un fichier verrouillé ‘K’ pour son verrouilleur et O pour les autres Svn info indique quel utilisateur a verrouillé. Il est possible pour n’importe quel utilisateur de déverrouiller un fichier avec svn unlock Voir http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html

Concepts et opérations de base Travailler à plusieurs sur un référentiel Gérer les diffusions : étiquettes et branches Opérations avancées Divers

Les clients et plugins Subversion Windows : TortoiseSVN Multi plateformes : RapidSVN, QSvn, Subcommander Eclipse : Subclipse, Subversive (beta) Visual Studio : AnkhSVN Emacs : psvn.el

Outils de navigation et API SVN::Web ViewVC WebSVN API C, C++, Python, JAVA, Perl, Ruby, C#, PHP Installation ultra simplifiée pour Windows SVN 1-Click Setup ViewVC est le successeur de ViewCVS.

Les protocoles d’accès à Subversion svn:// svn+ssh:// http:// https:// file:// Un Subversion peut offrir tout ou partie de ces protocoles d’accès. L’intérêt de HTTP/HTTPS est de traverser sans problèmes les firewalls, de pouvoir s’appuyer sur Apache pour les méthodes d’authentification et de permettre un contrôle d’accès par répertoire. Le protocole svn est réputé plus rapide

Conclusion

Un outil puissant et efficace CVS sans les défauts Fiable et performant Excellentes documentations Modèle centralisé simple à appréhender Subversion a tendance à de plus en plus remplacer CVS. Il est facile à appréhender pour les utilisateurs de CVS. Subversion est maintenant éprouvé et utilisé pour des projets majeurs (KDE par exemple). Il jouit aussi de bons outils d’administration et ne nécessite plus nécessairement Berkeley DB comme back-end. Il bénéficie de très bonnes documentations. Le mode de fonctionnement est assez simple à assimiler pour les développeurs. On bénéficie de la notion de référentiel.

Mais des limites inhérentes au modèle centralisé Seuls des utilisateurs privilégiés peuvent écrire dans le référentiel Besoin d’un accès réseau pour nombre d’opérations Une scission du projet est forcément binaire Une alternative : les VCS décentralisés (voir http://2005.jres.org/paper/2.pdf) L’écriture dans le référentiel est réservé à certains utilisateurs (les « commiteurs »). Les autres doivent soumettre des patchs : délais, dépendance envers les commiteurs. Cela peut créer des tensions et la notion de référentiel centralisé rend difficile le travail sur des versions parallèles : quand on fork, c’est du tout ou rien. Le mode centralisé n’est pas non plus favorable au travail déconnecté. Même si Subversion présente des améliorations par rapport à CVS sur ce point, il n’est toujours pas possible de préparer hors du réseau un ensemble de transactions successives à appliquer au référentiel. Les systèmes de contrôle de version (VCS) sont une alternative qui répond à ces problèmes en faisant disparaître la notion de référentiel centralisé. Chaque utilisateur peut gérer son propre référentiel . C’est un changement de paradigme complet. De nombreux VCS existent mais la plupart souffrent encore de limites (ergonomiques notamment). Cependant ils répondent à un modèle de développement ouvert et éclaté (ex. Linux).

Références Site : http://subversion.tigris.org, Doc officielle : http://svnbook.red-bean.com Gestion de projet avec Subversion (O’Reilly) Pragmatic Version Control (Pragmatic Bookshelf)

Traduction des termes branche = branche copie de travail = working copy dépôt = repository étiquette = tag message de journal = log propriété = property référentiel = repository révision = revision script associé = hook