Quelques commandes SVN utiles
Eh oui, la grande mode est à git, mais nous sommes encore nombreux à (être obligés d’)utiliser subversion, au travail par exemple. C’est mon cas. Comme j’ai une toute petite tête et que je préfère utiliser mes outils en ligne de commande, je note régulièrement les petites astuces avec svn. En voici certaines :
Checkout à une date donnée
svn checkout --revision {2002-02-17} url
Merge d’un commit depuis une branche
Pour réaliser cela, il faut disposer :
- du ou des numéros de commit (avec svn log)
- de l’url de la branche d’origine où le commit a été réalisé (svn info)
- … de patience car les merge sont souvent un parcours semé d’embûches sous svn
Par exemple, pour merger le commit 1000.
cd ~/destination/du/merge
svn merge -r999:1000 http://url/de/la/branche/ .
Pour un seul commit, on peut préférer l’option -c (comme change) :
svn merge -c1000 http://url/de/la/branche/ .
Pour plusieurs commit, c’est presque pareil. Ainsi, pour le merge du commit 1000 à 1010 :
svn merge -r999:1010 http://url/de/la/branche/ .
Revert d’un commit
C’est un merge inversé. Pour cela, il faut disposer du numéro de commit (svn log).
Par exemple, pour faire un revert du commit numéro 12 :
svn merge -r12:11 .
SVN nous informe qu’il s’agit d’une fusion inverse :
--- Fusion inverse de r12 dans '.' :
M chemin/fichier/modifie/fichier.txt
Il ne vous reste plus qu’à vérifier ce qui change (svn status) et de le commiter.
Find en évitant les .svn
find . -name "pattern" -not -path "*svn" -exec maCommande {} \;
Sinon, il y a ack qui est bien meilleur de grep. Il évite tout seul les .svn et autres fichiers embêtants.
Et vous, quelles sont vos astuces svn ?
-
Jean-Baptiste Potonnier le 2011-04-16 :
Merci Jean-Philippe de nous rappeler les base d’un outils que l’on utilise tous les jours.
Il me semble effectivement important de maitriser ce que l’on fait!
Au fait, j’en profite pour rappeler qu’il est dangereux de renommer des fichiers en changeant juste la casse, sous certains OS…
Il est également périlleux de renommer/déplacer plusieurs fois le même fichier, sans commit intermédiaire.
Comme moi ce matin , vous décrocherez le gros lot en faisant de même avec des répertoires entiers. Et découvrirez alors les joies des “conflicts”, “tree conflict” etc.
Vous serez alors contraint de (re) decouvrir certaines commandes à base de “resolve”, “cleanup”, ou bien de supprimer vos fichiers en espérant retrouver un état stable.
Personnellement la leçon que je retiendrai est que parfois, il est plus simple de jeter sa working copy, e refaire un checkout, puis de refaire ses modifications de manière plus intelligente.
-
Jean-Philippe Caruana le 2011-04-17 :
Jean-Baptiste, ta dernière remarque est tout a fait pertinente, et on oublie parfois que c’est très simple de procéder ainsi (
rm -rf; svn co).Sous git, c’est encore plus facile : à partir du moment où tu fais toutes tes modifications dans une branche, il est facile et sans impact de jeter cette branche en cas d’erreur. Luxe supplémentaire, la plupart des opérations que tu as citées et qui posent problème sous svn se déroulent très bien sous git. Mais 10 ans séparent ces 2 technologies.
Réactions