Comme vous avez pu le constater dans la section intitulée « Révisions », les numéros de révision dans Subversion sont d'une grande simplicité, formant une suite d'entiers incrémentés au fur et à mesure des changements propagés dans le dépôt. Néanmoins, il ne faudra pas longtemps avant que vous ne puissiez plus vous rappeler exactement quel changement correspond à quelle révision. Heureusement, le fonctionnement normal de Subversion ne requiert pas souvent que vous fournissiez explicitement un numéro de révision pour une opération. Pour les opérations qui nécessitent vraiment un numéro de révision, c'est généralement un numéro de révision que vous avez vu soit dans un mail de propagation, soit dans la sortie d'une autre opération Subversion, soit dans un autre contexte où ce numéro possédait une signification particulière.
![[Note]](images/note.png)
|
Note |
|---|---|
|
Faire référence aux numéros de révision avec le préfixe
« |
À l'occasion, vous aurez besoin d'indiquer un moment précis dans le temps pour lequel vous n'avez pas encore le numéro de révision sous la main ou en mémoire. C'est pourquoi, en sus des numéros de révision, la commande svn autorise d'autres formes d'appellations pour les révisions : les mots-clés de révision et les dates de révision.
|
|
Note |
|---|---|
|
Les différentes formes d'appellations pour les révisions
peuvent être mélangées et comparées pour définir des intervalles
de révisions. Par exemple, vous pouvez spécifier |
Le client Subversion accepte une grande variété de mots-clés
de révision. En tant qu'argument de l'option
--revision (-r) ces mots-clés
peuvent être utilisés en lieu et place des numéros et sont
remplacés par les numéros correspondants par
Subversion :
-
HEAD -
La dernière (c'est-à-dire la plus récente) révision présente dans le dépôt.
-
BASE -
Le numéro de révision d'un élément de la copie de travail. Si l'élément a été modifié localement, la « version BASE » fait référence à l'élément tel qu'il était sans ces modifications locales.
-
COMMITTED -
La révision la plus récente avant (ou égale à)
BASE, dans laquelle un élément a changé. -
PREV -
La révision précédant immédiatement la dernière révision dans laquelle un élément a changé. Techniquement, cela revient à
COMMITTED−1.
Comme vous pouvez le deviner d'après leur description, les
mots-clés de révision PREV,
BASE et COMMITTED ne sont
utilisés que pour faire référence à un chemin dans la copie de
travail ; ils ne s'appliquent pas à des URL du dépôt. En
revanche, HEAD peut être utilisé avec les
deux types de chemin (local ou URL du dépôt).
Vous trouvez ci-dessous des exemples de l'utilisation de ces mots-clés :
$ svn diff -r PREV:COMMITTED machin.c # affiche le dernier changement propagé concernant machin.c $ svn log -r HEAD # affiche le commentaire associé à la dernière propagation dans le dépôt. $ svn diff -r HEAD # compare votre copie de travail (avec tous ses changements locaux) # à la dernière version de l'arborescence correspondante du dépôt. $ svn diff -r BASE:HEAD machin.c # compare la version non modifiée localement de machin.c avec la dernière # version de machin.c dans le dépôt. $ svn log -r BASE:HEAD # affiche, pour le dossier suivi en versions courant, les commentaires # de propagation depuis la dernière mise à jour (svn update). $ svn update -r PREV machin.c # revient une version en arrière pour le fichier machin.c. Ceci diminue # de un la révision de la version de travail du fichier machin.c. $ svn diff -r BASE:14 machin.c # compare la version non modifiée localement de machin.c avec # la version de ce fichier à la révision 14.
Les numéros de révision n'ont aucune signification en dehors
du système de gestion de versions. Cependant, parfois, vous avez
besoin d'associer une date réelle à un moment précis de
l'historique des versions. À cette fin, l'option
--revision (-r) accepte comme
argument une date placée entre accolades ({
et }). Subversion accepte les dates et les
heures aux formats définis dans le standard ISO-8601 ainsi que
quelques autres formats. Voici quelques exemples :
$ svn update -r {2006-02-17}
$ svn update -r {15:30}
$ svn update -r {15:30:00.200000}
$ svn update -r {"2006-02-17 15:30"}
$ svn update -r {"2006-02-17 15:30 +0230"}
$ svn update -r {2006-02-17T15:30}
$ svn update -r {2006-02-17T15:30Z}
$ svn update -r {2006-02-17T15:30-04:00}
$ svn update -r {20060217T1530}
$ svn update -r {20060217T1530Z}
$ svn update -r {20060217T1530-0500}
…
|
|
Note |
|---|---|
|
Gardez à l'esprit que la plupart des interpréteurs de commandes (shells) requièrent de mettre les dates qui contiennent des espaces entre guillemets ou « d'échapper » les espaces. Certains interpréteurs peuvent aussi poser problème avec les accolades si elles ne sont pas échappées. Consulter la documentation de votre interpréteur pour connaître les spécificités de votre environnement. |
Quand vous spécifiez une date, Subversion convertit cette date vers le numéro de révision le plus récent du dépôt à la date spécifiée. Puis, il continue son travail avec ce numéro de révision :
$ svn log -r {2006-11-28}
------------------------------------------------------------------------
r12 | ira | 2006-11-27 12:31:51 -0600 (lun. 27 nov. 2006) | 6 lignes
…
Vous pouvez également utiliser des intervalles de dates. Subversion trouve alors les révisions incluses entre ces deux dates :
$ svn log -r {2006-11-20}:{2006-11-29}
…
![[Avertissement]](images/warning.png)
|
Avertissement |
|---|---|
|
L'aptitude de Subversion à convertir correctement les horodatages de révisions en numéros de révision repose sur le fait que les horodatages de révisions sont ordonnées de manière croissante (plus le numéro est élevé, plus l'horodatage est récent). Mais l'horodatage d'une révision étant stocké comme une propriété modifiable et non suivie en versions de la révision (reportez-vous à la section intitulée « Propriétés »), les horodatages peuvent être modifiés et ne plus suivre la chronologie réelle. Aujourd'hui, cela n'affecte pas la plupart des opérations de Subversion (c'est le numéro de révision qui est l'identifiant primaire d'une révision). Mais si l'ordonnacement des horodatages n'est pas maintenu, il y a de grandes chances que l'utilisation des dates pour spécifier des intervalles de révisions dans votre dépôt ne fournisse pas les résultats attendus. Combiner les historiques de plusieurs dépôts pour n'en former qu'un (tel que décrit dans la section intitulée « Migration des données d'un dépôt ») est la cause principale de ce type de situation. |
