Les opérations de base dans Subversion
Publié le 18 mar 09 à 07:29 | Catégorie : Développement Web | 9 commentaires
J’utilise depuis un certain temps maintenant Subversion, un gestionnaire de versions open source qui fonctionne plutôt bien. Plus léger que ClearCase et plus abouti que Vss ou Cvs, Subversion me permet de garder une trace de tous les changements effectués sur chacun de mes projets. Il offre également la possibilité de gérer des branches indépendantes pour des environnements de production et de staging nécessaires sur des applications complexes comme Loomiz. Voici donc un petit mémento des commandes que j’utilise le plus souvent.
Démarrer Subversion
1 | svnserve -d |
Créer un repository
Les chemins employés ci-dessous sont évidemment propres à ma configuration :
1 | svnadmin create E:/repository/loomiz |
Il faut ensuite décommenter certaines lignes dans le fichier E:/repository/loomiz/conf/svnserve.conf qui vient d’être créé par Subversion et qui spécifie la méthode d’authentification de ce repository. Lorsque l’on travaille en local (donc sans contraintes importantes en terme de sécurité), il suffit juste de décommenter les 3 lignes suivantes :
1 2 3 | anon-access = read auth-access = write password-db = passwd |
Il ne reste plus qu’à déclarer un nouvel utilisateur et son mot de passe dans le fichier E:/repository/loomiz/conf/passwd :
1 2 | [users] stephane = stephanesecret |
Et voilà, il est maintenant possible d’interagir avec le nouveau repository et de créer la structure standard des répertoires :
1 2 3 | svn mkdir svn://localhost/repository/loomiz/trunk svn://localhost/repository/loomiz/branches svn://localhost/repository/loomiz/tags -m "Setting up default directories" svn mkdir svn://localhost/repository/loomiz/branches/production -m "Creating a new 'production' branch" svn mkdir svn://localhost/repository/loomiz/branches/staging -m "Creating a new 'staging' branch" |
Si l’on souhaite importer du code dans le repository, il faut faire :
1 | svn import "F:/Work/Loomiz/Sources" svn://localhost/repository/loomiz/trunk -m "Initial revision" |
Et supprimer l’ancien répertoire F:/Work/Loomiz/Sources avant de créer une véritable working copy :
1 | svn checkout svn://localhost/repository/loomiz/trunk "F:/Work/Loomiz/Sources" |
Tagger une release
L’idée ici est - comme dirait un ami - de poser un label sur plusieurs branches afin d’avoir un snapshot du repository à un moment donné (mais il est bien sûr possible de tagger juste une seule branche) :
1 2 3 4 | svn mkdir svn://localhost/repository/loomiz/tags/release-7.0.0 -m "Creating a new directory for release-7.0.0 release" svn copy "F:/Work/Loomiz/Sources (Production)" svn://localhost/repository/loomiz/tags/release-7.0.0/production -m "Creating release-7.0.0 production release" svn copy "F:/Work/Loomiz/Sources (Staging)" svn://localhost/repository/loomiz/tags/release-7.0.0/staging -m "Creating release-7.0.0 staging release" svn copy "F:/Work/Loomiz/Sources" svn://localhost/repository/loomiz/tags/release-7.0.0/development -m "Creating release-7.0.0 development release" |
Nommer les releases
J’ai adopté la convention suivante pour le nom des releases (par exemple mockup-0.1.0, release-0.1.1, …) :
1 | <name>-<major>.<minor>.<bug> |
Sauvegarder un repository
Voici une commande très pratique pour faire un backup du repository lui-même :
1 | svnadmin dump E:/repository/loomiz > "F:/Work/Loomiz/Backup/Repository/repository.dump" |
Supprimer une ou plusieurs révisions
1. Faire un backup du repository avec les révisions que l’on veut garder :
1 | svnadmin dump E:/repository/loomiz -r 1:32 > repository.dump |
2. Supprimer le répertoire contenant le repository :
1 | del E:/repository/loomiz |
3. Recréer un nouveau repository avec le même nom :
1 | svnadmin create E:/repository/loomiz |
4. Charger la sauvegarde dans le nouveau repository :
1 | svnadmin load E:/repository/loomiz < repository.dump |
5. Il ne reste plus ensuite qu’à faire un checkout pour avoir une working copy à jour :
1 | svn co svn://localhost/repository/loomiz/trunk "F:/Work/Loomiz/Sources" |
6. Et à supprimer le fichier de backup :
1 | del repository.dump |
Changer la casse du nom d’un fichier sur Windows
Si vous voulez changer la casse d’un nom de fichier sous Windows, il suffit simplement de supprimer ce fichier de la working copy et d’aller modifier ensuite le nom du fichier directement dans le repository (par exemple TortoiseSVN permet de faire ça très facilement grâce à son repo-browser). Il ne reste plus alors qu’à mettre à jour le répertoire qui contenait ce fichier dans la working copy pour le récupérer avec la bonne casse.
Modifier un message de log
Dans le cas où vous avez effectué un commit avec un message incorrect ou incomplet, vous pouvez le modifier en autorisant tout d’abord la modification des propriétés de révision en créant un fichier pre-revprop-change.bat ou pre-revprop-change.sh dans le répertoire hooks du dépôt. Il suffit ensuite d’exécuter la commande suivante avec le nouveau message depuis le répertoire racine de la copie de travail :
1 | svn propset -r 162 --revprop svn:log "Backported production fix." |
En précisant bien sûr le numéro de révision. La dernière étape consiste à supprimer ce fichier afin de rétablir les mécanismes de hook par défaut.
A lire également
Vous pouvez continuer votre lecture sur des sujets similaires en consultant les articles suivants :
- Typologies web et la juste répartition des budgets de conception
- Le rôle des barres de progression sur le web
- Automatiser vos déploiements
- Comment optimiser un site en plusieurs langues pour les moteurs de recherche ?
Les visiteurs qui ont vu cette page ont consulté ensuite :
- Créer des timelines facilement avec Dipity (20 lectures)
- 8 gestionnaires de relation client à découvrir (16 lectures)
- 5 gestionnaires de bugs très web 2.0 (16 lectures)
A savoir
La rédaction de cet article a nécessité 1 heure et 33 minutes. Si vous le souhaitez, vous pouvez être prévenu de la parution de nouveaux articles en vous abonnant par RSS ou par email.
Un rétrolien à propos de “Les opérations de base dans Subversion” :
-
Les billets de la semaine #29 - YouBox
Le 29 mars 2009 à 22:10
8 commentaires à propos de “Les opérations de base dans Subversion” :
Très bon article mais c’est dommage de nous parler de Subversion alors que tout le monde est à Git désormais (notamment pour sa gestion des branches, bien plus simple qu’avec SVN !).
Raphaël le 18 mars 2009 à 09:51 (#1)
Mouais.. git c’est un peu dépassé, et sous Windows c’est pas top. Par contre Mercurial est vraiment intéressant, mais réservé à un public averti je dirais, il est moins facile d’accès que SVN.
SVN pour la gestion des branches est plus facile à comprendre, par contre il a un gros défaut, c’est qu’il ne sait pas faire les merges entre différentes branches, il faut faire ça à la main.
SVK est excellent pour ça, si on doit utiliser SVN, c’est un gestionnaire de version décentralisé, qui s’interface parfaitement avec SVN, et permet de merger les branches les doigts dans le nez.
Gérald le 18 mars 2009 à 11:05 (#2)
je ne me considère pas comme un spécialiste de SVN, même si je l’utilise, mais j’ai l’impression que la Version 1.5 intègre des grandes améliorations en ce qui concerne les merges…
Sinon, j’utilise et je vous recommande, http://xp-dev.com/ du SVN privé, gratuit avec 1.5 Giga.
Assez pour démarrer un projet à plusieurs, pour qui ne veut pas l’open sourcer, sans se prendre la tête sur l’infrastructure et l’hébergement…. tout simplement génial, et fiable pour l’utilisatio que j’en ai
y!onel le 18 mars 2009 à 11:28 (#3)
Sous Win32 tortoiseSVN permet de creer des “local repository”, qui sont en fait des repository sans avoir à installer de serveur SVN, le tout accessible par l’UI tortoiseSVN (cette UI étant le principal avantage de SVN sur tous les git et autres).
Apres ils suffit de livrer le repository au client, et il peut très facilement continuer dessus.
C’est de loin le plus simple et plus puissant des systèmes.
Il fait des checkout en donnant le chemin fichier de là ou est le repository.
(seul désavantage, on peut pas coller de trac ou autre web ui dessus.)
tuan kuranes le 18 mars 2009 à 11:31 (#4)
Pour ceux qui utilisent Eclipse, le plugin Subclipse (http://subclipse.tigris.org/, réalisé par Tigris), est très solide et permet de réaliser toutes les opérations classiques et bien des opérations avancées via l’interface d’Eclipse. Il dispose même d’une perspective dédiée dans laquelle il est possible d’administrer les branches, faire un diff d’une version du repository avec la version actuelle, consulter l’historique des révisions, etc.
Brice le 19 mars 2009 à 01:07 (#5)
Oui, la version 1.5 gère le merge, mais quand je lis :
The merge tracking support in Subversion 1.5 is “foundational”: its basic functionality is implemented, but there are still parts of our original spec that remain to be done, and merging is sometimes too slow. There will be merge tracking improvements in Subversion 1.5.1 and afterwards.
Ca me fait un peu peur
J’attends de voir une version stable qui ait toutes les fonctionnalités qu’il faut.
Je n’ai pas vu toutes les nouveautés de la dernière version, mais dans le version 1.4, le rennomage de fichier n’est pas supporté non plus.
Gérald le 19 mars 2009 à 10:46 (#6)
Une petite astuce en passant avec TortoiseSVN : parfois le menu contextuel de Windows (lorsqu’on fait un clic droit) sur un répertoire n’affiche pas toutes les options de TortoiseSVN. J’ai rencontré ce problème en utilisant le logiciel Servant Salamander, mais j’imagine que cela peut arriver avec d’autres outils de ce genre. Il s’agit probablement d’un bug, mais une bonne parade est tout simplement d’appuyer sur la touche shift lorsqu’on clique pour forcer leur affichage.
Stéphane le 23 mars 2009 à 09:51 (#7)
Et voici également un article qui explique comment rafraichir une copie de travail lorsqu’on déplace le repository attenant.
Stéphane le 28 mars 2009 à 13:46 (#8)
Ajouter un commentaire