hg - En ligne dans le Cloud

PROGRAMME:

Nom

hg - Système de gestion de code source Mercurial

SYNOPSIS

hg commander [option]... [argument] ...

DESCRIPTION

La hg La commande fournit une interface de ligne de commande au système Mercurial.

COMMAND ÉLÉMENTS

des dossiers...
indique un ou plusieurs noms de fichiers ou chemins relatifs ; voir Modèles de noms de fichiers
pour plus d'informations sur l'appariement des motifs

chemin indique un chemin sur la machine locale

révision
indique un ensemble de modifications qui peut être spécifié comme un numéro de révision d'ensemble de modifications, une balise,
ou une sous-chaîne unique de la valeur de hachage de l'ensemble de modifications

dépôt chemin
soit le chemin d'accès d'un référentiel local, soit l'URI d'un référentiel distant.

OPTIONS

-R,--dépôt
répertoire racine du référentiel ou nom du fichier d'ensemble de superposition

--cwd
changer de répertoire de travail

-oui, --non interactif
ne pas demander, choisir automatiquement le premier choix pour toutes les invites

-q, --silencieux
supprimer la sortie

-dans, --verbeux
activer une sortie supplémentaire

--config
set/override config option (utilisez 'section.name=value')

--déboguer
activer la sortie de débogage

--débogueur
démarrer le débogueur

--codage
définir l'encodage du jeu de caractères (par défaut : UTF-8)

--mode d'encodage
définir le mode d'encodage du jeu de caractères (par défaut : strict)

--trace
toujours imprimer un retraçage en cas d'exception

--temps temps combien de temps prend la commande

--profil
profil d'exécution de la commande d'impression

--version
informations de version et quitte

-h, --Aidez-moi
afficher l'aide et quitter

--caché
considérer les ensembles de modifications cachés

L'option marquée [+] peut être spécifiée plusieurs fois

COMMANDES

ajouter
ajoutez les fichiers spécifiés au prochain commit :

hg ajouter [OPTION]... [FICHIER]...

Planifiez la version des fichiers pour qu'ils soient contrôlés et ajoutés au référentiel.

Les fichiers seront ajoutés au référentiel lors du prochain commit. Pour annuler un ajout avant cela,
sur le lien hg oublier.

Si aucun nom n'est donné, ajoutez tous les fichiers au référentiel (sauf les fichiers correspondant .hgignore).

Exemples :

· Les nouveaux fichiers (inconnus) sont ajoutés automatiquement par hg ajouter:

$ls
foo.c
$ hg statut
? foo.c
$ hg ajouter
ajouter foo.c
$ hg statut
Un foo.c

· Des fichiers spécifiques à ajouter peuvent être spécifiés :

$ls
bar.c foo.c
$ hg statut
? bar.c
? foo.c
$ hg ajouter bar.c
$ hg statut
Un bar.c
? foo.c

Renvoie 0 si tous les fichiers sont ajoutés avec succès.

Options:

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-S, --sous-dépôt
récursif dans les sous-référentiels

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

L'option marquée [+] peut être spécifiée plusieurs fois

Ajouter enlever
ajouter tous les nouveaux fichiers, supprimer tous les fichiers manquants :

hg addremove [OPTION]... [FICHIER]...

Ajoutez tous les nouveaux fichiers et supprimez tous les fichiers manquants du référentiel.

À moins que des noms ne soient donnés, les nouveaux fichiers sont ignorés s'ils correspondent à l'un des modèles de
.hgignore. Comme avec add, ces modifications prennent effet au prochain commit.

Utilisez l'option -s/--similarity pour détecter les fichiers renommés. Cette option prend un pourcentage
entre 0 (désactivé) et 100 (les fichiers doivent être identiques) comme paramètre. Avec un paramètre
supérieur à 0, ceci compare chaque fichier supprimé avec chaque fichier ajouté et enregistre ceux
assez similaire à renommer. Détecter les fichiers renommés de cette façon peut être coûteux. Après avoir utilisé
cette option, hg statuts -C peut être utilisé pour vérifier quels fichiers ont été identifiés comme déplacés ou
renommé. S'il n'est pas spécifié, -s/--similarity est défini par défaut sur 100 et ne renomme que les
les fichiers sont détectés.

Exemples :

· Un certain nombre de fichiers (bar.c et foo.c) sont nouveaux, tandis que foobar.c a été supprimé (sans
en utilisant hg supprimez) à partir du référentiel :

$ls
bar.c foo.c
$ hg statut
! foobar.c
? bar.c
? foo.c
$hg addremove
ajout de bar.c
ajouter foo.c
suppression de foobar.c
$ hg statut
Un bar.c
Un foo.c
R foobar.c

· Un fichier foobar.c a été déplacé vers foo.c sans utiliser hg rebaptiser. Après, c'était
légèrement modifié :

$ls
foo.c
$ hg statut
! foobar.c
? foo.c
$hg addremove --similarité 90
suppression de foobar.c
ajouter foo.c
enregistrement de la suppression de foobar.c pour le renommer en foo.c (similaire à 94 %)
$ hg statut -C
Un foo.c
foobar.c
R foobar.c

Renvoie 0 si tous les fichiers sont ajoutés avec succès.

Options:

-Oui,--similarité
devinez les fichiers renommés par similarité (0<=s<=100)

-S, --sous-dépôt
récursif dans les sous-référentiels

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

L'option marquée [+] peut être spécifiée plusieurs fois

annoter
affichez les informations de l'ensemble de modifications par ligne pour chaque fichier :

hg annoter [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] FICHIER...

Répertorie les modifications apportées aux fichiers, indiquant l'ID de révision responsable de chaque ligne.

Cette commande est utile pour découvrir quand une modification a été apportée et par qui.

Si vous incluez --file, --user ou --date, le numéro de révision est supprimé sauf si vous
incluez également --number.

Sans l'option -a/--text, annotate évitera de traiter les fichiers qu'il détecte comme binaires.
Avec -a, annotate annotera le fichier de toute façon, bien que les résultats seront probablement
ni utile ni souhaitable.

Renvoie 0 en cas de succès.

Options:

-r,--tour
annoter la révision spécifiée

--poursuivre
suivre les copies/renommer et lister le nom du fichier (PÉRIMÉ)

--pas de suivi
ne pas suivre les copies et renommer

-une, --texte
traiter tous les fichiers comme du texte

-tu, --utilisateur
liste l'auteur (avec -v)

-F, --déposer
liste le nom du fichier

-ré, --Date
liste la date (court avec -q)

-n, --numéro
liste le numéro de révision (par défaut)

-c, --changeset
lister l'ensemble de modifications

-l, --numéro de ligne
afficher le numéro de ligne à la première apparition

-w, --ignore-tout-espace
ignorer les espaces blancs lors de la comparaison de lignes

-b, --ignore-changement d'espace
ignorer les changements dans la quantité d'espace blanc

-B, --ignore-lignes-vides
ignorer les modifications dont toutes les lignes sont vides

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

L'option marquée [+] peut être spécifiée plusieurs fois

alias : blâmer

archives
créer une archive non versionnée d'une révision de référentiel :

hg archive [OPTION]... DEST

Par défaut, la révision utilisée est le parent du répertoire de travail ; utilisez -r/--rev pour
spécifier une révision différente.

Le type d'archive est automatiquement détecté en fonction de l'extension de fichier (pour remplacer, utilisez
-t/--type).

Exemples :

· créer un fichier zip contenant la version 1.0 :

hg archive -r 1.0 projet-1.0.zip

· créer une archive tar excluant les fichiers .hg :

hg archive project.tar.gz -X ".hg*"

Les types valides sont :

fichiers

un répertoire plein de fichiers (par défaut)

goudron

archive tar, non compressée

tbz2

archive tar, compressée à l'aide de bzip2

tgz

archive tar, compressée à l'aide de gzip

Uzip

archive zip, non compressée

Zip *: français

archive zip, compressée à l'aide de deflate

Le nom exact de l'archive ou du répertoire de destination est donné à l'aide d'une chaîne de formatage ; voir
hg aider Exporter pour en savoir plus.

Chaque membre ajouté à un fichier d'archive est précédé d'un préfixe de répertoire. Utilisez -p/--prefix pour
spécifiez une chaîne de format pour le préfixe. La valeur par défaut est le nom de base de l'archive, avec
suffixes supprimés.

Renvoie 0 en cas de succès.

Options:

--pas de décodage
ne pas passer les fichiers via les décodeurs

-p,--préfixe
préfixe de répertoire pour les fichiers dans l'archive

-r,--tour
révision à distribuer

-t,--taper
type de distribution à créer

-S, --sous-dépôt
récursif dans les sous-référentiels

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

retrait
effet inverse de l'ensemble de modifications précédent :

hg backout [OPTION]... [-r] REV

Préparez un nouveau jeu de modifications avec l'effet de REV annulé dans le répertoire de travail actuel. Si
aucun conflit n'a été rencontré, il sera commis immédiatement.

Si REV est le parent du répertoire de travail, alors ce nouvel ensemble de modifications est validé
automatiquement (sauf si --no-commit est spécifié).

Notes hg retrait ne peut pas être utilisé pour corriger une fusion indésirable ou incorrecte.

Exemples :

· Inverser l'effet du parent du répertoire de travail. Ce retrait sera
commis immédiatement :

hg backout -r .

· Inverser l'effet de la mauvaise révision précédente 23 :

hg backout -r 23

· Inversez l'effet de la mauvaise révision précédente 23 et laissez les modifications non validées :

hg backout -r 23 --no-commit
hg commit -m "Révision de sauvegarde 23"

Par défaut, l'ensemble de modifications en attente aura un parent, maintenant un historique linéaire. Avec
--merge, l'ensemble de modifications en attente aura à la place deux parents : l'ancien parent du
répertoire de travail et un nouvel enfant de REV qui annule simplement REV.

Avant la version 1.7, le comportement sans --merge équivalait à spécifier --merge
suivie par hg Mise à jour --nettoyer . d'annuler la fusion et de laisser l'enfant de REV à la tête
à fusionner séparément.

See hg aider dates pour une liste de formats valides pour -d/--date.

See hg aider revenir pour un moyen de restaurer les fichiers à l'état d'une autre révision.

Renvoie 0 en cas de succès, 1 s'il n'y a rien à annuler ou s'il y a des fichiers non résolus.

Options:

--fusionner
fusionner avec l'ancien parent dirstate après la désactivation

--s'engager
commit si aucun conflit n'a été rencontré (PÉRIMÉ)

--sans engagement
ne pas s'engager

--parent
parent à choisir lors de l'annulation de la fusion (PÉRIMÉ)

-r,--tour
révision pour annuler

-e, --modifier
invoquer l'éditeur sur les messages de validation

-t,--outil
spécifier l'outil de fusion

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

L'option marquée [+] peut être spécifiée plusieurs fois

couper en deux
recherche par subdivision des ensembles de modifications :

hg bissectrice [-gbsr] [-U] [-c CMD] [REV]

Cette commande aide à trouver des ensembles de modifications qui introduisent des problèmes. Pour l'utiliser, marquez le plus tôt
le jeu de modifications que vous connaissez présente le problème comme étant grave, puis marquez le dernier jeu de modifications qui est
libre du problème aussi bien. Bisect mettra à jour votre répertoire de travail avec une révision pour
testing (sauf si l'option -U/--noupdate est spécifiée). Une fois les tests effectués,
marquez le répertoire de travail comme bon ou mauvais, et bisect se mettra à jour vers un autre
ensemble de modifications candidat ou annoncer qu'il a trouvé la mauvaise révision.

En guise de raccourci, vous pouvez également utiliser l'argument révision pour marquer une révision comme bonne ou mauvaise
sans le vérifier au préalable.

Si vous fournissez une commande, elle sera utilisée pour la bissection automatique. L'environnement
La variable HG_NODE contiendra l'ID de l'ensemble de modifications testé. Le statut de sortie du
sera utilisée pour marquer les révisions comme bonnes ou mauvaises : l'état 0 signifie bonne, 125 signifie à
sauter la révision, 127 (commande introuvable) annulera la bissection, et tout autre
un état de sortie différent de zéro signifie que la révision est mauvaise.

Quelques exemples:

· commencer une bissection avec une mauvaise révision 34 connue, et une bonne révision 12 :

hg bissectrice --mauvais 34
hg bissectrice --bonne 12

· faire avancer la bissection courante en marquant la révision courante comme bonne ou mauvaise :

hg bissectrice --bon
hg bissectrice --mauvais

· marquer la révision actuelle, ou une révision connue, à ignorer (par exemple si cette révision est
inutilisable à cause d'un autre problème) :

hg bissectrice --saut
hg bissectrice --saut 23

· ignorer toutes les révisions qui ne touchent pas aux répertoires foo or barre:

hg bisect --skip "!( file('path:foo') & file('path:bar') )"

· oublier la bissection courante :

hg bissectrice --reset

· utilisez 'make && make tests' pour trouver automatiquement la première révision cassée :

hg bissectrice --reset
hg bissectrice --mauvais 34
hg bissectrice --bonne 12
hg bisect --commande "faire && faire des tests"

· voir tous les changesets dont les états sont déjà connus dans la bissection courante :

hg log -r "bisect (élagué)"

· voir l'ensemble de modifications actuellement en cours de segmentation (particulièrement utile si vous utilisez
-U/--noupdate) :

hg log -r "bisect(current)"

· voir tous les ensembles de modifications qui ont participé à la bissection actuelle :

hg log -r "bisect(plage)"

· vous pouvez même obtenir un joli graphique :

hg log --graph -r "bisect(range)"

See hg aider les revets pour en savoir plus sur le couper en deux() mot-clé.

Renvoie 0 en cas de succès.

Options:

-r, --réinitialiser
réinitialiser l'état bisect

-g, --bon
marquer le jeu de modifications comme bon

-b, --mal
marquer le jeu de modifications comme mauvais

-Oui, --sauter
ignorer le test de l'ensemble de modifications

-e, --se déployer
étendre la gamme bissectrice

-c,--commander
utiliser la commande pour vérifier l'état de l'ensemble de modifications

-U, --Pas de mise à jour
ne pas mettre à jour pour cibler

signets
créer un nouveau signet ou répertorier les signets existants :

hg signets [OPTIONS]... [NOM]...

Les signets sont des étiquettes sur les ensembles de modifications pour aider à suivre les lignes de développement. Les signets sont
non versionné et peut être déplacé, renommé et supprimé. La suppression ou le déplacement d'un signet n'a pas
effet sur les ensembles de modifications associés.

La création ou la mise à jour d'un signet le marque comme « actif ». L'actif
le signet est indiqué par un '*'. Lorsqu'un commit est fait, le signet actif avancera
au nouveau commit. Une plaine hg Mise à jour fera également avancer un signet actif, si possible.
La mise à jour à partir d'un signet entraînera sa désactivation.

Les signets peuvent être poussés et tirés entre les référentiels (voir hg aider pousser ainsi que hg aider tirer
). Si un signet partagé a divergé, un nouveau " signet divergent " de la forme " nom@chemin "
sera créé. Utilisant hg fusionner résoudra la divergence.

Un signet nommé '@' a la propriété spéciale qui hg cloner va le vérifier par défaut
S'il existe.

Exemples :

· créer un signet actif pour une nouvelle ligne de développement :

nouveauté du livre hg

· créer un signet inactif comme marqueur de lieu :

hg book -j'ai revu

· créer un signet inactif sur un autre ensemble de modifications :

hg book -r .^ testé

· renommer le signet dinde en dîner :

hg book -m dîner de dinde

· déplacer le signet '@' d'une autre branche :

hg livre -f @

Options:

-F, --Obliger
forcer

-r,--tour
révision pour l'action de signet

-ré, --effacer
supprimer un signet donné

-m,--Renommer
renommer un signet donné

-je, --inactif
marquer un signet comme inactif

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

alias : signet

une succursale
définir ou afficher le nom de la branche actuelle :

branche hg [-fC] [NOM]

Remarque Les noms de branche sont permanents et globaux. Utiliser hg signet pour créer un poids léger
marque-page à la place. Voir hg aider glossaire pour plus d'informations sur les branches nommées
et des signets.

Sans argument, affiche le nom de la branche actuelle. Avec un argument, définissez le
nom de la branche du répertoire (la branche n'existera pas dans le référentiel avant le prochain commit).
La pratique standard recommande que le développement primaire ait lieu sur la branche « par défaut ».

À moins que -f/--force ne soit spécifié, la branche ne vous permettra pas de définir un nom de branche déjà
existe.

Utilisez -C/--clean pour réinitialiser la branche du répertoire de travail sur celle du parent du fichier de travail
répertoire, annulant un changement de branche précédent.

Utilisez la commande hg Mise à jour pour passer à une succursale existante. Utiliser hg commettre --fermer-branche à
marquez cette tête de branche comme fermée. Lorsque tous les responsables d'une succursale sont fermés, la succursale
être considéré comme fermé.

Renvoie 0 en cas de succès.

Options:

-F, --Obliger
définir le nom de la branche même s'il masque une branche existante

-Ç, --nettoyer
réinitialiser le nom de la branche au nom de la branche parent

branches
répertorier le référentiel nommé branches :

branches hg [-c]

Répertoriez les branches nommées du référentiel, en indiquant celles qui sont inactives. Si -c/--fermé
est spécifié, liste également les branches qui ont été marquées comme fermées (voir hg commettre
--fermer-branche).

Utilisez la commande hg Mise à jour pour passer à une succursale existante.

Retours 0.

Options:

-une, --actif
afficher uniquement les branches qui ont des têtes non fusionnées (PÉRIMÉ)

-c, --fermé
montrer des branches normales et fermées

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

pack
créer un fichier changegroup :

hg bundle [-f] [-t TYPE] [-a] [-r REV]... [--base REV]... FICHIER [DEST]

Générez un fichier de groupe de modifications collectant des ensembles de modifications à ajouter à un référentiel.

Pour créer un bundle contenant tous les ensembles de modifications, utilisez -a/--all (ou --base null). Sinon, hg
suppose que la destination aura tous les nœuds que vous spécifiez avec les paramètres --base.
Sinon, hg supposera que le référentiel a tous les nœuds dans la destination, ou
default-push/default si aucune destination n'est spécifiée.

Vous pouvez modifier le format de l'ensemble avec l'option -t/--type. Vous pouvez spécifier une compression, un
version groupée ou les deux à l'aide d'un tiret (version comp). Les méthodes de compression disponibles sont :
none, bzip2 et gzip (par défaut, les bundles sont compressés à l'aide de bzip2). Le disponible
les formats sont : v1, v2 (par défaut le plus approprié).

Le fichier bundle peut ensuite être transféré par des moyens conventionnels et appliqué à un autre
référentiel avec la commande unbundle ou pull. Ceci est utile lorsque la poussée et la traction directes sont
pas disponible ou lors de l'exportation d'un référentiel entier n'est pas souhaitable.

L'application de bundles préserve tous les contenus de l'ensemble de modifications, y compris les autorisations, copier/renommer
informations et historique des révisions.

Renvoie 0 en cas de succès, 1 si aucun changement n'est trouvé.

Options:

-F, --Obliger
exécuter même lorsque la destination n'est pas liée

-r,--tour
un ensemble de modifications destiné à être ajouté à la destination

-b,--branche
une branche spécifique que vous souhaitez regrouper

--base
un ensemble de modifications de base supposé être disponible à la destination

-une, --tout
regrouper tous les ensembles de modifications dans le référentiel

-t,--taper
type de compression de bundle à utiliser (par défaut : bzip2)

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

cat
afficher la révision actuelle ou donnée des fichiers :

hg cat [OPTION]... FICHIER...

Imprime les fichiers spécifiés tels qu'ils étaient à la révision donnée. Si aucune révision n'est donnée, le
parent du répertoire de travail est utilisé.

La sortie peut être vers un fichier, auquel cas le nom du fichier est donné en utilisant un format
chaîne de caractères. Les règles de formatage sont les suivantes :

%%

caractère littéral "%"

%s

nom de base du fichier en cours d'impression

%d

dirname du fichier en cours d'impression, ou '.' si dans la racine du référentiel

%p

chemin d'accès relatif à la racine du fichier en cours d'impression

%H

hash de l'ensemble de modifications (40 chiffres hexadécimaux)

%R

numéro de révision de l'ensemble de modifications

%h

hachage abrégé de l'ensemble de modifications (12 chiffres hexadécimaux)

%r

numéro de révision de l'ensemble de modifications complété par des zéros

%b

nom de base du référentiel d'exportation

Renvoie 0 en cas de succès.

Options:

-o,--output
imprimer la sortie dans un fichier avec un nom formaté

-r,--tour
imprimer la révision donnée

--décoder
appliquer n'importe quel filtre de décodage correspondant

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

cloner
faire une copie d'un dépôt existant :

clone hg [OPTION]... SOURCE [DEST]

Créez une copie d'un référentiel existant dans un nouveau répertoire.

Si aucun nom de répertoire de destination n'est spécifié, il prend par défaut le nom de base de la source.

L'emplacement de la source est ajouté au nouveau référentiel .hg/hgrc fichier, par défaut
à utiliser pour les futurs tirages.

Seuls les chemins locaux et chut:// Les URL sont prises en charge en tant que destinations. Pour chut:// destinations,
pas de répertoire de travail ou .hg/hgrc sera créé sur le côté distant.

Si le référentiel source a un signet appelé '@' défini, cette révision sera extraite
dans le nouveau référentiel par défaut.

Pour extraire une version particulière, utilisez -u/--update, ou -U/--noupdate pour créer un clone
sans répertoire de travail.

Pour extraire uniquement un sous-ensemble d'ensembles de modifications, spécifiez un ou plusieurs identifiants de révision avec
-r/--rev ou branches avec -b/--branch. Le clone résultant contiendra uniquement le
ensembles de modifications et leurs ancêtres. Ces options (ou 'clone src#rev dest') impliquent --pull, même
pour les référentiels sources locaux.

Remarque La spécification d'une balise inclura l'ensemble de modifications étiqueté mais pas l'ensemble de modifications contenant
la balise.

Pour plus d'efficacité, les liens physiques sont utilisés pour le clonage chaque fois que la source et la destination sont activées
le même système de fichiers (notez que cela s'applique uniquement aux données du référentiel, pas au
annuaire). Certains systèmes de fichiers, tels que AFS, implémentent incorrectement les liens physiques, mais ne le font pas.
signaler les erreurs. Dans ces cas, utilisez l'option --pull pour éviter les liens physiques.

Dans certains cas, vous pouvez cloner des référentiels et le répertoire de travail en utilisant des liens physiques complets
avec

$ cp -al REPO REPOCLONE

C'est le moyen le plus rapide de cloner, mais ce n'est pas toujours sûr. L'opération n'est pas atomique
(il vous appartient de vous assurer que REPO n'est pas modifié pendant l'opération) et vous devez faire
Assurez-vous que votre éditeur casse les liens physiques (Emacs et la plupart des outils du noyau Linux le font). Aussi, c'est
non compatible avec certaines extensions qui placent leurs métadonnées sous le répertoire .hg,
tels que mq.

Mercurial mettra à jour le répertoire de travail avec la première révision applicable à partir de ce
liste:

une. null si -U ou le référentiel source n'a aucun ensemble de modifications

b. si tu . et le référentiel source est local, le premier parent du référentiel source
directeur de travail

c. l'ensemble de modifications spécifié avec -u (s'il s'agit d'un nom de branche, cela signifie le dernier en-tête de cette
branche)

ré. l'ensemble de modifications spécifié avec -r

e. la tête la plus avancée spécifiée avec -b

F. la tête la plus avancée spécifiée avec la syntaxe source url#branch

g. la révision marquée du signet '@', si présent

h. la tête la plus avancée de la branche par défaut

je. pointe

Lors du clonage à partir de serveurs qui le prennent en charge, Mercurial peut récupérer des données pré-générées à partir d'un
URL annoncée par le serveur. Lorsque cela est fait, les hooks opérant sur les ensembles de modifications entrants et
changegroups peut se déclencher deux fois, une pour le bundle récupéré à partir de l'URL et une autre pour tout
données supplémentaires non récupérées à partir de cette URL. De plus, si une erreur se produit, le référentiel
peut être ramené à un clone partiel. Ce comportement peut changer dans les versions futures. Voir hg
aider -e lots de clones pour plus d'information.

Exemples :

· cloner un référentiel distant dans un nouveau répertoire nommé hg/ :

clone de hg http://selenic.com/hg

· créer un clone local léger :

hg projet clone/ projet-fonctionnalité/

· cloner à partir d'un chemin absolu sur un serveur ssh (notez la double barre oblique) :

hg clone ssh://user@server//home/projects/alpha/

· faire un clonage à grande vitesse sur un réseau local tout en vérifiant une version spécifiée :

hg clone --non compressé http://server/repo -u 1.5

· créer un référentiel sans ensembles de modifications après une révision particulière :

hg clone -r 04e544 expérimental/ bon/

· cloner (et suivre) une branche nommée particulière :

clone de hg http://selenic.com/hg#écurie

See hg aider urls pour plus de détails sur la spécification des URL.

Renvoie 0 en cas de succès.

Options:

-U, --Pas de mise à jour
le clone inclura un répertoire de travail vide (uniquement un référentiel)

-tu,--updaterev
révision, balise ou branche à extraire

-r,--tour
inclure l'ensemble de modifications spécifié

-b,--branche
cloner uniquement la branche spécifiée

--tirer utiliser le protocole pull pour copier les métadonnées

--non compressé
utiliser un transfert non compressé (rapide sur LAN)

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

commettre
valider les fichiers spécifiés ou toutes les modifications en attente :

hg commit [OPTION]... [FICHIER]...

Validez les modifications apportées aux fichiers donnés dans le référentiel. Contrairement à un SCM centralisé, ce
l'opération est une opération locale. Voir hg pousser pour un moyen de diffuser activement vos modifications.

Si une liste de fichiers est omise, toutes les modifications signalées par hg statuts sera engagé.

Si vous validez le résultat d'une fusion, ne fournissez aucun nom de fichier ou -I/-X
filtres

Si aucun message de validation n'est spécifié, Mercurial démarre votre éditeur configuré où vous pouvez
entrer un message. En cas d'échec de votre validation, vous trouverez une sauvegarde de votre message dans
.hg/dernier-message.txt.

L'indicateur --close-branch peut être utilisé pour marquer la tête de branche actuelle fermée. Quand toutes les têtes
d'une succursale sont fermées, la succursale sera considérée comme fermée et ne sera plus répertoriée.

L'indicateur --amend peut être utilisé pour modifier le parent du répertoire de travail avec un nouveau
commit qui contient les changements dans le parent en plus de ceux actuellement signalés par
hg statuts, s'il y en a. L'ancien commit est stocké dans un bundle de sauvegarde dans
.hg/strip-sauvegarde (voir hg aider pack ainsi que hg aider dégrouper sur la façon de le restaurer).

Le message, l'utilisateur et la date sont extraits du commit modifié, sauf indication contraire. Lorsqu'un message
n'est pas spécifié sur la ligne de commande, l'éditeur s'ouvrira avec le message de la modification
s'engager.

Il n'est pas possible de modifier les ensembles de modifications publics (voir hg aider phases) ou des ensembles de modifications qui ont
enfants.

See hg aider dates pour une liste de formats valides pour -d/--date.

Renvoie 0 en cas de succès, 1 si rien n'a changé.

Exemples :

· commit tous les fichiers se terminant par .py :

hg commit --include "set:**.py"

· commiter tous les fichiers non binaires :

hg commit --exclude "set:binary()"

· modifiez le commit actuel et définissez la date sur maintenant :

hg commit --amender --date maintenant

Options:

-UNE, --Ajouter enlever
marquer les fichiers nouveaux/manquants comme ajoutés/supprimés avant de valider

--fermer-branche
marquer une tête de branche comme fermée

--modifier
modifier le parent du répertoire de travail

-Oui, --secrète
utiliser la phase secrète pour s'engager

-e, --modifier
invoquer l'éditeur sur les messages de validation

-je, --interactif
utiliser le mode interactif

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

alias : ci

config
afficher les paramètres de configuration combinés de tous les fichiers hgrc :

hg config [-u] [NOM]...

Sans arguments, imprimez les noms et les valeurs de tous les éléments de configuration.

Avec un argument de la forme section.name, imprimez uniquement la valeur de cet élément de configuration.

Avec plusieurs arguments, imprimez les noms et les valeurs de tous les éléments de configuration avec la section correspondante
des noms.

Avec --edit, démarrez un éditeur sur le fichier de configuration au niveau utilisateur. Avec --global, modifiez le
fichier de configuration à l'échelle du système. Avec --local, modifiez le fichier de configuration au niveau du référentiel.

Avec --debug, la source (nom de fichier et numéro de ligne) est imprimée pour chaque élément de configuration.

See hg aider config pour plus d'informations sur les fichiers de configuration.

Renvoie 0 en cas de succès, 1 si NAME n'existe pas.

Options:

-tu, --non fiable
afficher les options de configuration non fiables

-e, --modifier
modifier la configuration utilisateur

-l, --locale
modifier la configuration du référentiel

-g, --mondial
modifier la configuration globale

alias : showconfig debugconfig

copier
marquer les fichiers comme copiés pour le prochain commit :

hg copier [OPTION]... [SOURCE]... DEST

Marquez dest comme ayant des copies des fichiers source. Si dest est un répertoire, des copies sont mises dans ce
annuaire. Si dest est un fichier, la source doit être un fichier unique.

Par défaut, cette commande copie le contenu des fichiers tels qu'ils existent dans le
annuaire. Si invoqué avec -A/--after, l'opération est enregistrée, mais aucune copie n'est
effectué.

Cette commande prend effet au prochain commit. Pour annuler une copie avant cela, voir hg revenir.

Renvoie 0 en cas de succès, 1 si des erreurs sont rencontrées.

Options:

-UNE, --après
enregistrer une copie qui a déjà eu lieu

-F, --Obliger
copier de force sur un fichier géré existant

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

L'option marquée [+] peut être spécifiée plusieurs fois

alias : cp

diff
référentiel diff (ou fichiers sélectionnés) :

hg diff [OPTION]... ([-c REV] | [-r REV1 [-r REV2]]) [FICHIER]...

Afficher les différences entre les révisions pour les fichiers spécifiés.

Les différences entre les fichiers sont affichées à l'aide du format diff unifié.

Notes hg diff peut générer des résultats inattendus pour les fusions, car il s'agira par défaut de comparer
par rapport au premier ensemble de modifications parent du répertoire de travail si aucune révision n'est
spécifié.

Lorsque deux arguments de révision sont fournis, les modifications sont affichées entre ces révisions. Si
une seule révision est spécifiée puis cette révision est comparée au répertoire de travail,
et, lorsqu'aucune révision n'est spécifiée, les fichiers du répertoire de travail sont comparés à ses
premier parent.

Alternativement, vous pouvez spécifier -c/--change avec une révision pour voir les changements dans ce
changeset par rapport à son premier parent.

Sans l'option -a/--text, diff évitera de générer des différences de fichiers qu'il détecte comme
binaire. Avec -a, diff générera un diff de toute façon, probablement avec des résultats indésirables.

Utilisez l'option -g/--git pour générer des diff au format de diff étendu git. Pour plus
informations, lire hg aider différences.

Exemples :

· comparer un fichier du répertoire de travail courant à son parent :

hg diff foo.c

· comparer deux versions historiques d'un répertoire, avec les informations de renommage :

hg diff --git -r 1.0:1.2 lib/

· obtenir des statistiques de changement relatives au dernier changement à une date :

hg diff --stat -r "date('2 mai')"

· Diff tous les fichiers nouvellement ajoutés qui contiennent un mot-clé :

hg diff "set:added() et grep(GNU)"

· comparer une révision et ses parents :

hg diff -c 9353 # comparer avec le premier parent
hg diff -r 9353^:9353 # même chose en utilisant la syntaxe revset
hg diff -r 9353^2:9353 # comparer avec le deuxième parent

Renvoie 0 en cas de succès.

Options:

-r,--tour
révision

-c,--monnaie
modification apportée par révision

-une, --texte
traiter tous les fichiers comme du texte

-g, --git
utiliser le format de diff étendu git

--nodate
omettre les dates des en-têtes diff

--pas de préfixe
omettre les préfixes a/ et b/ des noms de fichiers

-p, --show-fonction
montrer dans quelle fonction se trouve chaque changement

--sens inverse
produire un diff qui annule les changements

-w, --ignore-tout-espace
ignorer les espaces blancs lors de la comparaison de lignes

-b, --ignore-changement d'espace
ignorer les changements dans la quantité d'espace blanc

-B, --ignore-lignes-vides
ignorer les modifications dont toutes les lignes sont vides

-U,--unifié
nombre de lignes de contexte à afficher

--stat sortie résumé des modifications de style diffstat

--racine
produire des différences relatives au sous-répertoire

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

Exporter
videz l'en-tête et les différences pour un ou plusieurs ensembles de modifications :

hg export [OPTION]... [-o OUTFILESPEC] [-r] [REV]...

Imprimez l'en-tête et les différences de l'ensemble de modifications pour une ou plusieurs révisions. Si aucune révision n'est donnée,
le parent du répertoire de travail est utilisé.

Les informations affichées dans l'en-tête de l'ensemble de modifications sont : auteur, date, nom de la branche (si
non par défaut), hash de l'ensemble de modifications, parent(s) et commentaire de validation.

Notes hg Exporter peut générer une sortie diff inattendue pour les ensembles de modifications de fusion, car cela
comparer l'ensemble de modifications de fusion à son premier parent uniquement.

La sortie peut être vers un fichier, auquel cas le nom du fichier est donné en utilisant un format
chaîne de caractères. Les règles de formatage sont les suivantes :

%%

caractère littéral "%"

%H

hash de l'ensemble de modifications (40 chiffres hexadécimaux)

%N

nombre de patchs générés

%R

numéro de révision de l'ensemble de modifications

%b

nom de base du référentiel d'exportation

%h

hachage abrégé de l'ensemble de modifications (12 chiffres hexadécimaux)

%m

première ligne du message de validation (uniquement des caractères alphanumériques)

%n

numéro de séquence complété par des zéros, commençant à 1

%r

numéro de révision de l'ensemble de modifications complété par des zéros

Sans l'option -a/--text, l'exportation évitera de générer des différences de fichiers qu'il détecte comme
binaire. Avec -a, l'exportation générera de toute façon un diff, probablement avec des résultats indésirables.

Utilisez l'option -g/--git pour générer des diff au format de diff étendu git. Voir hg aider
différences pour plus d'information.

Avec l'option --switch-parent, la différence sera contre le deuxième parent. Ça peut être
utile pour revoir une fusion.

Exemples :

· utilisez l'export et l'import pour transplanter une correction de bogue dans la branche actuelle :

hg export -r 9353 | importation de hg -

· exporter tous les ensembles de modifications entre deux révisions dans un fichier avec les informations de renommage :

hg export --git -r 123:150 > changes.txt

· fractionner les modifications sortantes en une série de correctifs avec des noms descriptifs :

hg export -r "sortant()" -o "%n-%m.patch"

Renvoie 0 en cas de succès.

Options:

-o,--output
imprimer la sortie dans un fichier avec un nom formaté

--switch-parent
diff contre le deuxième parent

-r,--tour
révisions à exporter

-une, --texte
traiter tous les fichiers comme du texte

-g, --git
utiliser le format de diff étendu git

--nodate
omettre les dates des en-têtes diff

L'option marquée [+] peut être spécifiée plusieurs fois

fichiers
lister les fichiers suivis :

hg fichiers [OPTION]... [MOTIF]...

Imprimer les fichiers sous contrôle Mercurial dans le répertoire de travail ou la révision spécifiée dont
les noms correspondent aux modèles donnés (à l'exclusion des fichiers supprimés).

Si aucun modèle n'est donné pour correspondre, cette commande imprime les noms de tous les fichiers sous
Contrôle Mercurial dans le répertoire de travail.

Exemples :

· liste tous les fichiers du répertoire courant :

hg fichiers .

· affiche les tailles et les drapeaux pour la révision actuelle :

hg fichiers -vr .

· liste tous les fichiers nommés README :

hg fichiers -I "**/README"

· lister tous les fichiers binaires :

hg fichiers "set:binary()"

· rechercher des fichiers contenant une expression régulière :

hg fichiers "set:grep('bob')"

· rechercher le contenu des fichiers suivis avec xargs et grep :

hg fichiers -0 | xargs -0 grep foo

See hg aider motifs ainsi que hg aider ensembles de fichiers pour plus d'informations sur la spécification du fichier
modèles

Renvoie 0 si une correspondance est trouvée, 1 sinon.

Options:

-r,--tour
rechercher dans le référentiel tel qu'il est dans REV

-0, --print0
terminer les noms de fichiers avec NUL, à utiliser avec xargs

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

oublier
oubliez les fichiers spécifiés lors du prochain commit :

hg oublier [OPTION]... FICHIER...

Marquez les fichiers spécifiés afin qu'ils ne soient plus suivis après le prochain commit.

Cela ne supprime que les fichiers de la branche actuelle, pas de tout l'historique du projet, et
il ne les supprime pas du répertoire de travail.

Pour supprimer le fichier du répertoire de travail, consultez hg supprimez.

Pour annuler un oubli avant le prochain commit, voir hg ajouter.

Exemples :

· oubliez les fichiers binaires nouvellement ajoutés :

hg oublier "set:added() et binary()"

· oubliez les fichiers qui seraient exclus par .hgignore :

hg oublier "set:hgignore()"

Renvoie 0 en cas de succès.

Options:

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

greffer
copier les modifications des autres branches sur la branche actuelle :

hg greffe [OPTION]... [-r REV]... REV...

Cette commande utilise la logique de fusion de Mercurial pour copier les modifications individuelles d'autres branches
sans fusionner les branches dans le graphique d'historique. Ceci est parfois appelé « backportage » ou
« cueillette de cerises ». Par défaut, Greffe copiera l'utilisateur, la date et la description de la source
ensembles de modifications.

Les ensembles de modifications qui sont les ancêtres de la révision actuelle, qui ont déjà été greffés, ou
qui sont des fusions seront ignorées.

Si --log est spécifié, les messages du journal seront accompagnés d'un commentaire de la forme :

(greffé de CHANGESETHASH)

Si --force est spécifié, les révisions seront greffées même si elles sont déjà les ancêtres de
ou ont été greffés à la destination. Ceci est utile lorsque les révisions ont depuis
été reculé.

Si une fusion de greffe entraîne des conflits, le processus de greffe est interrompu de sorte que le
la fusion actuelle peut être résolue manuellement. Une fois tous les conflits réglés, la greffe
Le processus peut être poursuivi avec l'option -c/--continue.

Remarque L'option -c/--continue ne réapplique pas les options précédentes, à l'exception de --force.

Exemples :

· copier une seule modification dans la branche stable et éditer sa description :

hg mise à jour stable
greffon hg --modifier 9393

· greffer une plage de changesets à une exception près, les dates de mise à jour :

greffon hg -D "2085::2093 et ​​non 2091"

· continuer une greffe après résolution des conflits :

greffon hg -c

· montrer la source d'un ensemble de modifications greffé :

hg journal --debug -r .

· afficher les révisions triées par date :

hg log -r 'trier(tout(), date)'

See hg aider révisions ainsi que hg aider les revets pour en savoir plus sur la spécification des révisions.

Renvoie 0 en cas de réussite.

Options:

-r,--tour
révisions à greffer

-c, --Continuez
reprendre la greffe interrompue

-e, --modifier
invoquer l'éditeur sur les messages de validation

--Journal ajouter des informations sur la greffe au message de journal

-F, --Obliger
forcer la greffe

-RÉ, --date actuelle
enregistrer la date du jour comme date de validation

-U, --utilisateur actuel
enregistrer l'utilisateur actuel en tant que commiter

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

-t,--outil
spécifier l'outil de fusion

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

L'option marquée [+] peut être spécifiée plusieurs fois

grep
rechercher un modèle dans les fichiers et les révisions spécifiés :

hg grep [OPTION]... MOTIF [FICHIER]...

Rechercher des révisions de fichiers pour une expression régulière.

Cette commande se comporte différemment de grep Unix. Il accepte uniquement les expressions régulières Python/Perl. Ce
recherche l'historique du référentiel, pas le répertoire de travail. Il imprime toujours la révision
numéro dans lequel apparaît une correspondance.

Par défaut, grep n'imprime que la sortie de la première révision d'un fichier dans lequel il trouve un
correspondre. Pour qu'il imprime chaque révision qui contient un changement d'état de correspondance ("-" pour un
correspondance qui devient une non-correspondance, ou "+" pour une non-correspondance qui devient une correspondance), utilisez le
--tous les drapeaux.

Renvoie 0 si une correspondance est trouvée, 1 sinon.

Options:

-0, --print0
champs de fin avec NUL

--tout imprimer toutes les révisions qui correspondent

-une, --texte
traiter tous les fichiers comme du texte

-F, --poursuivre
suivre l'historique des modifications ou l'historique des fichiers à travers les copies et les renommages

-je, --ignore-cas
ignorer la casse lors de la correspondance

-l, --files-with-matchs
imprimer uniquement les noms de fichiers et les révisions qui correspondent

-n, --numéro de ligne
imprimer les numéros de ligne correspondants

-r,--tour
rechercher uniquement les fichiers modifiés dans la plage de révision

-tu, --utilisateur
liste l'auteur (avec -v)

-ré, --Date
liste la date (court avec -q)

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

têtes
afficher les chefs de branche :

hg head [-ct] [-r STARTREV] [REV]...

Sans arguments, affiche toutes les têtes de branche ouvertes dans le référentiel. Les chefs de succursale sont
ensembles de modifications qui n'ont pas de descendants sur la même branche. Ils sont là où le développement
a généralement lieu et sont les cibles habituelles des opérations de mise à jour et de fusion.

Si un ou plusieurs REV sont donnés, n'ouvrez que les têtes de dérivation sur les dérivations associées au
les ensembles de modifications spécifiés sont affichés. Cela signifie que vous pouvez utiliser hg têtes . voir les têtes
la branche actuellement extraite.

Si -c/--closed est spécifié, affiche également les têtes de branche marquées fermées (voir hg commettre
--fermer-branche).

Si STARTREV est spécifié, seules les têtes descendantes de STARTREV seront
affiché.

Si -t/--topo est spécifié, les mécanismes de branche nommés seront ignorés et uniquement topologiques
têtes (changesets sans enfants) seront affichés.

Renvoie 0 si des têtes correspondantes sont trouvées, 1 sinon.

Options:

-r,--tour
afficher uniquement les têtes descendantes de STARTREV

-t, --topo
afficher uniquement les têtes topologiques

-une, --actif
afficher uniquement les branches actives (PÉRIMÉ)

-c, --fermé
montrer les têtes de branches normales et fermées

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

aider
afficher l'aide pour un sujet donné ou un aperçu de l'aide :

hg help [-ecks] [SUJET]

Sans arguments, imprime une liste de commandes avec de courts messages d'aide.

Étant donné une rubrique, une extension ou un nom de commande, imprimez l'aide pour cette rubrique.

Renvoie 0 en cas de succès.

Options:

-e, --extension
afficher uniquement l'aide pour les extensions

-c, --commander
afficher uniquement l'aide pour les commandes

-k, --mot-clé
afficher les sujets correspondant au mot clé

-Oui,--système
afficher l'aide pour des plates-formes spécifiques

L'option marquée [+] peut être spécifiée plusieurs fois

identifier
identifier le répertoire de travail ou la révision spécifiée :

hg identifier [-nibtB] [-r REV] [SOURCE]

Imprimer un résumé identifiant l'état du référentiel à REV en utilisant un ou deux hachage parent
identificateurs, suivis d'un "+" si le répertoire de travail a des modifications non validées, le
le nom de la branche (s'il n'est pas par défaut), une liste de balises et une liste de signets.

Lorsque REV n'est pas fourni, imprimez un résumé de l'état actuel du référentiel.

La spécification d'un chemin d'accès à une racine de référentiel ou à un bundle Mercurial entraînera l'exécution de la recherche
ce référentiel/ensemble.

Exemples :

· générer un identifiant de build pour le répertoire de travail :

hg id --id > build-id.dat

· trouver la révision correspondant à une balise :

hg identifiant -n -r 1.3

· vérifier la révision la plus récente d'un référentiel distant :

hg id -r astuce http://selenic.com/hg/

See hg enregistrer pour générer plus d'informations sur des révisions spécifiques, y compris le hachage complet
identifiants.

Renvoie 0 en cas de succès.

Options:

-r,--tour
identifier la révision spécifiée

-n, --numéro
afficher le numéro de révision local

-je, --identifiant
afficher l'identifiant de révision global

-b, --branche
montrer la branche

-t, --Mots clés
Voir les étiquettes

-B, --signets
afficher les signets

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

alias : identifiant

importer
importer un ensemble ordonné de correctifs :

hg import [OPTION]... CORRECTION...

Importez une liste de correctifs et validez-les individuellement (sauf si --no-commit est spécifié).

Pour lire un patch depuis l'entrée standard, utilisez "-" comme nom de patch. Si une URL est spécifiée, le
patch sera téléchargé à partir de là.

L'importation applique d'abord les modifications au répertoire de travail (sauf si --bypass est spécifié),
l'importation s'arrêtera s'il y a des changements en suspens.

Utilisez --bypass pour appliquer et valider les correctifs directement dans le référentiel, sans affecter le
directeur de travail. Sans --exact, les correctifs seront appliqués sur le travail
révision parent du répertoire.

Vous pouvez importer un patch directement à partir d'un message électronique. Même les correctifs en tant que pièces jointes fonctionnent (pour
utilisez la partie body, elle doit être de type text/plain ou text/x-patch). En-têtes De et Objet
des e-mails sont utilisés comme commiteur et message de validation par défaut. Tout le texte/corps simple
les parties avant le premier diff sont ajoutées au message de validation.

Si le patch importé a été généré par hg Exporter, utilisateur et description du remplacement de correctif
les valeurs des en-têtes et du corps du message. Valeurs données en ligne de commande avec -m/--message et
-u/--user remplace ces derniers.

Si --exact est spécifié, import définira le répertoire de travail sur le parent de chaque patch
avant de l'appliquer, et s'arrêtera si l'ensemble de modifications résultant a un ID différent de celui
un enregistré dans le patch. Cela peut se produire en raison de problèmes de jeu de caractères ou d'autres
lacunes dans le format de patch de texte.

Utilisez --partial pour vous assurer qu'un ensemble de modifications sera créé à partir du correctif même si certains morceaux échouent
postuler. Les gros morceaux qui ne s'appliquent pas seront écrits sur un fichier .rej. Conflits
peut alors être résolu à la main avant hg commettre --modifier est exécuté pour mettre à jour le créé
ensemble de modifications. Ce drapeau existe pour permettre aux utilisateurs d'importer des correctifs qui s'appliquent partiellement sans
perdre les métadonnées associées (auteur, date, description, ...).

Remarque Lorsqu'aucun morceau ne s'applique proprement, hg importer --partiel va créer un ensemble de modifications vide,
importer uniquement les métadonnées du correctif.

Avec -s/--similarity, hg tentera de découvrir les renommages et les copies dans le patch dans le
de la même manière que hg Ajouter enlever.

Il est possible d'utiliser des programmes de patch externes pour effectuer le patch en réglant le interface utilisateur.patch
possibilité de configuration. Pour l'outil interne par défaut, le fuzz peut également être configuré via
patch.fuzz. Voir hg aider config pour plus d'informations sur les fichiers de configuration et comment
utilisez ces options.

See hg aider dates pour une liste de formats valides pour -d/--date.

Exemples :

· importer un patch traditionnel depuis un site web et détecter les renommages :

importation hg -s 80 http://example.com/bugfix.patch

· importer un ensemble de modifications depuis un serveur hgweb :

importation de hg http://www.selenic.com/hg/rev/5ca8c111e9aa

· importer tous les correctifs dans une mbox de style Unix :

hg importer les correctifs entrants.mbox

· tenter de restaurer exactement un ensemble de modifications exporté (pas toujours possible) :

hg import --exact proposition-fixe.patch

· utiliser un outil externe pour appliquer un patch trop flou pour l'outil interne par défaut.

hg import --config ui.patch="patch --merge" fuzzy.patch

· changer le fuzzing par défaut de 2 à un 7 moins strict

hg import --config ui.fuzz=7 fuzz.patch

Renvoie 0 en cas de succès, 1 en cas de succès partiel (voir --partial).

Options:

-p,--déshabiller
option de bande de répertoire pour le correctif. Cela a le même sens que le correspondant
option de correctif (par défaut : 1)

-b,--base
chemin de base (PÉRIMÉ)

-e, --modifier
invoquer l'éditeur sur les messages de validation

-F, --Obliger
ignorer la vérification des modifications non validées en suspens (PÉRIMÉ)

--sans engagement
ne vous engagez pas, mettez simplement à jour le répertoire de travail

--contourne
appliquer le correctif sans toucher au répertoire de travail

--partiel
s'engager même si certains mecs échouent

--exact
appliquer le correctif aux nœuds à partir desquels il a été généré

--préfixe
appliquer le correctif au sous-répertoire

--import-branche
utiliser n'importe quelle information de branche dans patch (implicite par --exact)

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

-Oui,--similarité
devinez les fichiers renommés par similarité (0<=s<=100)

alias : patch

nouveau
afficher les nouveaux ensembles de modifications trouvés dans la source :

hg entrant [-p] [-n] [-M] [-f] [-r REV]... [--bundle FILENAME] [SOURCE]

Afficher les nouveaux ensembles de modifications trouvés dans le chemin/l'URL spécifié ou l'emplacement d'extraction par défaut. Ces
sont les ensembles de modifications qui auraient été extraits si un extrait au moment où vous avez émis ce
commander.

Voir pull pour les détails du format source valide.

Avec -B/--bookmarks, le résultat de la comparaison des signets entre local et distant
référentiels s'affiche. Avec -v/--verbose, le statut est également affiché pour chaque signet
comme ci-dessous:

BM1 01234567890a ajouté
BM2 1234567890ab avancé
BM3 234567890abc a divergé
BM4 34567890abcd modifié

L'action entreprise localement lors de l'extraction dépend de l'état de chaque signet :

ajoutée

tirer le créera

Avancée

pull le mettra à jour

divergé

pull va créer un signet divergent

modifié

le résultat dépend des ensembles de modifications distants

Du point de vue du comportement de tirage, signet existant uniquement dans la télécommande
référentiel sont traités comme ajoutée, même s'il est en fait supprimé localement.

Pour le référentiel distant, l'utilisation de --bundle évite de télécharger deux fois les ensembles de modifications si le
entrant est suivi d'un pull.

Exemples :

· afficher les modifications entrantes avec des correctifs et une description complète :

hg entrant -vp

· afficher les modifications entrantes à l'exclusion des fusions, stocker un bundle :

hg dans -vpM --bundle entrant.hg
hg tirer entrant.hg

· énumérer brièvement les modifications à l'intérieur d'un paquet :

hg dans changes.hg -T "{desc|firstline}\n"

Renvoie 0 s'il y a des changements entrants, 1 sinon.

Options:

-F, --Obliger
exécuter même si le référentiel distant n'est pas lié

-n, --le plus récent d'abord
afficher le plus récent enregistrement en premier

--empaqueter
fichier dans lequel stocker les bundles

-r,--tour
un ensemble de modifications distant destiné à être ajouté

-B, --signets
comparer les signets

-b,--branche
une branche spécifique que vous voudriez tirer

-p, --pièce
montrer le patch

-g, --git
utiliser le format de diff étendu git

-l,--limite
nombre limite de modifications affichées

-M, --no-fusions
ne pas afficher les fusions

--stat sortie résumé des modifications de style diffstat

-G, --graphique
afficher le DAG de révision

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

alias : dans

init
créer un nouveau dépôt dans le répertoire donné :

hg init [-e CMD] [--remotecmd CMD] [DEST]

Initialiser un nouveau référentiel dans le répertoire donné. Si le répertoire donné n'existe pas,
il sera créé.

Si aucun répertoire n'est donné, le répertoire courant est utilisé.

Il est possible de spécifier un chut:// URL comme destination. Voir hg aider urls pour plus d'
</br>L’Information.

Renvoie 0 en cas de succès.

Options:

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

localiser
localiser les fichiers correspondant à des modèles spécifiques (PÉRIMÉ) :

hg localisez [OPTION]... [MOTIF]...

Imprimer les fichiers sous contrôle Mercurial dans le répertoire de travail dont les noms correspondent au
modèles

Par défaut, cette commande recherche tous les répertoires du répertoire de travail. Pour chercher juste
le répertoire courant et ses sous-répertoires, utilisez "--include .".

Si aucun modèle n'est donné pour correspondre, cette commande imprime les noms de tous les fichiers sous
Contrôle Mercurial dans le répertoire de travail.

Si vous souhaitez alimenter la sortie de cette commande dans la commande "xargs", utilisez l'option -0
à la fois cette commande et "xargs". Cela évitera le problème de "xargs" traitant des
les noms de fichiers qui contiennent des espaces en tant que noms de fichiers multiples.

See hg aider fichiers pour une commande plus polyvalente.

Renvoie 0 si une correspondance est trouvée, 1 sinon.

Options:

-r,--tour
rechercher dans le référentiel tel qu'il est dans REV

-0, --print0
terminer les noms de fichiers avec NUL, à utiliser avec xargs

-F, --chemin complet
imprimer les chemins complets à partir de la racine du système de fichiers

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

enregistrer
afficher l'historique des révisions de l'intégralité du référentiel ou des fichiers :

hg log [OPTION]... [FICHIER]

Imprimez l'historique des révisions des fichiers spécifiés ou de l'ensemble du projet.

Si aucune plage de révision n'est spécifiée, la valeur par défaut est conseil : 0 sauf si --follow est défini, dans lequel
cas, le répertoire de travail parent est utilisé comme révision de départ.

L'historique des fichiers est affiché sans renommer ou copier l'historique des fichiers. Utilisez -f/--suivre
avec un nom de fichier pour suivre l'historique à travers les renommages et les copies. --follow sans nom de fichier
affichera uniquement les ancêtres ou les descendants de la révision de départ.

Par défaut, cette commande imprime le numéro de révision et l'identifiant de l'ensemble de modifications, les balises, non triviales
parents, utilisateur, date et heure, et un résumé pour chaque commit. Lorsque le commutateur -v/--verbose
est utilisé, la liste des fichiers modifiés et le message de validation complet sont affichés.

Avec --graph, les révisions sont affichées sous la forme d'un DAG d'art ASCII avec le jeu de modifications le plus récent à
haut. 'o' est un ensemble de modifications, '@' est un répertoire parent de travail, 'x' est obsolète et '+'
représente un fork où le changeset des lignes ci-dessous est un parent de la fusion 'o' sur
la même ligne.

Notes hg enregistrer --pièce peut générer une sortie diff inattendue pour les ensembles de modifications de fusion, car cela
comparer uniquement l'ensemble de modifications de fusion à son premier parent. De plus, seuls les fichiers
différent des DEUX parents apparaîtra dans les fichiers :.

Remarque Pour des raisons de performances, hg enregistrer DOSSIER peut omettre les modifications en double effectuées sur les branches
et n'affichera pas les suppressions ou les changements de mode. Pour voir tous ces changements, utilisez le
--commutateur supprimé.

Quelques exemples:

· ensembles de modifications avec descriptions complètes et listes de fichiers :

hg journal -v

· ensembles de modifications ancestraux du répertoire de travail :

hg journal -f

· les 10 derniers commits sur la branche actuelle :

hg journal -l 10 -b .

· ensembles de modifications montrant toutes les modifications d'un fichier, y compris les suppressions :

hg log --fichier supprimé.c

· tous les ensembles de modifications qui touchent un répertoire, avec les différences, à l'exclusion des fusions :

hg log -Mp lib/

· tous les numéros de révision qui correspondent à un mot-clé :

hg log -k bug --template "{rev}\n"

· l'identifiant de hachage complet du parent du répertoire de travail :

hg log -r . --template "{nœud}\n"

· lister les modèles de journaux disponibles :

hg log -T liste

· vérifier si un ensemble de modifications donné est inclus dans une version balisée :

hg log -r "a21ccf et ancêtre(1.9)"

· trouver tous les ensembles de modifications d'un utilisateur dans une plage de dates :

hg log -k alice -d "mai 2008 à juillet 2008"

· résumé de tous les ensembles de modifications après la dernière balise :

hg log -r "last(tagged())::" --template "{desc|firstline}\n"

See hg aider dates pour une liste de formats valides pour -d/--date.

See hg aider révisions ainsi que hg aider les revets pour en savoir plus sur la spécification et la commande
révisions.

See hg aider modèles pour en savoir plus sur les styles préemballés et la spécification de modèles personnalisés.

Renvoie 0 en cas de succès.

Options:

-F, --poursuivre
suivre l'historique des modifications ou l'historique des fichiers à travers les copies et les renommages

--suivre d'abord
suivre uniquement le premier parent des ensembles de modifications de fusion (PÉRIMÉ)

-ré,--Date
afficher les révisions correspondant aux spécifications de date

-Ç, --copies
afficher les fichiers copiés

-k,--mot-clé
faire une recherche insensible à la casse pour un texte donné

-r,--tour
afficher la révision ou le revset spécifié

--supprimé
inclure les révisions où les fichiers ont été supprimés

-m, --only-fusions
afficher uniquement les fusions (PÉRIMÉ)

-tu,--utilisateur
révisions validées par l'utilisateur

--seulement-branche
afficher uniquement les ensembles de modifications dans la branche nommée donnée (PÉRIMÉ)

-b,--branche
afficher les ensembles de modifications dans la branche nommée donnée

-P,--prune
ne pas afficher la révision ou aucun de ses ancêtres

-p, --pièce
montrer le patch

-g, --git
utiliser le format de diff étendu git

-l,--limite
nombre limite de modifications affichées

-M, --no-fusions
ne pas afficher les fusions

--stat sortie résumé des modifications de style diffstat

-G, --graphique
afficher le DAG de révision

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

alias : historique

manifeste
afficher la révision actuelle ou donnée du manifeste du projet :

manifeste hg [-r REV]

Imprimer une liste de fichiers contrôlés par version pour la révision donnée. Si aucune révision n'est donnée,
le premier parent du répertoire de travail est utilisé, ou la révision nulle si aucune révision n'est
vérifié.

Avec -v, imprimez les autorisations de fichier, le lien symbolique et les bits exécutables. Avec --debug, imprimer le fichier
hachages de révision.

Si l'option --all est spécifiée, la liste de tous les fichiers de toutes les révisions est imprimée. Cette
inclut les fichiers supprimés et renommés.

Renvoie 0 en cas de succès.

Options:

-r,--tour
révision à afficher

--tout lister les fichiers de toutes les révisions

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

fusionner
fusionner une autre révision dans le répertoire de travail :

hg fusionner [-P] [[-r] REV]

Le répertoire de travail actuel est mis à jour avec toutes les modifications apportées à la révision demandée
depuis la dernière révision commune précédente.

Les fichiers qui ont changé entre l'un ou l'autre des parents sont marqués comme modifiés pour le prochain commit et un
commit doit être effectué avant que d'autres mises à jour du référentiel ne soient autorisées. le
le prochain commit aura deux parents.

--outil peut être utilisé pour spécifier l'outil de fusion utilisé pour les fusions de fichiers. Il remplace le
La variable d'environnement HGMERGE et vos fichiers de configuration. Voir hg aider outils de fusion en
options.

Si aucune révision n'est spécifiée, le parent du répertoire de travail est une révision principale et la
la branche actuelle contient exactement une autre tête, l'autre tête est fusionnée avec par défaut.
Sinon, une révision explicite avec laquelle fusionner doit être fournie.

See hg aider résoudre pour plus d'informations sur la gestion des conflits de fichiers.

Pour annuler une fusion non validée, utilisez hg Mise à jour --nettoyer . qui vérifiera une copie propre de
le parent de fusion d'origine, perdant toutes les modifications.

Renvoie 0 en cas de succès, 1 s'il y a des fichiers non résolus.

Options:

-F, --Obliger
forcer une fusion, y compris les modifications en attente (PÉRIMÉ)

-r,--tour
révision à fusionner

-P, --Aperçu
réviser les révisions à fusionner (aucune fusion n'est effectuée)

-t,--outil
spécifier l'outil de fusion

sortant
afficher les ensembles de modifications introuvables dans la destination :

hg sortant [-M] [-p] [-n] [-f] [-r REV]... [DEST]

Afficher les ensembles de modifications introuvables dans le référentiel de destination spécifié ou le push par défaut
emplacement. Ce sont les ensembles de modifications qui seraient poussés si un push était demandé.

Voir pull pour plus de détails sur les formats de destination valides.

Avec -B/--bookmarks, le résultat de la comparaison des signets entre local et distant
référentiels s'affiche. Avec -v/--verbose, le statut est également affiché pour chaque signet
comme ci-dessous:

BM1 01234567890a ajouté
BM2 supprimé
BM3 234567890abc avancé
BM4 34567890abcd a divergé
BM5 4567890abcde changé

L'action entreprise lors du push dépend de l'état de chaque signet :

ajoutée

pousser avec -B va le créer

supprimé

pousser avec -B va le supprimer

Avancée

push le mettra à jour

divergé

pousser avec -B le mettra à jour

modifié

pousser avec -B le mettra à jour

Du point de vue du comportement de poussée, les signets n'existant que dans la télécommande
référentiel sont traités comme supprimé, même s'il est en fait ajouté à distance.

Renvoie 0 s'il y a des modifications sortantes, 1 sinon.

Options:

-F, --Obliger
exécuter même lorsque la destination n'est pas liée

-r,--tour
un ensemble de modifications destiné à être inclus dans la destination

-n, --le plus récent d'abord
afficher le plus récent enregistrement en premier

-B, --signets
comparer les signets

-b,--branche
une branche spécifique que vous voudriez pousser

-p, --pièce
montrer le patch

-g, --git
utiliser le format de diff étendu git

-l,--limite
nombre limite de modifications affichées

-M, --no-fusions
ne pas afficher les fusions

--stat sortie résumé des modifications de style diffstat

-G, --graphique
afficher le DAG de révision

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

alias: out

parents
afficher les parents du répertoire de travail ou de la révision (PÉRIMÉ) :

hg parents [-r REV] [FILE]

Imprimer les révisions parent du répertoire de travail. Si une révision est donnée via -r/--rev, le
parent de cette révision sera imprimé. Si un argument de fichier est donné, la révision dans
lequel le fichier a été modifié pour la dernière fois (avant la révision du répertoire de travail ou l'argument de
--rev si donné) est imprimé.

Cette commande équivaut à :

hg log -r "p1()+p2()" ou
hg log -r "p1(REV)+p2(REV)" ou
hg log -r "max(::p1() et file(FILE))+max(::p2() et file(FILE))" ou
hg log -r "max(::p1(REV) et fichier(FICHIER))+max(::p2(REV) et fichier(FICHIER))"

See hg résumé ainsi que hg aider les revets pour des informations connexes.

Renvoie 0 en cas de succès.

Options:

-r,--tour
afficher les parents de la révision spécifiée

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

chemins
afficher les alias pour les référentiels distants :

chemins hg [NOM]

Afficher la définition du nom de chemin symbolique NAME. Si aucun nom n'est donné, montrer la définition de tous
noms disponibles.

L'option -q/--quiet supprime toutes les sorties lors de la recherche de NAME et n'affiche que le chemin
noms lors de la liste de toutes les définitions.

Les noms de chemin sont définis dans la section [paths] de votre fichier de configuration et dans
/etc/mercuriel/hgrc. S'il est exécuté dans un référentiel, .hg/hgrc est aussi utilisé.

Les noms de chemin défaut ainsi que push par défaut ont une signification particulière. Lorsque vous effectuez une poussée ou
pull, ils sont utilisés comme solutions de secours si aucun emplacement n'est spécifié sur le
ligne de commande. Lorsque push par défaut est défini, il sera utilisé pour pousser et défaut sera utilisé
pour tirer; autrement défaut est utilisé comme solution de repli pour les deux. Lors du clonage d'un référentiel,
la source du clone est écrite comme défaut in .hg/hgrc.

Notes défaut ainsi que push par défaut s'appliquent à tous les appels entrants (par exemple hg nouveau) et sortant
(par exemple hg sortant, hg email ainsi que hg pack) opérations.

See hg aider urls pour plus d'information.

Renvoie 0 en cas de succès.

Options:

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

phase
définir ou afficher le nom de la phase actuelle :

phase hg [-p|-d|-s] [-f] [-r] [REV...]

Sans argument, affiche le nom de la phase de la ou des révisions en cours.

Avec l'un de -p/--public, -d/--draft ou -s/--secret, modifiez la valeur de phase du
révisions spécifiées.

Sauf si -f/--force est spécifié, hg phase ne déplacera pas l'ensemble de modifications d'une phase inférieure à une
phase supérieure. Les phases sont ordonnées comme suit :

public < brouillon < secret

Renvoie 0 en cas de succès, 1 si certaines phases n'ont pas pu être modifiées.

(Pour plus d'informations sur le concept de phases, voir hg aider phases.)

Options:

-p, --Publique
définir la phase d'ensemble de modifications sur public

-ré, --Brouillon
définir la phase d'ensemble de modifications sur brouillon

-Oui, --secrète
définir la phase de modification sur secret

-F, --Obliger
permettre de déplacer la frontière vers l'arrière

-r,--tour
révision cible

L'option marquée [+] peut être spécifiée plusieurs fois

tirer
extraire les modifications de la source spécifiée :

hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE]

Extrayez les modifications d'un référentiel distant vers un référentiel local.

Cela trouve toutes les modifications du référentiel au chemin ou à l'URL spécifié et les ajoute à un
référentiel local (l'actuel sauf si -R est spécifié). Par défaut, cela ne
mettre à jour la copie du projet dans le répertoire de travail.

Utilisez hg nouveau si vous voulez voir ce qui aurait été ajouté par un pull au moment où vous
émis cette commande. Si vous décidez ensuite d'ajouter ces modifications au référentiel, vous devez
utilisé hg tirer -r X De X est le dernier ensemble de modifications répertorié par hg nouveau.

Si SOURCE est omis, le chemin 'par défaut' sera utilisé. Voir hg aider urls pour plus d'
</br>L’Information.

Renvoie 0 en cas de succès, 1 si une mise à jour avait des fichiers non résolus.

Options:

-tu, --mettre à jour
mise à jour vers le nouveau chef de branche si des ensembles de modifications ont été extraits

-F, --Obliger
s'exécuter même lorsque le référentiel distant n'est pas lié

-r,--tour
un ensemble de modifications distant destiné à être ajouté

-B,--signet
signet à tirer

-b,--branche
une branche spécifique que vous voudriez tirer

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

pousser
pousser les modifications vers la destination spécifiée :

hg appuyez sur [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]

Pousser les ensembles de modifications du référentiel local vers la destination spécifiée.

Cette opération est symétrique au pull : elle est identique à un pull dans la destination
référentiel de l'actuel.

Par défaut, push ne permettra pas la création de nouvelles têtes à destination, car plusieurs
têtes rendrait difficile de savoir quelle tête utiliser. Dans cette situation, il est recommandé de
tirez et fusionnez avant de pousser.

Utilisez --new-branch si vous souhaitez autoriser push pour créer une nouvelle branche nommée qui n'est pas
présent à destination. Cela vous permet de créer uniquement une nouvelle branche sans forcer
d'autres changements.

Remarque Des précautions supplémentaires doivent être prises avec l'option -f/--force, qui poussera tous les nouveaux
têtes sur toutes les branches, une action qui causera presque toujours de la confusion pour
collaborateurs.

Si -r/--rev est utilisé, la révision spécifiée et tous ses ancêtres seront poussés vers le
référentiel distant.

Si -B/--bookmark est utilisé, la révision spécifiée avec signet, ses ancêtres et le
signet sera poussé vers le référentiel distant.

S'il te plait regarde hg aider urls pour des détails importants sur chut:// URL. Si DESTINATION est
omis, un chemin par défaut sera utilisé.

Renvoie 0 si push a réussi, 1 si rien à pousser.

Options:

-F, --Obliger
forcer la poussée

-r,--tour
un ensemble de modifications destiné à être inclus dans la destination

-B,--signet
signet à pousser

-b,--branche
une branche spécifique que vous voudriez pousser

--nouvelle branche
permettre de pousser une nouvelle branche

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

récupérer
annuler une transaction interrompue :

hg récupérer

Récupérer à partir d'un commit ou d'un pull interrompu.

Cette commande essaie de corriger l'état du référentiel après une opération interrompue. Cela devrait
ne sera nécessaire que lorsque Mercurial le suggère.

Renvoie 0 en cas de succès, 1 si rien à récupérer ou à vérifier n'échoue.

supprimez
supprimer les fichiers spécifiés lors du prochain commit :

hg supprimer [OPTION]... FICHIER...

Planifiez la suppression des fichiers indiqués de la branche actuelle.

Cette commande programme la suppression des fichiers lors du prochain commit. Pour annuler une suppression
avant cela, voir hg revenir. Pour annuler les fichiers ajoutés, consultez hg oublier.

-A/--after peut être utilisé pour supprimer uniquement les fichiers qui ont déjà été supprimés, -f/--force peut
être utilisé pour forcer la suppression, et -Af peut être utilisé pour supprimer des fichiers de la prochaine révision
sans les supprimer du répertoire de travail.

Le tableau suivant détaille le comportement de remove pour différents états de fichier (colonnes) et
combinaisons d'options (lignes). Les états du fichier sont Ajouté [A], Nettoyer [C], Modifié [M] et
Manquant [!] (tel que rapporté par hg statuts). Les actions sont Avertir, Supprimer (de la branche) et
Supprimer (du disque):

┌──────────┬───┬────┬────┬───┐
│opt/état │ A │ C │ M │ ! │
├──────────┼───┼────┼────┼───┤
│aucun │ W │ RD │ W │ R │
├──────────┼───┼────┼────┼───┤
│-f │ R │ RD │ RD │ R │
├──────────┼───┼────┼────┼───┤
│-A │ W │ W │ W │ R │
├──────────┼───┼────┼────┼───┤
│-Af │ R │ R │ R │ R │
└──────────┴───┴────┴────┴───┘

Notes hg supprimez ne supprime jamais les fichiers dans l'état Ajouté [A] du répertoire de travail, pas
même si --Obliger est spécifié.

Renvoie 0 en cas de succès, 1 si des avertissements sont rencontrés.

Options:

-UNE, --après
suppression d'enregistrement pour les fichiers manquants

-F, --Obliger
supprimer (et supprimer) le fichier même s'il a été ajouté ou modifié

-S, --sous-dépôt
récursif dans les sous-référentiels

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

alias : rm

rebaptiser
renommer les fichiers ; équivalent de copier + supprimer :

hg renommer [OPTION]... SOURCE... DEST

Marquer dest comme copies des sources ; marquer les sources à supprimer. Si dest est un répertoire, copie
sont placés dans ce répertoire. Si dest est un fichier, il ne peut y avoir qu'une seule source.

Par défaut, cette commande copie le contenu des fichiers tels qu'ils existent dans le
annuaire. Si invoqué avec -A/--after, l'opération est enregistrée, mais aucune copie n'est
effectué.

Cette commande prend effet au prochain commit. Pour annuler un changement de nom avant cela, voir hg revenir.

Renvoie 0 en cas de succès, 1 si des erreurs sont rencontrées.

Options:

-UNE, --après
enregistrer un changement de nom qui a déjà eu lieu

-F, --Obliger
copier de force sur un fichier géré existant

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

L'option marquée [+] peut être spécifiée plusieurs fois

alias : déplacer mv

résoudre
rétablir les fusions ou définir/afficher le statut de fusion des fichiers :

hg résoudre [OPTION]... [FICHIER]...

Les fusions avec des conflits non résolus sont souvent le résultat d'une fusion non interactive utilisant le
interne:fusionner paramètre de configuration ou un outil de fusion en ligne de commande tel que diff3. La résolution
commande est utilisée pour gérer les fichiers impliqués dans une fusion, après hg fusionner a été exécuté, et
before hg commettre est exécuté (c'est-à-dire que le répertoire de travail doit avoir deux parents). Voir hg aider
outils de fusion pour plus d'informations sur la configuration des outils de fusion.

La commande de résolution peut être utilisée des manières suivantes :

· hg résoudre [--outil OUTIL] DÉPOSER...: tente de fusionner à nouveau les fichiers spécifiés, en supprimant
toutes les tentatives de fusion précédentes. La re-fusion n'est pas effectuée pour les fichiers déjà marqués comme
résolu. Utiliser --tous/-a pour sélectionner tous les fichiers non résolus. --outil peut être utilisé pour spécifier le
outil de fusion utilisé pour les fichiers donnés. Elle remplace la variable d'environnement HGMERGE et
vos fichiers de configuration. Le contenu du fichier précédent est enregistré avec un .orig suffixe.

· hg résoudre -m [DOSSIER]: marque un fichier comme ayant été résolu (par exemple après avoir manuellement
corrigé les fichiers). La valeur par défaut est de marquer tous les fichiers non résolus.

· hg résoudre -u [FICHIER]...: marque un fichier comme non résolu. La valeur par défaut est de marquer tous résolus
fichiers.

· hg résoudre -l: liste les fichiers qui ont eu ou ont encore des conflits. Dans la liste imprimée, U =
non résolu et R = résolu.

Remarque Mercurial ne vous permettra pas de valider des fichiers avec des conflits de fusion non résolus. Vous devez
utilisé hg résoudre -m avant de pouvoir valider après une fusion conflictuelle.

Renvoie 0 en cas de succès, 1 si des fichiers échouent lors d'une tentative de résolution.

Options:

-une, --tout
sélectionner tous les fichiers non résolus

-l, --liste
liste l'état des fichiers nécessitant une fusion

-m, --marque
marquer les fichiers comme résolus

-tu, --décocher
marquer les fichiers comme non résolus

-n, --pas de statut
masquer le préfixe d'état

-t,--outil
spécifier l'outil de fusion

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

L'option marquée [+] peut être spécifiée plusieurs fois

revenir
restaurer les fichiers à leur état d'extraction :

hg revert [OPTION]... [-r REV] [NOM]...

Remarque Pour extraire les révisions précédentes, vous devez utiliser hg Mise à jour REV. Pour annuler un
fusion non validée (et perdre vos modifications), utilisez hg Mise à jour --nettoyer ..

Sans révision spécifiée, rétablit les fichiers ou répertoires spécifiés au contenu qu'ils
avait dans le parent du répertoire de travail. Ceci restaure le contenu des fichiers dans un
état non modifié et non planifié ajoute, supprime, copie et renomme. Si le travail
répertoire a deux parents, vous devez spécifier explicitement une révision.

En utilisant les options -r/--rev ou -d/--date, rétablissez les fichiers ou répertoires donnés à leur
États à partir d'une révision spécifique. Parce que revenir ne change pas le répertoire de travail
parents, cela fera apparaître ces fichiers modifiés. Cela peut être utile pour "revenir en arrière"
tout ou partie d'un changement antérieur. Voir hg retrait pour une méthode associée.

Les fichiers modifiés sont enregistrés avec un suffixe .orig avant de revenir. Pour désactiver ces sauvegardes,
utilisez --no-backup.

See hg aider dates pour une liste de formats valides pour -d/--date.

See hg aider retrait pour un moyen d'inverser l'effet d'un ensemble de modifications antérieur.

Renvoie 0 en cas de succès.

Options:

-une, --tout
annule toutes les modifications lorsqu'aucun argument n'est donné

-ré,--Date
date de correspondance de la révision la plus avancée

-r,--tour
revenir à la révision spécifiée

-Ç, --pas de sauvegarde
ne pas enregistrer de copies de sauvegarde des fichiers

-je, --interactif
sélectionner interactivement les changements (EXPERIMENTAL)

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

L'option marquée [+] peut être spécifiée plusieurs fois

rollback
annuler la dernière transaction (DANGEROUS) (OBSOLÈTE) :

retour en arrière

S'il vous plaît utiliser hg commettre --modifier au lieu de revenir en arrière pour corriger les erreurs dans le dernier commit.

Cette commande doit être utilisée avec précaution. Il n'y a qu'un seul niveau de restauration, et il y a
aucun moyen d'annuler une restauration. Il restaurera également le dirstate au moment de la dernière
transaction, perdant tout changement d'état depuis lors. Cette commande ne modifie pas le
directeur de travail.

Les transactions sont utilisées pour encapsuler les effets de toutes les commandes qui créent de nouveaux
changesets ou propager des changesets existants dans un référentiel.

Par exemple, les commandes suivantes sont transactionnelles et leurs effets peuvent être annulés
arrière:

· s'engager

· importer

· tirer

· push (avec ce référentiel comme destination)

· dégrouper

Pour éviter une perte permanente de données, la restauration refusera de restaurer une transaction de validation si elle
n'est pas vérifié. Utilisez --force pour outrepasser cette protection.

Cette commande n'est pas destinée à être utilisée sur des référentiels publics. Une fois que les modifications sont visibles pour
tirer par d'autres utilisateurs, annuler une transaction localement est inefficace (quelqu'un d'autre peut
ont déjà apporté les modifications). De plus, une course est possible avec les lecteurs du
dépôt; par exemple, une extraction en cours du référentiel peut échouer si une restauration est
effectué.

Renvoie 0 en cas de succès, 1 si aucune donnée de restauration n'est disponible.

Options:

-n, - à sec
n'effectuez aucune action, imprimez simplement la sortie

-F, --Obliger
ignorer les mesures de sécurité

racine
affiche la racine (en haut) du répertoire de travail courant :

hg racine

Affiche le répertoire racine du référentiel actuel.

Renvoie 0 en cas de succès.

besoin
démarrer le serveur Web autonome :

hg servir [OPTION]...

Démarrez un navigateur de référentiel HTTP local et extrayez le serveur. Vous pouvez l'utiliser pour le partage ad hoc
et la navigation dans les référentiels. Il est recommandé d'utiliser un vrai serveur web pour servir un
dépôt pendant de plus longues périodes.

Veuillez noter que le serveur n'implémente pas de contrôle d'accès. Cela signifie que, par
par défaut, n'importe qui peut lire sur le serveur et personne ne peut y écrire par défaut. Met le
web.allow_push Option de * pour permettre à tout le monde de pousser vers le serveur. Vous devez utiliser un vrai
serveur Web si vous avez besoin d'authentifier les utilisateurs.

Par défaut, le serveur journalise les accès à stdout et les erreurs à stderr. Utilisez le
Options -A/--accesslog et -E/--errorlog pour se connecter aux fichiers.

Pour que le serveur choisisse un numéro de port libre sur lequel écouter, spécifiez un numéro de port de 0 ; dans
Dans ce cas, le serveur imprimera le numéro de port qu'il utilise.

Renvoie 0 en cas de succès.

Options:

-UNE,--accesslog
nom du fichier journal d'accès dans lequel écrire

-ré, --démon
exécuter le serveur en arrière-plan

--daemon-pipefds
utilisé en interne par le mode démon

-ET,--journal d'erreurs
nom du fichier journal des erreurs dans lequel écrire

-p,--Port
port sur lequel écouter (par défaut : 8000)

-une,--adresse
adresse à écouter (par défaut : toutes les interfaces)

--préfixe
chemin de préfixe à partir duquel servir (par défaut : racine du serveur)

-n,--Nom
nom à afficher dans les pages Web (par défaut : répertoire de travail)

--web-conf
nom du fichier de configuration de hgweb (voir "hg help hgweb")

--webdir-conf
nom du fichier de configuration hgweb (OBSOLETE)

--fichier-pid
nom du fichier dans lequel écrire l'ID de processus

--stdio
pour les clients distants

--cmdserveur
pour les clients distants

-t,--modèles
modèles Web à utiliser

--style
style de modèle à utiliser

-6, --ipv6
utiliser IPv6 en plus d'IPv4

--certificat
Fichier de certificat SSL

statuts
afficher les fichiers modifiés dans le répertoire de travail :

hg état [OPTION]... [FICHIER]...

Afficher l'état des fichiers dans le référentiel. Si des noms sont donnés, seuls les fichiers correspondants sont
montré. Les fichiers propres ou ignorés ou la source d'une opération de copie/déplacement ne sont pas
sauf si -c/--clean, -i/--ignored, -C/--copies ou -A/--all sont indiqués. Sauf options
décrites avec "show only ..." sont données, les options -mardu sont utilisées.

L'option -q/--quiet masque les fichiers non suivis (inconnus et ignorés) sauf demande explicite
avec -u/--inconnu ou -i/--ignoré.

Notes hg statuts peut sembler être en désaccord avec diff si les autorisations ont changé ou une fusion
s'est produit. Le format diff standard ne signale pas les modifications d'autorisation et diff
signale uniquement les modifications relatives à un parent de fusion.

Si une révision est donnée, elle est utilisée comme révision de base. Si deux révisions sont données,
les différences entre eux sont indiquées. L'option --change peut également être utilisée comme raccourci
pour lister les fichiers modifiés d'une révision depuis son premier parent.

Les codes utilisés pour afficher l'état des fichiers sont :

M = modifié
A = ajouté
R = supprimé
C = propre
! = manquant (supprimé par une commande non-hg, mais toujours suivi)
? = non suivi
je = ignoré
= origine du fichier précédent (avec --copies)

Exemples :

· afficher les changements dans le répertoire de travail par rapport à un changeset :

statut hg --rev 9353

· afficher les changements dans le répertoire de travail par rapport au répertoire courant (voir hg aider
motifs pour plus d'informations):

hg statut re :

· afficher toutes les modifications, y compris les copies dans un ensemble de modifications existant :

statut hg --copies --change 9353

· obtenir une liste séparée par NUL des fichiers ajoutés, adaptés aux xargs :

statut hg -an0

Renvoie 0 en cas de succès.

Options:

-UNE, --tout
afficher l'état de tous les fichiers

-m, --modifié
afficher uniquement les fichiers modifiés

-une, --ajoutée
afficher uniquement les fichiers ajoutés

-r, --supprimé
afficher uniquement les fichiers supprimés

-ré, --supprimé
afficher uniquement les fichiers supprimés (mais suivis)

-c, --nettoyer
afficher uniquement les fichiers sans modifications

-tu, --inconnue
afficher uniquement les fichiers inconnus (non suivis)

-je, --ignoré
afficher uniquement les fichiers ignorés

-n, --pas de statut
masquer le préfixe d'état

-Ç, --copies
afficher la source des fichiers copiés

-0, --print0
terminer les noms de fichiers avec NUL, à utiliser avec xargs

--tour
montrer la différence par rapport à la révision

--monnaie
lister les fichiers modifiés d'une révision

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-S, --sous-dépôt
récursif dans les sous-référentiels

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

L'option marquée [+] peut être spécifiée plusieurs fois

pseudonymes : st

résumé
résumer l'état du répertoire de travail :

hg résumé [--distant]

Cela génère un bref résumé de l'état du répertoire de travail, y compris les parents, la branche,
statut de validation, phase et mises à jour disponibles.

Avec l'option --remote, cela vérifiera les chemins par défaut pour les entrées et les sorties
changements. Cela peut prendre du temps.

Renvoie 0 en cas de succès.

Options:

--à distance
vérifier la poussée et la traction

alias : somme

Étiquette
ajoutez une ou plusieurs balises pour la révision actuelle ou donnée :

balise hg [-f] [-l] [-m TEXTE] [-d DATE] [-u UTILISATEUR] [-r REV] NOM...

Nommez une révision particulière en utilisant .

Les balises sont utilisées pour nommer des révisions particulières du référentiel et sont très utiles pour
comparer différentes révisions, revenir à des versions antérieures significatives ou marquer des branches
points en tant que versions, etc. La modification d'une étiquette existante est normalement interdite ; utiliser -f/--force
pour outrepasser.

Si aucune révision n'est donnée, le parent du répertoire de travail est utilisé.

Pour faciliter le contrôle de version, la distribution et la fusion des balises, elles sont stockées en tant que
fichier nommé ".hgtags" qui est géré de la même manière que les autres fichiers de projet et peut être
édité à la main si nécessaire. Cela signifie également que le balisage crée un nouveau commit. Le fichier
".hg/localtags" est utilisé pour les balises locales (non partagées entre les référentiels).

Les commits de balises sont généralement effectués à la tête d'une branche. Si le parent du travail
l'annuaire n'est pas un chef de branche, hg Étiquette abandonne ; utilisez -f/--force pour forcer la validation de la balise à
être basé sur un changeset non-head.

See hg aider dates pour une liste de formats valides pour -d/--date.

Étant donné que les noms de balises ont priorité sur les noms de branche lors de la recherche de révision, l'utilisation d'un
le nom de la branche comme nom de balise est déconseillé.

Renvoie 0 en cas de succès.

Options:

-F, --Obliger
balise de force

-l, --locale
rendre la balise locale

-r,--tour
révision de la balise

--supprimer
supprimer une étiquette

-e, --modifier
invoquer l'éditeur sur les messages de validation

-m,--un message
utiliser le texte comme message de validation

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

étiquettes
répertorier les balises du référentiel :

balises hg

Cela répertorie les balises régulières et locales. Lorsque le commutateur -v/--verbose est utilisé, un troisième
la colonne "local" est imprimée pour les balises locales. Lorsque le commutateur -q/--quiet est utilisé, seul le
le nom de la balise est imprimé.

Renvoie 0 en cas de succès.

Options:

-T,--modèle
affichage avec modèle (EXPERIMENTAL)

pointe
afficher la révision de pointe (OBSOLÈTE):

pointe hg [-p] [-g]

La révision de pointe (généralement simplement appelée la pointe) est le dernier ensemble de modifications ajouté au
référentiel (et donc la dernière tête modifiée).

Si vous venez de faire un commit, ce commit sera le pourboire. Si vous venez de tirer
modifications d'un autre référentiel, la pointe de ce référentiel devient la pointe actuelle. le
La balise "tip" est spéciale et ne peut pas être renommée ou affectée à un ensemble de modifications différent.

Cette commande est obsolète, veuillez utiliser hg têtes à la place.

Renvoie 0 en cas de succès.

Options:

-p, --pièce
montrer le patch

-g, --git
utiliser le format de diff étendu git

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

dégrouper
appliquez un ou plusieurs fichiers changegroup :

hg dégrouper [-u] FICHIER...

Appliquez un ou plusieurs fichiers changegroup compressés générés par la commande bundle.

Renvoie 0 en cas de succès, 1 si une mise à jour contient des fichiers non résolus.

Options:

-tu, --mettre à jour
mise à jour vers le nouveau chef de branche si les ensembles de modifications ont été dégroupés

Mise à jour
mettre à jour le répertoire de travail (ou changer de révision):

hg mise à jour [-c] [-C] [-d DATE] [[-r] REV]

Mettez à jour le répertoire de travail du référentiel vers l'ensemble de modifications spécifié. Si aucun ensemble de modifications n'est
spécifié, mettre à jour la pointe de la branche nommée actuelle et déplacer le signet actif (voir
hg aider signets).

La mise à jour définit la révision parent du répertoire de travail sur le jeu de modifications spécifié (voir hg
aider parents).

Si le changeset n'est pas un descendant ou un ancêtre du parent du répertoire de travail, le
la mise à jour est interrompue. Avec l'option -c/--check, le répertoire de travail est vérifié
modifications non validées ; si aucun n'est trouvé, le répertoire de travail est mis à jour avec le
ensemble de modifications.

Les règles suivantes s'appliquent lorsque le répertoire de travail contient des modifications non validées :

1. Si ni -c/--check ni -C/--clean ne sont spécifiés, et si le changeset demandé est un
ancêtre ou descendant du parent du répertoire de travail, les modifications non validées sont
fusionné dans l'ensemble de modifications demandé et le résultat fusionné n'est pas validé. Si la
l'ensemble de modifications demandé n'est pas un ancêtre ou un descendant (c'est-à-dire qu'il se trouve sur un autre
branch), la mise à jour est abandonnée et les modifications non validées sont conservées.

2. Avec l'option -c/--check, la mise à jour est abandonnée et les modifications non validées sont
conservé.

3. Avec l'option -C/--clean, les modifications non validées sont ignorées et le répertoire de travail
est mis à jour avec le jeu de modifications demandé.

Pour annuler une fusion non validée (et perdre vos modifications), utilisez hg Mise à jour --nettoyer ..

Utilisez null comme ensemble de modifications pour supprimer le répertoire de travail (comme hg cloner -U).

Si vous souhaitez rétablir un seul fichier vers une ancienne révision, utilisez hg revenir [-r TOUR] Nom.

See hg aider dates pour une liste de formats valides pour -d/--date.

Renvoie 0 en cas de succès, 1 s'il y a des fichiers non résolus.

Options:

-Ç, --nettoyer
ignorer les modifications non validées (pas de sauvegarde)

-c, --Chèque
mise à jour entre les branches si aucune modification non validée

-ré,--Date
date de correspondance de la révision la plus avancée

-r,--tour
révision

-t,--outil
spécifier l'outil de fusion

alias : up checkout co

vérifier
vérifier l'intégrité du référentiel :

hg vérifier

Vérifiez l'intégrité du référentiel actuel.

Cela effectuera une vérification approfondie de l'intégrité du référentiel, en validant les hachages
et les sommes de contrôle de chaque entrée dans le journal des modifications, le manifeste et les fichiers suivis, ainsi que le
l'intégrité de leurs liens croisés et indices.

Veuillez consulter https://mercurial-scm.org/wiki/RepositoryCorruption pour plus d'informations sur
récupération de la corruption du référentiel.

Renvoie 0 en cas de succès, 1 si des erreurs sont rencontrées.

version
version de sortie et informations de copyright :

version hg

version de sortie et informations de copyright

DATES FORMATS

Certaines commandes permettent à l'utilisateur de spécifier une date, par exemple :

· backout, commit, import, tag : Spécifiez la date de commit.

· se connecter, revenir, mettre à jour : sélectionnez la ou les révisions par date.

De nombreux formats de date sont valides. Voici quelques exemples:

· Mercredi Décembre 6 13:18:29 2006 (fuseau horaire local supposé)

· Décembre 6 13:18 - 0600 (année supposée, décalage horaire fourni)

· Décembre 6 13:18 UTC (UTC et GMT sont des alias pour +0000)

· Décembre 6 (minuit)

· 13:18 (actuellement supposé)

· 3:39 (3h39 supposé)

· 3: 39pm (15: 39)

· 2006-12-06 13:18:29 (format ISO 8601)

· 2006-12-6 13:18

· 2006-12-6

· 12-6

· 12/6

· 12/6/6 (6 déc. 2006)

· aujourd'hui (minuit)

· hier (minuit)

· maintenant - à l'heure actuelle

Enfin, il y a le format interne de Mercurial :

· 1165411109 0 (mercredi 6 décembre 13:18:29 2006 UTC)

Il s'agit du format de représentation interne des dates. Le premier nombre est le nombre de
secondes depuis l'époque (1970-01-01 00:00 UTC). Le second est le décalage du local
fuseau horaire, en secondes à l'ouest de UTC (négatif si le fuseau horaire est à l'est de UTC).

La commande log accepte également les plages de dates :

· <DATE - à ou avant une date/heure donnée

· >DATE - à ou après une date/heure donnée

· DATES à DATES - une plage de dates, inclusive

· -JOURS - dans un certain nombre de jours à partir d'aujourd'hui

DIFFÉRENT FORMATS

Le format par défaut de Mercurial pour afficher les changements entre deux versions d'un fichier est
compatible avec le format unifié de GNU diff, qui peut être utilisé par le patch GNU et de nombreux
autres outils standards.

Bien que ce format standard soit souvent suffisant, il n'encode pas les informations suivantes :

· état exécutable et autres bits d'autorisation

· copier ou renommer des informations

· changements dans les fichiers binaires

· création ou suppression de fichiers vides

Mercurial prend également en charge le format diff étendu du git VCS qui traite ces
limites. Le format git diff n'est pas produit par défaut car quelques outils répandus
ne comprends toujours pas ce format.

Cela signifie que lors de la génération de diffs à partir d'un référentiel Mercurial (par exemple avec hg Exporter),
vous devez faire attention à des choses comme les copies de fichiers et les changements de nom ou d'autres choses mentionnées
ci-dessus, car lors de l'application d'un diff standard à un référentiel différent, ce supplément
les informations sont perdues. Les opérations internes de Mercurial (comme le push et le pull) ne sont pas affectées
par cela, car ils utilisent un format binaire interne pour communiquer les modifications.

Pour que Mercurial produise le format de diff étendu de git, utilisez l'option --git disponible pour
de nombreuses commandes, ou définissez 'git = True' dans la section [diff] de votre fichier de configuration. Vous
il n'est pas nécessaire de définir cette option lors de l'importation de diffs dans ce format ou de leur utilisation dans le mq
extension.

ENVIRONNEMENT VARIABLES

HG Chemin vers l'exécutable 'hg', transmis automatiquement lors de l'exécution de crochets, d'extensions ou
outils externes. Si non défini ou vide, c'est le nom de l'exécutable hg s'il est gelé,
ou un exécutable nommé 'hg' (avec %PATHEXT% [par défaut COM/EXE/BAT/CMD]
extensions sous Windows) est recherché.

HGÉDITEUR
Il s'agit du nom de l'éditeur à exécuter lors de la validation. Voir ÉDITEUR.

(obsolète, utilisez le fichier de configuration)

HGENCODAGE
Cela remplace le paramètre régional par défaut détecté par Mercurial. Ce paramètre est
utilisé pour convertir des données, y compris les noms d'utilisateur, les descriptions des ensembles de modifications, les noms de balises et
branches. Ce paramètre peut être remplacé par l'option de ligne de commande --encoding.

MODE DE CODAGE HGEN
Cela définit le comportement de Mercurial pour la gestion des caractères inconnus lors du transcodage
entrée de l'utilisateur. La valeur par défaut est "strict", ce qui fait abandonner Mercurial s'il ne peut pas
mapper un personnage. D'autres paramètres incluent "remplacer", qui remplace inconnu
caractères, et "ignorer", qui les supprime. Ce paramètre peut être remplacé par le
Option de ligne de commande --encodingmode.

HGENCODINGAMBIGU
Cela définit le comportement de Mercurial pour gérer les caractères avec des largeurs "ambiguës" comme
caractères latins accentués avec des polices d'Asie de l'Est. Par défaut, Mercurial suppose
les caractères ambigus sont étroits, définissez cette variable sur "large" si de tels caractères
causer des problèmes de formatage.

HGFUSION
Un exécutable à utiliser pour résoudre les conflits de fusion. Le programme sera exécuté
avec trois arguments : fichier local, fichier distant, fichier ancêtre.

(obsolète, utilisez le fichier de configuration)

HGRCPATH
Une liste de fichiers ou de répertoires pour rechercher des fichiers de configuration. Le séparateur d'éléments est
":" sous Unix, ";" sur Windows. Si HGRCPATH n'est pas défini, le chemin de recherche par défaut de la plate-forme
est utilisé. S'il est vide, seul le fichier .hg/hgrc du référentiel actuel est lu.

Pour chaque élément de HGRCPATH :

· si c'est un répertoire, tous les fichiers se terminant par .rc sont ajoutés

· sinon, le fichier lui-même sera ajouté

HGPLAIN
Lorsqu'il est défini, cela désactive tous les paramètres de configuration susceptibles de modifier les paramètres de Mercurial.
sortie par défaut. Cela inclut l'encodage, les valeurs par défaut, le mode verbeux, le mode débogage, le silence
mode, tracebacks et localisation. Cela peut être utile lors de l'écriture de scripts sur
Mercurial face à la configuration utilisateur existante.

Les options équivalentes définies via des indicateurs de ligne de commande ou des variables d'environnement ne sont pas
outrepassé.

HGPLAINSAUF
Il s'agit d'une liste de fonctionnalités séparées par des virgules à conserver lorsque HGPLAIN est activé.
Actuellement, les valeurs suivantes sont prises en charge :

alias

Ne supprimez pas les alias.

i18n

Préserver l'internationalisation.

revsetalias

Ne supprimez pas les alias revset.

Définir HGPLAINEXCEPT sur n'importe quoi (même une chaîne vide) activera le mode simple.

HGUSER Il s'agit de la chaîne utilisée comme auteur d'un commit. Si non défini, valeurs disponibles
seront considérés dans cet ordre :

· HGUSER (obsolète)

· fichiers de configuration du HGRCPATH

· E-MAIL

· invite interactive

· LOGNAME (avec @nom_hôte en annexe)

(obsolète, utilisez le fichier de configuration)

E-MAIL Peut être utilisé comme auteur d'un commit ; voir HGUSER.

NOM DU JOURNAL
Peut être utilisé comme auteur d'un commit ; voir HGUSER.

VISUEL C'est le nom de l'éditeur à utiliser lors de la validation. Voir ÉDITEUR.

EDITEUR Parfois, Mercurial a besoin d'ouvrir un fichier texte dans un éditeur pour qu'un utilisateur le modifie,
par exemple lors de l'écriture de messages de validation. L'éditeur qu'il utilise est déterminé par
en regardant les variables d'environnement HGEDITOR, VISUAL et EDITOR, dans cet ordre.
Le premier non vide est choisi. Si tous sont vides, l'éditeur par défaut
'éditeur sensible'.

PYTHONPATH
Ceci est utilisé par Python pour trouver les modules importés et peut devoir être défini
de manière appropriée si ce Mercurial n'est pas installé à l'échelle du système.

EN UTILISANT COMPLÉMENTAIRES CARACTERISTIQUES

Mercurial a la capacité d'ajouter de nouvelles fonctionnalités grâce à l'utilisation d'extensions. Rallonges
peut ajouter de nouvelles commandes, ajouter des options aux commandes existantes, modifier le comportement par défaut de
commandes ou implémenter des crochets.

Pour activer l'extension "foo", fournie avec Mercurial ou dans le chemin de recherche Python,
créez une entrée pour cela dans votre fichier de configuration, comme ceci :

[extensions]
foo =

Vous pouvez également spécifier le chemin d'accès complet à une extension :

[extensions]
mafonctionnalité = ~/.hgext/mafonctionnalité.py

See hg aider config pour plus d'informations sur les fichiers de configuration.

Les extensions ne sont pas chargées par défaut pour diverses raisons : elles peuvent augmenter le temps de démarrage
aérien; ils peuvent être destinés à un usage avancé uniquement ; ils peuvent fournir potentiellement
capacités dangereuses (telles que vous laisser détruire ou modifier l'histoire) ; ils ne le sont peut-être pas
prêt pour les heures de grande écoute ; ou ils peuvent modifier certains comportements habituels du stock Mercurial. Il est
donc à l'utilisateur d'activer les extensions selon ses besoins.

Pour désactiver explicitement une extension activée dans un fichier de configuration de portée plus large,
ajouter son chemin avec ! :

[extensions]
# désactiver la barre d'extension résidant dans /path/to/extension/bar.py
bar = !/chemin/vers/extension/bar.py
# idem, mais aucun chemin n'a été fourni pour l'extension baz
baz = !

extensions désactivées :

acl crochets pour contrôler l'accès au référentiel

blackbox
consigner les événements du référentiel dans une boîte noire pour le débogage

bugzilla
hooks pour l'intégration avec le bug tracker de Bugzilla

censeur effacer le contenu du fichier à une révision donnée

baratte commande pour afficher des statistiques sur l'historique du dépôt

lots de clones
annoncez des bundles pré-générés pour semer des clones

Couleur coloriser la sortie de certaines commandes

convertir
importer des révisions de référentiels VCS étrangers dans Mercurial

eol gérer automatiquement les retours à la ligne dans les fichiers du référentiel

DiffExt
commande pour autoriser les programmes externes à comparer les révisions

factotum
authentification http avec factotum

gpg commandes pour signer et vérifier les ensembles de modifications

hgcia crochets pour l'intégration avec le service de notification CIA.vc

hgk parcourir le référentiel de manière graphique

mettre en évidence
coloration syntaxique pour hgweb (nécessite Pygments)

modifier
édition interactive de l'historique

mot-clé
développer les mots-clés dans les fichiers suivis

fichiers volumineux
suivre les gros fichiers binaires

mq gérer une pile de correctifs

notifier crochets pour l'envoi de notifications push par e-mail

payer parcourir la sortie de la commande avec un pager externe

bombe à patch
commande pour envoyer des ensembles de modifications sous la forme d'une (série d') e-mails de correctifs

purge commande pour supprimer les fichiers non suivis du répertoire de travail

rebasement commande pour déplacer des ensembles de révisions vers un ancêtre différent

record commandes pour sélectionner interactivement les changements pour commit/qrefresh

relier recrée les liens physiques entre les clones du référentiel

Schémas
étendre les schémas avec des raccourcis vers les essaims de référentiels

Partager partager un historique commun entre plusieurs répertoires de travail

ranger enregistrer et restaurer les modifications dans le répertoire de travail

bande supprimer les changesets et leurs descendants de l'histoire

transplantation
commande pour transplanter des ensembles de modifications d'une autre branche

win32mbcs
permettre l'utilisation de chemins MBCS avec des encodages problématiques

zéroconf
découvrir et publier des référentiels sur le réseau local

EN PRÉCISANT DOSSIER PARURES

Mercurial prend en charge un langage fonctionnel pour sélectionner un ensemble de fichiers.

Comme les autres modèles de fichiers, ce type de modèle est indiqué par un préfixe, 'set:'. La langue
prend en charge un certain nombre de prédicats qui sont joints par des opérateurs infixes. La parenthèse peut être
utilisé pour le regroupement.

Les identificateurs tels que les noms de fichiers ou les modèles doivent être placés entre guillemets simples ou doubles si
ils contiennent des caractères en dehors de [.*{}[]?/\_a-zA-Z0-9\x80-\xff] ou s'ils correspondent à l'un des
les prédicats prédéfinis. Cela s'applique généralement aux modèles de fichiers autres que globs et
arguments pour les prédicats.

Les caractères spéciaux peuvent être utilisés dans les identifiants entre guillemets en les échappant, par exemple, \n is
interprété comme une nouvelle ligne. Pour éviter qu'elles ne soient interprétées, les chaînes peuvent être préfixées
avec r, par exemple r'...'.

Il existe un seul opérateur de préfixe :

ne sauraient x

Fichiers pas dans x. La forme courte est ! x.

Voici les opérateurs d'infixe pris en charge :

x ainsi que y

L'intersection des fichiers en x et y. La forme courte est x & y.

x or y

L'union des fichiers en x et y. Il existe deux formes abrégées alternatives : x | y ainsi que x +
y.

x - y

Fichiers en x mais pas en y.

Les prédicats suivants sont pris en charge :

ajoutée()

Fichier qui est ajouté selon hg statuts.

binaire()

Fichier qui semble être binaire (contient des octets NUL).

nettoyer()

Fichier propre selon hg statuts.

copié()

Fichier enregistré comme étant copié.

supprimé()

Alias ​​pour manquant().

encodage (nom)

Le fichier peut être décodé avec succès avec le codage de caractères donné. N'est peut être pas
utile pour les encodages autres que ASCII et UTF-8.

eol (style)

Le fichier contient des nouvelles lignes du style donné (dos, unix, mac). Les fichiers binaires sont
exclus, les fichiers avec des fins de ligne mixtes correspondent à plusieurs styles.

exécutable()

Fichier marqué comme exécutable.

grep(expression régulière)

Le fichier contient l'expression régulière donnée.

hgignore()

Fichier qui correspond au modèle .hgignore actif.

ignoré()

Fichier ignoré selon hg statuts. Ces dossiers ne seront pris en compte que si
ce prédicat est utilisé.

manquant()

Fichier manquant selon hg statuts.

modifié()

Fichier modifié en fonction de hg statuts.

portable()

Fichier qui a un nom portable. (Cela n'inclut pas les noms de fichiers avec la casse
collisions.)

supprimé()

Fichier qui est supprimé selon hg statuts.

résolu()

Fichier marqué résolu selon hg résoudre -l.

taille (expression)

La taille du fichier correspond à l'expression donnée. Exemples:

· 1k (fichiers de 1024 à 2047 octets)

· < 20k (fichiers de moins de 20480 octets)

· >= .5MB (fichiers d'au moins 524288 octets)

· 4k - 1Mo (fichiers de 4096 octets à 1048576 octets)

sous-dépôt([motif])

Sous-dépôts dont les chemins correspondent au modèle donné.

lien symbolique()

Fichier marqué comme lien symbolique.

inconnue()

Fichier inconnu selon hg statuts. Ces dossiers ne seront pris en compte que si
ce prédicat est utilisé.

non résolu()

Fichier marqué comme non résolu selon hg résoudre -l.

Quelques exemples de requêtes :

· Afficher l'état des fichiers qui semblent être binaires dans le répertoire de travail :

hg status -A "set:binary()"

· Oubliez les fichiers qui sont en .hgignore mais qui sont déjà suivis :

hg oublier "set:hgignore() et non ignoré()"

· Rechercher des fichiers texte contenant une chaîne :

hg fichiers "set :grep(magique) et non binaire()"

· Rechercher des fichiers C dans un encodage non standard :

hg files "set:**.c and not encoding('UTF-8')"

· Rétablir les copies de fichiers binaires volumineux :

hg revert "set:copied() et binary() et size('>1M')"

· Supprimez les fichiers répertoriés dans foo.lst qui contiennent la lettre a ou b :

hg supprime "set: 'listfile:foo.lst' and (**a* or **b*)"

Voir aussi hg aider motifs.

GLOSSAIRE

Ancêtre
Tout ensemble de modifications pouvant être atteint par une chaîne ininterrompue d'ensembles de modifications parents à partir d'un
jeu de modifications donné. Plus précisément, les ancêtres d'un changeset peuvent être définis par deux
propriétés : un parent d'un ensemble de modifications est un ancêtre, et un parent d'un ancêtre est
un ancêtre. Voir aussi : 'Descendant'.

Favoris
Les signets sont des pointeurs vers certains commits qui se déplacent lors de la validation. Ils sont
similaire aux balises en ce sens qu'il est possible d'utiliser des noms de signet à tous les endroits où
Mercurial attend un ID d'ensemble de modifications, par exemple, avec hg Mise à jour. Contrairement aux balises, les signets se déplacent
lorsque vous faites un commit.

Les signets peuvent être renommés, copiés et supprimés. Les signets sont locaux, sauf s'ils sont
explicitement poussé ou tiré entre les référentiels. Pousser et tirer des signets
vous permettent de collaborer avec d'autres sur une branche sans créer de branche nommée.

Branche (Nom) Un ensemble de modifications enfant qui a été créé à partir d'un parent qui n'est pas une tête.
Celles-ci sont connues sous le nom de branches topologiques, voir 'Branche, topologique'. Si un
branche topologique est nommée, elle devient une branche nommée. Si une branche topologique est
non nommé, il devient une branche anonyme. Voir 'Succursale, anonyme' et 'Succursale,
nommé'.

Des branches peuvent être créées lorsque des modifications sont extraites ou poussées vers une télécommande
référentiel, car de nouvelles têtes peuvent être créées par ces opérations. A noter que le terme
branche peut également être utilisé de manière informelle pour décrire un processus de développement dans lequel
certains développements se font indépendamment d'autres développements. C'est parfois
fait explicitement avec une branche nommée, mais cela peut aussi être fait localement, en utilisant
signets ou clones et branches anonymes.

Exemple : "La branche expérimentale."

(Verbe) L'action de créer un ensemble de modifications enfant qui fait que son parent a
plus d'un enfant.

Exemple : "Je vais ouvrir une succursale à X."

Branche, anonyme
Chaque fois qu'un nouvel ensemble de modifications enfant est créé à partir d'un parent qui n'est pas un chef et
le nom de la branche n'est pas modifié, une nouvelle branche anonyme est créée.

Branche, fonds à capital fermé
Une succursale nommée dont les chefs de succursale ont tous été fermés.

Branche, défaut
La branche affectée à un ensemble de modifications lorsqu'aucun nom n'a été précédemment affecté.

Branche front
Voir 'Tête, branche'.

Branche, inactif
Si une branche nommée n'a pas de têtes topologiques, elle est considérée comme inactive. En tant que
Par exemple, une branche de fonctionnalité devient inactive lorsqu'elle est fusionnée avec la branche par défaut
branche. Les hg branches La commande affiche les branches inactives par défaut, bien qu'elles puissent
être caché avec hg branches --actif.

REMARQUE : ce concept est déprécié car il est trop implicite. Les succursales devraient maintenant
être explicitement fermé en utilisant hg commettre --fermer-branche quand ils ne sont plus nécessaires.

Branche, nommé
Une collection d'ensembles de modifications qui ont le même nom de branche. Par défaut, les enfants de
un changeset dans une branche nommée appartient à la même branche nommée. Un enfant peut être
explicitement affecté à une branche différente. Voir hg aider une succursale, hg aider branches ainsi que
hg commettre --fermer-branche pour plus d'informations sur la gestion des succursales.

Les branches nommées peuvent être considérées comme une sorte d'espace de noms, divisant la collection de
changesets qui composent le référentiel en une collection de sous-ensembles disjoints. UNE
la branche nommée n'est pas nécessairement une branche topologique. Si une nouvelle branche nommée est
créé à partir de la tête d'une autre branche nommée, ou de la branche par défaut, mais pas
d'autres ensembles de modifications sont ajoutés à cette branche précédente, puis à cette branche précédente
sera une succursale de nom seulement.

Branche pointe
Voir 'Astuce, branche'.

Branche, topologique
Chaque fois qu'un nouvel ensemble de modifications enfant est créé à partir d'un parent qui n'est pas une tête, un nouveau
branche topologique est créée. Si une branche topologique est nommée, elle devient une branche nommée
branche. Si une branche topologique n'est pas nommée, elle devient une branche anonyme du
branche actuelle, éventuellement par défaut.

Changelog
Un enregistrement des ensembles de modifications dans l'ordre dans lequel ils ont été ajoutés au référentiel.
Cela inclut des détails tels que l'identifiant de l'ensemble de modifications, l'auteur, le message de validation, la date et la liste
de fichiers modifiés.

Ensemble de modifications
Un instantané de l'état du référentiel utilisé pour enregistrer une modification.

Ensemble de modifications, enfant
L'inverse du jeu de modifications parent : si P est un parent de C, alors C est un enfant de P.
Il n'y a pas de limite au nombre d'enfants qu'un changeset peut avoir.

Ensemble de modifications id
Un hachage SHA-1 qui identifie de manière unique un ensemble de modifications. Il peut être représenté soit comme
une "longue" chaîne de 40 chiffres hexadécimaux ou une "courte" chaîne de 12 chiffres hexadécimaux.

Ensemble de modifications, fusionner
Un changeset avec deux parents. Cela se produit lorsqu'une fusion est validée.

Ensemble de modifications, mère
Une révision sur laquelle un ensemble de modifications enfant est basé. Plus précisément, un ensemble de modifications parent
d'un changeset C est un changeset dont le nœud précède immédiatement C dans le DAG.
Les changesets ont au plus deux parents.

Passer au paiement
(Nom) Le répertoire de travail mis à jour vers une révision spécifique. Cette utilisation doit
probablement être évitée dans la mesure du possible, car le jeu de modifications est beaucoup plus approprié que
caisse dans ce contexte.

Exemple : "J'utilise la caisse X."

(Verb) Mise à jour du répertoire de travail vers un ensemble de modifications spécifique. Voir hg aider Mise à jour.

Exemple : "Je vais vérifier l'ensemble de modifications X."

Enfant ensemble de modifications
Voir 'Changeset, enfant'.

Fermer ensemble de modifications
Voir 'Tête, branche fermée'.

Fermé une succursale
Voir « Succursale, fermée ».

Cloner (Nom) Une copie entière ou partielle d'un référentiel. Le clone partiel doit être dans le
forme d'une révision et ses ancêtres.

Exemple : "Votre clone est-il à jour ?"

(Verbe) Le processus de création d'un clone, en utilisant hg cloner.

Exemple : "Je vais cloner le dépôt."

Fermé une succursale front
Voir 'Tête, branche fermée'.

S’ENGAGER (Nom) Synonyme de changeset.

Exemple : "Le bogue est-il corrigé dans votre récent commit ?"

(Verbe) L'acte d'enregistrer des modifications dans un référentiel. Lorsque des fichiers sont validés dans un
répertoire de travail, Mercurial trouve les différences entre les fichiers validés et
leur ensemble de modifications parent, créant un nouvel ensemble de modifications dans le référentiel.

Exemple : "Vous devez valider ces modifications maintenant."

Cset Une abréviation courante du terme changeset.

JOUR Le référentiel des ensembles de modifications d'un système de contrôle de version distribué (DVCS) peut être
décrit comme un graphe acyclique orienté (DAG), composé de nœuds et d'arêtes, où
les nœuds correspondent aux changesets et les arêtes impliquent une relation parent -> enfant. Cette
graphique peut être visualisé par des outils graphiques tels que hg enregistrer --graphique. Dans Mercurial,
le DAG est limité par l'obligation pour les enfants d'avoir au plus deux parents.

Obsolète
Fonctionnalité supprimée de la documentation, mais dont la suppression n'est pas prévue.

Réglage par défaut une succursale
Voir 'Branche, par défaut'.

Descendant
Tout ensemble de modifications pouvant être atteint par une chaîne d'ensembles de modifications enfants à partir d'un
ensemble de modifications. Plus précisément, les descendants d'un changeset peuvent être définis par deux
propriétés : l'enfant d'un ensemble de modifications est un descendant, et l'enfant d'un descendant
est un descendant. Voir aussi : 'Ancêtre'.

Diff (Nom) La différence entre le contenu et les attributs des fichiers dans deux
changesets ou un changeset et le répertoire de travail actuel. La différence est
généralement représenté sous une forme standard appelée "diff" ou "patch". Le "git diff"
le format est utilisé lorsque les modifications incluent des copies, des changements de nom ou des modifications de fichier
attributs, dont aucun ne peut être représenté/géré par les classiques "diff" et "patch".

Exemple : "Avez-vous vu ma correction dans le diff ?"

(Verbe) Différer deux changesets est l'action de créer un diff ou un patch.

Exemple : "Si vous comparez avec l'ensemble de modifications X, vous verrez ce que je veux dire."

Annuaire, de travail
Le répertoire de travail représente l'état des fichiers suivis par Mercurial, qui
sera enregistré dans le prochain commit. Le répertoire de travail correspond initialement à
l'instantané d'un ensemble de modifications existant, connu comme le parent du travail
annuaire. Voir 'Parent, répertoire de travail'. L'état peut être modifié par des modifications de
les fichiers introduits manuellement ou par une fusion. Les métadonnées du référentiel existent dans le
.hg dans le répertoire de travail.

Draft Les ensembles de modifications en phase de brouillon n'ont pas été partagés avec les référentiels de publication et
peuvent donc être modifiés en toute sécurité par des extensions modifiant l'historique. Voir hg aider phases.

Expérimental
Fonctionnalité susceptible de changer ou d'être supprimée ultérieurement.

Graphique Voir DAG et hg enregistrer --graphique.

Head Le terme « tête » peut être utilisé pour désigner à la fois une tête de branche ou une tête de référentiel,
selon le contexte. Voir 'Head, branch' et 'Head, repository' pour des
définitions

Les têtes sont là où le développement a généralement lieu et sont les cibles habituelles pour
opérations de mise à jour et de fusion.

Tête, une succursale
Un changeset sans descendant sur la même branche nommée.

Tête, fonds à capital fermé une succursale
Un ensemble de modifications qui marque une tête comme n'étant plus intéressante. La tête fermée n'est pas
plus répertorié par hg têtes. Une succursale est considérée comme fermée lorsque toutes ses têtes sont
fermé et par conséquent n'est pas répertorié par hg branches.

Les têtes fermées peuvent être rouvertes en validant un nouvel ensemble de modifications en tant qu'enfant de
changeset qui marque une tête comme fermée.

Tête, dépôt
Une tête topologique qui n'a pas été fermée.

Tête, topologique
Un ensemble de modifications sans enfants dans le référentiel.

L'histoire, immuable
Une fois validés, les ensembles de modifications ne peuvent pas être modifiés. Extensions qui semblent changer
l'histoire crée en fait de nouveaux ensembles de modifications qui remplacent ceux existants, puis détruisent
les anciens changesets. Le faire dans des référentiels publics peut entraîner d'anciens ensembles de modifications
être réintroduit dans le dépôt.

L'histoire, réécriture
Les ensembles de modifications d'un référentiel sont immuables. Cependant, les extensions de Mercurial peuvent
être utilisé pour modifier le référentiel, généralement de manière à préserver le jeu de modifications
Contenu.

Immuable Histoire
Voir 'Histoire, immuable'.

aller ensemble de modifications
Voir 'Changeset, fusionner'.

Manifeste
Chaque ensemble de modifications a un manifeste, qui est la liste des fichiers qui sont suivis par le
ensemble de modifications.

aller Utilisé pour rassembler des branches de travail divergentes. Lorsque vous mettez à jour un ensemble de modifications
puis fusionnez un autre changeset, vous apportez l'historique de ce dernier changeset
dans votre répertoire de travail. Une fois les conflits résolus (et marqués), cette fusion
peut être validé en tant que groupe de modifications de fusion, réunissant deux branches dans le DAG.

Nommé une succursale
Voir 'Branche, nommée'.

Null ensemble de modifications
L'ensemble de modifications vide. Il s'agit de l'état parent des référentiels nouvellement initialisés et
référentiels sans révision extraite. C'est donc le parent des changesets racine
et l'ancêtre effectif lors de la fusion d'ensembles de modifications non liés. Peut être spécifié par
l'alias 'null' ou par l'ID de l'ensemble de modifications '000000000000'.

Parent Voir 'Changeset, parent'.

Parent ensemble de modifications
Voir 'Changeset, parent'.

Parent, de travail annuaire
Le parent du répertoire de travail reflète une révision virtuelle qui est l'enfant du
ensemble de modifications (ou deux ensembles de modifications avec une fusion non validée) indiqué par hg parents. Ce
est changé avec hg Mise à jour. Les autres commandes pour voir le parent du répertoire de travail sont
hg résumé ainsi que hg id. Peut être spécifié par l'alias ".".

Pièce (Nom) Le produit d'une opération diff.

Exemple : "Je vous ai envoyé mon patch."

(Verbe) Processus d'utilisation d'un fichier correctif pour transformer un ensemble de modifications en un autre.

Exemple : "Vous devrez corriger cette révision."

phase Un état par ensemble de modifications indiquant comment l'ensemble de modifications a été ou devrait être partagé. Voir
hg aider phases.

public Les ensembles de modifications de la phase publique ont été partagés avec les référentiels de publication et
sont donc considérés comme immuables. Voir hg aider phases.

Pull Une opération dans laquelle des ensembles de modifications dans un référentiel distant qui ne sont pas dans le local
référentiel sont importés dans le référentiel local. Notez que cette opération sans
les arguments spéciaux ne mettent à jour que le référentiel, il ne met pas à jour les fichiers dans le
directeur de travail. Voir hg aider tirer.

Push Une opération dans laquelle des ensembles de modifications dans un référentiel local qui ne sont pas dans un distant
référentiel sont envoyés au référentiel distant. Notez que cette opération ne fait qu'ajouter
les ensembles de modifications qui ont été validés localement dans le référentiel distant. Non engagé
les modifications ne sont pas envoyées. Voir hg aider pousser.

Dépôt
Les métadonnées décrivant tous les états enregistrés d'une collection de fichiers. Chaque enregistré
L'état est représenté par un changeset. Un référentiel est généralement (mais pas toujours) trouvé
dans l' .hg sous-répertoire d'un répertoire de travail. Tout état enregistré peut être recréé
en « mettant à jour » un répertoire de travail vers un ensemble de modifications spécifique.

Dépôt front
Voir 'Tête, référentiel'.

Révision
État du référentiel à un moment donné. Les révisions antérieures peuvent être mises à jour
en utilisant hg Mise à jour. Voir aussi 'Numéro de révision' ; Voir aussi 'Changeset'.

Révision nombre
Cet entier identifie de manière unique un ensemble de modifications dans un référentiel spécifique. Ce
représente l'ordre dans lequel les ensembles de modifications ont été ajoutés à un référentiel, en commençant par
numéro de révision 0. Notez que le numéro de révision peut être différent dans chaque clone de
un référentiel. Pour identifier les ensembles de modifications de manière unique entre différents clones, consultez
'Identifiant de l'ensemble de modifications'.

Revlog Mécanisme de stockage de l'historique utilisé par Mercurial. C'est une forme de codage delta, avec
révision complète occasionnelle des données suivie du delta de chaque révision successive. Ce
inclut des données et un index pointant vers les données.

Réécriture Histoire
Voir 'Histoire, réécriture'.

Traitement Un ensemble de modifications qui n'a que l'ensemble de modifications nul comme parent. La plupart des dépôts ont
un seul ensemble de modifications racine.

secret Les ensembles de modifications dans la phase secrète ne peuvent pas être partagés via push, pull ou clone. Voir hg
aider phases.

Jour Nom alternatif donné à un ensemble de modifications. Les balises peuvent être utilisées partout où
Mercurial attend un ID d'ensemble de modifications, par exemple, avec hg Mise à jour. La création d'une balise est
stocké dans l'historique et sera donc automatiquement partagé avec d'autres en utilisant push
et tirez.

Conseil L'ensemble de modifications avec le numéro de révision le plus élevé. C'est le dernier ensemble de modifications
ajouté dans un référentiel.

mon gars, une succursale
Le responsable d'une branche donnée avec le numéro de révision le plus élevé. Lorsqu'un nom de succursale est
utilisé comme identifiant de révision, il fait référence à la pointe de la branche. Voir aussi "Branche,
diriger'. Notez que parce que les numéros de révision peuvent être différents dans différents référentiels
clones, la pointe de la branche peut être différente dans différents référentiels clonés.

Mises à jour (Noun) Un autre synonyme de changeset.

Exemple : "J'ai poussé une mise à jour."

(Verbe) Ce terme est généralement utilisé pour décrire la mise à jour de l'état de fonctionnement
répertoire à celui d'un ensemble de modifications spécifique. Voir hg aider Mise à jour.

Exemple : "Vous devriez mettre à jour."

Working : un espace de travail commun annuaire
Voir 'Répertoire, fonctionnement'.

Working : un espace de travail commun annuaire mère
Voir 'Parent, répertoire de travail'.

SYNTAXE POUR MERCURIEL IGNORER DES DOSSIERS

Synopsis
Le système Mercurial utilise un fichier appelé .hgignore dans le répertoire racine d'un dépôt pour
contrôler son comportement lorsqu'il recherche des fichiers qu'il ne suit pas actuellement.

Description
Le répertoire de travail d'un dépôt Mercurial contiendra souvent des fichiers qui ne devraient pas
être suivi par Mercurial. Ceux-ci incluent les fichiers de sauvegarde créés par les éditeurs et les produits de construction
créés par les compilateurs. Ces fichiers peuvent être ignorés en les listant dans un .hgignore fichier dans
la racine du répertoire de travail. le .hgignore le fichier doit être créé manuellement. Il est
généralement mis sous contrôle de version, de sorte que les paramètres se propagent à d'autres
référentiels avec push et pull.

Un fichier non suivi est ignoré si son chemin relatif au répertoire racine du référentiel, ou tout
chemin de préfixe de ce chemin, est mis en correspondance avec n'importe quel modèle dans .hgignore.

Par exemple, disons que nous avons un fichier non suivi, fichier.c, à a/b/fichier.c à l'intérieur de notre dépôt.
Mercurial ignorera fichier.c si un motif dans .hgignore allumettes a/b/fichier.c, a / b or a.

De plus, un fichier de configuration Mercurial peut référencer un ensemble de paramètres par utilisateur ou globaux.
ignorer les fichiers. Voir le ignorer clé de configuration sur le [interface utilisateur] l'article de hg aider config en
détails sur la façon de configurer ces fichiers.

Pour contrôler la gestion par Mercurial des fichiers qu'il gère, de nombreuses commandes prennent en charge le -I ainsi que
-X choix ; voir hg aider ainsi que hg aider motifs pour en savoir plus.

Les fichiers déjà suivis ne sont pas affectés par .hgignore, même s'ils apparaissent dans
.hgignore. Un fichier X non suivi peut être explicitement ajouté avec hg ajouter X, même si X serait
exclus par un motif dans .hgignore.

Syntaxe
Un fichier ignoré est un fichier texte composé d'une liste de modèles, avec un modèle par
ligne. Les lignes vides sont sautées. le # caractère est traité comme un caractère de commentaire, et le
\ caractère est traité comme un caractère d'échappement.

Mercurial prend en charge plusieurs syntaxes de modèles. La syntaxe par défaut utilisée est de style Python/Perl
expressions régulières.

Pour changer la syntaxe utilisée, utilisez une ligne de la forme suivante :

syntaxe : NOM

De Nom est l'un des suivants :

regexp

Expression régulière, syntaxe Python/Perl.

glob

Globe de style coquille.

La syntaxe choisie reste en vigueur lors de l'analyse de tous les modèles qui suivent, jusqu'à ce qu'un autre
la syntaxe est sélectionnée.

Ni les modèles glob ni regexp ne sont enracinés. Un modèle de syntaxe globale de la forme *.c sera
correspond à un fichier se terminant par .c dans n'importe quel répertoire, et un modèle d'expression régulière de la forme \.c$ ça ira
le même. Pour rooter un modèle d'expression régulière, démarrez-le avec ^.

Les sous-répertoires peuvent avoir leurs propres paramètres .hgignore en ajoutant
sous-include:chemin/vers/sous-répertoire/.hgignore à la racine .hgignore. Voir hg aider motifs en
détails sur sous-inclure : ainsi que consistent à .

Note Motifs spécifiés dans autre que .hgignore sont toujours enracinés. S'il te plait regarde hg aider
motifs pour en savoir plus.

Exemple
Voici un exemple de fichier ignoré.

# utilise la syntaxe glob.
syntaxe : glob

*.elc
*.pyc
*~

# passer à la syntaxe regexp.
syntaxe : regexp
^\.pc/

CONFIGURATION HGWEB

Le serveur Web interne de Mercurial, hgweb, peut servir soit un référentiel unique, soit un arbre de
dépôts. Dans le second cas, les chemins de référentiel et les options globales peuvent être définis à l'aide de
un fichier de configuration dédié commun à hg besoin, hgweb.wsgi, hgweb.cgi ainsi que hgweb.fcgi.

Ce fichier utilise la même syntaxe que les autres fichiers de configuration de Mercurial mais ne reconnaît que
les rubriques suivantes :

· la toile

· chemins

· collectes

La web les options sont décrites en détail dans hg aider config.

La chemins La section mappe les chemins d'URL aux chemins des référentiels dans le système de fichiers. hgweb va
ne pas exposer directement le système de fichiers - seuls les référentiels Mercurial peuvent être publiés et seuls
selon la configuration.

Le côté gauche est le chemin dans l'URL. Notez que hgweb réserve des sous-chemins comme tour or
filet, essayez d'utiliser des noms différents pour les référentiels imbriqués afin d'éviter les effets de confusion.

Le côté droit est le chemin dans le système de fichiers. Si le chemin spécifié se termine par * or **
le système de fichiers sera recherché de manière récursive pour les référentiels en dessous de ce point. Avec * it
ne se récursera pas dans les référentiels qu'il trouve (sauf pour .hg/correctifs). Avec ** il sera
également rechercher dans les répertoires de travail du référentiel et éventuellement trouver des sous-dépôts.

Dans cet exemple:

[chemins]
/projects/a = /srv/tmprepos/a
/projets/b = c:/repos/b
/ = /srv/dépôt/*
/user/bob = /home/bob/repos/**

· Les deux premières entrées font apparaître deux référentiels dans des répertoires différents sous le
même répertoire dans l'interface web

· La troisième entrée publiera tous les référentiels Mercurial trouvés dans /srv/dépôt/, Pour
exemple le référentiel /srv/dépôt/quux/ apparaîtra comme http://server/quux/

· La quatrième entrée publiera les deux http://server/user/bob/quux/ ainsi que
http://server/user/bob/quux/testsubrepo/

La collections section est obsolète et a été remplacée par chemins.

URL ainsi que Commun Arguments
Les URL sous chaque référentiel ont la forme /{commande}[/{arguments}] De {commander}
représente le nom d'une commande ou d'un gestionnaire et {arguments} représente n'importe quel nombre de
paramètres d'URL supplémentaires à cette commande.

Le serveur Web est associé à un style par défaut. Les styles correspondent à une collection de noms
modèles. Chaque modèle est utilisé pour restituer une donnée spécifique, telle qu'un ensemble de modifications
ou diff.

Le style de la requête en cours peut être remplacé de deux manières. Premièrement, si {commander}
contient un trait d'union (-), le texte avant le trait d'union définit le style. Par example,
/atom-log rendra le enregistrer gestionnaire de commandes avec le atome style. La deuxième façon de régler
le style est avec le Catégorie argument de chaîne de requête. Par example, /log?style=atomeL’
le paramètre d'URL avec trait d'union est préféré.

Tous les modèles ne sont pas disponibles pour tous les styles. Essayer d'utiliser un style qui ne
avoir tous les modèles définis peut entraîner une erreur lors du rendu de la page.

De nombreuses commandes prennent un {révision} Paramètre d'URL. Ceci définit le changeset sur lequel opérer.
Ceci est généralement spécifié comme l'abréviation hexadécimale courte à 12 chiffres pour les 40
identificateur de révision unique de caractère. Cependant, toute valeur décrite par hg aider révisions
fonctionne généralement.

Commandes ainsi que URL
Les commandes Web suivantes et leurs URL sont disponibles :

/annoter/{révision}/{chemin}
Afficher les informations sur l'ensemble de modifications pour chaque ligne d'un fichier.

La fichierannoter le modèle est rendu.

/archive/{révision}.{format}[/{chemin}]
Obtenir une archive du contenu du référentiel.

Le contenu et le type de l'archive sont définis par un paramètre de chemin d'URL. le format est
extension de fichier du type d'archive à générer. par exemple Zip *: français or tar.bz2. Pas toutes les archives
types peuvent être autorisés par la configuration de votre serveur.

Le facultatif chemin Le paramètre URL contrôle le contenu à inclure dans l'archive. Si omis,
chaque fichier de la révision spécifiée est présent dans l'archive. S'il est inclus, seul le
fichier spécifié ou le contenu du répertoire spécifié sera inclus dans l'archive.

Aucun modèle n'est utilisé pour ce gestionnaire. Un contenu binaire brut est généré.

/signets
Afficher des informations sur les signets.

Aucun argument n'est accepté.

La signets le modèle est rendu.

/branches
Afficher des informations sur les succursales.

Toutes les branches connues sont contenues dans la sortie, même les branches fermées.

Aucun argument n'est accepté.

La branches le modèle est rendu.

/changelog[/{révision}]
Afficher des informations sur plusieurs ensembles de modifications.

Si l'optionnel révision L'argument URL est absent, les informations sur tous les ensembles de modifications commencent
at pointe sera rendu. Si la révision l'argument est présent, les ensembles de modifications seront affichés
à partir de la révision spécifiée.

If révision est absent, le tour un argument de chaîne de requête peut être défini. Cela effectuera une
rechercher des ensembles de modifications.

L'argument pour tour peut être une révision unique, un jeu de révisions ou un mot-clé littéral à
rechercher dans les données de l'ensemble de modifications (équivalent à hg enregistrer -k).

La compte-tours L'argument de la chaîne de requête définit le nombre maximal d'ensembles de modifications à afficher.

Pour les non-recherches, le changelog modèle sera rendu.

/changeset[/{révision}]
Afficher des informations sur un seul ensemble de modifications.

Un argument de chemin d'URL est l'identifiant de l'ensemble de modifications à afficher. Voir hg aider révisions en
valeurs possibles. S'il n'est pas défini, le pointe Le jeu de modifications sera affiché.

La ensemble de modifications le modèle est rendu. Contenu de la balise de modification, jeu de modificationssignet,
lien de nœud de fichier, fichierpas de lien, et les nombreux modèles liés aux diffs peuvent tous être utilisés pour
produire la sortie.

/comparaison/{révision}/{chemin}
Afficher une comparaison entre l'ancienne et la nouvelle version d'un fichier à partir des modifications apportées sur un
révision particulière.

Ceci est similaire à diff gestionnaire. Cependant, ce formulaire comporte une division ou côte à côte
diff plutôt qu'un diff unifié.

La contexte L'argument de chaîne de requête peut être utilisé pour contrôler les lignes de contexte dans le diff.

La comparaison de fichiers le modèle est rendu.

/diff/{révision}/{chemin}
Montrez comment un fichier a changé dans un commit particulier.

La fichierdiff le modèle est rendu.

Ce gestionnaire est enregistré à la fois sous le /diff ainsi que /fichierdiff chemins. /diff est utilisé dans
codes modernes.

/file/{révision}[/{chemin}]
Afficher des informations sur un répertoire ou un fichier dans le référentiel.

Informations sur le chemin donné comme paramètre d'URL sera rendu.

If chemin est un répertoire, les informations sur les entrées de ce répertoire seront rendues.
Ce formulaire équivaut au manifeste gestionnaire.

If chemin est un fichier, les informations sur ce fichier seront affichées via le révision de fichier
modèle.

If chemin n'est pas défini, les informations sur le répertoire racine seront rendues.

/diff/{révision}/{chemin}
Montrez comment un fichier a changé dans un commit particulier.

La fichierdiff le modèle est rendu.

Ce gestionnaire est enregistré à la fois sous le /diff ainsi que /fichierdiff chemins. /diff est utilisé dans
codes modernes.

/filelog/{révision}/{chemin}
Afficher des informations sur l'historique d'un fichier dans le référentiel.

La compte-tours l'argument de la chaîne de requête peut être défini pour contrôler le nombre maximum d'entrées
montrer.

La journal de fichiers modèle sera rendu.

/graphique[/{révision}]
Afficher des informations sur la topologie graphique du référentiel.

Les informations rendues par ce gestionnaire peuvent être utilisées pour créer des représentations visuelles de
topologie du référentiel.

La révision Le paramètre URL contrôle l'ensemble de modifications de départ.

La compte-tours l'argument de la chaîne de requête peut définir le nombre d'ensembles de modifications pour afficher les informations
pour.

Ce gestionnaire rendra le graphique modèle.

/rubrique d'aide}]
Rendre la documentation d'aide.

Cette commande Web est à peu près équivalente à hg aider. Si un sujet est défini, cette rubrique d'aide
sera rendu. Sinon, un index des rubriques d'aide disponibles sera affiché.

La aider modèle sera rendu lors de la demande d'aide pour un sujet. sujets d'aide sera
rendu pour l'index des rubriques d'aide.

/log[/{révision}[/{chemin}]]
Afficher le référentiel ou l'historique des fichiers.

Pour les URL du formulaire /log/{révision}, une liste d'ensembles de modifications commençant au point spécifié
l'identifiant de l'ensemble de modifications est affiché. Si {révision} n'est pas défini, la valeur par défaut est pointe. Ce formulaire
est équivalent à la changelog gestionnaire.

Pour les URL du formulaire /log/{révision}/{fichier}, l'historique d'un fichier spécifique sera
montré. Ce formulaire équivaut au journal de fichiers gestionnaire.

/manifest[/{révision}[/{chemin}]]
Afficher des informations sur un répertoire.

Si les arguments de chemin d'URL sont omis, les informations sur le répertoire racine du pointe
Le jeu de modifications sera affiché.

Étant donné que ce gestionnaire ne peut afficher que des informations pour les répertoires, il est recommandé d'utiliser
le filet gestionnaire à la place, car il peut gérer à la fois les répertoires et les fichiers.

La manifeste modèle sera rendu pour ce gestionnaire.

/changeset[/{révision}]
Afficher des informations sur un seul ensemble de modifications.

Un argument de chemin d'URL est l'identifiant de l'ensemble de modifications à afficher. Voir hg aider révisions en
valeurs possibles. S'il n'est pas défini, le pointe Le jeu de modifications sera affiché.

La ensemble de modifications le modèle est rendu. Contenu de la balise de modification, jeu de modificationssignet,
lien de nœud de fichier, fichierpas de lien, et les nombreux modèles liés aux diffs peuvent tous être utilisés pour
produire la sortie.

/shortlog
Afficher des informations de base sur un ensemble de changesets.

Celui-ci accepte les mêmes paramètres que le changelog gestionnaire. La seule différence est la
journal abrégé modèle sera rendu à la place du changelog modèle.

/sommaire
Afficher un résumé de l'état du référentiel.

Les informations sur les derniers ensembles de modifications, les signets, les balises et les branches sont capturées par ce
gestionnaire.

La résumé le modèle est rendu.

/Mots clés
Afficher des informations sur les balises.

Aucun argument n'est accepté.

La étiquettes le modèle est rendu.

SUPPORT Implémentation TOPICS

liasses
conteneur pour l'échange de données de référentiel

groupes de modifications
représentation des données revlog

revlogs
mécanisme de stockage des révisions

FUSIONNER OUTILS

Pour fusionner des fichiers, Mercurial utilise des outils de fusion.

Un outil de fusion combine deux versions différentes d'un fichier dans un fichier fusionné. Les outils de fusion sont
étant donné les deux fichiers et le plus grand ancêtre commun des deux versions de fichiers, afin qu'ils puissent
déterminer les changements effectués sur les deux branches.

Les outils de fusion sont utilisés à la fois pour hg résoudre, hg fusionner, hg Mise à jour, hg retrait et dans plusieurs
Extensions.

Habituellement, l'outil de fusion essaie de réconcilier automatiquement les fichiers en combinant tous
changements sans chevauchement qui se sont produits séparément dans les deux évolutions différentes de la
même fichier de base initial. De plus, certains programmes de fusion interactifs facilitent la
résoudre manuellement les fusions conflictuelles, soit de manière graphique, soit en insérant
marqueurs de conflit. Mercurial n'inclut aucun programme de fusion interactif mais s'appuie sur
outils externes pour cela.

Disponible fusionner les outils
Les outils de fusion externes et leurs propriétés sont configurés dans la configuration des outils de fusion
rubrique - voir hgrc(5) - mais ils peuvent souvent être simplement nommés par leur exécutable.

Un outil de fusion est généralement utilisable si son exécutable se trouve sur le système et s'il
peut gérer la fusion. L'exécutable est trouvé s'il s'agit d'un exécutable absolu ou relatif
path ou le nom d'une application dans le chemin de recherche de l'exécutable. L'outil est supposé
être capable de gérer la fusion s'il peut gérer les liens symboliques si le fichier est un lien symbolique, s'il le peut
gérer les fichiers binaires si le fichier est binaire, et si une interface graphique est disponible si l'outil l'exige
une interface graphique.

Certains outils de fusion internes peuvent être utilisés. Les outils de fusion internes sont :

:décharger

Crée trois versions des fichiers à fusionner, contenant le contenu de local,
autre et base. Ces fichiers peuvent ensuite être utilisés pour effectuer une fusion manuellement. Si la
le fichier à fusionner est nommé un.txt, ces fichiers seront donc nommés
a.txt.local, a.txt.autre ainsi que a.txt.base et ils seront placés dans le même
répertoire en tant que un.txt.

:échouer

Plutôt que d'essayer de fusionner les fichiers qui ont été modifiés sur les deux branches, il marque
eux comme non résolus. La commande resolve doit être utilisée pour résoudre ces conflits.

:locale

Utilise la version locale des fichiers comme version fusionnée.

:fusionner

Utilise l'algorithme de fusion simple interne non interactif pour fusionner des fichiers. Ce sera
échouer s'il y a des conflits et laisser des marqueurs dans le fichier partiellement fusionné.
Les marqueurs auront deux sections, une pour chaque côté de la fusion.

:merge-local

Comme :fusionner, mais résoudre tous les conflits de manière non interactive en faveur du local
changements.

:fusion-autre

Comme : fusionner, mais résoudre tous les conflits de manière non interactive en faveur de l'autre
changements.

:fusion3

Utilise l'algorithme de fusion simple interne non interactif pour fusionner des fichiers. Ce sera
échouer s'il y a des conflits et laisser des marqueurs dans le fichier partiellement fusionné.
Le marqueur aura trois sections, une de chaque côté de la fusion et une pour le
contenu de base.

:autre

Utilise l'autre version des fichiers comme version fusionnée.

:rapide

Demande à l'utilisateur quelle version locale ou autre conserver comme version fusionnée
version.

:tagmerge

Utilise l'algorithme de fusion de balises interne (expérimental).

:syndicat

Utilise l'algorithme de fusion simple interne non interactif pour fusionner des fichiers. Ce sera
utilisez les côtés gauche et droit pour les régions en conflit. Aucun marqueur n'est inséré.

Les outils internes sont toujours disponibles et ne nécessitent pas d'interface graphique, mais ne le seront pas par défaut.
gérer les liens symboliques ou les fichiers binaires.

Choisir a fusionner outil
Mercurial utilise ces règles pour décider quel outil de fusion utiliser :

1. Si un outil a été spécifié avec l'option --tool pour fusionner ou résoudre, il est utilisé.
S'il s'agit du nom d'un outil dans la configuration merge-tools, sa configuration est
utilisé. Sinon, l'outil spécifié doit être exécutable par le shell.

2. Si le HGFUSION variable d'environnement est présente, sa valeur est utilisée et doit être
exécutable par le shell.

3. Si le nom de fichier du fichier à fusionner correspond à l'un des modèles du
section de configuration de merge-patterns, le premier outil de fusion utilisable correspondant à un
le motif correspondant est utilisé. Ici, les capacités binaires de l'outil de fusion ne sont pas
pris en considération.

4. Si ui.merge est défini, il sera considéré ensuite. Si la valeur n'est pas le nom d'un
outil configuré, la valeur spécifiée est utilisée et doit être exécutable par le shell.
Sinon, l'outil nommé est utilisé s'il est utilisable.

5. Si des outils de fusion utilisables sont présents dans la section de configuration des outils de fusion, celui
avec la priorité la plus élevée est utilisé.

6. Si un programme nommé fusionner peut être trouvé sur le système, il est utilisé - mais il sera par
par défaut ne pas être utilisé pour les liens symboliques et les fichiers binaires.

7. Si le fichier à fusionner n'est pas binaire et n'est pas un lien symbolique, alors interne :fusionner is
utilisé.

8. La fusion du fichier échoue et doit être résolue avant la validation.

Remarque Après avoir sélectionné un programme de fusion, Mercurial tentera par défaut de fusionner le
fichiers en utilisant d'abord un algorithme de fusion simple. Seulement s'il ne réussit pas à cause de
changements conflictuels Mercurial exécutera réellement le programme de fusion. Que ce soit pour
utiliser d'abord l'algorithme de fusion simple peut être contrôlé par le paramètre de préfusion de
l'outil de fusion. La préfusion est activée par défaut sauf si le fichier est binaire ou un
lien symbolique.

Voir les sections merge-tools et ui de hgrc(5) pour plus de détails sur la configuration de la fusion
outils.

EN PRÉCISANT PLUSIEURS RÉVISIONS

Lorsque Mercurial accepte plus d'une révision, elles peuvent être spécifiées individuellement, ou
fourni sous la forme d'une plage topologiquement continue, séparée par le caractère ":".

La syntaxe de la notation de plage est [BEGIN]:[END], où BEGIN et END sont la révision
identifiants. BEGIN et END sont facultatifs. Si BEGIN n'est pas spécifié, la valeur par défaut est
numéro de révision 0. Si END n'est pas spécifié, il s'agit par défaut de la pointe. La plage ":" donc
signifie "toutes les révisions".

Si BEGIN est supérieur à END, les révisions sont traitées dans l'ordre inverse.

Une plage agit comme un intervalle fermé. Cela signifie qu'une plage de 3:5 donne 3, 4 et 5.
De même, une plage de 9:6 donne 9, 8, 7 et 6.

DOSSIER Nom MOTIFS

Mercurial accepte plusieurs notations pour identifier un ou plusieurs fichiers à la fois.

Par défaut, Mercurial traite les noms de fichiers comme des modèles glob étendus de style shell.

Les notations de modèle alternatives doivent être spécifiées explicitement.

Note Motifs spécifiés dans .hgignore ne sont pas rootés. S'il te plait regarde hg aider ignorer en
détails.

Pour utiliser un nom de chemin simple sans aucune correspondance de modèle, commencez-le par chemin:. Ces chemin
les noms doivent correspondre complètement à partir de la racine du référentiel actuel.

Pour utiliser un glob étendu, commencez un nom par global :. Les globs sont enracinés au courant
annuaire; un globe tel que *.c ne correspondra qu'aux fichiers du répertoire courant se terminant par
.c.

Les extensions de syntaxe glob prises en charge sont ** pour faire correspondre n'importe quelle chaîne à travers les séparateurs de chemin et
{un B} pour signifier "a ou b".

Pour utiliser une expression régulière Perl/Python, commencez un nom par re:. Correspondance de modèle d'expression régulière
est ancré à la racine du référentiel.

Pour lire des modèles de nom à partir d'un fichier, utilisez fichier de liste : or fichier_liste0 :. Ce dernier attend nul
motifs délimités tandis que le premier attend des sauts de ligne. Chaque chaîne lue à partir du fichier est
lui-même traité comme un modèle de fichier.

Pour lire un ensemble de modèles à partir d'un fichier, utilisez consistent à or sous-inclure :. consistent à utilisera tout
les motifs du fichier donné et les traiter comme s'ils avaient été transmis manuellement.
sous-inclure : n'appliquera les modèles qu'aux fichiers qui se trouvent sous la sous-inclusion
répertoire du fichier. Voir hg aider ignorer pour plus de détails sur le format de ces fichiers.

Tous les modèles, à l'exception de global : spécifié dans la ligne de commande (pas pour -I or -X options), peut
correspondre également aux répertoires : les fichiers sous les répertoires correspondants sont traités comme correspondants.

Exemples simples :

path:foo/bar une barre de nom dans un répertoire nommé foo à la racine
du référentiel
path:path:name un fichier ou un répertoire nommé "path:name"

Exemples globaux :

glob:*.c tout nom se terminant par ".c" dans le répertoire courant
*.c tout nom se terminant par ".c" dans le répertoire courant
**.c tout nom se terminant par ".c" dans tout sous-répertoire du
répertoire courant, y compris lui-même.
foo/*.c tout nom se terminant par ".c" dans le répertoire foo
foo/**.c tout nom se terminant par ".c" dans n'importe quel sous-répertoire de foo
y compris lui-même.

Exemples d'expressions régulières :

re:.*\.c$ n'importe quel nom se terminant par ".c", n'importe où dans le référentiel

Exemples de fichiers:

listfile:list.txt lit la liste de list.txt avec un modèle de fichier par ligne
listfile0:list.txt lit la liste de list.txt avec des délimiteurs d'octets nuls

Voir aussi hg aider ensembles de fichiers.

Inclure des exemples :

include:path/to/mypatternfile lit les modèles à appliquer à tous les chemins
subinclude:path/to/subignorefile lit les modèles spécifiquement pour les chemins dans le
sous-répertoire

TRAVAIL WITH ÉTAPES

Quoi phases ?
Les phases sont un système de suivi des ensembles de modifications qui ont été ou devraient être partagés. Ce
permet d'éviter les erreurs courantes lors de la modification de l'historique (par exemple, avec le mq ou rebase
rallonges).

Chaque ensemble de modifications d'un référentiel se trouve dans l'une des phases suivantes :

· public : le changeset est visible sur un serveur public

· brouillon : l'ensemble de modifications n'est pas encore publié

· secret : l'ensemble de modifications ne doit pas être poussé, extrait ou cloné

Ces phases sont ordonnées (public < brouillon < secret) et aucun ensemble de modifications ne peut être dans une version inférieure
phase que ses ancêtres. Par exemple, si un changeset est public, tous ses ancêtres sont
également publique. Enfin, les phases de changeset ne doivent être modifiées que vers la phase publique.

Comment phases géré ?
Pour la plupart, les phases doivent fonctionner de manière transparente. Par défaut, un changeset est créé dans
la phase de brouillon et passe à la phase publique lorsqu'il est poussé à un autre
dépôt.

Une fois les changesets rendus publics, les extensions comme mq et rebase refuseront de fonctionner sur
pour éviter de créer des ensembles de modifications en double. Les phases peuvent également être manipulées manuellement
les hg phase commande si nécessaire. Voir hg aider -v phase pour des exemples.

Pour rendre vos commits secrets par défaut, mettez ceci dans votre fichier de configuration :

[étapes]
nouveau-commit = secret

Phases ainsi que serveurs
Normalement, tous les serveurs sont édition par défaut. Ça signifie:

- tous les brouillons de modifications extraits ou clonés apparaissent en phase
public sur le client

- tous les brouillons de modifications qui sont poussés apparaissent comme publics sur les deux
client et serveur

- les ensembles de modifications secrets ne sont ni poussés, extraits ou clonés

Remarque L'extraction d'un brouillon d'un ensemble de modifications à partir d'un serveur de publication ne le marque pas comme public sur
côté serveur en raison de la nature en lecture seule de pull.

Parfois, il peut être souhaitable de pousser et de tirer des ensembles de modifications dans la phase de brouillon pour partager
travail inachevé. Cela peut être fait en configurant un référentiel pour désactiver la publication dans son
fichier de configuration:

[étapes]
publier = Faux

See hg aider config pour plus d'informations sur les fichiers de configuration.

Remarque Les serveurs exécutant des versions plus anciennes de Mercurial sont traités comme des publications.

Remarque Les ensembles de modifications en phase secrète ne sont pas échangés avec le serveur. Cela s'applique à leur
content : noms de fichier, contenu de fichier et métadonnées de l'ensemble de modifications. Pour des raisons techniques,
l'identifiant (par exemple d825e4025e39) du changeset secret peut être communiqué à
le serveur.

Exemples
· répertorier les ensembles de modifications en phase brouillon ou secrète :

hg log -r "non public()"

· changer tous les ensembles de modifications secrets en brouillon :

hg phase --draft "secret()"

· déplacer de force l'ensemble de modifications actuel et ses descendants de public à brouillon :

hg phase --force --draft .

· afficher une liste de révision et de phase de changeset :

hg log --template "{rev} {phase}\n"

· resynchroniser les brouillons des modifications relatives à un référentiel distant :

hg phase -fd "sortant (URL)"

See hg aider phase pour plus d'informations sur la manipulation manuelle des phases.

EN PRÉCISANT UNIQUE RÉVISIONS

Mercurial prend en charge plusieurs façons de spécifier des révisions individuelles.

Un entier simple est traité comme un numéro de révision. Les entiers négatifs sont traités comme
décalages séquentiels à partir de la pointe, avec -1 désignant la pointe, -2 désignant la révision précédente
jusqu'à la pointe, et ainsi de suite.

Une chaîne hexadécimale à 40 chiffres est traitée comme un identifiant de révision unique.

Une chaîne hexadécimale de moins de 40 caractères est traitée comme une révision unique
identifiant et est appelé identifiant abrégé. Un identifiant de forme abrégée est uniquement
valide s'il s'agit du préfixe d'exactement un identifiant complet.

Toute autre chaîne est traitée comme un signet, une balise ou un nom de branche. Un signet est un élément mobile
pointeur vers une révision. Une balise est un nom permanent associé à une révision. Un nom de branche
désigne le chef de branche ouvert le plus élevé de cette branche - ou s'ils sont tous fermés, le
tête la plus fermée de la branche. Les noms de signet, de balise et de branche ne doivent pas contenir le
":" personnage.

Le nom réservé "tip" identifie toujours la révision la plus récente.

Le nom réservé "null" indique la révision nulle. C'est la révision d'un vide
référentiel et le parent de la révision 0.

Le nom réservé "." indique le parent du répertoire de travail. Si aucun répertoire de travail n'est
extrait, il est équivalent à null. Si une fusion non validée est en cours, "." est le
révision du premier parent.

EN PRÉCISANT REVIEW PARURES

Mercurial prend en charge un langage fonctionnel pour sélectionner un ensemble de révisions.

Le langage prend en charge un certain nombre de prédicats qui sont joints par des opérateurs infixes.
Les parenthèses peuvent être utilisées pour le regroupement.

Les identificateurs tels que les noms de succursales peuvent nécessiter des guillemets simples ou doubles s'ils
contenir des caractères comme - ou s'ils correspondent à l'un des prédicats prédéfinis.

Les caractères spéciaux peuvent être utilisés dans les identifiants entre guillemets en les échappant, par exemple, \n is
interprété comme une nouvelle ligne. Pour éviter qu'elles ne soient interprétées, les chaînes peuvent être préfixées
avec r, par exemple r'...'.

Il existe un seul opérateur de préfixe :

ne sauraient x

Les changesets ne sont pas dans x. La forme courte est ! x.

Voici les opérateurs d'infixe pris en charge :

x :: y

Une plage DAG, c'est-à-dire tous les ensembles de modifications descendants de x et ancêtres de y,
y compris x et y eux-mêmes. Si le premier point final est omis, cela équivaut
à ancêtres(y), si la seconde est omise, cela équivaut à descendance(x).

Une syntaxe alternative est x..y.

x: y

Tous les ensembles de modifications avec des numéros de révision entre x et y, tous deux inclus. Soit
endpoint peut être omis, ils sont par défaut à 0 et tip.

x ainsi que y

L'intersection des changesets en x et y. La forme courte est x & y.

x or y

L'union des changesets en x et y. Il existe deux formes abrégées alternatives : x | y
ainsi que x + y.

x - y

Changesets dans x mais pas dans y.

x ^ n

Le nième parent de x, n == 0, 1 ou 2. Pour n == 0, x ; pour n == 1, le premier parent
de chaque changeset dans x ; pour n == 2, le deuxième parent du changeset dans x.

x~n

Le nième premier ancêtre de x ; x~0 est x ; x~3 is x^^^^.

Il existe un seul opérateur suffixé :

x^

Équivalent à x ^ 1, le premier parent de chaque ensemble de modifications dans x.

Les prédicats suivants sont pris en charge :

ajoute (motif)

Ensembles de modifications qui ajoutent un modèle de correspondance de fichier.

Le motif sans genre explicite comme global : devrait être relatif à la
répertoire courant et faire correspondre un fichier ou un répertoire.

tout()

Tous les changesets, les mêmes que 0 : pourboire.

ancêtre(*changeset)

Un plus grand ancêtre commun des changesets.

Accepte 0 ou plusieurs ensembles de modifications. Retournera une liste vide si aucun argument n'est passé.
Le plus grand ancêtre commun d'un seul ensemble de modifications est cet ensemble de modifications.

ancêtres (ensemble)

Ensembles de modifications qui sont les ancêtres d'un ensemble de modifications dans l'ensemble.

auteur (chaîne)

Alias ​​pour utilisateur (chaîne).

bissectrice (chaîne)

Ensembles de modifications marqués dans le statut bisect spécifié :

· Bien, mauvais, sauter: csets explicitement marqués comme bon/mauvais/ignorer

· pour les, les maux : csets topologiquement bon/mauvais

· gamme : csets participant à la bissection

· taillé : csets qui sont bons, mauvais ou sautés

· non testé : csets dont le sort est encore inconnu

· ignoré : csets ignorés en raison de la topologie DAG

· actuel : le cset actuellement bissecté

signet([nom])

Le signet nommé ou tous les signets.

If prénom commence avec re:, le reste du nom est traité comme un nom normal
expression. Pour faire correspondre un signet qui commence réellement par re:, utilisez le préfixe
littéral:.

branche (chaîne or ensemble)

Tous les changesets appartenant à la branche donnée ou aux branches de la donnée
ensembles de modifications.

If un magnifique commence avec re:, le reste du nom est traité comme un nom normal
expression. Pour faire correspondre une branche qui commence réellement par re:, utilisez le préfixe
littéral:.

point de branchement()

Changesets avec plus d'un enfant.

heurté ()

Ensembles de modifications mutables marqués comme successeurs des ensembles de modifications publics.

Seuls les changesets non publics et non obsolètes peuvent être heurté.

empaqueter()

Ensembles de modifications dans le bundle.

L'ensemble doit être spécifié par l'option -R.

enfants (ensemble)

Ensembles de modifications enfants des ensembles de modifications dans l'ensemble.

fermé()

L'ensemble de modifications est fermé.

contient (motif)

Le manifeste de la révision contient un modèle de correspondance de fichier (mais peut ne pas le modifier).
See hg aider motifs pour plus d'informations sur les modèles de fichiers.

Le motif sans genre explicite comme global : devrait être relatif à la
répertoire actuel et correspond exactement à un fichier pour plus d'efficacité.

converti([id])

Ensembles de modifications convertis à partir de l'identifiant donné dans l'ancien référentiel s'il est présent, ou
tous les changesets convertis si aucun identifiant n'est spécifié.

date (intervalle)

Changesets dans l'intervalle, voir hg aider dates.

desc(chaîne)

Rechercher le message de validation pour la chaîne. La correspondance est insensible à la casse.

descendants (ensemble)

Les ensembles de modifications qui sont les descendants des ensembles de modifications dans l'ensemble.

destination([ensemble])

Les ensembles de modifications qui ont été créés par une opération de greffe, de transplantation ou de rebasage, avec le
révisions données spécifiées comme source. L'omission de l'ensemble facultatif revient au même que
passant tout().

divergent()

Successeurs finaux des ensembles de modifications avec un ensemble alternatif de successeurs finaux.

Brouillon()

Changeset en phase de brouillon.

disparu()

Ensembles de modifications obsolètes avec des descendants obsolètes uniquement.

supplémentaire(étiquette, [évaluer])

Ensembles de modifications avec l'étiquette donnée dans les métadonnées supplémentaires, avec l'option donnée
valeur.

If Plus-value commence avec re:, le reste de la valeur est traité comme un nombre normal
expression. Pour faire correspondre une valeur qui commence réellement par re:, utilisez le préfixe
littéral:.

fichier (motif)

Ensembles de modifications affectant les fichiers correspondant au modèle.

Pour un résultat plus rapide mais moins précis, pensez à utiliser fichierlog() à la place.

Ce prédicat utilise global : comme type de modèle par défaut.

filelog (motif)

Ensembles de modifications connectés au journal de fichiers spécifié.

Pour des raisons de performances, ne visite que les révisions mentionnées dans le journal des fichiers au niveau du fichier,
plutôt que de filtrer tous les ensembles de modifications (beaucoup plus rapide, mais n'inclut pas
suppressions ou modifications en double). Pour un résultat plus lent et plus précis, utilisez fichier().

Le motif sans genre explicite comme global : devrait être relatif à la
répertoire actuel et correspond exactement à un fichier pour plus d'efficacité.

Si certains liens pointent vers des révisions filtrées par le référentiel actuel, nous travaillerons
autour pour renvoyer une valeur non filtrée.

premier (ensemble, [n])

Un alias pour limit().

suivre ([motif])

Un alias pour ::. (ancêtres du premier parent du répertoire de travail). Si modèle
est spécifié, les historiques des fichiers correspondant au modèle donné sont suivis, y compris
copies.

grep(expression régulière)

Comme mot-clé (chaîne) mais accepte une regex. Utiliser grep(r'...') pour assurer une évasion spéciale
les caractères sont traités correctement. contrairement à mot-clé (chaîne), la correspondance est
sensible aux majuscules et minuscules.

diriger()

Changeset est un responsable de branche nommé.

têtes (ensemble)

Membres de l'ensemble sans enfants dans l'ensemble.

caché()

Ensembles de modifications masqués.

identifiant (chaîne)

Révision spécifiée sans ambiguïté par le préfixe de chaîne hexadécimale donné.

mot-clé (chaîne)

Recherchez le message de validation, le nom d'utilisateur et les noms des fichiers modifiés pour la chaîne. Le match
est insensible à la casse.

dernier(set, [n])

Les n derniers membres de l'ensemble, la valeur par défaut étant 1.

limite(set[, n[, décalage]])

N premiers membres de l'ensemble, la valeur par défaut étant 1, en commençant par le décalage.

correspondance (révision [, champ])

Ensembles de modifications dans lesquels un ensemble de champs donné correspond à l'ensemble de champs de la
révision ou ensemble.

Pour faire correspondre plus d'un champ, passez la liste des champs à faire correspondre séparés par des espaces
(par exemple auteur la description).

Les champs valides sont les champs de révision les plus courants et certains champs spéciaux.

Les champs de révision réguliers sont la description, auteur, une succursale, données, fichiers, phase,
parents, sous-état, utilisateur ainsi que diff. Noter que auteur ainsi que utilisateur sont des synonymes. diff
fait référence au contenu de la révision. Deux révisions correspondant à leur diff sera également
correspondre à leur fichiers.

Les champs spéciaux sont résumé ainsi que métadonnées: résumé correspond à la première ligne du
la description. métadonnées équivaut à faire correspondre la description utilisateur données (c'est-à-dire qu'il
correspond aux principaux champs de métadonnées).

métadonnées est le champ par défaut qui est utilisé lorsqu'aucun champ n'est spécifié. Tu peux
correspondre à plus d'un champ à la fois.

maximum (ensemble)

Ensemble de modifications avec le numéro de révision le plus élevé dans l'ensemble.

fusionner()

Changeset est un ensemble de modifications de fusion.

min (ensemble)

Ensemble de modifications avec le numéro de révision le plus bas dans l'ensemble.

modifie (motif)

Ensembles de modifications modifiant les fichiers correspondant au modèle.

Le motif sans genre explicite comme global : devrait être relatif à la
répertoire courant et faire correspondre un fichier ou un répertoire.

nommé (espace de noms)

Les changesets dans un espace de noms donné.

If namespace commence avec re:, le reste de la chaîne est traité comme un normal
expression. Pour faire correspondre un espace de noms qui commence réellement par re:, utilisez le préfixe
littéral:.

obsolète()

Changeset modifiable avec une version plus récente.

seulement (ensemble, [ensemble])

Ensembles de modifications qui sont les ancêtres du premier ensemble qui ne sont les ancêtres d'aucun autre
tête dans le repo. Si un deuxième ensemble est spécifié, le résultat est les ancêtres du
premier ensemble qui ne sont pas des ancêtres du deuxième ensemble (c'est-à-dire :: - :: ).

origine([ensemble])

Ensembles de modifications spécifiés comme source pour les greffes, transplantations ou rebases
qui a créé les révisions données. Omettre l'ensemble optionnel revient à passer
tous(). Si un changeset créé par ces opérations est lui-même spécifié comme source
pour l'une de ces opérations, seul le changeset source de la première opération est
choisi.

sortant([chemin])

Ensembles de modifications introuvables dans le référentiel de destination spécifié ou le push par défaut
emplacement.

p1([ensemble])

Premier parent des ensembles de modifications dans l'ensemble, ou le répertoire de travail.

p2([ensemble])

Second parent des ensembles de modifications dans l'ensemble, ou le répertoire de travail.

parents([ensemble])

L'ensemble de tous les parents pour tous les ensembles de modifications dans l'ensemble, ou le répertoire de travail.

présent (ensemble)

Un ensemble vide, si aucune révision dans l'ensemble n'est trouvée ; sinon, toutes les révisions dans l'ensemble.

Si l'une des révisions spécifiées n'est pas présente dans le référentiel local, la requête est
normalement avorté. Mais ce prédicat permet à la requête de continuer même dans un tel
Cas.

Publique()

Changeset en phase publique.

distant([identifiant [,chemin]])

Révision locale qui correspond à l'identifiant donné dans un référentiel distant, si
cadeau. Ici le '.' l'identifiant est un synonyme de la branche locale actuelle.

supprime (motif)

Changesets qui suppriment les fichiers correspondant au modèle.

Le motif sans genre explicite comme global : devrait être relatif à la
répertoire courant et faire correspondre un fichier ou un répertoire.

tour(nombre)

Révision avec l'identifiant numérique donné.

inverser (ensemble)

Ordre inverse de l'ensemble.

racines (ensemble)

Ensembles de modifications dans l'ensemble sans ensemble de modifications parent dans l'ensemble.

secrète()

Changeset en phase secrète.

trier(ensemble[, [-]clé...])

Tri défini par clés. L'ordre de tri par défaut est croissant, spécifiez une clé comme -clé à
trier par ordre décroissant.

Les clés peuvent être :

· tour pour le numéro de révision,

· une succursale pour le nom de la branche,

· desc pour le message de commit (description),

· utilisateur pour le nom d'utilisateur (auteur peut être utilisé comme alias),

· données pour la date d'engagement

sous-dépôt([motif])

Ensembles de modifications qui ajoutent, modifient ou suppriment le sous-dépôt donné. Si aucun modèle de sous-dépôt n'est
nommé, toutes les modifications de sous-dépôt sont renvoyées.

balise([nom])

La balise spécifiée par son nom, ou toutes les révisions balisées si aucun nom n'est donné.

If prénom commence avec re:, le reste du nom est traité comme un nom normal
expression. Pour faire correspondre une balise qui commence réellement par re:, utilisez le préfixe littéral:.

instable()

Ensembles de modifications non obsolètes avec des ancêtres obsolètes.

utilisateur (chaîne)

Le nom d'utilisateur contient une chaîne. La correspondance est insensible à la casse.

If un magnifique commence avec re:, le reste de la chaîne est traité comme un normal
expression. Pour faire correspondre un utilisateur qui contient réellement re:, utilisez le préfixe littéral:.

De nouveaux prédicats (appelés "alias") peuvent être définis, en utilisant n'importe quelle combinaison de
prédicats ou autres alias. Une définition d'alias ressemble à :

=

dans l' revsetalias section d'un fichier de configuration Mercurial. Arguments de la forme $1,
$2, etc. sont substitués de l'alias dans la définition.

Par exemple,

[revsetalias]
h = têtes()
d($1) = tri($1, date)
rs($1, $2) = inverse(tri($1, $2))

définit trois alias, h, det rs. rs(0:astuce, auteur) est exactement équivalent à
reverse(sort(0:astuce, auteur)).

Un opérateur infixe ## peut concaténer des chaînes et des identifiants en une seule chaîne. Par exemple:

[revsetalias]
issue($1) = grep(r'\bissue[ :]?' ## $1 ## r'\b|\bbug\(' ## $1 ## r'\)')

aide(1234) équivaut à grep(r'\bissue[ :]?1234\b|\bbogue\(1234\)') dans ce cas. Ce
correspond à tous les "issue 1234", "issue:1234", "issue1234" et "bug(1234) ".

Tous les autres opérateurs de préfixe, d'infixe et de suffixe ont une priorité inférieure à ##. Par exemple, $1
## $ 2 ~ 2 équivaut à ($ 1 ## 2 $)~2.

Équivalents en ligne de commande pour hg enregistrer:

-f -> ::.
-dx -> date(x)
-kx -> mot clé(x)
-m -> fusionner()
-ux -> utilisateur(x)
-bx -> branche(x)
-P x -> !::x
-lx -> limite(expr, x)

Quelques exemples de requêtes :

· Changesets sur la branche par défaut :

hg log -r "branche (par défaut)"

· Changesets sur la branche par défaut depuis la balise 1.5 (hors fusions) :

hg log -r "branch(default) and 1.5 :: and not merge()"

· Têtes d'agence ouvertes :

hg log -r "head() et non fermé()"

· Changesets entre les balises 1.3 et 1.5 mentionnant "bug" qui affectent hgext/*:

hg log -r "1.3 :: 1.5 et mot-clé (bogue) et fichier ('hgext/*')"

· Ensembles de modifications validés en mai 2008, triés par utilisateur :

hg log -r "sort(date('Mai 2008'), utilisateur)"

· Ensembles de modifications mentionnant "bogue" ou "problème" qui ne sont pas dans une version taguée :

hg log -r "(mot-clé(bug) ou mot-clé(problème)) et non ancêtres(tag())"

EN UTILISANT MERCURIEL De ÉCRITURES ET AUTOMATION

Il est courant que les machines (par opposition aux humains) consomment du Mercurial. Cette rubrique d'aide
décrit certaines des considérations relatives à l'interfaçage des machines avec Mercurial.

Choisir an Interfaces
Les machines ont le choix entre plusieurs méthodes pour s'interfacer avec Mercurial. Ceux-ci inclus:

· Exécution de la hg processus

· Interroger un serveur HTTP

· Appel à un serveur de commande

Exécuter hg processus est très similaire à la façon dont les humains interagissent avec Mercurial dans la coque.
Il devrait déjà vous être familier.

hg besoin peut être utilisé pour démarrer un serveur. Par défaut, cela démarrera un serveur HTTP "hgweb".
Ce serveur HTTP prend en charge les sorties lisibles par machine, telles que JSON. Pour en savoir plus, voir hg
aider hgweb.

hg besoin peut également démarrer un "serveur de commandes". Les clients peuvent se connecter à ce serveur et émettre
Commandes mercurielles via un protocole spécial. Pour plus de détails sur le serveur de commandes,
y compris des liens vers des bibliothèques clientes, voir https://mercurial.selenic.com/wiki/CommandServer.

hg besoin les interfaces basées sur (le hgweb et les serveurs de commandes) ont l'avantage sur les simples
hg processus d'invocations dans la mesure où ils sont probablement plus efficaces. C'est parce qu'il y a
surcharge importante pour générer de nouveaux processus Python.

Conseil Si vous devez invoquer plusieurs hg processus en peu de temps et/ou la performance est
important pour vous, l'utilisation d'une interface basée sur un serveur est fortement recommandée.

Environment Variables
Comme documenté dans hg aider sûr, heureux et sain, diverses variables d'environnement influencent
fonctionnement de Mercurial. Les éléments suivants sont particulièrement pertinents pour les machines consommant
Mercuriel:

HGPLAIN
S'il n'est pas défini, la sortie de Mercurial pourrait être influencée par les paramètres de configuration qui
avoir un impact sur son encodage, son mode verbeux, sa localisation, etc.

Il est fortement recommandé aux machines de définir cette variable lors de l'appel hg
procédés.

HGENCODAGE
S'il n'est pas défini, les paramètres régionaux utilisés par Mercurial seront détectés à partir de l'environnement. Si
les paramètres régionaux déterminés ne prennent pas en charge l'affichage de certains caractères, Mercurial peut
rendent ces séquences de caractères incorrectes (souvent en utilisant "?" comme espace réservé
pour les caractères non valides dans les paramètres régionaux actuels).

Définir explicitement cette variable d'environnement est une bonne pratique pour garantir
des résultats cohérents. "utf-8" est un bon choix sur les environnements de type UNIX.

HGRCPATH
S'il n'est pas défini, Mercurial héritera des options de configuration des fichiers de configuration en utilisant le
processus décrit dans hg aider config. Cela inclut l'héritage de l'utilisateur ou de l'ensemble du système
fichiers de configuration.

Lorsqu'un contrôle maximal sur la configuration de Mercurial est souhaité, la valeur de
HGRCPATH peut être défini sur un fichier explicite avec de bonnes configurations connues. Dans de rares cas, le
la valeur peut être définie sur un fichier vide ou sur le périphérique nul (souvent / dev / null) dériver
chargement de tout fichier de configuration utilisateur ou système. Notez que ces approches peuvent avoir
conséquences imprévues, car les fichiers de configuration utilisateur et système définissent souvent les choses
comme le nom d'utilisateur et les extensions qui peuvent être nécessaires pour s'interfacer avec un
dépôt.

Les aliments Command Sortie
Il est courant que les machines aient besoin d'analyser la sortie des commandes Mercurial pour les
Les données. Cette section décrit les différentes techniques pour le faire.

Analyse raw Command Sortie
La solution la plus simple et la plus efficace pour consommer la sortie de commande consiste probablement à simplement
invoquer hg commandes comme vous le feriez en tant qu'utilisateur et analysez leur sortie.

La sortie de nombreuses commandes peut facilement être analysée avec des outils tels que grep, sedet awk.

Un inconvénient potentiel avec l'analyse de la sortie de la commande est que la sortie des commandes peut changer
lorsque Mercurial est mis à jour. Bien que Mercurial s'efforce généralement d'être solide en arrière
compatibilité, la sortie de la commande change parfois. Avoir des tests pour votre automatisation
interaction avec hg commandes est généralement recommandé, mais est encore plus important lorsque
l'analyse brute de la sortie de la commande est impliquée.

En utilisant Gabarits à Control Sortie
Merci beaucoup hg les commandes prennent en charge la sortie modélisée via le -T/--modèle argument. Pour en savoir plus, voir
hg aider modèles.

Les modèles sont utiles pour contrôler explicitement la sortie afin que vous obteniez exactement les données
vous voulez formaté comme vous le voulez. Par exemple, enregistrer -T {nœud}\n peut être utilisé pour imprimer un
liste délimitée par une nouvelle ligne de nœuds de modifications au lieu d'une sortie personnalisée contenant
auteurs, dates, descriptions, etc.

Conseil Si l'analyse de la sortie de commande brute est trop compliquée, envisagez d'utiliser des modèles pour
votre vie plus facile.

La -T/--modèle L'argument permet de spécifier des styles prédéfinis. Navires Mercurial avec le
styles lisibles par machine json ainsi que xml, qui fournissent respectivement une sortie JSON et XML.
Ceux-ci sont utiles pour produire une sortie lisible par machine telle quelle.

Important
La json ainsi que xml les styles sont considérés comme expérimentaux. Bien qu'ils puissent être attrayants
à utiliser pour obtenir facilement une sortie lisible par machine, leur comportement peut changer dans
versions ultérieures.

Ces styles peuvent également présenter des résultats inattendus lorsqu'ils traitent avec certains
encodages. Mercurial traite des choses comme les noms de fichiers comme une série d'octets et
normalisation de certaines séquences d'octets en JSON ou XML avec certains paramètres d'encodage
peut conduire à des surprises.

Command Server Sortie
Si vous utilisez le serveur de commandes pour interagir avec Mercurial, vous utilisez probablement un
bibliothèque/API qui résume les détails d'implémentation du serveur de commandes. Si oui, cela
la couche d'interface peut effectuer l'analyse pour vous, vous épargnant le travail de mise en œuvre
toi même.

Sortie Verbosité
Les commandes ont souvent une verbosité de sortie variable, même lorsque des styles lisibles par machine sont
utilisé (par ex. -T json). Ajouter -v/--verbeux ainsi que --déboguer aux arguments de la commande peut
augmenter la quantité de données exposées par Mercurial.

Une autre façon d'obtenir les données dont vous avez besoin consiste à spécifier explicitement un modèle.

Autre Les sujets
les revets
Les ensembles de révisions sont un langage de requête fonctionnel permettant de sélectionner un ensemble de révisions.
Considérez-le comme SQL pour les référentiels Mercurial. Les revsets sont utiles pour interroger
référentiels pour des données spécifiques.

See hg aider les revets pour plus d'information.

Partager extension
La Partager L'extension fournit une fonctionnalité pour partager les données du référentiel à travers
plusieurs exemplaires de travail. Il peut même automatiquement "grouper" le stockage pour logiquement
référentiels associés lors du clonage.

Configuration du Partager l'extension peut entraîner une utilisation importante des ressources
réduction, notamment autour de l'espace disque et du réseau. C'est particulièrement vrai
pour les environnements d'intégration continue (CI).

See hg aider -e Partager pour plus d'information.

SOUS-DÉPÔTS

Les sous-dépôts vous permettent d'imbriquer des dépôts ou des projets externes dans un Mercurial parent
référentiel et faites en sorte que les commandes fonctionnent dessus en tant que groupe.

Mercurial prend actuellement en charge les sous-dépôts Mercurial, Git et Subversion.

Les sous-dépôts sont constitués de trois composants :

1. Extractions de référentiels imbriqués. Ils peuvent apparaître n'importe où dans le répertoire de travail parent.

2. Références de référentiel imbriquées. Ils sont définis dans .hgsub, qui doit être placé dans le
racine du répertoire de travail et indiquez d'où proviennent les extractions du sous-dépôt.
Les sous-dépôts Mercurial sont référencés comme :

chemin/vers/nested = https://example.com/nested/repo/path

Les sous-dépôts Git et Subversion sont également pris en charge :

chemin/vers/nested = [git]git://example.com/nested/repo/path
chemin/vers/nested = [svn]https://example.com/nested/trunk/path

De chemin/vers/imbriqué est l'emplacement de paiement par rapport à la racine Mercurial parente,
ainsi que https://example.com/nested/repo/path est le chemin du référentiel source. La source peut
font également référence à un chemin de système de fichiers.

Notez que .hgsub n'existe pas par défaut dans les dépôts Mercurial, vous devez
créez-le et ajoutez-le au référentiel parent avant d'utiliser les sous-dépôts.

3. États de référentiel imbriqués. Ils sont définis dans .hgsubétat, qui est placé à la racine
du répertoire de travail et capturez toutes les informations nécessaires pour restaurer le
sous-dépôts à l'état dans lequel ils ont été validés dans un ensemble de modifications du référentiel parent.
Mercurial enregistre automatiquement les états des référentiels imbriqués lors de la validation dans le
référentiel parent.

Notes
La .hgsubétat le fichier ne doit pas être modifié manuellement.

L'ajout de a Sous-référentiel
If .hgsub n'existe pas, créez-le et ajoutez-le au référentiel parent. Cloner ou payer
les projets externes où vous voulez qu'il vive dans le référentiel parent. Éditer .hgsub ainsi que
ajoutez l'entrée de sous-référentiel comme décrit ci-dessus. À ce stade, le sous-dépôt est
suivi et le prochain commit enregistrera son état dans .hgsubétat et le lier au
ensemble de modifications validées.

Synchronisation a Sous-référentiel
Les sous-dépôts ne suivent pas automatiquement le dernier ensemble de modifications de leurs sources. Au lieu de cela, ils
sont mis à jour avec l'ensemble de modifications correspondant à l'ensemble de modifications extrait dans le
ensemble de modifications de niveau supérieur. C'est ainsi que les développeurs obtiennent toujours un ensemble cohérent de code compatible
et les bibliothèques lors de leur mise à jour.

Ainsi, la mise à jour des sous-dépôts est un processus manuel. Consultez simplement le sous-dépôt cible sur le
révision souhaitée, testez dans le référentiel de niveau supérieur, puis validez dans le référentiel parent pour
enregistrer la nouvelle combinaison.

Suppression a Sous-référentiel
Pour supprimer un sous-référentiel du référentiel parent, supprimez sa référence de .hgsub,
puis supprimez ses fichiers.

Interaction avec Mercuriel Commandes
ajouter add n'est pas récursif dans les sous-dépôts sauf si -S/--subrepos est spécifié. Toutefois, si
vous spécifiez le chemin complet d'un fichier dans un sous-dépôt, il sera ajouté même sans
-S/--subrepos spécifié. Les sous-dépôts Subversion sont actuellement silencieux
ignoré.

Ajouter enlever
addremove ne revient pas dans les sous-dépôts sauf si -S/--subrepos est spécifié.
Cependant, si vous spécifiez le chemin complet d'un répertoire dans un sous-dépôt, addremove
être exécuté dessus même sans que -S/--subrepos soit spécifié. Git et Subversion
les sous-dépôts afficheront un avertissement et continueront.

archives
archive ne récurse pas dans les sous-dépôts sauf si -S/--subrepos est spécifié.

cat cat ne gère actuellement que les correspondances exactes de fichiers dans les sous-dépôts. Subversion
les sous-dépôts sont actuellement ignorés.

commettre commit crée un instantané cohérent de l'état de l'ensemble du projet et de ses
sous-dépôts. Si des sous-dépôts ont été modifiés, Mercurial abandonnera.
Mercurial peut être amené à valider à la place tous les sous-dépôts modifiés en spécifiant
-S/--subrepos, ou en définissant "ui.commitsubrepos=True" dans un fichier de configuration (voir hg
aider config). Une fois qu'il n'y a plus de sous-dépôts modifiés, il enregistre
leur état et le valide enfin dans le référentiel parent. Le --addremove
respecte également l'option -S/--subrepos. Cependant, Git et Subversion
les sous-dépôts afficheront un avertissement et abandonneront.

diff diff ne se répète pas dans les sous-dépôts sauf si -S/--subrepos est spécifié. Les changements sont
affiché comme d'habitude, sur les éléments des sous-dépôts. Les sous-dépôts Subversion sont
actuellement silencieusement ignoré.

fichiers files ne se récursent pas dans les sous-dépôts sauf si -S/--subrepos est spécifié. Cependant,
si vous spécifiez le chemin complet d'un fichier ou d'un répertoire dans un sous-dépôt, il sera
affiché même sans -S/--subrepos spécifié. Git et Subversion
les sous-dépôts sont actuellement ignorés en silence.

oublier forget ne gère actuellement que les correspondances exactes de fichiers dans les sous-dépôts. Git et Subversion
les sous-dépôts sont actuellement ignorés en silence.

nouveau
entrant ne se répète pas dans les sous-dépôts sauf si -S/--subrepos est spécifié. Gite et
Les sous-dépôts Subversion sont actuellement ignorés en silence.

sortant
outgoing ne se répète pas dans les sous-dépôts sauf si -S/--subrepos est spécifié. Gite et
Les sous-dépôts Subversion sont actuellement ignorés en silence.

tirer pull n'est pas récursif car il n'est pas clair quoi tirer avant de s'exécuter hg Mise à jour
. Lister et récupérer tous les changements de sous-dépôts référencés par le parent
Les ensembles de modifications extraits du référentiel sont au mieux chers, impossibles dans Subversion
Cas.

pousser Mercurial poussera automatiquement tous les sous-dépôts en premier lorsque le parent
le référentiel est poussé. Cela garantit que les nouvelles modifications de sous-dépôt sont disponibles
lorsqu'il est référencé par des référentiels de niveau supérieur. Push est un no-op pour Subversion
sous-dépôts.

statuts status ne revient pas dans les sous-dépôts sauf si -S/--subrepos est spécifié.
Les changements de sous-dépôt sont affichés comme des changements Mercurial réguliers sur le
éléments du sous-répertoire. Les sous-dépôts Subversion sont actuellement ignorés en silence.

supprimez remove ne revient pas dans les sous-dépôts sauf si -S/--subrepos est spécifié.
Cependant, si vous spécifiez un chemin de fichier ou de répertoire dans un sous-dépôt, il sera supprimé
même sans -S/--subrepos. Les sous-dépôts Git et Subversion sont actuellement
ignoré en silence.

Mise à jour update restaure les sous-dépôts dans l'état dans lequel ils ont été initialement validés dans la cible
ensemble de modifications. Si l'ensemble de modifications enregistré n'est pas disponible dans le sous-dépôt actuel,
Mercurial l'intégrera d'abord avant la mise à jour. Cela signifie que la mise à jour peut
nécessitent un accès réseau lors de l'utilisation de sous-dépôts.

Remappage Sous-dépôts Sources
Un emplacement source de sous-référentiel peut changer au cours de la vie d'un projet, invalidant les références
stocké dans l'historique du référentiel parent. Pour résoudre ce problème, des règles de réécriture peuvent être définies dans
référentiel parent hgrc fichier ou dans la configuration Mercurial. Voir le [sous-chemins] section
hgrc(5) pour plus de détails.

MODÈLE UTILISATION

Mercurial vous permet de personnaliser la sortie des commandes via des modèles. Tu peux soit
transmettre un modèle ou sélectionner un style de modèle existant à partir de la ligne de commande, via le
--option de modèle.

Vous pouvez personnaliser la sortie pour n'importe quelle commande "de type journal": log, sortant, entrant, tip,
parents et chefs.

Certains styles intégrés sont fournis avec Mercurial. Ceux-ci peuvent être listés avec hg enregistrer
--modèle liste. Exemple d'utilisation :

$hg log -r1.0::1.1 --template changelog

Un modèle est un morceau de texte, avec un balisage pour invoquer l'expansion des variables :

$ hg log -r1 --template "{nœud}\n"
b56ce7b07c52de7d5fd79fb89701ea538af65746

Les chaînes entre accolades sont appelées mots-clés. La disponibilité des mots-clés dépend de la
contexte exact du templater. Ces mots-clés sont généralement disponibles pour modéliser un
commande de type log :

marque-page actif
Chaîne de caractères. Le signet actif, s'il est associé au changeset

auteur Chaîne de caractères. L'auteur non modifié du changeset.

couper en deux Chaîne de caractères. Le statut de la bissection du jeu de modifications.

signets
Liste des chaînes. Tous les signets associés à l'ensemble de modifications. Définit également 'actif',
le nom du signet actif.

une succursale Chaîne de caractères. Le nom de la branche sur laquelle l'ensemble de modifications a été validé.

changements depuis le dernier tag
Entier. Tous les ancêtres ne figurant pas dans la dernière étiquette.

les enfants
Liste des chaînes. Les enfants du changeset.

données Informations sur les dates. La date à laquelle l'ensemble de modifications a été validé.

desc Chaîne de caractères. Le texte de la description de l'ensemble de modifications.

diffstat
Chaîne de caractères. Statistiques des modifications au format suivant : "fichiers modifiés :
+lignes ajoutées/supprimées"

extras Liste des dicts avec clé, entrées de valeur du champ 'extras' de ce changeset.

fichier_ajoute
Liste des chaînes. Fichiers ajoutés par cet ensemble de modifications.

fichiers_copies
Liste des chaînes. Fichiers copiés dans ce changeset avec leurs sources.

fichier_copies_switch
Liste des chaînes. Comme "file_copies" mais affiché uniquement si le commutateur --copied est
défini.

fichier_dels
Liste des chaînes. Fichiers supprimés par cet ensemble de modifications.

fichier_mods
Liste des chaînes. Fichiers modifiés par ce changeset.

fichiers Liste des chaînes. Tous les fichiers modifiés, ajoutés ou supprimés par cet ensemble de modifications.

nœud de graphe
Chaîne de caractères. Le caractère représentant le nœud changeset dans un graphe de révision ASCII

dernier tag
Liste des chaînes. Les balises globales sur l'ancêtre balisé globalement le plus récent de
cet ensemble de modifications.

dernièretagdistance
Entier. Chemin le plus long vers la dernière balise.

espaces de noms
Dict des listes. Noms attachés à cet ensemble de modifications par espace de noms.

nœud Chaîne de caractères. Hachage d'identification de l'ensemble de modifications, sous la forme d'une chaîne de 40 chiffres hexadécimaux.

nœud p1 Chaîne de caractères. Le hachage d'identification du premier parent de l'ensemble de modifications, sous forme de 40 chiffres
chaîne hexadécimale. Si le changeset n'a pas de parents, tous les chiffres sont 0.

p1rév Entier. Le numéro de révision local du référentiel du premier parent de l'ensemble de modifications, ou
-1 si le changeset n'a pas de parents.

nœud p2 Chaîne de caractères. Le hachage d'identification du second parent de l'ensemble de modifications, sous forme de 40 chiffres
chaîne hexadécimale. Si le changeset n'a pas de deuxième parent, tous les chiffres sont 0.

p2rév Entier. Le numéro de révision local du dépôt du second parent du changeset, ou
-1 si le changeset n'a pas de second parent.

parents
Liste des chaînes. Les parents du changeset au format "rev:node". Si la
changeset n'a qu'un seul parent "naturel" (la révision du prédécesseur) rien n'est
montré.

phase Chaîne de caractères. Le nom de la phase de l'ensemble de modifications.

phaseidx
Entier. L'indice de phase de l'ensemble de modifications.

tour Entier. Le numéro de révision de l'ensemble de modifications local du référentiel.

sous-repos
Liste des chaînes. Mise à jour des sous-dépôts dans le changeset.

étiquettes Liste des chaînes. Toutes les balises associées à l'ensemble de modifications.

Le mot-clé "date" ne produit pas de sortie lisible par l'homme. Si vous souhaitez utiliser une date dans
votre sortie, vous pouvez utiliser un filtre pour la traiter. Les filtres sont des fonctions qui renvoient un
chaîne basée sur la variable d'entrée. Assurez-vous d'utiliser le filtre stringify en premier lorsque vous êtes
appliquer un filtre d'entrée de chaîne à une variable d'entrée de type liste. Vous pouvez également utiliser une chaîne de
filtres pour obtenir la sortie souhaitée :

$ hg tip --template "{date|isodate}\n"
2008-08-21 18:22 +0000

Liste des filtres :

ajouter des pauses
N'importe quel texte. Ajouter un XHTML " " avant la fin de chaque ligne sauf la dernière.

âge Date. Renvoie une différence de date/heure lisible par l'homme entre la date/heure donnée et
la date/heure actuelle.

nom de base
N'importe quel texte. Traite le texte comme un chemin et renvoie le dernier composant du chemin
après séparation par le séparateur de chemin (en ignorant les séparateurs de fin). Par exemple,
"foo/bar/baz" devient "baz" et "foo/bar//" devient "bar".

compter Liste ou texte. Renvoie la longueur sous forme d'entier.

domaine N'importe quel texte. Trouve la première chaîne qui ressemble à une adresse e-mail et extrait
juste le composant de domaine. Exemple: Utilisateur <[email protected]> devient example.com.

email N'importe quel texte. Extrait la première chaîne qui ressemble à une adresse e-mail. Exemple: Utilisateur
<[email protected]> devient [email protected].

utilisateur de messagerie
N'importe quel texte. Renvoie la partie utilisateur d'une adresse e-mail.

échapper N'importe quel texte. Remplace les caractères spéciaux XML/XHTML "&", "<" et ">" par XML
entités et filtre les caractères NUL.

fill68 N'importe quel texte. Enveloppe le texte pour tenir dans 68 colonnes.

fill76 N'importe quel texte. Enveloppe le texte pour tenir dans 76 colonnes.

Première ligne
N'importe quel texte. Renvoie la première ligne de texte.

hex N'importe quel texte. Convertir un identifiant de nœud binaire Mercurial en son long hexadécimal
représentation.

date du jour Date. Renvoie la date sous la forme d'une paire de nombres : "1157407993 25200" (horodatage Unix,
décalage horaire).

isodate
Date. Renvoie la date au format ISO 8601 : "2009-08-18 13:00 +0200".

isodatésec
Date. Renvoie la date au format ISO 8601, y compris les secondes : "2009-08-18 13:00:13
+0200". Voir aussi le filtre rfc3339date.

baisser N'importe quel texte. Convertit le texte en minuscules.

non vide
N'importe quel texte. Renvoie '(aucun)' si la chaîne est vide.

obscurcir
N'importe quel texte. Renvoie le texte d'entrée rendu sous la forme d'une séquence d'entités XML.

personne N'importe quel texte. Renvoie le nom avant une adresse e-mail, en l'interprétant conformément à la RFC
5322.

réévasion
N'importe quel texte. Échappe tous les caractères "spéciaux", sauf @. Les barres obliques sont échappées
deux fois pour empêcher les serveurs Web de leur échapper prématurément. Par exemple, "@foo
bar/baz" devient "@foo%20bar%252Fbaz".

RFC3339date
Date. Renvoie une date en utilisant le format de date Internet spécifié dans la RFC 3339 :
"2009-08-18T13:00:13+02:00".

RFC822date
Date. Renvoie une date en utilisant le même format que celui utilisé dans les en-têtes des e-mails : "mardi 18 août 2009
13:00:13 +0200".

court Hachage de l'ensemble de modifications. Renvoie la forme courte d'un hachage de changeset, c'est-à-dire un 12 hexadécimal
chaîne de chiffres.

couper en deux
N'importe quel texte. Gâteries texte comme statut de bissection et renvoie un caractère unique
représentant l'état (G : bon, B : mauvais, S : ignoré, U : non testé, I : ignoré).
Renvoie un seul espace si texte n'est pas un statut de bissection valide.

date courte
Date. Renvoie une date telle que "2006-09-18".

lignes de division
N'importe quel texte. Fractionner le texte en une liste de lignes.

stringifier
N'importe quel type. Transforme la valeur en texte en convertissant les valeurs en texte et
en les concaténant.

répertoire de strip
Traitez le texte comme un chemin et supprimez un niveau de répertoire, si possible. Par exemple, "foo"
et "foo/bar" devient "foo".

tabindent
N'importe quel texte. Renvoie le texte, avec chaque ligne non vide sauf la première commençant
avec un caractère de tabulation.

supérieur N'importe quel texte. Convertit le texte en majuscule.

paysage urbain
N'importe quel texte. Échappe tous les caractères "spéciaux". Par exemple, "foo bar" devient
"foo%20bar".

utilisateur N'importe quel texte. Renvoie une courte représentation d'un nom d'utilisateur ou d'une adresse e-mail.

Notez qu'un filtre n'est rien de plus qu'un appel de fonction, c'est-à-dire expression|filtre est équivalent
à filtre (expression).

En plus des filtres, il existe quelques fonctions intégrées de base :

date(date[, fmt])
Formater une date. Voir hg aider dates pour le formatage des chaînes. La valeur par défaut est une date Unix
format, y compris le fuseau horaire : "Mon Sep 04 15:13:13 2006 0700".

diff([incluremotif [, excluremotif]])
Afficher un diff, en spécifiant éventuellement les fichiers à inclure ou à exclure.

remplir(texte[, largeur[, identifiant initial[, retrait suspendu]]])
Remplissez de nombreux paragraphes avec une indentation facultative. Voir le filtre "remplir".

obtenir (dire, clé)
Obtenir un attribut/clé d'un objet. Certains mots-clés sont des types complexes. Cette fonction
permet d'obtenir la valeur d'un attribut sur ces types.

si(expr, ensuite[, autre])
Exécuter conditionnellement en fonction du résultat d'une expression.

si contient(recherche, chose, ensuite[, autre])
Exécuter conditionnellement selon que l'élément "recherche" est dans "chose".

ifeq(expr1, expression2, ensuite[, autre])
Exécuter conditionnellement selon que 2 éléments sont équivalents.

retrait(texte, caractères d'indentation[, Première ligne])
Indente toutes les lignes non vides avec les caractères donnés dans la chaîne indentchars. Une
le troisième paramètre facultatif remplacera le retrait de la première ligne uniquement si
présent.

joindre(liste, SEP)
Joindre des éléments dans une liste avec un délimiteur.

étiquette(étiquette, expression)
Appliquez une étiquette au contenu généré. Le contenu avec une étiquette appliquée peut entraîner
post-traitement supplémentaire, comme la colorisation automatique.

derniertag([motif])
Les balises globales correspondant au modèle donné sur la balise globale la plus récente
ancêtre de ce changeset.

datelocale(date[, tz])
Convertit une date dans le fuseau horaire spécifié. La valeur par défaut est la date locale.

pad(texte, largeur[, fillchar=' '[, droite=Faux]])
Remplir le texte avec un caractère de remplissage.

revset(requête[, formats de fichiers...])
Exécutez une requête de jeu de révisions. Voir hg aider revset.

rstdoc(texte, style)
Formater le texte restructuré.

le plus court(noeud, minlongueur=4)
Obtenir la représentation la plus courte d'un nœud.

commence par (motif, texte)
Renvoie la valeur de l'argument "texte" s'il commence par le contenu du
argument "motif".

bande(texte[, caractères])
Supprime les caractères d'une chaîne. Par défaut, supprime tous les éléments de début et de fin
espace.

sous (motif, remplacement, expression)
Effectuez une substitution de texte à l'aide d'expressions régulières.

mot (nombre, texte[, séparateur])
Renvoie le nième mot d'une chaîne.

De plus, pour toute expression qui renvoie une liste, il existe un opérateur de liste :

expr % "{modèle}"

Comme on le voit dans l'exemple ci-dessus, {modèle} est interprété comme un modèle. Pour l'empêcher de
être interprété, vous pouvez utiliser un caractère d'échappement \{ ou un préfixe de chaîne brute, r'...'.

Quelques exemples de modèles de ligne de commande :

· Formater des listes, par exemple des fichiers :

$ hg log -r 0 --template "fichiers :\n{fichiers % ' {fichier}\n'}"

· Joindre la liste des fichiers avec un ", " :

$ hg log -r 0 --template "fichiers : {joindre(fichiers, ', ')}\n"

· Modifiez chaque ligne d'une description de commit :

$ hg log --template "{splitlines(desc) % '**** {ligne}\n'}"

· Date format :

$ hg log -r 0 --template "{date(date, '%Y')}\n"

· Afficher la date en UTC :

$ hg log -r 0 --template "{datelocale(date, 'UTC')|date}\n"

· Générez la description définie sur une largeur de remplissage de 30 :

$ hg log -r 0 --template "{fill(desc, 30)}"

· Utilisez une condition pour tester la branche par défaut :

$ hg log -r 0 --template "{ifeq(branche, 'par défaut', 'sur la branche principale',
'sur la branche {branche}')}\n"

· Ajouter une nouvelle ligne si elle n'est pas vide :

$ hg tip --template "{if(auteur, '{auteur}\n')}"

· Étiquetez la sortie à utiliser avec l'extension de couleur :

$ hg log -r 0 --template "{label('changeset.{phase}', node|short)}\n"

· Inversez le filtre de première ligne, c'est-à-dire tout sauf la première ligne :

$ hg log -r 0 --template "{sub(r'^.*\n?\n?', '', desc)}\n"

· Affichez le contenu du champ 'extra', un par ligne :

$ hg log -r 0 --template "{join(extras, '\n')}\n"

· Marquez le signet actif avec '*' :

$ hg log --template "{signets % '{signet}{ifeq(signet, actif, '*')} '}\n"

· Trouvez la balise précédente de release candidate, la distance et les changements depuis la balise :

$ hg log -r . --template "{latesttag('re:^.*-rc$') % '{tag}, {changes}, {distance}'}\n"

· Marquez le parent de la copie de travail avec '@' :

$ hg log --template "{ifcontains(rev, revset('.'), '@')}\n"

· Afficher les détails des révisions parent :

$ hg log --template "{revset('parents(%d)', rev) % '{desc|première ligne}\n'}"

· Afficher uniquement les descriptions de commit commençant par "template" :

$ hg log --template "{startswith('template', firstline(desc))}\n"

· Imprimez le premier mot de chaque ligne d'un message de validation :

$ hg log --template "{mot(0, desc)}\n"

URL Les chemins

Les URL valides sont de la forme :

local/système de fichiers/chemin[#révision]
fichier://local/filesystem/path[#revision]
http://[user[:pass]@]host[:port]/[path][#revision]
https://[user[:pass]@]host[:port]/[path][#revision]
ssh://[utilisateur@]hôte[:port]/[chemin][#révision]

Les chemins dans le système de fichiers local peuvent soit pointer vers des référentiels Mercurial, soit vers un bundle
fichiers (tels que créés par hg pack or hg nouveau --empaqueter). Voir également hg aider chemins.

Un identifiant facultatif après # indique une branche, une balise ou un ensemble de modifications particulier à utiliser
depuis le référentiel distant. Voir également hg aider révisions.

Certaines fonctionnalités, telles que pousser vers les URL http:// et https:// ne sont possibles que si le
La fonctionnalité est explicitement activée sur le serveur Mercurial distant.

Notez que la sécurité des URL HTTPS dépend de la bonne configuration de web.cacerts.

Quelques notes sur l'utilisation de SSH avec Mercurial :

· SSH nécessite un compte shell accessible sur la machine de destination et une copie de hg dans
le chemin distant ou spécifié avec comme remotecmd.

· Le chemin est relatif au répertoire personnel de l'utilisateur distant par défaut. Utilisez une barre oblique supplémentaire à
le début d'un chemin pour spécifier un chemin absolu :

ssh://example.com//tmp/repository

· Mercurial n'utilise pas sa propre compression via SSH ; la bonne chose à faire est de configurer
dans votre ~ / .ssh / config, par exemple:

Hôte *.mylocalnetwork.example.com
compression non
Hôte *
compression oui

Vous pouvez également spécifier "ssh -C" comme commande ssh dans votre fichier de configuration ou avec
l'option de ligne de commande --ssh.

Ces URL peuvent toutes être stockées dans votre fichier de configuration avec des alias de chemin sous le
section [chemins] comme ceci :

[chemins]
alias1 = URL1
alias2 = URL2


Vous pouvez ensuite utiliser l'alias pour toute commande utilisant une URL (par exemple hg tirer alias1
sera traité comme hg tirer URL1).

Deux alias de chemin sont spéciaux car ils sont utilisés par défaut lorsque vous ne fournissez pas le
URL vers une commande :

par défaut:
Lorsque vous créez un référentiel avec hg clone, la commande clone enregistre l'emplacement de
le référentiel source comme chemin "par défaut" du nouveau référentiel. Celle-ci est ensuite utilisée
lorsque vous omettez le chemin des commandes de type push et pull (y compris les commandes entrantes et
sortant).

push par défaut :
La commande push recherchera un chemin nommé 'default-push' et le préférera à
'default' si les deux sont définis.

EXTENSIONS

Cette section contient de l'aide pour les extensions qui sont distribuées avec Mercurial.
L'aide pour les autres extensions est disponible dans le système d'aide.

acl
crochets pour contrôler l'accès au référentiel

Ce crochet permet d'autoriser ou de refuser l'accès en écriture à des branches et des chemins donnés d'un
référentiel lors de la réception des ensembles de modifications entrants via pretxnchangegroup et pretxncommit.

L'autorisation est mise en correspondance en fonction du nom d'utilisateur local sur le système où le hook
s'exécute, et non le committer du changeset d'origine (puisque ce dernier est simplement
informatif).

Le crochet acl est mieux utilisé avec une coque restreinte comme hgsh, empêchant
authentifiant les utilisateurs de faire autre chose que pousser ou tirer. Le crochet n'est pas
sûr à utiliser si les utilisateurs ont un accès shell interactif, car ils peuvent alors désactiver le hook. Ni
est-ce sûr si des utilisateurs distants partagent un compte, car il n'y a alors aucun moyen de distinguer
Eux.

L'ordre dans lequel les contrôles d'accès sont effectués est :

1. Liste de refus pour les succursales (section acl.deny.branches)

2. Autoriser la liste des succursales (section acl.allow.branches)

3. Liste de refus pour les chemins (section acl.deny)

4. Autoriser la liste des chemins (section acl.autoriser)

Les sections allow et deny acceptent des paires clé-valeur.

En succursale Accès Control
Utilisez l'option acl.deny.branches ainsi que acl.allow.branches sections pour avoir un accès basé sur la branche
contrôler. Les clés de ces sections peuvent être :

· un nom de succursale, ou

· un astérisque, pour correspondre à n'importe quelle branche ;

Les valeurs correspondantes peuvent être soit :

· une liste séparée par des virgules contenant des utilisateurs et des groupes, ou

· un astérisque, pour correspondre à n'importe qui ;

Vous pouvez ajouter le "!" préfixe à un nom d'utilisateur ou de groupe pour inverser le sens de la correspondance.

Basé sur le chemin Accès Control
Utilisez l'option acl.deny ainsi que acl.autoriser sections pour avoir un contrôle d'accès basé sur le chemin. Clés dans ces
les sections acceptent un modèle de sous-arbre (avec une syntaxe glob par défaut). Le correspondant
les valeurs suivent la même syntaxe que les autres sections ci-dessus.

Groupes
Les noms de groupe doivent être précédés d'un @ symbole. Spécifier un nom de groupe a le même effet
comme spécifiant tous les utilisateurs de ce groupe.

Vous pouvez définir les membres du groupe dans le acl.groupes section. Si un nom de groupe n'est pas défini
là, et que Mercurial fonctionne sous un système de type Unix, la liste des utilisateurs sera prise
du système d'exploitation. Dans le cas contraire, une exception sera levée.

Exemple configuration
[crochets]

# Utilisez ceci si vous souhaitez vérifier les restrictions d'accès au moment de la validation
pretxncommit.acl = python:hgext.acl.hook

# Utilisez ceci si vous voulez vérifier les restrictions d'accès pour tirer, pousser,
# regrouper et servir.
pretxnchangegroup.acl = python:hgext.acl.hook

[acl]
# Autoriser ou refuser l'accès aux modifications entrantes uniquement si leur source est
# répertoriés ici, laissez-les passer autrement. La source est "servir" pour tous
# accès distant (http ou ssh), "push", "pull" ou "bundle" lorsque le
# commandes associées sont exécutées localement.
# Par défaut : servir
sources = servir

[acl.deny.branches]

# Tout le monde est refusé à la branche gelée :
branche gelée = *

# Un mauvais utilisateur est refusé sur toutes les branches :
* = mauvais utilisateur

[acl.allow.branches]

# Quelques utilisateurs sont autorisés sur branch-a :
branche-a = utilisateur-1, utilisateur-2, utilisateur-3

# Un seul utilisateur est autorisé sur branch-b :
branche-b = utilisateur-1

# Le super utilisateur est autorisé sur n'importe quelle branche :
* = super-utilisateur

# Tout le monde est autorisé sur branch-for-tests :
branche-pour-tests = *

[acl.deny]
# Cette liste est vérifiée en premier. Si une correspondance est trouvée, acl.allow n'est pas
# vérifié. Tous les utilisateurs ont accès si acl.deny n'est pas présent.
# Format pour les deux listes : glob pattern = user, ..., @group, ...

# Pour faire correspondre tout le monde, utilisez un astérisque pour l'utilisateur :
# mon/glob/motif = *

# user6 n'aura accès en écriture à aucun fichier :
** = utilisateur6

# Le groupe "hg-denied" n'aura accès en écriture à aucun fichier :
** = @hg-refusé

# Personne ne pourra modifier "DONT-TOUCH-THIS.txt", malgré
# tout le monde pouvant modifier tous les autres fichiers. Voir ci-dessous.
src/main/resources/DONT-TOUCH-THIS.txt = *

[acl.autoriser]
# si acl.allow n'est pas présent, tous les utilisateurs sont autorisés par défaut
# vide acl.allow = aucun utilisateur autorisé

# L'utilisateur "doc_writer" a un accès en écriture à n'importe quel fichier sous "docs"
# dossier:
docs/** = doc_writer

# L'utilisateur "jack" et le groupe "designers" ont un accès en écriture à n'importe quel fichier
# sous le dossier "images":
images/** = prise, @designers

# Tout le monde (sauf pour "user6" et "@hg-denied" - voir acl.deny ci-dessus)
# aura un accès en écriture à n'importe quel fichier sous le dossier "ressources"
# (sauf pour 1 fichier. Voir acl.deny) :
src/main/ressources/** = *

.hgtags = release_engineer

Exemples en utilisant le ! préfixe
Supposons qu'il existe une branche vers laquelle seul un utilisateur (ou un groupe) donné devrait pouvoir pousser, et
vous ne voulez pas restreindre l'accès à toute autre branche qui pourrait être créée.

Le "!" Le préfixe vous permet d'empêcher quiconque, à l'exception d'un utilisateur ou d'un groupe donné, de pousser
ensembles de modifications dans une branche ou un chemin donné.

Dans les exemples ci-dessous, nous allons : 1) Refuser l'accès à la branche "ring" à quiconque sauf à l'utilisateur
"gollum" 2) Refuser l'accès à la branche "lac" à quiconque sauf aux membres du groupe "hobbit" 3)
Refuser l'accès à un fichier à quiconque sauf à l'utilisateur "gollum"

[acl.allow.branches]
# Vide

[acl.deny.branches]

# 1) seul 'gollum' peut s'engager sur la branche 'ring' ;
# 'gollum' et n'importe qui d'autre peuvent toujours s'engager dans n'importe quelle autre branche.
anneau = !gollum

# 2) seuls les membres du groupe 'hobbit' peuvent s'engager sur la branche 'lac';
# Les membres 'hobbit' et n'importe qui d'autre peuvent toujours s'engager dans n'importe quelle autre branche.
lac = !@hobbit

# Vous pouvez également refuser l'accès en fonction des chemins de fichiers :

[acl.autoriser]
# Vide

[acl.deny]
# 3) seul 'gollum' peut modifier le fichier ci-dessous ;
# 'gollum' et n'importe qui d'autre peuvent toujours modifier n'importe quel autre fichier.
/brumeux/montagnes/grotte/anneau = !gollum

blackbox
consigner les événements du référentiel dans une boîte noire pour le débogage

Enregistre les informations sur les événements dans .hg/blackbox.log pour aider à déboguer et diagnostiquer les problèmes. le
les événements enregistrés peuvent être configurés via la clé de configuration blackbox.track. Exemples:

[boîte noire]
piste = *

[boîte noire]
track = commande, fin de commande, exception de commande, exthook, pythonhook

[boîte noire]
piste = entrant

[boîte noire]
# limiter la taille d'un fichier journal
taillemax = 1.5 Mo
# faire pivoter jusqu'à N fichiers journaux lorsque l'actuel devient trop volumineux
maxfichiers = 3

Commandes
blackbox
afficher les événements récents du référentiel :

hg boîte noire [OPTION]...

afficher les événements récents du référentiel

Options:

-l,--limite
le nombre d'événements à afficher (par défaut : 10)

bugzilla
hooks pour l'intégration avec le bug tracker de Bugzilla

Cette extension de crochet ajoute des commentaires sur les bogues dans Bugzilla lorsque les modifications font référence à des bogues
par Bugzilla ID sont visibles. Le commentaire est formaté à l'aide du mécanisme de modèle Mercurial.

Les références de bogues peuvent éventuellement inclure une mise à jour pour Bugzilla des heures passées
travailler sur le bogue. Les bogues peuvent également être marqués corrigés.

Trois modes d'accès de base à Bugzilla sont fournis :

1. Accès via l'interface Bugzilla XMLRPC. Nécessite Bugzilla 3.4 ou version ultérieure.

2. Vérifiez les données via l'interface Bugzilla XMLRPC et soumettez les changements de bogue par e-mail à
Interface de messagerie Bugzilla. Nécessite Bugzilla 3.4 ou version ultérieure.

3. Écrire directement dans la base de données Bugzilla. Seules les installations de Bugzilla utilisant MySQL sont
prise en charge. Nécessite Python MySQLdb.

L'écriture directe dans la base de données est sensible aux changements de schéma et repose sur un
Script de contribution Bugzilla pour envoyer des e-mails de notification de changement de bogue. Ce script s'exécute comme
l'utilisateur exécutant Mercurial, doit être exécuté sur l'hôte avec l'installation de Bugzilla, et
nécessite l'autorisation de lire les détails de configuration de Bugzilla et l'utilisateur MySQL nécessaire
et mot de passe pour avoir des droits d'accès complets à la base de données Bugzilla. Pour ces raisons ce
le mode d'accès est désormais considéré comme obsolète et ne sera pas mis à jour pour le nouveau Bugzilla
versions à venir. Seul l'ajout de commentaires est pris en charge dans ce mode d'accès.

L'accès via XMLRPC nécessite un nom d'utilisateur et un mot de passe Bugzilla à spécifier dans le
configuration. Les commentaires sont ajoutés sous ce nom d'utilisateur. Étant donné que la configuration doit être
lisible par tous les utilisateurs de Mercurial, il est recommandé que les droits de cet utilisateur soient
limité dans Bugzilla au minimum nécessaire pour ajouter des commentaires. Correction des bugs de marquage
nécessite Bugzilla 4.0 et versions ultérieures.

L'accès via XMLRPC/e-mail utilise XMLRPC pour interroger Bugzilla, mais envoie un e-mail à Bugzilla
interface de messagerie pour soumettre des commentaires sur les bogues. L'adresse De : dans l'e-mail est définie sur
l'adresse e-mail de l'utilisateur Mercurial, donc le commentaire semble provenir de l'utilisateur Mercurial
utilisateur. Dans le cas où l'e-mail de l'utilisateur Mercurial n'est pas reconnu par Bugzilla comme un
Utilisateur Bugzilla, l'e-mail associé au nom d'utilisateur Bugzilla utilisé pour se connecter à Bugzilla
est utilisé à la place comme source du commentaire. Le marquage des bogues corrigés fonctionne sur tous les supports
Versions Bugzilla.

Éléments de configuration communs à tous les modes d'accès :

bugzilla.version
Le type d'accès à utiliser. Les valeurs reconnues sont :

xmlrpc

Interface Bugzilla XMLRPC.

xmlrpc+courriel

Bugzilla XMLRPC et interfaces de messagerie.

3.0

Accès MySQL, Bugzilla 3.0 et versions ultérieures.

2.18

Accès MySQL, Bugzilla 2.18 et jusqu'à mais non compris 3.0.

2.16

Accès MySQL, Bugzilla 2.16 et jusqu'à mais non compris 2.18.

bugzilla.regexp
Expression régulière pour faire correspondre les ID de bogue pour la mise à jour dans le message de validation de l'ensemble de modifications. Ce
doit contenir un groupe nommé "()" contenant les ID de bogue séparés par
caractères non numériques. Il peut également contenir un groupe nommé avec une
nombre à virgule flottante donnant les heures travaillées sur le bogue. Si aucun groupe nommé n'est
présent, le premier groupe "()" est supposé contenir les ID de bogue, et le temps de travail est
pas à jour. L'expression par défaut correspond Punaise 1234, Punaise no. 1234, Punaise nombre
1234, Bugs 1234,5678, Punaise 1234 ainsi que 5678 et ses variantes, suivi d'un
nombre d'heures précédé de h or heures, par exemple heures 1.5. La correspondance est insensible à la casse.

bugzilla.fixregexp
Expression régulière pour faire correspondre les ID de bogue pour le marquage corrigé dans le message de validation de l'ensemble de modifications.
Celui-ci doit contenir un groupe nommé "()" ` comprenant le bug ID séparé by
non numérique caractères. It Au cours de cette réunion, Matthew a obtenu de précieux conseils et Linda lui a demandé de la tenir au courant de ses progrès. aussi contiennent a nommé groupe `` avec une
nombre à virgule flottante donnant les heures travaillées sur le bogue. Si aucun groupe nommé n'est
présent, le premier groupe "()" est supposé contenir les ID de bogue, et le temps de travail est
pas à jour. L'expression par défaut correspond Correctifs 1234, Correctifs bug 1234, Correctifs bogues
1234,5678, Correctifs 1234 ainsi que 5678 et ses variantes, suivi d'un nombre d'heures
préfixé par h or heures, par exemple heures 1.5. La correspondance est insensible à la casse.

statut bugzilla.fix
Le statut auquel définir un bogue lors du marquage corrigé. Défaut RÉSOLU.

bugzilla.fixresolution
La résolution pour définir un bogue lors du marquage est corrigée. Défaut FIXE.

bugzilla.style
Le fichier de style à utiliser lors du formatage des commentaires.

bugzilla.template
Modèle à utiliser lors de la mise en forme des commentaires. Remplace le style si spécifié. en outre
aux mots-clés usuels de Mercurial, l'extension précise :

{bogue}

L'ID de bogue Bugzilla.

{racine}

Le chemin d'accès complet du dépôt Mercurial.

{racine Web}

Nom de chemin dépouillé du référentiel Mercurial.

{hgweb}

URL de base pour parcourir les référentiels Mercurial.

Réglage par défaut ensemble de modifications {nœud|court} in repo {racine} se réfère à bug
{bug}.\ndétails :\n\t{desc|tabindent}

bugzilla.strip
Le nombre de caractères séparateurs de chemin à supprimer de l'avant du Mercurial
chemin du référentiel ({racine} dans les modèles) pour produire {racine Web}. Par exemple, un
référentiel avec {racine} /var/local/mon-projet avec une bande de 2 donne une valeur pour
{racine Web} of mon projet. 0 par défaut.

web.baseurl
URL de base pour parcourir les référentiels Mercurial. Référencé à partir des modèles comme {hgweb}.

Éléments de configuration communs aux modes d'accès XMLRPC+email et MySQL :

bugzilla.usermap
Chemin du fichier contenant les correspondances entre l'e-mail du committer Mercurial et l'e-mail de l'utilisateur Bugzilla.
Si spécifié, le fichier doit contenir un mappage par ligne :

committer = utilisateur Bugzilla

Voir aussi [carte utilisateur] .

La [carte utilisateur] La section est utilisée pour spécifier les mappages de l'e-mail du committer Mercurial vers Bugzilla
e-mail de l'utilisateur. Voir également bugzilla.usermap. Contient des entrées du formulaire committer = Bugzilla
utilisateur.

Configuration du mode d'accès XMLRPC :

bugzilla.bzurl
L'URL de base pour l'installation de Bugzilla. Défaut http://localhost/bugzilla.

bugzilla.utilisateur
Le nom d'utilisateur à utiliser pour se connecter à Bugzilla via XMLRPC. Défaut bogues.

bugzilla.mot de passe
Le mot de passe pour la connexion à Bugzilla.

Le mode d'accès XMLRPC+email utilise les éléments de configuration du mode d'accès XMLRPC, ainsi que :

bugzilla.bzemail
L'adresse e-mail de Bugzilla.

De plus, les paramètres de messagerie Mercurial doivent être configurés. Voir la documentation dans
hgrc(5), articles [e-mail] ainsi que [smtp].

Configuration du mode d'accès MySQL :

bugzilla.hôte
Nom d'hôte du serveur MySQL contenant la base de données Bugzilla. Défaut localhost.

bugzilla.db
Nom de la base de données Bugzilla dans MySQL. Défaut bogues.

bugzilla.utilisateur
Nom d'utilisateur à utiliser pour accéder au serveur MySQL. Défaut bogues.

bugzilla.mot de passe
Mot de passe à utiliser pour accéder au serveur MySQL.

bugzilla.timeout
Délai de connexion à la base de données (secondes). Par défaut 5.

bugzilla.bzuser
Nom d'utilisateur Bugzilla de secours avec lequel enregistrer les commentaires, si le committer de l'ensemble de modifications ne peut pas
être trouvé en tant qu'utilisateur de Bugzilla.

bugzilla.bzdir
Répertoire d'installation de Bugzilla. Utilisé par défaut notifier. Défaut /var/www/html/bugzilla.

bugzilla.notifier
La commande à exécuter pour que Bugzilla envoie des e-mails de notification de changement de bogue.
Substituts d'une carte à 3 touches, bzdir, id (identifiant du bogue) et utilisateur (commettre bugzilla
e-mail). La valeur par défaut dépend de la version ; depuis 2.18 c'est "cd %(bzdir)s && perl -T
contrib/sendbugmail.pl %(id)s %(user)s".

Activation de l'extension :

[extensions]
bugzilla =

[crochets]
# lancer le hook bugzilla sur chaque changement tiré ou poussé ici
entrant.bugzilla = python:hgext.bugzilla.hook

Exemples de configurations :

Exemple de configuration XMLRPC. Ceci utilise le Bugzilla à http://my-project.org/bugzilla,
se connecter en tant qu'utilisateur [email protected] avec mot de passe rire. Il est utilisé avec un
collection de dépôts Mercurial dans /var/local/hg/repos/, avec une interface web à
http://my-project.org/hg.

[bugzilla]
bzurl=http://my-project.org/bugzilla
utilisateur =[email protected]
mot de passe=plugh
version=xmlrpc
template=Changeset {node|short} dans {root|basename}.
{hgweb}/{webroot}/rev/{node|short}\n
{desc}\n
bande=5

[la toile]
baseurl=http://my-project.org/hg

Exemple de configuration XMLRPC + e-mail. Ceci utilise le Bugzilla à
http://my-project.org/bugzilla, se connectant en tant qu'utilisateur [email protected] avec mot de passe
rire. Il est utilisé avec une collection de référentiels Mercurial dans /var/local/hg/repos/,
avec une interface web sur http://my-project.org/hg. Les commentaires de bogue sont envoyés au Bugzilla
adresse e-mail [email protected].

[bugzilla]
bzurl=http://my-project.org/bugzilla
utilisateur =[email protected]
mot de passe=plugh
version=xmlrpc+courriel
bzemail=[email protected]
template=Changeset {node|short} dans {root|basename}.
{hgweb}/{webroot}/rev/{node|short}\n
{desc}\n
bande=5

[la toile]
baseurl=http://my-project.org/hg

[carte utilisateur]
[email protected]=[email protected]

Exemple de configuration MySQL. Cela a une installation locale de Bugzilla 3.2 dans
/opt/bugzilla-3.2. La base de données MySQL est activée localhost, le nom de la base de données Bugzilla est bogues
et MySQL est accessible avec le nom d'utilisateur MySQL bogues Mot de passe XYZZY. Il est utilisé avec un
collection de dépôts Mercurial dans /var/local/hg/repos/, avec une interface web à
http://my-project.org/hg.

[bugzilla]
hôte = hôte local
mot de passe=XYZZY
version = 3.0
bzuser=[email protected]
bzdir=/opt/bugzilla-3.2
template=Changeset {node|short} dans {root|basename}.
{hgweb}/{webroot}/rev/{node|short}\n
{desc}\n
bande=5

[la toile]
baseurl=http://my-project.org/hg

[carte utilisateur]
[email protected]=[email protected]

Tout ce qui précède ajoute un commentaire à l'enregistrement de bogue Bugzilla du formulaire :

Ensemble de modifications 3b16791d6642 dans le nom du référentiel.
http://my-project.org/hg/repository-name/rev/3b16791d6642

Commentaire de validation de l'ensemble de modifications. Bogue 1234.

censeur
effacer le contenu du fichier à une révision donnée

La commande censor demande à Mercurial d'effacer tout le contenu d'un fichier à une révision donnée
sans la mise à jour le ensemble de modifications hacher. Cela permet à l'historique existant de rester valide pendant
empêcher les futurs clones/pulls de recevoir les données effacées.

Les utilisations typiques de la censure sont dues à des exigences de sécurité ou légales, notamment :

* Mots de passe, clés privées, matériel cryptographique
* Données/code/bibliothèques sous licence pour lesquels la licence a expiré
* Informations personnellement identifiables ou autres données privées

Les nœuds censurés peuvent interrompre le fonctionnement typique de Mercurial chaque fois que les données excisées en ont besoin
être matérialisé. Certaines commandes, comme hg cat/hg revenir, échoue simplement lorsqu'on lui demande
produire des données censurées. D'autres, comme hg vérifier ainsi que hg Mise à jour, doit être capable de tolérer
données censurées pour continuer à fonctionner de manière significative. De telles commandes ne tolèrent
révisions de fichiers censurés si elles sont autorisées par l'option de configuration "censor.policy=ignore".

Commandes
censeur
hg censeur -r REV [-t TEXTE] [FICHIER]

Options:

-r,--tour
fichier de censure de la révision spécifiée

-t,--pierre tombale
données de désactivation de remplacement

chgserver
extension du serveur de commande pour cHg (EXPERIMENTAL)

'S' chaine (lire écrire)
propager la requête ui.system() au client

'attaché' commander
attachez le stdio du client passé par sendmsg()

'chdir' commander
changer le répertoire courant

'get pager' commander
vérifie si le pager est activé et quel pager doit être exécuté

'setenv' commander
remplacer complètement os.environ

'SIGHUP' signal
recharger les fichiers de configuration

les enfants
commande pour afficher les ensembles de modifications enfants (OBSOLÈTE)

Cette extension est obsolète. Tu devrais utiliser hg enregistrer -r "enfants(REV)" à la place.

Commandes
les enfants
affiche les enfants de la révision donnée ou du répertoire de travail :

hg enfants [-r REV] [FILE]

Affiche les enfants des révisions du répertoire de travail. Si une révision est donnée via
-r/--rev, les enfants de cette révision seront imprimés. Si un argument de fichier est donné,
révision dans laquelle le fichier a été modifié pour la dernière fois (après la révision du répertoire de travail ou la
argument de --rev s'il est fourni) est imprimé.

S'il vous plaît utiliser hg enregistrer au lieu:

hg enfants => hg log -r 'enfants()'
hg enfants -r REV => hg log -r 'enfants(REV)'

See hg aider enregistrer ainsi que hg aider revsets.enfants.

Options:

-r,--tour
afficher les enfants de la révision spécifiée

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

baratte
commande pour afficher des statistiques sur l'historique du dépôt

Commandes
baratte
histogramme des modifications apportées au référentiel :

hg churn [-d DATE] [-r REV] [--aliases FICHIER] [FICHIER]

Cette commande affichera un histogramme représentant le nombre de lignes modifiées ou
révisions, regroupées selon le modèle donné. Le modèle par défaut regroupera
modifications par auteur. L'option --dateformat peut être utilisée pour regrouper les résultats par date
à la place.

Les statistiques sont basées sur le nombre de lignes modifiées, ou alternativement sur le nombre de
révisions correspondantes si l'option --changesets est spécifiée.

Exemples :

# affiche le nombre de lignes modifiées pour chaque committer
hg churn -t "{auteur|email}"

# afficher le graphique d'activité quotidienne
hg désabonnement -f "%H" -s -c

# affichage de l'activité des développeurs par mois
hg churn -f "%Y-%m" -s -c

# afficher le nombre de lignes modifiées chaque année
hg désabonnement -f "%Y" -s

Il est possible de mapper des adresses e-mail alternatives à une adresse principale en fournissant un fichier
en utilisant le format suivant:

=

Un tel fichier peut être spécifié avec l'option --aliases, sinon un fichier .hgchurn sera
recherché dans la racine du répertoire de travail. Les alias seront séparés du "=" le plus à droite.

Options:

-r,--tour
taux de comptage pour la révision ou le revset spécifié

-ré,--Date
taux de comptage pour les révisions correspondant à la spécification de date

-t,--ancienmodèle
modèle pour regrouper les ensembles de modifications (OBSOLÈTE)

-T,--modèle
modèle pour regrouper les changesets (par défaut : {author|email})

-F,--format de date
format compatible strftime pour le regroupement par date

-c, --changesets
taux de comptage par nombre de changesets

-Oui, --sorte
trier par clé (par défaut : trier par nombre)

--diffstat
afficher les lignes ajoutées/supprimées séparément

--alias
fichier avec des alias de messagerie

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

lots de clones
annoncez des bundles pré-générés pour semer des clones

"clonebundles" est une extension côté serveur utilisée pour annoncer l'existence de
fichiers groupés pré-générés et hébergés en externe aux clients qui procèdent au clonage afin que le clonage
peuvent être plus rapides, plus fiables et nécessitent moins de ressources sur le serveur.

Le clonage peut être une opération gourmande en CPU et en E/S sur les serveurs. Traditionnellement, le serveur, en
réponse à la demande de clonage d'un client, génère dynamiquement un bundle contenant le
tout le contenu du référentiel et l'envoie au client. Il n'y a pas de cache sur le serveur
et le serveur devra générer de manière redondante le même bundle sortant en réponse à
chaque demande de clonage. Pour les serveurs avec de grands référentiels ou avec un volume de clone élevé, le
la charge à partir de clones peut rendre la mise à l'échelle du serveur difficile et coûteuse.

Cette extension offre aux opérateurs de serveurs la possibilité de décharger des
cloner le chargement vers un service externe. Voici comment cela fonctionne.

1. Un opérateur de serveur met en place un mécanisme permettant de mettre à disposition des fichiers groupés sur un
service d'hébergement où les clients de Mercurial peuvent les récupérer.

2. Un fichier manifeste répertoriant les URL de bundle disponibles et certaines métadonnées facultatives est ajouté à
le référentiel Mercurial sur le serveur.

3. Un client lance un clone sur un serveur prenant en charge les bundles de clones.

4. Le client voit que le serveur annonce des bundles de clones et récupère le manifeste
répertoriant les forfaits disponibles.

5. Le client filtre et trie les bundles disponibles en fonction de ce qu'il prend en charge et
préfère.

6. Le client télécharge et applique un bundle disponible à partir de l'URL spécifiée par le serveur.

7. Le client se reconnecte au serveur d'origine et exécute l'équivalent de hg tirer à
récupérer toutes les données du référentiel qui ne se trouvent pas dans le bundle. (Le référentiel aurait pu être mis à jour
entre le moment où le bundle a été créé et le moment où le client a démarré le clone.)

Au lieu que le serveur génère des bundles de référentiel complets pour chaque demande de clonage, il
génère des bundles complets une fois et ils sont ensuite réutilisés pour amorcer de nouveaux clones. le
le serveur peut toujours transférer des données au moment du clonage. Cependant, ce ne sont que des données qui ont été
ajoutés/modifiés depuis la création du bundle. Pour les grands référentiels établis, cela peut
réduire la charge du serveur pour les clones à moins de 1 % de l'original.

Pour fonctionner, cette extension nécessite les opérateurs de serveur suivants :

· Génération de fichiers groupés du contenu du référentiel (généralement périodiquement, comme une fois par
journée).

· Un serveur de fichiers auquel les clients ont accès au réseau et auquel Python sait parler
via sa fonction de gestion d'URL normale (généralement un serveur HTTP).

· Un processus permettant de synchroniser le manifeste des ensembles avec les fichiers d'ensembles disponibles.

Strictement parlant, l'utilisation d'un serveur d'hébergement de fichiers statiques n'est pas obligatoire : un opérateur de serveur
pourrait utiliser un service dynamique pour récupérer les données du bundle. Cependant, l'hébergement de fichiers statiques
les services sont simples et évolutifs et devraient être suffisants pour la plupart des besoins.

Les fichiers groupés peuvent être générés avec le hg pack commander. Typiquement hg pack --tout is
utilisé pour produire un bundle de l'ensemble du référentiel.

hg débogagecreatestreamclonebundle peut être utilisé pour produire un spécial streaming cloner pack.
Ce sont des fichiers groupés extrêmement efficaces à produire et à consommer (lire : rapides).
Cependant, ils sont plus volumineux que les formats de bundle traditionnels et nécessitent que les clients prennent en charge
l'ensemble exact des formats de magasin de données du référentiel utilisé par le référentiel qui les a créés.
Généralement, un serveur plus récent peut servir des données compatibles avec des clients plus anciens. Cependant,
streaming cloner liasses n'ont pas cette garantie. Server opérateurs need à be conscients qui
Plus récent versions of Mercuriel Au cours de cette réunion, Matthew a obtenu de précieux conseils et Linda lui a demandé de la tenir au courant de ses progrès. produire streaming cloner liasses incompatible avec plus
Mercuriel versions.

Un opérateur de serveur est responsable de la création d'un .hg/clonebundles.manifest fichier contenant
la liste des fichiers bundle disponibles adaptés à l'ensemencement des clones. Si ce fichier ne
existent, le référentiel n'annoncera pas l'existence de bundles de clones lorsque les clients
se connecter.

Le fichier manifeste contient une liste d'entrées délimitées par des retours à la ligne ( ).

Chaque ligne de ce fichier définit un bundle disponible. Les lignes ont le format :

[ = [ = ]]

Autrement dit, une URL suivie d'une liste facultative, délimitée par des espaces, de paires clé=valeur décrivant
propriétés supplémentaires de ce bundle. Les clés et les valeurs sont codées en URI.

Les clés en MAJUSCULES sont réservées à l'usage de Mercurial et sont définies ci-dessous. Tous
les clés non majuscules peuvent être utilisées par les installations du site. Un exemple d'utilisation pour les propriétés personnalisées
est d'utiliser le datacenter attribut pour définir dans quel centre de données un fichier est hébergé.
Les clients pourraient alors préférer un serveur dans le centre de données le plus proche d'eux.

Les clés réservées suivantes sont actuellement définies :

ENSEMBLESPEC
Une chaîne de "spécification de l'ensemble" qui décrit le type de l'ensemble.

Ce sont des valeurs de chaîne qui sont acceptées par l'argument "--type" de hg pack.

Les valeurs sont analysées en mode strict, ce qui signifie qu'elles doivent être du
" - ". Voir mercurial.exchange.parsebundlespec() pour plus
détails.

hg groupe de débogage --spec peut être utilisé pour imprimer la chaîne de spécification de bundle pour un
fichier groupé. La sortie de cette commande peut être utilisée textuellement pour la valeur de
ENSEMBLESPEC (il est déjà échappé).

Les clients filtreront automatiquement les spécifications inconnues ou
non pris en charge afin qu'ils n'essaient pas de télécharger quelque chose qui ne s'appliquera probablement pas.

La valeur réelle n'a pas d'incidence sur le comportement du client au-delà du filtrage : les clients
toujours renifler le type de bundle à partir de l'en-tête des fichiers téléchargés.

Utilisez of this key is très recommandé, car il permet aux clients d'ignorer facilement
paquets non pris en charge. Si cette clé n'est pas définie, un ancien client peut tenter d'appliquer
un paquet qu'il est incapable de lire.

REQUIRESNI
Indique si l'indication du nom du serveur (SNI) est requise pour se connecter à l'URL. SNI permet
serveurs d'utiliser plusieurs certificats sur la même IP. C'est assez courant dans les CDN
et d'autres fournisseurs d'hébergement. Les anciennes versions de Python ne prennent pas en charge SNI. Définir
cet attribut permet aux clients avec des versions plus anciennes de Python de filtrer cette entrée
sans subir d'échec SSL opaque au moment de la connexion.

Si cela est défini, il est important d'annoncer une URL ou des clients de secours non SNI
l'exécution d'anciennes versions de Python peut ne pas être en mesure de cloner avec les clonebundles
installation.

La valeur doit être "true".

Les manifestes peuvent contenir plusieurs entrées. En supposant que les métadonnées sont définies, les clients filtreront
entrées du manifeste qu'ils ne prennent pas en charge. Les entrées restantes sont éventuellement
triés par préférences client (experimental.clonebundleprefers option de configuration). Le client
tente ensuite de récupérer le bundle à la première URL de la liste restante.

Erreurs quand téléchargement a pack sera échouer le tout cloner opération: CLIENTS do ne sauraient
automatiquement tomber RETOUR à a traditionnel cloner. La raison en est que si un serveur est
en utilisant des bundles de clones, il le fait probablement parce que la fonctionnalité est nécessaire pour l'aider
escalader. En d'autres termes, on suppose que la charge du clone sera déchargée sur un autre
service et que le serveur Mercurial n'est pas responsable du service de cette charge de clone. Si
que d'autres services rencontrent des problèmes et que les clients commencent à revenir massivement à l'original
Serveur Mercurial, la charge de clone ajoutée pourrait submerger le serveur en raison d'une charge inattendue
et le mettre hors ligne efficacement. Ne pas avoir de clients qui se rabattent automatiquement sur le clonage
du serveur d'origine atténue ce scénario.

Parce qu'il n'y a pas de secours automatique du serveur Mercurial en cas d'échec de l'hébergement du bundle
service, il est important que les opérateurs de serveurs considèrent le service d'hébergement groupé comme un
extension du serveur Mercurial en termes de disponibilité et d'accords de niveau de service :
si le service d'hébergement groupé tombe en panne, il en va de même pour la possibilité pour les clients de cloner. Noter:
les clients verront un message les informant de la manière de contourner la fonction de bundles de clonage lorsqu'un
l'échec se produit. Les opérateurs de serveurs doivent donc se préparer à ce que certaines personnes suivent ces
instructions en cas de panne, entraînant ainsi plus de charge sur le Mercurial d'origine
serveur en cas d'échec du service d'hébergement groupé.

Couleur
coloriser la sortie de certaines commandes

L'extension color colorise la sortie de plusieurs commandes Mercurial. Par exemple, le
La commande diff affiche les ajouts en vert et les suppressions en rouge, tandis que la commande status affiche
fichiers modifiés en magenta. De nombreuses autres commandes ont des couleurs analogues. Il est possible de
personnalisez ces couleurs.

Effets
D'autres effets en plus de la couleur, comme le texte en gras et souligné, sont également disponibles. Par
par défaut, la base de données terminfo est utilisée pour trouver les codes terminaux utilisés pour changer de couleur et
effet. Si terminfo n'est pas disponible, les effets sont rendus avec le SGR ECMA-48
fonction de contrôle (alias codes d'échappement ANSI).

Les effets disponibles en mode terminfo sont 'blink', 'bold', 'dim', 'inverse', 'invisible',
'italique', 'hors jeu' et 'souligné' ; en mode ECMA-48, les options sont 'gras', 'inverse',
'italique' et 'souligné'. Le rendu de chacun dépend de l'émulateur de terminal. Quelque
peut ne pas être disponible pour un type de terminal donné et sera ignoré en silence.

Etiquettes
Le texte reçoit des effets de couleur en fonction des étiquettes dont il dispose. Beaucoup de Mercurial par défaut
les commandes émettent du texte étiqueté. Vous pouvez également définir vos propres étiquettes dans des modèles à l'aide de la
fonction d'étiquette, voir hg aider modèles. Une seule portion de texte peut avoir plus d'un
étiqueter. Dans ce cas, les effets donnés à la dernière étiquette remplaceront tous les autres effets. Ce
inclut l'effet spécial "aucun", qui annule les autres effets.

Les étiquettes sont normalement invisibles. Afin de voir ces étiquettes et leur position dans le
texte, utilisez l'option globale --color=debug. Le même texte d'ancrage peut être associé à
plusieurs étiquettes, par exemple

[log.changeset changeset.secret|changeset: 22611:6f0a53c8f587]

Voici les effets par défaut pour certaines étiquettes par défaut. Les effets par défaut peuvent être
remplacé à partir de votre fichier de configuration :

[Couleur]
status.modified = bleu gras souligné red_background
status.added = vert gras
status.removed = rouge gras blue_background
status.deleted = souligné gras cyan
status.unknown = magenta gras souligné
status.ignored = noir gras

# 'aucun' désactive tous les effets
status.clean = aucun
status.copied = aucun

qseries.applied = soulignement gras bleu
qseries.unapplied = noir gras
qseries.missing = rouge gras

diff.diffline = gras
diff.extended = cyan gras
diff.file_a = rouge gras
diff.file_b = vert gras
diff.hunk = magenta
diff.supprimé = rouge
diff.inséré = vert
diff.changé = blanc
diff.tab =
diff.trailingwhitespace = gras red_background

# Vide pour hériter du style de l'étiquette environnante
changeset.public =
changeset.draft =
changeset.secret =

resolve.unresolved = rouge gras
resolve.resolved = vert gras

bookmarks.active = vert

branches.active = aucun
branches.closed = noir gras
branches.current = vert
branches.inactive = aucun

tags.normal = vert
tags.local = gras noir

rebase.rebased = bleu
rebase.remaining = rouge gras

étagère.age = cyan
shelve.newest = vert gras
shelve.name = bleu gras

histedit.remaining = rouge gras

Coutume les couleurs
Parce qu'il n'y a que huit couleurs standard, ce module vous permet de définir des noms de couleurs
pour les autres emplacements de couleur qui pourraient être disponibles pour votre type de terminal, en supposant que terminfo
mode. Par exemple:

couleur.brightblue = 12
couleur.rose = 207
couleur.orange = 202

pour définir 'brightblue' sur l'emplacement de couleur 12 (utile pour les terminaux 16 couleurs qui ont des couleurs plus lumineuses
couleurs définies dans les huit hauts) et "rose" et "orange" aux couleurs des xterms 256 couleurs
cube de couleur par défaut. Ces couleurs définies peuvent ensuite être utilisées comme n'importe laquelle des couleurs prédéfinies.
huit, y compris l'ajout de '_background' pour définir l'arrière-plan sur cette couleur.

Modes
Par défaut, l'extension de couleur utilisera le mode ANSI (ou le mode win32 sous Windows) si elle
détecte une borne. Pour annuler le mode automatique (pour activer le mode terminfo, par exemple), définissez le
option de configuration suivante :

[Couleur]
mode = infoterme

Toute valeur autre que 'ansi', 'win32', 'terminfo' ou 'auto' désactivera la couleur.

Notez que sur certains systèmes, le mode terminfo peut causer des problèmes lors de l'utilisation de la couleur avec le
extension de téléavertisseur et moins -R. moins avec l'option -R n'affichera que la couleur ECMA-48
codes, et le mode terminfo peut parfois émettre des codes que moins ne comprend pas. Tu peux
contourner ce problème en utilisant soit le mode ansi (ou le mode auto), soit en utilisant less -r (ce qui
passer par tous les codes de contrôle du terminal, pas seulement les codes de contrôle de couleur).

Sur certains systèmes (tels que MSYS sous Windows), le terminal peut prendre en charge un mode de couleur différent
que le pager (activé via l'extension "pager"). Il est possible de définir séparément
modes selon que le pager est actif :

[Couleur]
mode = automatique
mode pager = ansi

If mode téléavertisseur n'est pas défini, le mode sera utilisé.

Commandes
convertir
importer des révisions de référentiels VCS étrangers dans Mercurial

Commandes
convertir
convertir un référentiel SCM étranger en un référentiel Mercurial :

hg convertir [OPTION]... SOURCE [DEST [REVMAP]]

Formats sources acceptés [identifiants] :

· Mercurial [hg]

· CV [CV]

· Darcs [darcs]

· git [git]

· Subversion [svn]

· Monotone [mtn]

· Arche GNU [gnuarch]

· Bazar [bzr]

· Forcer [p4]

Formats de destination acceptés [identifiants] :

· Mercurial [hg]

· Subversion [svn] (l'historique des branches n'est pas conservé)

Si aucune révision n'est donnée, toutes les révisions seront converties. Sinon, la conversion ne fera que
importer jusqu'à la révision nommée (donnée dans un format compris par la source).

Si aucun nom de répertoire de destination n'est spécifié, il s'agit par défaut du nom de base de la source
avec -hg annexé. Si le référentiel de destination n'existe pas, il sera créé.

Par défaut, toutes les sources sauf Mercurial utiliseront --branchsort. Utilisations mercurielles
--sourcesort pour conserver l'ordre des numéros de révision d'origine. Les modes de tri ont les éléments suivants
effets:

--tri de branches
convertir de la révision parent à la révision enfant lorsque cela est possible, ce qui signifie que les branches sont
généralement convertis les uns après les autres. Il génère des référentiels plus compacts.

--datesort
trier les révisions par date. Les référentiels convertis ont de beaux journaux des modifications, mais sont
souvent un ordre de grandeur supérieur à ceux générés par --branchsort.

--tri des sources
essayez de préserver l'ordre des révisions des sources, uniquement pris en charge par les sources Mercurial.

--closesort
essayez de déplacer les révisions fermées aussi près que possible des branches parentes, uniquement
pris en charge par des sources Mercurial.

If REVMAP n'est pas donné, il sera placé dans un emplacement par défaut (/.hg/shamap by
défaut). Les REVMAP est un simple fichier texte qui associe chaque ID de validation source au
ID de destination pour cette révision, comme ceci :



Si le fichier n'existe pas, il est automatiquement créé. Il est mis à jour à chaque commit copié,
so hg convertir peut être interrompu et peut être exécuté à plusieurs reprises pour copier de nouveaux commits.

Le authormap est un simple fichier texte qui mappe chaque auteur de commit source à une destination
commettre l'auteur. C'est pratique pour les SCM source qui utilisent des identifiants Unix pour identifier les auteurs (par exemple :
CVS). Une ligne par mappage d'auteur et le format de ligne est :

auteur source = auteur destination

Lignes vides et lignes commençant par un # sont ignorés.

Le filemap est un fichier qui permet de filtrer et de remapper des fichiers et des répertoires. Chaque
line peut contenir l'une des directives suivantes :

inclure chemin/vers/fichier-ou-répertoire

exclure chemin/vers/fichier-ou-répertoire

renommer chemin/vers/chemin source/vers/destination

Les lignes de commentaire commencent par #. Un chemin spécifié correspond s'il est égal au nom relatif complet
d'un fichier ou d'un de ses répertoires parents. le comprendre or exclure directive avec le
le chemin correspondant le plus long s'applique, donc l'ordre des lignes n'a pas d'importance.

La comprendre entraîne l'inclusion d'un fichier ou de tous les fichiers d'un répertoire dans la
référentiel de destination. La valeur par défaut s'il n'y a pas comprendre déclarations doit inclure
tout. S'il y en a comprendre déclarations, rien d'autre n'est inclus. le exclure
directive entraîne l'omission de fichiers ou de répertoires. le rebaptiser directive renomme un fichier
ou répertoire s'il est converti. Pour renommer un sous-répertoire à la racine du
référentiel, utiliser . comme chemin à renommer.

--complet s'assurera que les changesets convertis contiennent exactement les bons fichiers avec le
contenu correct. Il fera une conversion complète de tous les fichiers, pas seulement ceux qui ont
modifié. Les fichiers qui sont déjà corrects ne seront pas modifiés. Cela peut être utilisé pour appliquer
le mappage de fichiers change lors de la conversion incrémentielle. Ceci n'est actuellement pris en charge que pour
Mercurial et Subversion.

Le splicemap est un fichier qui permet l'insertion d'un historique synthétique, vous permettant de spécifier
les parents d'une révision. Ceci est utile si vous voulez, par exemple, donner à une fusion Subversion deux
parents, ou greffer ensemble deux séries d'histoires déconnectées. Chaque entrée contient une clé,
suivi d'un espace, suivi d'une ou deux valeurs séparées par des virgules :

clé parent1, parent2

La clé est l'ID de révision dans le système de contrôle de révision source dont les parents doivent être
modifié (même format qu'une clé dans .hg/shamap). Les valeurs sont les ID de révision (dans
le système de contrôle de révision source ou destination) qui doivent être utilisés comme nouveaux parents
pour ce nœud. Par exemple, si vous avez fusionné "release-1.0" dans "trunk", alors vous devriez
spécifiez la révision sur "trunk" comme premier parent et celle sur la "release-1.0"
branche comme la seconde.

Le branchmap est un fichier qui permet de renommer une branche lors de son introduction
à partir de n'importe quel référentiel externe. Lorsqu'il est utilisé en conjonction avec un splicemap, il permet
pour une combinaison puissante pour aider à réparer même les référentiels les plus mal gérés et
transformez-les en référentiels Mercurial bien structurés. Le branchmap contient des lignes de
la forme:

nom_de_branche_d'origine nouveau_nom_de_branche

où "original_branch_name" est le nom de la branche dans le référentiel source, et
"new_branch_name" est le nom de la branche est le référentiel de destination. Pas d'espace
est autorisé dans les noms de branche. Cela peut être utilisé pour (par exemple) déplacer du code dans un
référentiel de "default" vers une branche nommée.

Mercuriel Identifier
La source Mercurial reconnaît les options de configuration suivantes, que vous pouvez définir sur
la ligne de commande avec --config:

convert.hg.ignoreerrors
ignorer les erreurs d'intégrité lors de la lecture. Utilisez-le pour réparer les référentiels Mercurial avec
revlogs manquants, en convertissant depuis et vers Mercurial. La valeur par défaut est False.

convertir.hg.saverev
stocker l'ID de révision d'origine dans l'ensemble de modifications (force la modification des ID cibles). Il faut un
argument booléen et la valeur par défaut est False.

convertir.hg.startrev
spécifier la révision Mercurial initiale. La valeur par défaut est 0.

convertir.hg.revs
revset spécifiant les révisions source à convertir.

CVS Identifier
La source CVS utilisera un bac à sable (c'est-à-dire une copie extraite) de CVS pour indiquer le début
point de ce qui sera converti. L'accès direct aux fichiers du référentiel n'est pas nécessaire,
à moins bien sûr que le référentiel soit :locale:. La conversion utilise le répertoire de niveau supérieur dans
le bac à sable pour trouver le référentiel CVS, puis utilise les commandes CVS rlog pour trouver des fichiers à
convertir. Cela signifie qu'à moins qu'un mappage de fichiers ne soit donné, tous les fichiers sous le répertoire de départ
seront convertis et que toute réorganisation de répertoire dans le sandbox CVS est ignorée.

Les options suivantes peuvent être utilisées avec --config:

convertir.cvsps.cache
Définissez sur False pour désactiver la mise en cache des journaux à distance, à des fins de test et de débogage.
La valeur par défaut est True.

convertir.cvsps.fuzz
Spécifiez le temps maximum (en secondes) autorisé entre les commits avec
utilisateur et message de journal identiques dans un seul ensemble de modifications. Lorsque de très gros fichiers étaient
archivé dans le cadre d'un ensemble de modifications, la valeur par défaut peut ne pas être assez longue. le
la valeur par défaut est 60.

convertir.cvsps.mergeto
Spécifiez une expression régulière à laquelle les messages du journal de validation sont mis en correspondance. Si un match
se produit, alors le processus de conversion insérera une révision factice fusionnant la branche
sur laquelle ce message de journal apparaît à la branche indiquée dans la regex. La valeur par défaut est
{{fusionnerune branche ([-\w]+)}}

convertir.cvsps.mergefrom
Spécifiez une expression régulière à laquelle les messages du journal de validation sont mis en correspondance. Si un match
se produit, le processus de conversion ajoutera la révision la plus récente sur la branche
indiqué dans la regex comme second parent du changeset. La valeur par défaut est
{{mergefrombranch ([-\w]+)}}

convertir.localtimezone
utiliser l'heure locale (telle que déterminée par la variable d'environnement TZ) pour le jeu de modifications
dates/heures. La valeur par défaut est False (utilisez UTC).

crochets.cvslog
Spécifiez une fonction Python à appeler à la fin de la collecte du journal CVS. le
la fonction reçoit une liste avec les entrées du journal et peut modifier les entrées
sur place, ou ajoutez-les ou supprimez-les.

crochets.cvschangesets
Spécifiez une fonction Python à appeler après le calcul des ensembles de modifications à partir du
Journal CVS. La fonction reçoit une liste avec les entrées du jeu de modifications et peut modifier
les ensembles de modifications en place, ou ajoutez-les ou supprimez-les.

Une commande Mercurial "debugcvsps" supplémentaire permet au code de fusion de l'ensemble de modifications intégré de
être exécuté sans faire de conversion. Ses paramètres et sa sortie sont similaires à ceux de cvsps
2.1. Veuillez consulter l'aide de la commande pour plus de détails.

Subversion Identifier
La source Subversion détecte les dispositions tronc/branches/tags classiques. Par défaut, le
svn://dépôt/chemin/ l'URL source est convertie en une seule branche. Si svn://dépôt/chemin/tronc
existe, il remplace la branche par défaut. Si svn://dépôt/chemin/branches existe, son
les sous-répertoires sont répertoriés comme des branches possibles. Si svn://dépôt/chemin/tags existe, c'est
recherché des balises faisant référence à des branches converties. Défaut tronc, branches ainsi que étiquettes valeurs
peut être remplacé par les options suivantes. Définissez-les sur des chemins relatifs à l'URL source, ou
laissez-les vides pour désactiver la détection automatique.

Les options suivantes peuvent être définies avec --config:

convertir.svn.branches
spécifiez le répertoire contenant les branches. La valeur par défaut est branches.

convertir.svn.tags
spécifiez le répertoire contenant les balises. La valeur par défaut est étiquettes.

convertir.svn.trunk
spécifiez le nom de la branche du tronc. La valeur par défaut est tronc.

convertir.localtimezone
utiliser l'heure locale (telle que déterminée par la variable d'environnement TZ) pour le jeu de modifications
dates/heures. La valeur par défaut est False (utilisez UTC).

L'historique des sources peut être récupéré à partir d'une révision spécifique, au lieu d'être
intégralement converti. Seules les conversions de branche unique sont prises en charge.

convertir.svn.startrev
spécifiez le numéro de révision Subversion de départ. La valeur par défaut est 0.

Git Identifier
L'importateur Git convertit les commits de toutes les branches accessibles (refs in refs/heads) et
remotes (refs dans refs/remotes) à Mercurial. Les branches sont converties en signets avec le
même nom, avec le premier 'refs/heads' dépouillé. Les sous-modules Git sont convertis en Git
sous-dépôts dans Mercurial.

Les options suivantes peuvent être définies avec --config:

convert.git.similarité
spécifier comment les fichiers similaires modifiés dans un commit doivent être importés en tant que noms ou
copies, en pourcentage entre 0 (désactivé) et 100 (les fichiers doivent être identiques). Pour
Par exemple, 90 signifie qu'une paire supprimer/ajouter sera importée en tant que changement de nom si plus de
90% du fichier n'a pas changé. La valeur par défaut est 50.

convert.git.findcopiesharder
lors de la détection des copies, examinez tous les fichiers de la copie de travail au lieu de simplement
changés. Ceci est très coûteux pour les grands projets et n'est efficace que lorsque
convert.git.similarité est supérieur à 0. La valeur par défaut est False.

convertir.git.remoteprefix
les références distantes sont converties en signets avec convertir.git.remoteprefix comme préfixe
suivie d'une /. La valeur par défaut est 'distant'.

convertir.git.skipsubmodules
ne convertit pas les fichiers .gitmodules de niveau racine ou les fichiers avec le mode 160000 indiquant
un sous-module. La valeur par défaut est False.

Forcément Identifier
L'importateur Perforce (P4) peut recevoir un chemin de dépôt p4 ou une spécification client comme
la source. Il convertira tous les fichiers de la source en un référentiel Mercurial plat, ignorant
étiquettes, branches et intégrations. Notez que lorsqu'un chemin de dépôt vous est donné, généralement
doit spécifier un répertoire cible, car sinon la cible peut être nommée ...-hg.

Les options suivantes peuvent être définies avec --config:

convertir.p4.encoding
spécifier l'encodage à utiliser lors du décodage de la sortie standard de la commande Perforce
outil de ligne. La valeur par défaut est l'encodage système par défaut.

convertir.p4.startrev
spécifier la révision Perforce initiale (un numéro de liste de modifications Perforce).

Mercuriel dentaire
La destination Mercurial reconnaîtra les sous-dépôts Mercurial dans la destination
répertoire et mettre à jour le fichier .hgsubstate automatiquement si la destination
les sous-dépôts contiennent les / /.hg/fichier shamap. Conversion d'un dépôt avec
les sous-dépôts nécessitent la conversion d'un seul référentiel à la fois, de bas en haut.

Un exemple montrant comment convertir un dépôt avec des sous-dépôts :

# donc convert connaît le type quand il voit une destination non vide
$ hg init converti

$ hg convertir orig/sub1 converti/sub1
$ hg convertir orig/sub2 converti/sub2
$ hg convertir orig converti

Les options suivantes sont prises en charge :

convertir.hg.clonebranches
répartir les branches source dans des clones séparés. Le défaut est faux.

convertir.hg.tagsbranch
nom de branche pour les révisions de balises, par défaut défaut.

convertir.hg.usebranchnames
conserver les noms de branche. La valeur par défaut est Vrai.

convertir.hg.nomsource
enregistre la chaîne donnée en tant que valeur supplémentaire 'convert_source' à chaque commit effectué dans
le référentiel cible. La valeur par défaut est Aucun.

Tous Destinations
Tous les types de destination acceptent les options suivantes :

convertir.skiptags
ne convertit pas les balises du référentiel source vers le référentiel cible. La valeur par défaut est
Faux.

Options:

--auteurs
nom de fichier de mappage de nom d'utilisateur (OBSOLÈTÉ) (utilisez --authormap à la place)

-Oui,--Type de Source
type de référentiel source

-ré,--dest-type
type de référentiel de destination

-r,--tour
importer jusqu'à la révision source REV

-UNE,--authormap
remapper les noms d'utilisateur à l'aide de ce fichier

--filemap
remapper les noms de fichiers en utilisant le contenu du fichier

--complet appliquer les modifications du plan de fichiers en convertissant à nouveau tous les fichiers

--splicemap
coller l'histoire synthétisée en place

--branchmap
changer les noms des branches lors de la conversion

--tri de branches
essayez de trier les changesets par branches

--datesort
essayez de trier les changesets par date

--tri des sources
préserver l'ordre des ensembles de modifications source

--closesort
essayez de réorganiser les révisions fermées

L'option marquée [+] peut être spécifiée plusieurs fois

eol
gérer automatiquement les retours à la ligne dans les fichiers du référentiel

Cette extension permet de gérer le type de fins de ligne (CRLF ou LF) utilisées dans
le référentiel et dans le répertoire de travail local. De cette façon, vous pouvez obtenir les fins de ligne CRLF
sous Windows et LF sous Unix/Mac, permettant ainsi à chacun d'utiliser les terminaisons de ligne natives de son système d'exploitation.

L'extension lit sa configuration à partir d'un fichier versionné .hgeol fichier de configuration trouvé dans
la racine du répertoire de travail. le .hgeol fichier utilise la même syntaxe que tous les autres
Fichiers de configuration Mercurial. Il utilise deux sections, [motifs] ainsi que [dépôt].

La [motifs] section spécifie comment les fins de ligne doivent être converties entre le travail
répertoire et le référentiel. Le format est spécifié par un modèle de fichier. Le premier match
est utilisé, alors mettez d'abord des modèles plus spécifiques. Les fins de ligne disponibles sont LF, CRLFet
BIN.

Fichiers au format déclaré de CRLF or LF sont toujours extraits et stockés dans le
référentiel dans ce format et les fichiers déclarés binaires (BIN) restent inchangés.
En outre, indigène est un alias pour l'extraction dans la fin de ligne par défaut de la plate-forme :
LF sous Unix (y compris Mac OS X) et CRLF sur Windows. Noter que BIN (ne rien faire à la ligne
terminaisons) est le comportement par défaut de Mercurial ; il n'est nécessaire que si vous devez remplacer un
plus tard, schéma plus général.

Le facultatif [dépôt] spécifie les fins de ligne à utiliser pour les fichiers stockés dans
le référentiel. Il a un réglage unique, indigène, qui détermine les fins de ligne de stockage
pour les fichiers déclarés comme indigène dans l' [motifs] section. Il peut être réglé sur LF or CRLFL’
la valeur par défaut est LF. Par exemple, cela signifie que sous Windows, les fichiers configurés comme indigène (CRLF
par défaut) sera converti en LF lorsqu'ils sont stockés dans le référentiel. Fichiers déclarés comme LF,
CRLFou BIN dans l' [motifs] section sont toujours stockés tels quels dans le référentiel.

Exemple versionné .hgeol fichier:

[motifs]
**.py = natif
**.vcproj = CRLF
**.txt = natif
Makefile = LF
**.jpg = BAC

[dépôt]
natif = LF

Remarque Les règles s'appliqueront d'abord lorsque des fichiers sont touchés dans le répertoire de travail, par exemple par
mise à jour à null et retour à tip pour toucher tous les fichiers.

L'extension utilise une option [éol] section lu à la fois du Mercurial normal
les fichiers de configuration et les .hgeol fichier, ce dernier prenant le pas sur le premier. Tu peux
utilisez cette section pour contrôler le comportement général. Il existe trois paramètres :

· eol.natif (défaut os.linesep) peut être réglé sur LF or CRLF pour remplacer la valeur par défaut
interprétation de indigène pour la caisse. Ceci peut être utilisé avec hg archives sous Unix, disons, à
générer une archive où les fichiers ont des fins de ligne pour Windows.

· eol.only-cohérent (Vrai par défaut) peut être défini sur Faux pour que l'extension soit convertie
fichiers avec des EOL incohérents. Incohérent signifie qu'il y a à la fois CRLF ainsi que LF représentent
dans le fichier. Ces fichiers ne sont normalement pas touchés sous l'hypothèse qu'ils ont
intentionnellement des EOL mixtes.

· eol.fix-trailing-newline (Faux par défaut) peut être défini sur Vrai pour s'assurer que
les fichiers se terminent par un caractère EOL (soit \n or \ R \ n selon les modèles configurés).

L'extension fournit code intelligent : ainsi que décodage intelligent : filtres comme obsolète
l'extension win32text le fait. Cela signifie que vous pouvez désactiver win32text et activer eol et
vos filtres fonctionneront toujours. Vous n'avez besoin de ces filtres que jusqu'à ce que vous ayez préparé un
.hgeol fichier.

La win32text.forbid* crochets fournis par l'extension win32text ont été unifiés dans un
crochet unique nommé eol.checkheadshook. Le crochet recherchera les fins de ligne attendues à partir de
le .hgeol fichier, ce qui signifie que vous devez migrer vers un .hgeol fichier avant d'utiliser le
crochet. eol.checkheadshook ne vérifie que les têtes, les révisions invalides intermédiaires seront poussées.
Pour les interdire complètement, utilisez le eol.checkallhook crochet. Ces crochets sont mieux utilisés comme
faire semblant de changer de groupe crochets.

See hg aider motifs pour plus d'informations sur les modèles glob utilisés.

DiffExt
commande pour autoriser les programmes externes à comparer les révisions

L'extension extdiff Mercurial vous permet d'utiliser des programmes externes pour comparer les révisions,
ou révision avec répertoire de travail. Les programmes diff externes sont appelés avec un
ensemble configurable d'options et deux arguments non optionnels : chemins vers les répertoires contenant
instantanés de fichiers à comparer.

L'extension extdiff vous permet également de configurer de nouvelles commandes diff, vous n'avez donc pas besoin
taper hg DiffExt -p kdiff3 toujours.

[diffext]
# ajouter une nouvelle commande qui exécute GNU diff(1) en mode 'context diff'
cdiff = gdiff -Nprc5
## ou à l'ancienne :
#cmd.cdiff = gdiff
#opts.cdiff = -Nprc5

# ajouter une nouvelle commande appelée meld, exécute meld (pas besoin de nommer deux fois). Si
# l'exécutable de fusion n'est pas disponible, l'outil de fusion dans [merge-tools]
# sera utilisé, si disponible
fusionner =

# ajouter une nouvelle commande appelée vimdiff, exécute gvimdiff avec le plugin DirDiff
# (voir http://www.vim.org/scripts/script.php?script_id=102) Non
# Utilisateur anglais, assurez-vous de mettre "let g:DirDiffDynamicDiffText = 1" dans
# votre .vimrc
vimdiff = gvim -f "+suivant" \
"+execute 'DirDiff' fnameescape(argv(0)) fnameescape(argv(dix))"

Les arguments de l'outil peuvent inclure des variables développées lors de l'exécution :

$parent1, $plabel1 - nom de fichier, étiquette descriptive du premier parent
$child, $clabel - nom de fichier, étiquette descriptive de la révision enfant
$parent2, $plabel2 - nom de fichier, étiquette descriptive du second parent
$root - racine du référentiel
$parent est un alias pour $parent1.

L'extension extdiff cherchera dans vos sections [diff-tools] et [merge-tools] pour diff
arguments de l'outil, lorsqu'aucun n'est spécifié dans [extdiff].

[diffext]
kdiff3 =

[diff-outils]
kdiff3.diffargs=--L1 '$plabel1' --L2 '$clabel' $parent $enfant

Vous pouvez utiliser -I/-X et la liste des noms de fichiers ou de répertoires comme d'habitude hg diff commander. le
extdiff fait des instantanés des seuls fichiers nécessaires, donc en exécutant le diff externe
programme sera en fait assez rapide (au moins plus rapide que d'avoir à comparer l'ensemble
arbre).

Commandes
DiffExt
utiliser un programme externe pour différencier le référentiel (ou les fichiers sélectionnés):

hg diffext [OPT]... [FICHIER]...

Afficher les différences entre les révisions des fichiers spécifiés, à l'aide d'un programme externe. Le
Le programme par défaut utilisé est diff, avec les options par défaut "-Npru".

Pour sélectionner un autre programme, utilisez l'option -p/--program. Le programme sera adopté le
noms de deux répertoires à comparer. Pour passer des options supplémentaires au programme, utilisez
-o/--option. Ceux-ci seront passés avant les noms des répertoires à comparer.

Lorsque deux arguments de révision sont fournis, les modifications sont affichées entre ces révisions. Si
une seule révision est spécifiée puis cette révision est comparée au répertoire de travail,
et, lorsqu'aucune révision n'est spécifiée, les fichiers du répertoire de travail sont comparés à ses
parent.

Options:

-p,--programme
programme de comparaison à exécuter

-o,--option
passer l'option au programme de comparaison

-r,--tour
révision

-c,--monnaie
modification apportée par révision

--pièce
comparer les correctifs pour deux révisions

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

factotum
authentification http avec factotum

Cette extension permet au factotum(4) installation sur Plan 9 depuis les plates-formes Bell Labs vers
fournir des informations d'authentification pour l'accès HTTP. Les entrées de configuration spécifiées dans le
auth ainsi que les informations d'authentification fournies dans l'URL du référentiel sont
entièrement pris en charge. Si aucun préfixe n'est spécifié, la valeur "*" sera supposée.

Par défaut, les clés sont spécifiées comme :

proto=pass service=hg prefix= utilisateur= !mot de passe=

Si l'extension de factotum n'est pas en mesure de lire la clé requise, une clé sera demandée
de manière interactive.

Une section de configuration est disponible pour personnaliser le comportement d'exécution. Par défaut, ces
les entrées sont :

[factotum]
exécutable = /bin/auth/factotum
point de montage = /mnt/factotum
service = hg

L'entrée exécutable définit le chemin complet vers le factotum binaire. L'entrée du point de montage
définit le chemin vers le service de fichier factotum. Enfin, l'entrée de service contrôle la
nom de service utilisé lors de la lecture des clés.

rapporter
extraire, mettre à jour et fusionner en une seule commande (OBSOLÈTE)

Commandes
rapporter
extrayez les modifications d'un référentiel distant, fusionnez les nouvelles modifications si nécessaire :

hg récupérer [SOURCE]

Cela trouve toutes les modifications du référentiel au chemin ou à l'URL spécifié et les ajoute à
le référentiel local.

Si les modifications extraites ajoutent une nouvelle tête de branche, la tête est automatiquement fusionnée et la
résultat de la fusion est validé. Sinon, le répertoire de travail est mis à jour pour inclure
les nouveaux changements.

Lorsqu'une fusion est nécessaire, le répertoire de travail est d'abord mis à jour vers le nouveau répertoire
changements. Les modifications locales sont ensuite fusionnées dans les modifications extraites. Pour changer l'ordre de fusion,
utilisez --switch-parent.

See hg aider dates pour une liste de formats valides pour -d/--date.

Renvoie 0 en cas de succès.

Options:

-r,--tour
une révision spécifique que vous souhaitez extraire

-e, --modifier
invoquer l'éditeur sur les messages de validation

--éditeur de force
modifier le message de validation (obsolète)

--switch-parent
changer de parent lors de la fusion

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

gpg
commandes pour signer et vérifier les ensembles de modifications

Commandes
sigcheck
vérifier toutes les signatures qu'il peut y avoir pour une révision particulière :

hg sigcheck REV

vérifier toutes les signatures qu'il peut y avoir pour une révision particulière

signer
ajouter une signature pour la révision actuelle ou donnée :

signe hg [OPTION]... [REV]...

Si aucune révision n'est donnée, le parent du répertoire de travail est utilisé, ou tip si non
la révision est extraite.

La gpg.cmd Le paramètre de configuration peut être utilisé pour spécifier la commande à exécuter. Une clé par défaut peut être
spécifié avec gpg.clé.

See hg aider dates pour une liste de formats valides pour -d/--date.

Options:

-l, --locale
rendre la signature locale

-F, --Obliger
signer même si le fichier sig est modifié

--sans engagement
ne validez pas le fichier sig après la signature

-k,--clé
l'identifiant de clé avec lequel signer

-m,--un message
utiliser le texte comme message de validation

-e, --modifier
invoquer l'éditeur sur les messages de validation

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

sigs
lister les changesets signés :

signes hg

lister les changesets signés

journal graphique
commande pour afficher les graphiques de révision à partir d'un shell (OBSOLÈTE)

La fonctionnalité de cette extension a été incluse dans le noyau Mercurial depuis la version 2.3.
S'il vous plaît utiliser hg enregistrer -G à la place.

Cette extension ajoute une option --graph aux commandes entrantes, sortantes et log. Quand cela
options est donnée, une représentation ASCII du graphique de révision est également affichée.

Commandes
aubépine
afficher l'historique des révisions à côté d'un graphique de révision ASCII :

hg glog [OPTION]... [FICHIER]

Imprimez un historique de révision à côté d'un graphique de révision dessiné avec des caractères ASCII.

Les nœuds imprimés sous la forme d'un caractère @ sont les parents du répertoire de travail.

Ceci est un alias pour hg enregistrer -G.

Options:

-F, --poursuivre
suivre l'historique des modifications ou l'historique des fichiers à travers les copies et les renommages

--suivre d'abord
suivre uniquement le premier parent des ensembles de modifications de fusion (PÉRIMÉ)

-ré,--Date
afficher les révisions correspondant aux spécifications de date

-Ç, --copies
afficher les fichiers copiés

-k,--mot-clé
faire une recherche insensible à la casse pour un texte donné

-r,--tour
afficher la révision ou le revset spécifié

--supprimé
inclure les révisions où les fichiers ont été supprimés

-m, --only-fusions
afficher uniquement les fusions (PÉRIMÉ)

-tu,--utilisateur
révisions validées par l'utilisateur

--seulement-branche
afficher uniquement les ensembles de modifications dans la branche nommée donnée (PÉRIMÉ)

-b,--branche
afficher les ensembles de modifications dans la branche nommée donnée

-P,--prune
ne pas afficher la révision ou aucun de ses ancêtres

-p, --pièce
montrer le patch

-g, --git
utiliser le format de diff étendu git

-l,--limite
nombre limite de modifications affichées

-M, --no-fusions
ne pas afficher les fusions

--stat sortie résumé des modifications de style diffstat

-G, --graphique
afficher le DAG de révision

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

hgcia
crochets pour l'intégration avec le service de notification CIA.vc

Ceci est destiné à être exécuté en tant que groupe de modification ou crochet entrant. Pour le configurer, réglez le
options suivantes dans votre hgrc :

[cia]
# votre nom d'utilisateur enregistré auprès de la CIA
utilisateur = foo
# le nom du projet dans CIA
projet = foo
# le module (sous-projet) (optionnel)
#module = foo
# Ajouter un diffstat au message de journal (facultatif)
#diffstat = Faux
# Modèle à utiliser pour les messages de journal (facultatif)
#template = {desc}\n{baseurl}{webroot}/rev/{node}-- {diffstat}
# Style à utiliser (facultatif)
#style = truc
# L'URL du service de notification CIA (optionnel)
# Vous pouvez utiliser mailto : URL à envoyer par e-mail, par exemple
# mailto:[email protected]
# Assurez-vous de définir email.from si vous faites cela.
#URL = http://cia.vc/
# imprime le message au lieu de l'envoyer (optionnel)
#test = Faux
# nombre de barres obliques à supprimer pour les chemins d'URL
#bande = 0

[crochets]
# un de ceux-là:
changegroup.cia = python:hgcia.hook
#incoming.cia = python:hgcia.hook

[la toile]
# Si vous voulez des hyperliens (optionnel)
baseurl = http://server/path/to/repo

hgk
parcourir le référentiel de manière graphique

L'extension hgk permet de parcourir l'historique d'un dépôt de manière graphique. Ce
nécessite Tcl/Tk version 8.4 ou ultérieure. (Tcl/Tk n'est pas distribué avec Mercurial.)

hgk se compose de deux parties : un script Tcl qui affiche et interroge
informations, et une extension de Mercurial nommée hgk.py, qui fournit des crochets pour hgk à
obtenir des informations. hgk se trouve dans le répertoire contrib et l'extension est livrée
dans le référentiel hgext et doit être activé.

La hg vue La commande lancera le script hgk Tcl. Pour que cette commande fonctionne, hgk doit être
dans votre chemin de recherche. Alternativement, vous pouvez spécifier le chemin vers hgk dans votre configuration
fichier:

[hgk]
chemin = /emplacement/de/hgk

hgk peut utiliser l'extension extdiff pour visualiser les révisions. En supposant que vous aviez
commande extdiff vdiff déjà configurée, ajoutez simplement :

[hgk]
vdiff=vdiff

Le menu contextuel des révisions affichera désormais des entrées supplémentaires pour déclencher vdiff survolé et
révisions sélectionnées.

Commandes
vue
démarrer la visionneuse d'historique interactive :

hg vue [-l LIMITE] [REVRANGE]

démarrer la visionneuse d'historique interactive

Options:

-l,--limite
nombre limite de modifications affichées

mettre en évidence
coloration syntaxique pour hgweb (nécessite Pygments)

Cela dépend de la bibliothèque de coloration syntaxique Pygments : http://pygments.org/

Il existe les options de configuration suivantes :

[la toile]
pygments_style = (default: colorful)
fichiers de surbrillance = (par défaut : taille('<5M'))
highlightonlymatchfilename = (Faux par défaut)

mettre en surbrillance uniquement le nom de fichier correspondant ne mettra en surbrillance les fichiers que si leur type a pu être identifié par
leur nom de fichier. Lorsque cela n'est pas activé (par défaut), Pygments s'efforcera de
identifier le type de fichier à partir du contenu et de toute correspondance (même les correspondances avec un faible niveau de confiance
score) sera utilisé.

modifier
édition interactive de l'historique

Avec cette extension installée, Mercurial gagne une nouvelle commande : histedit. L'utilisation est comme
suit, en supposant l'historique suivant :

@ 3[astuce] 7c2fd3b9020c 2009-04-27 18:04 -0500 durin42
| Ajouter delta
|
o 2 030b686bedc4 2009-04-27 18:04 -0500 durin42
| Ajouter gamma
|
o 1 c561b4e977df 2009-04-27 18:04 -0500 pendantrin42
| Ajouter la version bêta
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 pendantrin42
Ajouter alpha

Si tu devais courir hg modifier c561b4e977df, vous verrez le fichier suivant s'ouvrir dans votre
éditeur:

choisir c561b4e977df Ajouter bêta
choisissez 030b686bedc4 Ajouter gamma
choisissez 7c2fd3b9020c Ajouter un delta

# Modifier l'historique entre c561b4e977df et 7c2fd3b9020c
#
# Les commits sont listés du moins au plus récent
#
# Commandes :
# p, choisir = utiliser commit
# e, edit = utiliser commit, mais s'arrêter pour modifier
# f, fold = utilisez commit, mais combinez-le avec celui ci-dessus
# r, roll = like fold, mais ignore la description de ce commit
# d, drop = supprimer le commit de l'historique
# m, mess = modifier le message de commit sans changer le contenu du commit
#

Dans ce fichier, les lignes commençant par # sont ignorés. Vous devez spécifier une règle pour chaque
révision dans votre histoire. Par exemple, si vous vouliez ajouter gamma avant bêta, puis
vouliez ajouter delta dans la même révision que la version bêta, vous réorganiseriez le fichier pour qu'il ressemble
comme ça:

choisissez 030b686bedc4 Ajouter gamma
choisir c561b4e977df Ajouter bêta
plier 7c2fd3b9020c Ajouter delta

# Modifier l'historique entre c561b4e977df et 7c2fd3b9020c
#
# Les commits sont listés du moins au plus récent
#
# Commandes :
# p, choisir = utiliser commit
# e, edit = utiliser commit, mais s'arrêter pour modifier
# f, fold = utilisez commit, mais combinez-le avec celui ci-dessus
# r, roll = like fold, mais ignore la description de ce commit
# d, drop = supprimer le commit de l'historique
# m, mess = modifier le message de commit sans changer le contenu du commit
#

À quel point vous fermez l'éditeur et modifier commence à fonctionner. Lorsque vous spécifiez un plier
le fonctionnement, modifier ouvrira un éditeur lorsqu'il regroupera ces révisions, offrant
vous une chance de nettoyer le message de validation :

Ajouter la version bêta
***
Ajouter delta

Modifiez le message de validation à votre convenance, puis fermez l'éditeur. Pour cet exemple, prenons
supposons que le message de validation a été remplacé par Ajouter bêta ainsi que delta. Après l'exécution de histedit
et a eu la possibilité de supprimer toutes les révisions anciennes ou temporaires dont il avait besoin, l'historique semble
comme ça:

@ 2[astuce] 989b4d060121 2009-04-27 18:04 -0500 durin42
| Ajouter bêta et delta.
|
o 1 081603921c3f 2009-04-27 18:04 -0500 durin42
| Ajouter gamma
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 pendantrin42
Ajouter alpha

Notez que modifier ne sauraient supprimer toutes les révisions (même ses propres temporaires) jusqu'après
il a terminé toutes les opérations d'édition, il va donc probablement effectuer plusieurs bandes
opérations quand c'est fait. Pour l'exemple ci-dessus, il a dû exécuter la bande deux fois. La bande peut être
lente en fonction de divers facteurs, vous devrez peut-être être un peu patient. Tu peux
choisir de conserver les révisions d'origine en passant le --garder drapeau.

La éditer l'opération vous ramènera à une invite de commande, vous permettant de modifier des fichiers
librement, ou même utiliser hg record pour valider certaines modifications dans un commit séparé. Quand tu es
terminé, toutes les modifications restantes non validées seront également validées. Lorsque vous avez terminé, exécutez hg
modifier --Continuez pour terminer cette étape. Vous serez invité à entrer un nouveau message de validation, mais
le message de validation par défaut sera le message d'origine pour le éditer révision éd.

La message opération vous donnera une chance de réviser un message de validation sans changer
les contenus. C'est un raccourci pour faire éditer immédiatement suivi de hg modifier
--continuer`.

If modifier rencontre un conflit lors du déplacement d'une révision (lors du traitement en particulier pendant la préparation or plier),
il s'arrêtera de la même manière que éditer à la différence qu'il ne vous demandera pas de
valider le message lorsque vous avez terminé. Si vous décidez à ce stade que vous n'aimez pas la quantité de travail
sera de réorganiser l'historique, ou que vous avez fait une erreur, vous pouvez utiliser hg modifier --avorter
pour abandonner les nouvelles modifications que vous avez apportées et revenir à l'état avant que vous n'essayiez de
modifier votre historique.

Si nous clonons l'exemple de référentiel histedit-ed ci-dessus et ajoutons quatre modifications supplémentaires, telles que
nous avons l'historique suivant :

@ 6[astuce] 038383181893 2009-04-27 18:04 -0500 stefan
| Ajouter thêta
|
o 5 140988835471 2009-04-27 18:04 -0500 stefan
| Ajouter eta
|
o 4 122930637314 2009-04-27 18:04 -0500 stefan
| Ajouter zêta
|
o 3 836302820282 2009-04-27 18:04 -0500 stefan
| Ajouter epsilon
|
o 2 989b4d060121 2009-04-27 18:04 -0500 pendantrin42
| Ajouter bêta et delta.
|
o 1 081603921c3f 2009-04-27 18:04 -0500 durin42
| Ajouter gamma
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 pendantrin42
Ajouter alpha

Si vous courez hg modifier --sortant sur le clone alors c'est la même chose que de courir hg modifier
836302820282. Si vous avez besoin de planifier de pousser vers un référentiel que Mercurial ne détecte pas pour
être lié au référentiel source, vous pouvez ajouter un --Obliger option.

Config
Les lignes de règles Histedit sont tronquées à 80 caractères par défaut. Vous pouvez personnaliser ce
comportement en définissant une longueur différente dans votre fichier de configuration :

[modifier]
linelen = 120 # tronque les lignes de règle à 120 caractères

hg modifier tente de choisir automatiquement une révision de base appropriée à utiliser. Pour
changez la révision de base utilisée, définissez un revset dans votre fichier de configuration :

[modifier]
defaultrev = only(.) & draft()

Par défaut, chaque révision éditée doit être présente dans les commandes histedit. Ôter
révision que vous devez utiliser déposer opération. Vous pouvez configurer la suppression pour qu'elle soit implicite pour
commits manquants en ajoutant :

[modifier]
dropmissing = Vrai

Commandes
modifier
modifier de manière interactive l'historique des modifications :

hg histedit [OPTIONS] ([ANCETEUR] | --outgoing [URL])

Cette commande vous permet de modifier une série linéaire d'ensembles de modifications (jusqu'à et y compris le
répertoire, qui doit être propre). Tu peux:

· en particulier pendant la préparation pour [ré]ordonner un ensemble de modifications

· déposer pour omettre le changeset

· mess pour reformuler le message de validation de l'ensemble de modifications

· plier pour le combiner avec le changeset précédent

· rouleau comme fold, mais en supprimant la description de ce commit

· éditer pour modifier ce changeset

Il existe plusieurs façons de sélectionner l'ensemble de modifications racine :

· Spécifiez ANCESTOR directement

· Utilisez --outgoing -- ce sera le premier ensemble de modifications linéaire non inclus dans la destination.
(Voir hg aider config.default-push)

· Sinon, la valeur de l'option de configuration "histedit.defaultrev" est utilisée comme revset pour
sélectionnez la révision de base lorsque ANCESTOR n'est pas spécifié. La première révision renvoyée par
le revset est utilisé. Par défaut, cela sélectionne l'historique modifiable qui est unique au
ascendance du répertoire de travail.

Si vous utilisez --outgoing, cette commande s'arrêtera s'il y a des révisions sortantes ambiguës.
Par exemple, s'il existe plusieurs branches contenant des révisions sortantes.

Utilisez "min(outgoing() and ::.)" ou une spécification revset similaire au lieu de --outgoing to
spécifiez exactement la révision cible de modification dans une telle situation ambiguë. Voir hg aider les revets en
détails sur la sélection des révisions.

Exemples :

· Un certain nombre de modifications ont été apportées. La révision 3 n'est plus nécessaire.

Commencer l'édition de l'historique à partir de la révision 3 :

hg histedit -r 3

Un éditeur s'ouvre, contenant la liste des révisions, avec des actions spécifiques spécifiées :

choisissez 5339bf82f0ca 3 Zworgle le foobar
choisissez 8ef592ce7cc4 4 Bedazzle le zerlog
choisissez 0a9639fcda9d 5 Morgifiez la cromulance

Des informations supplémentaires sur les actions possibles à entreprendre apparaissent sous la liste des
révisions.

Pour supprimer la révision 3 de l'historique, son action (au début de la
line) est remplacé par 'drop' :

déposer 5339bf82f0ca 3 Zworgle le foobar
choisissez 8ef592ce7cc4 4 Bedazzle le zerlog
choisissez 0a9639fcda9d 5 Morgifiez la cromulance

· Un certain nombre de modifications ont été apportées. Les révisions 2 et 4 doivent être échangées.

Commencer l'édition de l'historique à partir de la révision 2 :

hg histedit -r 2

Un éditeur s'ouvre, contenant la liste des révisions, avec des actions spécifiques spécifiées :

choisissez 252a1af424ad 2 Blorb a morgwazzle
choisissez 5339bf82f0ca 3 Zworgle le foobar
choisissez 8ef592ce7cc4 4 Bedazzle le zerlog

Pour permuter les révisions 2 et 4, ses lignes sont permutées dans l'éditeur :

choisissez 8ef592ce7cc4 4 Bedazzle le zerlog
choisissez 5339bf82f0ca 3 Zworgle le foobar
choisissez 252a1af424ad 2 Blorb a morgwazzle

Renvoie 0 en cas de succès, 1 si l'intervention de l'utilisateur est requise (pas seulement pour une "modification" intentionnelle
commande, mais aussi pour résoudre des conflits inattendus).

Options:

--commandes
lire les modifications de l'historique à partir du fichier spécifié

-c, --Continuez
continuer une modification déjà en cours

--modifier-plan
modifier la liste des actions restantes

-k, --garder
ne supprimez pas les anciens nœuds une fois la modification terminée

--avorter
abandonner une édition en cours

-o, --sortant
ensembles de modifications introuvables dans la destination

-F, --Obliger
forcer la sortie même pour les référentiels non liés

-r,--tour
première révision à éditer

L'option marquée [+] peut être spécifiée plusieurs fois

mot-clé
développer les mots-clés dans les fichiers suivis

Cette extension étend les $Keywords$ de type RCS/CVS ou auto-personnalisés dans les fichiers texte suivis
sélectionné par votre configuration.

Les mots clés ne sont développés que dans les référentiels locaux et ne sont pas stockés dans l'historique des modifications. Le
mécanisme peut être considéré comme une commodité pour l'utilisateur actuel ou pour l'archivage
distribution.

Les mots-clés s'étendent aux données de l'ensemble de modifications relatives à la dernière modification relative à la
répertoire de travail parent de chaque fichier.

La configuration se fait dans les sections [keyword], [keywordset] et [keywordmaps] de hgrc
fichiers.

Mise en situation :

[mot-clé]
# développe les mots-clés dans chaque fichier python sauf ceux correspondant à "x*"
**.py =
x* = ignorer

[jeu de mots clés]
# préférez les cartes de mots-clés par défaut de type svn plutôt que cvs
svn = Vrai

Remarque Plus vous êtes précis dans vos modèles de nom de fichier, moins vous perdez de la vitesse dans d'énormes
référentiels.

Pour le mappage de modèles [keywordmaps] et la démonstration d'expansion et l'exécution de contrôle hg kwdemo.
See hg aider modèles pour obtenir la liste des modèles et filtres disponibles.

Trois filtres de modèle de date supplémentaires sont fournis :

mise à jour

"2006/09/18 15:13:13"

svnutcdate

"2006-09-18 15:13:13Z"

svnisodate

"2006-09-18 08:13:13 -700 (lundi 18 septembre 2006)"

Les mappages de modèles par défaut (affichage avec hg kwdemo -d) peut être remplacé par personnalisé
mots-clés et modèles. Encore une fois, cours hg kwdemo pour contrôler les résultats de votre configuration
changements.

Avant de modifier/désactiver des mots-clés actifs, vous devez exécuter hg kwshrink pour éviter de stocker
mots-clés étendus dans l'historique des modifications.

Pour forcer l'expansion après l'avoir activée, ou un changement de configuration, exécutez hg kwexpand.

Les extensions s'étendant sur plus d'une ligne et les extensions incrémentielles, comme $Log$ de CVS, sont
non supporté. Un modèle de mappage de mots clés "Log = {desc}" s'étend jusqu'à la première ligne du
description de l'ensemble de modifications.

Commandes
kwdemo
print [keywordmaps] configuration et un exemple d'extension :

hg kwdemo [-d] [-f RCFILE] [TEMPLATEMAP]...

Affichez les cartes de modèles de mots clés actuels, personnalisés ou par défaut et leurs extensions.

Étendez la configuration actuelle en spécifiant des cartes comme arguments et en utilisant -f/--rcfile pour
source un fichier hgrc externe.

Utilisez -d/--default pour désactiver la configuration actuelle.

See hg aider modèles pour plus d'informations sur les modèles et les filtres.

Options:

-ré, --défaut
afficher les cartes de modèles de mots clés par défaut

-F,--rcfile
lire les cartes de rcfile

kwexpand
développez les mots-clés dans le répertoire de travail :

hg kwexpand [OPTION]... [FICHIER]...

Exécuter après (ré)activation de l'expansion des mots clés.

kwexpand refuse de s'exécuter si des fichiers donnés contiennent des modifications locales.

Options:

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

fichiers kw
afficher les fichiers configurés pour l'expansion des mots clés :

hg kwfiles [OPTION]... [FICHIER]...

Répertorier les fichiers du répertoire de travail correspondant à la configuration [mot clé]
modèles

Utile pour empêcher l'expansion involontaire des mots-clés et pour accélérer l'exécution en incluant
seuls les fichiers réellement candidats à l'expansion.

See hg aider mot-clé sur la façon de construire des modèles à la fois pour l'inclusion et l'exclusion de
fichiers.

Avec -A/--all et -v/--verbose les codes utilisés pour afficher l'état des fichiers sont :

K = candidat à l'expansion des mots clés
k = candidat à l'extension du mot clé (non suivi)
je = ignoré
i = ignoré (non suivi)

Options:

-UNE, --tout
afficher les indicateurs d'état des mots clés de tous les fichiers

-je, --ignorer
afficher les fichiers exclus de l'expansion

-tu, --inconnue
afficher uniquement les fichiers inconnus (non suivis)

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

kwshrink
rétablir les mots-clés étendus dans le répertoire de travail :

hg kwshrink [OPTION]... [FICHIER]...

Doit être exécuté avant de modifier/désactiver les mots clés actifs.

kwshrink refuse de s'exécuter si des fichiers donnés contiennent des modifications locales.

Options:

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

fichiers volumineux
suivre les gros fichiers binaires

Les fichiers binaires volumineux ont tendance à être peu compressibles, peu variables et pas du tout
fusionnable. Ces fichiers ne sont pas gérés efficacement par le format de stockage de Mercurial (revlog),
qui est basé sur des deltas binaires compressés ; stocker de gros fichiers binaires comme d'habitude
Les fichiers Mercurial gaspillent de la bande passante et de l'espace disque et augmentent l'utilisation de la mémoire de Mercurial.
L'extension largefiles résout ces problèmes en ajoutant un client-serveur centralisé
couche au-dessus de Mercurial : les fichiers volumineux vivent dans un central Boutique sortir sur le réseau
quelque part, et vous ne récupérez les révisions dont vous avez besoin que lorsque vous en avez besoin.

largefiles fonctionne en maintenant un "fichier standin" dans .hglf/ pour chaque largefile. Le
Les standins sont petits (41 octets : un hachage SHA-1 plus une nouvelle ligne) et sont suivis par Mercurial.
Les révisions de fichiers volumineux sont identifiées par le hachage SHA-1 de leur contenu, qui s'écrit
au standin. largefiles utilise cet ID de révision pour obtenir/mettre des révisions largefile de/vers
le magasin central. Cela permet d'économiser à la fois de l'espace disque et de la bande passante, puisque vous n'avez pas besoin de
récupérer toutes les révisions historiques des fichiers volumineux lorsque vous clonez ou extrayez.

Pour démarrer un nouveau référentiel ou ajouter de nouveaux fichiers binaires volumineux, ajoutez simplement --large à votre hg ajouter
commander. Par exemple:

$ dd if=/dev/urandom of=nombre de données aléatoires=2000
$hg add --large données aléatoires
$ hg commit -m 'ajoute des données aléatoires en tant que fichier volumineux'

Lorsque vous poussez un ensemble de modifications qui ajoute/modifie des fichiers volumineux à un référentiel distant, son
les révisions de fichier volumineux seront téléchargées avec lui. Notez que la télécommande Mercurial doit
avoir également l'extension largefiles activée pour que cela fonctionne.

Lorsque vous extrayez un ensemble de modifications qui affecte les fichiers volumineux à partir d'un référentiel distant, les fichiers volumineux
car l'ensemble de modifications ne sera pas supprimé par défaut. Cependant, lorsque vous mettez à jour vers un tel
révision, tous les fichiers volumineux nécessaires à cette révision sont téléchargés et mis en cache (s'ils ont
jamais été téléchargé auparavant). Une façon d'extraire des fichiers volumineux lors de l'extraction consiste donc à utiliser
--update, qui mettra à jour votre copie de travail avec la dernière révision extraite (et donc
téléchargement de nouveaux fichiers volumineux).

Si vous souhaitez extraire des fichiers volumineux dont vous n'avez pas encore besoin pour la mise à jour, vous pouvez utiliser pull avec
le --lfrev option ou le hg lfpull commander.

Si vous savez que vous tirez d'un emplacement autre que celui par défaut et que vous souhaitez télécharger tous les
largefiles qui correspondent aux nouveaux changesets en même temps, alors vous pouvez tirer avec
--lfrev "tiré()".

Si vous voulez juste vous assurer que vous aurez les fichiers volumineux nécessaires pour fusionner ou rebaser
avec de nouvelles têtes que vous tirez, alors vous pouvez tirer avec --lfrev "tête (tiré())" drapeau
pour télécharger de manière préventive tous les fichiers volumineux qui sont nouveaux dans les têtes que vous extrayez.

Gardez à l'esprit que l'accès au réseau peut maintenant être nécessaire pour mettre à jour les ensembles de modifications que vous avez
pas mis à jour auparavant. La nature de l'extension largefiles signifie que la mise à jour est
n'est plus garanti d'être une opération uniquement locale.

Si vous avez déjà de gros fichiers suivis par Mercurial sans l'extension largefiles, vous
devra convertir votre référentiel afin de bénéficier des fichiers volumineux. C'est fait
les hg lfconvertir commander:

$ hg lfconvert --taille 10 ancien dépôt nouveau dépôt

Dans les référentiels qui contiennent déjà des fichiers volumineux, tout nouveau fichier de plus de 10 Mo sera
automatiquement ajouté en tant que fichier volumineux. Pour modifier ce seuil, réglez grands fichiers.minsize in
votre fichier de configuration Mercurial à la taille minimale en mégaoctets pour suivre en tant que fichier volumineux, ou
utilisez l'option --lfsize pour la commande add (également en mégaoctets) :

[gros fichiers]
taille min = 2

$ hg ajouter --lfsize 2

La grands fichiers.patterns L'option de configuration vous permet de spécifier une liste de modèles de noms de fichiers
(voir hg aider motifs) qui doivent toujours être suivis en tant que fichiers volumineux :

[gros fichiers]
motifs =
* .jpg
re:.*\.(png|bmp)$
bibliothèque.zip
contenu/audio/*

Les fichiers qui correspondent à l'un de ces modèles seront ajoutés en tant que fichiers volumineux, quel que soit leur
Taille.

La grands fichiers.minsize ainsi que grands fichiers.patterns les options de configuration seront ignorées pour tout
référentiels ne contenant pas déjà un fichier volumineux. Pour ajouter le premier fichier volumineux à un
référentiel, vous devez le faire explicitement avec l'indicateur --large passé au hg ajouter commander.

Commandes
lfconvertir
convertir un référentiel normal en un référentiel largefiles :

hg lfconvert SOURCE DEST [FICHIER ...]

Convertir le référentiel SOURCE en un nouveau référentiel DEST, identique à SOURCE sauf que
certains fichiers seront convertis en fichiers volumineux : en particulier, tout fichier correspondant à
RECONNAISSANCE or dont la taille est supérieure au seuil de taille minimale est converti en fichier volumineux. Le
taille utilisée pour déterminer s'il faut ou non suivre un fichier en tant que fichier volumineux correspond à la taille du
première version du fichier. La taille minimale peut être spécifiée avec --size ou dans
configuration comme grands fichiers.size.

Après avoir exécuté cette commande, vous devrez vous assurer que les fichiers volumineux sont activés n'importe où
vous avez l'intention de pousser le nouveau référentiel.

Utilisez --to-normal pour reconvertir les fichiers volumineux en fichiers normaux ; après cela, le DEST
référentiel peut être utilisé sans fichiers volumineux du tout.

Options:

-Oui,--Taille
taille minimale (Mo) pour les fichiers à convertir en fichiers volumineux

--À la normale
convertir d'un dépôt de fichiers volumineux en un dépôt normal

lfpull
extrayez les fichiers volumineux pour les révisions spécifiées à partir de la source spécifiée :

hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [SOURCE]

Extrayez les fichiers volumineux référencés à partir des ensembles de modifications locaux mais manquants localement, en tirant
d'un référentiel distant vers le cache local.

Si SOURCE est omis, le chemin 'par défaut' sera utilisé. Voir hg aider urls pour plus d'
</br>L’Information.

Quelques exemples:

· extrayez les fichiers volumineux pour tous les chefs de branche :

hg lfpull -r "head() et non fermé()"

· pull largefiles sur la branche par défaut :

hg lfpull -r "branche (par défaut)"

Options:

-r,--tour
tirez les fichiers volumineux pour ces révisions

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

mq
gérer une pile de correctifs

Cette extension vous permet de travailler avec une pile de correctifs dans un référentiel Mercurial. Ça gère
deux piles de correctifs - tous les correctifs connus et les correctifs appliqués (sous-ensemble de correctifs connus).

Les correctifs connus sont représentés sous forme de fichiers correctifs dans le répertoire .hg/patches. Patchs appliqués
sont à la fois des fichiers correctifs et des ensembles de modifications.

Tâches courantes (utiliser hg aider commander pour plus de détails):

créer un nouveau patch qnew
importer un patch existant qimport

série de patchs d'impression qseries
imprimer les correctifs appliqués

ajouter un correctif connu à la pile appliquée qpush
supprimer le patch de la pile appliquée qpop
actualiser le contenu du patch le plus appliqué qrefresh

Par défaut, mq utilisera automatiquement les correctifs git si nécessaire pour éviter de perdre le mode fichier
modifications, copies d'enregistrements, fichiers binaires ou créations ou suppressions de fichiers vides. Ce comportement
peut être configuré avec :

[m²]
git = auto/garder/oui/non

S'il est défini sur 'keep', mq obéira à la configuration de la section [diff] tout en préservant
git patchs sur qrefresh. Si défini sur 'yes' ou 'no', mq remplacera la section [diff]
et toujours générer des correctifs git ou réguliers, en perdant éventuellement des données dans le second cas.

Il peut être souhaitable que les ensembles de modifications mq soient conservés dans la phase secrète (voir hg aider phases),
qui peut être activé avec le paramètre suivant :

[m²]
secret = Vrai

Vous gérerez par défaut une file d'attente de correctifs nommée "correctifs". Vous pouvez en créer d'autres,
files d'attente de correctifs indépendantes avec hg file d'attente commander.

Si le répertoire de travail contient des fichiers non validés, qpush, qpop et qgoto abandonnent
immédiatement. Si -f/--force est utilisé, les modifications sont ignorées. Paramètre:

[m²]
keepchanges = Vrai

faites-les se comporter comme si --keep-changes était passé, et les changements locaux non conflictuels seront
être toléré et préservé. Si des options incompatibles telles que -f/--force ou --exact sont
passé, ce paramètre est ignoré.

Cette extension servait à fournir une commande strip. Cette commande vit maintenant dans la bande
extension.

Commandes
qappliqué
imprimez les patchs déjà appliqués :

hg qappliqué [-1] [-s] [PATCH]

Renvoie 0 en cas de succès.

Options:

-1, --dernier
afficher uniquement le correctif appliqué précédent

-Oui, --sommaire
imprimer la première ligne de l'en-tête du patch

qclone
clonez le référentiel principal et le référentiel de correctifs en même temps :

hg qclone [OPTION]... SOURCE [DEST]

Si la source est locale, la destination n'aura pas de correctifs appliqués. Si la source est distante, cela
la commande ne peut pas vérifier si les correctifs sont appliqués dans la source, donc ne peut pas garantir que les correctifs
ne sont pas appliqués dans la destination. Si vous clonez un référentiel distant, assurez-vous avant qu'il a
aucun patch appliqué.

Le référentiel de correctifs source est recherché dans /.hg/patches par défaut. Utilisez -p pour
changer.

Le répertoire des correctifs doit être un référentiel Mercurial imbriqué, tel qu'il serait créé par hg init
--mq.

Renvoie 0 en cas de succès.

Options:

--tirer utiliser le protocole pull pour copier les métadonnées

-U, --Pas de mise à jour
ne pas mettre à jour les nouveaux répertoires de travail

--non compressé
utiliser un transfert non compressé (rapide sur LAN)

-p,--correctifs
emplacement du référentiel de correctifs source

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

qcommit
valider les modifications dans le référentiel de file d'attente (obsolète) :

hg qcommit [OPTION]... [FICHIER]...

Cette commande est obsolète ; utiliser hg commettre --mq à la place.

Options:

-UNE, --Ajouter enlever
marquer les fichiers nouveaux/manquants comme ajoutés/supprimés avant de valider

--fermer-branche
marquer une tête de branche comme fermée

--modifier
modifier le parent du répertoire de travail

-Oui, --secrète
utiliser la phase secrète pour s'engager

-e, --modifier
invoquer l'éditeur sur les messages de validation

-je, --interactif
utiliser le mode interactif

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

-S, --sous-dépôt
récursif dans les sous-référentiels

L'option marquée [+] peut être spécifiée plusieurs fois

alias : qci

qsupprimer
supprimer les correctifs de la file d'attente :

hg qdelete [-k] [PATCH]...

Les correctifs ne doivent pas être appliqués et au moins un correctif est requis. Patch exact
des identifiants doivent être fournis. Avec -k/--keep, les fichiers de patch sont conservés dans le patch
répertoire.

Pour arrêter la gestion d'un patch et le déplacer dans l'historique permanent, utilisez le bouton hg finition commander.

Options:

-k, --garder
conserver le fichier de correctif

-r,--tour
arrêter de gérer une révision (OBSOLÈTE)

L'option marquée [+] peut être spécifiée plusieurs fois

alias : qremove qrm

qdiff
diff du patch actuel et modifications ultérieures :

hg qdiff [OPTION]... [FICHIER]...

Affiche un diff qui inclut le patch actuel ainsi que toutes les modifications qui ont été apportées
dans le répertoire de travail depuis la dernière actualisation (montrant ainsi ce que le patch actuel serait
devenir après un qrefresh).

Utilisez hg diff si vous ne voulez voir que les changements effectués depuis le dernier qrefresh, ou hg Exporter
coton tige si vous souhaitez voir les modifications apportées par le patch actuel sans inclure les modifications apportées
depuis le qrefresh.

Renvoie 0 en cas de succès.

Options:

-une, --texte
traiter tous les fichiers comme du texte

-g, --git
utiliser le format de diff étendu git

--nodate
omettre les dates des en-têtes diff

--pas de préfixe
omettre les préfixes a/ et b/ des noms de fichiers

-p, --show-fonction
montrer dans quelle fonction se trouve chaque changement

--sens inverse
produire un diff qui annule les changements

-w, --ignore-tout-espace
ignorer les espaces blancs lors de la comparaison de lignes

-b, --ignore-changement d'espace
ignorer les changements dans la quantité d'espace blanc

-B, --ignore-lignes-vides
ignorer les modifications dont toutes les lignes sont vides

-U,--unifié
nombre de lignes de contexte à afficher

--stat sortie résumé des modifications de style diffstat

--racine
produire des différences relatives au sous-répertoire

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

finition
déplacer les correctifs appliqués dans l'historique du référentiel :

hg qfinir [-a] [REV]...

Termine les révisions spécifiées (correspondant aux correctifs appliqués) en les déplaçant hors de
mq control dans l'historique régulier du référentiel.

Accepte une plage de révision ou l'option -a/--appliquée. Si --applied est spécifié, tous
les révisions mq appliquées sont supprimées du contrôle mq. Sinon, les révisions données doivent être
à la base de la pile de patchs appliqués.

Cela peut être particulièrement utile si vos modifications ont été appliquées à un dépôt en amont,
ou si vous êtes sur le point de pousser vos modifications en amont.

Renvoie 0 en cas de succès.

Options:

-une, --appliqué
terminer tous les ensembles de modifications appliqués

qfold
plier les patchs nommés dans le patch actuel :

hg qfold [-e] [-k] [-m TEXTE] [-l FICHIER] PATCH...

Les correctifs ne doivent pas encore être appliqués. Chaque patch sera successivement appliqué au
patch dans l'ordre indiqué. Si tous les correctifs s'appliquent correctement, le correctif actuel sera
actualisé avec le nouveau patch cumulatif, et les patchs pliés seront supprimés. Avec
-k/--keep, les fichiers de patch pliés ne seront pas supprimés par la suite.

L'en-tête de chaque patch replié sera concaténé avec l'en-tête de patch actuel,
séparés par une ligne de * * *.

Renvoie 0 en cas de succès.

Options:

-e, --modifier
invoquer l'éditeur sur les messages de validation

-k, --garder
conserver les fichiers de patch pliés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

qgoto
push ou pop patchs jusqu'à ce que le patch nommé soit en haut de la pile :

hg qaller à [OPTION]... PATCH

Renvoie 0 en cas de succès.

Options:

--Notez les changements
tolérer des changements locaux non conflictuels

-F, --Obliger
écraser les modifications locales

--pas de sauvegarde
ne pas enregistrer de copies de sauvegarde des fichiers

qguard
définir ou imprimer des gardes pour un patch :

hg qguard [-l] [-n] [PATCH] [-- [+GUARD]... [-GUARD]...]

Les gardes contrôlent si un patch peut être poussé. Un patch sans gardes est toujours poussé. UN
patch avec une garde positive ("+foo") n'est poussé que si le hg qselect la commande a
l'a activé. Un patch avec une garde négative ("-foo") n'est jamais poussé si le hg qselect
commande l'a activé.

Sans arguments, affiche les gardes actuellement actifs. Avec des arguments, placez des gardes pour le
patch nommé.

Remarque La spécification de gardes négatives nécessite désormais '--'.

Pour définir des gardes sur un autre patch :

hg qguard autre.patch -- +2.6.17 -stable

Renvoie 0 en cas de succès.

Options:

-l, --liste
lister tous les patchs et gardes

-n, --rien
baissez tous les gardes

en-tête
imprime l'en-tête du patch le plus haut ou spécifié :

hg qheader [PATCH]

Renvoie 0 en cas de succès.

qimporter
importer un correctif ou un ensemble de modifications existant :

hg qimport [-e] [-n NOM] [-f] [-g] [-P] [-r REV]... [FICHIER]...

Le patch est inséré dans la série après le dernier patch appliqué. Si aucun patch n'a
été appliqué, qimport ajoute le correctif à la série.

Le patch aura le même nom que son fichier source à moins que vous ne lui en donniez un nouveau avec
-n/--nom.

Vous pouvez enregistrer un correctif existant dans le répertoire des correctifs avec l'indicateur -e/--existing.

Avec -f/--force, un patch existant du même nom sera écrasé.

Un ensemble de modifications existant peut être placé sous contrôle mq avec -r/--rev (par exemple qimport --rev .
-n patch placera la révision actuelle sous contrôle mq). Avec -g/--git, patchs
importé avec --rev utilisera le format git diff. Voir la rubrique d'aide des diffs pour plus d'informations
pourquoi c'est important pour conserver les informations de renommage/copie et les changements d'autorisation.
Utilisez hg finition pour supprimer les ensembles de modifications de mq control.

Pour importer un patch depuis l'entrée standard, passez - comme fichier de patch. Lors de l'importation de
entrée standard, un nom de correctif doit être spécifié à l'aide de l'indicateur --name.

Pour importer un patch existant tout en le renommant :

hg qimport -e patch-existant -n nouveau-nom

Renvoie 0 si l'importation a réussi.

Options:

-e, --existant
importer le fichier dans le répertoire des patchs

-n,--Nom
nom du fichier correctif

-F, --Obliger
écraser les fichiers existants

-r,--tour
placer les révisions existantes sous contrôle mq

-g, --git
utiliser le format de diff étendu git

-P, --pousser
qpush après importation

L'option marquée [+] peut être spécifiée plusieurs fois

qinit
init un nouveau référentiel de file d'attente (OBSOLÈTE):

hg qinit [-c]

Le référentiel de file d'attente n'est pas versionné par défaut. Si -c/--create-repo est spécifié, qinit
créera un référentiel imbriqué séparé pour les correctifs (qinit -c peut également être exécuté ultérieurement pour
convertir un référentiel de correctifs non versionné en un référentiel versionné). Vous pouvez utiliser qcommit pour
valider les modifications dans ce référentiel de file d'attente.

Cette commande est obsolète. Sans -c, il est impliqué par d'autres commandes pertinentes. Avec -c,
utilisé hg init --mq à la place.

Options:

-c, --create-dépôt
créer un référentiel de file d'attente

qnouveau
créer un nouveau patch :

hg qnouveau [-e] [-m TEXTE] [-l FICHIER] PATCH [FICHIER]...

qnew crée un nouveau patch au-dessus du patch actuellement appliqué (le cas échéant). Le patch sera
initialisé avec toutes les modifications en suspens dans le répertoire de travail. Vous pouvez également utiliser
-I/--include, -X/--exclude et/ou une liste de fichiers après le nom du patch à ajouter uniquement
modifications apportées aux fichiers correspondants au nouveau correctif, laissant le reste en tant que modifications non validées.

-u/--user et -d/--date peuvent être utilisés pour définir respectivement l'utilisateur (donné) et la date.
-U/--currentuser et -D/--currentdate définissent l'utilisateur sur l'utilisateur actuel et la date sur la date actuelle.

-e/--edit, -m/--message ou -l/--logfile définissent l'en-tête du patch ainsi que le commit
message. Si aucun n'est spécifié, l'en-tête est vide et le message de validation est '[mq] :
CORRECTIF'.

Utilisez l'option -g/--git pour conserver le patch au format git diff étendu. Lire les différences
rubrique d'aide pour plus d'informations sur les raisons pour lesquelles cela est important pour conserver les modifications d'autorisation
et copier/renommer les informations.

Renvoie 0 en cas de création réussie d'un nouveau patch.

Options:

-e, --modifier
invoquer l'éditeur sur les messages de validation

-F, --Obliger
importer des modifications non validées (obsolète)

-g, --git
utiliser le format de diff étendu git

-U, --utilisateur actuel
ajouter "De : " patcher

-tu,--utilisateur
ajouter "De : " patcher

-RÉ, --date actuelle
ajouter "Date : " patcher

-ré,--Date
ajouter "Date : " patcher

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

L'option marquée [+] peut être spécifiée plusieurs fois

Qnext
imprimer le nom du prochain patch pushable :

hg qsuivant [-s]

Renvoie 0 en cas de succès.

Options:

-Oui, --sommaire
imprimer la première ligne de l'en-tête du patch

qpop
retirer le patch actuel de la pile :

hg qpop [-a] [-f] [PATCH | INDICE]

Sans argument, apparaît en haut de la pile de correctifs. Si un nom de patch lui est attribué, conserve
supprimer les patchs jusqu'à ce que le patch nommé soit en haut de la pile.

Par défaut, abandonnez si le répertoire de travail contient des modifications non validées. Avec
--keep-changes, n'abandonne que si les fichiers non validés chevauchent des fichiers corrigés. Avec
-f/--force, sauvegarde et annule les modifications apportées à ces fichiers.

Renvoie 0 en cas de succès.

Options:

-une, --tout
pop tous les correctifs

-n,--Nom
nom de la file d'attente à afficher (OBSOLÈTE)

--Notez les changements
tolérer des changements locaux non conflictuels

-F, --Obliger
oublier les modifications locales apportées aux fichiers corrigés

--pas de sauvegarde
ne pas enregistrer de copies de sauvegarde des fichiers

qpréc
imprimer le nom du patch appliqué précédent :

hg qprév [-s]

Renvoie 0 en cas de succès.

Options:

-Oui, --sommaire
imprimer la première ligne de l'en-tête du patch

q push
poussez le patch suivant sur la pile :

hg qpush [-f] [-l] [-a] [--move] [PATCH | INDICE]

Par défaut, abandonnez si le répertoire de travail contient des modifications non validées. Avec
--keep-changes, n'abandonne que si les fichiers non validés chevauchent des fichiers corrigés. Avec
-f/--force, sauvegarde et correctif sur les modifications non validées.

Renvoie 0 en cas de succès.

Options:

--Notez les changements
tolérer des changements locaux non conflictuels

-F, --Obliger
appliquer en plus des modifications locales

-e, --exact
appliquer le patch cible à son parent enregistré

-l, --liste
lister le nom du correctif dans le texte de validation

-une, --tout
appliquer tous les correctifs

-m, --fusionner
fusionner à partir d'une autre file d'attente (obsolète)

-n,--Nom
nom de la file d'attente de fusion (obsolète)

--mouvement réorganiser la série de correctifs et appliquer uniquement le correctif

--pas de sauvegarde
ne pas enregistrer de copies de sauvegarde des fichiers

file d'attente
gérer plusieurs files d'attente de correctifs :

hg qqueue [OPTION] [FILE D'ATTENTE]

Prend en charge la commutation entre différentes files d'attente de correctifs, ainsi que la création de nouvelles files d'attente de correctifs
et en supprimant ceux qui existent déjà.

Omettre un nom de file d'attente ou spécifier -l/--list vous montrera les files d'attente enregistrées - en
par défaut, la file d'attente "normale" des correctifs est enregistrée. La file d'attente actuellement active sera
marqué par "(actif)". Spécifier --active n'imprimera que le nom de la file d'attente active.

Pour créer une nouvelle file d'attente, utilisez -c/--create. La file d'attente est automatiquement rendue active, sauf dans
le cas où des correctifs sont appliqués à partir de la file d'attente actuellement active dans le
dépôt. Ensuite, la file d'attente sera uniquement créée et la commutation échouera.

Pour supprimer une file d'attente existante, utilisez --delete. Vous ne pouvez pas supprimer la file d'attente actuellement active.

Renvoie 0 en cas de succès.

Options:

-l, --liste
lister toutes les files d'attente disponibles

--actif
imprimer le nom de la file d'attente active

-c, --créer
créer une nouvelle file d'attente

--Renommer
renommer la file d'attente active

--effacer
supprimer la référence à la file d'attente

--purge
supprimer la file d'attente et supprimer le répertoire des correctifs

qactualiser
mettre à jour le patch actuel :

hg qrefresh [-I] [-X] [-e] [-m TEXTE] [-l FICHIER] [-s] [FICHIER]...

Si des modèles de fichiers sont fournis, le correctif actualisé ne contiendra que les modifications
qui correspondent à ces modèles ; les modifications restantes resteront dans le travail
répertoire.

Si -s/--short est spécifié, les fichiers actuellement inclus dans le correctif seront actualisés juste
comme les fichiers correspondants et restent dans le patch.

Si -e/--edit est spécifié, Mercurial démarrera votre éditeur configuré pour que vous saisissiez un
message. En cas d'échec de qrefresh, vous trouverez une sauvegarde de votre message dans
.hg/dernier-message.txt.

hg ajouter/supprimer/copier/renommer fonctionne comme d'habitude, bien que vous souhaitiez peut-être utiliser des correctifs de style git
(-g/--git ou [diff] git=1) pour suivre les copies et les renommer. Voir le sujet d'aide des diffs pour plus d'informations
informations sur le format git diff.

Renvoie 0 en cas de succès.

Options:

-e, --modifier
invoquer l'éditeur sur les messages de validation

-g, --git
utiliser le format de diff étendu git

-Oui, --court
actualiser uniquement les fichiers déjà dans le correctif et les fichiers spécifiés

-U, --utilisateur actuel
ajouter/mettre à jour le champ auteur dans le patch avec l'utilisateur actuel

-tu,--utilisateur
ajouter/mettre à jour le champ auteur dans le patch avec un utilisateur donné

-RÉ, --date actuelle
ajouter/mettre à jour le champ de date dans le patch avec la date actuelle

-ré,--Date
ajouter/mettre à jour le champ de date dans le patch avec la date donnée

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

L'option marquée [+] peut être spécifiée plusieurs fois

renommer
renommer un patch :

hg qrename PATCH1 [PATCH2]

Avec un argument, renomme le patch actuel en PATCH1. Avec deux arguments, renomme
PATCH1 à PATCH2.

Renvoie 0 en cas de succès.

alias : qmv

qrestaurer
restaurer l'état de la file d'attente enregistré par une révision (OBSOLÈTE) :

hg qrestore [-d] [-u] RÉV

Cette commande est obsolète, utilisez hg rebasement à la place.

Options:

-ré, --effacer
supprimer enregistrer l'entrée

-tu, --mettre à jour
mettre à jour le répertoire de travail de la file d'attente

qsave
enregistrer l'état actuel de la file d'attente (obsolète) :

hg qsave [-m TEXTE] [-l FICHIER] [-c] [-n NOM] [-e] [-f]

Cette commande est obsolète, utilisez hg rebasement à la place.

Options:

-c, --copie
copier le répertoire des correctifs

-n,--Nom
copier le nom du répertoire

-e, --vide
effacer le fichier d'état de la file d'attente

-F, --Obliger
forcer la copie

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

qselect
définir ou imprimer des correctifs protégés pour pousser :

hg qsélectionnez [OPTION]... [GARDE]...

Utilisez l'option hg qguard commande pour définir ou imprimer des gardes sur le patch, puis utilisez qselect pour indiquer à mq
quelles protections utiliser. Un patch sera poussé s'il n'a pas de gardes ou de gardes positifs
correspond à la garde actuellement sélectionnée, mais ne sera pas poussé si des gardes négatives correspondent
la garde actuelle. Par exemple:

qguard foo.patch -- -stable (garde négative)
qguard bar.patch +stable (garde positive)
qselect stable

Cela active la garde "stable". mq ignorera foo.patch (parce qu'il a un négatif
match) mais appuyez sur bar.patch (car il a une correspondance positive).

Sans arguments, imprime les gardes actuellement actifs. Avec un argument, définit l'actif
garde.

Utilisez -n/--none pour désactiver les gardes (aucun autre argument n'est nécessaire). Lorsqu'il n'y a pas de gardes
actifs, les patchs avec des gardes positives sont ignorés et les patchs avec des gardes négatives sont
poussé.

qselect peut changer les gardes sur les patchs appliqués. Il ne fait pas apparaître les patchs gardés par
défaut. Utilisez --pop pour revenir au dernier patch appliqué qui n'est pas protégé. Utilisation
--reapply (ce qui implique --pop) pour revenir ensuite au patch actuel, mais ignorer
patchs gardés.

Utilisez -s/--series pour imprimer une liste de tous les gardes dans le fichier de série (pas d'autres arguments
nécessaire). Utilisez -v pour plus d'informations.

Renvoie 0 en cas de succès.

Options:

-n, --rien
désactiver tous les gardes

-Oui, --séries
lister tous les gardes dans le fichier de série

--populaire pop à avant le premier patch appliqué gardé

--réappliquer
pop, puis réappliquez les correctifs

série q
imprimez tout le fichier de la série :

hg série q [-ms]

Renvoie 0 en cas de succès.

Options:

-m, --disparu
patchs d'impression pas en série

-Oui, --sommaire
imprimer la première ligne de l'en-tête du patch

qtop
imprimer le nom du patch courant :

hg qtop [-s]

Renvoie 0 en cas de succès.

Options:

-Oui, --sommaire
imprimer la première ligne de l'en-tête du patch

qunappliqué
imprimez les patchs pas encore appliqués :

hg qunappliqué [-1] [-s] [PATCH]

Renvoie 0 en cas de succès.

Options:

-1, --premier
afficher uniquement le premier patch

-Oui, --sommaire
imprimer la première ligne de l'en-tête du patch

notifier
crochets pour l'envoi de notifications push par e-mail

Cette extension implémente des crochets pour envoyer des notifications par e-mail lorsque des ensembles de modifications sont envoyés à partir de
ou reçu par le référentiel local.

Tout d'abord, activez l'extension comme expliqué dans hg aider extensions, et enregistrez le crochet que vous
envie de courir. nouveau ainsi que changer de groupe les crochets sont exécutés lorsque les ensembles de modifications sont reçus, tandis que
sortant les crochets sont pour les ensembles de modifications envoyés à un autre référentiel :

[crochets]
# un e-mail pour chaque ensemble de modifications entrant
entrant.notify = python:hgext.notify.hook
# un e-mail pour tous les ensembles de modifications entrants
changegroup.notify = python:hgext.notify.hook

# un e-mail pour tous les ensembles de modifications sortants
sortant.notify = python:hgext.notify.hook

Cela enregistre les crochets. Pour activer la notification, les abonnés doivent être affectés à
dépôts. La [abonnés utilisateurs] mappe plusieurs référentiels à un destinataire donné. La
[dépôts] mappe plusieurs destinataires à un seul référentiel :

[abonnés utilisateurs]
# la clé est l'adresse e-mail de l'abonné, la valeur est une liste de modèles de dépôt séparés par des virgules
utilisateur@hôte = modèle

[dépôts]
# la clé est un modèle de dépôt, la valeur est une liste d'e-mails d'abonnés séparés par des virgules
modèle = utilisateur @ hôte

A modèle est une glob correspondant au chemin absolu vers un référentiel, éventuellement combiné avec un
expression revset. Une expression revset, si elle est présente, est séparée du glob par un hachage.
Mise en situation :

[dépôts]
*/widgets#branch(version) = [email protected]

Cela envoie à [email protected] chaque fois qu'un changeset sur le libérer branche déclenche un
notification dans tout référentiel se terminant par widgets.

Afin de les placer sous la gestion directe des utilisateurs, [abonnés utilisateurs] ainsi que [dépôts] les sections
peut être placé dans un endroit séparé hgrc fichier et incorporé par référence :

[notifier]
config = /chemin/vers/fichier d'abonnements

Les notifications ne seront pas envoyées avant le notifier.test la valeur est définie sur Faux; voir ci-dessous.

Le contenu des notifications peut être modifié avec les entrées de configuration suivantes :

notifier.test
If Vrai, imprime les messages sur stdout au lieu de les envoyer. Par défaut : Vrai.

notifier.les sources
Liste des sources de changement séparées par des espaces. Les notifications ne sont activées que lorsqu'un
la source du changeset est dans cette liste. Les sources peuvent être :

besoin

changesets reçus via http ou ssh

tirer

ensembles de modifications reçus via hg tirer

dégrouper

ensembles de modifications reçus via hg dégrouper

pousser

changesets envoyés ou reçus via hg pousser

pack

ensembles de modifications envoyés via hg dégrouper

Par défaut : servir.

notifier.strip
Nombre de barres obliques à supprimer des chemins d'URL. Par défaut, les notifications
référentiels de référence avec leur chemin absolu. notifier.strip vous permet de les transformer
en chemins relatifs. Par exemple, notifier.strip=3 changera /long/chemin/dépôt
développement dépôt. Par défaut: 0.

notifier.domaine
Domaine de messagerie par défaut pour l'expéditeur ou les destinataires sans domaine explicite.

notifier.style
Fichier de style à utiliser lors du formatage des e-mails.

notifier.modèle
Modèle à utiliser lors du formatage des e-mails.

notifier.entrant
Modèle à utiliser lorsqu'il est exécuté en tant que crochet entrant, remplaçant notifier.modèle.

notifier.sortant
Modèle à utiliser lorsqu'il est exécuté en tant que hook sortant, remplaçant notifier.modèle.

notifier.changegroup
Modèle à utiliser lors de l'exécution en tant que hook de groupe de modification, remplaçant notifier.modèle.

notifier.maxdiff
Nombre maximal de lignes de comparaison à inclure dans l'e-mail de notification. Mettre à 0 pour désactiver
le diff, ou -1 pour tout inclure. Par défaut : 300.

notifier.maxsubject
Nombre maximal de caractères dans la ligne d'objet de l'e-mail. Par défaut : 67.

notifier.diffstat
Défini sur True pour inclure un diffstat avant le contenu diff. Par défaut : Vrai.

notifier.merge
Si True, envoyer des notifications pour les ensembles de modifications de fusion. Par défaut : Vrai.

notifier.mbox
S'il est défini, ajoute les e-mails à ce fichier mbox au lieu de les envoyer. Par défaut : Aucun.

notifier.de l'auteur
Si défini, utilisez le committer du premier ensemble de modifications dans un groupe de modifications pour le "De"
champ de l'e-mail de notification. S'il n'est pas défini, retirez l'utilisateur du référentiel push.
Par défaut : Faux.

Si elles sont définies, les entrées suivantes seront également utilisées pour personnaliser les notifications :

email de
Email Du adresse à utiliser si aucune ne peut être trouvée dans le contenu de l'e-mail généré.

web.baseurl
URL de référentiel racine à combiner avec les chemins de référentiel lors de la création de références. Voir
aussi notifier.strip.

payer
parcourir la sortie de la commande avec un pager externe

Pour définir le pager à utiliser, définissez la variable d'application :

[téléavertisseur]
téléavertisseur = moins -FRX

Si aucun pager n'est défini, les extensions de pager utilisent la variable d'environnement $PAGER. Si ni l'un ni l'autre
pager.pager, ni $PAGER n'est défini, aucun pager n'est utilisé.

Vous pouvez désactiver le pager pour certaines commandes en les ajoutant à la liste pager.ignore :

[téléavertisseur]
ignorer = version, aide, mise à jour

Vous pouvez également activer le pager uniquement pour certaines commandes à l'aide de pager.attend. Ci-dessous le
liste par défaut des commandes à paginer :

[téléavertisseur]
assister = annoter, chat, diff, exporter, glog, journal, qdiff

Si vous définissez pager.attend sur une valeur vide, toutes les commandes seront paginées.

Si pager.attend est présent, pager.ignore sera ignoré.

Enfin, vous pouvez activer et désactiver la pagination pour des commandes individuelles avec le
assister à- option. Ce paramètre a préséance sur l'assistance et l'ignorance existantes
options et valeurs par défaut :

[téléavertisseur]
attend-cat = faux

Pour ignorer les commandes globales comme hg version or hg aider, vous devez les spécifier dans votre
fichier de configuration utilisateur.

Pour contrôler si le téléavertisseur est utilisé pour une commande individuelle, vous pouvez utiliser
--pager= :

- utiliser au besoin : `auto`.
- exiger le téléavertisseur : `yes` ou `on`.
- supprimer le pager : `no` ou `off` (toute valeur non reconnue
fonctionnera également).

bombe à patch
commande pour envoyer des ensembles de modifications sous la forme d'une (série d') e-mails de correctifs

La série commence par une introduction "[PATCH 0 of N]", qui décrit la série
dans son ensemble.

Chaque e-mail de patch a une ligne d'objet "[PATCH M of N] ...", en utilisant la première ligne du
description de l'ensemble de modifications comme texte d'objet. Le message contient deux ou trois parties du corps :

· La description de l'ensemble de modifications.

· [Facultatif] Le résultat de l'exécution de diffstat sur le correctif.

· Le patch lui-même, tel que généré par hg Exporter.

Chaque message fait référence au premier de la série en utilisant In-Reply-To et References
en-têtes, afin qu'ils apparaissent sous forme de séquence dans les fils de discussion et les lecteurs de nouvelles, et dans le courrier
archives.

Pour configurer d'autres valeurs par défaut, ajoutez une section comme celle-ci à votre fichier de configuration :

[e-mail]
de = Mon nom
à = destinataire1, destinataire2, ...
cc = cc1, cc2, ...
cci = cci1, cci2, ...
répondre à = adresse1, adresse2, ...

Utilisez [bombe patch] comme nom de section de configuration si vous devez remplacer global [e-mail]
paramètres d'adresse.

Ensuite, vous pouvez utiliser le hg email commande pour envoyer une série de changesets sous forme de patchbomb.

Vous pouvez également soit configurer l'option de méthode dans la section e-mail pour être un sendmail
mailer compatible ou remplissez la section [smtp] afin que l'extension patchbomb puisse
envoyer automatiquement des patchbombs directement depuis la ligne de commande. Voir le [email] et [smtp]
sections dans hgrc(5) pour plus de détails.

Par défaut, hg email demandera un À or CC en-tête si vous n'en fournissez pas via
configuration ou la ligne de commande. Vous pouvez remplacer cela pour ne jamais demander en configurant
une valeur vide :

[e-mail]
cc =

Vous pouvez contrôler l'inclusion par défaut d'un message d'introduction avec le patchbomb.intro
options de configuration. La configuration est toujours écrasée par des drapeaux de ligne de commande comme
--intro et --desc :

[bombe patch]
intro=auto # inclure le message d'introduction si plus d'un patch (par défaut)
intro=never # ne jamais inclure de message d'introduction
intro=always # inclut toujours un message d'introduction

Vous pouvez configurer patchbomb pour qu'il demande toujours confirmation en définissant patchbomb.confirmer à vrai.

Commandes
email
envoyer les changesets par e-mail :

hg email [OPTION]... [DEST]...

Par défaut, les diffs sont envoyés dans le format généré par hg Exporter, un par message. La
commence par une introduction "[PATCH 0 of N]", qui décrit la série dans son ensemble.

Chaque e-mail de patch a une ligne d'objet "[PATCH M of N] ...", en utilisant la première ligne du
description de l'ensemble de modifications comme texte d'objet. Le message contient deux ou trois parties.
Tout d'abord, la description du changeset.

Avec l'option -d/--diffstat, si le programme diffstat est installé, le résultat de l'exécution
diffstat sur le patch est inséré.

Enfin, le patch lui-même, tel que généré par hg Exporter.

Avec les options -d/--diffstat ou --confirm, un résumé final de
tous les messages et demandé confirmation avant l'envoi des messages.

Par défaut, le correctif est inclus sous forme de texte dans le corps de l'e-mail pour faciliter la lecture. En utilisant le
L'option -a/--attach créera à la place une pièce jointe pour le patch. Avec -i/--inline an
une pièce jointe en ligne sera créée. Vous pouvez inclure un correctif sous forme de texte dans le corps de l'e-mail
et comme pièce jointe régulière ou en ligne en combinant -a/--attach ou -i/--inline avec
l'option --body.

Avec -o/--outgoing, des e-mails seront générés pour les correctifs introuvables dans la destination
référentiel (ou uniquement ceux qui sont les ancêtres des révisions spécifiées, le cas échéant
à condition de)

Avec -b/--bundle, les ensembles de modifications sont sélectionnés comme pour --outgoing, mais un seul e-mail contenant
un bundle Mercurial binaire en pièce jointe sera envoyé. Utilisez le patchbomb.bundletype
option de configuration pour contrôler le type de bundle comme avec hg pack --taper.

Avec -m/--mbox, au lieu de prévisualiser chaque message patchbomb dans un téléavertisseur ou d'envoyer le
messages directement, il créera un fichier de boîte aux lettres UNIX avec les e-mails de correctif. Cette boîte aux lettres
peut être prévisualisé avec n'importe quel agent utilisateur de messagerie prenant en charge les fichiers mbox UNIX.

Avec -n/--test, toutes les étapes seront exécutées, mais le courrier ne sera pas envoyé. Vous serez invité à
une adresse e-mail de destinataire, un sujet et un message d'introduction décrivant les correctifs
de votre bombe patch. Ensuite, lorsque tout est terminé, des messages de patchbomb sont affichés. Si le téléavertisseur
la variable d'environnement est définie, votre pager sera lancé une fois pour chaque message patchbomb,
afin que vous puissiez vérifier que tout va bien.

En cas d'échec de l'envoi de l'e-mail, vous trouverez une sauvegarde de votre message d'introduction de la série dans
.hg/dernier-email.txt.

Le comportement par défaut de cette commande peut être personnalisé via la configuration. (Voir hg aider
bombe à patch pour plus de détails)

Exemples :

hg email -r 3000 # envoyer le patch 3000 uniquement
hg email -r 3000 -r 3001 # envoie les correctifs 3000 et 3001
hg email -r 3000:3005 # envoie les correctifs 3000 à 3005
hg email 3000 # envoyer le patch 3000 (obsolète)

hg email -o # envoie tous les correctifs qui ne sont pas par défaut
hg email -o DEST # envoie tous les correctifs qui ne sont pas dans DEST
hg email -o -r 3000 # envoie tous les ancêtres de 3000 non par défaut
hg email -o -r 3000 DEST # envoie tous les ancêtres de 3000 pas dans DEST

hg email -b # envoie un ensemble de tous les correctifs qui ne sont pas par défaut
hg email -b DEST # envoie un ensemble de tous les correctifs qui ne sont pas dans DEST
hg email -b -r 3000 # bundle de tous les ancêtres de 3000 pas par défaut
hg email -b -r 3000 DEST # bundle de tous les ancêtres de 3000 pas dans DEST

hg email -o -m mbox && # génère un fichier mbox...
mutt -R -f mbox # ... et visualisez-le avec mutt
hg email -o -m mbox && # génère un fichier mbox ...
formail -s sendmail \ # ... et utilisez formail pour envoyer depuis la mbox
-bm -t < mbox # ... en utilisant sendmail

Avant d'utiliser cette commande, vous devrez activer le courrier électronique dans votre hgrc. Voir le [courriel]
section hgrc(5) pour plus de détails.

Options:

-g, --git
utiliser le format de diff étendu git

--plaine
omettre l'en-tête du patch hg

-o, --sortant
envoyer les modifications introuvables dans le référentiel cible

-b, --empaqueter
envoyer les changements qui ne sont pas dans la cible en tant que bundle binaire

--nom du bundle
nom du fichier joint du bundle (par défaut : bundle)

-r,--tour
une révision à envoyer

--Obliger
exécuter même lorsque le référentiel distant n'est pas lié (avec -b/--bundle)

--base
un changeset de base à spécifier au lieu d'une destination (avec -b/--bundle)

--introduction
envoyer un e-mail d'introduction pour un seul patch

--corps envoyer les correctifs sous forme de texte de message en ligne (par défaut)

-une, --attacher
envoyer des correctifs en pièces jointes

-je, --en ligne
envoyer des correctifs en tant que pièces jointes en ligne

--cci
adresses e-mail des destinataires en copie carbone invisible

-c,--cc
adresses e-mail des destinataires de la copie

--confirmer
demander confirmation avant envoi

-ré, --diffstat
ajouter la sortie diffstat aux messages

--Date
utiliser la date indiquée comme date d'envoi

--desc
utiliser le fichier donné comme description de la série

-F,--de
adresse e-mail de l'expéditeur

-n, --test
imprimer les messages qui seraient envoyés

-m,--mbox
écrire des messages dans le fichier mbox au lieu de les envoyer

--répondre à
les adresses e-mail auxquelles les réponses doivent être envoyées

-Oui,--matière
sujet du premier message (intro ou patch unique)

--en réponse à
identifiant du message auquel répondre

--drapeau
drapeaux à ajouter dans les préfixes de sujet

-t,--à
adresses e-mail des destinataires

-e,--ssh
spécifier la commande ssh à utiliser

--remotecmd
spécifier la commande hg à exécuter sur le côté distant

--peu sûr
ne pas vérifier le certificat du serveur (ignorer la configuration web.cacerts)

L'option marquée [+] peut être spécifiée plusieurs fois

purge
commande pour supprimer les fichiers non suivis du répertoire de travail

Commandes
purge
supprime les fichiers non suivis par Mercurial :

hg purge [OPTION]... [DIR]...

Supprimez les fichiers inconnus de Mercurial. Ceci est utile pour tester les modifications locales et non validées
dans une arborescence source par ailleurs propre.

Cela signifie que la purge supprimera les éléments suivants par défaut :

· Fichiers inconnus : fichiers marqués d'un " ?" par hg statuts

· Répertoires vides : en fait Mercurial ignore les répertoires sauf s'ils contiennent des fichiers sous
gestion du contrôle des sources

Mais il laissera intact:

· Fichiers suivis modifiés et non modifiés

· Fichiers ignorés (sauf si --all est spécifié)

· Nouveaux fichiers ajoutés au référentiel (avec hg ajouter)

Les options --files et --dirs peuvent être utilisées pour diriger la purge afin de supprimer uniquement les fichiers, uniquement
répertoires, ou les deux. Si aucune option n'est donnée, les deux seront supprimés.

Si des répertoires sont indiqués sur la ligne de commande, seuls les fichiers de ces répertoires sont
pris en considération.

Soyez prudent avec la purge, car vous pourriez supprimer de manière irréversible certains fichiers que vous avez oublié d'ajouter à
le référentiel. Si vous souhaitez uniquement imprimer la liste des fichiers que ce programme
supprimer, utilisez l'option --print.

Options:

-une, --abandon en cas d'erreur
abandonner si une erreur se produit

--tout purger également les fichiers ignorés

--répertoires purger les répertoires vides

--des dossiers
purger les fichiers

-p, --imprimer
imprimer les noms de fichiers au lieu de les supprimer

-0, --print0
fin des noms de fichiers avec NUL, à utiliser avec xargs (implique -p/--print)

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

alias : nettoyer

rebasement
commande pour déplacer des ensembles de révisions vers un ancêtre différent

Cette extension vous permet de rebaser les ensembles de modifications dans un référentiel Mercurial existant.

Pour plus d'informations : https://mercurial-scm.org/wiki/RebaseExtension

Commandes
rebasement
déplacer l'ensemble de modifications (et ses descendants) vers une autre branche :

hg rebase [-s REV | -b INV] [-d INV] [OPTION]

Rebase utilise des fusions répétées pour greffer des ensembles de modifications d'une partie de l'historique (la source)
sur un autre (la destination). Cela peut être utile pour linéariser locales changements relatifs
à un arbre de développement principal.

Les commits publiés ne peuvent pas être rebasés (voir hg aider phases). Pour copier des commits, voir hg aider
greffer.

Si vous ne spécifiez pas d'ensemble de modifications de destination (-d/--dest), rebase utilise la branche courante
pourboire comme destination. (Le changeset de destination n'est pas modifié par le rebasage, mais le nouveau
les ensembles de modifications sont ajoutés en tant que ses descendants.)

Voici les façons de sélectionner les ensembles de modifications :

1. Sélectionnez-les explicitement en utilisant --tour.

2. Utiliser --la source pour sélectionner un ensemble de modifications racine et inclure tous ses descendants.

3. Utiliser --base pour sélectionner un ensemble de modifications ; rebase trouvera les ancêtres et leurs descendants
qui ne sont pas aussi des ancêtres de la destination.

4. Si vous ne spécifiez aucun des --tour, la sourceou --base, le rebase utilisera --base . as
au dessus.

Rebase détruira les modifications d'origine à moins que vous n'utilisiez --garder. Cela déplacera également votre
signets (même si vous le faites).

Certains ensembles de modifications peuvent être supprimés s'ils ne contribuent pas aux modifications (par exemple, les fusions à partir du
branche de destination).

Contrairement à fusionner, rebase ne fera rien si vous êtes au bout d'une branche nommée avec
deux têtes. Vous devrez spécifier explicitement la source et/ou la destination.

Si un rebase est interrompu pour résoudre manuellement un conflit, il peut être poursuivi avec
--continue/-c ou abandonné avec --abort/-a.

Exemples :

· déplacer les "modifications locales" (validation actuelle vers le point de branchement) vers la pointe de la branche actuelle
après un tirage :

rebase hg

· déplacer un seul ensemble de modifications vers la branche stable :

hg rebase -r 5f493448 -d stable

· coller un commit et tous ses descendants sur une autre partie de l'historique :

hg rebase --source c0c3 --dest 4cf9

· rebaser tout sur une branche marquée par un signet sur la branche par défaut :

hg rebase --base mafonctionnalité --dest par défaut

· réduire une séquence de modifications en un seul commit :

hg rebase --collapse -r 1520:1525 -d .

· déplacer une branche nommée en conservant son nom :

hg rebase -r "branche(entitéX)" -d 1.3 --keepbranches

Renvoie 0 en cas de succès, 1 s'il n'y a rien à rebaser ou s'il y a des conflits non résolus.

Options:

-Oui,--la source
rebase le changeset et les descendants spécifiés

-b,--base
tout rebaser à partir du point de branchement du jeu de modifications spécifié

-r,--tour
rebaser ces révisions

-ré,--dest
rebaser sur l'ensemble de modifications spécifié

--effondrer
réduire les changesets rebasés

-m,--un message
utiliser le texte comme message de validation de repli

-e, --modifier
invoquer l'éditeur sur les messages de validation

-l,--fichier journal
lire le message de validation d'effondrement du fichier

-k, --garder
conserver les modifications d'origine

--garder les branches
conserver les noms de branche d'origine

-RÉ, --détacher
(PÉRIMÉ)

-je, --interactif
(PÉRIMÉ)

-t,--outil
spécifier l'outil de fusion

-c, --Continuez
continuer un rebasage interrompu

-une, --avorter
abandonner un rebasage interrompu

--style
affichage à l'aide d'un fichier de carte modèle (OBSOLÈTE)

-T,--modèle
afficher avec modèle

L'option marquée [+] peut être spécifiée plusieurs fois

record
commandes pour sélectionner interactivement les changements pour commit/qrefresh

Commandes
qenregistrement
enregistrer interactivement un nouveau patch :

hg qrecord [OPTION]... PATCH [FICHIER]...

See hg aider qnouveau & hg aider record pour plus d'informations et d'utilisation.

record
sélectionnez interactivement les modifications à valider :

hg record [OPTION]... [FICHIER]...

Si une liste de fichiers est omise, toutes les modifications signalées par hg statuts seront candidats à
enregistrement.

See hg aider dates pour une liste de formats valides pour -d/--date.

Vous serez invité à indiquer si vous souhaitez enregistrer les modifications apportées à chaque fichier modifié, et pour les fichiers
avec plusieurs changements, pour chaque changement à utiliser. Pour chaque requête, les réponses suivantes sont
possible:

y - enregistrer ce changement
n - ignorer ce changement
e - modifiez ce changement manuellement

s - ignore les modifications restantes dans ce fichier
f - enregistrer les modifications restantes dans ce fichier

d - terminé, ignorez les modifications et les fichiers restants
a - enregistrer toutes les modifications apportées à tous les fichiers restants
q - quitter, enregistrer aucun changement

? - afficher l'aide

Cette commande n'est pas disponible lors de la validation d'une fusion.

Options:

-UNE, --Ajouter enlever
marquer les fichiers nouveaux/manquants comme ajoutés/supprimés avant de valider

--fermer-branche
marquer une tête de branche comme fermée

--modifier
modifier le parent du répertoire de travail

-Oui, --secrète
utiliser la phase secrète pour s'engager

-e, --modifier
invoquer l'éditeur sur les messages de validation

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

-m,--un message
utiliser le texte comme message de validation

-l,--fichier journal
lire le message de validation à partir du fichier

-ré,--Date
enregistrer la date spécifiée comme date de validation

-tu,--utilisateur
enregistrer l'utilisateur spécifié en tant que commiter

-S, --sous-dépôt
récursif dans les sous-référentiels

-w, --ignore-tout-espace
ignorer les espaces blancs lors de la comparaison de lignes

-b, --ignore-changement d'espace
ignorer les changements dans la quantité d'espace blanc

-B, --ignore-lignes-vides
ignorer les modifications dont toutes les lignes sont vides

L'option marquée [+] peut être spécifiée plusieurs fois

relier
recrée les liens physiques entre les clones du référentiel

Commandes
relier
recréer des liens durs entre deux dépôts :

hg relink [ORIGINE]

Lorsque les référentiels sont clonés localement, leurs fichiers de données seront liés en dur afin qu'ils
utiliser uniquement l'espace d'un seul référentiel.

Malheureusement, les extractions ultérieures dans l'un ou l'autre des référentiels rompront les liens physiques pour tous les fichiers
touché par les nouveaux ensembles de modifications, même si les deux référentiels finissent par extraire les mêmes modifications.

De même, passer --rev à "hg clone" n'utilisera aucun lien physique, revenant à un
copie complète du référentiel source.

Cette commande vous permet de recréer ces liens physiques et de récupérer cet espace perdu.

Ce référentiel sera réassocié pour partager l'espace avec ORIGIN, qui doit être sur le même
disque local. Si ORIGIN est omis, recherche "default-relink", puis "default", dans [chemins].

Ne tentez aucune opération de lecture sur ce référentiel pendant l'exécution de la commande. (Tous les deux
les référentiels seront verrouillés contre les écritures.)

Schémas
étendre les schémas avec des raccourcis vers les essaims de référentiels

Cette extension vous permet de spécifier des raccourcis pour les URL parents avec de nombreux référentiels
agir comme un stratagème, par exemple :

[schémas]
pi = http://code.python.org/hg/

Après cela, vous pouvez l'utiliser comme:

hg clone py://trunk/

De plus, certains schémas plus complexes sont pris en charge, par exemple utilisés par Google
Code:

[schémas]
gcode = http://{1}.googlecode.com/hg/

La syntaxe est tirée des modèles Mercurial, et vous avez un nombre illimité de variables,
commençant par 1 {} et continuer avec 2 {}, 3 {} etc. Cette variable recevra
parties de l'URL fournies, divisées par /. Tout ce qui n'est pas spécifié comme {partie} sera juste ajouté
à une URL.

Pour plus de commodité, l'extension ajoute ces schémas par défaut :

[schémas]
pi = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://[email protected]/
gcode = https://{1}.googlecode.com/hg/
four = https://{1}.kilnhg.com/Repo/

Vous pouvez remplacer un schéma prédéfini en définissant un nouveau schéma portant le même nom.

Partager
partager un historique commun entre plusieurs répertoires de travail

Automatique Groupé Stockage en Clones
Lorsque cette extension est active, hg cloner peut être configuré pour partager/regrouper automatiquement
stockage sur plusieurs clones. Ce mode convertit efficacement hg cloner à hg cloner + hg
Partager. L'intérêt de l'utilisation de ce mode est la gestion automatique des parcours magasins et
mutualisation intelligente des référentiels associés.

action. les options de configuration influencent cette fonctionnalité :

partager.pool

Chemin du système de fichiers où les données du référentiel partagé seront stockées. Lorsqu'il est défini, hg cloner
utilisera automatiquement le stockage de référentiel partagé au lieu de créer un magasin à l'intérieur
chaque clone.

partager.poolnaming

Comment les noms de répertoire dans partager.pool sont construits.

"identité" signifie que le nom est dérivé du premier ensemble de modifications du référentiel. Dans
ce mode, différentes télécommandes partagent le stockage si leur ensemble de modifications racine/initial est
identique. Dans ce mode, le référentiel partagé local est un agrégat de tous
référentiels distants rencontrés.

"distant" signifie que le nom est dérivé du chemin ou de l'URL du référentiel source. Dans
ce mode, le stockage n'est partagé que si le chemin ou l'URL demandé dans le hg cloner
correspond exactement à un référentiel qui a été cloné auparavant.

Le mode de nommage par défaut est "identité".

Commandes
Partager
créer un nouveau référentiel partagé :

hg partage [-U] [-B] SOURCE [DEST]

Initialiser un nouveau référentiel et répertoire de travail qui partage son historique (et éventuellement
signets) avec un autre référentiel.

Notez que l'utilisation de rollback ou d'extensions qui détruisent/modifient l'historique (mq, rebase, etc.)
causer une confusion considérable avec les clones partagés. En particulier, si deux partagent
les clones sont tous les deux mis à jour avec le même ensemble de modifications, et l'un d'eux le détruit
changeset avec rollback, l'autre clone cessera soudainement de fonctionner : toutes les opérations
échouera avec "abandon : le répertoire de travail a un parent inconnu". Le seul connu
la solution consiste à utiliser debugsetparents sur le clone cassé pour le réinitialiser à un ensemble de modifications
qui existe encore.

Options:

-U, --Pas de mise à jour
ne pas créer de répertoire de travail

-B, --signets
partager également des signets

ne pas partager
convertir un référentiel partagé en référentiel normal :

hg annuler le partage

Copiez les données du magasin dans le référentiel et supprimez les données du chemin partagé.

ranger
enregistrer et restaurer les modifications dans le répertoire de travail

La commande "hg shelve" enregistre les modifications apportées au répertoire de travail et annule celles
changements, réinitialisant le répertoire de travail à un état propre.

Plus tard, la commande "hg unshelve" restaure les modifications enregistrées par "hg shelve". Les changements peuvent
être restauré même après la mise à jour vers un parent différent, auquel cas la fusion de Mercurial
les machines résoudront les conflits si nécessaire.

Vous pouvez avoir plus d'une modification mise à l'écart en attente à la fois ; chaque changement en attente a un
nom distinct. Pour plus de détails, consultez l'aide de "hg shelve".

Commandes
ranger
enregistrez et mettez de côté les modifications du répertoire de travail :

hg étagère [OPTION]... [FICHIER]...

La mise en rayon prend les fichiers que "hg status" signale comme n'étant pas propres, enregistre les modifications dans un
bundle (un changement mis en veilleuse), et rétablit les fichiers afin que leur état dans le travail
répertoire devient propre.

Pour restaurer ces modifications dans le répertoire de travail, utilisez "hg unshelve" ; cela fonctionnera
même si vous passez à un autre commit.

Lorsqu'aucun fichier n'est spécifié, "hg shelve" enregistre tous les fichiers non nettoyés. Si des fichiers spécifiques ou
répertoires sont nommés, seules les modifications apportées à ces fichiers sont conservées.

Chaque modification mise en attente a un nom qui permet de la retrouver plus facilement par la suite. Le nom d'une étagère
changer les valeurs par défaut pour qu'elles soient basées sur le signet actif, ou s'il n'y a pas de signet actif,
la branche nommée actuelle. Pour spécifier un nom différent, utilisez --Nom.

Pour afficher une liste des modifications mises en réserve existantes, utilisez la --liste option. Pour chaque modification en attente,
cela imprimera son nom, son âge et sa description; utilisation --pièce or --stat pour plus de détails.

Pour supprimer des modifications spécifiques mises en réserve, utilisez --effacer. Pour supprimer toutes les modifications mises en réserve, utilisez
--nettoyer.

Options:

-UNE, --Ajouter enlever
marquer les fichiers nouveaux/manquants comme ajoutés/supprimés avant la mise en rayon

-tu, --inconnue
stocker les fichiers inconnus dans l'étagère

--nettoyer
supprimer toutes les modifications mises en réserve

--Date
étagère avec la date de validation spécifiée

-ré, --effacer
supprimer les modifications mises en réserve nommées

-e, --modifier
invoquer l'éditeur sur les messages de validation

-l, --liste
lister les étagères actuelles

-m,--un message
utiliser le texte comme message d'étagère

-n,--Nom
utiliser le nom donné pour le commit mis à l'écart

-p, --pièce
montrer le patch

-je, --interactif
mode interactif, ne fonctionne que lors de la création d'une étagère

--stat sortie résumé des modifications de style diffstat

-JE,--comprendre
inclure des noms correspondant aux modèles donnés

-X,--exclure
exclure les noms correspondant aux modèles donnés

L'option marquée [+] peut être spécifiée plusieurs fois

déballer
restaurer une modification mise de côté dans le répertoire de travail :

hg retirer l'étagère [ÉTAGÉ]

Cette commande accepte un nom facultatif d'une modification mise en attente à restaurer. Si aucun n'est donné,
la modification mise en attente la plus récente est utilisée.

Si une modification mise en attente est appliquée avec succès, le groupe contenant les modifications mises en attente
est déplacé vers un emplacement de sauvegarde (.hg/shelve-backup).

Étant donné que vous pouvez restaurer une modification mise en veilleuse en plus d'un commit arbitraire, il est possible que
la désétagère entraînera un conflit entre vos modifications et les commits que vous êtes
désétagère sur. Si cela se produit, vous devez résoudre le conflit, puis utiliser --Continuez à
terminer l'opération de désétagère. (Le lot ne sera pas déplacé tant que vous n'aurez pas réussi
terminez la désétagère.)

(Vous pouvez également utiliser --avorter abandonner une désétagère qui provoque un conflit. Cette
annule les modifications non réservées et laisse le bundle en place.)

Après un désarchivage réussi, les modifications mises en attente sont stockées dans un répertoire de sauvegarde. Seulement
les N sauvegardes les plus récentes sont conservées. N est défini par défaut sur 10 mais peut être remplacé à l'aide de la
étagère.maxbackups option de configuration.

L'horodatage en secondes est utilisé pour décider de l'ordre des sauvegardes. Plus que sauvegardes maximales les sauvegardes sont
conservés, si le même horodatage empêche de décider de leur ordre exact, pour des raisons de sécurité.

Options:

-une, --avorter
abandonner une opération de désétagère incomplète

-c, --Continuez
poursuivre une opération de désétagère incomplète

-k, --garder
garder étagère après désétagère

-t,--outil
spécifier l'outil de fusion

--Date
définir la date des commits temporaires (OBSOLÈTE)

bande
supprimer les changesets et leurs descendants de l'histoire

Cette extension vous permet de supprimer les changesets et tous leurs descendants du
dépôt. Voir l'aide de la commande pour plus de détails.

Commandes
bande
supprimez les ensembles de modifications et tous leurs descendants du référentiel :

hg bande [-k] [-f] [-B signet] [-r] REV...

La commande strip supprime les changesets spécifiés et tous leurs descendants. Si la
répertoire de travail contient des modifications non validées, l'opération est abandonnée à moins que le --force
flag est fourni, auquel cas les modifications seront ignorées.

Si un parent du répertoire de travail est supprimé, le répertoire de travail sera
être automatiquement mis à jour avec l'ancêtre disponible le plus récent du parent supprimé
une fois l'opération terminée.

Tous les ensembles de modifications supprimés sont stockés dans .hg/strip-sauvegarde en lot (voir hg aider pack ainsi que
hg aider dégrouper). Ils peuvent être restaurés en exécutant hg dégrouper .hg/strip-backup/BUNDLE,
où BUNDLE est le fichier bundle créé par la bande. Notez que les numéros de révision locaux
sera en général différent après la restauration.

Utilisez l'option --no-backup pour supprimer le bundle de sauvegarde une fois l'opération terminée.

Strip n'est pas une opération de réécriture d'historique et peut être utilisé sur des ensembles de modifications dans le public
phase. Mais si les ensembles de modifications supprimés ont été poussés vers un référentiel distant, vous
probablement les tirer à nouveau.

Renvoie 0 en cas de succès.

Options:

-r,--tour
supprimer la révision spécifiée (facultatif, peut spécifier des révisions sans cette option)

-F, --Obliger
forcer la suppression des ensembles de modifications, supprimer les modifications non validées (pas de sauvegarde)

--pas de sauvegarde
pas de sauvegardes

--pas de sauvegarde
aucune sauvegarde (obsolète)

-n ignoré (obsolète)

-k, --garder
ne pas modifier le répertoire de travail pendant le strip

-B,--signet
supprimer les tours accessibles uniquement à partir d'un signet donné

L'option marquée [+] peut être spécifiée plusieurs fois

transplantation
commande pour transplanter des ensembles de modifications d'une autre branche

Cette extension vous permet de transplanter les modifications dans une autre révision parente, éventuellement dans
un autre dépôt. La greffe se fait à l'aide de patchs 'diff'.

Les patchs transplantés sont enregistrés dans .hg/transplant/transplants, comme une carte d'un ensemble de modifications
hachage à son hachage dans le référentiel source.

Commandes
transplantation
greffer des ensembles de modifications d'une autre branche :

greffe hg [-s REPO] [-b BRANCHE [-a]] [-p REV] [-m REV] [REV]...

Les ensembles de modifications sélectionnés seront appliqués au-dessus du répertoire de travail actuel avec le journal
de l'ensemble de modifications d'origine. Les changesets sont copiés et apparaîtront donc deux fois dans le
histoire avec des identités différentes.

Envisagez d'utiliser la commande greffe si tout se trouve dans le même référentiel - il utilisera
fusionne et donnera généralement un meilleur résultat. Utilisez l'extension rebase si les changesets
ne sont pas publiés et que vous souhaitez les déplacer au lieu de les copier.

Si --log est spécifié, les messages du journal seront accompagnés d'un commentaire de la forme :

(transplanté de CHANGESETHASH)

Vous pouvez réécrire le message du journal des modifications avec l'option --filter. Son argumentation sera
invoqué avec le message actuel du journal des modifications en tant que $1 et le correctif en tant que $2.

--source/-s spécifie un autre référentiel à utiliser pour sélectionner les ensembles de modifications, comme s'il
temporairement avait été retiré. Si --branch/-b est spécifié, ces révisions seront utilisées comme
têtes lors du choix des changesets à transplanter, comme si seules ces révisions avaient
été tiré. Si --all/-a est spécifié, toutes les révisions jusqu'aux têtes spécifiées avec
--la branche sera transplantée.

Mise en situation :

· Transférez toutes les modifications jusqu'à REV en plus de votre révision actuelle :

greffon hg --branche REV --tous

Vous pouvez éventuellement marquer les ensembles de modifications transplantés sélectionnés comme ensembles de modifications de fusion. Tu ne vas pas
être invité à transplanter tous les ancêtres d'une greffe fusionnée, et vous pouvez fusionner
leurs descendants normalement au lieu de les transplanter.

Les ensembles de modifications de fusion peuvent être transplantés directement en spécifiant l'ensemble de modifications parent approprié par
appel hg transplantation --parent.

Si aucune fusion ou révision n'est fournie, hg transplantation lancera un ensemble de modifications interactif
navigateur.

Si une application changeset échoue, vous pouvez corriger la fusion à la main, puis reprendre là où vous
laissé en appelant hg transplantation --continuer/-c.

Options:

-Oui,--la source
greffer des ensembles de modifications à partir de REPO

-b,--branche
utiliser cet ensemble de modifications source comme tête

-une, --tout
tirez tous les ensembles de modifications jusqu'aux révisions --branch

-p,--prune
sauter REV

-m,--fusionner
fusionner à REV

--parent
parent à choisir lors de la transplantation de fusion

-e, --modifier
invoquer l'éditeur sur les messages de validation

--Journal ajouter les informations de transplantation au message de journal

-c, --Continuez
continuer la dernière séance de greffe après avoir résolu les conflits

--filtre
filtrer les ensembles de modifications via la commande

L'option marquée [+] peut être spécifiée plusieurs fois

win32mbcs
permettre l'utilisation de chemins MBCS avec des encodages problématiques

Certains encodages MBCS ne conviennent pas à certaines opérations de chemin (c'est-à-dire le fractionnement du chemin, la casse
conversion, etc.) avec ses octets encodés. Nous appelons un tel encodage (ie shift_jis et
big5) comme "encodage problématique". Cette extension peut être utilisée pour résoudre le problème avec ceux
encodages en enveloppant certaines fonctions à convertir en chaîne Unicode avant l'opération de chemin.

Cette extension est utile pour :

· Utilisateurs japonais de Windows utilisant l'encodage shift_jis.

· Utilisateurs chinois de Windows utilisant l'encodage big5.

· Tous les utilisateurs qui utilisent un référentiel avec l'un des encodages problématiques sur insensible à la casse
système de fichiers.

Cette extension n'est pas nécessaire pour :

· Tout utilisateur qui utilise uniquement des caractères ASCII dans le chemin.

· Tout utilisateur qui n'utilise aucun des encodages problématiques.

Notez qu'il existe certaines limitations à l'utilisation de cette extension :

· Vous devez utiliser un encodage unique dans un référentiel.

· Si le chemin du référentiel se termine par 0x5c, .hg/hgrc ne peut pas être lu.

· win32mbcs n'est pas compatible avec l'extension fixutf8.

Par défaut, win32mbcs utilise encoding.encoding décidé par Mercurial. Vous pouvez spécifier le
encodage par option de configuration :

[win32mbcs]
encodage = sjis

Il est utile pour les utilisateurs qui souhaitent s'engager avec un message de journal UTF-8.

win32texte
effectuer une conversion automatique de saut de ligne (OBSOLÈTE)

Obsolescence : l'extension win32text nécessite que chaque utilisateur configure l'extension
encore et encore pour chaque clone puisque la configuration n'est pas copiée lors du clonage.

Nous avons donc fait le eol comme alternative. La eol utilise une version contrôlée
fichier pour sa configuration et chaque clone utilisera donc les bons paramètres de
le début.

Pour effectuer une conversion automatique de saut de ligne, utilisez :

[extensions]
win32text =
[encoder]
** = code intelligent :
# ou ** = macencode :

[décoder]
** = décodage intelligent :
# ou ** = macdecode :

Si vous ne faites pas de conversion, pour vous assurer de ne pas commettre CRLF/CR par accident :

[crochets]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf
# ou pretxncommit.cr = python:hgext.win32text.forbidcr

Pour effectuer la même vérification sur un serveur afin d'empêcher CRLF/CR d'être poussé ou tiré :

[crochets]
pretxnchangegroup.crlf = python:hgext.win32text.forbidcrlf
# ou pretxnchangegroup.cr = python:hgext.win32text.forbidcr

zéroconf
découvrir et publier des référentiels sur le réseau local

L'extension zeroconf annoncera hg besoin instances sur DNS-SD afin qu'elles puissent être
découverte à l'aide de la hg chemins commande sans connaître l'adresse du serveur.

Pour permettre à d'autres personnes de découvrir votre référentiel à l'aide de run hg besoin dans votre référentiel :

test de $ cd
$ hg servir

Vous pouvez découvrir les référentiels compatibles Zeroconf en exécutant hg chemins:

$hg chemins
test zc = http://example.com:8000/essai

Utilisez hg en ligne en utilisant les services onworks.net