Lorsqu'un projet grossit et devient plus complexe, il est souvent utile de pouvoir donner un nom symbolique à une révision particulière de l'archive.
Par exemple, supposons que le projet hello-world ait de nombreuses révisions :
mainline -------- base-0 patch-1 patch-2 .... patch-23
Il est possible qu'en cours de développement des publications de « snapshots » soient effectuées à partir de la mainline. Toutes les révisions ne deviennent pas des « snapshots », mais certaines oui.
Il serait intéressant d'indiquer une étiquette aux révisions qui deviennent des « snapshots » :
mainline -------- base-0 patch-1 snapshot 0 patch-2 .... patch-12 snapshot 2 .... patch-23 snapshot 3
La commande tag introduite précédemment, peut être utilisée à cette fin. (voir « Créer une branche d'un projet distant dans une archive locale »)
La première fois que nous avons rencontré la commande tag, c'était pour créer la révision base_0 d'une branche élémentaire. Elle peut également être utilisée pour créer une branche pour toutes les révisions ayant une étiquette.
Supposons que nous voulions créer une branche appelée hello-world--snapshots--0.1. Sous forme de diagramme, nous aurons :
mainline snapshots -------- --------- base-0 --------> base-0 (tag) patch-1 -------------' ------> patch-1 (tag) patch-2 ' .... ' patch-12 ------------' .... patch-23
Pour créer l'étiquette snapshot pour le patch-23:
% tla tag hello-world--mainline--0.1--patch-23 \
hello-world--snapshots--0.1
après quoi nous aurons :
mainline snapshots -------- --------- base-0 --------> base-0 (tag) patch-1 -------------' ------> patch-1 (tag) patch-2 ' -----> patch-2 (tag) .... ' ' patch-12 ------------' ' .... ' patch-23 ------------'
En effet, la branche snapshots est une sorte de nom symbolique avec un historique. Nous pouvons récupérer la dernière révision nommée par ce symbole avec :
% tla get hello-world--snapshots--0.1
et les révisions précédentes par le nom spécifique de leurs révisions, ex. :
% tla get hello-world--snapshots--0.1--patch-1
Attention!
En général, vos branches devraient être soit des branches basées sur commit (toutes les révisions après base-0 sont créées par commit), soit des branches basées sur tag (toutes les révisions sont créées par tag). Les commandes telles que replay, update, et star-merge sont basées sur la présomption que vous suivez cette règle. Même s'il peut être tentant, dans d'obscures circonstances, de mélanger commit et tag sur une même branche -- c'est généralement peu recommandable.
Version du 31/05/2004 21h18 : wilk@flibuste.net--libre docs-tla--fr--1.0 patch-99 ... base-0