Planet GCU

Comment faire quand certaines modification qui ont été validées (svn commit) ne tiennent pas la route pour différentes raisons (bug, performance, ...)? La solution consiste à replacer certains fichiers modifiés dans un état plus ancien pour retrouver la situation souhaitée. Pour ce faire, il faut identifier la révision cible, effacer les fichiers concernés et les remplacer par la version de la révision voulue.

A partir d'une copie de travail à jour, on vérifie la révision courante :

$ svn info
Path: .
URL: http://code/svn/t/test/trunk
Repository Root: http://code/svn/t/test
Repository UUID: 4d726b7c-4586-4a21-a23b-c1e54c03d712
Revision: 67
Node Kind: directory
Schedule: normal
Last Changed Author: hr
Last Changed Rev: 51
Last Changed Date: 2009-04-15 17:07:06 +0200 (Wed, 15 Apr 2009)
$ ls
conf  file.txt  script.sh

Dans cet exemple, je dois remettre file.txt dans un ancien état, je vais chercher dans les logs quelle révision correspond à la version que je cherche.

$ svn log file.txt
[...]
------------------------------------------------------------------------
r48 | hr | 2009-04-15 16:53:05 +0200 (Wed, 15 Apr 2009) | 1 line

* conflict test.
------------------------------------------------------------------------
r24 | hr | 2009-02-16 15:33:23 +0100 (Mon, 16 Feb 2009) | 1 line

* bugfix
------------------------------------------------------------------------
[...]

Dans mon cas, je prends la révision 48 comme révision cible.

Je dois maintenant remplacer le fichier file.txt courant par sa version r48

$ svn rm file.txt
D         file.txt
$ svn copy -r48 http://code/svn/t/test/trunk/file.txt ./file.txt
A         file.txt
$ svn status
R  +   file.txt

La commande svn status me donne plusieurs informations intéressantes. Le caractère 'R' signifie que je remplace le fichier en question; le caractère '+' m'indique que je fais une copie de l'historique avec celle du fichier.

ATTENTION: nous sommes bien avec une version de subversion etch (version 1.4.2 (r22196)), les versions plus récentes acceptent une syntaxe différente :

$ svn copy http://code/svn/t/test/trunk/file.txt@48 ./file.txt

Je vais maintenant publier cette modification au niveau du serveur avec un message de log clair.

$ svn ci -m "* reverting file.txt to r48." file.txt
Replacing      file.txt

Committed revision 68.
$ svn log file.txt
------------------------------------------------------------------------
r68 | hr | 2009-06-25 17:11:16 +0200 (Thu, 25 Jun 2009) | 1 line

* reverting file.txt to r48.
------------------------------------------------------------------------
r48 | hr | 2009-04-15 16:53:05 +0200 (Wed, 15 Apr 2009) | 1 line

* conflict test.
------------------------------------------------------------------------
[...]

Et voilà, l'historique a bien été copié et mon message de log est clair.

Pour remettre tout un projet dans un état ancien, svn merge est plus conseillé, ça fera peut-être l'objet d'un autre billet.