(Traduction du texte original en anglais : Tag)
Tag
(Note: Si vous migrez depuis CVS, veuillez lire cette discussion en anglais sur les tags CVS avant de continuer.)
hg tags
hg tag [-l] [-m TEXTE] [-d DATE] [-u UTILISATEUR] [-r REV] NOM...
Un tag est un identifiant symbolique pour un changeset. Il peut contenir n'importe quel caractère sauf ":" (deux points), "\r" (retour-chariot) ou "\n" (saut de ligne). Mercurial dispose de deux types de tags : local et normal.
Un tag local est une commodité d'identification qui n'est pas inscrite dans une révision, il ne se propage pas avec les autres changements et réside dans le fichier .hg/localtags d'un dépôt.
Un tag "normal" (sans spécification spéciale) est inscrit dans une révision, il se propage avec les autres changements et il demeure dans le fichier .hgtags d'un dépôt.
Contents
- Exemple
- Comment fonctionnent les tags dans Mercurial ?
- Et si je veux juste utiliser les tags locaux ?
- Mes tags sont en conflit quand je fusionne. Pourquoi ? Comment dois-je les fusionner ?
- Comment se comportent les tags avec des heads multiples ?
- Et si plusieurs lignes avec des révisions différentes utilisent le même nom de tag dans .hgtags ?
- Comment supprimer un tag ?
- Références manuel
Exemple
hg tag voici_mon_tag
Comment fonctionnent les tags dans Mercurial ?
Les tags fonctionnent légèrement différemment dans Mercurial que dans la plupart des autres systèmes de révision. L'architecture implique les pré-requis suivants :
être sous contrôle de version et fusionnable comme n'importe quel autre fichier
- autoriser la signature des tags
autoriser l'ajout d'un tag à un changeset déjà validé
- autoriser le changement futur des tags
Pour cela, mercurial stocke les tags dans un fichier dans le dossier de travail. Ce fichier est nommé .hgtags et consiste en une liste d'IDs de changeset et de leur tags correspondants. Pour ajouter un tag au système, il suffit d'ajouter une ligne dans ce fichier et de faire un commit pour qu'il prenne effet. La commande hg tag fera cela pour vous et hg tags montrera les tags effectifs courants.
Notez que puisque les tags font référence à des IDs de changeset et que l'ID d'un changeset est effectivement la somme de tous les contenus du dépôt pour ce changement, il est impossible dans Mercurial de faire un commit et d'ajouter un tag pour ce commit simultanément. Par conséquent le tag d'une révision doit être réalisé dans un second temps. Donc, comme précédemment, les seuls changesets qui peuvent être "taggés" sont ceux déjà validés.
Le fait que les tags identifient les changesets et soient aussi des parties de changesets a quelques implications pouvant prêter à confusion :
- Le changeset référencé par un tag est toujours plus ancien que le changeset validant le tag lui-même.
Faire un update d'un dossier de travail vers un tag particulier va ramener ce dossier à un point précédent l'existence du-dit tag.
Faire un clone d'un dépôt à un tag précis va donner un nouveau dépôt qui ne contient pas ce tag.
La sagesse populaire incite à d'éviter la confusion d'un tag disparaissant, vous devriez cloner le dépôt en entier et ensuite faire un update du dossier de travail vers le tag. Ainsi le tag sera préservé dans le dépôt.
Et si je veux juste utiliser les tags locaux ?
Vous pouvez utiliser la commange "hg tag" avec l'option -l ou --local. Ceci stockera le tag dans le fichier .hg/localtags, qui ne sera ni distribué ni versionné. Le format de ce fichier est identique à celui de .hgtags et les tags stockés dedans le seront à l'identique.
Mes tags sont en conflit quand je fusionne. Pourquoi ? Comment dois-je les fusionner ?
Divers ensembles de tags, venant de différentes branches et heads, peuvent provoquer des conflits de fusion. Bien que Mercurial sache comment gérer divers .hgtags dans divers heads, il n'utilise pas cette connaissance lors d'une tentative de fusion. Au lieu de cela, les fichiers .hgtags sont fusionnés comme n'importe quels autres fichiers, il peut donc résulter de cela un conflit de fichiers, même lorsque la résolution est triviale.
En cas de conflit de fusion sur vos tags, l'option la plus sûre est de récupérer l'ensemble des deux versions.
Comment se comportent les tags avec des heads multiples ?
Les tags qui sont effectifs à un moment donné sont ceux spécifiés dans chaque head. Un cas délicat se pose, si les mêmes tag spécifient deux révisions différentes dans deux heads. Il n'y a pas de solution générale "correcte" à ce problème.
Si deux définitions/changements de tags semblent décousues comme dans le diagramme suivant, le "meilleur tip" (c-à-d celui qui à le plus grand numéro de révision) gagne.
Dans le schéma ci-dessus tag_a référence la révision 2, puisque la révision 14 est plus élevée que la révision 13.
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
Notez que le numéro de révision dépend de l'ordre dans lequel les changements ont été rapportés au dépôt, c'est pourquoi ils peuvent varier même sur des dépôts contenant les mêmes changesets.
Cependant si un tag a été défini dans un ancêtre commun des deux heads, mais changé dans un seul head, celui changé l'emporte sur celui inchangé. 
Dans le diagramme ci-dessus tag_b fait référence à la révision 10, bien que la révision 13 ne soit pas le Tip.
Notez que cet algorithme de résolution des conflits de tag pour les head multiples dépend du fichier .hgtags qui doit être ajouter uniquement et qui sera soigneusement fusionné.
Les tags locaux surchargent tous les autres tags.
Voir aussi : MultipleHeads
Et si plusieurs lignes avec des révisions différentes utilisent le même nom de tag dans .hgtags ?
S'il y a juste un head, seul la dernière ligne ou le tag apparaît est prise en compte. S'il y a des heads multiples, les définitions précédentes du tag sont utilisées pour déterminer quel head contient le tag le plus récent. Voir "Comment se comportent les tags avec des heads multiples ?". Si un tag pointe vers 0000000000000000000000000000000000000000 il est considéré comme effacé.
La règle est la même en ce qui concerne .hg/localtags.
Comment supprimer un tag ?
Au choix par :
hg tag --remove nom_du_tag (c'est ce qui s'approche le plus de cvs tag -d)
en ajoutant nom_du_tag 0000000000000000000000000000000000000000 à la fin de .hgtags
en supprimant toutes les références à nom_du_tag dans .hgtags (mais ceci peut créer des confusions dans l'algorithme de résolution des conflits de tag pour les head multiples)