Identifiants de révision

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, vous pouvez fournir 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.

Occasionnellement, vous avez besoin d'identifier un moment précis pour lequel vous n'avez pas de numéro de révision en tête ou sous la main. C'est pourquoi, en plus des numéros de révision, svn accepte également en entrée d'autres formats d'appellations pour les révisions : les mots-clés de révision et les dates de révision.

[Note] 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 -r REV1:REV2REV1 est un mot-clé de révision et REV2 est un numéro de révision, ou bien où REV1 est une date et REV2 est un numéro de révision. Comme chaque appellation de révision est évaluée indépendamment, vous pouvez placer n'importe quel type d'appellation de chaque côté du symbole deux-points.

Mots-clés de révision

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 message 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 répertoire suivi en versions courant, les messages
# 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.

Dates de révision

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 (n'oubliez pas de mettre les dates qui contiennent des espaces entre guillemets) :

$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
$ svn checkout -r {"2006-02-17 15:30"}
$ svn checkout -r {"2006-02-17 15:30 +0230"}
$ svn checkout -r {2006-02-17T15:30}
$ svn checkout -r {2006-02-17T15:30Z}
$ svn checkout -r {2006-02-17T15:30-04:00}
$ svn checkout -r {20060217T1530}
$ svn checkout -r {20060217T1530Z}
$ svn checkout -r {20060217T1530-0500}
…

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] Avertissement

Puisque l'horodatage d'une révision est 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 changés et ne pas refléter la chronologie réelle. Ils peuvent même être tous supprimés. Or la capacité de Subversion à convertir correctement les dates en numéros de révision dépend des horodatages de révisions et de leur ordonnancement correct dans le temps : à une révision antérieure correspond un horodatage antérieur. Si cet ordonnancement 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.