hg - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

hg - Mercurial-Quellcode-Verwaltungssystem

ZUSAMMENFASSUNG

hg Befehl [zu erhalten]... [Argument] ...

BESCHREIBUNG

Das hg command stellt eine Befehlszeilenschnittstelle zum Mercurial-System bereit.

COMMAND ELEMENTS

Dateien ...
gibt einen oder mehrere Dateinamen oder relative Pfaddateinamen an; siehe Dateinamenmuster
für Informationen zum Mustervergleich

Weg gibt einen Pfad auf dem lokalen Computer an

Revision
bezeichnet ein Changeset, das als Changeset-Revisionsnummer, Tag,
oder eine eindeutige Teilzeichenfolge des Changeset-Hash-Werts

Quelle Weg
entweder der Pfadname eines lokalen Repositorys oder der URI eines entfernten Repositorys.

OPTIONAL

-R,--Repository
Repository-Stammverzeichnis oder Name der Overlay-Bundle-Datei

--cwd
Arbeitsverzeichnis ändern

-Und, --nicht interaktiv
nicht auffordern, wählen Sie automatisch die erste Wahl für alle Aufforderungen

-Q, --ruhig
Ausgabe unterdrücken

-in, - ausführlich
zusätzliche Ausgabe aktivieren

--config
Konfigurationsoption setzen/überschreiben (verwenden Sie 'section.name=value')

--debuggen
Debugging-Ausgabe aktivieren

- Debugger
Debugger starten

--Codierung
setze die Zeichensatzkodierung (Standard: UTF-8)

--encodingmode
Setze den Zeichensatz-Kodierungsmodus (Standard: strikt)

--zurück verfolgen
Bei Ausnahme immer ein Traceback drucken

--Zeit Zeit wie lange der Befehl dauert

--Profil
Befehlsausführungsprofil drucken

--Version
Ausgabe der Versionsinformation und beenden

-H, --help
Hilfe anzeigen und beenden

--versteckt
Berücksichtigen Sie versteckte Änderungssätze

[+] markierte Option kann mehrfach angegeben werden

BEFEHLE

hinzufügen
fügen Sie die angegebenen Dateien beim nächsten Commit hinzu:

hg hinzufügen [OPTION]... [DATEI]...

Planen Sie, dass Dateien versioniert und dem Repository hinzugefügt werden.

Die Dateien werden beim nächsten Commit dem Repository hinzugefügt. Um eine vorherige Hinzufügung rückgängig zu machen,
sehen hg vergessen.

Wenn keine Namen angegeben werden, fügen Sie alle Dateien zum Repository hinzu (außer Dateien, die übereinstimmen .hgignorieren).

Beispiele:

· Neue (unbekannte) Dateien werden automatisch hinzugefügt von hg hinzufügen:

$ls
foo.c
$ hg-Status
? foo.c
$hg hinzufügen
foo.c hinzufügen
$ hg-Status
Ein foo.c

· Spezifische hinzuzufügende Dateien können angegeben werden:

$ls
bar.c foo.c
$ hg-Status
? bar.c
? foo.c
$ hg hinzufügen bar.c
$ hg-Status
Ein bar.c
? foo.c

Gibt 0 zurück, wenn alle Dateien erfolgreich hinzugefügt wurden.

Zubehör:

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-S, --subrepos
Rekurs in Unterverzeichnisse

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

[+] markierte Option kann mehrfach angegeben werden

hinzufügenentfernen
alle neuen Dateien hinzufügen, alle fehlenden Dateien löschen:

hg addremove [OPTION]... [DATEI]...

Fügen Sie alle neuen Dateien hinzu und entfernen Sie alle fehlenden Dateien aus dem Repository.

Sofern keine Namen angegeben werden, werden neue Dateien ignoriert, wenn sie mit einem der Muster in übereinstimmen
.hgignorieren. Wie bei add werden diese Änderungen beim nächsten Commit wirksam.

Verwenden Sie die Option -s/--similarity, um umbenannte Dateien zu erkennen. Diese Option erfordert einen Prozentsatz
zwischen 0 (deaktiviert) und 100 (Dateien müssen identisch sein) als Parameter. Mit einem Parameter
größer als 0, vergleicht dies jede entfernte Datei mit jeder hinzugefügten Datei und zeichnet diese auf
ähnlich genug wie Umbenennungen. Das Erkennen umbenannter Dateien auf diese Weise kann teuer werden. Nach der Verwendung
diese Option, hg Status -C kann verwendet werden, um zu überprüfen, welche Dateien als verschoben erkannt wurden oder
umbenannt. Wenn nicht angegeben, ist -s/--similarity standardmäßig 100 und benennt nur identische um
Dateien erkannt werden.

Beispiele:

· Einige Dateien (bar.c und foo.c) sind neu, während foobar.c entfernt wurde (ohne
Verwendung von hg entfernen) aus dem Repository:

$ls
bar.c foo.c
$ hg-Status
! foobar.c
? bar.c
? foo.c
$ hg addremove
Hinzufügen von bar.c
foo.c hinzufügen
Entfernen von foobar.c
$ hg-Status
Ein bar.c
Ein foo.c
R foobar.c

· Eine Datei foobar.c wurde nach foo.c verschoben, ohne zu verwenden hg umbenennen. Danach war es
leicht bearbeitet:

$ls
foo.c
$ hg-Status
! foobar.c
? foo.c
$ hg addremove --Ähnlichkeit 90
Entfernen von foobar.c
foo.c hinzufügen
Aufzeichnung der Entfernung von foobar.c als Umbenennung in foo.c (94% ähnlich)
$ hg-Status -C
Ein foo.c
foobar.c
R foobar.c

Gibt 0 zurück, wenn alle Dateien erfolgreich hinzugefügt wurden.

Zubehör:

-S,--Ähnlichkeit
umbenannte Dateien nach Ähnlichkeit erraten (0<=s<=100)

-S, --subrepos
Rekurs in Unterverzeichnisse

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

[+] markierte Option kann mehrfach angegeben werden

kommentieren
Changeset-Informationen für jede Datei zeilenweise anzeigen:

hg kommentieren [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] DATEI...

Listen Sie Änderungen in Dateien auf und zeigen Sie die für jede Zeile verantwortliche Revisions-ID an.

Dieser Befehl ist nützlich, um herauszufinden, wann und von wem eine Änderung vorgenommen wurde.

Wenn Sie --file, --user oder --date angeben, wird die Revisionsnummer unterdrückt, es sei denn, Sie
auch --nummer einschließen.

Ohne die Option -a/--text vermeidet annotate die Verarbeitung von Dateien, die als Binärdateien erkannt werden.
Mit -a wird annotate die Datei trotzdem mit Anmerkungen versehen, obwohl die Ergebnisse wahrscheinlich sein werden
weder sinnvoll noch wünschenswert.

Gibt bei Erfolg 0 zurück.

Zubehör:

-R,--rev
kommentieren Sie die angegebene Revision

--Folgen
Folgen Sie den Kopien/Umbenennungen und listen Sie den Dateinamen auf (VERALTET)

--no-follow
Folgen Sie keinen Kopien und Umbenennungen

-a, --Text
Behandeln Sie alle Dateien als Text

-du, --Benutzer
den Autor auflisten (lang mit -v)

-F, --Datei
den Dateinamen auflisten

-D, --Datum
das Datum auflisten (kurz mit -q)

-nicht, --Nummer
die Revisionsnummer auflisten (Standard)

-C, --Änderungssatz
listet das Änderungsset auf

- l, --Zeilennummer
Zeilennummer beim ersten Auftreten anzeigen

-w, --ignore-all-space
ignoriere Leerzeichen beim Vergleichen von Zeilen

-B, --ignore-space-change
Ignorieren Sie Änderungen in der Menge des Leerraums

-B, --leerzeilen ignorieren
Ignoriere Änderungen, deren Zeilen alle leer sind

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

[+] markierte Option kann mehrfach angegeben werden

Pseudonym: Schuld

Archiv
Erstellen Sie ein unversioniertes Archiv einer Repository-Revision:

hg-Archiv [OPTION]... DEST

Standardmäßig ist die verwendete Revision die übergeordnete Version des Arbeitsverzeichnisses; benutze -r/--rev um
eine andere Revision angeben.

Der Archivtyp wird automatisch anhand der Dateierweiterung erkannt (zum Überschreiben verwenden Sie
-t/--Typ).

Beispiele:

· Erstellen Sie eine ZIP-Datei mit der Version 1.0:

hg Archiv -r 1.0 Projekt-1.0.zip

· Erstellen Sie einen Tarball ohne .hg-Dateien:

hg-Archivprojekt.tar.gz -X ".hg*"

Gültige Typen sind:

Dateien

ein Verzeichnis voller Dateien (Standard)

Teer

tar-Archiv, unkomprimiert

tbz2

tar-Archiv, komprimiert mit bzip2

tgz

tar-Archiv, komprimiert mit gzip

uzip

ZIP-Archiv, unkomprimiert

Reißverschluss

zip-Archiv, komprimiert mit deflate

Der genaue Name des Zielarchivs oder -verzeichnisses wird mit einer Formatzeichenfolge angegeben; sehen
hg Hilfe exportieren für weitere Einzelheiten.

Jedes Mitglied, das einer Archivdatei hinzugefügt wird, hat ein vorangestelltes Verzeichnispräfix. Verwenden Sie -p/--Präfix für
Geben Sie eine Formatzeichenfolge für das Präfix an. Der Standardwert ist der Basisname des Archivs, mit
Suffixe entfernt.

Gibt bei Erfolg 0 zurück.

Zubehör:

--no-decode
Übergeben Sie keine Dateien durch Decoder

-P,prefix
Verzeichnispräfix für Dateien im Archiv

-R,--rev
Überarbeitung zu verteilen

-T,--Typ
Art der Verteilung zu erstellen

-S, --subrepos
Rekurs in Unterverzeichnisse

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

zurücktreten
umgekehrter Effekt des früheren Changesets:

hg Zurücksetzen [OPTION]... [-r] REV

Bereiten Sie im aktuellen Arbeitsverzeichnis ein neues Changeset mit der Wirkung von REV rückgängig vor. Wenn
keine Konflikte aufgetreten sind, wird es sofort festgeschrieben.

Wenn REV das Elternverzeichnis des Arbeitsverzeichnisses ist, wird dieser neue Änderungssatz festgeschrieben
automatisch (es sei denn, --no-commit ist angegeben).

Note hg zurücktreten kann nicht verwendet werden, um eine unerwünschte oder falsche Zusammenführung zu beheben.

Beispiele:

· Kehren Sie die Wirkung des Elternteils des Arbeitsverzeichnisses um. Dieses Backout wird sein
sofort verpflichtet:

hg backout -r .

· Kehren Sie den Effekt der vorherigen schlechten Revision 23 um:

hg backout -r 23

· Machen Sie die Auswirkungen der vorherigen fehlerhaften Revision 23 rückgängig und lassen Sie die Änderungen nicht festgeschrieben:

hg backout -r 23 --no-commit
hg commit -m "Backout-Revision 23"

Standardmäßig hat das ausstehende Änderungsset ein übergeordnetes Element, das einen linearen Verlauf beibehält. Mit
--merge, das ausstehende Changeset hat stattdessen zwei Elternteile: das alte Elternteil des
Arbeitsverzeichnis und ein neues Kind von REV, das REV einfach rückgängig macht.

Vor Version 1.7 entsprach das Verhalten ohne --merge der Angabe von --merge
gefolgt von hg Aktualisierung --sauber . um die Zusammenführung abzubrechen und das Kind von REV als Kopf zu lassen
separat zusammengeführt werden.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

See hg Hilfe zurückkehren für eine Möglichkeit, Dateien in den Zustand einer anderen Revision wiederherzustellen.

Gibt 0 bei Erfolg zurück, 1 wenn nichts rückgängig zu machen ist oder unaufgelöste Dateien vorhanden sind.

Zubehör:

--verschmelzen
nach dem Backout mit dem alten Dirstate-Elternteil zusammenführen

--verpflichten
Commit, wenn keine Konflikte aufgetreten sind (DEPRECATED)

--keine Verpflichtung
nicht festlegen

--Elternteil
Übergeordnetes Element, das beim Zurücksetzen der Zusammenführung ausgewählt werden soll (VERALTET)

-R,--rev
Überarbeitung zum Backout

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-T,--Werkzeug
Zusammenführungswerkzeug angeben

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

[+] markierte Option kann mehrfach angegeben werden

halbieren
Unterteilungssuche von Changesets:

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

Dieser Befehl hilft, Changesets zu finden, die Probleme verursachen. Um zu verwenden, markieren Sie das früheste
Änderungssatz, von dem Sie wissen, dass das Problem als schlecht angezeigt wird, markieren Sie dann den neuesten Änderungssatz, der
frei von dem Problem so gut. Bisect aktualisiert Ihr Arbeitsverzeichnis auf eine Revision für
testing (es sei denn, die Option -U/--noupdate ist angegeben). Nachdem Sie Tests durchgeführt haben,
Markieren Sie das Arbeitsverzeichnis als gut oder schlecht, und bisect wird entweder auf ein anderes aktualisiert
Candidate Changeset oder geben bekannt, dass die fehlerhafte Revision gefunden wurde.

Als Abkürzung können Sie auch das Revisionsargument verwenden, um eine Revision als gut oder schlecht zu markieren
ohne es vorher zu überprüfen.

Wenn Sie einen Befehl eingeben, wird dieser für die automatische Halbierung verwendet. Die Umgebung
Die Variable HG_NODE enthält die ID des getesteten Changesets. Der Austrittsstatus der
Befehl wird verwendet, um Revisionen als gut oder schlecht zu markieren: Status 0 bedeutet gut, 125 bedeutet zu
Überspringen Sie die Revision, 127 (Befehl nicht gefunden) bricht die Bisektion ab und alle anderen
Ein Exit-Status ungleich Null bedeutet, dass die Revision fehlerhaft ist.

Einige Beispiele:

· eine Bisektion mit bekanntermaßen schlechter Revision 34 und guter Revision 12 beginnen:

hg halbieren --schlechte 34
hg halbieren --gut 12

· die aktuelle Bisektion vorantreiben, indem die aktuelle Revision als gut oder schlecht markiert wird:

hg halbieren --gut
hg halbieren --bad

· markieren Sie die aktuelle Revision oder eine bekannte Revision, die übersprungen werden soll (z. B. wenn diese Revision
nicht verwendbar wegen eines anderen Problems):

hg halbieren --skip
hg halbieren --überspringen 23

· alle Revisionen überspringen, die keine Verzeichnisse berühren foo or Bar:

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

· vergessen Sie die aktuelle Bisektion:

hg halbieren --reset

· Verwenden Sie 'make && make tests', um automatisch die erste defekte Revision zu finden:

hg halbieren --reset
hg halbieren --schlechte 34
hg halbieren --gut 12
hg bisect --command "Make && Tests machen"

· alle Changesets anzeigen, deren Zustände bereits in der aktuellen Bisektion bekannt sind:

hg log -r "halbieren(beschnitten)"

· sehen Sie das Changeset, das gerade halbiert wird (besonders nützlich, wenn Sie mit laufen
-U/--noupdate):

hg log -r "halbieren (aktuell)"

· alle Changesets anzeigen, die an der aktuellen Bisektion teilgenommen haben:

hg log -r "halbieren(Bereich)"

· Sie können sogar eine schöne Grafik erhalten:

hg log --graph -r "halbieren(Bereich)"

See hg Hilfe kehrt zurück für mehr über die halbieren() Stichwort.

Gibt bei Erfolg 0 zurück.

Zubehör:

-R, --zurücksetzen
Bisect-Zustand zurücksetzen

-G, --gut
Änderungssatz gut markieren

-B, --Schlecht
Änderungssatz als schlecht markieren

-S, --überspringen
Testen des Änderungssatzes überspringen

-e, --erweitern
Erweitern Sie den Halbierungsbereich

-C,--Befehl
Verwenden Sie den Befehl, um den Status des Changesets zu überprüfen

-U, --kein Update
nicht auf Ziel aktualisieren

bookmarks
Erstellen Sie ein neues Lesezeichen oder listen Sie vorhandene Lesezeichen auf:

hg Lesezeichen [OPTIONEN]... [NAME]...

Lesezeichen sind Beschriftungen auf Änderungssätzen, um Entwicklungslinien nachzuverfolgen. Lesezeichen sind
unversioniert und kann verschoben, umbenannt und gelöscht werden. Das Löschen oder Verschieben eines Lesezeichens hat keine
Auswirkungen auf die zugehörigen Changesets.

Wenn Sie ein Lesezeichen erstellen oder aktualisieren, wird es als „aktiv“ markiert. Die Aktiven
Lesezeichen sind mit einem '*' gekennzeichnet. Wenn ein Commit gemacht wird, wird das aktive Lesezeichen vorrücken
zum neuen Commit. Eine Fläche hg Aktualisierung wird auch ein aktives Lesezeichen vorrücken, wenn möglich.
Wenn Sie außerhalb eines Lesezeichens aktualisieren, wird es deaktiviert.

Lesezeichen können zwischen Repositorys verschoben und gezogen werden (siehe hg Hilfe drücken und hg Hilfe ziehen
). Wenn ein freigegebenes Lesezeichen auseinandergegangen ist, wird ein neues 'divergentes Lesezeichen' der Form 'Name@Pfad'
erstellt werden. Verwenden von hg fusionieren wird die Abweichung auflösen.

Ein Lesezeichen namens '@' hat die besondere Eigenschaft, dass hg klonen wird es standardmäßig überprüfen
wenn es existiert.

Beispiele:

· Erstellen Sie ein aktives Lesezeichen für eine neue Entwicklungslinie:

hg buch neu-feature

· ein inaktives Lesezeichen als Ortsmarkierung erstellen:

hg Buch - ich habe rezensiert

· ein inaktives Lesezeichen auf einem anderen Changeset erstellen:

hg book -r .^ getestet

· Lesezeichen Truthahn in Abendessen umbenennen:

hg book -m Truthahnessen

· Verschieben Sie das Lesezeichen '@' von einem anderen Zweig:

hg buch -f @

Zubehör:

-F, --Macht
Stärke

-R,--rev
Überarbeitung für Lesezeichenaktion

-D, --löschen
ein bestimmtes Lesezeichen löschen

-M,--umbenennen
Benennen Sie ein bestimmtes Lesezeichen um

-ich, --inaktiv
ein Lesezeichen als inaktiv markieren

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

Aliase: Lesezeichen

Filiale
den aktuellen Zweignamen setzen oder anzeigen:

hg-Zweig [-fC] [NAME]

Hinweis Zweignamen sind permanent und global. Verwenden hg Lesezeichen um ein leichtes zu schaffen
Lesezeichen statt. Sehen hg Hilfe Glossar für weitere Informationen zu benannten Zweigen
und Lesezeichen.

Zeigen Sie ohne Argument den aktuellen Zweignamen an. Legen Sie mit einem Argument die Funktion fest
Verzeichniszweigname (der Zweig existiert erst beim nächsten Commit im Repository).
Die Standardpraxis empfiehlt, dass die primäre Entwicklung im 'Standard'-Zweig stattfindet.

Sofern -f/--force nicht angegeben ist, können Sie mit Branch keinen bereits vorhandenen Branch-Namen festlegen
besteht.

Verwenden Sie -C/--clean, um den Arbeitsverzeichniszweig auf den des Elternverzeichnisses des Arbeitsverzeichnisses zurückzusetzen
Verzeichnis, wodurch eine vorherige Verzweigungsänderung negiert wird.

Verwenden Sie den Befehl hg Aktualisierung in eine bestehende Filiale wechseln. Verwenden hg verpflichten --Zweig schließen zu
markieren Sie diesen Zweigkopf als geschlossen. Wenn alle Leiter einer Filiale geschlossen sind, wird die Filiale
als geschlossen gelten.

Gibt bei Erfolg 0 zurück.

Zubehör:

-F, --Macht
setze den Branch-Namen, auch wenn er einen bestehenden Branch überschattet

-VS, --sauber
Zweigstellennamen auf den Namen der übergeordneten Zweigstelle zurücksetzen

Geäst
listet Repository mit dem Namen Branches auf:

hg-Zweige [-c]

Listen Sie die benannten Branches des Repositorys auf und geben Sie an, welche inaktiv sind. Wenn -c/--geschlossen
angegeben ist, listen Sie auch Filialen auf, die als geschlossen markiert wurden (siehe hg verpflichten
--Zweig schließen).

Verwenden Sie den Befehl hg Aktualisierung in eine bestehende Filiale wechseln.

Rückgabe 0.

Zubehör:

-a, --aktiv
Nur Branches anzeigen, die nicht zusammengeführte Köpfe haben (DEPRECATED)

-C, --abgeschlossen
normale und geschlossene Filialen anzeigen

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

bündeln
Erstellen Sie eine Changegroup-Datei:

hg Bündel [-f] [-t TYP] [-a] [-r REV]... [--base REV]... DATEI [ZIEL]

Generieren Sie eine Änderungsgruppendatei, die Änderungssätze sammelt, die einem Repository hinzugefügt werden sollen.

Um ein Bundle mit allen Änderungssätzen zu erstellen, verwenden Sie -a/--all (oder --base null). Ansonsten, hg
geht davon aus, dass das Ziel alle Knoten enthält, die Sie mit den Parametern --base angeben.
Andernfalls geht hg davon aus, dass das Repository alle Knoten im Ziel hat, oder
default-push/default, wenn kein Ziel angegeben ist.

Sie können das Bundle-Format mit der Option -t/--type ändern. Sie können eine Komprimierung angeben, a
Bundle-Version oder beides mit einem Bindestrich (comp-version). Die verfügbaren Komprimierungsmethoden sind:
none, bzip2 und gzip (standardmäßig werden Bundles mit bzip2 komprimiert). Die verfügbaren
Formate sind: v1, v2 (standardmäßig am besten geeignet).

Die Bundle-Datei kann dann mit herkömmlichen Mitteln übertragen und auf eine andere übertragen werden
Repository mit dem Unbundle- oder Pull-Befehl. Dies ist nützlich, wenn direktes Drücken und Ziehen
nicht verfügbar ist oder wenn ein gesamtes Repository exportiert wird, ist unerwünscht.

Beim Anwenden von Bundles bleiben alle Changeset-Inhalte erhalten, einschließlich Berechtigungen, Kopieren/Umbenennen
Informationen und Revisionshistorie.

Gibt bei Erfolg 0 zurück, 1 wenn keine Änderungen gefunden wurden.

Zubehör:

-F, --Macht
laufen, auch wenn das Ziel nicht verwandt ist

-R,--rev
ein Änderungsset, das zum Ziel hinzugefügt werden soll

-B,--Zweig
eine bestimmte Filiale, die Sie bündeln möchten

--Base
ein Basis-Changeset, von dem angenommen wird, dass es am Ziel verfügbar ist

-a, --alle
bündeln Sie alle Changesets im Repository

-T,--Typ
zu verwendender Bundle-Komprimierungstyp (Standard: bzip2)

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

Katze
gibt die aktuelle oder gegebene Revision von Dateien aus:

hg katze [OPTION]... DATEI...

Drucken Sie die angegebenen Dateien so, wie sie bei der angegebenen Revision waren. Wenn keine Revision angegeben ist, wird die
Eltern des Arbeitsverzeichnisses verwendet.

Die Ausgabe kann in eine Datei erfolgen, in diesem Fall wird der Name der Datei in einem Format angegeben
Schnur. Die Formatierungsregeln wie folgt:

%%

wörtliches "%"-Zeichen

%s

Basisname der zu druckenden Datei

%d

dirname der zu druckenden Datei oder '.' wenn im Repository root

%p

Root-relativer Pfadname der zu druckenden Datei

%H

Changeset-Hash (40 hexadezimale Ziffern)

%R

Änderungssatz-Revisionsnummer

%h

Changeset-Hash in kurzer Form (12 hexadezimale Ziffern)

%r

mit Nullen aufgefüllte Änderungssatz-Revisionsnummer

%b

Basisname des exportierenden Repositorys

Gibt bei Erfolg 0 zurück.

Zubehör:

-Ö,--Ausgabe
Ausgabe in Datei mit formatiertem Namen drucken

-R,--rev
Drucken Sie die angegebene Revision

--dekodieren
Wenden Sie einen passenden Dekodierungsfilter an

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

klonen
Erstellen Sie eine Kopie eines vorhandenen Repositorys:

hg-Klon [OPTION]... QUELLE [DEST]

Erstellen Sie eine Kopie eines vorhandenen Repositorys in einem neuen Verzeichnis.

Wenn kein Zielverzeichnisname angegeben wird, wird standardmäßig der Basisname der Quelle verwendet.

Der Speicherort der Quelle wird dem neuen Repository hinzugefügt .hg/hgrc Datei, als Standard
für zukünftige Ziehungen verwendet werden.

Nur lokale Pfade und ssh:// URLs werden als Ziele unterstützt. Zum ssh:// Destinationen,
kein Arbeitsverzeichnis oder .hg/hgrc wird auf der Remote-Seite erstellt.

Wenn im Quell-Repository ein Lesezeichen namens '@' gesetzt ist, wird diese Revision ausgecheckt
im neuen Repository standardmäßig.

Um eine bestimmte Version auszuchecken, verwenden Sie -u/--update oder -U/--noupdate, um einen Klon zu erstellen
ohne Arbeitsverzeichnis.

Um nur eine Teilmenge von Änderungssätzen abzurufen, geben Sie eine oder mehrere Revisionskennungen mit . an
-r/--rev oder verzweigt mit -b/--branch. Der resultierende Klon enthält nur die angegebenen
Changesets und ihre Vorfahren. Diese Optionen (oder 'clone src#rev dest') implizieren --pull, even
für lokale Quell-Repositorys.

Hinweis Wenn Sie ein Tag angeben, wird das mit Tags versehene Änderungsset eingeschlossen, jedoch nicht das Änderungsset, das . enthält
das Etikett.

Aus Effizienzgründen werden Hardlinks zum Klonen verwendet, wenn Quelle und Ziel eingeschaltet sind
das gleiche Dateisystem (beachten Sie, dass dies nur für die Repository-Daten gilt, nicht für die Arbeits
Verzeichnis). Einige Dateisysteme wie AFS implementieren Hardlinking falsch, aber nicht
Fehler melden. Verwenden Sie in diesen Fällen die Option --pull, um Hardlinking zu vermeiden.

In einigen Fällen können Sie Repositorys und das Arbeitsverzeichnis mit vollständigen Hardlinks klonen
mit

$ cp -al REPO REPOCLONE

Dies ist der schnellste Weg zum Klonen, aber es ist nicht immer sicher. Die Operation ist nicht atomar
(Stellen Sie sicher, dass REPO während der Operation nicht geändert wird) und Sie müssen dies tun
Stellen Sie sicher, dass Ihr Editor Hardlinks unterbricht (Emacs und die meisten Linux-Kernel-Tools tun dies). Das ist auch
nicht kompatibel mit bestimmten Erweiterungen, die ihre Metadaten im .hg-Verzeichnis ablegen,
wie mq.

Mercurial aktualisiert das Arbeitsverzeichnis auf die erste anwendbare Revision davon
Liste:

A. null if -U oder das Quell-Repository hat keine Änderungssätze

B. wenn du . und das Quell-Repository ist lokal, das erste übergeordnete Element des Quell-Repositorys
Arbeitsverzeichnis

C. das mit -u angegebene Changeset (bei einem Branch-Namen bedeutet dies den neuesten Kopf davon
Ast)

D. das mit -r . angegebene Changeset

e. der äußerste Kopf, der mit -b . angegeben wird

F. der äußerste Kopf, der mit der url#branch-Quellsyntax angegeben wird

g. die mit dem '@'-Lesezeichen markierte Revision, falls vorhanden

h. der klügste Kopf des Standardzweigs

ich. Spitze

Beim Klonen von Servern, die dies unterstützen, kann Mercurial vorgenerierte Daten von einem
vom Server beworbene URL. Wenn dies erledigt ist, arbeiten Hooks mit eingehenden Changesets und
changegroups können zweimal ausgelöst werden, einmal für das von der URL abgerufene Paket und ein weiteres für alle
zusätzliche Daten, die nicht von dieser URL abgerufen wurden. Außerdem wird im Fehlerfall das Repository
kann auf einen partiellen Klon zurückgesetzt werden. Dieses Verhalten kann sich in zukünftigen Versionen ändern. Sehen hg
Hilfe -e Klonbündel für mehr.

Beispiele:

· ein entferntes Repository in ein neues Verzeichnis namens hg/ klonen:

hg Klon http://selenic.com/hg

· einen leichten lokalen Klon erstellen:

hg Klon-Projekt/ Projekt-Feature/

· Klonen von einem absoluten Pfad auf einem SSH-Server (beachten Sie den doppelten Schrägstrich):

hg-Klon ssh://user@server//home/projects/alpha/

· Führen Sie einen Hochgeschwindigkeits-Klon über ein LAN durch, während Sie eine bestimmte Version auschecken:

hg-Klon --unkomprimiert http://server/repo -u 1.5

· nach einer bestimmten Revision ein Repository ohne Changesets erstellen:

hg-Klon -r 04e544 experimentell/ gut/

· einen bestimmten benannten Zweig klonen (und verfolgen):

hg Klon http://selenic.com/hg#stabil

See hg Hilfe urls für Details zum Angeben von URLs.

Gibt bei Erfolg 0 zurück.

Zubehör:

-U, --kein Update
der Klon enthält ein leeres Arbeitsverzeichnis (nur ein Repository)

-du,--updaterev
Überarbeitung, Tag oder Verzweigung zum Auschecken

-R,--rev
das angegebene Änderungsset einschließen

-B,--Zweig
nur den angegebenen Zweig klonen

--ziehen Verwenden Sie das Pull-Protokoll, um Metadaten zu kopieren

--unkomprimiert
unkomprimierte Übertragung verwenden (schnell über LAN)

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

verpflichten
Commit die angegebenen Dateien oder alle ausstehenden Änderungen:

hg commit [OPTION]... [DATEI]...

Übertragen Sie Änderungen an den angegebenen Dateien in das Repository. Im Gegensatz zu einem zentralisierten SCM ist dies
Betrieb ist ein lokaler Betrieb. Sehen hg drücken für eine Möglichkeit, Ihre Änderungen aktiv zu verteilen.

Wenn eine Liste von Dateien weggelassen wird, werden alle Änderungen gemeldet von hg Status wird begangen.

Wenn Sie das Ergebnis einer Zusammenführung festschreiben, geben Sie keine Dateinamen oder -I/-X . an
Filter.

Wenn keine Commit-Nachricht angegeben ist, startet Mercurial Ihren konfigurierten Editor, wo Sie
eine Nachricht eingeben. Falls Ihr Commit fehlschlägt, finden Sie ein Backup Ihrer Nachricht in
.hg/letzte-Nachricht.txt.

Das Flag --close-branch kann verwendet werden, um den aktuellen Zweigkopf als geschlossen zu markieren. Wenn alle Köpfe
einer Filiale geschlossen sind, gilt die Filiale als geschlossen und wird nicht mehr gelistet.

Das Flag --amend kann verwendet werden, um das Elternverzeichnis des Arbeitsverzeichnisses mit einem neuen . zu ergänzen
Commit, der die Änderungen im übergeordneten Element zusätzlich zu denen enthält, die derzeit von . gemeldet werden
hg Status, falls vorhanden. Das alte Commit wird in einem Backup-Bundle in gespeichert
.hg/strip-backup (sehen hg Hilfe bündeln und hg Hilfe aufschlüsseln zur Wiederherstellung).

Nachricht, Benutzer und Datum werden aus dem geänderten Commit übernommen, sofern nicht anders angegeben. Wenn eine Nachricht
nicht in der Befehlszeile angegeben ist, öffnet sich der Editor mit der Meldung des geänderten
verpflichten.

Es ist nicht möglich, öffentliche Changesets zu ändern (siehe hg Hilfe Phasen) oder Changesets, die
Kinder.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Gibt bei Erfolg 0 zurück, 1 wenn sich nichts geändert hat.

Beispiele:

· Commit alle Dateien mit der Endung .py:

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

· Commit alle nicht-binären Dateien:

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

· den aktuellen Commit ändern und das Datum auf jetzt setzen:

hg commit --amend --date jetzt

Zubehör:

-EIN, --addremove
Markiere neue/fehlende Dateien als hinzugefügt/entfernt, bevor du sie festlegst

--Zweig schließen
einen Zweigkopf als geschlossen markieren

--ändern
das übergeordnete Element des Arbeitsverzeichnisses ändern

-S, --Geheimnis
Nutze die geheime Phase zum Begehen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-ich, --interaktiv
Verwenden Sie den interaktiven Modus

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

Aliase: ci

Config
Kombinierte Konfigurationseinstellungen aus allen hgrc-Dateien anzeigen:

hg config [-u] [NAME]...

Geben Sie ohne Argumente Namen und Werte aller Konfigurationselemente aus.

Geben Sie mit einem Argument der Form section.name nur den Wert dieses Konfigurationselements aus.

Geben Sie mit mehreren Argumenten Namen und Werte aller Konfigurationselemente mit übereinstimmendem Abschnitt aus.
Namen.

Starten Sie mit --edit einen Editor für die Konfigurationsdatei auf Benutzerebene. Bearbeiten Sie mit --global die
systemweite Konfigurationsdatei. Bearbeiten Sie mit --local die Konfigurationsdatei auf Repository-Ebene.

Mit --debug wird die Quelle (Dateiname und Zeilennummer) für jedes Konfigurationselement ausgegeben.

See hg Hilfe Config Weitere Informationen zu Konfigurationsdateien.

Gibt bei Erfolg 0 zurück, 1 wenn NAME nicht existiert.

Zubehör:

-du, --nicht vertrauenswürdig
nicht vertrauenswürdige Konfigurationsoptionen anzeigen

-e, --bearbeiten
Benutzerkonfiguration bearbeiten

- l, --lokal
Repository-Konfiguration bearbeiten

-G, - global
Bearbeiten der globalen Konfiguration

Aliase: showconfig debugconfig

Kopieren
Dateien für den nächsten Commit als kopiert markieren:

hg kopieren [OPTION]... [QUELLE]... DEST

Markieren Sie dest als Kopien von Quelldateien. Wenn dest ein Verzeichnis ist, werden Kopien darin abgelegt
Verzeichnis. Wenn dest eine Datei ist, muss die Quelle eine einzelne Datei sein.

Standardmäßig kopiert dieser Befehl den Inhalt von Dateien, wie sie in der Arbeitsumgebung vorhanden sind
Verzeichnis. Bei Aufruf mit -A/--after wird der Vorgang aufgezeichnet, aber kein Kopieren
durchgeführt.

Dieser Befehl wird mit dem nächsten Commit wirksam. Um eine vorherige Kopie rückgängig zu machen, siehe hg zurückkehren.

Gibt 0 bei Erfolg zurück, 1 wenn Fehler aufgetreten sind.

Zubehör:

-EIN, --nach
eine bereits aufgetretene Kopie aufzeichnen

-F, --Macht
erzwungenes Kopieren über eine vorhandene verwaltete Datei

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

[+] markierte Option kann mehrfach angegeben werden

Aliase: cp

diff
diff-Repository (oder ausgewählte Dateien):

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

Unterschiede zwischen Revisionen für die angegebenen Dateien anzeigen.

Unterschiede zwischen Dateien werden im einheitlichen Diff-Format angezeigt.

Note hg diff kann unerwartete Ergebnisse für Zusammenführungen erzeugen, da standardmäßig verglichen wird
gegen das erste übergeordnete Changeset des Arbeitsverzeichnisses, wenn keine Revisionen vorhanden sind
spezifiziert.

Wenn zwei Revisionsargumente angegeben werden, werden Änderungen zwischen diesen Revisionen angezeigt. Wenn
nur eine Revision angegeben ist, dann wird diese Revision mit dem Arbeitsverzeichnis verglichen,
und wenn keine Revisionen angegeben sind, werden die Arbeitsverzeichnisdateien mit ihren
erster Elternteil.

Alternativ können Sie -c/--change mit einer Revision angeben, um die Änderungen darin zu sehen
Changeset relativ zu seinem ersten Elternteil.

Ohne die Option -a/--text vermeidet diff das Generieren von Diffs von Dateien, als die es erkannt wird
binär. Mit -a erzeugt diff trotzdem ein diff, wahrscheinlich mit unerwünschten Ergebnissen.

Verwenden Sie die Option -g/--git, um Diffs im erweiterten Diff-Format von git zu generieren. Für mehr
Informationen, lesen hg Hilfe Unterschiede.

Beispiele:

· Vergleichen Sie eine Datei im aktuellen Arbeitsverzeichnis mit ihrem Elternverzeichnis:

hg diff foo.c

· Vergleichen Sie zwei historische Versionen eines Verzeichnisses mit Umbenennungsinformationen:

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

· Änderungsstatistiken relativ zur letzten Änderung an einem bestimmten Datum abrufen:

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

· diff alle neu hinzugefügten Dateien, die ein Schlüsselwort enthalten:

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

· Vergleichen Sie eine Revision und ihre Eltern:

hg diff -c 9353 # Vergleich mit dem ersten Elternteil
hg diff -r 9353^:9353 # dasselbe mit der Revset-Syntax
hg diff -r 9353^2:9353 # Vergleich mit dem zweiten Elternteil

Gibt bei Erfolg 0 zurück.

Zubehör:

-R,--rev
Revision

-C,--Veränderung
Änderung durch Überarbeitung

-a, --Text
Behandeln Sie alle Dateien als Text

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

--nodates
Daten aus Diff-Headern weglassen

--noprefix
weglassen a/ und b/ Präfixe von Dateinamen

-P, --show-Funktion
zeigen, in welcher Funktion jede Änderung enthalten ist

--umkehren
einen Diff erzeugen, der die Änderungen rückgängig macht

-w, --ignore-all-space
ignoriere Leerzeichen beim Vergleichen von Zeilen

-B, --ignore-space-change
Ignorieren Sie Änderungen in der Menge des Leerraums

-B, --leerzeilen ignorieren
Ignoriere Änderungen, deren Zeilen alle leer sind

-U,--einheitlich
Anzahl der anzuzeigenden Kontextzeilen

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

--Wurzel
erzeugen Diffs relativ zum Unterverzeichnis

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

exportieren
Dump der Header und Diffs für ein oder mehrere Changesets:

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

Drucken Sie den Changeset-Header und die Diffs für eine oder mehrere Revisionen. Wenn keine Revision angegeben ist,
das Elternverzeichnis des Arbeitsverzeichnisses wird verwendet.

Die im Changeset-Header angezeigten Informationen sind: Autor, Datum, Zweigname (wenn
Nicht-Standard), Changeset-Hash, Parent(s) und Commit-Kommentar.

Note hg exportieren kann unerwartete diff-Ausgaben für Merge-Changesets erzeugen, da dies der Fall ist
vergleichen Sie das Merge-Änderungsset nur mit seinem ersten übergeordneten Element.

Die Ausgabe kann in eine Datei erfolgen, in diesem Fall wird der Name der Datei in einem Format angegeben
Schnur. Die Formatierungsregeln lauten wie folgt:

%%

wörtliches "%"-Zeichen

%H

Changeset-Hash (40 hexadezimale Ziffern)

%N

Anzahl der generierten Patches

%R

Änderungssatz-Revisionsnummer

%b

Basisname des exportierenden Repositorys

%h

Changeset-Hash in kurzer Form (12 hexadezimale Ziffern)

%m

erste Zeile der Commit-Nachricht (nur alphanumerische Zeichen)

%n

mit Nullen aufgefüllte Sequenznummer, beginnend bei 1

%r

mit Nullen aufgefüllte Änderungssatz-Revisionsnummer

Ohne die Option -a/--text vermeidet der Export das Generieren von Diffs von Dateien, die als erkannt werden
binär. Mit -a erzeugt export trotzdem ein Diff, wahrscheinlich mit unerwünschten Ergebnissen.

Verwenden Sie die Option -g/--git, um Diffs im erweiterten Diff-Format von git zu generieren. Sehen hg Hilfe
Unterschiede um mehr zu erfahren.

Mit der Option --switch-parent wird der Diff gegen den zweiten Elternteil verwendet. Es kann sein
nützlich, um eine Zusammenführung zu überprüfen.

Beispiele:

· Verwenden Sie Export und Import, um einen Bugfix in den aktuellen Zweig zu übertragen:

hg export -r 9353 | HG-Import -

· Exportieren Sie alle Changesets zwischen zwei Revisionen in eine Datei mit Umbenennungsinformationen:

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

· Ausgehende Änderungen in eine Reihe von Patches mit beschreibenden Namen aufteilen:

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

Gibt bei Erfolg 0 zurück.

Zubehör:

-Ö,--Ausgabe
Ausgabe in Datei mit formatiertem Namen drucken

--switch-parent
gegen den zweiten Elternteil differenzieren

-R,--rev
Überarbeitungen für den Export

-a, --Text
Behandeln Sie alle Dateien als Text

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

--nodates
Daten aus Diff-Headern weglassen

[+] markierte Option kann mehrfach angegeben werden

Dateien
Listet verfolgte Dateien auf:

hg-Dateien [OPTION]... [MUSTER]...

Drucken Sie Dateien unter der Kontrolle von Mercurial im Arbeitsverzeichnis oder der angegebenen Revision, deren
Namen stimmen mit den angegebenen Mustern überein (ausgenommen entfernte Dateien).

Wenn keine passenden Muster angegeben sind, druckt dieser Befehl die Namen aller Dateien unter
Merkurial-Kontrolle im Arbeitsverzeichnis.

Beispiele:

· alle Dateien unter dem aktuellen Verzeichnis auflisten:

hg-Dateien.

· zeigt Größen und Flags für die aktuelle Revision an:

hg-Dateien -vr .

· alle Dateien mit dem Namen README auflisten:

hg-Dateien -I "**/README"

· alle Binärdateien auflisten:

hg-Dateien "set:binary()"

· Dateien finden, die einen regulären Ausdruck enthalten:

hg-Dateien "set:grep('bob')"

· nach verfolgten Dateiinhalten mit xargs und grep suchen:

hg-Dateien -0 | xargs -0 grep foo

See hg Hilfe Muster und hg Hilfe Dateisätze für weitere Informationen zum Angeben der Datei
Muster.

Gibt 0 zurück, wenn eine Übereinstimmung gefunden wird, andernfalls 1 zurück.

Zubehör:

-R,--rev
Durchsuchen Sie das Repository, wie es in REV . ist

-0, --print0
Dateinamen mit NUL beenden, zur Verwendung mit xargs

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

vergessen
vergessen Sie die angegebenen Dateien beim nächsten Commit:

hg [OPTION] vergessen... DATEI...

Markieren Sie die angegebenen Dateien, damit sie nach dem nächsten Commit nicht mehr nachverfolgt werden.

Dadurch werden nur Dateien aus dem aktuellen Zweig entfernt, nicht aus dem gesamten Projektverlauf, und
es löscht sie nicht aus dem Arbeitsverzeichnis.

Um die Datei aus dem Arbeitsverzeichnis zu löschen, siehe hg entfernen.

Um ein Vergessen vor dem nächsten Commit rückgängig zu machen, siehe hg hinzufügen.

Beispiele:

· vergessen Sie neu hinzugefügte Binärdateien:

hg vergiss "set:added() und binary()"

· Dateien vergessen, die von .hgignore ausgeschlossen würden:

hg vergiss "set:hgignore()"

Gibt bei Erfolg 0 zurück.

Zubehör:

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Graft
Änderungen aus anderen Zweigen in den aktuellen Zweig kopieren:

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

Dieser Befehl verwendet die Merge-Logik von Mercurial, um einzelne Änderungen aus anderen Branches zu kopieren
ohne Verzweigungen im Verlaufsgraphen zusammenzuführen. Dies wird manchmal als "Rückportieren" bezeichnet oder
'Rosinenpickerei'. Standardmäßig kopiert Graft Benutzer, Datum und Beschreibung aus der Quelle
Änderungssätze.

Changesets, die Vorfahren der aktuellen Revision sind, die bereits gepfropft wurden, oder
die Zusammenführungen sind, werden übersprungen.

Wenn --log angegeben ist, wird an Protokollnachrichten ein Kommentar in der Form angehängt:

(gepfropft aus CHANGESETHASH)

Wenn --force angegeben ist, werden Revisionen gepfropft, auch wenn sie bereits Vorfahren von . sind
oder wurden an das Ziel gepfropft. Dies ist nützlich, wenn die Überarbeitungen seit
zurückgetreten worden.

Wenn ein Graft-Merge zu Konflikten führt, wird der Graft-Prozess unterbrochen, so dass die
aktuelle Zusammenführung kann manuell aufgelöst werden. Sobald alle Konflikte angegangen sind, wird das Transplantat
Der Vorgang kann mit der Option -c/--continue fortgesetzt werden.

Hinweis Die Option -c/--continue wendet frühere Optionen mit Ausnahme von --force nicht erneut an.

Beispiele:

· Kopieren Sie eine einzelne Änderung in den Stable-Zweig und bearbeiten Sie ihre Beschreibung:

hg update stabil
hg Transplantat --bearbeiten 9393

· eine Reihe von Changesets mit einer Ausnahme veredeln, Aktualisierungsdaten:

hg-Transplantat -D "2085::2093 und nicht 2091"

· eine Transplantation nach der Lösung von Konflikten fortsetzen:

hg-Transplantat -c

· die Quelle eines gepfropften Changesets anzeigen:

hg log --debug -r .

· Revisionen nach Datum sortiert anzeigen:

hg log -r 'sort(all(), Datum)'

See hg Hilfe Revisionen und hg Hilfe kehrt zurück Weitere Informationen zum Angeben von Revisionen.

Gibt bei erfolgreichem Abschluss 0 zurück.

Zubehör:

-R,--rev
Revisionen zum Transplantat

-C, --fortsetzen
unterbrochenes Transplantat wieder aufnehmen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

--Protokoll Transplantatinformationen an Protokollnachricht anhängen

-F, --Macht
Krafttransplantat

-D, --aktuelles Datum
das aktuelle Datum als Commit-Datum aufzeichnen

-U, --aktuellerBenutzer
den aktuellen Benutzer als Committer eintragen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

-T,--Werkzeug
Zusammenführungswerkzeug angeben

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

[+] markierte Option kann mehrfach angegeben werden

grep
Suche nach einem Muster in bestimmten Dateien und Revisionen:

hg grep [OPTION]... MUSTER [DATEI]...

Durchsuchen Sie Revisionen von Dateien nach einem regulären Ausdruck.

Dieser Befehl verhält sich anders als Unix grep. Es akzeptiert nur Python/Perl-Regexps. Es
durchsucht den Repository-Verlauf, nicht das Arbeitsverzeichnis. Es druckt immer die Revision
Nummer, in der eine Übereinstimmung vorkommt.

Standardmäßig druckt grep nur die Ausgabe für die erste Revision einer Datei, in der es gefunden wird:
Spiel. Damit es jede Revision ausdruckt, die eine Änderung des Match-Status enthält ("-" für a
Übereinstimmung, die zu einer Nichtübereinstimmung wird, oder "+" für eine Nichtübereinstimmung, die zu einer Übereinstimmung wird), verwenden Sie die
--all-Flagge.

Gibt 0 zurück, wenn eine Übereinstimmung gefunden wird, andernfalls 1 zurück.

Zubehör:

-0, --print0
Endfelder mit NUL

--alle Drucken Sie alle Überarbeitungen, die übereinstimmen

-a, --Text
Behandeln Sie alle Dateien als Text

-F, --Folgen
Verfolgen Sie den Änderungsverlauf oder den Dateiverlauf über Kopien und Umbenennungen hinweg

-ich, --Fall ignorieren
ignoriere die Groß-/Kleinschreibung beim Abgleichen

- l, --files-with-matches
nur passende Dateinamen und Revisionen drucken

-nicht, --Zeilennummer
übereinstimmende Zeilennummern drucken

-R,--rev
nur Dateien suchen, die innerhalb des Revisionsbereichs geändert wurden

-du, --Benutzer
den Autor auflisten (lang mit -v)

-D, --Datum
das Datum auflisten (kurz mit -q)

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Köpfe
Filialleiter anzeigen:

hg Köpfe [-ct] [-r STARTREV] [REV]...

Zeigen Sie ohne Argumente alle geöffneten Zweigköpfe im Repository an. Niederlassungsleiter sind
Changesets, die keine Nachkommen im selben Zweig haben. Sie sind dort, wo Entwicklung
findet im Allgemeinen statt und sind die üblichen Ziele für Aktualisierungs- und Zusammenführungsoperationen.

Wenn eine oder mehrere REVs angegeben sind, öffnen Sie nur Zweigstellenköpfe in den Zweigen, die mit der
angegebene Änderungssätze werden angezeigt. Dies bedeutet, dass Sie verwenden können hg Köpfe . um die Köpfe zu sehen
die aktuell ausgecheckte Filiale.

Wenn -c/--closed angegeben ist, werden auch Zweigköpfe als geschlossen angezeigt (siehe hg verpflichten
--Zweig schließen).

Wenn STARTREV angegeben ist, werden nur die Köpfe, die Nachkommen von STARTREV sind
angezeigt.

Wenn -t/--topo angegeben ist, werden benannte Verzweigungsmechaniken ignoriert und nur topologisch
Köpfe (Changesets ohne Kinder) werden angezeigt.

Gibt 0 zurück, wenn übereinstimmende Köpfe gefunden werden, 1, wenn nicht.

Zubehör:

-R,--rev
nur Köpfe anzeigen, die Nachkommen von STARTREV . sind

-T, --topo
Nur topologische Köpfe anzeigen

-a, --aktiv
Nur aktive Verzweigungsköpfe anzeigen (DEPRECATED)

-C, --abgeschlossen
normale und geschlossene Zweigköpfe anzeigen

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

Hilfe
Hilfe zu einem bestimmten Thema oder eine Hilfeübersicht anzeigen:

hg hilfe [-ecks] [TOPIC]

Geben Sie ohne Argumente eine Liste von Befehlen mit kurzen Hilfemeldungen aus.

Wenn ein Thema, eine Erweiterung oder ein Befehlsname angegeben ist, drucken Sie die Hilfe zu diesem Thema.

Gibt 0 zurück, wenn erfolgreich.

Zubehör:

-e, --Verlängerung
Nur Hilfe für Erweiterungen anzeigen

-C, --Befehl
nur Hilfe für Befehle anzeigen

-k, --Stichwort
Themen mit passendem Keyword anzeigen

-S,--System
Hilfe für bestimmte Plattform(en) anzeigen

[+] markierte Option kann mehrfach angegeben werden

identifizieren
Identifizieren Sie das Arbeitsverzeichnis oder die angegebene Revision:

hg identifizieren [-nibtB] [-r REV] [QUELLE]

Drucken Sie eine Zusammenfassung, die den Repository-Status bei REV mit einem oder zwei übergeordneten Hashs identifiziert
Bezeichner, gefolgt von einem "+", wenn das Arbeitsverzeichnis nicht festgeschriebene Änderungen enthält, wird die
Zweigname (wenn nicht Standard), eine Liste mit Tags und eine Liste mit Lesezeichen.

Wenn REV nicht angegeben ist, drucken Sie eine Zusammenfassung des aktuellen Status des Repositorys.

Wenn Sie einen Pfad zu einem Repository-Root oder einem Mercurial-Bundle angeben, wird die Suche ausgeführt
dieses Repository/Bündel.

Beispiele:

· einen Build-Identifier für das Arbeitsverzeichnis generieren:

hg id --id > build-id.dat

· finden Sie die Revision, die einem Tag entspricht:

hg id -n -r 1.3

· Überprüfen Sie die neueste Revision eines Remote-Repositorys:

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

See hg Log zum Generieren weiterer Informationen zu bestimmten Revisionen, einschließlich des vollständigen Hashs
Identifikatoren.

Gibt 0 zurück, wenn erfolgreich.

Zubehör:

-R,--rev
Identifizieren Sie die angegebene Revision

-nicht, --num
lokale Revisionsnummer anzeigen

-ich, --Ich würde
globale Revisions-ID anzeigen

-B, --Zweig
Filiale anzeigen

-T, --Stichworte
Tags anzeigen

-B, --Lesezeichen
Lesezeichen anzeigen

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

Aliase: id

importieren
einen geordneten Satz von Patches importieren:

hg importieren [OPTION]... PATCH...

Importieren Sie eine Liste von Patches und übergeben Sie sie einzeln (sofern --no-commit nicht angegeben ist).

Um ein Patch von der Standardeingabe zu lesen, verwenden Sie "-" als Patch-Name. Wenn eine URL angegeben ist, wird die
Patch wird von dort heruntergeladen.

Import zuerst wendet Änderungen auf das Arbeitsverzeichnis an (es sei denn, --bypass ist angegeben),
Bei ausstehenden Änderungen wird der Import abgebrochen.

Verwenden Sie --bypass, um Patches direkt auf das Repository anzuwenden und zu übertragen, ohne die
Arbeitsverzeichnis. Ohne --exact werden Patches zusätzlich zu den funktionierenden angewendet
Überarbeitung der übergeordneten Verzeichnisse.

Sie können einen Patch direkt aus einer E-Mail-Nachricht importieren. Auch Patches als Anhänge funktionieren (zu
Körperteil verwenden, es muss vom Typ text/plain oder text/x-patch sein). Von und Betreff Überschriften
der E-Mail-Nachricht werden als Standard-Committer und Commit-Nachricht verwendet. Alle Texte/einfacher Text
Teile vor dem ersten Diff werden der Commit-Nachricht hinzugefügt.

Wenn der importierte Patch generiert wurde von hg exportieren, Benutzer und Beschreibung von Patch-Override
Werte aus Nachrichtenheadern und Nachrichtentext. Werte in der Kommandozeile mit -m/--message und
-u/--user überschreibt diese.

Wenn --exact angegeben ist, setzt import das Arbeitsverzeichnis auf das Elternverzeichnis jedes Patches
bevor es angewendet wird, und wird abgebrochen, wenn das resultierende Changeset eine andere ID hat als die
eine im Patch aufgezeichnet. Dies kann aufgrund von Zeichensatzproblemen oder anderen auftreten
Mängel im Textpatchformat.

Verwenden Sie --partial, um sicherzustellen, dass ein Changeset aus dem Patch erstellt wird, auch wenn einige Hunks fehlschlagen
bewerben. Hunks, die sich nicht bewerben, werden an a . geschrieben .rej-Datei. Konflikte
kann dann vorher von Hand gelöst werden hg verpflichten --ändern wird ausgeführt, um das erstellte zu aktualisieren
Änderungssatz. Dieses Flag existiert, damit Leute Patches importieren können, die teilweise ohne zutreffen
Verlust der zugehörigen Metadaten (Autor, Datum, Beschreibung, ...).

Hinweis Wenn keine Hunks sauber auftragen, hg importieren --teilweise erstellt ein leeres Changeset,
nur die Patch-Metadaten importieren.

Mit -s/--similarity versucht hg, Umbenennungen und Kopien im Patch im
genauso wie hg hinzufügenentfernen.

Es ist möglich, externe Patch-Programme zum Ausführen des Patches zu verwenden, indem Sie die ui.patch
Konfigurationsmöglichkeit. Für das standardmäßige interne Tool kann der Fuzz auch über . konfiguriert werden
patch.fuzz. Sehen hg Hilfe Config für weitere Informationen zu Konfigurationsdateien und zur Vorgehensweise
verwenden Sie diese Optionen.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Beispiele:

· einen traditionellen Patch von einer Website importieren und Umbenennungen erkennen:

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

· ein Changeset von einem hgweb-Server importieren:

HG-Import http://www.selenic.com/hg/rev/5ca8c111e9aa

· Importieren Sie alle Patches in eine mbox im Unix-Stil:

hg importieren eingehende-patches.mbox

· versuchen, ein exportiertes Changeset exakt wiederherzustellen (nicht immer möglich):

hg import --genauer vorgeschlagener-fix.patch

· Verwenden Sie ein externes Werkzeug, um einen Patch anzuwenden, der für das interne Standardwerkzeug zu unscharf ist.

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

· Ändern Sie das Standard-Fuzzing von 2 auf ein weniger strenges 7

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

Gibt 0 bei Erfolg zurück, 1 bei Teilerfolg (siehe --partial).

Zubehör:

-P,--Streifen
Verzeichnis-Strip-Option für Patch. Dies hat die gleiche Bedeutung wie das entsprechende
Patch-Option (Standard: 1)

-B,--Base
Basispfad (VERALTET)

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-F, --Macht
Prüfung auf ausstehende, nicht festgeschriebene Änderungen überspringen (DEPRECATED)

--keine Verpflichtung
nicht festlegen, nur das Arbeitsverzeichnis aktualisieren

--Bypass
Patch anwenden, ohne das Arbeitsverzeichnis zu berühren

--teilweise
begehen, auch wenn einige Hunks versagen

--genau
Patch auf die Knoten anwenden, aus denen es generiert wurde

prefix
Patch auf Unterverzeichnis anwenden

--import-Zweig
Verwenden Sie alle Zweiginformationen in Patch (impliziert von --exact)

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

-S,--Ähnlichkeit
umbenannte Dateien nach Ähnlichkeit erraten (0<=s<=100)

Aliase: Patch

eingehende
Neue Änderungssätze anzeigen, die in der Quelle gefunden wurden:

hg eingehend [-p] [-n] [-M] [-f] [-r REV]... [--bundle DATEINAME] [QUELLE]

Zeigen Sie neue Änderungssätze an, die im angegebenen Pfad/der angegebenen URL oder am Standard-Pull-Speicherort gefunden wurden. Diese
sind die Changesets, die bei einem Pull gezogen worden wären, als Sie dies ausgegeben haben
Befehl.

Details zu gültigen Quellformaten finden Sie unter Pull.

Mit -B/--Lesezeichen das Ergebnis des Lesezeichenvergleichs zwischen lokalem und entferntem
Repositorys angezeigt. Mit -v/--verbose wird auch der Status für jedes Lesezeichen angezeigt
Wie unten:

BM1 01234567890a hinzugefügt
BM2 1234567890ab fortgeschritten
BM3 234567890abc divergiert
BM4 34567890abcd geändert

Die beim Ziehen lokal ausgeführte Aktion hängt vom Status jedes Lesezeichens ab:

hinzugefügt

ziehen wird es schaffen

advanced

Pull wird es aktualisieren

divergierte

Pull erstellt ein abweichendes Lesezeichen

geändert

Ergebnis hängt von entfernten Änderungssätzen ab

Aus Sicht des Ziehverhaltens Lesezeichen nur in der Fernbedienung vorhanden
Repository werden behandelt als hinzugefügt, auch wenn es tatsächlich lokal gelöscht wird.

Für ein entferntes Repository vermeidet die Verwendung von --bundle das zweimalige Herunterladen der Änderungssätze, wenn die
auf den Eingang folgt ein Pull.

Beispiele:

· Eingehende Änderungen mit Patches und vollständiger Beschreibung anzeigen:

hg eingehend -vp

· Eingehende Änderungen ohne Zusammenführungen anzeigen, Bündel speichern:

hg in -vpM --bundle eingehend.hg
hg ziehen ankommend.hg

· Änderungen innerhalb eines Bundles kurz auflisten:

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

Gibt bei eingehenden Änderungen 0 zurück, ansonsten 1 zurück.

Zubehör:

-F, --Macht
ausgeführt, auch wenn das Remote-Repository nicht verknüpft ist

-nicht, --das neuste zuerst
neueste Platte zuerst anzeigen

--bündeln
Datei zum Speichern der Bundles in

-R,--rev
ein Remote-Changeset, das hinzugefügt werden soll

-B, --Lesezeichen
Lesezeichen vergleichen

-B,--Zweig
einen bestimmten Zweig, den Sie ziehen möchten

-P, - Patch
Patch anzeigen

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

- l,--Grenze
Anzahl der angezeigten Änderungen begrenzen

-M, --no-merges
Zusammenführungen nicht anzeigen

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

-G, --Graph
zeige die Revision DAG

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

Aliase: in

init
Erstellen Sie ein neues Repository im angegebenen Verzeichnis:

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

Initialisieren Sie ein neues Repository im angegebenen Verzeichnis. Wenn das angegebene Verzeichnis nicht existiert,
es wird erstellt.

Wird kein Verzeichnis angegeben, wird das aktuelle Verzeichnis verwendet.

Es ist möglich, einen . anzugeben ssh:// URL als Ziel. Sehen hg Hilfe urls Für weitere
Informationen.

Gibt bei Erfolg 0 zurück.

Zubehör:

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

lokalisieren
Suchen Sie nach Dateien, die bestimmten Mustern entsprechen (VERALTET):

hg lokalisieren [OPTION]... [MUSTER]...

Drucken Sie Dateien unter der Kontrolle von Mercurial im Arbeitsverzeichnis, deren Namen mit den angegebenen übereinstimmen
Muster.

Standardmäßig durchsucht dieser Befehl alle Verzeichnisse im Arbeitsverzeichnis. Nur suchen
das aktuelle Verzeichnis und seine Unterverzeichnisse verwenden, verwenden Sie "--include .".

Wenn keine passenden Muster angegeben sind, druckt dieser Befehl die Namen aller Dateien unter
Merkurial-Kontrolle im Arbeitsverzeichnis.

Wenn Sie die Ausgabe dieses Befehls in den Befehl "xargs" einspeisen möchten, verwenden Sie die Option -0
sowohl auf diesen Befehl als auch auf "xargs". Dies wird das Problem von "xargs" vermeiden, die Singles behandeln
Dateinamen, die Leerzeichen als mehrere Dateinamen enthalten.

See hg Hilfe Dateien für einen vielseitigeren Befehl.

Gibt 0 zurück, wenn eine Übereinstimmung gefunden wird, andernfalls 1 zurück.

Zubehör:

-R,--rev
Durchsuchen Sie das Repository, wie es in REV . ist

-0, --print0
Dateinamen mit NUL beenden, zur Verwendung mit xargs

-F, --vollständigen Pfad
komplette Pfade aus dem Dateisystem-Root ausgeben

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Log
Revisionsverlauf des gesamten Repositorys oder der Dateien anzeigen:

hg log [OPTION]... [DATEI]

Drucken Sie den Revisionsverlauf der angegebenen Dateien oder des gesamten Projekts.

Wenn kein Revisionsbereich angegeben ist, ist die Standardeinstellung Tipp: 0 es sei denn --follow ist gesetzt, wobei
Falls das übergeordnete Arbeitsverzeichnis als Startrevision verwendet wird.

Der Dateiverlauf wird angezeigt, ohne den Umbenennungs- oder Kopierverlauf von Dateien zu verfolgen. Verwenden Sie -f/--folgen
mit einem Dateinamen, um den Verlauf über Umbenennungen und Kopien hinweg zu verfolgen. --Folge ohne Dateinamen
zeigt nur Vorfahren oder Nachkommen der Startrevision an.

Standardmäßig druckt dieser Befehl Revisionsnummer und Changeset-ID, Tags, nicht trivial
Eltern, Benutzer, Datum und Uhrzeit sowie eine Zusammenfassung für jeden Commit. Wenn der Schalter -v/--verbose
verwendet wird, werden die Liste der geänderten Dateien und die vollständige Commit-Meldung angezeigt.

Mit --graph werden die Revisionen als ASCII-Art-DAG mit dem neuesten Änderungssatz bei . angezeigt
die Spitze. 'o' ist ein Changeset, '@' ist ein übergeordnetes Arbeitsverzeichnis, 'x' ist veraltet und '+'
stellt einen Fork dar, bei dem das Changeset aus den folgenden Zeilen ein Elternteil der 'o'-Zusammenführung ist
die gleiche Zeile.

Note hg Log - Patch kann unerwartete diff-Ausgaben für Merge-Changesets erzeugen, da dies der Fall ist
Vergleichen Sie nur das Merge-Änderungsset mit seinem ersten übergeordneten Element. Auch nur Dateien
anders als BEIDE Eltern erscheinen in Dateien:.

Hinweis Aus Performancegründen hg Log FILE kann doppelte Änderungen an Zweigen auslassen
und zeigt keine Entfernungen oder Modusänderungen an. Um all diese Änderungen anzuzeigen, verwenden Sie die
--Schalter entfernt.

Einige Beispiele:

· Changesets mit vollständigen Beschreibungen und Dateilisten:

hg log -v

· Changesets Vorfahren des Arbeitsverzeichnisses:

hg log -f

· die letzten 10 Commits im aktuellen Branch:

hg log -l 10 -b .

· Changesets, die alle Änderungen einer Datei anzeigen, einschließlich Entfernungen:

hg log --entfernte Datei.c

· alle Changesets, die ein Verzeichnis berühren, mit Diffs, außer Zusammenführungen:

hg log -MP lib/

· alle Revisionsnummern, die einem Schlüsselwort entsprechen:

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

· die vollständige Hash-Kennung des übergeordneten Arbeitsverzeichnisses:

hg log -r . --template "{node}\n"

· Verfügbare Protokollvorlagen auflisten:

hg log -T-Liste

· Überprüfen Sie, ob ein bestimmtes Changeset in einem markierten Release enthalten ist:

hg log -r "a21ccf und Vorfahre(1.9)"

· alle Änderungssätze eines Benutzers in einem Datumsbereich finden:

hg log -k alice -d "Mai 2008 bis Juli 2008"

· Zusammenfassung aller Changesets nach dem letzten Tag:

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

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

See hg Hilfe Revisionen und hg Hilfe kehrt zurück für mehr über spezifizieren und bestellen
Überarbeitungen.

See hg Hilfe Vorlagen Weitere Informationen zu vorgefertigten Stilen und zum Angeben benutzerdefinierter Vorlagen.

Gibt bei Erfolg 0 zurück.

Zubehör:

-F, --Folgen
Verfolgen Sie den Änderungsverlauf oder den Dateiverlauf über Kopien und Umbenennungen hinweg

--folgen-zuerst
Folgen Sie nur dem ersten übergeordneten Element von Merge-Changesets (DEPRECATED)

-D,--Datum
Überarbeitungen anzeigen, die der Datumsspezifikation entsprechen

-VS, --Kopien
kopierte Dateien anzeigen

-k,--Stichwort
Suche nach einem bestimmten Text ohne Berücksichtigung der Groß-/Kleinschreibung

-R,--rev
zeige die angegebene Revision oder Revset

--ENTFERNT
Überarbeitungen einschließen, bei denen Dateien entfernt wurden

-M, --only-merges
Nur Zusammenführungen anzeigen (DEPRECATED)

-du,--Benutzer
Überarbeitungen, die vom Benutzer festgelegt wurden

--only-Zweig
nur Changesets innerhalb des angegebenen benannten Zweigs anzeigen (DEPRECATED)

-B,--Zweig
Änderungsmengen innerhalb des angegebenen benannten Zweigs anzeigen

-P,--Pflaume
keine Revision oder einen ihrer Vorfahren anzeigen

-P, - Patch
Patch anzeigen

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

- l,--Grenze
Anzahl der angezeigten Änderungen begrenzen

-M, --no-merges
Zusammenführungen nicht anzeigen

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

-G, --Graph
zeige die Revision DAG

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Aliase: Geschichte

Manifest
die aktuelle oder gegebene Revision des Projektmanifests ausgeben:

hg-Manifest [-r REV]

Drucken Sie eine Liste von versionierten Dateien für die angegebene Revision. Wenn keine Revision angegeben ist,
der erste Elternteil des Arbeitsverzeichnisses wird verwendet, oder die Null-Revision, wenn keine Revision vorhanden ist
geprüft.

Mit -v können Sie Dateiberechtigungen, Symlinks und ausführbare Bits drucken. Mit --debug Datei drucken
Überarbeitungs-Hashes.

Wenn die Option --all angegeben ist, wird die Liste aller Dateien aus allen Revisionen gedruckt. Dies
enthält gelöschte und umbenannte Dateien.

Gibt bei Erfolg 0 zurück.

Zubehör:

-R,--rev
Überarbeitung anzuzeigen

--alle Dateien aller Revisionen auflisten

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

fusionieren
Merge eine andere Revision in das Arbeitsverzeichnis:

hg zusammenführen [-P] [[-r] REV]

Das aktuelle Arbeitsverzeichnis wird mit allen Änderungen aktualisiert, die in der angeforderten Revision vorgenommen wurden
seit der letzten gemeinsamen Vorgängerrevision.

Dateien, die sich zwischen einem der Eltern geändert haben, werden für den nächsten Commit als geändert markiert und a
Commit muss ausgeführt werden, bevor weitere Aktualisierungen des Repositorys zugelassen werden. Die
Der nächste Commit wird zwei Eltern haben.

--Werkzeug kann verwendet werden, um das Zusammenführungswerkzeug anzugeben, das für Dateizusammenführungen verwendet wird. Es überschreibt die
HGMERGE-Umgebungsvariable und Ihre Konfigurationsdateien. Sehen hg Hilfe Merge-Tools für
Optionen.

Wenn keine Revision angegeben ist, ist das Elternverzeichnis des Arbeitsverzeichnisses eine Hauptrevision, und die
Der aktuelle Zweig enthält genau einen anderen Kopf, mit dem der andere Kopf standardmäßig zusammengeführt wird.
Andernfalls muss eine explizite Revision angegeben werden, mit der zusammengeführt werden soll.

See hg Hilfe lösen für Informationen zum Umgang mit Dateikonflikten.

Um eine nicht festgeschriebene Zusammenführung rückgängig zu machen, verwenden Sie hg Aktualisierung --sauber . die eine saubere Kopie von auschecken wird
das ursprüngliche Merge-Elternteil, wobei alle Änderungen verloren gehen.

Gibt bei Erfolg 0 zurück, 1 wenn nicht aufgelöste Dateien vorhanden sind.

Zubehör:

-F, --Macht
Zusammenführung erzwingen, einschließlich ausstehender Änderungen (VERALTET)

-R,--rev
Überarbeitung zum Zusammenführen

-P, --Vorschau
Revisionen zum Zusammenführen überprüfen (es wird keine Zusammenführung durchgeführt)

-T,--Werkzeug
Zusammenführungswerkzeug angeben

abgehenden
show changesets nicht im Ziel gefunden:

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

Changesets anzeigen, die nicht im angegebenen Ziel-Repository oder im Standard-Push gefunden wurden
Lage. Dies sind die Changesets, die gepusht würden, wenn ein Push angefordert würde.

Weitere Informationen zu gültigen Zielformaten finden Sie unter Pull.

Mit -B/--Lesezeichen das Ergebnis des Lesezeichenvergleichs zwischen lokalem und entferntem
Repositorys angezeigt. Mit -v/--verbose wird auch der Status für jedes Lesezeichen angezeigt
Wie unten:

BM1 01234567890a hinzugefügt
BM2 gelöscht
BM3 234567890abc fortgeschritten
BM4 34567890abcd divergiert
BM5 4567890abcde geändert

Die beim Drücken ausgeführte Aktion hängt vom Status jedes Lesezeichens ab:

hinzugefügt

schieben mit -B werde es schaffen

gelöscht

schieben mit -B werde es löschen

advanced

push wird es aktualisieren

divergierte

schieben mit -B werde es aktualisieren

geändert

schieben mit -B werde es aktualisieren

Aus Sicht des Schiebeverhaltens existieren Lesezeichen nur in der Fernbedienung
Repository werden behandelt als gelöscht, auch wenn es tatsächlich aus der Ferne hinzugefügt wird.

Gibt 0 zurück, wenn es ausgehende Änderungen gibt, andernfalls 1 zurück.

Zubehör:

-F, --Macht
laufen, auch wenn das Ziel nicht verwandt ist

-R,--rev
ein Änderungsset, das in das Ziel aufgenommen werden soll

-nicht, --das neuste zuerst
neueste Platte zuerst anzeigen

-B, --Lesezeichen
Lesezeichen vergleichen

-B,--Zweig
eine bestimmte Filiale, die Sie pushen möchten

-P, - Patch
Patch anzeigen

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

- l,--Grenze
Anzahl der angezeigten Änderungen begrenzen

-M, --no-merges
Zusammenführungen nicht anzeigen

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

-G, --Graph
zeige die Revision DAG

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

Aliase: out

Eltern
die Eltern des Arbeitsverzeichnisses oder der Revision anzeigen (VERALTET):

hg Eltern [-r REV] [DATEI]

Drucken Sie die übergeordneten Revisionen des Arbeitsverzeichnisses. Wird über -r/--rev eine Revision angegeben, wird die
übergeordnetes Element dieser Revision wird gedruckt. Wenn ein Dateiargument angegeben ist, wird die Revision in
welche Datei zuletzt geändert wurde (vor der Revision des Arbeitsverzeichnisses oder dem Argument zu
--rev, falls angegeben) wird ausgegeben.

Dieser Befehl ist äquivalent zu:

hg log -r "p1()+p2()" oder
hg log -r "p1(REV)+p2(REV)" oder
hg log -r "max(::p1() und Datei(DATEI))+max(::p2() und Datei(DATEI))" oder
hg log -r "max(::p1(REV) und Datei(DATEI))+max(::p2(REV) und Datei(DATEI))"

See hg Zusammenfassung und hg Hilfe kehrt zurück für verwandte Informationen.

Gibt bei Erfolg 0 zurück.

Zubehör:

-R,--rev
Eltern der angegebenen Revision anzeigen

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

Pfade
Aliase für Remote-Repositorys anzeigen:

hg-Pfade [NAME]

Definition des symbolischen Pfadnamens NAME anzeigen. Wenn kein Name angegeben ist, zeige die Definition von all
verfügbaren Namen.

Option -q/--quiet unterdrückt alle Ausgaben bei der Suche nach NAME und zeigt nur den Pfad an
Namen, wenn Sie alle Definitionen auflisten.

Pfadnamen werden im Abschnitt [paths] Ihrer Konfigurationsdatei und in
/etc/mercurial/hgrc. Bei Ausführung in einem Repository .hg/hgrc wird auch verwendet.

Die Pfadnamen Standard und Standard-Push eine besondere Bedeutung haben. Beim Ausführen eines Pushs oder
Pull-Operation, sie werden als Fallbacks verwendet, wenn kein Ort auf der
Befehlszeile. Wann Standard-Push gesetzt ist, wird es für Push und . verwendet Standard wird verwendet
zum Ziehen; Andernfalls Standard wird für beide als Fallback verwendet. Beim Klonen eines Repositorys
die Klonquelle ist geschrieben als Standard in .hg/hgrc.

Note Standard und Standard-Push gelten für alle eingehenden (z hg eingehende) und ausgehende
(z.B hg abgehenden, hg E-Mail und hg bündeln) Operationen.

See hg Hilfe urls um mehr zu erfahren.

Gibt bei Erfolg 0 zurück.

Zubehör:

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

Phase
den aktuellen Phasennamen einstellen oder anzeigen:

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

Zeigen Sie ohne Argument den Phasennamen der aktuellen Revision(en) an.

Ändern Sie mit einem von -p/--public, -d/--draft oder -s/--secret den Phasenwert des
angegebenen Revisionen.

Sofern -f/--force nicht angegeben ist, hg Phase wird Changeset nicht von einer niedrigeren Phase in eine verschieben
höhere Phase. Die Phasen sind wie folgt geordnet:

öffentlich < Entwurf < geheim

Gibt bei Erfolg 0 zurück, 1 wenn einige Phasen nicht geändert werden konnten.

(Weitere Informationen zum Phasenkonzept finden Sie unter hg Hilfe Phasen.)

Zubehör:

-P, --öffentlich
setze die changeset-Phase auf öffentlich

-D, --Luftzug
setze changeset phase auf Draft

-S, --Geheimnis
setze changeset phase auf geheim

-F, --Macht
erlauben, die Grenze nach hinten zu verschieben

-R,--rev
Zielüberarbeitung

[+] markierte Option kann mehrfach angegeben werden

ziehen
Pull-Änderungen aus der angegebenen Quelle:

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

Ziehen Sie Änderungen von einem Remote-Repository in ein lokales.

Dies findet alle Änderungen aus dem Repository unter dem angegebenen Pfad oder der angegebenen URL und fügt sie zu a
lokales Repository (das aktuelle, sofern nicht -R angegeben ist). Standardmäßig ist dies nicht
Aktualisieren Sie die Kopie des Projekts im Arbeitsverzeichnis.

Verwenden Sie die hg eingehende wenn Sie sehen möchten, was durch einen Pull zu dem Zeitpunkt hinzugefügt worden wäre, an dem Sie
diesen Befehl ausgegeben. Wenn Sie sich dann entscheiden, diese Änderungen zum Repository hinzuzufügen, sollten Sie
- hg ziehen -r X woher X ist das letzte Änderungsset, das von . aufgeführt ist hg eingehende.

Wenn SOURCE weggelassen wird, wird der 'Standard'-Pfad verwendet. Sehen hg Hilfe urls Für weitere
Informationen.

Gibt bei Erfolg 0 zurück, 1 wenn ein Update unaufgelöste Dateien hatte.

Zubehör:

-du, --aktualisieren
Update auf neuen Zweigkopf, wenn Changesets gezogen wurden

-F, --Macht
ausgeführt, auch wenn das Remote-Repository nicht verknüpft ist

-R,--rev
ein Remote-Changeset, das hinzugefügt werden soll

-B,--Lesezeichen
Lesezeichen zum Ziehen

-B,--Zweig
einen bestimmten Zweig, den Sie ziehen möchten

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

drücken
Push-Änderungen an das angegebene Ziel:

hg drücken [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]

Verschieben Sie Changesets aus dem lokalen Repository an das angegebene Ziel.

Dieser Vorgang ist symmetrisch zum Ziehen: Er ist identisch mit einem Ziehen am Ziel
Repository aus dem aktuellen.

Standardmäßig erlaubt Push keine Erstellung neuer Köpfe am Ziel, da mehrere
Köpfe würde es unklar machen, welcher Kopf verwendet werden soll. In dieser Situation wird empfohlen,
ziehen und zusammenführen, bevor Sie drücken.

Verwenden Sie --new-branch, wenn Sie Push erlauben möchten, einen neuen benannten Branch zu erstellen, der nicht
am Zielort vorhanden. Dadurch können Sie nur einen neuen Zweig erstellen, ohne zu erzwingen
andere Änderungen.

Hinweis Besondere Vorsicht ist bei der Option -f/--force geboten, die alle neuen pusht
Köpfe auf allen Ästen, eine Aktion, die fast immer für Verwirrung sorgen wird
Mitarbeiter.

Wenn -r/--rev verwendet wird, werden die angegebene Revision und alle ihre Vorfahren an die
Remote-Repository.

Wenn -B/--bookmark verwendet wird, werden die angegebene mit einem Lesezeichen versehene Revision, ihre Vorfahren und die
Lesezeichen werden an das Remote-Repository gepusht.

Bitte ansehen hg Hilfe urls für wichtige Details zu ssh:// URLs. Wenn ZIEL ist
weggelassen, wird ein Standardpfad verwendet.

Gibt 0 zurück, wenn Push erfolgreich war, 1 wenn nichts zu pushen ist.

Zubehör:

-F, --Macht
erzwingen

-R,--rev
ein Änderungsset, das in das Ziel aufgenommen werden soll

-B,--Lesezeichen
Lesezeichen zum Drücken

-B,--Zweig
eine bestimmte Filiale, die Sie pushen möchten

--Neue Abteilung
erlauben, einen neuen Zweig zu pushen

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

erholen
Rollback einer unterbrochenen Transaktion:

hg erholen

Wiederherstellen nach einem unterbrochenen Commit oder Pull.

Dieser Befehl versucht, den Repository-Status nach einer unterbrochenen Operation zu korrigieren. Es sollte
nur notwendig sein, wenn Mercurial es vorschlägt.

Gibt 0 zurück, wenn erfolgreich, 1, wenn nichts wiederherzustellen oder zu überprüfen fehlschlägt.

entfernen
Entfernen Sie die angegebenen Dateien beim nächsten Commit:

hg entfernen [OPTION]... DATEI...

Planen Sie die angegebenen Dateien zum Entfernen aus dem aktuellen Zweig ein.

Dieser Befehl plant, dass die Dateien beim nächsten Commit entfernt werden. Entfernen rückgängig machen
vorher siehe hg zurückkehren. Informationen zum Rückgängigmachen hinzugefügter Dateien finden Sie unter hg vergessen.

-A/--after kann verwendet werden, um nur Dateien zu entfernen, die bereits gelöscht wurden, -f/--force kann
verwendet werden, um das Löschen zu erzwingen, und -Af kann verwendet werden, um Dateien aus der nächsten Revision zu entfernen
ohne sie aus dem Arbeitsverzeichnis zu löschen.

Die folgende Tabelle beschreibt das Verhalten von remove für verschiedene Dateistatus (Spalten) und
Optionskombinationen (Reihen). Die Dateistatus sind Hinzugefügt [A], Clean [C], Modified [M] und
Fehlende [!] (wie berichtet von hg Status). Die Aktionen sind Warnen, Entfernen (aus Zweig) und
Löschen (von Datenträger):

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

Note hg entfernen löscht niemals Dateien im Status [A] hinzugefügt aus dem Arbeitsverzeichnis, nicht
selbst wenn --Macht angegeben.

Gibt 0 bei Erfolg zurück, 1 wenn Warnungen aufgetreten sind.

Zubehör:

-EIN, --nach
Datensatz löschen für fehlende Dateien

-F, --Macht
Datei entfernen (und löschen), auch wenn sie hinzugefügt oder geändert wurde

-S, --subrepos
Rekurs in Unterverzeichnisse

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Aliase: rm

umbenennen
Dateien umbenennen; Äquivalent von kopieren + entfernen:

hg umbenennen [OPTION]... QUELLE... DEST

dest als Kopien von Quellen markieren; Quellen zum Löschen markieren. Wenn dest ein Verzeichnis ist, wird kopiert
werden in diesem Verzeichnis abgelegt. Wenn dest eine Datei ist, kann es nur eine Quelle geben.

Standardmäßig kopiert dieser Befehl den Inhalt von Dateien, wie sie in der Arbeitsumgebung vorhanden sind
Verzeichnis. Bei Aufruf mit -A/--after wird der Vorgang aufgezeichnet, aber kein Kopieren
durchgeführt.

Dieser Befehl wird beim nächsten Commit wirksam. Um eine vorherige Umbenennung rückgängig zu machen, siehe hg zurückkehren.

Gibt 0 bei Erfolg zurück, 1 wenn Fehler aufgetreten sind.

Zubehör:

-EIN, --nach
eine bereits erfolgte Umbenennung aufzeichnen

-F, --Macht
erzwungenes Kopieren über eine vorhandene verwaltete Datei

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

[+] markierte Option kann mehrfach angegeben werden

Aliase: Move mv

lösen
Zusammenführungen wiederholen oder den Zusammenführungsstatus von Dateien festlegen/anzeigen:

hg auflösen [OPTION]... [DATEI]...

Zusammenführungen mit ungelösten Konflikten sind oft das Ergebnis einer nicht interaktiven Zusammenführung mit dem
intern:zusammenführen Konfigurationseinstellung oder ein Befehlszeilen-Merge-Tool wie diff3. Die Entschlossenheit
Befehl wird verwendet, um die an einer Zusammenführung beteiligten Dateien zu verwalten, nachdem hg fusionieren ausgeführt wurde, und
Bevor hg verpflichten ausgeführt wird (dh das Arbeitsverzeichnis muss zwei Eltern haben). Sehen hg Hilfe
Merge-Tools Informationen zum Konfigurieren von Zusammenführungstools.

Der Auflösungsbefehl kann auf folgende Weise verwendet werden:

· hg lösen [--Werkzeug WERKZEUG] DATEI...: Versuch, die angegebenen Dateien erneut zusammenzuführen, verwerfen
alle vorherigen Zusammenführungsversuche. Für Dateien, die bereits als . markiert sind, wird keine erneute Zusammenführung durchgeführt
aufgelöst. Benutzen --alle/-a um alle nicht aufgelösten Dateien auszuwählen. --Werkzeug kann verwendet werden, um die
Merge-Tool, das für die angegebenen Dateien verwendet wird. Sie überschreibt die Umgebungsvariable HGMERGE und
Ihre Konfigurationsdateien. Vorherige Dateiinhalte werden mit a . gespeichert .orig Suffix.

· hg lösen -m [DATEI]: eine Datei als gelöst markieren (zB nachdem sie manuell
die Dateien repariert). Standardmäßig werden alle nicht aufgelösten Dateien markiert.

· hg lösen -u [DATEI]...: eine Datei als nicht aufgelöst markieren. Standardmäßig werden alle gelöst markiert
Dateien.

· hg lösen -l: Dateien auflisten, die Konflikte hatten oder noch haben. In der gedruckten Liste U =
ungelöst und R = gelöst.

Hinweis Mercurial lässt Sie keine Dateien mit ungelösten Zusammenführungskonflikten festschreiben. Du musst
- hg lösen -m ... bevor Sie nach einem widersprüchlichen Merge einen Commit durchführen können.

Gibt 0 bei Erfolg zurück, 1 wenn ein Auflösungsversuch bei Dateien fehlschlägt.

Zubehör:

-a, --alle
wähle alle unaufgelösten Dateien aus

- l, --aufführen
Listenstatus der Dateien, die zusammengeführt werden müssen

-M, --Markierung
Dateien als gelöst markieren

-du, --Markierung aufheben
Dateien als nicht aufgelöst markieren

-nicht, --kein Status
Statuspräfix ausblenden

-T,--Werkzeug
Zusammenführungswerkzeug angeben

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

[+] markierte Option kann mehrfach angegeben werden

zurückkehren
Dateien in den Checkout-Status wiederherstellen:

hg zurück [OPTION]... [-r REV] [NAME]...

Hinweis Um frühere Revisionen auszuchecken, sollten Sie hg Aktualisierung REV. Um eine zu stornieren
nicht festgeschriebenes Zusammenführen (und Ihre Änderungen verlieren), verwenden Sie hg Aktualisierung --sauber ..

Wenn keine Revision angegeben ist, setzen Sie die angegebenen Dateien oder Verzeichnisse auf den Inhalt zurück, den sie
im übergeordneten Verzeichnis des Arbeitsverzeichnisses hatte. Dadurch wird der Inhalt von Dateien wiederhergestellt
unveränderter Zustand und außerplanmäßiges Hinzufügen, Entfernen, Kopieren und Umbenennen. Wenn das funktioniert
Verzeichnis zwei Eltern hat, müssen Sie explizit eine Revision angeben.

Verwenden Sie die Optionen -r/--rev oder -d/--date, um die angegebenen Dateien oder Verzeichnisse auf ihre
Zustände ab einer bestimmten Überarbeitung. Weil revert das Arbeitsverzeichnis nicht ändert
Eltern, dies führt dazu, dass diese Dateien geändert erscheinen. Dies kann hilfreich sein, um "zurückzugehen"
einige oder alle einer früheren Änderung. Sehen hg zurücktreten für eine verwandte Methode.

Geänderte Dateien werden mit einem .orig-Suffix gespeichert, bevor sie zurückgesetzt werden. Um diese Sicherungen zu deaktivieren,
Verwenden Sie --no-backup.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

See hg Hilfe zurücktreten um den Effekt eines früheren Changesets umzukehren.

Gibt bei Erfolg 0 zurück.

Zubehör:

-a, --alle
alle Änderungen rückgängig machen, wenn keine Argumente angegeben sind

-D,--Datum
tippmost Überarbeitungsabgleichdatum

-R,--rev
zur angegebenen Revision zurückkehren

-VS, --keine Sicherung
keine Sicherungskopien von Dateien speichern

-ich, --interaktiv
die Änderungen interaktiv auswählen (EXPERIMENTELL)

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

[+] markierte Option kann mehrfach angegeben werden

Rollback
Rollback der letzten Transaktion (GEFÄHRLICH) (VERALTET):

Hg Rollback

Benutzen Sie bitte hg verpflichten --ändern anstelle eines Rollbacks, um Fehler im letzten Commit zu korrigieren.

Dieser Befehl sollte mit Vorsicht verwendet werden. Es gibt nur eine Rollback-Ebene, und zwar
keine Möglichkeit, ein Rollback rückgängig zu machen. Es wird auch den Schmutz zum Zeitpunkt der letzten wiederherstellen
Transaktion, wobei alle schwerwiegenden Änderungen seit dieser Zeit verloren gehen. Dieser Befehl ändert nichts an der
Arbeitsverzeichnis.

Transaktionen werden verwendet, um die Auswirkungen aller Befehle zu kapseln, die neue erstellen
Changesets oder propagieren vorhandener Changesets in ein Repository.

Die folgenden Befehle sind beispielsweise transaktional und ihre Auswirkungen können gewürfelt werden
zurück:

· verpflichten

· importieren

· ziehen

· push (mit diesem Repository als Ziel)

· entbündeln

Um dauerhaften Datenverlust zu vermeiden, wird Rollback das Rollback einer Commit-Transaktion verweigern, wenn es
ist nicht ausgecheckt. Verwenden Sie --force, um diesen Schutz zu überschreiben.

Dieser Befehl ist nicht für die Verwendung in öffentlichen Repositorys vorgesehen. Sobald Änderungen sichtbar sind für
Pull durch andere Benutzer, ist das Zurücksetzen einer Transaktion lokal wirkungslos (jemand anderes kann
habe die Änderungen bereits gezogen). Außerdem ist ein Rennen mit Lesern der
Repository; zum Beispiel kann ein laufender Pull aus dem Repository fehlschlagen, wenn ein Rollback
durchgeführt.

Gibt bei Erfolg 0 zurück, 1 wenn keine Rollback-Daten verfügbar sind.

Zubehör:

-nicht, --Probelauf
keine Aktionen ausführen, nur Ausgabe drucken

-F, --Macht
Sicherheitsmaßnahmen ignorieren

Wurzel
Drucken Sie das Stammverzeichnis (oben) des aktuellen Arbeitsverzeichnisses:

hg Wurzel

Drucken Sie das Stammverzeichnis des aktuellen Repositorys.

Gibt bei Erfolg 0 zurück.

brauchen
eigenständigen Webserver starten:

hg servieren [OPTION]...

Starten Sie einen lokalen HTTP-Repository-Browser und ziehen Sie den Server. Sie können dies für die Ad-hoc-Freigabe verwenden
und Durchsuchen von Repositorys. Es wird empfohlen, einen echten Webserver zu verwenden, um a
für längere Zeit lagern.

Bitte beachten Sie, dass der Server keine Zugriffskontrolle implementiert. Dies bedeutet, dass durch
Standardmäßig kann jeder vom Server lesen und niemand kann standardmäßig darauf schreiben. Stellen Sie die
web.allow_push Option zu * damit jeder auf den Server pushen kann. Sie sollten ein echtes verwenden
Webserver, wenn Sie Benutzer authentifizieren müssen.

Standardmäßig protokolliert der Server Zugriffe auf stdout und Fehler auf stderr. Verwenden Sie die
-A/--accesslog und -E/--errorlog Optionen zum Protokollieren in Dateien.

Damit der Server eine freie Portnummer zum Abhören auswählt, geben Sie eine Portnummer von 0 an; in
In diesem Fall druckt der Server die von ihm verwendete Portnummer.

Gibt bei Erfolg 0 zurück.

Zubehör:

-EIN,--Zugriffsprotokoll
Name der Zugriffsprotokolldatei, in die geschrieben werden soll

-D, --dämon
Server im Hintergrund ausführen

--daemon-pipefds
Wird intern vom Daemon-Modus verwendet

-IS,--Fehlerprotokoll
Name der Fehlerprotokolldatei, in die geschrieben werden soll

-P,--Hafen
Port zum Abhören (Standard: 8000)

-a,--die Anschrift
Adresse zum Abhören (Standard: alle Schnittstellen)

prefix
Präfix-Pfad, von dem aus bedient werden soll (Standard: Server-Root)

-nicht,--Name
Name, der in Webseiten angezeigt werden soll (Standard: Arbeitsverzeichnis)

--web-conf
Name der hgweb-Konfigurationsdatei (siehe "hg help hgweb")

--webdir-conf
Name der hgweb-Konfigurationsdatei (VERALTET)

--pid-Datei
Name der Datei, in die die Prozess-ID geschrieben werden soll

--stdio
für Remote-Clients

--cmdserver
für Remote-Clients

-T,--Vorlagen
zu verwendende Webvorlagen

--Stil
Vorlagenstil zu verwenden

-6, --ipv6
IPv6 zusätzlich zu IPv4 verwenden

--Zertifikat
SSL-Zertifikatsdatei

Status
Geänderte Dateien im Arbeitsverzeichnis anzeigen:

hg-Status [OPTION]... [DATEI]...

Status der Dateien im Repository anzeigen. Wenn Namen angegeben werden, werden nur übereinstimmende Dateien
gezeigt. Dateien, die sauber oder ignoriert sind oder die Quelle eines Kopier-/Verschiebungsvorgangs sind, sind nicht
aufgeführt, es sei denn, -c/--clean, -i/--ignored, -C/--copys oder -A/--all sind angegeben. Es sei denn, Optionen
mit "show only ..." beschrieben sind, werden die Optionen -mardu verwendet.

Option -q/--quiet versteckt nicht verfolgte (unbekannte und ignorierte) Dateien, es sei denn, dies wird ausdrücklich angefordert
mit -u/--unknown oder -i/--ignored.

Note hg Status kann mit diff nicht übereinstimmen, wenn sich die Berechtigungen geändert haben oder eine Zusammenführung erfolgt
ist vorgefallen. Das Standard-Diff-Format meldet keine Berechtigungsänderungen und Diff
meldet nur Änderungen relativ zu einem Merge-Elternteil.

Wenn eine Revision angegeben ist, wird diese als Basisrevision verwendet. Wenn zwei Revisionen angegeben sind,
die Unterschiede zwischen ihnen werden gezeigt. Die Option --change kann auch als Verknüpfung verwendet werden
um die geänderten Dateien einer Revision von ihrem ersten Elternteil aufzulisten.

Die Codes, die verwendet werden, um den Status von Dateien anzuzeigen, sind:

M = modifiziert
A = hinzugefügt
R = entfernt
C = sauber
! = fehlt (von non-hg-Befehl gelöscht, aber noch verfolgt)
? = nicht verfolgt
ich = ignoriert
= Ursprung der vorherigen Datei (mit --copies)

Beispiele:

· Änderungen im Arbeitsverzeichnis relativ zu einem Changeset anzeigen:

hg-Status --rev 9353

· Änderungen im Arbeitsverzeichnis relativ zum aktuellen Verzeichnis anzeigen (siehe hg Hilfe
Muster für mehr Informationen):

hg-Status zu:

· alle Änderungen einschließlich Kopien in einem bestehenden Changeset anzeigen:

hg status --copys --change 9353

· eine NUL-separierte Liste von hinzugefügten Dateien erhalten, geeignet für xargs:

hg-Status -an0

Gibt bei Erfolg 0 zurück.

Zubehör:

-EIN, --alle
Status aller Dateien anzeigen

-M, --geändert
nur geänderte Dateien anzeigen

-a, --hinzugefügt
nur hinzugefügte Dateien anzeigen

-R, --ENTFERNT
Nur entfernte Dateien anzeigen

-D, --gelöscht
nur gelöschte (aber verfolgte) Dateien anzeigen

-C, --sauber
nur Dateien ohne Änderungen anzeigen

-du, --Unbekannt
nur unbekannte (nicht verfolgte) Dateien anzeigen

-ich, --ignoriert
nur ignorierte Dateien anzeigen

-nicht, --kein Status
Statuspräfix ausblenden

-VS, --Kopien
Quelle der kopierten Dateien anzeigen

-0, --print0
Dateinamen mit NUL beenden, zur Verwendung mit xargs

--rev
Unterschied zur Revision anzeigen

--Veränderung
die geänderten Dateien einer Revision auflisten

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-S, --subrepos
Rekurs in Unterverzeichnisse

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

[+] markierte Option kann mehrfach angegeben werden

Decknamen: st

Zusammenfassung
den Status des Arbeitsverzeichnisses zusammenfassen:

hg-Zusammenfassung [--remote]

Dadurch wird eine kurze Zusammenfassung des Status des Arbeitsverzeichnisses generiert, einschließlich Eltern, Zweig,
Commit-Status, Phase und verfügbare Updates.

Mit der Option --remote werden die Standardpfade für eingehende und ausgehende überprüft
Änderungen. Dies kann zeitaufwendig sein.

Gibt bei Erfolg 0 zurück.

Zubehör:

--Fernbedienung
auf Push und Pull prüfen

Aliase: Summe

Etikett
Fügen Sie ein oder mehrere Tags für die aktuelle oder gegebene Revision hinzu:

hg tag [-f] [-l] [-m TEXT] [-d DATUM] [-u BENUTZER] [-r REV] NAME...

Benennen Sie eine bestimmte Revision mit .

Tags werden verwendet, um bestimmte Revisionen des Repositorys zu benennen und sind sehr nützlich für
verschiedene Revisionen vergleichen, zu bedeutenden früheren Versionen zurückkehren oder Verzweigungen markieren
Punkte als Freigaben usw. Das Ändern eines bestehenden Tags ist normalerweise nicht erlaubt; benutze -f/--force
überschreiben.

Wenn keine Revision angegeben ist, wird das Elternverzeichnis des Arbeitsverzeichnisses verwendet.

Um die Versionskontrolle, Verteilung und Zusammenführung von Tags zu erleichtern, werden sie als
Datei namens ".hgtags", die ähnlich wie andere Projektdateien verwaltet wird und
bei Bedarf handbearbeitet. Dies bedeutet auch, dass das Tagging einen neuen Commit erstellt. Die Datei
".hg/localtags" wird für lokale Tags verwendet (nicht von Repositorys geteilt).

Tag-Commits werden normalerweise am Anfang eines Branchs vorgenommen. Wenn der Elternteil des arbeitenden
Verzeichnis ist kein Zweigleiter, hg Etikett bricht ab; Verwenden Sie -f/--force, um das Tag-Commit zu erzwingen
auf einem Nicht-Kopf-Changeset basieren.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Da Tag-Namen bei der Revisionssuche Vorrang vor Verzweigungsnamen haben, ist die Verwendung eines vorhandenen
Zweigname als Tag-Name wird nicht empfohlen.

Gibt bei Erfolg 0 zurück.

Zubehör:

-F, --Macht
Tag erzwingen

- l, --lokal
mach das tag lokal

-R,--rev
Überarbeitung zum Tag

--Löschen
ein Tag entfernen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-M,--Botschaft
Text als Commit-Nachricht verwenden

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

Tags
Repository-Tags auflisten:

Hg-Tags

Dies listet sowohl reguläre als auch lokale Tags auf. Wenn der Schalter -v/--verbose verwendet wird, wird ein dritter
Spalte "local" wird für lokale Tags gedruckt. Bei Verwendung des Schalters -q/--quiet werden nur die
Tag-Name wird gedruckt.

Gibt bei Erfolg 0 zurück.

Zubehör:

-T,--Vorlage
Anzeige mit Vorlage (EXPERIMENTELL)

Tip
Tipp-Revision anzeigen (VERALTET):

hg-Tipp [-p] [-g]

Die Tipp-Revision (normalerweise nur Tipp genannt) ist das Änderungsset, das zuletzt dem hinzugefügt wurde
Repository (und damit der zuletzt geänderte Head).

Wenn Sie gerade einen Commit gemacht haben, ist dieser Commit der Tipp. Wenn du gerade gezogen hast
von einem anderen Repository ändert, wird der Tipp dieses Repositorys zum aktuellen Tipp. Der
Das Tag "tip" ist speziell und kann nicht umbenannt oder einem anderen Changeset zugewiesen werden.

Dieser Befehl ist veraltet, bitte verwenden Sie hg Köpfe stattdessen.

Gibt bei Erfolg 0 zurück.

Zubehör:

-P, - Patch
Patch anzeigen

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

aufschlüsseln
Wenden Sie eine oder mehrere Changegroup-Dateien an:

hg entbündeln [-u] DATEI...

Wenden Sie eine oder mehrere komprimierte Changegroup-Dateien an, die vom Bundle-Befehl generiert wurden.

Gibt bei Erfolg 0 zurück, 1 wenn ein Update unaufgelöste Dateien enthält.

Zubehör:

-du, --aktualisieren
Update auf neuen Filialleiter, wenn Changesets entbündelt wurden

Aktualisierung
Arbeitsverzeichnis aktualisieren (oder Revisionen wechseln):

hg aktualisieren [-c] [-C] [-d DATUM] [[-r] REV]

Aktualisieren Sie das Arbeitsverzeichnis des Repositorys auf das angegebene Changeset. Wenn kein Changeset vorhanden ist
angegeben, aktualisieren Sie bis zur Spitze des aktuell benannten Zweigs und verschieben Sie das aktive Lesezeichen (siehe
hg Hilfe bookmarks).

Update setzt die übergeordnete Revision des Arbeitsverzeichnisses auf das angegebene Changeset (siehe hg
Hilfe Eltern).

Wenn das Changeset kein Nachkomme oder Vorfahre des Elternverzeichnisses des Arbeitsverzeichnisses ist, wird das
die Aktualisierung wird abgebrochen. Mit der Option -c/--check wird das Arbeitsverzeichnis überprüft
nicht festgeschriebene Änderungen; wenn keine gefunden werden, wird das Arbeitsverzeichnis auf den angegebenen Wert aktualisiert
Änderungssatz.

Die folgenden Regeln gelten, wenn das Arbeitsverzeichnis nicht festgeschriebene Änderungen enthält:

1. Wenn weder -c/--check noch -C/--clean angegeben ist und das angeforderte Changeset ein . ist
Vorfahren oder Nachkomme des Elternverzeichnisses des Arbeitsverzeichnisses sind die nicht festgeschriebenen Änderungen
mit dem angeforderten Changeset zusammengeführt und das zusammengeführte Ergebnis wird nicht festgeschrieben. Wenn die
Das angeforderte Changeset ist kein Vorfahre oder Nachkomme (d. h. es befindet sich auf einem anderen)
Branch), wird das Update abgebrochen und die nicht festgeschriebenen Änderungen bleiben erhalten.

2. Mit der Option -c/--check wird das Update abgebrochen und die nicht festgeschriebenen Änderungen werden
konserviert.

3. Mit der Option -C/--clean werden nicht festgeschriebene Änderungen verworfen und das Arbeitsverzeichnis
wird auf das angeforderte Changeset aktualisiert.

Um eine nicht festgeschriebene Zusammenführung abzubrechen (und Ihre Änderungen zu verlieren), verwenden Sie hg Aktualisierung --sauber ..

Verwenden Sie null als Changeset, um das Arbeitsverzeichnis zu entfernen (wie hg klonen -U).

Wenn Sie nur eine Datei auf eine ältere Revision zurücksetzen möchten, verwenden Sie hg zurückkehren [-R RÜCK] NAME/FUNKTION.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Gibt bei Erfolg 0 zurück, 1 wenn nicht aufgelöste Dateien vorhanden sind.

Zubehör:

-VS, --sauber
nicht festgeschriebene Änderungen verwerfen (kein Backup)

-C, --prüfen
branchenübergreifend aktualisieren, wenn keine nicht festgeschriebenen Änderungen

-D,--Datum
tippmost Überarbeitungsabgleichdatum

-R,--rev
Revision

-T,--Werkzeug
Zusammenführungswerkzeug angeben

Aliase: zur Kasse gehen co

überprüfen
Überprüfen Sie die Integrität des Repositorys:

hg verifizieren

Überprüfen Sie die Integrität des aktuellen Repositorys.

Dadurch wird eine umfassende Überprüfung der Integrität des Repositorys durchgeführt und die Hashes validiert
und Prüfsummen jedes Eintrags im Änderungsprotokoll, Manifest und nachverfolgten Dateien sowie die
Integrität ihrer Crosslinks und Indizes.

Weitere Informationen zu finden Sie unter https://mercurial-scm.org/wiki/RepositoryCorruption
Wiederherstellung nach Beschädigung des Repositorys.

Gibt 0 bei Erfolg zurück, 1 wenn Fehler aufgetreten sind.

Version
Ausgabeversion und Copyright-Informationen:

hg-Version

Ausgabeversion und Copyright-Informationen

DATUM FORMATEN

Bei einigen Befehlen kann der Benutzer ein Datum angeben, z. B.:

· Backout, Commit, Import, Tag: Geben Sie das Commit-Datum an.

· protokollieren, rückgängig machen, aktualisieren: Revision(en) nach Datum auswählen.

Viele Datumsformate sind gültig. Hier sind einige Beispiele:

· Mi Dezember 6 13:18:29 2006 (lokale Zeitzone angenommen)

· Dezember 6 13:18 -0600 (Jahr angenommen, Zeitverschiebung angegeben)

· Dezember 6 13:18 UTC (UTC und GMT sind Aliase für +0000)

· Dezember 6 (Mitternacht)

· 13:18 (heute angenommen)

· 3:39 (3:39 Uhr angenommen)

· 3:39pm (15: 39)

· 2006-12-06 13:18:29 (ISO-8601-Format)

· 2006-12-6 13:18

· 2006-12-6

· 12-6

· 12/6

· 12/6/6 (6. Dezember 2006)

· heute (Mitternacht)

· gestern (Mitternacht)

· jetzt an - im Augenblick

Schließlich gibt es noch das interne Format von Mercurial:

· 1165411109 0 (Mittwoch 6. Dezember 13:18:29 UTC)

Dies ist das interne Darstellungsformat für Datumsangaben. Die erste Zahl ist die Zahl der
Sekunden seit der Epoche (1970-01-01 00:00 UTC). Der zweite ist der Offset des lokalen
timezone, in Sekunden westlich von UTC (negativ, wenn die Zeitzone östlich von UTC liegt).

Der Befehl log akzeptiert auch Datumsbereiche:

· <DATE - an oder vor einem bestimmten Datum/Uhrzeit

· >DATUM - an oder nach einem bestimmten Datum/Uhrzeit

· DATUM zu DATUM - ein Datumsbereich, einschließlich

· -TAGE - innerhalb einer bestimmten Anzahl von Tagen ab heute

DIFF FORMATEN

Das Standardformat von Mercurial zum Anzeigen von Änderungen zwischen zwei Versionen einer Datei ist
kompatibel mit dem einheitlichen Format von GNU diff, das von GNU Patch und vielen verwendet werden kann
andere Standardwerkzeuge.

Obwohl dieses Standardformat oft ausreicht, werden die folgenden Informationen nicht codiert:

· ausführbarer Status und andere Berechtigungsbits

· Informationen kopieren oder umbenennen

· Änderungen in Binärdateien

· Erstellen oder Löschen von leeren Dateien

Mercurial unterstützt auch das erweiterte Diff-Format von git VCS, das diese adressiert
Einschränkungen. Das Git-Diff-Format wird nicht standardmäßig erstellt, da einige weit verbreitete Tools
verstehe dieses Format immer noch nicht.

Das bedeutet, dass beim Generieren von Diffs aus einem Mercurial-Repository (z. B. mit hg exportieren),
Sie sollten bei Dingen wie Dateikopien und Umbenennungen oder anderen erwähnten Dingen vorsichtig sein
oben, denn wenn Sie ein Standard-Diff auf ein anderes Repository anwenden, ist dieses Extra
Informationen gehen verloren. Die internen Vorgänge von Mercurial (wie Push und Pull) sind nicht betroffen
dadurch, weil sie ein internes Binärformat verwenden, um Änderungen zu kommunizieren.

Damit Mercurial das erweiterte git-diff-Format erzeugt, verwenden Sie die Option --git für
viele Befehle, oder setzen Sie 'git = True' im Abschnitt [diff] Ihrer Konfigurationsdatei. Sie
Sie müssen diese Option nicht setzen, wenn Sie Diffs in diesem Format importieren oder in der mq verwenden
Erweiterung.

VARIABLEN

HG Pfad zur ausführbaren 'hg'-Datei, die beim Ausführen von Hooks, Erweiterungen oder . automatisch übergeben wird
externe Werkzeuge. Wenn nicht gesetzt oder leer, ist dies der Name der ausführbaren hg-Datei, wenn sie eingefroren ist.
oder eine ausführbare Datei namens 'hg' (mit %PATHEXT% [standardmäßig COM/EXE/BAT/CMD]
Erweiterungen unter Windows) wird durchsucht.

HGEDITOR
Dies ist der Name des Editors, der beim Commit ausgeführt werden soll. Siehe HERAUSGEBER.

(veraltet, Konfigurationsdatei verwenden)

HGENCODIERUNG
Dies überschreibt die von Mercurial erkannte Standardeinstellung für das Gebietsschema. Diese Einstellung ist
Wird verwendet, um Daten zu konvertieren, einschließlich Benutzernamen, Beschreibungen von Änderungssätzen, Tag-Namen und
Geäst. Diese Einstellung kann mit der Befehlszeilenoption --encoding überschrieben werden.

HGENCODINGMODE
Dadurch wird das Verhalten von Mercurial für den Umgang mit unbekannten Zeichen beim Transkodieren festgelegt
Benutzereingabe. Der Standardwert ist "strict", was dazu führt, dass Mercurial abbricht, wenn dies nicht möglich ist
einen Charakter zuordnen. Andere Einstellungen umfassen "ersetzen", was unbekannt ersetzt
Zeichen und "ignore", wodurch sie gelöscht werden. Diese Einstellung kann überschrieben werden mit dem
--encodingmode-Befehlszeilenoption.

HGENCODE MEHRDEUTIG
Dies legt das Verhalten von Mercurial für den Umgang mit Zeichen mit "mehrdeutigen" Breiten wie . fest
akzentuierte lateinische Zeichen mit ostasiatischen Schriftarten. Standardmäßig geht Mercurial davon aus, dass
mehrdeutige Zeichen sind schmal, setzen Sie diese Variable auf "breit", wenn solche Zeichen
Formatierungsprobleme verursachen.

HGMERGE
Eine ausführbare Datei zum Auflösen von Zusammenführungskonflikten. Das Programm wird ausgeführt
mit drei Argumenten: lokale Datei, entfernte Datei, Vorgängerdatei.

(veraltet, Konfigurationsdatei verwenden)

HGRCPATH
Eine Liste von Dateien oder Verzeichnissen, um nach Konfigurationsdateien zu suchen. Artikeltrennzeichen ist
":" unter Unix, ";" auf Windows. Wenn HGRCPATH nicht festgelegt ist, wird der Standardsuchpfad der Plattform verwendet
wird genutzt. Wenn leer, wird nur die .hg/hgrc-Datei aus dem aktuellen Repository gelesen.

Für jedes Element in HGRCPATH:

· Wenn es sich um ein Verzeichnis handelt, werden alle Dateien mit der Endung .rc hinzugefügt

· andernfalls wird die Datei selbst hinzugefügt

HGPLAIN
Wenn dies festgelegt ist, werden alle Konfigurationseinstellungen deaktiviert, die die Einstellungen von Mercurial . ändern könnten
Standardausgabe. Dazu gehören Kodierung, Standardeinstellungen, ausführlicher Modus, Debug-Modus, still
Modus, Tracebacks und Lokalisierung. Dies kann nützlich sein, wenn Sie Skripte gegen . erstellen
Mercurial angesichts der bestehenden Benutzerkonfiguration.

Äquivalente Optionen, die über Befehlszeilen-Flags oder Umgebungsvariablen gesetzt werden, sind nicht
überschrieben.

HGPLAINEAUSGENOMMEN
Dies ist eine durch Kommas getrennte Liste von Funktionen, die beibehalten werden sollen, wenn HGPLAIN aktiviert ist.
Derzeit werden die folgenden Werte unterstützt:

alias

Entfernen Sie keine Aliasse.

i18n

Internationalisierung bewahren.

Revsetalias

Entfernen Sie keine Revset-Aliasse.

Wenn Sie HGPLAINEXCEPT auf einen beliebigen Wert (auch eine leere Zeichenfolge) setzen, wird der einfache Modus aktiviert.

HGBENUTZER Dies ist die Zeichenfolge, die als Autor eines Commits verwendet wird. Wenn nicht eingestellt, verfügbare Werte
werden in dieser Reihenfolge berücksichtigt:

· HGUSER (eingestellt)

· Konfigurationsdateien aus dem HGRCPATH

· EMAIL

· interaktive Aufforderung

· LOGNAME (mit @hostname angehängt)

(veraltet, Konfigurationsdatei verwenden)

EMAIL Kann als Autor eines Commits verwendet werden; siehe HGUSER.

LOGNAME
Kann als Autor eines Commits verwendet werden; siehe HGUSER.

VISUAL Dies ist der Name des Editors, der beim Commit verwendet werden soll. Siehe HERAUSGEBER.

EDITOR Manchmal muss Mercurial eine Textdatei in einem Editor öffnen, damit ein Benutzer sie ändern kann.
zum Beispiel beim Schreiben von Commit-Nachrichten. Der verwendete Editor wird bestimmt durch
Betrachten Sie die Umgebungsvariablen HGEDITOR, VISUAL und EDITOR in dieser Reihenfolge.
Der erste nicht leere wird ausgewählt. Wenn alle leer sind, verwendet der Editor standardmäßig
'vernünftiger-Editor'.

PYTHONPFAD
Dies wird von Python verwendet, um importierte Module zu finden, und muss möglicherweise festgelegt werden
angemessen, wenn dieses Mercurial nicht systemweit installiert ist.

VERWENDUNG ZUSÄTZLICH MERKMALE

Mercurial hat die Möglichkeit, durch die Verwendung von Erweiterungen neue Funktionen hinzuzufügen. Erweiterungen
kann neue Befehle hinzufügen, Optionen zu bestehenden Befehlen hinzufügen, das Standardverhalten von . ändern
Befehle oder implementieren Sie Hooks.

Um die Erweiterung "foo" zu aktivieren, die entweder mit Mercurial geliefert wird oder im Python-Suchpfad enthalten ist,
Erstellen Sie einen Eintrag dafür in Ihrer Konfigurationsdatei, wie folgt:

[Erweiterungen]
foo =

Sie können auch den vollständigen Pfad zu einer Erweiterung angeben:

[Erweiterungen]
mein Merkmal = ~/.hgext/myfeature.py

See hg Hilfe Config Weitere Informationen zu Konfigurationsdateien.

Erweiterungen werden aus verschiedenen Gründen nicht standardmäßig geladen: Sie können den Start beschleunigen
Overhead; sie dürfen nur für den fortgeschrittenen Gebrauch bestimmt sein; sie können möglicherweise bereitstellen
gefährliche Fähigkeiten (wie Sie den Verlauf zerstören oder ändern zu lassen); sie könnten nicht sein
bereit für die Hauptsendezeit; oder sie können einige übliche Verhaltensweisen von Mercurial-Aktien ändern. es ist
somit obliegt es dem Benutzer, Erweiterungen nach Bedarf zu aktivieren.

Um eine in einer Konfigurationsdatei mit größerem Umfang aktivierte Erweiterung explizit zu deaktivieren,
stelle dem Pfad ! voran:

[Erweiterungen]
# Deaktivierung der Erweiterungsleiste in /path/to/extension/bar.py
bar = !/Pfad/zu/Erweiterung/bar.py
# dito, aber es wurde kein Pfad für die Erweiterung baz angegeben
baz = !

deaktivierte Erweiterungen:

Acl Hooks zur Kontrolle des Repository-Zugriffs

blackbox
Repository-Ereignisse zum Debuggen in einer Blackbox protokollieren

Bugzilla
Hooks zur Integration mit dem Bugzilla Bug Tracker

zensieren Dateiinhalt bei einer bestimmten Revision löschen

Abwanderung Befehl zum Anzeigen von Statistiken zum Repository-Verlauf

Klonbündel
Werbung für vorgenerierte Bundles für Seed-Klone

Farbe die Ausgabe einiger Befehle einfärben

verkaufen
Revisionen aus fremden VCS-Repositorys in Mercurial importieren

eol automatisch Zeilenumbrüche in Repository-Dateien verwalten

extdiff
Befehl, um externen Programmen zu ermöglichen, Revisionen zu vergleichen

Faktotum
http-Authentifizierung mit factotum

gpg Befehle zum Signieren und Überprüfen von Änderungssätzen

hgcia Hooks für die Integration mit dem CIA.vc-Benachrichtigungsdienst

hgk durchsuchen Sie das Repository grafisch

hervorheben
Syntaxhervorhebung für hgweb (benötigt Pygments)

histedit
interaktive Verlaufsbearbeitung

Stichwort
Erweitern von Schlüsselwörtern in verfolgten Dateien

große Dateien
Verfolgen Sie große Binärdateien

mq einen Stapel von Patches verwalten

benachrichtigen Hooks zum Senden von E-Mail-Push-Benachrichtigungen

zahlen Durchsuchen Sie die Befehlsausgabe mit einem externen Pager

Patchbombe
Befehl zum Senden von Änderungssätzen als (eine Reihe von) Patch-E-Mails

Säuberung Befehl zum Löschen nicht verfolgter Dateien aus dem Arbeitsverzeichnis

zurückweisen Befehl zum Verschieben von Revisionssätzen auf einen anderen Vorfahren

Rekord Befehle zum interaktiven Auswählen von Änderungen für Commit/qrefresh

neu verlinken stellt Hardlinks zwischen Repository-Klonen wieder her

Regelungen
Schemas mit Verknüpfungen zu Repository-Schwärmen erweitern

Teilen teilen eine gemeinsame Geschichte zwischen mehreren Arbeitsverzeichnissen

zurückstellen Änderungen im Arbeitsverzeichnis speichern und wiederherstellen

abstreifen Changesets und ihre Nachkommen aus der Geschichte entfernen

Transplantation
Befehl zum Transplantieren von Changesets von einem anderen Zweig

win32mbcs
erlauben die Verwendung von MBCS-Pfaden mit problematischen Codierungen

zeroconf
Repositorys im lokalen Netzwerk entdecken und bewerben

SPEZIFIKATION FILE SETS

Mercurial unterstützt eine funktionale Sprache zum Auswählen einer Reihe von Dateien.

Wie andere Dateimuster wird dieser Mustertyp durch das Präfix 'set:' angezeigt. Die Sprache
unterstützt eine Reihe von Prädikaten, die durch Infixoperatoren verbunden sind. Klammern können sein
zum Gruppieren verwendet.

Bezeichner wie Dateinamen oder Muster müssen in einfachen oder doppelten Anführungszeichen gesetzt werden, wenn
sie enthalten Zeichen außerhalb von [.*{}[]?/\_a-zA-Z0-9\x80-\xff] oder wenn sie zu einem von passen
die vordefinierten Prädikate. Dies gilt im Allgemeinen für andere Dateimuster als Globs und
Argumente für Prädikate.

Sonderzeichen können in Bezeichnern in Anführungszeichen verwendet werden, indem sie mit Escape-Zeichen versehen werden, z. \n is
als Zeilenumbruch interpretiert. Um zu verhindern, dass sie interpretiert werden, können Zeichenfolgen vorangestellt werden
mit r, z.B R'...'.

Es gibt einen einzelnen Präfixoperator:

nicht x

Dateien nicht in x. Kurzform ist ! x.

Dies sind die unterstützten Infixoperatoren:

x und y

Der Schnittpunkt der Dateien in x und y. Kurzform ist x & y.

x or y

Die Vereinigung von Dateien in x und y. Es gibt zwei alternative Kurzformen: x | y und x +
y.

x - y

Dateien in x, aber nicht in y.

Die folgenden Prädikate werden unterstützt:

hinzugefügt()

Datei, die nach . hinzugefügt wird hg Status.

binär()

Scheinbar binäre Datei (enthält NUL-Bytes).

reinigen()

Saubere Datei gemäß hg Status.

kopiert()

Datei, die als kopiert aufgezeichnet wird.

gelöscht()

Alias ​​für fehlen().

Kodierung (Name)

Die Datei kann mit der angegebenen Zeichenkodierung erfolgreich dekodiert werden. Möglicherweise nicht
nützlich für andere Kodierungen als ASCII und UTF-8.

eol (Stil)

Datei enthält Zeilenumbrüche des angegebenen Stils (dos, unix, mac). Binärdateien sind
ausgeschlossen, entsprechen Dateien mit gemischten Zeilenenden mehreren Stilen.

exec ()

Datei, die als ausführbar markiert ist.

grep (Regex)

Datei enthält den angegebenen regulären Ausdruck.

hgignorieren()

Datei, die dem aktiven .hgignore-Muster entspricht.

ignoriert()

Datei, die gemäß ignoriert wird hg Status. Diese Dateien werden nur berücksichtigt, wenn
dieses Prädikat wird verwendet.

fehlen()

Fehlende Datei gemäß hg Status.

geändert()

Datei, die entsprechend geändert wurde hg Status.

tragbar()

Datei mit einem portablen Namen. (Dies beinhaltet keine Dateinamen mit Groß-/Kleinschreibung
Kollisionen.)

ENTFERNT()

Datei, die entfernt wird gemäß hg Status.

aufgelöst()

Datei, die als aufgelöst gekennzeichnet ist gemäß hg lösen -l.

Größe (Ausdruck)

Die Dateigröße entspricht dem angegebenen Ausdruck. Beispiele:

· 1k (Dateien von 1024 bis 2047 Byte)

· < 20k (Dateien mit weniger als 20480 Bytes)

· >= .5 MB (Dateien mindestens 524288 Byte)

· 4k - 1 MB (Dateien von 4096 Byte bis 1048576 Byte)

Unterrepo ([Muster])

Unterrepositorys, deren Pfade dem angegebenen Muster entsprechen.

Symlink()

Datei, die als Symlink markiert ist.

Unbekannt()

Datei, die gemäß unbekannt ist hg Status. Diese Dateien werden nur berücksichtigt, wenn
dieses Prädikat wird verwendet.

ungelöst()

Datei, die gemäß als nicht aufgelöst markiert ist hg lösen -l.

Einige Beispielabfragen:

· Status von Dateien anzeigen, die im Arbeitsverzeichnis binär erscheinen:

hg-Status -A "set:binary()"

· Vergessen Sie Dateien, die sich in .hgignore befinden, aber bereits verfolgt wurden:

hg vergiss "set:hgignore() und nicht ignoriert()"

· Textdateien suchen, die eine Zeichenfolge enthalten:

hg-Dateien "set:grep(Magie) und nicht binär()"

· C-Dateien in einer nicht standardmäßigen Codierung finden:

hg-Dateien "set:**.c and not encoding('UTF-8')"

· Kopien großer Binärdateien rückgängig machen:

hg revert "set:copied() and binary() and size('>1M')"

· Entfernen Sie in foo.lst aufgelistete Dateien, die den Buchstaben a oder b enthalten:

hg remove "set: 'listfile:foo.lst' und (**a* oder **b*)"

[VORLÄUFIGE VOLLAUTOMATISCHE TEXTÜBERSETZUNG - muss noch überarbeitet werden. Wir bitten um Ihr Verständnis.] hg Hilfe Muster.

GLOSSAR

Vorfahr
Jedes Changeset, das von einer ununterbrochenen Kette von Parent-Changesets von a . erreicht werden kann
Änderungssatz gegeben. Genauer gesagt können die Vorfahren eines Changesets durch zwei definiert werden
Eigenschaften: ein Elternteil eines Changesets ist ein Vorfahre und ein Elternteil eines Vorfahren ist
ein Vorfahr. Siehe auch: 'Nachkomme'.

Lesezeichen
Lesezeichen sind Zeiger auf bestimmte Commits, die sich beim Commit bewegen. Sie sind
ähnlich wie bei Tags, dass es möglich ist, Lesezeichennamen an allen Stellen zu verwenden, an denen
Mercurial erwartet eine Changeset-ID, zB mit hg Aktualisierung. Im Gegensatz zu Tags bewegen sich Lesezeichen
zusammen, wenn Sie einen Commit machen.

Lesezeichen können umbenannt, kopiert und gelöscht werden. Lesezeichen sind lokal, es sei denn, sie sind es
explizit zwischen Repositorys gepusht oder gezogen. Lesezeichen schieben und ziehen
ermöglichen Ihnen die Zusammenarbeit mit anderen an einem Branch, ohne einen benannten Branch zu erstellen.

Filiale (Substantiv) Ein untergeordnetes Changeset, das von einem übergeordneten Element erstellt wurde, das kein Kopf ist.
Diese werden als topologische Zweige bezeichnet, siehe 'Zweig, topologisch'. Wenn ein
topologischer Zweig benannt wird, wird er zu einem benannten Zweig. Ist ein topologischer Zweig
nicht benannt, wird es ein anonymer Zweig. Siehe 'Filiale, anonym' und 'Filiale,
genannt'.

Verzweigungen können erstellt werden, wenn Änderungen von einer Fernbedienung abgerufen oder an diese gepusht werden
Repository, da durch diese Operationen neue Köpfe erstellt werden können. Beachten Sie, dass der Begriff
branch kann auch informell verwendet werden, um einen Entwicklungsprozess zu beschreiben, in dem
bestimmte Entwicklung erfolgt unabhängig von anderen Entwicklungen. Das ist manchmal
explizit mit einem benannten Branch, aber auch lokal mit
Lesezeichen oder Klone und anonyme Zweige.

Beispiel: "Der experimentelle Zweig."

(Verb) Die Aktion, ein untergeordnetes Changeset zu erstellen, das dazu führt, dass sein Elternteil
mehr als ein Kind.

Beispiel: "Ich verzweige bei X."

Ast, anonym
Jedes Mal, wenn ein neues untergeordnetes Changeset von einem Elternteil erstellt wird, das kein Kopf ist und
Der Name der Filiale wird nicht geändert, eine neue anonyme Filiale wird erstellt.

Ast, geschlossen
Ein benannter Zweig, dessen Zweigleiter alle geschlossen wurden.

Ast, Standard
Der einem Changeset zugewiesene Zweig, wenn zuvor noch kein Name zugewiesen wurde.

Filiale ganzer
Siehe 'Kopf, Zweig'.

Ast, inaktiv
Wenn ein benannter Zweig keine topologischen Köpfe hat, wird er als inaktiv betrachtet. Als
Beispiel: Ein Feature-Branch wird inaktiv, wenn er mit dem Standard zusammengeführt wird
Zweig. Das hg Geäst Befehl zeigt standardmäßig inaktive Branches an, obwohl sie das können
mit versteckt sein hg Geäst --aktiv.

HINWEIS: Dieses Konzept ist veraltet, da es zu implizit ist. Filialen sollten jetzt
explizit geschlossen werden mit hg verpflichten --Zweig schließen wenn sie nicht mehr benötigt werden.

Ast, namens
Eine Sammlung von Changesets, die denselben Zweignamen haben. Standardmäßig sind Kinder von
ein Changeset in einem benannten Zweig gehört zum gleichen benannten Zweig. Ein Kind kann sein
explizit einer anderen Filiale zugeordnet. Sehen hg Hilfe Filiale, hg Hilfe Geäst und
hg verpflichten --Zweig schließen Weitere Informationen zum Verwalten von Filialen.

Benannte Zweige können als eine Art Namensraum betrachtet werden, der die Sammlung von aufteilt
Changesets, aus denen das Repository besteht, in eine Sammlung von disjunkten Teilmengen. EIN
Der benannte Zweig ist nicht unbedingt ein topologischer Zweig. Wenn ein neuer benannter Zweig ist
erstellt aus dem Kopf eines anderen benannten Zweigs oder dem Standardzweig, aber nein
weitere Changesets werden zu diesem vorherigen Branch hinzugefügt, dann zu diesem vorherigen Branch
wird nur dem Namen nach eine Filiale sein.

Filiale Tip
Siehe 'Tipp, Zweig'.

Ast, topologisch
Jedes Mal, wenn ein neues untergeordnetes Changeset von einem Elternteil erstellt wird, das kein Kopf ist, wird ein neues
topologischer Zweig wird erstellt. Wenn ein topologischer Zweig benannt ist, wird er ein benannter
Ast. Wenn ein topologischer Zweig nicht benannt ist, wird er zu einem anonymen Zweig des
aktueller, möglicherweise standardmäßiger, Zweig.

Änderungsprotokoll
Ein Datensatz der Changesets in der Reihenfolge, in der sie dem Repository hinzugefügt wurden.
Dazu gehören Details wie Changeset-ID, Autor, Commit-Nachricht, Datum und Liste
von geänderten Dateien.

Änderungssatz
Eine Momentaufnahme des Status des Repositorys, das zum Aufzeichnen einer Änderung verwendet wird.

Änderungssatz, der
Die Umkehrung der Eltern-Changeset: Wenn P ein Elternteil von C ist, dann ist C ein Kind von P.
Es gibt keine Begrenzung für die Anzahl der untergeordneten Elemente, die ein Changeset haben kann.

Änderungssatz id
Ein SHA-1-Hash, der ein Changeset eindeutig identifiziert. Es kann dargestellt werden als entweder
eine "lange" 40 hexadezimale Zeichenkette oder eine "kurze" 12 hexadezimale Zeichenkette.

Änderungssatz, fusionieren
Ein Changeset mit zwei Eltern. Dies tritt auf, wenn eine Zusammenführung festgeschrieben wird.

Änderungssatz, Elternteil
Eine Revision, auf der ein untergeordnetes Changeset basiert. Insbesondere ein übergeordnetes Changeset
eines Changesets C ist ein Changeset, dessen Knoten C in der DAG unmittelbar vorausgeht.
Changesets haben höchstens zwei Eltern.

Kasse
(Substantiv) Das Arbeitsverzeichnis, das auf eine bestimmte Revision aktualisiert wird. Diese Verwendung sollte
wahrscheinlich nach Möglichkeit vermieden werden, da Changeset viel besser geeignet ist als
Kasse in diesem Zusammenhang.

Beispiel: "Ich verwende Kasse X."

(Verb) Aktualisieren des Arbeitsverzeichnisses auf ein bestimmtes Änderungsset. Sehen hg Hilfe Aktualisierung.

Beispiel: "Ich werde Changeset X auschecken."

Kind changeset
Siehe 'Changeset, Kind'.

Menu changeset
Siehe 'Leiter, geschlossene Filiale'.

Geschlossen Filiale
Siehe 'Zweig, geschlossen'.

Clone (Substantiv) Eine vollständige oder teilweise Kopie eines Repositorys. Der partielle Klon muss sich im
Form einer Revision und ihre Vorfahren.

Beispiel: "Ist Ihr Klon aktuell?"

(Verb) Der Vorgang zum Erstellen eines Klons mit hg klonen.

Beispiel: "Ich werde das Repository klonen."

Geschlossen Filiale ganzer
Siehe 'Leiter, geschlossene Filiale'.

Verpflichten (Substantiv) Ein Synonym für Changeset.

Beispiel: "Ist der Fehler in Ihrem letzten Commit behoben?"

(Verb) Das Aufzeichnen von Änderungen in einem Repository. Wenn Dateien in a . festgeschrieben werden
Arbeitsverzeichnis findet Mercurial die Unterschiede zwischen den festgeschriebenen Dateien und
ihr übergeordnetes Changeset, wodurch ein neues Changeset im Repository erstellt wird.

Beispiel: "Sie sollten diese Änderungen jetzt festschreiben."

Cset Eine gebräuchliche Abkürzung des Begriffs Changeset.

TAG Das Repository von Changesets eines verteilten Versionskontrollsystems (DVCS) kann
beschrieben als gerichteter azyklischer Graph (DAG), bestehend aus Knoten und Kanten, wobei
Knoten entsprechen Changesets und Kanten implizieren eine Eltern -> Kind-Beziehung. Dies
Grafik kann mit grafischen Tools visualisiert werden, wie z hg Log --Graph. Bei Mercurial,
das DAG wird durch die Anforderung eingeschränkt, dass Kinder höchstens zwei Elternteile haben müssen.

Veraltete
Funktion aus der Dokumentation entfernt, aber nicht zur Entfernung geplant.

Standard Filiale
Siehe 'Zweig, Standard'.

Nachkomme
Jedes Changeset, das von einer Kette untergeordneter Changesets von einem bestimmten erreicht werden kann
Änderungssatz. Genauer gesagt können die Nachkommen eines Changesets durch zwei definiert werden
Eigenschaften: das Kind eines Changesets ist ein Nachkomme und das Kind eines Nachfahren
ist ein Nachkomme. Siehe auch: 'Vorfahr'.

Diff (Substantiv) Der Unterschied zwischen den Inhalten und Attributen von Dateien in zwei
Changesets oder ein Changeset und das aktuelle Arbeitsverzeichnis. Der Unterschied ist
normalerweise in einer Standardform dargestellt, die als "diff" oder "patch" bezeichnet wird. Das "Git-Diff"
Format wird verwendet, wenn die Änderungen Kopien, Umbenennungen oder Änderungen an der Datei umfassen
Attribute, von denen keines durch das klassische "diff" und "patch" dargestellt/gehandhabt werden kann.

Beispiel: "Haben Sie meine Korrektur im Diff gesehen?"

(Verb) Das Diffing zweier Changesets ist die Aktion des Erstellens eines Diffs oder Patches.

Beispiel: "Wenn Sie mit Changeset X differenzieren, werden Sie sehen, was ich meine."

Verzeichnis, arbeiten,
Das Arbeitsverzeichnis stellt den Status der von Mercurial verfolgten Dateien dar, d. h
wird beim nächsten Commit aufgezeichnet. Das Arbeitsverzeichnis entspricht zunächst
der Snapshot in einem vorhandenen Changeset, bekannt als das übergeordnete Element des Arbeits
Verzeichnis. Siehe 'Übergeordnetes, Arbeitsverzeichnis'. Der Status kann durch Änderungen an geändert werden
die Dateien, die manuell oder durch eine Zusammenführung eingefügt wurden. Die Repository-Metadaten sind im
.hg-Verzeichnis innerhalb des Arbeitsverzeichnisses.

Entwurf Changesets in der Entwurfsphase wurden nicht mit Publishing-Repositories geteilt und
kann somit sicher durch historienmodifizierende Erweiterungen geändert werden. Sehen hg Hilfe Phasen.

Experimentell
Funktion, die zu einem späteren Zeitpunkt geändert oder entfernt werden kann.

Graph Siehe DAG und hg Log --Graph.

Head Der Begriff 'Kopf' kann verwendet werden, um sich sowohl auf einen Zweigstellenkopf als auch auf einen Repository-Kopf zu beziehen.
je nach Kontext. Siehe 'Head, Branch' und 'Head, Repository' für Spezifische
Definitionen.

Köpfe sind dort, wo allgemein Entwicklung stattfindet und sind die üblichen Ziele für
Aktualisierungs- und Zusammenführungsvorgänge.

Kopf, Filiale
Ein Changeset ohne Nachkommen im gleichnamigen Zweig.

Kopf, geschlossen Filiale
Ein Changeset, das einen Kopf als nicht mehr interessant markiert. Der geschlossene Kopf ist nein
länger gelistet von hg Köpfe. Ein Zweig gilt als geschlossen, wenn alle seine Köpfe
geschlossen und wird daher nicht gelistet von hg Geäst.

Geschlossene Köpfe können wieder geöffnet werden, indem ein neues Changeset als Kind des übergeben wird
Changeset, das einen Kopf als geschlossen markiert.

Kopf, Quelle
Ein topologischer Kopf, der nicht geschlossen wurde.

Kopf, topologisch
Ein Changeset ohne untergeordnete Elemente im Repository.

Geschichte, unveränderlich
Nach dem Commit können Changesets nicht mehr geändert werden. Erweiterungen, die sich scheinbar ändern
History erstellt tatsächlich neue Changesets, die bestehende ersetzen und dann zerstören
die alten Changesets. Dies kann in öffentlichen Repositorys zu alten Änderungssätzen führen
wieder in das Repository eingeführt werden.

Geschichte, Umschreibung
Die Changesets in einem Repository sind unveränderlich. Erweiterungen von Mercurial können jedoch
verwendet werden, um das Repository zu ändern, normalerweise so, dass der Änderungssatz erhalten bleibt
Inhalt.

Unveränderlich Geschichte
Siehe 'Verlauf, unveränderlich'.

Merge changeset
Siehe 'Änderungssatz, Zusammenführen'.

Manifest
Jeder Änderungssatz hat ein Manifest, das die Liste der Dateien ist, die vom verfolgt werden
Änderungssatz.

Merge Wird verwendet, um unterschiedliche Arbeitszweige zusammenzuführen. Wenn Sie auf ein Änderungsset aktualisieren
und dann ein anderes Changeset zusammenführen, bringen Sie die Geschichte des letzteren Changesets
in Ihr Arbeitsverzeichnis. Sobald Konflikte gelöst (und markiert) sind, wird diese Zusammenführung
kann als Merge-Changeset festgeschrieben werden, wodurch zwei Zweige in der DAG zusammengeführt werden.

Namens Filiale
Siehe 'Zweig, benannt'.

Null changeset
Das leere Changeset. Es ist der übergeordnete Status von neu initialisierten Repositorys und
Repositorys ohne ausgecheckte Revision. Es ist somit das Elternteil von Root-Changesets
und der effektive Vorfahre beim Zusammenführen nicht verwandter Changesets. Kann angegeben werden durch
den Alias ​​'null' oder durch die Changeset-ID '000000000000'.

Elternteil Siehe „Änderungssatz, Eltern“.

Elternteil changeset
Siehe „Änderungssatz, Eltern“.

Elternteil, arbeiten, Verzeichnis
Das Elternverzeichnis des Arbeitsverzeichnisses spiegelt eine virtuelle Revision wider, die das Kind des
Changeset (oder zwei Changesets mit einer nicht festgeschriebenen Zusammenführung) angezeigt von hg Eltern. Dies
wird geändert mit hg Aktualisierung. Andere Befehle zum Anzeigen des übergeordneten Arbeitsverzeichnisses sind
hg Zusammenfassung und hg id. Kann durch den Alias ​​"." angegeben werden.

Patch (Substantiv) Das Produkt einer Diff-Operation.

Beispiel: "Ich habe dir meinen Patch geschickt."

(Verb) Der Prozess der Verwendung einer Patch-Datei, um ein Changeset in ein anderes umzuwandeln.

Beispiel: "Sie müssen diese Revision patchen."

Phase Ein Status pro Änderungssatz, der nachverfolgt, wie der Änderungssatz freigegeben wurde oder freigegeben werden sollte. Sehen
hg Hilfe Phasen.

Öffentliche Changesets in der öffentlichen Phase wurden mit Publishing-Repositorys geteilt und
gelten daher als unveränderlich. Sehen hg Hilfe Phasen.

Pull Eine Operation, bei der Changesets in einem Remote-Repository, die sich nicht im lokalen
Repository werden in das lokale Repository geladen. Beachten Sie, dass dieser Vorgang ohne
spezielle Argumente aktualisieren nur das Repository, nicht die Dateien im
Arbeitsverzeichnis. Sehen hg Hilfe ziehen.

Push Eine Operation, bei der Changesets in einem lokalen Repository, die sich nicht in einem Remote-Repository befinden,
Repository werden an das Remote-Repository gesendet. Beachten Sie, dass dieser Vorgang nur hinzufügt
Changesets, die lokal an das Remote-Repository übergeben wurden. Unverbindlich
Änderungen werden nicht gesendet. Sehen hg Hilfe drücken.

Dokumente
Die Metadaten, die alle aufgezeichneten Zustände einer Sammlung von Dateien beschreiben. Jeder aufgezeichnet
Zustand wird durch ein Changeset dargestellt. Ein Repository wird normalerweise (aber nicht immer) gefunden
der .hg Unterverzeichnis eines Arbeitsverzeichnisses. Jeder aufgezeichnete Zustand kann neu erstellt werden
durch "Aktualisieren" eines Arbeitsverzeichnisses auf ein bestimmtes Changeset.

Dokumente ganzer
Siehe 'Kopf, Repository'.

Änderungsstand
Ein Zustand des Repositorys zu einem bestimmten Zeitpunkt. Frühere Revisionen können aktualisiert werden
durch die Verwendung hg Aktualisierung. Siehe auch 'Revisionsnummer'; Siehe auch 'Änderungssatz'.

Änderungsstand Anzahl
Diese ganze Zahl identifiziert ein Changeset in einem bestimmten Repository eindeutig. Es
stellt die Reihenfolge dar, in der Changesets zu einem Repository hinzugefügt wurden, beginnend mit
Revisionsnummer 0. Beachten Sie, dass die Revisionsnummer in jedem Klon von unterschiedlich sein kann
ein Repository. Um Changesets zwischen verschiedenen Klonen eindeutig zu identifizieren, siehe
'Changeset-ID'.

Revlog Von Mercurial verwendeter Geschichtsspeichermechanismus. Es ist eine Form der Delta-Codierung, mit
gelegentliche vollständige Revision der Daten, gefolgt von Delta jeder nachfolgenden Revision. Es
enthält Daten und einen Index, der auf die Daten verweist.

Umschreiben Geschichte
Siehe 'Geschichte, Umschreiben'.

Wurzel Ein Changeset, das nur das NULL-Changeset als übergeordnetes Element hat. Die meisten Repositorys haben
nur ein einzelnes Root-Changeset.

Die Geheime Changesets in der geheimen Phase dürfen nicht per Push, Pull oder Klon geteilt werden. Sehen hg
Hilfe Phasen.

Etikett Ein alternativer Name für ein Changeset. Tags können überall verwendet werden, wo
Mercurial erwartet eine Changeset-ID, zB mit hg Aktualisierung. Die Erstellung eines Tags ist
in der Historie gespeichert und wird somit automatisch per Push mit anderen geteilt
und ziehen.

Tipp Das Changeset mit der höchsten Revisionsnummer. Es ist das letzte Änderungsset
in einem Repository hinzugefügt.

Spitze, Filiale
Der Leiter einer bestimmten Filiale mit der höchsten Revisionsnummer. Wenn ein Filialname ist
als Revisionskennzeichen verwendet, bezieht es sich auf die Verzweigungsspitze. Siehe auch 'Zweig,
Kopf'. Beachten Sie, dass die Revisionsnummern in verschiedenen Repositorys unterschiedlich sein können
Klone kann die Zweigspitze in verschiedenen geklonten Repositorys unterschiedlich sein.

Aktualisierung (Substantiv) Ein weiteres Synonym für Changeset.

Beispiel: "Ich habe ein Update gepusht."

(Verb) Dieser Begriff wird normalerweise verwendet, um die Aktualisierung des Arbeitsstatus zu beschreiben
Verzeichnis in das eines bestimmten Changesets. Sehen hg Hilfe Aktualisierung.

Beispiel: "Sie sollten aktualisieren."

Arbeiten Verzeichnis
Siehe 'Verzeichnis, funktioniert'.

Arbeiten Verzeichnis Elternteil
Siehe 'Übergeordnetes, Arbeitsverzeichnis'.

SYNTAX FÜR Merkur IGNORIEREN DATEIEN

Zusammenfassung
Das Mercurial-System verwendet eine Datei namens .hgignorieren im Stammverzeichnis eines Repositorys zu
steuert sein Verhalten, wenn es nach Dateien sucht, die es derzeit nicht verfolgt.

Beschreibung
Das Arbeitsverzeichnis eines Mercurial-Repositorys enthält oft Dateien, die nicht
von Mercurial verfolgt werden. Dazu gehören Backup-Dateien, die von Editoren und Build-Produkten erstellt wurden
von Compilern erstellt. Diese Dateien können ignoriert werden, indem sie in a . aufgelistet werden .hgignorieren Datei in
das Stammverzeichnis des Arbeitsverzeichnisses. Der .hgignorieren Datei muss manuell erstellt werden. es ist
normalerweise unter Versionskontrolle gestellt, damit die Einstellungen an andere weitergegeben werden
Repositorys mit Push und Pull.

Eine nicht nachverfolgte Datei wird ignoriert, wenn ihr Pfad relativ zum Repository-Stammverzeichnis oder einer anderen ist
Präfixpfad dieses Pfads, wird mit jedem Muster in abgeglichen .hgignorieren.

Angenommen, wir haben eine nicht verfolgte Datei, Datei.c, beim a/b/datei.c in unserem Repository.
Mercurial wird ignorieren Datei.c wenn irgendein Muster in .hgignorieren Streichhölzer a/b/datei.c, a / b or a.

Darüber hinaus kann eine Mercurial-Konfigurationsdatei auf eine Reihe von benutzerspezifischen oder globalen
Dateien ignorieren. Siehe die ignorieren Konfigurationstaste auf dem [ui] Abschnitt hg Hilfe Config für
Einzelheiten zur Konfiguration dieser Dateien.

Um die Handhabung der von Mercurial verwalteten Dateien zu steuern, unterstützen viele Befehle die -I und
-X Optionen; sehen hg Hilfe und hg Hilfe Muster für weitere Einzelheiten.

Bereits verfolgte Dateien sind von .hgignore nicht betroffen, auch wenn sie in
.hgignorieren. Eine nicht verfolgte Datei X kann explizit mit hinzugefügt werden hg hinzufügen X, auch wenn X wäre
durch ein Muster in .hgignore ausgeschlossen.

Syntax
Eine Ignorierdatei ist eine reine Textdatei, die aus einer Liste von Mustern besteht, mit einem Muster pro
Linie. Leerzeilen werden übersprungen. Der # Zeichen wird als Kommentarzeichen behandelt, und das
\ Zeichen wird als Escape-Zeichen behandelt.

Mercurial unterstützt mehrere Mustersyntaxen. Die verwendete Standardsyntax ist Python/Perl-Stil
Reguläre Ausdrücke.

Um die verwendete Syntax zu ändern, verwenden Sie eine Zeile der folgenden Form:

Syntax: NAME

woher NAME/FUNKTION ist einer der folgenden:

regexp

Regulärer Ausdruck, Python/Perl-Syntax.

Klacks

Kugel im Muschelstil.

Die gewählte Syntax bleibt beim Parsen aller folgenden Muster wirksam, bis eine andere
Syntax ist ausgewählt.

Weder Glob- noch Regexp-Muster sind verwurzelt. Ein Glob-Syntax-Muster der Form *.C werden wir
Übereinstimmung mit einer Datei mit der Endung .c in einem beliebigen Verzeichnis und ein Regexp-Muster der Form \.c$ Wird besorgt
das gleiche. Um ein Regexp-Muster zu rooten, starten Sie es mit ^.

Unterverzeichnisse können ihre eigenen .hgignore-Einstellungen haben, indem Sie hinzufügen
subinclude:Pfad/zu/Unterverzeichnis/.hgignore zur Wurzel .hgignorieren. Sehen hg Hilfe Muster für
Details zu unterschließen: und -System umfasst:.

Note Patterns, die in anderen als . angegeben sind .hgignorieren sind immer verwurzelt. Bitte sehen hg Hilfe
Muster für weitere Einzelheiten.

Beispiel
Hier ist ein Beispiel für eine Ignore-Datei.

# Verwenden Sie die Glob-Syntax.
Syntax: Globus

*.elc
*.pyc
*~

# Wechsel zur Regexp-Syntax.
Syntax: regexp
^\.Stk/

KONFIGURIEREN HGWEB

Der interne Webserver von Mercurial, hgweb, kann entweder ein einzelnes Repository oder einen Baum von
Depots. Im zweiten Fall können Repository-Pfade und globale Optionen definiert werden mit
eine dedizierte Konfigurationsdatei gemeinsam mit hg brauchen, hgweb.wsgi, hgweb.cgi und hgweb.fcgi.

Diese Datei verwendet dieselbe Syntax wie andere Mercurial-Konfigurationsdateien, erkennt jedoch nur
die folgenden Abschnitte:

· Netz

· Wege

· Sammlungen

Das Netz Optionen sind ausführlich beschrieben in hg Hilfe Config.

Das Pfade Abschnitt ordnet URL-Pfade Pfaden von Repositorys im Dateisystem zu. hgweb wird
das Dateisystem nicht direkt freigeben - nur Mercurial-Repositorys können veröffentlicht werden und nur
entsprechend der Konfiguration.

Die linke Seite ist der Pfad in der URL. Beachten Sie, dass hgweb Unterpfade wie reserviert Umdrehung or
Datei, versuchen Sie, verschiedene Namen für verschachtelte Repositorys zu verwenden, um verwirrende Effekte zu vermeiden.

Die rechte Seite ist der Pfad im Dateisystem. Wenn der angegebene Pfad mit endet * or **
das Dateisystem wird rekursiv nach Repositorys unterhalb dieses Punktes durchsucht. Mit * it
wird nicht in die gefundenen Repositorys rekursieren (außer für .hg/Patches). Mit ** es wird
Suchen Sie auch in den Arbeitsverzeichnissen des Projektarchivs und finden Sie möglicherweise Unterverzeichnisse.

In diesem Beispiel:

[Wege]
/projects/a = /srv/tmprepos/a
/projekte/b = c:/repos/b
/ = /srv/repos/*
/user/bob = /home/bob/repos/**

· Die ersten beiden Einträge lassen zwei Repositories in unterschiedlichen Verzeichnissen unter dem . erscheinen
gleiches Verzeichnis im Webinterface

· Der dritte Eintrag veröffentlicht jedes gefundene Mercurial-Repository in /srv/repos/Z.
Instanz des Repositorys /srv/repos/quux/ wird als angezeigt http://server/quux/

· Der vierte Eintrag wird beides veröffentlichen http://server/user/bob/quux/ und
http://server/user/bob/quux/testsubrepo/

Das Produktauswahl Abschnitt ist veraltet und wurde ersetzt durch Pfade.

URLs und gemeinsam Argumente
URLs unter jedem Repository haben die Form /{Befehl}[/{Argumente}] woher {Befehl}
steht für den Namen eines Befehls oder Handlers und {Argumente} steht für eine beliebige Anzahl von
zusätzliche URL-Parameter für diesen Befehl.

Dem Webserver ist ein Standardstil zugeordnet. Styles werden einer Sammlung von benannten . zugeordnet
Vorlagen. Jede Vorlage wird verwendet, um ein bestimmtes Datenelement zu rendern, z. B. ein Änderungsset
oder div.

Der Stil für die aktuelle Anfrage kann auf zwei Arten überschrieben werden. Erstens, wenn {Befehl}
enthält einen Bindestrich (-), definiert der Text vor dem Bindestrich den Stil. Beispielsweise,
/atom-log wird die machen Log Befehlshandler mit dem Atom Stil. Der zweite Weg zum Einstellen
der stil ist mit dem Stil Argument für Abfragezeichenfolge. Beispielsweise, /log?style=atomdem „Vermischten Geschmack“. Seine
URL-Parameter mit Bindestrich werden bevorzugt.

Nicht alle Vorlagen sind für alle Stile verfügbar. Der Versuch, einen Stil zu verwenden, der dies nicht tut
Wenn alle Vorlagen definiert sind, kann dies zu einem Fehler beim Rendern der Seite führen.

Viele Befehle dauern a {Revision} URL-Parameter. Dies definiert das Changeset, mit dem gearbeitet werden soll.
Dies wird üblicherweise als kurze, 12-stellige hexadezimale Abkürzung für die vollen 40 . angegeben
Zeichen eindeutige Revisionskennung. Jeder Wert, der durch beschrieben wird, ist jedoch hg Hilfe Revisionen
funktioniert normalerweise.

Befehle und URLs
Die folgenden Webbefehle und ihre URLs sind verfügbar:

/annotate/{revision}/{path}
Zeigt Changeset-Informationen für jede Zeile in einer Datei an.

Das Dateianmerkung Vorlage wird gerendert.

/archive/{revision}.{format}[/{pfad}]
Besorgen Sie sich ein Archiv mit Repository-Inhalten.

Inhalt und Typ des Archivs werden durch einen URL-Pfadparameter definiert. Format lernen muss die
Dateierweiterung des zu generierenden Archivtyps. z.B Reißverschluss or tar.bz2. Nicht alle archivieren
Typen können von Ihrer Serverkonfiguration zugelassen werden.

Das optionale Weg Der URL-Parameter steuert den Inhalt, der in das Archiv aufgenommen werden soll. Wenn weggelassen,
jede Datei in der angegebenen Revision ist im Archiv vorhanden. Falls enthalten, nur die
angegebene Datei oder der Inhalt des angegebenen Verzeichnisses wird in das Archiv aufgenommen.

Für diesen Handler wird keine Vorlage verwendet. Roher, binärer Inhalt wird generiert.

/Lesezeichen
Informationen zu Lesezeichen anzeigen.

Es werden keine Argumente akzeptiert.

Das bookmarks Vorlage wird gerendert.

/Geäst
Informationen zu Filialen anzeigen.

Alle bekannten Zweige sind in der Ausgabe enthalten, auch geschlossene Zweige.

Es werden keine Argumente akzeptiert.

Das Geäst Vorlage wird gerendert.

/Änderungsprotokoll[/{Überarbeitung}]
Informationen zu mehreren Changesets anzeigen.

Wenn die optionale Revision URL-Argument fehlt, Informationen zu allen Änderungssätzen beginnend
at Tip wird gerendert. Wenn die Revision Argument vorhanden ist, werden Changesets angezeigt
beginnend mit der angegebenen Revision.

If Revision fehlt, die Umdrehung Abfragezeichenfolgenargument kann definiert werden. Dies wird ausgeführt
nach Änderungssätzen suchen.

Das Argument für Umdrehung kann eine einzelne Revision, ein Revisionssatz oder ein wörtliches Schlüsselwort sein
Suche nach in Changeset-Daten (entspricht hg Log -k).

Das Drehzahl Das Abfragezeichenfolgenargument definiert die maximale Anzahl von zu rendernden Änderungssätzen.

Für Nicht-Suchen, die Changelog Vorlage wird gerendert.

/Änderungssatz[/{Überarbeitung}]
Informationen zu einem einzelnen Changeset anzeigen.

Ein URL-Pfadargument ist die anzuzeigende Changeset-ID. Sehen hg Hilfe Revisionen für
mögliche Werte. Wenn nicht definiert, wird die Tip Changeset wird angezeigt.

Das changeset Vorlage wird gerendert. Inhalt der Changesettag, Lesezeichen ändern,
Dateiknotenlink, Dateinolink, und die vielen Vorlagen für Diffs können alle verwendet werden, um
die Ausgabe produzieren.

/Vergleich/{Revision}/{Pfad}
Zeigen Sie einen Vergleich zwischen der alten und der neuen Version einer Datei aus Änderungen an, die an einem . vorgenommen wurden
besondere Überarbeitung.

Dies ist ähnlich dem diff handler. Dieses Formular verfügt jedoch über eine Teilung oder Seite an Seite
diff statt ein einheitliches diff.

Das Kontext Das Abfragezeichenfolgenargument kann verwendet werden, um die Kontextzeilen im Diff zu steuern.

Das Dateivergleich Vorlage wird gerendert.

/diff/{Revision}/{Pfad}
Zeigen Sie, wie sich eine Datei in einem bestimmten Commit geändert hat.

Das Filediff Vorlage wird gerendert.

Dieser Handler ist unter beiden registriert /diff und /filediff Pfade. /diff wird in verwendet
moderner Code.

/Datei/{Revision}[/{Pfad}]
Informationen zu einem Verzeichnis oder einer Datei im Repository anzeigen.

Infos über die Weg als URL-Parameter angegeben wird gerendert.

If Weg ein Verzeichnis ist, werden Informationen zu den Einträgen in diesem Verzeichnis gerendert.
Diese Form entspricht der Manifest Handler.

If Weg eine Datei ist, werden Informationen zu dieser Datei über das Dateirevision
Vorlage.

If Weg nicht definiert ist, werden Informationen über das Root-Verzeichnis gerendert.

/diff/{Revision}/{Pfad}
Zeigen Sie, wie sich eine Datei in einem bestimmten Commit geändert hat.

Das Filediff Vorlage wird gerendert.

Dieser Handler ist unter beiden registriert /diff und /filediff Pfade. /diff wird in verwendet
moderner Code.

/filelog/{revision}/{pfad}
Informationen zum Verlauf einer Datei im Repository anzeigen.

Das Drehzahl Abfragezeichenfolgenargument kann definiert werden, um die maximale Anzahl von Einträgen zu steuern
zeigen.

Das Dateiprotokoll Vorlage wird gerendert.

/graph[/{revision}]
Zeigt Informationen zur grafischen Topologie des Repositorys an.

Die von diesem Handler gerenderten Informationen können verwendet werden, um visuelle Darstellungen von . zu erstellen
Topologie des Repositorys.

Das Revision Der URL-Parameter steuert das Start-Changeset.

Das Drehzahl Das Argument der Abfragezeichenfolge kann die Anzahl der Änderungssätze definieren, um Informationen anzuzeigen
für.

Dieser Handler rendert die Graph Vorlage.

/Hilfethema}]
Rendern Sie die Hilfedokumentation.

Dieser Webbefehl entspricht ungefähr hg Hilfe. Wenn eine Thema definiert ist, dass Hilfethema
wird gerendert. Wenn nicht, wird ein Index der verfügbaren Hilfethemen gerendert.

Das Hilfe Vorlage wird gerendert, wenn Hilfe zu einem Thema angefordert wird. Hilfethemen wird sein
für den Index der Hilfethemen gerendert.

/log[/{revision}[/{pfad}]]
Repository- oder Dateiverlauf anzeigen.

Für URLs des Formulars /log/{Überarbeitung}, eine Liste von Änderungssätzen, beginnend mit dem angegebenen
Changeset-ID wird angezeigt. Wenn {Revision} ist nicht definiert, der Standardwert ist Tip. Diese Form
entspricht dem Changelog Handler.

Für URLs des Formulars /log/{Revision}/{Datei}, ist der Verlauf für eine bestimmte Datei
gezeigt. Diese Form entspricht der Dateiprotokoll Handler.

/manifest[/{revision}[/{pfad}]]
Informationen zu einem Verzeichnis anzeigen.

Wenn die URL-Pfadargumente weggelassen werden, werden Informationen zum Stammverzeichnis für die Tip
Changeset wird angezeigt.

Da dieser Handler nur Informationen für Verzeichnisse anzeigen kann, wird empfohlen, zu verwenden
Datei -Handler, da er sowohl Verzeichnisse als auch Dateien verarbeiten kann.

Das Manifest Vorlage wird für diesen Handler gerendert.

/Änderungssatz[/{Überarbeitung}]
Informationen zu einem einzelnen Changeset anzeigen.

Ein URL-Pfadargument ist die anzuzeigende Changeset-ID. Sehen hg Hilfe Revisionen für
mögliche Werte. Wenn nicht definiert, wird die Tip Changeset wird angezeigt.

Das changeset Vorlage wird gerendert. Inhalt der Changesettag, Lesezeichen ändern,
Dateiknotenlink, Dateinolink, und die vielen Vorlagen für Diffs können alle verwendet werden, um
die Ausgabe produzieren.

/kurzlog
Zeigt grundlegende Informationen zu einer Reihe von Änderungssätzen an.

Dieser akzeptiert die gleichen Parameter wie der Changelog handler. Der einzige Unterschied ist der
Kurzprotokoll Vorlage wird statt der gerendert Changelog Vorlage.

/Zusammenfassung
Zeigt eine Zusammenfassung des Repository-Status an.

Dadurch werden Informationen zu den neuesten Changesets, Lesezeichen, Tags und Branches erfasst
Handler.

Das Zusammenfassung Vorlage wird gerendert.

/Stichworte
Informationen zu Tags anzeigen.

Es werden keine Argumente akzeptiert.

Das Tags Vorlage wird gerendert.

TECHNISCHE IMPLEMENTIERUNG THEMEN

Bündel
Container zum Austausch von Repository-Daten

Changegroups
Darstellung von Revlog-Daten

Revlogs
Revisionsspeichermechanismus

MERGE TOOLS

Um Dateien zusammenzuführen, verwendet Mercurial Merge-Tools.

Ein Zusammenführungswerkzeug kombiniert zwei verschiedene Versionen einer Datei zu einer zusammengeführten Datei. Merge-Tools sind
die beiden Dateien und den größten gemeinsamen Vorfahren der beiden Dateiversionen gegeben, also können sie
Bestimmen Sie die Änderungen, die an beiden Zweigen vorgenommen wurden.

Zusammenführungswerkzeuge werden sowohl für hg lösen, hg fusionieren, hg Aktualisierung, hg zurücktreten und die mehreren
Erweiterungen.

Normalerweise versucht das Merge-Tool, die Dateien automatisch abzugleichen, indem es alle kombiniert
sich nicht überschneidende Veränderungen, die in den beiden unterschiedlichen Entwicklungen der
gleiche anfängliche Basisdatei. Darüber hinaus erleichtern einige interaktive Zusammenführungsprogramme die
Lösen Sie widersprüchliche Zusammenführungen manuell, entweder grafisch oder durch Einfügen von einigen
Konfliktmarker. Mercurial enthält keine interaktiven Merge-Programme, sondern verlässt sich auf
externe Tools dafür.

Verfügbar fusionieren Werkzeuge
Externe Merge-Tools und ihre Eigenschaften werden in der Merge-Tools-Konfiguration konfiguriert
Abschnitt - siehe hgrc(5) - aber sie können oft nur nach ihrer ausführbaren Datei benannt werden.

Ein Merge-Tool ist im Allgemeinen verwendbar, wenn seine ausführbare Datei auf dem System zu finden ist und wenn es
kann mit der Zusammenführung umgehen. Die ausführbare Datei wird gefunden, wenn es sich um eine absolute oder relative ausführbare Datei handelt
Pfad oder der Name einer Anwendung im ausführbaren Suchpfad. Es wird davon ausgegangen, dass das Werkzeug
in der Lage sein, die Zusammenführung zu verarbeiten, wenn sie mit Symlinks umgehen kann, wenn die Datei ein Symlink ist, wenn dies möglich ist
Binärdateien verarbeiten, wenn die Datei binär ist, und wenn eine GUI verfügbar ist, wenn das Tool dies erfordert
eine GUI.

Es gibt einige interne Merge-Tools, die verwendet werden können. Die internen Merge-Tools sind:

:entsorgen

Erstellt drei Versionen der zusammenzuführenden Dateien, die den Inhalt der lokalen,
andere und basis. Diese Dateien können dann verwendet werden, um manuell eine Zusammenführung durchzuführen. Wenn die
Datei, die zusammengeführt werden soll, heißt a.txt, diese Dateien werden entsprechend benannt
a.txt.local, a.txt.andere und a.txt.base und sie werden gleich platziert
Verzeichnis als a.txt.

:Scheitern

Anstatt zu versuchen, Dateien zusammenzuführen, die in beiden Zweigen geändert wurden, markiert es
sie als ungelöst. Zum Auflösen dieser Konflikte muss der Befehl "resolve" verwendet werden.

:lokal

Verwendet die lokale Version der Dateien als zusammengeführte Version.

:verschmelzen

Verwendet den internen nicht interaktiven einfachen Zusammenführungsalgorithmus zum Zusammenführen von Dateien. Es wird
bei Konflikten fehlschlagen und Markierungen in der teilweise zusammengeführten Datei hinterlassen.
Marker haben zwei Abschnitte, einen für jede Seite der Zusammenführung.

:lokal zusammenführen

Wie :merge, aber lösen Sie alle Konflikte nicht interaktiv zugunsten des Lokalen
ändert.

:verschmelzen-andere

Wie :merge, aber alle Konflikte nicht interaktiv zu Gunsten des anderen lösen
ändert.

:zusammenführen3

Verwendet den internen nicht interaktiven einfachen Zusammenführungsalgorithmus zum Zusammenführen von Dateien. Es wird
bei Konflikten fehlschlagen und Markierungen in der teilweise zusammengeführten Datei hinterlassen.
Der Marker hat drei Abschnitte, einen von jeder Seite der Zusammenführung und einen für die
Basisinhalt.

:andere

Verwendet die andere Version der Dateien als zusammengeführte Version.

:prompt

Fragt den Benutzer, welche der lokalen oder anderen Versionen als zusammengeführte Version beibehalten werden soll
Version.

:tagverschmelzen

Verwendet den internen Tag-Zusammenführungsalgorithmus (experimentell).

:Union

Verwendet den internen nicht interaktiven einfachen Zusammenführungsalgorithmus zum Zusammenführen von Dateien. Es wird
Verwenden Sie für Konfliktregionen sowohl die linke als auch die rechte Seite. Es werden keine Markierungen eingefügt.

Interne Tools sind immer verfügbar und erfordern keine GUI, werden jedoch standardmäßig nicht verwendet
Umgang mit symbolischen Links oder Binärdateien.

Die Wahl a fusionieren Werkzeug
Mercurial verwendet diese Regeln bei der Entscheidung, welches Zusammenführungstool verwendet werden soll:

1. Wenn ein Werkzeug mit der Option --tool zum Zusammenführen oder Auflösen angegeben wurde, wird es verwendet.
Wenn es der Name eines Tools in der Merge-Tools-Konfiguration ist, ist seine Konfiguration
Gebraucht. Andernfalls muss das angegebene Tool von der Shell ausführbar sein.

2. Wenn die HGMERGE Umgebungsvariable ist vorhanden, ihr Wert wird verwendet und muss sein
von der Shell ausführbar.

3. Wenn der Dateiname der zusammenzuführenden Datei mit einem der Muster im
Merge-Patterns-Konfigurationsabschnitt, das erste verwendbare Merge-Tool entsprechend a
passendes Muster verwendet wird. Hier sind die binären Fähigkeiten des Merge-Tools nicht
in Betracht gezogen.

4. Wenn ui.merge gesetzt ist, wird es als nächstes berücksichtigt. Wenn der Wert nicht der Name von a . ist
konfigurierten Tool wird der angegebene Wert verwendet und muss von der Shell ausführbar sein.
Andernfalls wird das genannte Werkzeug verwendet, wenn es verwendbar ist.

5. Wenn im Konfigurationsabschnitt der Merge-Tools verwendbare Merge-Tools vorhanden sind,
mit der höchsten Priorität verwendet.

6. Wenn ein Programm namens verschmelzen ist auf dem System zu finden, es wird gebraucht - wird aber vergehen
Standard nicht für Symlinks und Binärdateien verwendet werden.

7. Wenn die zusammenzuführende Datei nicht binär und kein Symlink ist, dann intern :verschmelzen is
benutzt.

8. Das Zusammenführen der Datei schlägt fehl und muss vor dem Festschreiben aufgelöst werden.

Hinweis Nachdem Sie ein Zusammenführungsprogramm ausgewählt haben, versucht Mercurial standardmäßig, die
Dateien zuerst mit einem einfachen Zusammenführungsalgorithmus. Nur wenn es nicht gelingt wegen
widersprüchliche Änderungen Mercurial führt das Zusammenführungsprogramm tatsächlich aus. Ob zu
Verwenden Sie zuerst den einfachen Zusammenführungsalgorithmus, der durch die Premerge-Einstellung von . gesteuert werden kann
das Merge-Tool. Premerge ist standardmäßig aktiviert, es sei denn, die Datei ist binär oder a
Symlink.

Siehe die Merge-Tools und UI-Abschnitte von hgrc(5) für Details zur Konfiguration von Merge
Werkzeuge.

SPEZIFIKATION MEHRERE REVISIONEN

Wenn Mercurial mehr als eine Revision akzeptiert, können diese einzeln angegeben werden, oder
als topologisch kontinuierlicher Bereich bereitgestellt, getrennt durch das Zeichen ":".

Die Syntax der Bereichsnotation ist [BEGIN]:[END], wobei BEGIN und END Revision sind
Identifikatoren. Sowohl BEGIN als auch END sind optional. Wenn BEGIN nicht angegeben ist, wird standardmäßig verwendet
Revisionsnummer 0. Wenn END nicht angegeben wird, wird standardmäßig der Tipp verwendet. Der Bereich ":" also
bedeutet "alle Revisionen".

Wenn BEGIN größer als END ist, werden Revisionen in umgekehrter Reihenfolge behandelt.

Ein Bereich fungiert als geschlossenes Intervall. Dies bedeutet, dass ein Bereich von 3:5 3, 4 und 5 ergibt.
Ebenso ergibt ein Bereich von 9:6 9, 8, 7 und 6.

FILE NAME/FUNKTION PATTERNS

Mercurial akzeptiert mehrere Notationen, um eine oder mehrere Dateien gleichzeitig zu identifizieren.

Standardmäßig behandelt Mercurial Dateinamen als erweiterte Glob-Muster im Shell-Stil.

Alternative Musternotationen müssen explizit angegeben werden.

Notenmuster angegeben in .hgignorieren sind nicht verwurzelt. Bitte sehen hg Hilfe hgignorieren für
Details.

Um einen einfachen Pfadnamen ohne Musterzuordnung zu verwenden, beginnen Sie mit Pfad:. Dieser Weg
Die Namen müssen ab dem aktuellen Repository-Stammverzeichnis vollständig übereinstimmen.

Um einen erweiterten Glob zu verwenden, beginnen Sie einen Namen mit globus:. Globs sind im Strom verwurzelt
Verzeichnis; ein globus wie *.C findet nur Dateien im aktuellen Verzeichnis, die mit enden
.c.

Die unterstützten Glob-Syntaxerweiterungen sind ** um eine beliebige Zeichenfolge über Pfadtrennzeichen hinweg abzugleichen und
{a, b} "a oder b" bedeuten.

Um einen regulären Perl/Python-Ausdruck zu verwenden, beginnen Sie einen Namen mit re:. Regexp-Musterabgleich
ist im Stammverzeichnis des Repositorys verankert.

Um Namensmuster aus einer Datei zu lesen, verwenden Sie Listendatei: or Listendatei0:. Letzteres erwartet null
abgegrenzte Muster, während erstere Zeilenvorschübe erwartet. Jeder aus der Datei gelesene String ist
selbst als Dateimuster behandelt.

Um eine Reihe von Mustern aus einer Datei zu lesen, verwenden Sie -System umfasst: or unterschließen:. -System umfasst: werde alles benutzen
die Muster aus der angegebenen Datei und behandeln sie so, als ob sie manuell übergeben worden wären.
unterschließen: wendet die Muster nur auf Dateien an, die sich unter dem Subinclude befinden
Verzeichnis der Datei. Sehen hg Hilfe hgignorieren Einzelheiten zum Format dieser Dateien.

Alle Muster, außer globus: in der Befehlszeile angegeben (nicht für -I or -X Optionen), kann
auch gegen Verzeichnisse abgleichen: Dateien unter übereinstimmenden Verzeichnissen werden als abgeglichen behandelt.

Einfache Beispiele:

path:foo/bar eine Namensleiste in einem Verzeichnis namens foo im Stammverzeichnis
des Repositorys
path:path:name eine Datei oder ein Verzeichnis namens "path:name"

Glob-Beispiele:

glob:*.c Beliebiger Name mit der Endung ".c" im aktuellen Verzeichnis
*.c ein beliebiger Name mit der Endung ".c" im aktuellen Verzeichnis
**.c ein beliebiger Name mit der Endung ".c" in einem beliebigen Unterverzeichnis des
aktuelles Verzeichnis einschließlich sich selbst.
foo/*.c ein beliebiger Name mit der Endung ".c" im Verzeichnis foo
foo/**.c ein beliebiger Name mit der Endung ".c" in einem beliebigen Unterverzeichnis von foo
einschließlich sich selbst.

Regexp-Beispiele:

re:.*\.c$ jeder Name, der auf ".c" endet, irgendwo im Repository

Dateibeispiele:

listfile:list.txt Liste aus list.txt lesen mit einem Dateimuster pro Zeile
listfile0:list.txt Liste aus list.txt mit Null-Byte-Trennzeichen lesen

[VORLÄUFIGE VOLLAUTOMATISCHE TEXTÜBERSETZUNG - muss noch überarbeitet werden. Wir bitten um Ihr Verständnis.] hg Hilfe Dateisätze.

Fügen Sie Beispiele hinzu:

include:path/to/mypatternfile liest Muster, die auf alle Pfade angewendet werden sollen
subinclude:path/to/subignorefile liest Muster speziell für Pfade im
Unterverzeichnis

ARBEITEN MIT PHASEN

Was sind Phasen?
Phasen sind ein System zum Nachverfolgen, welche Changesets geteilt wurden oder geteilt werden sollten. Dies
hilft, häufige Fehler beim Ändern des Verlaufs zu vermeiden (z. B. mit mq oder rebase
Erweiterungen).

Jedes Changeset in einem Repository befindet sich in einer der folgenden Phasen:

· public : Changeset ist auf einem öffentlichen Server sichtbar

· Entwurf: Changeset ist noch nicht veröffentlicht

· geheim: Changeset sollte nicht gepusht, gezogen oder geklont werden

Diese Phasen sind geordnet (öffentlich < Entwurf < geheim) und kein Changeset kann in einem niedrigeren sein
Phase als seine Vorfahren. Wenn beispielsweise ein Changeset öffentlich ist, sind alle seine Vorfahren
auch öffentlich. Schließlich sollten Changeset-Phasen nur in Richtung der öffentlichen Phase geändert werden.

Ultraschall sind Phasen gelang es?
Phasen sollten überwiegend transparent ablaufen. Standardmäßig wird ein Changeset erstellt in
die Entwurfsphase und wird in die öffentliche Phase verschoben, wenn sie in eine andere verschoben wird
Repository.

Sobald Changesets öffentlich werden, werden Erweiterungen wie mq und rebase den Betrieb verweigern
sie, um zu verhindern, dass doppelte Änderungssätze erstellt werden. Phasen können auch manuell manipuliert werden
an. Nach der Installation können Sie HEIC-Dateien mit der hg Phase Befehl ggf. Sehen hg Hilfe -v Phase zum Beispiel.

Um Ihre Commits standardmäßig geheim zu halten, fügen Sie dies in Ihre Konfigurationsdatei ein:

[Phasen]
new-commit = geheim

Phasen und Server
Normalerweise sind alle Server Verlagswesen standardmäßig. Das heisst:

- Alle Draft-Changesets, die gezogen oder geklont werden, erscheinen in Phase
öffentlich auf dem Client

- Alle gepushten Draft-Changesets erscheinen auf beiden als öffentlich
Client und Server

- geheime Changesets werden weder gepusht, gezogen oder geklont

Hinweis Das Abrufen eines Entwurfs-Änderungssatzes von einem Veröffentlichungsserver markiert ihn nicht als öffentlich auf
auf der Serverseite aufgrund des schreibgeschützten Charakters von Pull.

Manchmal kann es wünschenswert sein, Changesets in der Entwurfsphase zu pushen und zu ziehen, um sie zu teilen
unvollendete Arbeit. Dies kann erreicht werden, indem ein Repository so eingestellt wird, dass die Veröffentlichung in seinem
Konfigurationsdatei:

[Phasen]
veröffentlichen = Falsch

See hg Hilfe Config Weitere Informationen zu Konfigurationsdateien.

Hinweis Server, auf denen ältere Versionen von Mercurial ausgeführt werden, werden als Veröffentlichung behandelt.

Hinweis Changesets in der geheimen Phase werden nicht mit dem Server ausgetauscht. Dies gilt für ihre
Inhalt: Dateinamen, Dateiinhalt und Changeset-Metadaten. Aus technischen Gründen,
die Kennung (zB d825e4025e39) des geheimen Changesets darf mitgeteilt werden an
der Kellner.

Beispiele
· Changesets in Draft- oder Secret-Phase auflisten:

hg log -r "nicht öffentlich()"

· ändere alle geheimen Changesets in Draft:

hg phase --draft "secret()"

· das aktuelle Changeset und die Nachkommen zwangsweise aus der Öffentlichkeit in den Entwurf verschieben:

hg-Phase --force --draft .

· eine Liste der Änderungsset-Revisionen und -Phasen anzeigen:

hg log --template "{rev} {phase}\n"

· Entwurfs-Änderungssätze relativ zu einem entfernten Repository resynchronisieren:

hg phase -fd "ausgehend(URL)"

See hg Hilfe Phase Weitere Informationen zum manuellen Bearbeiten von Phasen.

SPEZIFIKATION SINGLE REVISIONEN

Mercurial unterstützt mehrere Möglichkeiten, einzelne Revisionen anzugeben.

Eine einfache ganze Zahl wird als Revisionsnummer behandelt. Negative ganze Zahlen werden behandelt als
sequentielle Versätze von der Spitze, wobei -1 die Spitze bezeichnet, -2 die vorherige Revision bezeichnet
bis zur Spitze usw.

Eine 40-stellige hexadezimale Zeichenfolge wird als eindeutige Revisionskennung behandelt.

Eine hexadezimale Zeichenfolge mit einer Länge von weniger als 40 Zeichen wird als eindeutige Revision behandelt
Bezeichner und wird als Kurzformbezeichner bezeichnet. Eine Kurzbezeichnung ist nur
gültig, wenn es das Präfix von genau einem Bezeichner voller Länge ist.

Jede andere Zeichenfolge wird als Lesezeichen, Tag oder Zweigname behandelt. Ein Lesezeichen ist ein bewegliches
Hinweis auf eine Überarbeitung. Ein Tag ist ein permanenter Name, der einer Revision zugeordnet ist. Ein Filialname
bezeichnet den äußersten offenen Zweigkopf dieses Zweigs - oder wenn sie alle geschlossen sind, die
äußerster geschlossener Kopf des Zweiges. Lesezeichen-, Tag- und Zweignamen dürfen nicht das
":"-Zeichen.

Der reservierte Name "tip" identifiziert immer die neueste Revision.

Der reservierte Name "null" gibt die Null-Revision an. Dies ist die Überarbeitung eines leeren
Repository und das übergeordnete Element von Revision 0.

Der reservierte Name "." gibt das übergeordnete Arbeitsverzeichnis an. Wenn kein Arbeitsverzeichnis vorhanden ist
ausgecheckt, ist es äquivalent zu null. Wenn eine nicht festgeschriebene Zusammenführung im Gange ist, wird "." ist der
Revision des ersten Elternteils.

SPEZIFIKATION REVISION SETS

Mercurial unterstützt eine funktionale Sprache zum Auswählen einer Reihe von Revisionen.

Die Sprache unterstützt eine Reihe von Prädikaten, die durch Infixoperatoren verbunden sind.
Klammern können zur Gruppierung verwendet werden.

Bezeichner wie Zweignamen müssen möglicherweise in einfache oder doppelte Anführungszeichen gesetzt werden, wenn sie
enthalten Zeichen wie - oder wenn sie mit einem der vordefinierten Prädikate übereinstimmen.

Sonderzeichen können in Bezeichnern in Anführungszeichen verwendet werden, indem sie mit Escape-Zeichen versehen werden, z. \n is
als Zeilenumbruch interpretiert. Um zu verhindern, dass sie interpretiert werden, können Zeichenfolgen vorangestellt werden
mit r, z.B R'...'.

Es gibt einen einzelnen Präfixoperator:

nicht x

Changesets nicht in x. Kurzform ist ! x.

Dies sind die unterstützten Infixoperatoren:

x::y

Ein DAG-Bereich, d. h. alle Changesets, die Nachkommen von x und Vorfahren von y sind,
einschließlich x und y selbst. Wenn der erste Endpunkt weggelassen wird, ist dies äquivalent
zu Vorfahren(e), wenn die zweite weggelassen wird, ist sie äquivalent zu Nachkommen(x).

Eine alternative Syntax ist x..y.

x: y

Alle Changesets mit Revisionsnummern zwischen x und y, beide inklusive. Entweder
endpoint kann weggelassen werden, sie sind standardmäßig 0 und tip.

x und y

Der Schnittpunkt von Changesets in x und y. Kurzform ist x & y.

x or y

Die Vereinigung von Changesets in x und y. Es gibt zwei alternative Kurzformen: x | y
und x + y.

x - y

Changesets in x, aber nicht in y.

x^n

Der n-te Elternteil von x, n == 0, 1 oder 2. Für n == 0, x; für n == 1, der erste Elternteil
von jedem Changeset in x; für n == 2, der zweite Elternteil von Changeset in x.

x~n

Der n-te erste Vorfahre von x; x~0 ist x; x~3 is x^^^.

Es gibt einen einzigen Postfix-Operator:

x^

Gleichwertig x ^ 1, dem ersten Elternteil jedes Changesets in x.

Die folgenden Prädikate werden unterstützt:

fügt hinzu (Muster)

Änderungssätze, die ein Dateiabgleichsmuster hinzufügen.

Das Muster ohne explizite Art wie globus: wird erwartet, dass sie relativ zu dem ist
aktuelles Verzeichnis und vergleicht sie mit einer Datei oder einem Verzeichnis.

alle()

Alle Changesets, die gleichen wie 0: Tipp.

Vorfahr(*Änderungssatz)

Ein größter gemeinsamer Vorfahre der Changesets.

Akzeptiert 0 oder mehr Changesets. Gibt eine leere Liste zurück, wenn keine Argumente übergeben werden.
Der größte gemeinsame Vorfahre eines einzelnen Changesets ist dieses Changeset.

Vorfahren (Satz)

Changesets, die Vorfahren eines Changesets im Set sind.

Autor(Zeichenfolge)

Alias ​​für Benutzer (Zeichenfolge).

halbieren (Zeichenfolge)

Im angegebenen Halbierungsstatus markierte Änderungssätze:

· gut, Badewanne , überspringen: csets explizit als gut/schlecht/überspringen markiert

· Waren, Bads : csets topologisch gut/schlecht

· Angebot : Csets, die an der Bisektion teilnehmen

· beschnitten : csets, die gut, schlecht oder übersprungen sind

· ungetestet : Csets, deren Schicksal noch unbekannt ist

· ignoriert : Csets werden aufgrund der DAG-Topologie ignoriert

· Strom : das Cset wird derzeit halbiert

Lesezeichen ([Name])

Das benannte Lesezeichen oder alle Lesezeichen.

If Name beginnt mit re:, der Rest des Namens wird als regulärer Name behandelt
Ausdruck. Um ein Lesezeichen abzugleichen, das tatsächlich mit beginnt re:, verwenden Sie das Präfix
wörtlich:.

Zweig (String or set)

Alle Changesets, die zu dem angegebenen Zweig oder den Zweigen des angegebenen Zweigs gehören
Änderungssätze.

If Schnur beginnt mit re:, der Rest des Namens wird als regulärer Name behandelt
Ausdruck. Um einen Zweig abzugleichen, der tatsächlich mit beginnt re:, verwenden Sie das Präfix
wörtlich:.

Verzweigungspunkt()

Changesets mit mehr als einem Kind.

gestoßen ()

Veränderbare Changesets, die als Nachfolger öffentlicher Changesets markiert sind.

Es können nur nicht öffentliche und nicht veraltete Changesets erstellt werden gestoßen.

bündeln()

Changesets im Bundle.

Bundle muss mit der Option -R angegeben werden.

Kinder(set)

Untergeordnete Changesets von Changesets im Set.

abgeschlossen()

Changeset ist geschlossen.

enthält (Muster)

Das Manifest der Revision enthält ein Dateiabgleichsmuster (kann es jedoch nicht ändern).
See hg Hilfe Muster für Informationen zu Dateimustern.

Das Muster ohne explizite Art wie globus: wird erwartet, dass sie relativ zu dem ist
aktuelles Verzeichnis und vergleiche sie aus Effizienzgründen genau mit einer Datei.

konvertiert([id])

Änderungssätze, die vom angegebenen Bezeichner in das alte Repository konvertiert wurden, falls vorhanden, oder
alle konvertierten Changesets, wenn kein Bezeichner angegeben ist.

Datum (Intervall)

Changesets innerhalb des Intervalls, siehe hg Hilfe Datteln.

desc(Zeichenfolge)

Commit-Nachricht nach Zeichenfolge durchsuchen. Bei der Übereinstimmung wird die Groß-/Kleinschreibung nicht beachtet.

Nachkommen (Satz)

Changesets, die Nachkommen von Changesets im Set sind.

Ziel ([set])

Changesets, die durch eine Transplantation, Transplantation oder Rebase-Operation erstellt wurden, mit dem
gegebene Revisionen als Quelle angegeben. Das Weglassen des optionalen Sets ist dasselbe wie
übergeben all().

abweichend()

Endgültige Nachfolger von Changesets mit einem alternativen Set von finalen Nachfolgern.

Entwurf()

Changeset in der Entwurfsphase.

ausgestorben()

Nur veraltete Changesets mit veralteten Nachkommen.

extra (Etikett, [Wert])

Changesets mit dem angegebenen Label in den zusätzlichen Metadaten, mit den angegebenen optionalen
Wert.

If Wert beginnt mit re:, der Rest des Wertes wird als regulärer Wert behandelt
Ausdruck. Um einen Wert abzugleichen, der tatsächlich mit beginnt re:, verwenden Sie das Präfix
wörtlich:.

Datei (Muster)

Änderungssätze, die Dateien betreffen, die nach Mustern übereinstimmen.

Für ein schnelleres, aber weniger genaues Ergebnis sollten Sie die Verwendung von . in Erwägung ziehen Dateilog() stattdessen.

Dieses Prädikat verwendet globus: als Standardmusterart.

Dateiprotokoll (Muster)

Mit dem angegebenen Dateiprotokoll verbundene Änderungssätze.

Besucht aus Leistungsgründen nur Revisionen, die im Dateiprotokoll auf Dateiebene aufgeführt sind.
anstatt alle Changesets zu filtern (viel schneller, aber nicht enthalten
löscht oder dupliziert Änderungen). Für ein langsameres und genaueres Ergebnis verwenden Sie Datei().

Das Muster ohne explizite Art wie globus: wird erwartet, dass sie relativ zu dem ist
aktuelles Verzeichnis und vergleiche sie aus Effizienzgründen genau mit einer Datei.

Wenn einige linkrev auf Revisionen verweisen, die nach der aktuellen Repoview gefiltert wurden, werden wir arbeiten
um ihn herum, um einen nicht gefilterten Wert zurückzugeben.

erstes Set, [N])

Ein Alias ​​für limit().

folgen ([Muster])

Ein Alias ​​für ::. (Vorfahren des ersten Elternteils des Arbeitsverzeichnisses). Wenn Muster
angegeben ist, wird der Verlauf der Dateien, die dem gegebenen Muster entsprechen, verfolgt, einschließlich
Kopien.

grep (Regex)

Like Schlüsselwort (Zeichenfolge) akzeptiert aber eine Regex. Benutzen grep(r'...') um eine besondere Flucht zu gewährleisten
Zeichen werden richtig gehandhabt. nicht wie Schlüsselwort (Zeichenfolge), das Spiel ist
Groß- und Kleinschreibung beachten.

Kopf()

Changeset ist ein benannter Zweigkopf.

Köpfe (Satz)

Mitglieder des Sets ohne Kinder im Set.

versteckt()

Versteckte Changesets.

id(Zeichenfolge)

Revision, die durch das angegebene Hex-String-Präfix eindeutig angegeben wird.

Schlüsselwort (Zeichenfolge)

Commit-Nachricht, Benutzername und Namen geänderter Dateien nach Zeichenfolge durchsuchen. Das Spiel
Groß- und Kleinschreibung wird nicht berücksichtigt.

letzte(eingestellt, [N])

Die letzten n Mitglieder des Satzes, der Standardwert ist 1.

limit(einstellen[, N[, Versatz]])

Die ersten n Mitglieder der Menge, der Standardwert ist 1, beginnend mit dem Offset.

passend (Überarbeitung) [, Bereich])

Änderungssätze, bei denen ein bestimmter Satz von Feldern mit dem Satz von Feldern im ausgewählten
Überarbeitung oder Satz.

Um mehr als ein Feld abzugleichen, übergeben Sie die Liste der abzugleichenden Felder durch Leerzeichen getrennt
(z.B Autor Beschreibung).

Gültige Felder sind die meisten regulären Revisionsfelder und einige spezielle Felder.

Regelmäßige Revisionsfelder sind Beschreibung, Autor, Filiale, Datum, Dateien, Phase,
Eltern, Unterstaat, Benutzer und diff. Beachten Sie, dass Autor und Benutzer sind synonym. diff
verweist auf den Inhalt der Überarbeitung. Zwei Überarbeitungen, die zu ihren passen diff wird auch
passen zu ihren Dateien.

Spezialgebiete sind Zusammenfassung und Metadaten: Zusammenfassung stimmt mit der ersten Zeile des überein
Beschreibung. Metadaten ist gleichbedeutend mit Matching Beschreibung Benutzer Datum (dh es
stimmt mit den Hauptmetadatenfeldern überein).

Metadaten ist das Standardfeld, das verwendet wird, wenn keine Felder angegeben sind. Sie können
mehr als ein Feld gleichzeitig zuordnen.

max (einstellen)

Changeset mit der höchsten Revisionsnummer im Set.

verschmelzen()

Changeset ist ein Merge-Changeset.

min(eingestellt)

Changeset mit der niedrigsten Revisionsnummer im Set.

modifiziert (Muster)

Änderungssätze, die Dateien ändern, die nach Mustern übereinstimmen.

Das Muster ohne explizite Art wie globus: wird erwartet, dass sie relativ zu dem ist
aktuelles Verzeichnis und vergleicht sie mit einer Datei oder einem Verzeichnis.

benannt(Namensraum)

Die Changesets in einem bestimmten Namespace.

If Namensraum beginnt mit re:, der Rest des Strings wird als normal behandelt
Ausdruck. Um einen Namensraum abzugleichen, der tatsächlich mit beginnt re:, verwenden Sie das Präfix
wörtlich:.

obsolet()

Mutable Changeset mit einer neueren Version.

nur (einstellen, [einstellen])

Changesets, die Vorfahren des ersten Sets sind, die keine Vorfahren eines anderen sind
Kopf im Repo. Wenn eine zweite Menge angegeben wird, sind das Ergebnis Vorfahren der
ersten Satz, die keine Vorfahren des zweiten Satzes sind (dh :: - :: ).

Herkunft ([Satz])

Changesets, die als Quelle für die Grafts, Transplants oder Rebases angegeben wurden
die die angegebenen Revisionen erstellt haben. Das Weglassen des optionalen Satzes ist dasselbe wie das Bestehen
alle(). Wenn ein durch diese Operationen erstelltes Changeset selbst als Quelle angegeben ist
für eine dieser Operationen ist nur das Quell-Changeset für die erste Operation
ausgewählt.

ausgehend ([Pfad])

Änderungssätze wurden im angegebenen Ziel-Repository oder im Standard-Push nicht gefunden


p1([einstellen])

Erstes übergeordnetes Element von Changesets im Set oder im Arbeitsverzeichnis.

p2([einstellen])

Zweites Elternteil von Changesets in set oder das Arbeitsverzeichnis.

Eltern ([set])

Der Satz aller Eltern für alle Änderungssätze im Satz oder das Arbeitsverzeichnis.

Geschenk(set)

Ein leerer Satz, wenn keine Revision im Satz gefunden wird; andernfalls alle Revisionen im Satz.

Wenn eine der angegebenen Revisionen nicht im lokalen Repository vorhanden ist, lautet die Abfrage
normalerweise abgebrochen. Aber dieses Prädikat erlaubt es, die Abfrage auch in solchen Fällen fortzusetzen
Fälle.

allgemein()

Changeset in der öffentlichen Phase.

Fernbedienung ([id [,Weg]])

Lokale Revision, die dem angegebenen Bezeichner in einem Remote-Repository entspricht, wenn
Geschenk. Hier die '.' Bezeichner ist ein Synonym für den aktuellen lokalen Zweig.

entfernt (Muster)

Changesets, die Dateien entfernen, die dem Muster entsprechen.

Das Muster ohne explizite Art wie globus: wird erwartet, dass sie relativ zu dem ist
aktuelles Verzeichnis und vergleicht sie mit einer Datei oder einem Verzeichnis.

Umdrehung(Zahl)

Revision mit dem angegebenen numerischen Bezeichner.

umkehren (einstellen)

Umgekehrte Reihenfolge des Satzes.

Wurzeln (Satz)

Changesets im Set ohne übergeordnetes Changeset im Set.

Geheimnis()

Changeset in geheimer Phase.

sortieren(einstellen[, [-]Schlüssel...])

Sortierung nach Schlüsseln. Die Standardsortierreihenfolge ist aufsteigend, geben Sie einen Schlüssel an als -Schlüssel zu
absteigend sortieren.

Die Schlüssel können sein:

· Umdrehung für die Revisionsnummer,

· Filiale für den Filialnamen,

· desc für die Commit-Nachricht (Beschreibung),

· Benutzer für Benutzername (Autor kann als Alias ​​verwendet werden),

· Datum für das Commit-Datum

Unterrepo ([Muster])

Changesets, die das angegebene Unterrepo hinzufügen, ändern oder entfernen. Wenn kein Subrepo-Muster vorhanden ist
benannt, werden alle Subrepo-Änderungen zurückgegeben.

Verlinke den Namen])

Das angegebene Tag nach Name oder alle mit Tags versehenen Revisionen, wenn kein Name angegeben wird.

If Name beginnt mit re:, der Rest des Namens wird als regulärer Name behandelt
Ausdruck. Um ein Tag abzugleichen, das tatsächlich mit beginnt re:, verwenden Sie das Präfix wörtlich:.

instabil()

Nicht veraltete Changesets mit veralteten Vorfahren.

Benutzer (Zeichenfolge)

Benutzername enthält Zeichenfolge. Bei der Übereinstimmung wird die Groß-/Kleinschreibung nicht beachtet.

If Schnur beginnt mit re:, der Rest des Strings wird als normal behandelt
Ausdruck. Um einen Benutzer abzugleichen, der tatsächlich enthält re:, verwenden Sie das Präfix wörtlich:.

Neue Prädikate (bekannt als "Aliases") können definiert werden, indem eine beliebige Kombination vorhandener . verwendet wird
Prädikate oder andere Aliase. Eine Alias-Definition sieht wie folgt aus:

=

der Revsetalias Abschnitt einer Mercurial-Konfigurationsdatei. Argumente der Form $1,
$2, usw. werden aus dem Alias ​​in die Definition eingefügt.

Zum Beispiel,

[Revset-Alias]
h = Köpfe ()
d($1) = sort($1, Datum)
rs($1, $2) = reverse(sortieren($1, $2))

definiert drei Aliase, h, d und rs. rs(0:Tipp, Autor) ist genau äquivalent zu
reverse(sortieren(0:tipp, Autor)).

Ein Infix-Operator ## kann Zeichenfolgen und Bezeichner zu einer Zeichenfolge verketten. Beispielsweise:

[Revset-Alias]
Issue($1) = grep(r'\bissue[ :]?' ## $1 ## r'\b|\bbug\(' ## $1 ## r'\)')

Problem(1234) entspricht grep(r'\bissue[ :]?1234\b|\bbug\(1234\)') in diesem Fall. Dies
Übereinstimmungen mit allen "Ausgabe 1234", "Ausgabe:1234", "Ausgabe1234" und "Fehler(1234)".

Alle anderen Präfix-, Infix- und Postfix-Operatoren haben eine niedrigere Priorität als ##. Beispielsweise, $1
## $ 2 ~ 2 entspricht ($ 1 ## $2)~2.

Befehlszeilen-Äquivalente für hg Log:

-f -> ::.
-dx -> Datum(x)
-kx -> Schlüsselwort(x)
-m -> zusammenführen()
-ux -> Benutzer(x)
-bx -> Zweig(x)
-P x -> !::x
-lx -> limit(ausdruck, x)

Einige Beispielabfragen:

· Changesets im Standard-Branch:

hg log -r "Zweig (Standard)"

· Changesets auf dem Standard-Branch seit Tag 1.5 (außer Zusammenführungen):

hg log -r "branch(default) and 1.5:: and not merge()"

· Offene Filialleiter:

hg log -r "head() und nicht geschlossen()"

· Changesets zwischen Tags 1.3 und 1.5 erwähnen "Bug", die sich auswirken htext/*:

hg log -r "1.3::1.5 and keyword(bug) and file('hgext/*')"

· Changesets, die im Mai 2008 festgeschrieben wurden, sortiert nach Benutzern:

hg log -r "sort(date('Mai 2008'), user)"

· Änderungssätze, die "Bug" oder "Problem" erwähnen, die nicht in einer getaggten Version enthalten sind:

hg log -r "(keyword(bug) or keyword(issue)) und nicht ancestors(tag())"

VERWENDUNG Merkur AB SKRIPTE UND AUTOMATISIERUNG

Es ist üblich, dass Maschinen (im Gegensatz zu Menschen) Mercurial konsumieren. Dieses Hilfethema
beschreibt einige der Überlegungen zum Verbinden von Maschinen mit Mercurial.

Die Wahl an Schnittstelle
Maschinen haben die Wahl zwischen mehreren Methoden, um sich mit Mercurial zu verbinden. Diese schließen ein:

· Ausführung der hg Prozessdefinierung

· Abfrage eines HTTP-Servers

· Aufruf an einen Kommandoserver

Ausführen hg Prozesse ist sehr ähnlich wie Menschen mit Mercurial in der Schale interagieren.
Es sollte Ihnen bereits bekannt sein.

hg brauchen kann zum Starten eines Servers verwendet werden. Dadurch wird standardmäßig ein HTTP-Server "hgweb" gestartet.
Dieser HTTP-Server unterstützt maschinenlesbare Ausgaben wie JSON. Weitere Informationen finden Sie unter hg
Hilfe hgweb.

hg brauchen kann auch einen "Befehlsserver" starten. Clients können sich mit diesem Server verbinden und ausgeben
Mercurial Befehle über ein spezielles Protokoll. Weitere Informationen zum Befehlsserver finden Sie unter
einschließlich Links zu Clientbibliotheken, siehe https://mercurial.selenic.com/wiki/CommandServer.

hg brauchen basierte Schnittstellen (die hgweb- und Command-Server) haben den Vorteil gegenüber einfachen
hg Verarbeitungsaufrufe, da sie wahrscheinlich effizienter sind. Das liegt daran, dass es
erheblicher Aufwand, um neue Python-Prozesse hervorzubringen.

Tipp Wenn Sie mehrere aufrufen müssen hg Prozesse in kurzer Zeit und/oder Leistung ist
Wichtig für Sie ist, dass die Verwendung einer serverbasierten Schnittstelle dringend empfohlen wird.

Arbeitsumfeld Variablen
Wie in dokumentiert hg Hilfe Umwelt, verschiedene Umgebungsvariablen beeinflussen die
Betrieb von Mercurial. Für Maschinen, die verbrauchen, sind besonders relevant:
Quecksilber:

HGPLAIN
Wenn nicht festgelegt, kann die Ausgabe von Mercurial durch Konfigurationseinstellungen beeinflusst werden, die
Auswirkungen auf die Kodierung, den ausführlichen Modus, die Lokalisierung usw.

Für Maschinen wird dringend empfohlen, diese Variable beim Aufrufen zu setzen hg
Prozesse.

HGENCODIERUNG
Wenn nicht festgelegt, wird das von Mercurial verwendete Gebietsschema aus der Umgebung erkannt. Wenn
das festgelegte Gebietsschema unterstützt die Anzeige bestimmter Zeichen nicht, Mercurial kann
diese Zeichenfolgen falsch wiedergeben (oft mit "?" als Platzhalter
für ungültige Zeichen im aktuellen Gebietsschema).

Das explizite Festlegen dieser Umgebungsvariable ist eine bewährte Vorgehensweise, um sicherzustellen
konsistente Ergebnisse. "utf-8" ist eine gute Wahl in UNIX-ähnlichen Umgebungen.

HGRCPATH
Wenn nicht festgelegt, erbt Mercurial die Konfigurationsoptionen von den Konfigurationsdateien mit dem
Prozess beschrieben in hg Hilfe Config. Dies beinhaltet die Vererbung benutzer- oder systemweiter
config-Dateien.

Wenn die größtmögliche Kontrolle über die Mercurial-Konfiguration gewünscht wird, ist der Wert von
HGRCPATH kann auf eine explizite Datei mit bekannt guten Konfigurationen gesetzt werden. In seltenen Fällen kann die
Wert kann auf eine leere Datei oder das Nullgerät gesetzt werden (oft / dev / null) umgehen
Laden von Benutzer- oder Systemkonfigurationsdateien. Beachten Sie, dass diese Ansätze haben können
unbeabsichtigte Folgen, da die Benutzer- und Systemkonfigurationsdateien oft Dinge definieren
wie der Benutzername und die Erweiterungen, die möglicherweise für die Schnittstelle mit a . erforderlich sind
Repository.

Der Konsum von Befehl Output
Es ist üblich, dass Maschinen die Ausgabe von Mercurial-Befehlen auf relevante
Daten. In diesem Abschnitt werden die verschiedenen Techniken dafür beschrieben.

Parsing Roh Befehl Output
Die wahrscheinlich einfachste und effektivste Lösung zum Konsumieren von Befehlsausgaben besteht darin, einfach
aufrufen hg Befehle, wie Sie es als Benutzer tun würden, und analysieren ihre Ausgabe.

Die Ausgabe vieler Befehle kann leicht mit Tools wie . geparst werden grep, Durst und awk.

Ein potenzieller Nachteil beim Parsen der Befehlsausgabe besteht darin, dass sich die Ausgabe von Befehlen ändern kann
wenn Mercurial aktualisiert wird. Während Mercurial im Allgemeinen einen starken Rückwärtsgang anstrebt
Kompatibilität, die Befehlsausgabe ändert sich gelegentlich. Tests für Ihre automatisierten
Interaktionen mit hg Befehle wird im Allgemeinen empfohlen, ist aber noch wichtiger, wenn
Raw-Befehlsausgabe-Parsing ist beteiligt.

Die richtigen Template zu Control Output
Viele hg Befehle unterstützen die Ausgabe von Vorlagen über das -T/--Vorlage Streit. Weitere Informationen finden Sie unter
hg Hilfe Vorlagen.

Vorlagen sind nützlich, um die Ausgabe explizit zu steuern, damit Sie genau die Daten erhalten
Sie möchten formatiert werden, wie Sie es möchten. Beispielsweise, Log -T {Knoten}\n kann zum Drucken verwendet werden
durch Zeilenumbrüche getrennte Liste von Changeset-Knoten anstelle einer angepassten Ausgabe mit
Autoren, Daten, Beschreibungen usw.

Tipp Wenn das Parsen der unformatierten Befehlsausgabe zu kompliziert ist, ziehen Sie die Verwendung von Vorlagen in Betracht, um
dein Leben einfacher.

Das -T/--Vorlage -Argument ermöglicht die Angabe vordefinierter Stile. Mercurial-Schiffe mit dem
maschinenlesbare Stile JSON und xml, die eine JSON- bzw. XML-Ausgabe bereitstellen.
Diese sind nützlich, um eine Ausgabe zu erstellen, die unverändert maschinenlesbar ist.

Wichtig
Das JSON und xml Stile gelten als experimentell. Auch wenn sie attraktiv sein mögen
zu verwenden, um eine maschinenlesbare Ausgabe zu erhalten, kann sich ihr Verhalten ändern
nachfolgende Versionen.

Diese Stile können auch unerwartete Ergebnisse zeigen, wenn sie mit bestimmten
Kodierungen. Mercurial behandelt Dinge wie Dateinamen als eine Reihe von Bytes und
Normalisieren bestimmter Bytesequenzen zu JSON oder XML mit bestimmten Codierungseinstellungen
kann zu Überraschungen führen.

Befehl Server Output
Wenn Sie den Befehlsserver verwenden, um mit Mercurial zu interagieren, verwenden Sie wahrscheinlich ein vorhandenes
Bibliothek/API, die Implementierungsdetails des Befehlsservers abstrahiert. Wenn ja, das
Interface-Layer kann das Parsen für Sie durchführen, was Ihnen die Arbeit bei der Implementierung erspart
dich selber.

Output Ausführlichkeit
Befehle haben oft eine unterschiedliche Ausführlichkeit der Ausgabe, selbst wenn maschinenlesbare Stile verwendet werden
verwendet (zB -T JSON). Hinzufügen -v/--ausführlich und --debuggen zu den Argumenten des Befehls kann
die von Mercurial preisgegebene Datenmenge erhöhen.

Eine andere Möglichkeit, die benötigten Daten abzurufen, besteht darin, explizit eine Vorlage anzugeben.

Andere Themen
kehrt zurück
Revisionssätze ist eine funktionale Abfragesprache zum Auswählen eines Satzes von Revisionen.
Betrachten Sie es als SQL für Mercurial-Repositorys. Resets sind nützlich für Abfragen
Speicher für bestimmte Daten.

See hg Hilfe kehrt zurück für mehr.

Teilen Erweiterung
Das Teilen Erweiterung bietet Funktionen für die gemeinsame Nutzung von Repository-Daten über
mehrere Arbeitskopien. Es kann sogar automatisch Speicher "poolen" für logisch
verwandte Repositories beim Klonen.

Konfigurieren der Teilen Erweiterung kann zu einer erheblichen Ressourcenauslastung führen
Reduzierung, insbesondere um Speicherplatz und das Netzwerk. Das gilt besonders
für Continuous Integration (CI) Umgebungen.

See hg Hilfe -e Teilen für mehr.

ZWISCHENLAGEBERICHTE

Mit Sub-Repositorys können Sie externe Repositorys oder Projekte in einem übergeordneten Mercurial verschachteln
Repository, und make-Befehle arbeiten mit ihnen als Gruppe.

Mercurial unterstützt derzeit die Unterverzeichnisse von Mercurial, Git und Subversion.

Unterverzeichnisse bestehen aus drei Komponenten:

1. Verschachtelte Repository-Checkouts. Sie können überall im übergeordneten Arbeitsverzeichnis erscheinen.

2. Verschachtelte Repository-Referenzen. Sie sind definiert in .hgsub, die in der platziert werden sollte
root des Arbeitsverzeichnisses, und geben Sie an, woher die Unterrepository-Checkouts kommen.
Mercurial-Unterrepositorys werden wie folgt referenziert:

path/to/nested = https://example.com/nested/repo/path

Git- und Subversion-Subrepos werden ebenfalls unterstützt:

path/to/nested = [git]git://example.com/nested/repo/path
path/to/nested = [svn]https://example.com/nested/trunk/path

woher Pfad/zu/verschachtelt ist der Checkout-Standort relativ zum übergeordneten Mercurial-Stamm,
und https://example.com/nested/repo/path ist der Quell-Repository-Pfad. Die Quelle kann
Verweisen Sie auch auf einen Dateisystempfad.

Beachten Sie, dass .hgsub nicht standardmäßig in Mercurial-Repositorys vorhanden ist, müssen Sie
erstellen Sie es und fügen Sie es dem übergeordneten Repository hinzu, bevor Sie untergeordnete Repositorys verwenden.

3. Verschachtelte Repository-Zustände. Sie sind definiert in .hgsubstate, die in der Wurzel platziert wird
des Arbeitsverzeichnisses und erfassen Sie alle Informationen, die zum Wiederherstellen des
Unterrepositorys in den Zustand, in dem sie in einem übergeordneten Repository-Changeset festgeschrieben wurden.
Mercurial zeichnet automatisch die Zustände der verschachtelten Repositorys beim Commit in der . auf
übergeordnetes Repository.

Note
Das .hgsubstate Datei sollte nicht manuell bearbeitet werden.

Hinzufügen a Unterablage
If .hgsub nicht existiert, erstellen Sie es und fügen Sie es dem übergeordneten Repository hinzu. Klonen oder zur Kasse gehen
die externen Projekte, in denen es im übergeordneten Repository gespeichert werden soll. Bearbeiten .hgsub und
fügen Sie den Unterrepository-Eintrag wie oben beschrieben hinzu. An dieser Stelle ist das Unterrepository
verfolgt und der nächste Commit wird seinen Status in .hgsubstate und binde es an die
engagierte Änderungsmenge.

Synchronisieren a Unterablage
Subrepos verfolgen nicht automatisch den neuesten Änderungssatz ihrer Quellen. Stattdessen
werden auf das Changeset aktualisiert, das dem im ausgecheckten Changeset entspricht
Änderungssatz der obersten Ebene. Auf diese Weise erhalten Entwickler immer einen konsistenten Satz kompatiblen Codes
und Bibliotheken, wenn sie aktualisiert werden.

Daher ist das Aktualisieren von Subrepos ein manueller Prozess. Schauen Sie sich einfach das Ziel-Subrepo im . an
gewünschte Revision, Test im Top-Level-Repository, dann Commit im übergeordneten Repository an
notieren Sie die neue Kombination.

Löschen a Unterablage
Um ein Unter-Repository aus dem übergeordneten Repository zu entfernen, löschen Sie seine Referenz aus .hgsub,
entfernen Sie dann seine Dateien.

Interaktion mit Quecksilber- Befehle
hinzufügen add wird in Subrepos nicht rekursiv ausgeführt, es sei denn, -S/--subrepos ist angegeben. wie auch immer, falls
Sie geben den vollständigen Pfad einer Datei in einem Unterrepo an, es wird auch ohne hinzugefügt
-S/--Subrepos angegeben. Subversion-Unterverzeichnisse sind derzeit stumm
ignoriert.

hinzufügenentfernen
addremove führt keine Rekursion in Subrepos durch, es sei denn, -S/--subrepos ist angegeben.
Wenn Sie jedoch den vollständigen Pfad eines Verzeichnisses in einem Unterrepo angeben, wird addremove
auch ohne Angabe von -S/--subrepos ausgeführt werden. Git und Subversion
subrepositories wird eine Warnung ausgeben und fortfahren.

Archiv
archive wird in Unterrepositorys nicht wiederholt, es sei denn, -S/--subrepos ist angegeben.

Katze cat verarbeitet derzeit nur exakte Dateiübereinstimmungen in Unterrepos. Subversion
Unterverzeichnisse werden derzeit ignoriert.

verpflichten Commit erstellt eine konsistente Momentaufnahme des Status des gesamten Projekts und seiner
Unterverzeichnisse. Wenn Unterrepositorys geändert wurden, wird Mercurial abgebrochen.
Mercurial kann dazu veranlasst werden, stattdessen alle geänderten Unterrepositorys festzuschreiben, indem
-S/--subrepos, oder das Setzen von "ui.commitsubrepos=True" in einer Konfigurationsdatei (siehe hg
Hilfe Config). Nachdem keine geänderten Unter-Repositorys mehr vorhanden sind, zeichnet es auf
ihren Zustand und schreibt ihn schließlich in das übergeordnete Repository. Die --addremove
Option berücksichtigt auch die Option -S/--subrepos. Git und Subversion
subrepositories geben eine Warnung aus und brechen ab.

diff diff ist in Subrepos nicht rekursiv, es sei denn, -S/--subrepos ist angegeben. Änderungen sind
wird wie gewohnt auf den Unterrepository-Elementen angezeigt. Subversion-Unterverzeichnisse sind
derzeit stillschweigend ignoriert.

Dateien Dateien werden nicht in Unterrepos rekursiert, es sei denn, -S/--subrepos ist angegeben. Jedoch,
Wenn Sie den vollständigen Pfad einer Datei oder eines Verzeichnisses in einem Unterrepo angeben, wird es
auch ohne Angabe von -S/--subrepos angezeigt. Git und Subversion
Unterverzeichnisse werden derzeit stillschweigend ignoriert.

vergessen Forget verarbeitet derzeit nur genaue Dateiübereinstimmungen in Unterrepos. Git und Subversion
Unterverzeichnisse werden derzeit stillschweigend ignoriert.

eingehende
eingehend wird in Subrepos nicht rekursiert, es sei denn, -S/--subrepos ist angegeben. Git und
Subversion-Unterverzeichnisse werden derzeit stillschweigend ignoriert.

abgehenden
ausgehend wird in Subrepos nicht rekursiv, es sei denn, -S/--subrepos ist angegeben. Git und
Subversion-Unterverzeichnisse werden derzeit stillschweigend ignoriert.

ziehen Pull ist nicht rekursiv, da nicht klar ist, was vor dem Ausführen gezogen werden soll hg Aktualisierung
. Auflisten und Abrufen aller Unterrepository-Änderungen, auf die vom übergeordneten Element verwiesen wird
aus dem Repository gezogene Changesets sind bestenfalls teuer, in der Subversion unmöglich
Fall.

drücken Mercurial wird automatisch zuerst alle Unterrepositorys pushen, wenn die Eltern
Repository wird gepusht. Dadurch wird sichergestellt, dass neue Subrepository-Änderungen verfügbar sind
wenn von Top-Level-Repositorys referenziert wird. Push ist ein No-Op für Subversion
Unterverzeichnisse.

Status Status wird nicht in Unterrepositorys rekursiert, es sei denn, -S/--subrepos wird angegeben.
Subrepository-Änderungen werden als reguläre Mercurial-Änderungen auf dem
untergeordnete Repository-Elemente. Subversion-Unterverzeichnisse werden derzeit stillschweigend ignoriert.

entfernen remove führt keine Rekursion in Unterrepositorys durch, es sei denn, -S/--subrepos ist angegeben.
Wenn Sie jedoch einen Datei- oder Verzeichnispfad in einem Unterrepo angeben, wird es entfernt
auch ohne -S/--subrepos. Git- und Subversion-Unterverzeichnisse sind derzeit
still ignoriert.

Aktualisierung update stellt die Unterrepos in dem Zustand wieder her, in dem sie ursprünglich im Ziel festgeschrieben wurden
Änderungssatz. Wenn das aufgezeichnete Changeset im aktuellen Unterrepository nicht verfügbar ist,
Mercurial zieht es zuerst ein, bevor es aktualisiert wird. Dies bedeutet, dass die Aktualisierung
erfordern Netzwerkzugriff, wenn Unterrepositorys verwendet werden.

Neuzuordnung Unterverzeichnisse Quellen
Der Quellspeicherort eines Unterrepositorys kann sich während der Projektlaufzeit ändern, wodurch Referenzen ungültig werden
im Verlauf des übergeordneten Repositorys gespeichert. Um dies zu beheben, können Umschreibungsregeln definiert werden in
übergeordnetes Repository hgrc Datei oder in der Mercurial-Konfiguration. Siehe die [Unterpfade] Abschnitt in
hgrc(5) für weitere Details.

TEMPLATE ANWENDUNG

Mercurial ermöglicht es Ihnen, die Ausgabe von Befehlen über Vorlagen anzupassen. Du kannst entweder
Übergeben Sie eine Vorlage oder wählen Sie über die Befehlszeile einen vorhandenen Vorlagenstil aus
--template-Option.

Sie können die Ausgabe für jeden "log-ähnlichen" Befehl anpassen: log, ausgehend, eingehend, tip,
Eltern und Köpfe.

Einige integrierte Stile sind im Lieferumfang von Mercurial enthalten. Diese können mit aufgeführt werden hg Log
--Vorlage Liste. Anwendungsbeispiel:

$ hg log -r1.0::1.1 --template changelog

Eine Vorlage ist ein Stück Text mit Markup zum Aufrufen der Variablenerweiterung:

$ hg log -r1 --template "{node}\n"
b56ce7b07c52de7d5fd79fb89701ea538af65746

Strings in geschweiften Klammern werden als Schlüsselwörter bezeichnet. Die Verfügbarkeit von Keywords hängt von den
genauen Kontext des Templaters. Diese Schlüsselwörter stehen normalerweise für die Erstellung von Vorlagen zur Verfügung
log-ähnlicher Befehl:

aktives Lesezeichen
Zeichenfolge. Das aktive Lesezeichen, wenn es mit dem Änderungssatz verknüpft ist

Autor Zeichenfolge. Der unveränderte Autor des Changesets.

halbieren Zeichenfolge. Der geänderte Bisektionsstatus.

bookmarks
Liste der Zeichenfolgen. Alle Lesezeichen, die dem Changeset zugeordnet sind. Setzt auch 'aktiv',
der Name des aktiven Lesezeichens.

Filiale Zeichenfolge. Der Name des Branchs, für den das Changeset festgeschrieben wurde.

Änderungenincelatesttag
Ganze Zahl. Alle Vorfahren nicht im neuesten Tag.

und Kindern
Liste der Zeichenfolgen. Die Kinder des Changesets.

Datum Datum Informationen. Das Datum, an dem das Changeset festgeschrieben wurde.

desc Zeichenfolge. Der Text der Changeset-Beschreibung.

diffstat
Zeichenfolge. Statistik der Änderungen mit folgendem Format: "geänderte Dateien:
+hinzugefügte/-entfernte Zeilen"

Extras Liste der Diktate mit Schlüssel- und Werteinträgen des 'Extras'-Feldes dieses Changesets.

file_adds
Liste der Zeichenfolgen. Von diesem Changeset hinzugefügte Dateien.

Datei_Kopien
Liste der Zeichenfolgen. In dieses Changeset kopierte Dateien mit ihren Quellen.

file_copys_switch
Liste der Zeichenfolgen. Wie "file_copies", wird aber nur angezeigt, wenn der Schalter --copied . ist
gesetzt.

file_dels
Liste der Zeichenfolgen. Dateien, die von diesem Changeset entfernt wurden.

file_mods
Liste der Zeichenfolgen. Von diesem Changeset geänderte Dateien.

Dateien Liste der Zeichenfolgen. Alle Dateien, die von diesem Änderungssatz geändert, hinzugefügt oder entfernt wurden.

graphnode
Zeichenfolge. Das Zeichen, das den Changeset-Knoten in einem ASCII-Revisionsgraphen darstellt

neuestes Tag
Liste der Zeichenfolgen. Die globalen Tags des neuesten global markierten Vorfahren von
dieses Changeset.

neuestetagabstand
Ganze Zahl. Längster Pfad zum neuesten Tag.

Namespaces
Diktat von Listen. Namen, die diesem Changeset pro Namespace zugeordnet sind.

Knoten Zeichenfolge. Der Changeset-Identifikations-Hash als 40 hexadezimale Zeichenfolge.

p1node Zeichenfolge. Der Identifikations-Hash des ersten Elternteils des Changesets als 40-stellige
hexadezimale Zeichenfolge. Wenn das Changeset keine Eltern hat, sind alle Ziffern 0.

p1rev Ganze Zahl. Die Repository-lokale Revisionsnummer des ersten Elternteils des Changesets, oder
-1, wenn das Changeset keine übergeordneten Elemente hat.

p2node Zeichenfolge. Der Identifikations-Hash des zweiten Elternteils des Changesets als 40-stellige
hexadezimale Zeichenfolge. Wenn das Changeset kein zweites Elternteil hat, sind alle Ziffern 0.

p2rev Ganze Zahl. Die Repository-lokale Revisionsnummer des zweiten Elternteils des Changesets, oder
-1 wenn das Changeset kein zweites Elternteil hat.

Eltern
Liste der Zeichenfolgen. Die Eltern des Changesets im Format "rev:node". Wenn die
Changeset hat nur ein "natürliches" Elternteil (die Vorgängerrevision) nichts ist
gezeigt.

Phase Zeichenfolge. Der Name der Changeset-Phase.

Phaseidx
Ganze Zahl. Der Changeset-Phasenindex.

Umdrehung Ganze Zahl. Die Repository-lokale Changeset-Revisionsnummer.

Unterlager
Liste der Zeichenfolgen. Untergeordnete Repositorys im Changeset aktualisiert.

Tags Liste der Zeichenfolgen. Alle Tags, die dem Changeset zugeordnet sind.

Das Schlüsselwort "date" erzeugt keine lesbare Ausgabe. Wenn Sie ein Datum in verwenden möchten
Ihre Ausgabe können Sie einen Filter verwenden, um sie zu verarbeiten. Filter sind Funktionen, die a . zurückgeben
Zeichenfolge basierend auf der Eingabevariable. Stellen Sie sicher, dass Sie zuerst den Stringify-Filter verwenden, wenn Sie
Anwenden eines String-Eingabefilters auf eine listenartige Eingabevariable. Sie können auch eine Kette von verwenden
Filter, um die gewünschte Ausgabe zu erhalten:

$ hg tip --template "{date|isodate}\n"
2008-08-21 18:22 +0000

Liste der Filter:

Addbreaks
Beliebiger Text. XHTML hinzufügen" "-Tag vor dem Ende jeder Zeile außer der letzten.

Alter Datum. Gibt eine lesbare Datums-/Uhrzeitdifferenz zwischen dem angegebenen Datum/der angegebenen Uhrzeit und . zurück
das aktuelle Datum/die aktuelle Uhrzeit.

Basisname
Beliebiger Text. Behandelt den Text als Pfad und gibt die letzte Komponente des Pfads zurück
nach der Aufteilung durch das Pfadtrennzeichen (nachfolgende Trennzeichen werden ignoriert). Beispielsweise,
Aus "foo/bar/baz" wird "baz" und aus "foo/bar//" wird "bar".

zählen Liste oder Text. Gibt die Länge als Ganzzahl zurück.

Domain Beliebiger Text. Findet die erste Zeichenfolge, die wie eine E-Mail-Adresse aussieht, und extrahiert
nur die Domänenkomponente. Beispiel: Mitglied <[E-Mail geschützt] > wird example.com.

E-Mail Beliebiger Text. Extrahiert die erste Zeichenfolge, die wie eine E-Mail-Adresse aussieht. Beispiel: Mitglied
<[E-Mail geschützt] > wird [E-Mail geschützt] .

E-Mail-Benutzer
Beliebiger Text. Gibt den Benutzerteil einer E-Mail-Adresse zurück.

Flucht Beliebiger Text. Ersetzt die speziellen XML/XHTML-Zeichen "&", "<" und ">" durch XML
Entitäten und filtert NUL-Zeichen heraus.

füllen68 Beliebiger Text. Umbricht den Text so, dass er in 68 Spalten passt.

füllen76 Beliebiger Text. Umbricht den Text so, dass er in 76 Spalten passt.

Erste Meereslinie
Beliebiger Text. Gibt die erste Textzeile zurück.

hex Beliebiger Text. Wandeln Sie eine binäre Mercurial-Knotenkennung in ihre lange Hexadezimalzahl um
Darstellung.

Hgdate Datum. Gibt das Datum als Zahlenpaar zurück: "1157407993 25200" (Unix-Zeitstempel,
Zeitzonenverschiebung).

isodieren
Datum. Gibt das Datum im ISO 8601-Format zurück: "2009-08-18 13:00 +0200".

Isodatesec
Datum. Gibt das Datum im ISO 8601-Format einschließlich Sekunden zurück: "2009-08-18 13:00:13
+0200". Siehe auch den rfc3339date-Filter.

senken Beliebiger Text. Wandelt den Text in Kleinbuchstaben um.

nicht leer
Beliebiger Text. Gibt '(keine)' zurück, wenn die Zeichenfolge leer ist.

verschleiern
Beliebiger Text. Gibt den als Sequenz von XML-Entitäten gerenderten Eingabetext zurück.

person Beliebiger Text. Gibt den Namen vor einer E-Mail-Adresse zurück und interpretiert ihn gemäß RFC
5322

Revescape
Beliebiger Text. Maskiert alle "Sonderzeichen" außer @. Schrägstriche werden maskiert
zweimal, um zu verhindern, dass Webserver sie vorzeitig verlassen. Beispiel: "@foo
bar/baz" wird zu "@foo%20bar%252Fbaz".

rfc3339date
Datum. Gibt ein Datum mit dem in RFC 3339 angegebenen Internet-Datumsformat zurück:
"2009-08-18T13:00:13+02:00".

rfc822date
Datum. Gibt ein Datum im gleichen Format zurück, das in E-Mail-Headern verwendet wird: "Di, 18. August 2009
13:00:13 +0200".

kurz Changeset-Hash. Gibt die Kurzform eines Changeset-Hashs zurück, dh eine 12 hexadezimal
Ziffernfolge.

kurzbisect
Beliebiger Text. Leckereien Text als Bisektionsstatus und gibt ein einzelnes Zeichen zurück
repräsentiert den Status (G: gut, B: schlecht, S: übersprungen, U: ungetestet, I: ignoriert).
Gibt ein einzelnes Leerzeichen zurück, wenn Text ist kein gültiger Bisektionsstatus.

kurzes Date
Datum. Gibt ein Datum wie "2006-09-18" zurück.

Trennlinien
Beliebiger Text. Teilen Sie Text in eine Liste von Zeilen auf.

stringifizieren
Jeder Typ. Wandelt den Wert in Text um, indem Werte in Text umgewandelt werden und
sie verketten.

Stripdir
Behandeln Sie den Text als Pfad und entfernen Sie nach Möglichkeit eine Verzeichnisebene. Zum Beispiel "foo"
und aus "foo/bar" wird "foo".

tabindent
Beliebiger Text. Gibt den Text mit jeder nicht leeren Zeile außer der ersten beginnend zurück
mit Tabulatorzeichen.

obere Beliebiger Text. Wandelt den Text in Großbuchstaben um.

urlescape
Beliebiger Text. Entfernt alle "Sonderzeichen". Aus "foo bar" wird beispielsweise
"foo%20bar".

Benutzer Beliebiger Text. Gibt eine kurze Darstellung eines Benutzernamens oder einer E-Mail-Adresse zurück.

Beachten Sie, dass ein Filter nichts anderes als ein Funktionsaufruf ist, dh ausdruck|filter ist gleichwertig
zu filtern (ausdruck).

Neben Filtern gibt es einige grundlegende eingebaute Funktionen:

Datum datum[, fmt])
Formatieren Sie ein Datum. Sehen hg Hilfe Datteln zum Formatieren von Zeichenfolgen. Die Vorgabe ist ein Unix-Datum
Format, einschließlich der Zeitzone: "Mo Sep 04 15:13:13 2006 0700".

diff([Muster einschließen [, Ausschlussmuster]])
Diff anzeigen und optional Dateien angeben, die eingeschlossen oder ausgeschlossen werden sollen.

füllen(text[, Breite[, initialident[, hängend]]])
Füllen Sie viele Absätze mit optionalem Einzug. Siehe den Filter "Füllen".

bekommen (dikt, Schlüssel)
Holen Sie sich ein Attribut/einen Schlüssel von einem Objekt. Einige Schlüsselwörter sind komplexe Typen. Diese Funktion
ermöglicht es Ihnen, den Wert eines Attributs für diese Typen abzurufen.

if(ausdruck, dann[, anders])
Bedingte Ausführung basierend auf dem Ergebnis eines Ausdrucks.

ifcontains (Suche, Sache, dann[, anders])
Bedingte Ausführung basierend darauf, ob das Element "Suche" in "Ding" enthalten ist.

ifeq(ausdr1, Ausdruck2, dann[, anders])
Bedingte Ausführung basierend darauf, ob 2 Elemente gleichwertig sind.

einrücken (Text, Einrückungszeichen[, erste Linie])
Rückt alle nicht leeren Zeilen mit den in der Zeichenkette indentchars angegebenen Zeichen ein. Ein
Der optionale dritte Parameter überschreibt den Einzug für die erste Zeile nur dann, wenn
Geschenk.

beitreten (Liste, September)
Verbinden Sie Elemente in einer Liste mit einem Trennzeichen.

Etikett (Etikett, Ausdruck)
Wenden Sie ein Label auf generierte Inhalte an. Inhalte mit einem angebrachten Label können dazu führen
zusätzliche Nachbearbeitung, wie z. B. automatische Kolorierung.

neustesTag([Muster])
Die globalen Tags, die dem gegebenen Muster auf dem neuesten global markierten entsprechen
Vorfahre dieses Änderungssatzes.

localdate(Datum[, z])
Konvertiert ein Datum in die angegebene Zeitzone. Der Standardwert ist das lokale Datum.

Pad (Text, Breite[, fillchar=' '[, richtig=Falsch]])
Füllen Sie Text mit einem Füllzeichen auf.

revset(abfrage[, Formatangaben...])
Führen Sie eine Revisionssatzabfrage aus. Sehen hg Hilfe Drehzahl.

rstdoc(Text, Stil)
ReStructuredText formatieren.

kürzeste (Knoten, Mindestlänge=4)
Erhalten Sie die kürzeste Darstellung eines Knotens.

beginntmit(Muster, Text)
Gibt den Wert aus dem Argument "text" zurück, wenn es mit dem Inhalt von beginnt
"Muster"-Argument.

Streifen(Text[, Zeichen])
Zeichen aus einer Zeichenfolge entfernen. Entfernt standardmäßig alle führenden und nachfolgenden Zeilen
Leerzeichen.

unter (Muster, Ersatz, Ausdruck)
Führen Sie Textersetzungen mit regulären Ausdrücken durch.

Wort (Zahl, Text[, Separator])
Gibt das n-te Wort aus einer Zeichenfolge zurück.

Außerdem gibt es für jeden Ausdruck, der eine Liste zurückgibt, einen Listenoperator:

expr % "{template}"

Wie im obigen Beispiel zu sehen, {Schablone} wird als Vorlage interpretiert. Um es zu verhindern
interpretiert werden, können Sie ein Escape-Zeichen verwenden \{ oder ein rohes String-Präfix, R'...'.

Einige Beispiele für Befehlszeilenvorlagen:

· Formatlisten, zB Dateien:

$ hg log -r 0 --template "Dateien:\n{Dateien % ' {Datei}\n'}"

· Verbinden Sie die Liste der Dateien mit einem ", ":

$ hg log -r 0 --template "files: {join(files, ', ')}\n"

· Ändern Sie jede Zeile einer Commit-Beschreibung:

$ hg log --template "{splitlines(desc) % '**** {line}\n'}"

· Datum formatieren:

$ hg log -r 0 --template "{date(date, '%Y')}\n"

· Anzeigedatum in UTC:

$ hg log -r 0 --template "{localdate(date, 'UTC')|date}\n"

· Ausgabe der Beschreibung mit einer Füllbreite von 30:

$ hg log -r 0 --template "{fill(desc, 30)}"

· Verwenden Sie eine Bedingung, um den Standardzweig zu testen:

$ hg log -r 0 --template "{ifeq(branch, 'default', 'on the main branch',
'auf Zweig {Zweig}')}\n"

· Fügen Sie eine neue Zeile hinzu, wenn sie nicht leer ist:

$ hg tip --template "{if(autor, '{autor}\n')}"

· Beschriften Sie die Ausgabe für die Verwendung mit der Farberweiterung:

$ hg log -r 0 --template "{label('changeset.{phase}', node|short)}\n"

· Firstline-Filter invertieren, also alles außer der ersten Zeile:

$ hg log -r 0 --template "{sub(r'^.*\n?\n?', '', desc)}\n"

· Zeigen Sie den Inhalt des 'Extra'-Felds an, einen pro Zeile:

$ hg log -r 0 --template "{join(extras, '\n')}\n"

· Aktives Lesezeichen mit '*' markieren:

$ hg log --template "{bookmarks % '{bookmark}{ifeq(bookmark, active, '*')} '}\n"

· Finden Sie das vorherige Release Candidate-Tag, die Entfernung und die Änderungen seit dem Tag:

$hg log -r . --template "{latesttag('re:^.*-rc$') % '{tag}, {changes}, {distance}'}\n"

· Markieren Sie die übergeordnete Arbeitskopie mit '@':

$ hg log --template "{ifcontains(rev, revset('.'), '@')}\n"

· Details der übergeordneten Revisionen anzeigen:

$ hg log --template "{revset('parents(%d)', rev) % '{desc|firstline}\n'}"

· Nur Commit-Beschreibungen anzeigen, die mit „Vorlage“ beginnen:

$ hg log --template "{startswith('template', firstline(desc))}\n"

· Drucken Sie das erste Wort jeder Zeile einer Commit-Nachricht:

$ hg log --template "{word(0, desc)}\n"

URL PFADE

Gültige URLs haben folgende Form:

lokal/Dateisystem/Pfad[#revision]
file://local/filesystem/path[#revision]
http://[user[:pass]@]host[:port]/[path][#revision]
https://[user[:pass]@]host[:port]/[path][#revision]
ssh://[Benutzer@]Host[:Port]/[Pfad][#Revision]

Pfade im lokalen Dateisystem können entweder auf Mercurial-Repositories oder auf Bundles verweisen
Dateien (wie erstellt von hg bündeln or hg eingehende --bündeln). Siehe auch hg Hilfe Pfade.

Ein optionaler Bezeichner nach # gibt einen bestimmten Zweig, Tag oder Änderungssatz an, der verwendet werden soll
aus dem entfernten Repository. Siehe auch hg Hilfe Revisionen.

Einige Funktionen, wie z. B. Pushen auf http://- und https://-URLs, sind nur möglich, wenn die
Funktion auf dem Remote-Mercurial-Server explizit aktiviert ist.

Beachten Sie, dass die Sicherheit von HTTPS-URLs von der richtigen Konfiguration von web.cacerts abhängt.

Einige Hinweise zur Verwendung von SSH mit Mercurial:

· SSH erfordert ein zugängliches Shell-Konto auf dem Zielcomputer und eine Kopie von hg in
der entfernte Pfad oder angegeben mit als remotecmd.

· Pfad ist standardmäßig relativ zum Home-Verzeichnis des entfernten Benutzers. Verwenden Sie einen zusätzlichen Schrägstrich bei
den Beginn eines Pfads, um einen absoluten Pfad anzugeben:

ssh://example.com//tmp/repository

· Mercurial verwendet keine eigene Komprimierung über SSH; das Richtige ist zu konfigurieren
es in deinem ~ / .ssh / Konfig, z.B:

Hosten Sie *.mylocalnetwork.example.com
Kompression Nr
Gastgeber *
Kompression ja

Geben Sie alternativ "ssh -C" als Ihren ssh-Befehl in Ihrer Konfigurationsdatei oder mit an
die Befehlszeilenoption --ssh.

Diese URLs können alle in Ihrer Konfigurationsdatei mit Pfadaliasnamen unter gespeichert werden
Abschnitt [Pfade] wie folgt:

[Wege]
alias1 = URL1
alias2 = URL2
...

Sie können den Alias ​​dann für jeden Befehl verwenden, der eine URL verwendet (z hg ziehen alias1
wird behandelt als hg ziehen URL1).

Zwei Pfad-Aliase sind etwas Besonderes, da sie als Standardwerte verwendet werden, wenn Sie die nicht angeben
URL zu einem Befehl:

Standard:
Wenn Sie mit hg clone ein Repository erstellen, speichert der Befehl clone den Speicherort von
das Quell-Repository als „Standard“-Pfad des neuen Repositorys. Diese wird dann verwendet
Wenn Sie den Pfad bei Push- und Pull-ähnlichen Befehlen weglassen (einschließlich eingehender und
abgehend).

Standard-Push:
Der Push-Befehl sucht nach einem Pfad namens „default-push“ und bevorzugt ihn
'default' wenn beide definiert sind.

ERWEITERUNGEN

Dieser Abschnitt enthält Hilfe zu Erweiterungen, die zusammen mit Mercurial vertrieben werden.
Hilfe für andere Erweiterungen ist im Hilfesystem verfügbar.

Acl
Hooks zur Kontrolle des Repository-Zugriffs

Dieser Hook ermöglicht es, den Schreibzugriff auf bestimmte Zweige und Pfade von a zu erlauben oder zu verweigern
Repository, wenn eingehende Änderungssätze über pretxnchangegroup und pretxncommit empfangen werden.

Die Berechtigung wird anhand des lokalen Benutzernamens auf dem System abgeglichen, auf dem der Haken gesetzt wird
läuft, und nicht der Committer des ursprünglichen Änderungssatzes (da letzterer lediglich
informativ).

Der acl-Hook wird am besten zusammen mit einer eingeschränkten Shell wie hgsh verwendet, um dies zu verhindern
Authentifizieren von Benutzern, die nichts anderes als Pushen oder Pullen tun. Der Haken ist es nicht
sicher zu verwenden, wenn Benutzer interaktiven Shell-Zugriff haben, da sie dann den Hook deaktivieren können. Noch
ist es sicher, wenn sich entfernte Benutzer ein Konto teilen, denn dann gibt es keine Unterscheidungsmöglichkeit
Them.

Die Reihenfolge, in der Zugriffsprüfungen durchgeführt werden, ist:

1. Ablehnungsliste für Filialen (Abschnitt acl.deny.branches)

2. Zulassungsliste für Branches (Abschnitt acl.allow.branches)

3. Sperrliste für Pfade (Abschnitt acl.deny)

4. Zulassungsliste für Pfade (Abschnitt acl.erlauben)

Die Allow- und Deny-Abschnitte nehmen Schlüssel-Wert-Paare.

Branchenbasiert Access Control
Verwenden Sie das acl.deny.branches und acl.allow.branches Sektionen, um branchenbasierten Zugriff zu haben
Kontrolle. Schlüssel in diesen Abschnitten können entweder sein:

· ein Filialname, oder

· ein Sternchen, passend zu einem Zweig;

Die entsprechenden Werte können entweder sein:

· eine durch Kommas getrennte Liste mit Benutzern und Gruppen oder

· ein Sternchen, passend für jeden;

Sie können das "!" Präfix für einen Benutzer- oder Gruppennamen, um den Sinn der Übereinstimmung umzukehren.

Pfadbasiert Access Control
Verwenden Sie das acl.deny und acl.erlauben Abschnitte, um eine pfadbasierte Zugriffskontrolle zu haben. Schlüssel in diesen
Abschnitte akzeptieren ein Teilbaummuster (standardmäßig mit einer Glob-Syntax). Die entsprechende
-Werte folgen der gleichen Syntax wie in den anderen Abschnitten oben.

Groups
Gruppennamen muss ein vorangestellt werden @ Symbol. Die Angabe eines Gruppennamens hat die gleiche Wirkung
als Angabe aller Benutzer in dieser Gruppe.

Sie können Gruppenmitglieder in der definieren acl.Gruppen Sektion. Wenn kein Gruppenname definiert ist
dort, und Mercurial läuft unter einem Unix-ähnlichen System, wird die Liste der Benutzer genommen
aus dem Betriebssystem. Andernfalls wird eine Ausnahme ausgelöst.

Beispiel Konfiguration
[Haken]

# Verwenden Sie dies, wenn Sie Zugriffsbeschränkungen zum Commit-Zeitpunkt überprüfen möchten
pretxncommit.acl = python:hgext.acl.hook

# Verwenden Sie dies, wenn Sie Zugriffsbeschränkungen für Pull, Push,
# bündeln und servieren.
pretxnchangegroup.acl = python:hgext.acl.hook

[acl]
# Erlauben oder verweigern Sie den Zugriff für eingehende Änderungen nur, wenn ihre Quelle ist
# hier aufgelistet, ansonsten passieren lassen. Quelle ist "dienen" für alle
# Fernzugriff (http oder ssh), "Push", "Pull" oder "Bundle", wenn die
# zugehörige Befehle werden lokal ausgeführt.
# Standard: dienen
Quellen = dienen

[acl.deny.branches]

# Jedem wird der eingefrorene Zweig verweigert:
eingefrorener Zweig = *

# Ein schlechter Benutzer wird auf allen Zweigen abgelehnt:
* = schlechter Benutzer

[acl.allow.branches]

# Ein paar Benutzer sind auf branch-a erlaubt:
Zweig-a = Benutzer-1, Benutzer-2, Benutzer-3

# Auf Branch-b ist nur ein Benutzer erlaubt:
Zweig-b = Benutzer-1

# Der Superuser ist auf jedem Zweig erlaubt:
* = Superuser

# Jeder darf auf Branch-for-Tests gehen:
branch-for-tests = *

[acl. verweigern]
# Diese Liste wird zuerst geprüft. Wenn eine Übereinstimmung gefunden wird, ist dies bei acl.allow nicht der Fall
# überprüft. Allen Benutzern wird Zugriff gewährt, wenn acl.deny nicht vorhanden ist.
# Format für beide Listen: glob pattern = user, ..., @group, ...

# Um alle abzugleichen, verwenden Sie ein Sternchen für den Benutzer:
# mein/glob/muster = *

# user6 hat keinen Schreibzugriff auf eine Datei:
** = Benutzer6

# Die Gruppe "hg-denied" hat keinen Schreibzugriff auf eine Datei:
** = @hg-verweigert

# Niemand wird trotzdem in der Lage sein, "DONT-TOUCH-THIS.txt" zu ändern
# jeder kann alle anderen Dateien ändern. Siehe unten.
src/main/resources/DONT-TOUCH-THIS.txt = *

[acl.allow]
# Wenn acl.allow nicht vorhanden ist, werden standardmäßig alle Benutzer zugelassen
# empty acl.allow = keine Benutzer erlaubt

# Benutzer "doc_writer" hat Schreibzugriff auf jede Datei unter "docs"
# Mappe:
docs/** = doc_writer

# Benutzer "jack" und Gruppe "designer" haben Schreibzugriff auf alle Dateien
# unter dem Ordner "images":
Bilder/** = Jack, @designers

# Jeder (außer "user6" und "@hg-denied" - siehe acl.deny oben)
# hat Schreibzugriff auf alle Dateien im Ordner "Ressourcen".
# (außer für 1 Datei. Siehe acl.deny):
src/main/resources/** = *

.hgtags = release_engineer

Beispiele Verwendung von ! Präfix
Angenommen, es gibt einen Zweig, zu dem nur ein bestimmter Benutzer (oder eine bestimmte Gruppe) pushen können soll, und
Sie möchten den Zugriff auf keine anderen möglicherweise erstellten Zweige einschränken.

Das "!" prefix ermöglicht es Ihnen, jeden außer einem bestimmten Benutzer oder einer bestimmten Gruppe am Pushen zu hindern
Änderungssätze in einem bestimmten Zweig oder Pfad.

In den folgenden Beispielen werden wir: 1) den Zugriff auf die Verzweigung „Ring“ jedem außer dem Benutzer verweigern
"gollum" 2) Verweigern Sie den Zugriff auf den Zweig "See" allen außer Mitgliedern der Gruppe "Hobbit" 3)
Zugriff auf eine Datei für jeden außer dem Benutzer „gollum“ verweigern

[acl.allow.branches]
# Leer

[acl.deny.branches]

# 1) nur 'gollum' kann sich auf den Zweig 'ring' festlegen;
# 'gollum' und alle anderen können sich immer noch auf einen anderen Zweig festlegen.
ring = !gollum

# 2) nur Mitglieder der Gruppe 'Hobbit' können sich auf den Zweig 'See' festlegen;
# 'Hobbit'-Mitglieder und alle anderen können sich weiterhin jedem anderen Zweig anschließen.
See = !@hobbit

# Sie können den Zugriff auch basierend auf Dateipfaden verweigern:

[acl.allow]
# Leer

[acl. verweigern]
# 3) Nur 'Gollum' kann die folgende Datei ändern;
# 'gollum' und alle anderen können immer noch jede andere Datei ändern.
/neblig/berge/höhle/ring = !gollum

blackbox
Repository-Ereignisse zum Debuggen in einer Blackbox protokollieren

Protokolliert Ereignisinformationen in .hg/blackbox.log, um beim Debuggen und Diagnostizieren von Problemen zu helfen. Das
Ereignisse, die protokolliert werden, können über den Konfigurationsschlüssel blackbox.track konfiguriert werden. Beispiele:

[Flugschreiber]
Spur = *

[Flugschreiber]
track = Befehl, Befehlsende, Befehlsausnahme, Exthook, Pythonhook

[Flugschreiber]
Spur = ankommend

[Flugschreiber]
# die Größe einer Protokolldatei begrenzen
maximale Größe = 1.5 MB
# bis zu N Protokolldateien rotieren, wenn die aktuelle zu groß wird
maxfiles = 3

Befehle
blackbox
Sehen Sie sich die letzten Repository-Ereignisse an:

hg blackbox [OPTION]...

Zeigen Sie die letzten Repository-Ereignisse an

Zubehör:

- l,--Grenze
die Anzahl der anzuzeigenden Ereignisse (Standard: 10)

Bugzilla
Hooks zur Integration mit dem Bugzilla Bug Tracker

Diese Hook-Erweiterung fügt Kommentare zu Fehlern in Bugzilla hinzu, wenn sich Änderungssätze auf Fehler beziehen
von Bugzilla ID gesehen werden. Der Kommentar wird mithilfe des Mercurial-Vorlagenmechanismus formatiert.

Die Fehlerreferenzen können optional eine Aktualisierung der aufgewendeten Stunden für Bugzilla enthalten
an dem Fehler arbeiten. Fehler können auch als behoben markiert werden.

Es stehen drei grundlegende Zugriffsmodi auf Bugzilla zur Verfügung:

1. Zugriff über die XMLRPC-Schnittstelle von Bugzilla. Benötigt Bugzilla 3.4 oder höher.

2. Daten über die XMLRPC-Schnittstelle von Bugzilla prüfen und Fehleränderung per E-Mail an senden
Bugzilla-E-Mail-Schnittstelle. Benötigt Bugzilla 3.4 oder höher.

3. Direktes Schreiben in die Bugzilla-Datenbank. Nur Bugzilla-Installationen mit MySQL sind
unterstützt. Benötigt Python MySQLdb.

Das direkte Schreiben in die Datenbank ist anfällig für Schemaänderungen und beruht auf a
Bugzilla-Beitragsskript zum Versenden von Benachrichtigungs-E-Mails über Fehleränderungen. Dieses Skript wird ausgeführt als
der Benutzer, der Mercurial ausführt, muss auf dem Host mit der Bugzilla-Installation ausgeführt werden, und
erfordert die Berechtigung zum Lesen der Bugzilla-Konfigurationsdetails und den erforderlichen MySQL-Benutzer
und Passwort, um volle Zugriffsrechte auf die Bugzilla-Datenbank zu haben. Aus diesen Gründen dies
Der Zugriffsmodus gilt jetzt als veraltet und wird für das neue Bugzilla nicht aktualisiert
Versionen weiter. In diesem Zugriffsmodus wird nur das Hinzufügen von Kommentaren unterstützt.

Für den Zugriff über XMLRPC müssen ein Bugzilla-Benutzername und ein Passwort in der angegeben werden
Aufbau. Kommentare werden unter diesem Benutzernamen hinzugefügt. Da muss die Konfiguration sein
von allen Mercurial-Benutzern lesbar ist, wird empfohlen, dass die Rechte dieses Benutzers vorhanden sind
in Bugzilla auf das zum Hinzufügen von Kommentaren erforderliche Minimum beschränkt. Markierungsfehler behoben
erfordert Bugzilla 4.0 und höher.

Der Zugriff über XMLRPC/E-Mail verwendet XMLRPC, um Bugzilla abzufragen, sendet jedoch eine E-Mail an Bugzilla
E-Mail-Schnittstelle zum Einreichen von Kommentaren zu Fehlern. Die Von:-Adresse in der E-Mail ist auf gesetzt
E-Mail-Adresse des Mercurial-Benutzers, sodass der Kommentar anscheinend von Mercurial stammt
Benutzer. Für den Fall, dass die Mercurial-Benutzer-E-Mail von Bugzilla nicht als
Bugzilla-Benutzer, die mit dem Bugzilla-Benutzernamen verknüpfte E-Mail-Adresse, die zum Anmelden bei Bugzilla verwendet wird
wird stattdessen als Quelle des Kommentars verwendet. Das Markieren von behobenen Fehlern funktioniert auf allen unterstützten
Bugzilla-Versionen.

Gemeinsame Konfigurationselemente für alle Zugriffsmodi:

bugzilla.version
Der zu verwendende Zugriffstyp. Anerkannte Werte sind:

xmlrpc

Bugzilla XMLRPC-Schnittstelle.

xmlrpc + E-Mail

Bugzilla XMLRPC und E-Mail-Schnittstellen.

3.0

MySQL-Zugriff, Bugzilla 3.0 und höher.

2.18

MySQL-Zugriff, Bugzilla 2.18 und bis einschließlich 3.0.

2.16

MySQL-Zugriff, Bugzilla 2.16 und bis einschließlich 2.18.

bugzilla.regexp
Regulärer Ausdruck zum Abgleichen von Fehler-IDs für die Aktualisierung in der Changeset-Commit-Nachricht. Es
muss eine "()" benannte Gruppe enthalten enthält die durch getrennten Fehler-IDs
nichtstellige Zeichen. Es kann auch eine benannte Gruppe enthalten mit
Fließkommazahl, die die Stunden angibt, die an dem Fehler gearbeitet wurden. Wenn keine benannten Gruppen sind
vorhanden ist, wird angenommen, dass die erste "()"-Gruppe die Fehler-IDs enthält, und die Arbeitszeit ist
Nicht aktualisiert. Der Standardausdruck passt Fehler 1234, Fehler Nr. 1234, Fehler Anzahl
1234, Fehler 1234,5678, Fehler 1234 und 5678 und Variationen davon, gefolgt von an
Stundenzahl mit vorangestelltem h or Stunden, z.B Stunden 1.5. Beim Abgleich wird die Groß-/Kleinschreibung nicht beachtet.

bugzilla.fixregexp
Regulärer Ausdruck zum Abgleichen von Fehler-IDs zum Markieren von behoben in der Changeset-Commit-Nachricht.
Diese muss eine „()“ benannte Gruppe enthalten ` mit Fehler IDs getrennt by
Nicht-Ziffer Zeichen. It Mai ebenfalls enthalten a namens Gruppe „ mit
Fließkommazahl, die die Stunden angibt, die an dem Fehler gearbeitet wurden. Wenn keine benannten Gruppen sind
vorhanden ist, wird angenommen, dass die erste "()"-Gruppe die Fehler-IDs enthält, und die Arbeitszeit ist
Nicht aktualisiert. Der Standardausdruck passt Fehlerkorrekturen 1234, Fehlerkorrekturen Fehler 1234, Fehlerkorrekturen Bugs
1234,5678, Fehlerkorrekturen 1234 und 5678 und Variationen davon, gefolgt von einer Stundenzahl
mit vorangestelltem h or Stunden, z.B Stunden 1.5. Beim Abgleich wird die Groß-/Kleinschreibung nicht beachtet.

bugzilla.fixstatus
Der Status, auf den ein Fehler gesetzt werden soll, wenn er als behoben markiert wird. Standard ENTSCHLOSSEN.

bugzilla.fixresolution
Die Auflösung, um einen Fehler beim Markieren als behoben zu setzen. Standard FIXED.

bugzilla.style
Die Stildatei, die beim Formatieren von Kommentaren verwendet werden soll.

bugzilla.template
Vorlage zum Formatieren von Kommentaren. Überschreibt den Stil, falls angegeben. Zusätzlich
zu den üblichen Mercurial-Schlüsselwörtern spezifiziert die Erweiterung:

{Insekt}

Die Bugzilla-Fehler-ID.

{Wurzel}

Der vollständige Pfadname des Mercurial-Repositorys.

{webroot}

Entfernter Pfadname des Mercurial-Repositorys.

{hgweb}

Basis-URL zum Durchsuchen von Mercurial-Repositories.

Standard changeset {Knoten|kurz} in Repo {Wurzel} bezieht sich zu Fehler
{bug}.\ndetails:\n\t{desc|tabindent}

bugzilla.strip
Die Anzahl der Pfadtrennzeichen, die von der Vorderseite des Mercurial entfernt werden sollen
Repository-Pfad ({Wurzel} in Vorlagen) zu produzieren {webroot}. Zum Beispiel a
Repository mit {Wurzel} /var/local/mein-projekt mit einem Streifen von 2 ergibt einen Wert für
{webroot} of Mein Projekt. Standard 0.

web.baseurl
Basis-URL zum Durchsuchen von Mercurial-Repositories. Von Vorlagen referenziert als {hgweb}.

Gemeinsame Konfigurationselemente für XMLRPC+E-Mail- und MySQL-Zugriffsmodi:

bugzilla.usermap
Pfad der Datei, die E-Mail-Zuordnungen von Mercurial-Committern zu E-Mail-Adressen von Bugzilla-Benutzern enthält.
Falls angegeben, sollte die Datei eine Zuordnung pro Zeile enthalten:

committer = Bugzilla-Benutzer

Siehe auch die [Benutzerkarte] .

Das [Benutzerkarte] -Abschnitt wird verwendet, um Zuordnungen von Mercurial-Committer-E-Mails zu Bugzilla anzugeben
Benutzer Email. Siehe auch bugzilla.usermap. Enthält Einträge des Formulars Committer = Bugzilla
Benutzer.

Konfiguration des XMLRPC-Zugriffsmodus:

bugzilla.bzurl
Die Basis-URL für die Bugzilla-Installation. Standard http://localhost/bugzilla.

bugzilla.user
Der Benutzername für die Anmeldung bei Bugzilla über XMLRPC. Standard Bugs.

bugzilla.passwort
Das Passwort für die Bugzilla-Anmeldung.

Der XMLRPC+E-Mail-Zugriffsmodus verwendet die XMLRPC-Zugriffsmodus-Konfigurationselemente und außerdem:

bugzilla.bzemail
Die E-Mail-Adresse von Bugzilla.

Außerdem müssen die Mercurial-E-Mail-Einstellungen konfiguriert werden. Siehe die Dokumentation in
hgrc(5), Abschnitte [Email] und [SMTP].

Konfiguration des MySQL-Zugriffsmodus:

bugzilla.host
Hostname des MySQL-Servers, auf dem sich die Bugzilla-Datenbank befindet. Standard localhost.

bugzilla.db
Name der Bugzilla-Datenbank in MySQL. Standard Bugs.

bugzilla.user
Benutzername für den Zugriff auf den MySQL-Server. Standard Bugs.

bugzilla.passwort
Passwort für den Zugriff auf den MySQL-Server.

bugzilla.timeout
Timeout der Datenbankverbindung (Sekunden). Standard 5.

bugzilla.bzuser
Fallback-Bugzilla-Benutzername zum Aufzeichnen von Kommentaren, wenn der Changeset-Committer dies nicht kann
als Bugzilla-Benutzer gefunden werden.

bugzilla.bzdir
Bugzilla-Installationsverzeichnis. Standardmäßig verwendet Benachrichtigung. Standard /var/www/html/bugzilla.

bugzilla.notify
Der auszuführende Befehl, um Bugzilla dazu zu bringen, Benachrichtigungs-E-Mails über Fehleränderungen zu senden.
Stellvertreter aus einer Karte mit 3 Schlüsseln, bzdir, id (Fehler-ID) und Benutzer (Commiter bugzilla
Email). Standard hängt von der Version ab; ab 2.18 ist es "cd %(bzdir)s && perl -T
contrib/sendbugmail.pl %(id)s %(user)s".

Aktivieren der Erweiterung:

[Erweiterungen]
bugzilla=

[Haken]
# Führen Sie den Bugzilla-Hook bei jeder Änderung aus, die hier gezogen oder eingefügt wird
eingehende.bugzilla = python:hgext.bugzilla.hook

Beispielkonfigurationen:

XMLRPC-Beispielkonfiguration. Dies nutzt der Bugzilla bei http://my-project.org/bugzilla,
als Benutzer anmelden [E-Mail geschützt] mit Passwort zupfen. Es wird mit a verwendet
Sammlung von Mercurial-Repositories in /var/local/hg/repos/, mit einer Webschnittstelle unter
http://my-project.org/hg.

[Bugzilla]
bzurl=http://my-project.org/bugzilla
Benutzer=[E-Mail geschützt]
Passwort=plugh
version=xmlrpc
template=Änderungssatz {node|short} in {root|basename}.
{hgweb}/{webroot}/rev/{node|short}\n
{ab}\n
Streifen=5

[Netz]
baseurl=http://my-project.org/hg

XMLRPC+E-Mail-Beispielkonfiguration. Dies nutzt der Bugzilla bei
http://my-project.org/bugzilla, als Benutzer anmelden [E-Mail geschützt] mit Passwort
zupfen. Es wird mit einer Sammlung von Mercurial-Repositories in verwendet /var/local/hg/repos/,
mit einem Webinterface unter http://my-project.org/hg. Fehlerkommentare werden an Bugzilla gesendet
E-Mail-Addresse [E-Mail geschützt] .

[Bugzilla]
bzurl=http://my-project.org/bugzilla
Benutzer=[E-Mail geschützt]
Passwort=plugh
Version=xmlrpc+E-Mail
bzemail=[E-Mail geschützt]
template=Änderungssatz {node|short} in {root|basename}.
{hgweb}/{webroot}/rev/{node|short}\n
{ab}\n
Streifen=5

[Netz]
baseurl=http://my-project.org/hg

[Benutzerkarte]
[E-Mail geschützt] =[E-Mail geschützt]

MySQL-Beispielkonfiguration. Dies hat eine lokale Bugzilla 3.2-Installation in
/opt/bugzilla-3.2. Die MySQL-Datenbank ist eingeschaltet localhost, der Name der Bugzilla-Datenbank lautet Bugs
und auf MySQL wird mit dem MySQL-Benutzernamen zugegriffen Bugs Passwort XYZZY. Es wird mit a verwendet
Sammlung von Mercurial-Repositories in /var/local/hg/repos/, mit einer Webschnittstelle unter
http://my-project.org/hg.

[Bugzilla]
host=localhost
Passwort=XYZZY
version = 3.0
bzuser=[E-Mail geschützt]
bzdir=/opt/bugzilla-3.2
template=Änderungssatz {node|short} in {root|basename}.
{hgweb}/{webroot}/rev/{node|short}\n
{ab}\n
Streifen=5

[Netz]
baseurl=http://my-project.org/hg

[Benutzerkarte]
[E-Mail geschützt] =[E-Mail geschützt]

Alle oben genannten fügen einen Kommentar zum Bugzilla-Bug-Record des Formulars hinzu:

Änderungssatz 3b16791d6642 in Repository-Name.
http://my-project.org/hg/repository-name/rev/3b16791d6642

Commit-Kommentar zum Änderungssatz. Fehler 1234.

zensieren
Dateiinhalt bei einer bestimmten Revision löschen

Der Befehl censor weist Mercurial an, den gesamten Inhalt einer Datei bei einer bestimmten Revision zu löschen
ohne Aktualisierung changeset hash Dadurch kann die vorhandene Historie gültig bleiben
Verhindern, dass zukünftige Klone/Pulls die gelöschten Daten erhalten.

Typische Anwendungen für die Zensur sind aufgrund von Sicherheits- oder gesetzlichen Anforderungen, einschließlich:

* Passwörter, private Schlüssel, kryptografisches Material
* Lizenzierte Daten/Code/Bibliotheken, für die die Lizenz abgelaufen ist
* Persönlich identifizierbare Informationen oder andere private Daten

Zensierte Knoten können den typischen Betrieb von Mercurial unterbrechen, wann immer die herausgeschnittenen Daten dies benötigen
materialisiert werden. Einige Befehle, wie z hg Katze/hg zurückkehren, scheitern einfach, wenn Sie dazu aufgefordert werden
zensierte Daten produzieren. Andere mögen hg überprüfen und hg Aktualisierung, muss erträglich sein
zensierte Daten weiterhin sinnvoll funktionieren. Solche Befehle nur tolerieren
zensierte Dateirevisionen, wenn sie von der Konfigurationsoption "censor.policy=ignore" zugelassen werden.

Befehle
zensieren
hg censor -r REV [-t TEXT] [DATEI]

Zubehör:

-R,--rev
Zensurdatei aus der angegebenen Revision

-T,--Grabstein
Ersatz-Tombstone-Daten

Änderungsserver
Befehlsserver-Erweiterung für cHg (EXPERIMENTELL)

'S' Kanal (lesen Schreiben)
ui.system()-Anfrage an den Client weitergeben

'Anhang' Befehl
stdio des Clients anhängen, das von sendmsg() übergeben wird

'chdir' Befehl
aktuelles Verzeichnis wechseln

'Getpager' Befehl
prüft, ob Pager aktiviert ist und welcher Pager ausgeführt werden soll

'setenv' Befehl
Ersetzen Sie os.environ vollständig

'SEUFZEND' Signal
Konfigurationsdateien neu laden

und Kindern
Befehl zum Anzeigen untergeordneter Änderungssätze (VERALTET)

Diese Erweiterung ist veraltet. Du solltest benutzen hg Log -r "Kinder (REV)" stattdessen.

Befehle
und Kindern
zeige die Kinder der gegebenen oder Arbeitsverzeichnisrevision:

hg Kinder [-r REV] [DATEI]

Gibt die Kinder der Revisionen des Arbeitsverzeichnisses aus. Wenn eine Revision per gegeben wird
-r/--rev, die Kinder dieser Revision werden gedruckt. Wenn ein Dateiargument angegeben wird,
Revision, in der die Datei zuletzt geändert wurde (nach der Revision des Arbeitsverzeichnisses oder der
Argument für --rev falls angegeben) wird ausgegeben.

Benutzen Sie bitte hg Log stattdessen:

hg Kinder => hg log -r 'Kinder()'
hg children -r REV => hg log -r 'Kinder (REV)'

See hg Hilfe Log und hg Hilfe drehzahlen.kinder.

Zubehör:

-R,--rev
Kinder der angegebenen Revision anzeigen

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

Abwanderung
Befehl zum Anzeigen von Statistiken zum Repository-Verlauf

Befehle
Abwanderung
Histogramm der Änderungen am Repository:

hg churn [-d DATUM] [-r REV] [--aliases DATEI] [DATEI]

Dieser Befehl zeigt ein Histogramm an, das die Anzahl der geänderten Zeilen oder darstellt
Revisionen, gruppiert nach der gegebenen Vorlage. Die Standardvorlage wird gruppiert
Änderungen durch den Autor. Die Option --dateformat kann verwendet werden, um die Ergebnisse nach Datum zu gruppieren
stattdessen.

Die Statistik basiert auf der Anzahl geänderter Zeilen oder alternativ auf der Anzahl geänderter Zeilen
übereinstimmende Revisionen, wenn die Option --changesets angegeben ist.

Beispiele:

# Zeigt die Anzahl der geänderten Zeilen für jeden Committer an
hg churn -t "{Autor|E-Mail}"

# tägliches Aktivitätsdiagramm anzeigen
hg churn -f "%H" -s -c

# Zeigt die Aktivität der Entwickler nach Monat an
hg churn -f "%Y-%m" -s -c

# Zeigt die Anzahl der Zeilen an, die sich in jedem Jahr geändert haben
hg churn -f "%Y" -s

Es ist möglich, alternative E-Mail-Adressen einer Hauptadresse zuzuordnen, indem eine Datei bereitgestellt wird
mit dem folgenden Format:

=

Eine solche Datei kann mit der Option --aliases angegeben werden, andernfalls wäre es eine .hgchurn-Datei
im Arbeitsverzeichnis root gesucht. Aliasse werden vom ganz rechten "=" getrennt.

Zubehör:

-R,--rev
Zählrate für die angegebene Revision oder Revset

-D,--Datum
Zählrate für Revisionen passend zum Datum spez

-T,--alte Vorlage
Vorlage zum Gruppieren von Änderungssätzen (VERALTET)

-T,--Vorlage
Vorlage zum Gruppieren von Änderungssätzen (Standard: {Autor|E-Mail})

-F,--Datumsformat
strftime-kompatibles Format zum Gruppieren nach Datum

-C, --Änderungssätze
Zählrate nach Anzahl der Änderungssätze

-S, --Sortieren
nach Schlüssel sortieren (Standard: nach Anzahl sortieren)

--diffstat
hinzugefügte/entfernte Zeilen separat anzeigen

--aliase
Datei mit E-Mail-Aliase

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Klonbündel
Werbung für vorgenerierte Bundles für Seed-Klone

"clonebundles" ist eine serverseitige Erweiterung, die verwendet wird, um die Existenz von anzukündigen
vorgenerierte, extern gehostete Bundle-Dateien an Clients, die klonen, damit das Klonen
kann schneller und zuverlässiger sein und benötigt weniger Ressourcen auf dem Server.

Das Klonen kann auf Servern ein CPU- und E/A-intensiver Vorgang sein. Traditionell ist der Server, in
Antwort auf die Anforderung eines Clients zum Klonen, generiert dynamisch ein Bundle, das die
gesamten Repository-Inhalt und sendet ihn an den Client. Es gibt kein Caching auf dem Server
und der Server muss als Antwort darauf redundant dasselbe ausgehende Bündel generieren
jede Klonanforderung. Für Server mit großen Repositories oder mit hohem Klonvolumen ist die
Last von Klonen kann die Skalierung des Servers schwierig und kostspielig machen.

Diese Erweiterung bietet Serverbetreibern die Möglichkeit, potenziell teure Ressourcen auszulagern
klonen Sie die Last auf einen externen Dienst. So funktioniert das.

1. Ein Serverbetreiber richtet einen Mechanismus ein, um Bundle-Dateien verfügbar zu machen auf a
Hosting-Service, wo Mercurial-Kunden sie abrufen können.

2. Eine Manifestdatei, die verfügbare Bundle-URLs und einige optionale Metadaten auflistet, wird hinzugefügt
das Mercurial-Repository auf dem Server.

3. Ein Client initiiert einen Klon gegen einen Klon-Bundle-fähigen Server.

4. Der Client sieht, dass der Server Clone-Bundles ankündigt, und ruft das Manifest ab
Verfügbare Pakete auflisten.

5. Der Client filtert und sortiert die verfügbaren Bundles basierend darauf, was er unterstützt und
bevorzugt.

6. Der Client lädt ein verfügbares Bundle von der vom Server angegebenen URL herunter und wendet es an.

7. Der Client verbindet sich erneut mit dem ursprünglichen Server und führt das Äquivalent von durch hg ziehen zu
Rufen Sie alle Repository-Daten ab, die nicht im Bundle enthalten sind. (Das Repository könnte aktualisiert worden sein
zwischen der Erstellung des Bundles und dem Start des Klons durch den Client.)

Anstatt dass der Server für jede Klonanforderung vollständige Repository-Bundles generiert, wird it
generiert einmal vollständige Bundles und sie werden anschließend wiederverwendet, um neue Klone zu booten. Das
Der Server kann zur Klonzeit immer noch Daten übertragen. Dies sind jedoch nur Daten, die wurden
hinzugefügt/geändert, seit das Bundle erstellt wurde. Bei großen, etablierten Repositories kann dies der Fall sein
Reduzieren Sie die Serverlast für Klone auf weniger als 1 % des Originals.

Um zu funktionieren, erfordert diese Erweiterung die folgenden Serverbetreiber:

· Generieren von Bündeldateien mit Repository-Inhalten (normalerweise regelmäßig, z. B. einmal pro
Tag).

· Ein Dateiserver, auf den Clients Netzwerkzugriff haben und mit dem Python kommunizieren kann
über seine normale URL-Handhabungseinrichtung (normalerweise ein HTTP-Server).

· Ein Prozess, um das Bundle-Manifest mit den verfügbaren Bundle-Dateien synchron zu halten.

Genau genommen ist die Verwendung eines statischen Datei-Hosting-Servers nicht erforderlich: ein Serverbetreiber
könnte einen dynamischen Dienst zum Abrufen von Bündeldaten verwenden. Allerdings statisches Dateihosting
Die Dienste sind einfach und skalierbar und sollten für die meisten Anforderungen ausreichen.

Bundle-Dateien können mit der generiert werden hg bündeln Befehl. Typisch hg bündeln --alle is
verwendet, um ein Bündel des gesamten Repositorys zu erstellen.

hg debugcreatestreamclonebundle kann verwendet werden, um ein besonderes zu produzieren Streaming klonen bündeln.
Dies sind Bundle-Dateien, die äußerst effizient zu produzieren und zu konsumieren sind (sprich: schnell).
Sie sind jedoch größer als herkömmliche Bündelformate und erfordern die Unterstützung durch den Kunden
der genaue Satz von Repository-Datenspeicherformaten, die von dem Repository verwendet werden, das sie erstellt hat.
In der Regel kann ein neuerer Server Daten bereitstellen, die mit älteren Clients kompatibel sind. Jedoch,
Streaming klonen Bündel habe diese Garantie nicht. Server Betreiber technische zu be bewusst zur Verbesserung der Gesundheitsgerechtigkeit
neuer Versionen of Quecksilber- Mai produziert Streaming klonen Bündel unvereinbar mit Telefongebühren sparen
Quecksilber- Versionen.

Ein Serverbetreiber ist für die Erstellung einer .hg/clonebundles.manifest Datei mit
die Liste der verfügbaren Bundle-Dateien, die zum Seeding von Klonen geeignet sind. Wenn diese Datei nicht
existieren, wird das Repository die Existenz von Klon-Bundles nicht ankündigen, wenn Clients
zu verbinden.

Die Manifestdatei enthält eine durch Zeilenumbrüche ( ) getrennte Liste von Einträgen.

Jede Zeile in dieser Datei definiert ein verfügbares Bundle. Zeilen haben das Format:

[ = [ = ]]

Das heißt, eine URL, gefolgt von einer optionalen, durch Leerzeichen getrennten Liste von Schlüssel=Wert-Paaren, die beschreiben
zusätzliche Eigenschaften dieses Bündels. Sowohl Schlüssel als auch Werte sind URI-kodiert.

Schlüssel in GROSSBUCHSTABEN sind für die Verwendung durch Mercurial reserviert und werden unten definiert. Alle
Nicht in Großbuchstaben geschriebene Schlüssel können von Standortinstallationen verwendet werden. Ein Beispiel für die Verwendung von benutzerdefinierten Eigenschaften
ist das zu benutzen Rechenzentrum -Attribut, um festzulegen, in welchem ​​Rechenzentrum eine Datei gehostet wird.
Kunden könnten dann einen Server im nächstgelegenen Rechenzentrum bevorzugen.

Die folgenden reservierten Schlüssel sind derzeit definiert:

BUNDLESPEZ
Eine "Bundle-Spezifikation"-Zeichenfolge, die den Typ des Bundles beschreibt.

Dies sind Zeichenfolgenwerte, die vom "--type"-Argument von akzeptiert werden hg bündeln.

Die Werte werden im strikten Modus geparst, was bedeutet, dass sie vom Typ sein müssen
" - " Form. Weitere Informationen finden Sie unter mercurial.exchange.parsebundlespec()
Details.

hg Debugbundle --spez kann verwendet werden, um die Bundle-Spezifikationszeichenfolge für a zu drucken
Bundle-Datei. Die Ausgabe dieses Befehls kann wörtlich für den Wert von verwendet werden
BUNDLESPEZ (es ist bereits entkommen).

Clients filtern automatisch Spezifikationen heraus, die unbekannt sind oder
nicht unterstützt, damit sie nicht versuchen, etwas herunterzuladen, das wahrscheinlich nicht zutrifft.

Der tatsächliche Wert wirkt sich über das Filtern hinaus nicht auf das Clientverhalten aus: Clients werden es tun
schnüffeln Sie immer noch den Bundle-Typ aus dem Header der heruntergeladenen Dateien.

Verwenden Sie die of fehlen uns die Worte. Schlüssel is hoch empfohlen, da Clients problemlos überspringen können
nicht unterstützte Pakete. Wenn dieser Schlüssel nicht definiert ist, kann ein alter Client versuchen, sich zu bewerben
ein Bündel, das es nicht lesen kann.

ERFORDERLICHNI
Ob Server Name Indication (SNI) erforderlich ist, um eine Verbindung mit der URL herzustellen. SNI ermöglicht
Server, mehrere Zertifikate auf derselben IP zu verwenden. Es ist etwas üblich in CDNs
und andere Hosting-Anbieter. Ältere Python-Versionen unterstützen SNI nicht. Definieren
Dieses Attribut ermöglicht es Clients mit älteren Python-Versionen, diesen Eintrag zu filtern
ohne dass zum Zeitpunkt der Verbindung ein undurchsichtiger SSL-Fehler auftritt.

Wenn dies definiert ist, ist es wichtig, eine Nicht-SNI-Fallback-URL oder Clients zu bewerben
Laufende alte Python-Releases können möglicherweise nicht mit den Clonebundles klonen
Möglichkeiten.

Der Wert sollte "true" sein.

Manifeste können mehrere Einträge enthalten. Unter der Annahme, dass Metadaten definiert sind, werden Clients filtern
Einträge aus dem Manifest, die sie nicht unterstützen. Die restlichen Einträge sind optional
sortiert nach Kundenpräferenzen (Experimental.clonebundleprefers Konfigurationsoption). Der Kunde
versucht dann, das Bundle unter der ersten URL in der verbleibenden Liste abzurufen.

Fehler wann Herunterladen a bündeln werden wir scheitern klonen Operation: Kunden do nicht
Im Prinzip so, wie Sie es von Google Maps kennen. fallen Zurück zu a traditionell klonen. Der Grund dafür ist, dass wenn ein Server ist
Wenn Sie Klonpakete verwenden, geschieht dies wahrscheinlich, weil die Funktion zur Unterstützung erforderlich ist
Skala. Mit anderen Worten, es wird davon ausgegangen, dass die Klonlast auf eine andere ausgelagert wird
Service und dass der Mercurial-Server nicht dafür verantwortlich ist, diese Clone-Last zu bedienen. Wenn
dass bei anderen Diensten Probleme auftreten und Kunden massenweise auf das Original zurückfallen
Mercurial-Server, die hinzugefügte Klonlast könnte den Server aufgrund unerwarteter Last überfordern
und effektiv offline nehmen. Clients werden nicht automatisch auf das Klonen zurückgesetzt
vom ursprünglichen Server entschärft dieses Szenario.

Denn es gibt keinen automatischen Mercurial-Server-Fallback bei Ausfall des Bundle-Hostings
Service, ist es für Serverbetreiber wichtig, den Bundle-Hosting-Service als einen zu betrachten
Erweiterung des Mercurial-Servers in Bezug auf Verfügbarkeit und Service Level Agreements:
Wenn der Bundle-Hosting-Service ausfällt, fällt auch die Möglichkeit für Clients zum Klonen aus. Notiz:
Clients sehen eine Meldung, die sie darüber informiert, wie sie die Clone-Bundle-Funktion umgehen können, wenn a
Ausfall auftritt. Serverbetreiber sollten sich also darauf vorbereiten, dass einige Leute diesen folgen
Anweisungen, wenn ein Fehler auftritt, wodurch mehr Last auf das ursprüngliche Mercurial gelenkt wird
Server, wenn der Bundle-Hosting-Dienst ausfällt.

Farbe
die Ausgabe einiger Befehle einfärben

Die Farberweiterung koloriert die Ausgabe mehrerer Mercurial-Befehle. Zum Beispiel die
Der Befehl diff zeigt Hinzufügungen grün und Löschungen rot an, während der Befehl status angezeigt wird
geänderte Dateien in Magenta. Viele andere Befehle haben analoge Farben. Es ist möglich zu
Passen Sie diese Farben an.

Effekte
Neben Farbe sind auch andere Effekte wie fetter und unterstrichener Text verfügbar. Durch
Standardmäßig wird die terminfo-Datenbank verwendet, um die Terminalcodes zu finden, die zum Ändern der Farbe und verwendet werden
Wirkung. Wenn Termininfo nicht verfügbar ist, werden Effekte mit ECMA-48 SGR gerendert
Steuerfunktion (auch bekannt als ANSI-Escape-Codes).

Die verfügbaren Effekte im Termininfo-Modus sind 'blink', 'bold', 'dim', 'inverse', 'invisible',
„kursiv“, „herausragend“ und „unterstrichen“; im ECMA-48-Modus sind die Optionen 'fett', 'invers',
„kursiv“ und „unterstrichen“. Wie jeder gerendert wird, hängt vom Terminal-Emulator ab. Etwas
ist möglicherweise für einen bestimmten Terminaltyp nicht verfügbar und wird stillschweigend ignoriert.

Etiketten
Text erhält je nach Beschriftung Farbeffekte. Viele Standard-Mercurial
Befehle geben beschrifteten Text aus. Sie können auch Ihre eigenen Etiketten in Vorlagen definieren, indem Sie die verwenden
Label-Funktion, siehe hg Hilfe Vorlagen. Ein einzelner Textabschnitt kann mehr als einen haben
Etikett. In diesem Fall überschreiben die dem letzten Etikett zugewiesenen Effekte alle anderen Effekte. Dies
enthält den Spezialeffekt "Keine", der andere Effekte zunichte macht.

Beschriftungen sind normalerweise unsichtbar. Um diese Labels und ihre Position in der zu sehen
Text, verwenden Sie die globale Option --color=debug. Es kann derselbe Ankertext zugeordnet werden
mehrere Etiketten, z

[log.changeset changeset.secret|changeset: 22611:6f0a53c8f587]

Im Folgenden sind die Standardeffekte für einige Standardetiketten aufgeführt. Standardeffekte können sein
von Ihrer Konfigurationsdatei überschrieben:

[Farbe]
status.modified = blau fett unterstrichen red_background
status.added = grün fett
status.removed = roter fetter blauer_hintergrund
status.deleted = Cyan fett unterstrichen
status.unknown = Magenta fett unterstrichen
status.ignored = schwarz fett

# 'none' schaltet alle Effekte aus
status.clean = keine
status.kopiert = keine

qseries.applied = blaue fette Unterstreichung
qseries.unapplied = schwarz fett
qseries.missing = rot fett

diff.diffline = fett
diff.extended = Cyan fett
diff.file_a = rot fett
diff.file_b = grün fett
diff.hunk = Magenta
diff.gelöscht = rot
diff. eingefügt = grün
diff.geändert = weiß
diff.tab =
diff.trailingwhitespace = fetter roter_Hintergrund

# Leer, damit es den Stil des umgebenden Labels erbt
changeset.public =
changeset.draft =
changeset.secret =

resolve.unresolved = rot fett
resolve.resolved = grün fett

lesezeichen.aktiv = grün

Branches.active = keine
Branches.closed = schwarz fett
Branches.current = grün
Branches.inactive = keine

tags.normal = grün
tags.local = schwarz fett

rebase.rebased = blau
rebase.remaining = rot fett

regal.alter = cyan
shelve.newest = grün fett
regal.name = blau fett

histedit.remaining = rot fett

Maßgeschneidert Farben
Da es nur acht Standardfarben gibt, können Sie mit diesem Modul Farbnamen definieren
für andere Farbslots, die für Ihren Terminaltyp verfügbar sein könnten, vorausgesetzt, terminfo
Modus. Zum Beispiel:

color.hellblau = 12
Farbe.Rosa = 207
Farbe.Orange = 202

um 'hellblau' auf Farbsteckplatz 12 einzustellen (nützlich für 16-farbige Terminals, die hellere
Farben, die in den oberen acht definiert sind) und 'Pink' und 'Orange' für Farben in 256-Farben-Xterms
Standardfarbwürfel. Diese definierten Farben können dann als beliebige der vordefinierten verwendet werden
acht, einschließlich des Anhängens von '_background', um den Hintergrund auf diese Farbe einzustellen.

Modi
Standardmäßig verwendet die Farberweiterung den ANSI-Modus (oder den Win32-Modus unter Windows), wenn dies der Fall ist
erkennt ein Endgerät. Um den Auto-Modus außer Kraft zu setzen (z. B. um den Termininfo-Modus zu aktivieren), legen Sie fest
folgende Konfigurationsmöglichkeit:

[Farbe]
Modus = Termininfo

Jeder andere Wert als „ansi“, „win32“, „terminfo“ oder „auto“ deaktiviert die Farbe.

Beachten Sie, dass der terminfo-Modus auf manchen Systemen Probleme bei der Verwendung von Farbe mit dem verursachen kann
Pager-Erweiterung und weniger -R. less mit der Option -R zeigt nur ECMA-48-Farbe an
Codes, und der Termininfo-Modus kann manchmal Codes ausgeben, die Lesser nicht versteht. Du kannst
Umgehen Sie dies, indem Sie entweder den Ansi-Modus (oder den Auto-Modus) verwenden oder less -r verwenden (was
alle Terminal-Steuercodes durchlaufen, nicht nur Farb-Steuercodes).

Auf einigen Systemen (z. B. MSYS in Windows) unterstützt das Terminal möglicherweise einen anderen Farbmodus
als der Pager (aktiviert über die Erweiterung "pager"). Es ist möglich, separat zu definieren
Modi abhängig davon, ob der Pager aktiv ist:

[Farbe]
Modus = automatisch
pagermode = ansi

If Pagermodus ist nicht definiert, die Modus werden verwendet.

Befehle
verkaufen
Revisionen aus fremden VCS-Repositorys in Mercurial importieren

Befehle
verkaufen
Konvertieren Sie ein fremdes SCM-Repository in ein Mercurial-Repository.:

hg convert [OPTION]... QUELLE [DEST [REVMAP]]

Akzeptierte Quellformate [Bezeichner]:

· Quecksilber [hg]

· Lebenslauf [Lebenslauf]

· Darcs [Darks]

· git [git]

· Unterversion [svn]

· Monoton [mtn]

· GNU-Bogen [gnuarch]

· Basar [bzr]

· Notwendigerweise [p4]

Akzeptierte Zielformate [Kennungen]:

· Quecksilber [hg]

· Subversion [svn] (Verlauf auf Zweigen wird nicht beibehalten)

Wird keine Revision angegeben, werden alle Revisionen konvertiert. Andernfalls wird nur konvertiert
bis zur benannten Revision importieren (in einem Format angegeben, das von der Quelle verstanden wird).

Wenn kein Zielverzeichnisname angegeben ist, wird standardmäßig der Basisname der Quelle verwendet
mit -hg angehängt. Wenn das Ziel-Repository nicht vorhanden ist, wird es erstellt.

Standardmäßig verwenden alle Quellen außer Mercurial --branchsort. Quecksilber verwendet
--sourcesort um die ursprüngliche Reihenfolge der Revisionsnummern beizubehalten. Sortiermodi haben Folgendes
Effekte:

--branchsort
Konvertieren Sie, wenn möglich, von der übergeordneten in die untergeordnete Revision, was bedeutet, dass Zweige vorhanden sind
in der Regel nacheinander umgewandelt. Es erzeugt kompaktere Repositories.

--datesort
Revisionen nach Datum sortieren. Konvertierte Repositories haben gut aussehende Änderungsprotokolle, sind es aber
oft um eine Größenordnung größer als die von --branchsort erzeugten.

--sourcesort
Versuchen Sie, die Reihenfolge der Quellrevisionen beizubehalten, die nur von Mercurial-Quellen unterstützt wird.

--closesort
Versuchen Sie, geschlossene Revisionen nur so nah wie möglich an übergeordnete Zweige zu verschieben
von Mercurial-Quellen unterstützt.

If REVMAP nicht angegeben ist, wird es an einem Standardspeicherort abgelegt (/.hg/shamap by
Ursprünglich). Der REVMAP ist eine einfache Textdatei, die jede Quell-Commit-ID dem zuordnet
Ziel-ID für diese Revision, etwa so:



Wenn die Datei nicht existiert, wird sie automatisch erstellt. Es wird bei jedem kopierten Commit aktualisiert,
so hg verkaufen kann unterbrochen und wiederholt ausgeführt werden, um neue Commits zu kopieren.

Die Authormap ist eine einfache Textdatei, die jeden Quell-Commit-Autor einem Ziel zuordnet
Autor verpflichten. Es ist praktisch für Quell-SCMs, die Unix-Logins verwenden, um Autoren zu identifizieren (z. B.:
CVS). Eine Zeile pro Autorenzuordnung und das Zeilenformat ist:

Quellautor = Zielautor

Leerzeilen und Zeilen, die mit a beginnen # werden ignoriert.

Die Dateizuordnung ist eine Datei, die das Filtern und Neuzuordnen von Dateien und Verzeichnissen ermöglicht. Jeder
Zeile kann eine der folgenden Anweisungen enthalten:

schließen Sie Pfad/zu/Datei-oder-Verzeichnis ein

Pfad/zu/Datei-oder-Verzeichnis ausschließen

Pfad/nach/Quelle umbenennen Pfad/nach/Ziel

Kommentarzeilen beginnen mit #. Ein angegebener Pfad stimmt überein, wenn er dem vollständigen relativen Namen entspricht
einer Datei oder eines ihrer übergeordneten Verzeichnisse. Das das or ausschließen Richtlinie mit der
es gilt der längste übereinstimmende Pfad, sodass die Zeilenreihenfolge keine Rolle spielt.

Das das Direktive bewirkt, dass eine Datei oder alle Dateien in einem Verzeichnis in die aufgenommen werden
Ziel-Repository. Der Standardwert, wenn es keine gibt das Aussagen sind aufzunehmen
alles. Wenn es welche gibt das Aussagen, nichts anderes ist enthalten. Das ausschließen
Direktive bewirkt, dass Dateien oder Verzeichnisse weggelassen werden. Das umbenennen Direktive benennt eine Datei um
oder Verzeichnis, wenn es konvertiert wird. Um von einem Unterverzeichnis in das Stammverzeichnis umzubenennen
Aufbewahrungsort, verwenden . als Pfad zum Umbenennen.

--voll stellt sicher, dass die konvertierten Änderungssätze genau die richtigen Dateien mit der enthalten
richtigen Inhalt. Es wird eine vollständige Konvertierung aller Dateien durchführen, nicht nur derjenigen, die bereits vorhanden sind
geändert. Dateien, die bereits korrekt sind, werden nicht geändert. Damit kann man sich bewerben
Dateizuordnung ändert sich beim inkrementellen Konvertieren. Dies wird derzeit nur unterstützt für
Mercurial und Subversion.

Die Splicemap ist eine Datei, die das Einfügen des synthetischen Verlaufs ermöglicht und Sie spezifizieren lässt
die Eltern einer Revision. Dies ist nützlich, wenn Sie zB einem Subversion-Merge zwei geben wollen
Eltern, oder zwei unzusammenhängende Serien der Geschichte zusammenpfropfen. Jeder Eintrag enthält einen Schlüssel,
gefolgt von einem Leerzeichen, gefolgt von einem oder zwei kommagetrennten Werten:

Schlüssel parent1, parent2

Der Schlüssel ist die Revisions-ID im Quell-Revisionskontrollsystem, dessen Eltern sein sollten
geändert (gleiches Format wie ein Schlüssel in .hg/shamap). Die Werte sind die Revisions-IDs (in beiden
das Quell- oder Zielversionskontrollsystem), die als neue Eltern verwendet werden sollen
für diesen Knoten. Wenn Sie beispielsweise „release-1.0“ mit „trunk“ zusammengeführt haben, sollten Sie dies tun
Geben Sie die Revision auf "trunk" als erstes übergeordnetes Element und die auf "release-1.0" an
Verzweigung als zweite.

Die Branchmap ist eine Datei, die es Ihnen ermöglicht, einen Branch umzubenennen, wenn er eingebracht wird
aus einem beliebigen externen Repository. Wenn es in Verbindung mit einer Splicemap verwendet wird, ermöglicht es
für eine leistungsstarke Kombination, um selbst die am schlimmsten schlecht verwalteten Repositories zu reparieren und
wandeln Sie sie in gut strukturierte Mercurial-Repositories um. Die Branchmap enthält Zeilen von
die Form:

ursprünglicher_Zweigname neuer_Zweigname

wobei "original_branch_name" der Name der Verzweigung im Quell-Repository ist und
"new_branch_name" ist der Name des Zweigs im Ziel-Repository. Kein Leerzeichen
ist in den Zweignamen erlaubt. Dies kann verwendet werden, um (zum Beispiel) Code in einem zu verschieben
Repository von "default" zu einem benannten Zweig.

Quecksilber- Quelle
Die Mercurial-Quelle erkennt die folgenden Konfigurationsoptionen, die Sie einstellen können
die Kommandozeile mit --config:

konvertieren.hg.ignoreerrors
Integritätsfehler beim Lesen ignorieren. Verwenden Sie es, um Mercurial-Repositories zu reparieren
fehlende Revlogs, durch Umstellung von und auf Mercurial. Der Standardwert ist „Falsch“.

konvertieren.hg.saverev
Speichern Sie die ursprüngliche Revisions-ID im Änderungssatz (erzwingt die Änderung der Ziel-IDs). Es dauert ein
boolesches Argument und ist standardmäßig False.

konvertieren.hg.startrev
Geben Sie die ursprüngliche Mercurial-Revision an. Der Standardwert ist 0.

konvertieren.hg.revs
revset, das die zu konvertierenden Quellrevisionen angibt.

CVS Quelle
Die CVS-Quelle verwendet eine Sandbox (dh eine ausgecheckte Kopie) von CVS, um den Start anzuzeigen
Punkt dessen, was konvertiert wird. Ein direkter Zugriff auf die Repository-Dateien ist nicht erforderlich,
es sei denn natürlich das Repository ist :lokal:. Die Konvertierung verwendet das oberste Verzeichnis in
die Sandbox, um das CVS-Repository zu finden, und verwendet dann CVS-rlog-Befehle, um Dateien zu finden
Konvertieren. Das bedeutet, dass, sofern keine Dateizuordnung angegeben ist, alle Dateien unter dem Startverzeichnis liegen
konvertiert werden und dass jede Verzeichnisreorganisation in der CVS-Sandbox ignoriert wird.

Die folgenden Optionen können mit verwendet werden --config:

konvertieren.cvsps.cache
Auf False setzen, um das Remote-Protokoll-Caching zu Test- und Debugging-Zwecken zu deaktivieren.
Standard ist True.

konvertieren.cvsps.fuzz
Geben Sie die maximale Zeit (in Sekunden) an, die zwischen Festschreibungen mit zulässig ist
identische Benutzer- und Protokollnachricht in einem einzigen Änderungssatz. Wenn sehr große Dateien waren
als Teil eines Changesets eingecheckt, dann ist die Standardeinstellung möglicherweise nicht lang genug. Das
Standard ist 60.

konvertieren.cvsps.mergeto
Geben Sie einen regulären Ausdruck an, mit dem Commit-Protokollmeldungen abgeglichen werden. Wenn ein Spiel
auftritt, fügt der Konvertierungsprozess eine Dummy-Revision ein, die den Zweig zusammenführt
an dem diese Protokollnachricht auftritt, an den in der Regex angegebenen Zweig. Standard ist
{{Mergetobranch ([-\w]+)}}

konvertieren.cvsps.mergefrom
Geben Sie einen regulären Ausdruck an, mit dem Commit-Protokollmeldungen abgeglichen werden. Wenn ein Spiel
auftritt, fügt der Konvertierungsprozess die neueste Revision zum Zweig hinzu
in der Regex als zweites übergeordnetes Element des Änderungssatzes angegeben. Standard ist
{{mergefrombranch ([-\w]+)}}

konvertieren.localtimezone
Verwenden Sie die Ortszeit (wie durch die Umgebungsvariable TZ festgelegt) für den Änderungssatz
Datum/Zeiten. Der Standardwert ist False (UTC verwenden).

Hooks.cvslog
Geben Sie eine Python-Funktion an, die am Ende der Erfassung des CVS-Protokolls aufgerufen werden soll. Das
erhält eine Liste mit den Protokolleinträgen übergeben und kann die Einträge ändern
an Ort und Stelle, oder fügen Sie sie hinzu oder löschen Sie sie.

Hooks.cvchangesets
Geben Sie eine Python-Funktion an, die aufgerufen werden soll, nachdem die Änderungssätze aus berechnet wurden
CVS-Protokoll. Der Funktion wird eine Liste mit den Changeset-Einträgen übergeben und kann modifizieren
die Changesets an Ort und Stelle, oder fügen Sie sie hinzu oder löschen Sie sie.

Ein zusätzlicher Mercurial-Befehl „debugcvsps“ ermöglicht es dem eingebauten Changeset-Merging-Code
ohne Konvertierung ausgeführt werden. Seine Parameter und Ausgabe ähneln denen von cvsps
2.1. Weitere Informationen finden Sie in der Befehlshilfe.

Subversion Quelle
Die Subversion-Quelle erkennt klassische Stamm-/Zweig-/Tag-Layouts. Standardmäßig ist die mitgelieferte
svn://repo/path/ Quell-URL wird als einzelne Verzweigung konvertiert. Wenn svn://repo/path/trunk
Existiert, ersetzt es den Default-Branch. Wenn svn://repo/path/branches existiert, seine
Unterverzeichnisse werden als mögliche Zweige aufgeführt. Wenn svn://repo/path/tags existiert, es ist
nach Tags gesucht, die auf konvertierte Branches verweisen. Standard Kofferraum, Geäst und Tags Werte
kann mit folgenden Optionen überschrieben werden. Legen Sie sie auf Pfade relativ zur Quell-URL fest, oder
lassen Sie sie leer, um die automatische Erkennung zu deaktivieren.

Die folgenden Optionen können mit eingestellt werden --config:

konvertieren.svn.branches
Geben Sie das Verzeichnis an, das Branches enthält. Die Voreinstellung ist Geäst.

konvertieren.svn.tags
Geben Sie das Verzeichnis an, das Tags enthält. Die Voreinstellung ist Tags.

konvertieren.svn.trunk
Geben Sie den Namen des Trunk-Zweigs an. Die Voreinstellung ist Kofferraum.

konvertieren.localtimezone
Verwenden Sie die Ortszeit (wie durch die Umgebungsvariable TZ festgelegt) für den Änderungssatz
Datum/Zeiten. Der Standardwert ist False (UTC verwenden).

Der Quellverlauf kann ab einer bestimmten Revision abgerufen werden, anstatt zu sein
integral umgewandelt. Es werden nur einzelne Verzweigungskonvertierungen unterstützt.

konvertieren.svn.startrev
Geben Sie die Start-Subversion-Revisionsnummer an. Der Standardwert ist 0.

Git Quelle
Der Git-Importer konvertiert Commits aus allen erreichbaren Branches (Refs in Refs/Heads) und
remotes (refs in refs/remotes) an Mercurial. Verzweigungen werden mit in Lesezeichen umgewandelt
gleichen Namen, wobei die führenden 'refs/heads' entfernt wurden. Git-Submodule werden in Git konvertiert
Subrepos in Mercurial.

Die folgenden Optionen können mit eingestellt werden --config:

convert.git.ähnlichkeit
angeben, wie ähnliche Dateien, die in einem Commit geändert wurden, als Umbenennungen oder importiert werden müssen
Kopien, als Prozentsatz zwischen 0 (behindert) und 100 (Dateien müssen identisch sein). Zum
Beispiel 90 bedeutet, dass ein Löschen/Hinzufügen-Paar als Umbenennung importiert wird, wenn mehr als
90 % der Datei hat sich nicht geändert. Die Voreinstellung ist 50.

Convert.git.findcopiesharder
Sehen Sie sich beim Erkennen von Kopien alle Dateien in der Arbeitskopie an, anstatt nur
geänderte. Dies ist bei großen Projekten sehr teuer und nur dann effektiv
convert.git.ähnlichkeit größer als 0 ist. Der Standardwert ist False.

konvertieren.git.remoteprefix
Remote-Refs werden als Lesezeichen mit konvertiert konvertieren.git.remoteprefix als Präfix
gefolgt von einem /. Der Standardwert ist „entfernt“.

Convert.git.skipsubmodules
konvertiert keine .gitmodules-Dateien auf Root-Ebene oder Dateien mit 160000-Modusanzeige
ein Submodul. Der Standardwert ist „Falsch“.

Perforce Quelle
Dem Perforce (P4)-Importer kann ein p4-Depot-Pfad oder eine Client-Spezifikation als angegeben werden
Quelle. Es konvertiert alle Dateien in der Quelle in ein flaches Mercurial-Repository und ignoriert
Labels, Verzweigungen und Integrationen. Beachten Sie, dass Ihnen dann normalerweise ein Depotpfad angegeben wird
sollte ein Zielverzeichnis angeben, da sonst das Ziel benannt werden kann ...-hg.

Die folgenden Optionen können mit eingestellt werden --config:

konvertieren.p4.encoding
Geben Sie die Codierung an, die beim Decodieren der Standardausgabe des Perforce-Befehls verwendet werden soll
Linienwerkzeug. Der Standardwert ist die Standardsystemcodierung.

konvertieren.p4.startrev
Geben Sie die anfängliche Perforce-Revision an (eine Perforce-Änderungslistennummer).

Quecksilber- Reiseziel
Das Mercurial-Ziel erkennt Mercurial-Subrepositories im Ziel
Verzeichnis und aktualisieren Sie die .hgsubstate-Datei automatisch, wenn das Ziel
Subrepositories enthalten die / /.hg/shamap-Datei. Konvertieren eines Repositorys mit
Subrepositories erfordert die Konvertierung eines einzelnen Repositorys nach dem anderen, von unten nach oben.

Ein Beispiel, das zeigt, wie ein Repository mit Unterrepositorys konvertiert wird:

# so convert kennt den Typ, wenn es ein nicht leeres Ziel sieht
$ hg init umgewandelt

$ hg konvertieren orig/sub1 konvertiert/sub1
$ hg konvertieren orig/sub2 konvertiert/sub2
$ hg konvertieren orig konvertiert

Die folgenden Optionen werden unterstützt:

konvertieren.hg.clonebranches
Quellzweige in separaten Klonen versenden. Der Standardwert ist False.

konvertieren.hg.tagsbranch
Verzweigungsname für Tag-Revisionen, standardmäßig auf Standard.

Convert.hg.usebranchnames
Filialnamen beibehalten. Der Standardwert ist True.

convert.hg.Quellenname
Zeichnet die angegebene Zeichenfolge als 'convert_source'-Zusatzwert bei jedem durchgeführten Commit auf
das Ziel-Repository. Der Standardwert ist Keine.

Alle Reiseziele
Alle Zieltypen akzeptieren die folgenden Optionen:

konvertieren.skiptags
konvertiert keine Tags aus dem Quellrepo in das Zielrepo. Die Voreinstellung ist
Falsch.

Zubehör:

--Autoren
Dateiname der Benutzernamenzuordnung (VERALTET) (verwenden Sie stattdessen --authormap)

-S,--Quelle Typ
Quell-Repository-Typ

-D,--dest-type
Ziel-Repository-Typ

-R,--rev
Import bis Quellrevision REV

-EIN,--Autorenkarte
Benutzernamen mit dieser Datei neu zuordnen

--filemap
Dateinamen mit Inhalt der Datei neu zuordnen

--voll Wenden Sie Filemap-Änderungen an, indem Sie alle Dateien erneut konvertieren

--splicemap
Spleiß synthetisierte Geschichte an Ort und Stelle

--branchmap
Zweignamen beim Konvertieren ändern

--branchsort
Versuchen Sie, Changesets nach Branches zu sortieren

--datesort
Versuchen Sie, Changesets nach Datum zu sortieren

--sourcesort
Reihenfolge der Quell-Änderungssätze beibehalten

--closesort
Versuchen Sie, geschlossene Revisionen neu zu ordnen

[+] markierte Option kann mehrfach angegeben werden

eol
automatisch Zeilenumbrüche in Repository-Dateien verwalten

Mit dieser Erweiterung können Sie die Art der verwendeten Zeilenenden (CRLF oder LF) verwalten
im Repository und im lokalen Arbeitsverzeichnis. Auf diese Weise können Sie CRLF-Zeilenenden erhalten
unter Windows und LF unter Unix/Mac, wodurch jeder seine nativen Zeilenenden des Betriebssystems verwenden kann.

Die Erweiterung liest ihre Konfiguration aus einer versionierten .hgeol Konfigurationsdatei gefunden in
das Stammverzeichnis des Arbeitsverzeichnisses. Der .hgeol Datei verwenden die gleiche Syntax wie alle anderen
Mercurial-Konfigurationsdateien. Es verwendet zwei Abschnitte, [Muster] und [Repository].

Das [Muster] Abschnitt gibt an, wie Zeilenenden zwischen den Arbeitsschritten konvertiert werden sollen
Verzeichnis und das Repository. Das Format wird durch ein Dateimuster angegeben. Das erste Spiel
verwendet wird, setzen Sie also zuerst spezifischere Muster. Die verfügbaren Zeilenenden sind LF, CRLF und
BIN.

Dateien mit dem deklarierten Format von CRLF or LF werden immer ausgecheckt und im gespeichert
Repository in diesem Format und als binär deklarierte Dateien (BIN) bleiben unverändert.
Zusätzlich nativen ist ein Alias ​​zum Auschecken im Standard-Zeilenende der Plattform:
LF unter Unix (einschließlich Mac OS X) und CRLF unter Windows. Beachten Sie, dass BIN (Nichts tun, um zu linieren
Endungen) ist das Standardverhalten von Mercurial; Es wird nur benötigt, wenn Sie a überschreiben müssen
später allgemeineres Muster.

Das optionale [Repository] Abschnitt gibt die Zeilenenden an, die für gespeicherte Dateien verwendet werden sollen
das Depot. Es hat eine einzige Einstellung, nativen, die die Speicherzeilenenden bestimmt
für Dateien, die als deklariert sind nativen der [Muster] Sektion. Es kann eingestellt werden LF or CRLFdem „Vermischten Geschmack“. Seine
Standard ist LF. Dies bedeutet beispielsweise, dass unter Windows Dateien konfiguriert sind als nativen (CRLF
standardmäßig) konvertiert werden LF wenn im Repository gespeichert. Dateien deklariert als LF,
CRLF, oder BIN der [Muster] -Abschnitt werden immer so wie sie sind im Repository gespeichert.

Beispiel versioniert .hgeol Datei:

[Muster]
**.py = nativ
**.vcproj = CRLF
**.txt = nativ
Makefile = LF
**.jpg = BEHÄLTER

[Repository]
nativ = LF

Hinweis Die Regeln gelten erst, wenn Dateien im Arbeitsverzeichnis berührt werden, zB von
Aktualisieren auf Null und zurück zum Tipp, um alle Dateien zu berühren.

Die Erweiterung verwendet eine optionale [eol] Abschnitt gelesen sowohl von der normalen Mercurial
Konfigurationsdateien und die .hgeol Datei, wobei letzteres ersteres überschreibt. Du kannst
Verwenden Sie diesen Abschnitt, um das Gesamtverhalten zu steuern. Es gibt drei Einstellungen:

· eol.native (Standard os.linesep) eingestellt werden LF or CRLF um die Standardeinstellung zu überschreiben
Interpretation von nativen zur Kasse. Dies kann mit verwendet werden hg Archiv auf Unix, sagen wir, zu
Generieren Sie ein Archiv, in dem Dateien Zeilenenden für Windows haben.

· eol.only-consistent (standardmäßig True) kann auf False gesetzt werden, damit die Erweiterung konvertiert wird
Dateien mit inkonsistenten EOLs. Inkonsistent bedeutet, dass es beides gibt CRLF und LF Gegenwart
in der Datei. Solche Dateien werden normalerweise unter der Annahme, dass sie vorhanden sind, nicht angerührt
gemischte EOLs absichtlich.

· eol.fix-trailing-newline (Standardwert False) kann auf True gesetzt werden, um sicherzustellen, dass konvertiert wird
Dateien enden mit einem EOL-Zeichen (entweder \n or \ R \ n gemäß den konfigurierten Mustern).

Die Erweiterung bietet clevercode: und cleverdecode: Filter wie die veralteten
win32text-Erweiterung tut. Das bedeutet, dass Sie win32text deaktivieren und eol and aktivieren können
Ihre Filter funktionieren weiterhin. Sie brauchen diese Filter nur, bis Sie einen vorbereitet haben
.hgeol Datei.

Das win32text.forbid* Hooks, die von der win32text-Erweiterung bereitgestellt werden, wurden in a vereinheitlicht
Einzelhaken benannt eol.checkheadshook. Der Hook sucht nach den erwarteten Zeilenenden
.hgeol Datei, was bedeutet, dass Sie zu einer migrieren müssen .hgeol Datei zuerst, bevor Sie die
Haken. eol.checkheadshook prüft nur Köpfe, zwischenzeitliche ungültige Revisionen werden verschoben.
Um sie vollständig zu verbieten, verwenden Sie die eol.checkallhook Haken. Diese Haken werden am besten als verwendet
pretxnchangegroup Haken.

See hg Hilfe Muster für weitere Informationen über die verwendeten Glob-Muster.

extdiff
Befehl, um externen Programmen zu ermöglichen, Revisionen zu vergleichen

Mit der Mercurial-Erweiterung extdiff können Sie externe Programme verwenden, um Revisionen zu vergleichen.
oder Revision mit Arbeitsverzeichnis. Die externen diff-Programme werden mit a aufgerufen
konfigurierbarer Satz von Optionen und zwei Nicht-Optionsargumente: Pfade zu Verzeichnissen, die enthalten
Schnappschüsse von zu vergleichenden Dateien.

Die extdiff-Erweiterung ermöglicht es Ihnen auch, neue Diff-Befehle zu konfigurieren, die Sie also nicht benötigen
tippen hg extdiff -p kdiff3 immer.

[extdiff]
# neuen Befehl hinzufügen, der GNU ausführt diff(1) im 'Kontext-Diff'-Modus
cdiff = gdiff -Nprc5
## oder auf die alte Art:
#cmd.cdiff = gdiff
#opts.cdiff = -Nprc5

# neuen Befehl namens meld hinzufügen, führt meld aus (keine doppelte Benennung nötig). Wenn
# die ausführbare meld-Datei ist nicht verfügbar, das meld-Tool in [merge-tools]
# wird verwendet, falls verfügbar
melden =

# neuen Befehl namens vimdiff hinzufügen, führt gvimdiff mit dem DirDiff-Plugin aus
# (sehen http://www.vim.org/scripts/script.php?script_id=102) Nein
# Englischer Benutzer, stellen Sie sicher, dass Sie "let g:DirDiffDynamicDiffText = 1" eingeben
# Ihre .vimrc
vimdiff = gvim -f "+weiter" \
"+Führe 'DirDiff' fnameescape(argv(0)) fnameescape(argv(1))"

Werkzeugargumente können Variablen enthalten, die zur Laufzeit erweitert werden:

$parent1, $label1 - Dateiname, beschreibendes Etikett des ersten Elternteils
$child, $clabel - Dateiname, beschreibendes Etikett der untergeordneten Revision
$parent2, $plabel2 - Dateiname, beschreibendes Etikett des zweiten Elternteils
$root - Repository-Stamm
$parent ist ein Alias ​​für $parent1.

Die Erweiterung extdiff sucht in den Abschnitten [diff-tools] und [merge-tools] nach diff
Werkzeugargumente, wenn keine in [extdiff] angegeben sind.

[extdiff]
kdiff3 =

[Diff-Tools]
kdiff3.diffargs=--L1 '$plabel1' --L2 '$clabel' $parent $child

Sie können -I/-X und eine Liste von Datei- oder Verzeichnisnamen wie gewohnt verwenden hg diff Befehl. Das
extdiff-Erweiterung erstellt Schnappschüsse von nur benötigten Dateien, sodass das externe Diff ausgeführt wird
Das Programm wird tatsächlich ziemlich schnell sein (zumindest schneller, als die gesamte Datei vergleichen zu müssen
Baum).

Befehle
extdiff
Verwenden Sie ein externes Programm, um das Repository (oder ausgewählte Dateien) zu unterscheiden:

hg extdiff [OPT]... [DATEI]...

Unterschiede zwischen Revisionen für die angegebenen Dateien mithilfe eines externen Programms anzeigen. Das
Das verwendete Standardprogramm ist diff mit den Standardoptionen "-Npru".

Um ein anderes Programm auszuwählen, verwenden Sie die Option -p/--program. Das Programm wird übergeben
Namen von zwei zu vergleichenden Verzeichnissen. Um dem Programm zusätzliche Optionen zu übergeben, verwenden Sie
-o/--Option. Diese werden vor den Namen der zu vergleichenden Verzeichnisse übergeben.

Wenn zwei Revisionsargumente angegeben werden, werden Änderungen zwischen diesen Revisionen angezeigt. Wenn
nur eine Revision angegeben ist, dann wird diese Revision mit dem Arbeitsverzeichnis verglichen,
und wenn keine Revisionen angegeben sind, werden die Arbeitsverzeichnisdateien mit ihren
Elternteil.

Zubehör:

-P,--Programm
Vergleichsprogramm auszuführen

-Ö,--Möglichkeit
Option an Vergleichsprogramm übergeben

-R,--rev
Revision

-C,--Veränderung
Änderung durch Überarbeitung

- Patch
Patches für zwei Revisionen vergleichen

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

Faktotum
http-Authentifizierung mit factotum

Diese Erweiterung ermöglicht die Faktotum(4) Anlage auf Plan 9 von Bell Labs-Plattformen zu
Authentifizierungsinformationen für den HTTP-Zugriff bereitstellen. Konfigurationseinträge, die in der angegeben sind
auth-Abschnitt sowie Authentifizierungsinformationen, die in der Repository-URL bereitgestellt werden
voll unterstützt. Wenn kein Präfix angegeben ist, wird ein Wert von "*" angenommen.

Standardmäßig werden Schlüssel wie folgt angegeben:

proto=pass service=hg prefix= Benutzer= !Passwort=

Wenn die factotum-Erweiterung den erforderlichen Schlüssel nicht lesen kann, wird einer angefordert
interaktiv.

Ein Konfigurationsabschnitt ist verfügbar, um das Laufzeitverhalten anzupassen. Standardmäßig diese
Einträge sind:

[Faktotum]
ausführbar = /bin/auth/factotum
Einhängepunkt = /mnt/factotum
Dienst = hg

Der ausführbare Eintrag definiert den vollständigen Pfad zur factotum-Binärdatei. Der Mountpoint-Eintrag
definiert den Pfad zum factotum-Dateidienst. Schließlich steuert der Diensteintrag die
Dienstname, der beim Lesen von Schlüsseln verwendet wird.

holen
Ziehen, Aktualisieren und Zusammenführen in einem Befehl (VERALTET)

Befehle
holen
Ziehen Sie Änderungen aus einem Remote-Repository, führen Sie neue Änderungen zusammen, falls erforderlich.:

hg holen [QUELLE]

Dadurch werden alle Änderungen aus dem Repository unter dem angegebenen Pfad oder der angegebenen URL gefunden und hinzugefügt
das lokale Repository.

Wenn die gezogenen Änderungen einen neuen Zweigkopf hinzufügen, wird der Kopf automatisch zusammengeführt und die
Ergebnis der Zusammenführung wird festgeschrieben. Andernfalls wird das Arbeitsverzeichnis aktualisiert, um es einzuschließen
die neuen Änderungen.

Wenn eine Zusammenführung erforderlich ist, wird das Arbeitsverzeichnis zuerst auf das neu gezogene aktualisiert
Änderungen. Lokale Änderungen werden dann mit den abgerufenen Änderungen zusammengeführt. Um die Zusammenführungsreihenfolge zu ändern,
Verwenden Sie --switch-parent.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Gibt bei Erfolg 0 zurück.

Zubehör:

-R,--rev
eine bestimmte Revision, die Sie abrufen möchten

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

--force-editor
Commit-Nachricht bearbeiten (VERALTET)

--switch-parent
Eltern wechseln beim Zusammenführen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

gpg
Befehle zum Signieren und Überprüfen von Änderungssätzen

Befehle
Sigcheck
Überprüfen Sie alle Signaturen, die für eine bestimmte Revision vorhanden sein können:

hg sigcheck REV

Überprüfen Sie alle Signaturen, die für eine bestimmte Revision vorhanden sein können

Schild
Fügen Sie eine Signatur für die aktuelle oder angegebene Revision hinzu:

hg-Zeichen [OPTION]... [REV]...

Wenn keine Revision angegeben ist, wird das übergeordnete Verzeichnis des Arbeitsverzeichnisses verwendet, oder Tipp, wenn nein
Revision ist ausgecheckt.

Das gpg.cmd config-Einstellung kann verwendet werden, um den auszuführenden Befehl anzugeben. Ein Standardschlüssel kann sein
angegeben mit gpg.key.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Zubehör:

- l, --lokal
Machen Sie die Signatur lokal

-F, --Macht
signieren, auch wenn die Signaturdatei geändert wird

--keine Verpflichtung
Übertragen Sie die Signaturdatei nach dem Signieren nicht

-k,--Schlüssel
die Schlüssel-ID, mit der signiert werden soll

-M,--Botschaft
Text als Commit-Nachricht verwenden

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

sigs
signierte Änderungssätze auflisten:

hg zeichen

signierte Änderungssätze auflisten

graphlog
Befehl zum Anzeigen von Revisionsdiagrammen aus einer Shell (VERALTET)

Die Funktionalität dieser Erweiterung ist seit Version 2.3 im Mercurial-Kern enthalten.
Benutzen Sie bitte hg Log -G ... stattdessen.

Diese Erweiterung fügt den eingehenden, ausgehenden und Protokollbefehlen eine Option --graph hinzu. Wenn das
Wenn Optionen angegeben sind, wird auch eine ASCII-Darstellung des Revisionsdiagramms angezeigt.

Befehle
Glog
Überarbeitungsverlauf neben einem ASCII-Überarbeitungsdiagramm anzeigen:

hg glog [OPTION]... [DATEI]

Drucken Sie einen Revisionsverlauf neben einem mit ASCII-Zeichen gezeichneten Revisionsdiagramm.

Knoten, die als @-Zeichen gedruckt werden, sind Eltern des Arbeitsverzeichnisses.

Dies ist ein Alias ​​für hg Log -G.

Zubehör:

-F, --Folgen
Verfolgen Sie den Änderungsverlauf oder den Dateiverlauf über Kopien und Umbenennungen hinweg

--folgen-zuerst
Folgen Sie nur dem ersten übergeordneten Element von Merge-Changesets (DEPRECATED)

-D,--Datum
Überarbeitungen anzeigen, die der Datumsspezifikation entsprechen

-VS, --Kopien
kopierte Dateien anzeigen

-k,--Stichwort
Suche nach einem bestimmten Text ohne Berücksichtigung der Groß-/Kleinschreibung

-R,--rev
zeige die angegebene Revision oder Revset

--ENTFERNT
Überarbeitungen einschließen, bei denen Dateien entfernt wurden

-M, --only-merges
Nur Zusammenführungen anzeigen (DEPRECATED)

-du,--Benutzer
Überarbeitungen, die vom Benutzer festgelegt wurden

--only-Zweig
nur Changesets innerhalb des angegebenen benannten Zweigs anzeigen (DEPRECATED)

-B,--Zweig
Änderungsmengen innerhalb des angegebenen benannten Zweigs anzeigen

-P,--Pflaume
keine Revision oder einen ihrer Vorfahren anzeigen

-P, - Patch
Patch anzeigen

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

- l,--Grenze
Anzahl der angezeigten Änderungen begrenzen

-M, --no-merges
Zusammenführungen nicht anzeigen

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

-G, --Graph
zeige die Revision DAG

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

hgcia
Hooks für die Integration mit dem CIA.vc-Benachrichtigungsdienst

Dies soll als Changegroup oder eingehender Hook ausgeführt werden. Um es zu konfigurieren, setzen Sie die
folgende Optionen in Ihrem hgrc:

[cia]
# Ihr registrierter CIA-Benutzername
Benutzer = foo
# der Name des Projekts in CIA
Projekt = foo
# das Modul (Teilprojekt) (optional)
#modul = foo
# Diffstat an die Protokollnachricht anhängen (optional)
#diffstat = Falsch
# Vorlage für Protokollnachrichten (optional)
#template = {desc}\n{baseurl}{webroot}/rev/{node}-- {diffstat}
# Zu verwendender Stil (optional)
#style = foo
# Die URL des CIA-Benachrichtigungsdienstes (optional)
# Sie können mailto: URLs zum Versenden per E-Mail verwenden, z
# mailto:[E-Mail geschützt]
# Stellen Sie sicher, dass Sie email.from festlegen, wenn Sie dies tun.
#url = http://cia.vc/
# Nachricht drucken statt senden (optional)
#test = Falsch
# Anzahl der Schrägstriche, die für URL-Pfade entfernt werden sollen
#strip = 0

[Haken]
# einer von diesen:
changegroup.cia = python:hgcia.hook
#eingehend.cia = python:hgcia.hook

[Netz]
# Wenn Sie Hyperlinks wünschen (optional)
Basis-URL = http://server/path/to/repo

hgk
durchsuchen Sie das Repository grafisch

Die hgk-Erweiterung ermöglicht das grafische Durchsuchen des Verlaufs eines Repositorys. Es
erfordert Tcl/Tk-Version 8.4 oder höher. (Tcl/Tk wird nicht mit Mercurial vertrieben.)

hgk besteht aus zwei Teilen: einem Tcl-Skript, das die Anzeige und Abfrage von
Informationen und eine Erweiterung für Mercurial namens hgk.py, die Hooks für hgk bereitstellt
Informationen bekommen. hgk ist im contrib-Verzeichnis zu finden, und die Erweiterung wird mitgeliefert
im hgext-Repository und muss aktiviert werden.

Das hg view Der Befehl startet das hgk Tcl-Skript. Damit dieser Befehl funktioniert, muss hgk sein
in Ihrem Suchpfad. Alternativ können Sie den Pfad zu hgk in Ihrer Konfiguration angeben
Datei:

[hgk]
Pfad = /Standort/von/hgk

hgk kann die Erweiterung extdiff verwenden, um Revisionen zu visualisieren. Angenommen, Sie hatten
bereits konfigurierter extdiff vdiff-Befehl, fügen Sie einfach hinzu:

[hgk]
vdiff=vdiff

Das Revisions-Kontextmenü zeigt jetzt zusätzliche Einträge zum Auslösen von vdiff beim Bewegen des Mauszeigers und an
ausgewählte Revisionen.

Befehle
view
interaktiven Verlaufsbetrachter starten:

hg Ansicht [-l LIMIT] [REVRANGE]

Starten Sie den interaktiven Verlaufsbetrachter

Zubehör:

- l,--Grenze
Anzahl der angezeigten Änderungen begrenzen

hervorheben
Syntaxhervorhebung für hgweb (benötigt Pygments)

Es hängt von der Syntaxhervorhebungsbibliothek von Pygments ab: http://pygments.org/

Es gibt folgende Konfigurationsmöglichkeiten:

[Netz]
pygments_style = (default: colorful)
Highlightfiles = (Standard: Größe('<5M'))
HighlightOnlyMatchDateiname = (standardmäßig falsch)

Nur übereinstimmenden Dateinamen hervorheben hebt nur Dateien hervor, deren Typ identifiziert werden konnte
ihren Dateinamen. Wenn dies nicht aktiviert ist (Standardeinstellung), wird sich Pygments sehr bemühen
Identifizieren Sie den Dateityp anhand des Inhalts und aller Übereinstimmungen (sogar Übereinstimmungen mit geringem Vertrauen
Punktzahl) verwendet werden.

histedit
interaktive Verlaufsbearbeitung

Wenn diese Erweiterung installiert ist, erhält Mercurial einen neuen Befehl: histedit. Die Verwendung ist als
folgt unter der Annahme der folgenden Historie:

@ 3[Tipp] 7c2fd3b9020c 2009-04-27 18:04 -0500 durin42
| Delta hinzufügen
|
o 2 030b686bedc4 2009 04:27 -18 durin04
| Gamma hinzufügen
|
o 1 c561b4e977df 2009 04:27 -18 durin04
| Beta hinzufügen
|
o 0 d8d2fcd0e319 2009 04:27 -18 durin04
Alpha hinzufügen

Wenn du laufen würdest hg histedit c561b4e977df, würden Sie die folgende Datei in Ihrem geöffnet sehen
Editor:

Wählen Sie c561b4e977df Beta hinzufügen
wähle 030b686bedc4 Gamma hinzufügen
wähle 7c2fd3b9020c Delta hinzufügen

# Bearbeiten Sie den Verlauf zwischen c561b4e977df und 7c2fd3b9020c
#
# Commits werden vom kleinsten bis zum neuesten aufgelistet
#
# Befehle:
# p, pick = Commit verwenden
# e, edit = Commit verwenden, aber zum Ändern aufhören
# f, fold = Commit verwenden, aber mit dem obigen kombinieren
# r, roll = wie fold, aber die Beschreibung dieses Commits verwerfen
# d, drop = Commit aus Verlauf entfernen
# m, mess = Commit-Nachricht bearbeiten, ohne den Commit-Inhalt zu ändern
#

In dieser Datei beginnen die Zeilen mit # werden ignoriert. Sie müssen jeweils eine Regel angeben
Revision in Ihrer Geschichte. Zum Beispiel, wenn Sie Gamma vor Beta hinzufügen wollten, und dann
Wenn Sie Delta in derselben Revision wie Beta hinzufügen möchten, müssen Sie die Datei neu organisieren, um sie anzuzeigen
so was:

wähle 030b686bedc4 Gamma hinzufügen
Wählen Sie c561b4e977df Beta hinzufügen
Falte 7c2fd3b9020c Füge Delta hinzu

# Bearbeiten Sie den Verlauf zwischen c561b4e977df und 7c2fd3b9020c
#
# Commits werden vom kleinsten bis zum neuesten aufgelistet
#
# Befehle:
# p, pick = Commit verwenden
# e, edit = Commit verwenden, aber zum Ändern aufhören
# f, fold = Commit verwenden, aber mit dem obigen kombinieren
# r, roll = wie fold, aber die Beschreibung dieses Commits verwerfen
# d, drop = Commit aus Verlauf entfernen
# m, mess = Commit-Nachricht bearbeiten, ohne den Commit-Inhalt zu ändern
#

An dieser Stelle schließen Sie den Editor und histedit beginnt zu arbeiten. Wenn Sie a angeben falten
Betrieb histedit öffnet einen Editor, wenn er diese Revisionen zusammenfaltet und bietet
Sie haben die Möglichkeit, die Commit-Nachricht zu bereinigen:

Beta hinzufügen
***
Delta hinzufügen

Bearbeiten Sie die Commit-Nachricht nach Ihren Wünschen und schließen Sie dann den Editor. Lassen Sie uns für dieses Beispiel
davon aus, dass die Commit-Nachricht in geändert wurde Speichern Beta und Delta. Nachdem histedit ausgeführt wurde
und hatte die Möglichkeit, alle alten oder temporären Überarbeitungen zu entfernen, die es benötigte, sieht der Verlauf aus
so was:

@ 2[Tipp] 989b4d060121 2009-04-27 18:04 -0500 durin42
| Fügen Sie Beta und Delta hinzu.
|
o 1 081603921c3f 2009 04:27 -18 durin04
| Gamma hinzufügen
|
o 0 d8d2fcd0e319 2009 04:27 -18 durin04
Alpha hinzufügen

Beachten Sie, dass histedit die nicht Entfernen Sie alle Revisionen (auch seine eigenen temporären) bis danach
es hat alle Bearbeitungsvorgänge abgeschlossen, also wird es wahrscheinlich mehrere Streifen ausführen
Operationen, wenn es fertig ist. Für das obige Beispiel musste der Streifen zweimal laufen. Streifen kann sein
langsam, abhängig von einer Vielzahl von Faktoren, daher müssen Sie möglicherweise ein wenig geduldig sein. Du kannst
entscheiden Sie sich dafür, die ursprünglichen Überarbeitungen beizubehalten, indem Sie die --halten Flagge.

Das bearbeiten Operation bringt Sie zurück zu einer Eingabeaufforderung, wo Sie Dateien bearbeiten können
frei, oder sogar verwenden hg Rekord einige Änderungen als separates Commit festzuschreiben. Wenn du bist
abgeschlossen sind, werden alle verbleibenden, nicht festgeschriebenen Änderungen ebenfalls festgeschrieben. Wenn Sie fertig sind, laufen Sie hg
histedit --fortsetzen um diesen Schritt abzuschließen. Sie werden aufgefordert, eine neue Commit-Nachricht einzugeben, aber
Die Standard-Commit-Nachricht ist die ursprüngliche Nachricht für die bearbeiten ed Überarbeitung.

Das Nachricht Die Operation gibt Ihnen die Möglichkeit, eine Commit-Nachricht zu überarbeiten, ohne sie zu ändern
die Inhalte. Es ist eine Abkürzung für das Tun bearbeiten unmittelbar gefolgt von hg histedit
--weiter.

If histedit beim Verschieben einer Revision auf einen Konflikt stößt (beim Handling wählen or falten),
es wird in ähnlicher Weise zu stoppen bearbeiten mit dem Unterschied, dass Sie nicht nach a gefragt werden
Commit-Nachricht, wenn fertig. Wenn Sie an dieser Stelle entscheiden, dass Sie nicht mögen, wie viel Arbeit es
wird, um den Verlauf neu zu ordnen, oder dass Sie einen Fehler gemacht haben, können Sie verwenden hg histedit --abbrechen
um die neuen Änderungen, die Sie vorgenommen haben, zu verwerfen und zu dem Zustand zurückzukehren, bevor Sie es versucht haben
Bearbeiten Sie Ihren Verlauf.

Wenn wir das histedit-ed Beispiel-Repository oben klonen und vier weitere Änderungen hinzufügen, wie z
Wir haben folgende Historie:

@ 6[tipp] 038383181893 2009-04-27 18:04 -0500 stefan
| Theta hinzufügen
|
o 5 140988835471 2009 04:27 -18 stefan
| Eta hinzufügen
|
o 4 122930637314 2009 04:27 -18 stefan
| Zeta hinzufügen
|
o 3 836302820282 2009 04:27 -18 stefan
| Epsilon hinzufügen
|
o 2 989b4d060121 2009-04-27 18:04 -0500 dauer42
| Fügen Sie Beta und Delta hinzu.
|
o 1 081603921c3f 2009 04:27 -18 durin04
| Gamma hinzufügen
|
o 0 d8d2fcd0e319 2009 04:27 -18 durin04
Alpha hinzufügen

Wenn du läufst hg histedit - ausgehend auf dem Klon läuft es dann genauso hg histedit
836302820282. Wenn Sie planen, in ein Repository zu pushen, das Mercurial nicht erkennt
mit dem Quellrepo verwandt sein, können Sie eine hinzufügen --Macht .

Config
Histedit-Regelzeilen werden standardmäßig auf 80 Zeichen gekürzt. Sie können dies anpassen
Verhalten, indem Sie in Ihrer Konfigurationsdatei eine andere Länge festlegen:

[histedit]
linelen = 120 # Regelzeilen bei 120 Zeichen abschneiden

hg histedit versucht, automatisch eine geeignete Basisrevision auszuwählen. Zu
ändern, welche Basisrevision verwendet wird, definieren Sie ein Revset in Ihrer Konfigurationsdatei:

[histedit]
defaultrev = nur(.) & Entwurf()

Standardmäßig muss jede bearbeitete Revision in histedit-Befehlen vorhanden sein. Zu entfernen
Revision, die Sie verwenden müssen fallen lassen Betrieb. Sie können den Drop so konfigurieren, dass er implizit ist
fehlende Commits durch Hinzufügen von:

[histedit]
dropmissing = True

Befehle
histedit
Changeset-Verlauf interaktiv bearbeiten:

hg histedit [OPTIONEN] ([VORFAHREN] | --outgoing [URL])

Mit diesem Befehl können Sie eine lineare Reihe von Änderungssätzen bearbeiten (bis einschließlich der Datei working
Verzeichnis, das sauber sein sollte). Du kannst:

· wählen um einen Änderungssatz [nachzubestellen].

· fallen lassen Änderungssatz wegzulassen

· Durcheinander um die Changeset-Commit-Nachricht umzuformulieren

· falten um es mit dem vorhergehenden Änderungssatz zu kombinieren

· rollen wie fold, aber die Beschreibung dieses Commits wird verworfen

· bearbeiten um diesen Änderungssatz zu bearbeiten

Es gibt mehrere Möglichkeiten, das Root-Änderungsset auszuwählen:

· Geben Sie ANCESTOR direkt an

· Verwenden Sie --outgoing -- es wird die erste lineare Änderungsmenge sein, die nicht im Ziel enthalten ist.
(Siehe hg Hilfe config.default-push)

· Andernfalls wird der Wert aus der Konfigurationsoption „histedit.defaultrev“ als revset to verwendet
Wählen Sie die Basisrevision aus, wenn ANCESTOR nicht angegeben ist. Die erste Revision zurückgegeben von
Die Drehzahl wird verwendet. Standardmäßig wird hiermit der bearbeitbare Verlauf ausgewählt, der für die eindeutig ist
Herkunft des Arbeitsverzeichnisses.

Wenn Sie --outgoing verwenden, wird dieser Befehl abgebrochen, wenn mehrdeutige ausgehende Revisionen vorhanden sind.
Zum Beispiel, wenn es mehrere Zweige gibt, die ausgehende Revisionen enthalten.

Verwenden Sie "min(outgoing() and ::.)" oder eine ähnliche revset-Spezifikation anstelle von --outgoing to
Geben Sie in einer solchen mehrdeutigen Situation genau die Bearbeitungszielrevision an. Sehen hg Hilfe kehrt zurück für
Details zur Auswahl von Revisionen.

Beispiele:

· Eine Reihe von Änderungen wurden vorgenommen. Revision 3 wird nicht mehr benötigt.

Verlaufsbearbeitung ab Revision 3 starten:

hg histedit -r 3

Ein Editor wird geöffnet, der die Liste der Überarbeitungen enthält, in der bestimmte Aktionen angegeben sind:

pick 5339bf82f0ca 3 Zworgle die Foobar
pick 8ef592ce7cc4 4 Verblende das Zerlog
pick 0a9639fcda9d 5 Beschämen Sie die Cromulancy

Zusätzliche Informationen zu den möglichen Maßnahmen werden unterhalb der Liste angezeigt
Überarbeitungen.

Um die Revision 3 aus dem Verlauf zu entfernen, muss ihre Aktion (am Anfang der relevanten
line) wird in 'drop' geändert:

drop 5339bf82f0ca 3 Zworgle die Foobar
pick 8ef592ce7cc4 4 Verblende das Zerlog
pick 0a9639fcda9d 5 Beschämen Sie die Cromulancy

· Eine Reihe von Änderungen wurden vorgenommen. Revision 2 und 4 müssen getauscht werden.

Verlaufsbearbeitung ab Revision 2 starten:

hg histedit -r 2

Ein Editor wird geöffnet, der die Liste der Überarbeitungen enthält, in der bestimmte Aktionen angegeben sind:

pick 252a1af424ad 2 Blorb a morgwazzle
pick 5339bf82f0ca 3 Zworgle die Foobar
pick 8ef592ce7cc4 4 Verblende das Zerlog

Um Revision 2 und 4 zu vertauschen, werden deren Zeilen im Editor vertauscht:

pick 8ef592ce7cc4 4 Verblende das Zerlog
pick 5339bf82f0ca 3 Zworgle die Foobar
pick 252a1af424ad 2 Blorb a morgwazzle

Gibt 0 bei Erfolg zurück, 1 wenn ein Benutzereingriff erforderlich ist (nicht nur für absichtliches „Bearbeiten“
Befehl, sondern auch zur Lösung unerwarteter Konflikte).

Zubehör:

--Befehle
liest Verlaufsänderungen aus der angegebenen Datei

-C, --fortsetzen
Fortsetzen einer bereits laufenden Bearbeitung

--Plan bearbeiten
verbleibende Aktionsliste bearbeiten

-k, --halten
Entfernen Sie keine alten Knoten, nachdem die Bearbeitung abgeschlossen ist

--abbrechen
eine laufende Bearbeitung abbrechen

-Ö, - ausgehend
Änderungssätze im Ziel nicht gefunden

-F, --Macht
Erzwingen Sie den Ausgang auch für nicht verwandte Repositories

-R,--rev
erste zu bearbeitende Überarbeitung

[+] markierte Option kann mehrfach angegeben werden

Stichwort
Erweitern von Schlüsselwörtern in verfolgten Dateien

Diese Erweiterung erweitert RCS/CVS-ähnliche oder selbst angepasste $Keywords$ in getrackten Textdateien
ausgewählt durch Ihre Konfiguration.

Schlüsselwörter werden nur in lokalen Repositorys erweitert und nicht in der Änderungshistorie gespeichert. Das
Mechanismus kann als Bequemlichkeit für den aktuellen Benutzer oder für das Archiv angesehen werden
Verteilung.

Schlüsselwörter werden zu den Changeset-Daten erweitert, die sich auf die letzte Änderung relativ zu beziehen
übergeordnetes Arbeitsverzeichnis jeder Datei.

Die Konfiguration erfolgt in den Abschnitten [keyword], [keywordset] und [keywordmaps] von hgrc
Dateien.

Beispiel:

[Stichwort]
# Schlüsselwörter in jeder Python-Datei erweitern, außer denen, die mit "x*" übereinstimmen
**.py =
x* = ignorieren

[Schlüsselwortsatz]
# Bevorzugen Sie svn- gegenüber cvs-ähnlichen Standard-Schlüsselwortzuordnungen
svn = True

Hinweis: Je spezifischer Sie in Ihren Dateinamenmustern sind, desto weniger verlieren Sie an Geschwindigkeit
Repositories.

Für [keywordmaps]-Vorlagenzuordnung und Erweiterungsdemonstration und Kontrolllauf hg kwdemo.
See hg Hilfe Vorlagen für eine Liste der verfügbaren Vorlagen und Filter.

Drei zusätzliche Filter für Datumsvorlagen stehen zur Verfügung:

utcdate

"2006/09/18 15:13:13"

svnutcdate

"2006-09-18 15:13:13Z"

svnisodate

"2006-09-18 08:13:13 -700 (Montag, 18. September 2006)"

Die standardmäßigen Vorlagenzuordnungen (Ansicht mit hg kwdemo -d) kann durch angepasst ersetzt werden
Schlüsselwörter und Vorlagen. Wieder laufen hg kwdemo um die Ergebnisse Ihrer Konfiguration zu kontrollieren
ändert.

Vor dem Ändern/Deaktivieren aktiver Schlüsselwörter müssen Sie ausführen hg kwschrumpfen um eine Speicherung zu vermeiden
erweiterte Keywords im Änderungsverlauf.

Um die Erweiterung nach der Aktivierung oder einer Konfigurationsänderung zu erzwingen, führen Sie hg kwexpand.

Erweiterungen, die sich über mehr als eine Zeile erstrecken, und inkrementelle Erweiterungen, wie $Log$ von CVS, sind
nicht unterstützt. Eine Keyword-Vorlagenzuordnung "Log = {desc}" wird in die erste Zeile des erweitert
Changeset-Beschreibung.

Befehle
kwdemo
print [keywordmaps] Konfiguration und ein Erweiterungsbeispiel:

hg kwdemo [-d] [-f RCFILE] [TEMPLATEMAP]...

Zeigen Sie aktuelle, benutzerdefinierte oder standardmäßige Keyword-Vorlagenzuordnungen und ihre Erweiterungen an.

Erweitern Sie die aktuelle Konfiguration, indem Sie Maps als Argumente angeben und -f/--rcfile to verwenden
source eine externe hgrc-Datei.

Verwenden Sie -d/--default, um die aktuelle Konfiguration zu deaktivieren.

See hg Hilfe Vorlagen für Informationen zu Vorlagen und Filtern.

Zubehör:

-D, --Ursprünglich
Standard-Keyword-Vorlagenzuordnungen anzeigen

-F,--rcfile
Karten aus rcfile lesen

kwexpand
Schlüsselwörter im Arbeitsverzeichnis erweitern:

hg kwexpand [OPTION]... [DATEI]...

Ausführung nach (erneuter) Aktivierung der Keyword-Erweiterung.

kwexpand verweigert die Ausführung, wenn angegebene Dateien lokale Änderungen enthalten.

Zubehör:

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

kw-Dateien
Dateien anzeigen, die für die Schlüsselworterweiterung konfiguriert sind:

hg kwfiles [OPTION]... [DATEI]...

Listen Sie auf, welche Dateien im Arbeitsverzeichnis mit der [Schlüsselwort]-Konfiguration übereinstimmen
Muster.

Nützlich, um eine versehentliche Erweiterung von Schlüsselwörtern zu verhindern und die Ausführung durch Einschließen zu beschleunigen
nur Dateien, die tatsächlich Kandidaten für eine Erweiterung sind.

See hg Hilfe Stichwort wie man Muster sowohl für die Inklusion als auch für den Exklusion konstruiert
Dateien.

Mit -A/--all und -v/--verbose werden folgende Codes verwendet, um den Status von Dateien anzuzeigen:

K = Keyword-Erweiterungskandidat
k = Keyword-Erweiterungskandidat (nicht verfolgt)
ich = ignoriert
i = ignoriert (nicht verfolgt)

Zubehör:

-EIN, --alle
Keyword-Status-Flags aller Dateien anzeigen

-ich, --ignorieren
Dateien anzeigen, die von der Erweiterung ausgeschlossen sind

-du, --Unbekannt
zeigt nur unbekannte (nicht getrackte) Dateien an

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

kwschrumpfen
erweiterte Schlüsselwörter im Arbeitsverzeichnis wiederherstellen:

hg kwshrink [OPTION]... [DATEI]...

Muss ausgeführt werden, bevor aktive Keywords geändert/deaktiviert werden.

kwshrink verweigert die Ausführung, wenn angegebene Dateien lokale Änderungen enthalten.

Zubehör:

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

große Dateien
Verfolgen Sie große Binärdateien

Große Binärdateien sind in der Regel nicht sehr komprimierbar, nicht sehr differenzierbar und überhaupt nicht
fusionierbar. Solche Dateien werden vom Speicherformat von Mercurial (revlog) nicht effizient gehandhabt,
das auf komprimierten binären Deltas basiert; Speichern großer Binärdateien wie gewohnt
Mercurial-Dateien verschwenden Bandbreite und Speicherplatz und erhöhen die Speichernutzung von Mercurial.
Die largefiles-Erweiterung geht diese Probleme an, indem sie einen zentralisierten Client-Server hinzufügt
Schicht auf Mercurial: Largefiles leben in a Hauptgeschäftsstelle speichern draußen im Netzwerk
irgendwo, und Sie holen sich nur die Überarbeitungen, die Sie brauchen, wenn Sie sie brauchen.

largefiles funktioniert, indem es für jede largefile eine "Standin-Datei" in .hglf/ verwaltet. Das
Standins sind klein (41 Byte: ein SHA-1-Hash plus Zeilenumbruch) und werden von Mercurial verfolgt.
Largefile-Revisionen werden durch den SHA-1-Hash ihres Inhalts identifiziert, der geschrieben wird
zum Stehen. largefiles verwendet diese Revisions-ID, um Largefile-Revisionen von/zu abzurufen/abzulegen
das Zentrallager. Dies spart sowohl Speicherplatz als auch Bandbreite, da Sie dies nicht tun müssen
Rufen Sie beim Klonen oder Pullen alle historischen Revisionen großer Dateien ab.

Um ein neues Repository zu starten oder neue große Binärdateien hinzuzufügen, fügen Sie einfach --large zu Ihrer hinzu hg hinzufügen
Befehl. Zum Beispiel:

$ dd if=/dev/urandom of=randomdata count=2000
$ hg add --large zufällige Daten
$ hg commit -m 'zufällige Daten als große Datei hinzufügen'

Wenn Sie einen Änderungssatz übertragen, der große Dateien zu einem Remote-Repository hinzufügt/ändert, wird seine
Largefile-Revisionen werden mit hochgeladen. Beachten Sie, dass das entfernte Mercurial muss
Lassen Sie auch die Largefiles-Erweiterung aktiviert, damit dies funktioniert.

Wenn Sie einen Änderungssatz abrufen, der sich auf Largefiles aus einem Remote-Repository auswirkt, werden die largefiles
denn das Changeset wird standardmäßig nicht heruntergezogen. Wenn Sie jedoch auf eine solche aktualisieren
Revision werden alle großen Dateien, die von dieser Revision benötigt werden, heruntergeladen und zwischengespeichert (falls vorhanden
wurde noch nie heruntergeladen). Eine Möglichkeit, große Dateien beim Ziehen zu ziehen, ist daher zu verwenden
--update, wodurch Ihre Arbeitskopie auf die neueste gezogene Revision aktualisiert wird (und dadurch
Herunterladen neuer großer Dateien).

Wenn Sie große Dateien ziehen möchten, die Sie noch nicht für das Update benötigen, können Sie pull with verwenden
--lfrev Option oder die hg lfpull Befehl.

Wenn Sie wissen, dass Sie von einem nicht standardmäßigen Speicherort ziehen und alle herunterladen möchten
largefiles, die gleichzeitig den neuen changesets entsprechen, dann kannst du mit ziehen
--lfrev "gezogen()".

Wenn Sie nur sicherstellen möchten, dass Sie über die großen Dateien verfügen, die zum Zusammenführen oder Rebasieren erforderlich sind
mit neuen köpfen, die du ziehst, dann kannst du mit ziehen --lfrev "Kopf (gezogen ())" Flagge
um vorbeugend alle großen Dateien herunterzuladen, die neu in den Köpfen sind, die Sie ziehen.

Denken Sie daran, dass jetzt möglicherweise ein Netzwerkzugriff erforderlich ist, um auf vorhandene Änderungssätze zu aktualisieren
zuvor nicht aktualisiert. Die Art der Largefiles-Erweiterung bedeutet, dass die Aktualisierung erfolgt
Es ist nicht mehr garantiert, dass es sich um einen rein lokalen Vorgang handelt.

Wenn Sie bereits große Dateien von Mercurial ohne die Erweiterung largefiles verfolgt haben, können Sie
müssen Ihr Repository konvertieren, um von Largefiles profitieren zu können. Das ist fertig
an. Nach der Installation können Sie HEIC-Dateien mit der hg lfconvert Befehl:

$ hg lfconvert --Größe 10 altes Repo neues Repo

In Repositorys, die bereits große Dateien enthalten, wird jede neue Datei über 10 MB
automatisch als largefile hinzugefügt. Um diesen Schwellenwert zu ändern, stellen Sie ein largefiles.minsize in
Ihre Mercurial-Konfigurationsdatei auf die Mindestgröße in Megabyte, um sie als Largefile zu verfolgen, oder
Verwenden Sie die Option --lfsize für den Befehl add (ebenfalls in Megabyte):

[große Dateien]
Mindestgröße = 2

$ hg füge --lfsize 2 hinzu

Das largefiles.patterns config-Option können Sie eine Liste von Dateinamenmustern angeben
(sehen hg Hilfe Muster), die immer als große Dateien verfolgt werden sollten:

[große Dateien]
Muster =
* .jpg
re:.*\.(png|bmp)$
Bibliothek.zip
Inhalt/Audio/*

Dateien, die einem dieser Muster entsprechen, werden unabhängig von ihrer Größe als große Dateien hinzugefügt
Größe.

Das largefiles.minsize und largefiles.patterns Konfigurationsoptionen werden für alle ignoriert
Repositorys, die noch keine Largefile enthalten. So fügen Sie die erste große Datei zu a
-Repository müssen Sie dies ausdrücklich mit dem --large -Flag tun, das an das übergeben wird hg hinzufügen Befehl.

Befehle
lfconvert
Konvertieren Sie ein normales Repository in ein Largefiles-Repository:

hg lfconvert QUELLE ZIEL [DATEI ...]

Konvertieren Sie das Repository SOURCE in ein neues Repository DEST, das bis auf das mit SOURCE identisch ist
Bestimmte Dateien werden als große Dateien konvertiert: insbesondere jede Datei, die mit einer übereinstimmt
MUSTER or deren Größe über der Mindestgröße liegt, wird in eine große Datei konvertiert. Das
Größe, die verwendet wird, um zu bestimmen, ob eine Datei nachverfolgt werden soll oder nicht, da eine große Datei die Größe der Datei ist
erste Version der Datei. Die Mindestgröße kann entweder mit --size oder in angegeben werden
Konfiguration als große Dateien.Größe.

Nachdem Sie diesen Befehl ausgeführt haben, müssen Sie sicherstellen, dass Largefiles überall aktiviert ist
Sie beabsichtigen, das neue Repository zu pushen.

Verwenden Sie --to-normal, um große Dateien wieder in normale Dateien umzuwandeln; danach das DEST
Das Repository kann überhaupt ohne große Dateien verwendet werden.

Zubehör:

-S,--Größe
Mindestgröße (MB) für Dateien, die als largefiles konvertiert werden sollen

--zu-normal
Konvertieren Sie von einem Largefiles-Repo in ein normales Repo

lfpull
große Dateien für die angegebenen Revisionen aus der angegebenen Quelle abrufen:

hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [QUELLE]

Ziehen Sie große Dateien, auf die von lokalen Änderungssätzen verwiesen wird, die jedoch lokal fehlen, und ziehen Sie sie
von einem entfernten Repository in den lokalen Cache.

Wenn SOURCE weggelassen wird, wird der 'Standard'-Pfad verwendet. Sehen hg Hilfe urls Für weitere
Informationen.

Einige Beispiele:

· große Dateien für alle Zweigköpfe ziehen:

hg lfpull -r "head() und nicht closed()"

· große Dateien auf den Standardzweig ziehen:

hg lfpull -r "Zweig (Standard)"

Zubehör:

-R,--rev
Ziehen Sie große Dateien für diese Revisionen

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

mq
einen Stapel von Patches verwalten

Mit dieser Erweiterung können Sie mit einem Stapel von Patches in einem Mercurial-Repository arbeiten. Es verwaltet
zwei Stapel von Patches – alle bekannten Patches und angewendete Patches (Teilmenge bekannter Patches).

Bekannte Patches werden als Patch-Dateien im Verzeichnis .hg/patches dargestellt. Angewandte Patches
sind sowohl Patch-Dateien als auch Changesets.

Allgemeine Aufgaben (use hg Hilfe Befehl für mehr Details):

neuen Patch erstellen qnew
bestehenden Patch importieren qimport

Druckpatch-Serie qseries
aufgebrachte Patches drucken qapplied

bekannten Patch zum angewendeten Stack hinzufügen qpush
Entfernen Sie den Patch aus dem angewendeten Stack qpop
Aktualisieren Sie den Inhalt des am häufigsten angewendeten Patches qrefresh

Standardmäßig verwendet mq bei Bedarf automatisch Git-Patches, um den Verlust des Dateimodus zu vermeiden
Änderungen, Kopieren von Datensätzen, Erstellen oder Löschen von Binärdateien oder leeren Dateien. Dieses Verhalten
kann konfiguriert werden mit:

[mq]
git = auto/behalten/ja/nein

Wenn es auf „Keep“ gesetzt ist, wird mq der Konfiguration des [diff]-Abschnitts gehorchen, während die vorhandene beibehalten wird
git-Patches bei qrefresh. Wenn auf „yes“ oder „no“ gesetzt, überschreibt mq den Abschnitt [diff].
und generieren Sie immer Git- oder reguläre Patches, wobei im zweiten Fall möglicherweise Daten verloren gehen.

Es kann wünschenswert sein, dass mq-Änderungssätze in der geheimen Phase gehalten werden (siehe hg Hilfe Phasen),
die mit der folgenden Einstellung aktiviert werden kann:

[mq]
geheim = wahr

Standardmäßig verwalten Sie eine Patch-Warteschlange mit dem Namen „Patches“. Sie können andere erstellen,
unabhängige Patch-Warteschlangen mit der hg Warteschlange Befehl.

Wenn das Arbeitsverzeichnis nicht festgeschriebene Dateien enthält, brechen qpush, qpop und qgoto ab
sofort. Wenn -f/--force verwendet wird, werden die Änderungen verworfen. Einstellung:

[mq]
Keepchanges = True

Lassen Sie sie sich so verhalten, als ob --keep-changes übergeben worden wäre, und nicht widersprüchliche lokale Änderungen werden dies tun
geduldet und bewahrt werden. Wenn inkompatible Optionen wie -f/--force oder --exact sind
bestanden, wird diese Einstellung ignoriert.

Diese Erweiterung wurde verwendet, um einen Strip-Befehl bereitzustellen. Dieser Befehl lebt jetzt im Streifen
Erweiterung.

Befehle
qangewendet
Drucken Sie die bereits aufgebrachten Patches:

hg qapplied [-1] [-s] [PATCH]

Gibt bei Erfolg 0 zurück.

Zubehör:

-1, --letzte
zeigt nur das vorher angewendete Patch

-S, --Zusammenfassung
erste Zeile des Patch-Headers drucken

qclone
Haupt- und Patch-Repository gleichzeitig klonen:

hg qclone [OPTION]... QUELLE [ZIEL]

Wenn die Quelle lokal ist, werden auf das Ziel keine Patches angewendet. Wenn die Quelle entfernt ist, dies
Der Befehl kann nicht überprüfen, ob Patches in der Quelle angewendet wurden, und kann daher nicht garantieren, dass Patches vorhanden sind
werden im Bestimmungsort nicht angewendet. Wenn Sie ein entferntes Repository klonen, vergewissern Sie sich vorher, dass dies der Fall ist
keine Patches angewendet.

Das Quell-Patch-Repository wird in gesucht /.hg/patches standardmäßig. Verwenden Sie -p zu
zu navigieren.

Das Patch-Verzeichnis muss ein verschachteltes Mercurial-Repository sein, wie es von erstellt würde hg init
--mq.

Bei Erfolg 0 zurückgeben.

Zubehör:

--ziehen Verwenden Sie das Pull-Protokoll, um Metadaten zu kopieren

-U, --kein Update
aktualisieren Sie die neuen Arbeitsverzeichnisse nicht

--unkomprimiert
unkomprimierte Übertragung verwenden (schnell über LAN)

-P,- Patches
Speicherort des Quell-Patch-Repositorys

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

qcommit
Commit-Änderungen im Warteschlangen-Repository (VERALTET):

hg qcommit [OPTION]... [DATEI]...

Dieser Befehl ist veraltet; verwenden hg verpflichten --mq stattdessen.

Zubehör:

-EIN, --addremove
Markiere neue/fehlende Dateien als hinzugefügt/entfernt, bevor du sie festlegst

--Zweig schließen
einen Zweigkopf als geschlossen markieren

--ändern
das übergeordnete Element des Arbeitsverzeichnisses ändern

-S, --Geheimnis
Nutze die geheime Phase zum Begehen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-ich, --interaktiv
Verwenden Sie den interaktiven Modus

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

-S, --subrepos
Rekurs in Unterverzeichnisse

[+] markierte Option kann mehrfach angegeben werden

Aliasse: qci

qlöschen
Patches aus der Warteschlange entfernen:

hg qdelete [-k] [PATCH]...

Die Patches müssen nicht angewendet werden, und mindestens ein Patch ist erforderlich. Genauer Patch
Kennungen müssen angegeben werden. Mit -k/--keep bleiben die Patch-Dateien im Patch erhalten
Verzeichnis.

Um die Verwaltung eines Patches zu beenden und ihn in den permanenten Verlauf zu verschieben, verwenden Sie die hg qfertig Befehl.

Zubehör:

-k, --halten
Patchdatei behalten

-R,--rev
Verwaltung einer Überarbeitung beenden (VERALTET)

[+] markierte Option kann mehrfach angegeben werden

Aliasse: qremove qrm

qdiff
diff des aktuellen Patches und nachfolgende Modifikationen:

hg qdiff [OPTION]... [DATEI]...

Zeigt ein Diff an, das den aktuellen Patch sowie alle vorgenommenen Änderungen enthält
im Arbeitsverzeichnis seit der letzten Aktualisierung (zeigt also, was der aktuelle Patch würde
werden nach einem qrefresh).

Verwenden Sie die hg diff wenn Sie nur die Änderungen sehen möchten, die seit dem letzten qrefresh vorgenommen wurden, oder hg exportieren
Tipp wenn Sie die vom aktuellen Patch vorgenommenen Änderungen sehen möchten, ohne die vorgenommenen Änderungen einzubeziehen
seit dem qrefresh.

Gibt bei Erfolg 0 zurück.

Zubehör:

-a, --Text
Behandeln Sie alle Dateien als Text

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

--nodates
Daten aus Diff-Headern weglassen

--noprefix
weglassen a/ und b/ Präfixe von Dateinamen

-P, --show-Funktion
zeigen, in welcher Funktion jede Änderung enthalten ist

--umkehren
einen Diff erzeugen, der die Änderungen rückgängig macht

-w, --ignore-all-space
ignoriere Leerzeichen beim Vergleichen von Zeilen

-B, --ignore-space-change
Ignorieren Sie Änderungen in der Menge des Leerraums

-B, --leerzeilen ignorieren
Ignoriere Änderungen, deren Zeilen alle leer sind

-U,--einheitlich
Anzahl der anzuzeigenden Kontextzeilen

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

--Wurzel
erzeugen Diffs relativ zum Unterverzeichnis

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

qfertig
Angewandte Patches in den Repository-Verlauf verschieben:

hg qfinish [-a] [REV]...

Beendet die angegebenen Revisionen (die angewendeten Patches entsprechen), indem sie aus verschoben werden
mq control in den regulären Repository-Verlauf.

Akzeptiert einen Revisionsbereich oder die Option -a/--applied. Wenn --applied angegeben ist, all
Angewandte mq-Revisionen werden aus der mq-Steuerung entfernt. Ansonsten müssen die angegebenen Revisionen sein
an der Basis des Stapels aufgebrachter Patches.

Dies kann besonders nützlich sein, wenn Ihre Änderungen auf ein Upstream-Repository angewendet wurden.
oder wenn Sie im Begriff sind, Ihre Änderungen in den Upstream zu verschieben.

Gibt bei Erfolg 0 zurück.

Zubehör:

-a, --angewandt
Beenden Sie alle angewendeten Änderungssätze

qfach
falten Sie die benannten Patches in den aktuellen Patch:

hg qfold [-e] [-k] [-m TEXT] [-l DATEI] PATCH...

Patches dürfen noch nicht angewendet werden. Jeder Patch wird nacheinander auf den Strom angewendet
Patch in der angegebenen Reihenfolge. Wenn alle Patches erfolgreich angewendet werden, wird der aktuelle Patch sein
mit dem neuen kumulativen Patch aktualisiert und die gefalteten Patches werden gelöscht. Mit
-k/--keep, die gefalteten Patch-Dateien werden danach nicht entfernt.

Der Header für jeden gefalteten Patch wird mit dem aktuellen Patch-Header verkettet,
getrennt durch eine Linie von * * *.

Gibt bei Erfolg 0 zurück.

Zubehör:

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-k, --halten
Bewahren Sie gefaltete Patch-Dateien auf

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

qgoto
Push- oder Pop-Patches, bis der benannte Patch ganz oben auf dem Stapel ist:

hg qgoto [OPTION]... PATCH

Gibt bei Erfolg 0 zurück.

Zubehör:

--behalte die Änderungen bei
tolerieren nicht widersprüchliche lokale Änderungen

-F, --Macht
Überschreiben Sie alle lokalen Änderungen

--keine Sicherung
keine Sicherungskopien von Dateien speichern

qwache
Guards für einen Patch setzen oder drucken:

hg qguard [-l] [-n] [PATCH] [-- [+GUARD]... [-GUARD]...]

Guards kontrollieren, ob ein Patch gepusht werden kann. Ein Patch ohne Guards wird immer gepusht. EIN
Patch mit einem positiven Guard ("+foo") wird nur gepusht, wenn der hg SAUSWAHL Befehl hat
aktiviert es. Ein Patch mit einem negativen Guard ("-foo") wird niemals gepusht, wenn die hg SAUSWAHL
Befehl hat es aktiviert.

Geben Sie ohne Argumente die derzeit aktiven Guards aus. Setzen Sie mit Argumenten Wachen für die
Namenspatch.

Hinweis Die Angabe negativer Wächter erfordert jetzt '--'.

So legen Sie Guards auf einem anderen Patch fest:

hg qguard other.patch – +2.6.17 – stabil

Gibt bei Erfolg 0 zurück.

Zubehör:

- l, --aufführen
listet alle Patches und Guards auf

-nicht, --keiner
Lass alle Wachen fallen

qheader
Drucken Sie die Kopfzeile des obersten oder angegebenen Patches:

hg qheader [PATCH]

Gibt bei Erfolg 0 zurück.

qimport
Importieren Sie einen Patch oder ein vorhandenes Changeset:

hg qimport [-e] [-n NAME] [-f] [-g] [-P] [-r REV]... [DATEI]...

Der Patch wird nach dem zuletzt angewendeten Patch in die Reihe eingefügt. Wenn keine Patches haben
angewendet wurde, stellt qimport den Patch der Serie voran.

Der Patch hat denselben Namen wie seine Quelldatei, es sei denn, Sie geben ihm einen neuen mit
-n/--Name.

Sie können einen vorhandenen Patch im Patch-Verzeichnis mit dem Flag -e/--existing registrieren.

Mit -f/--force wird ein vorhandener gleichnamiger Patch überschrieben.

Ein bestehender Changeset kann mit -r/--rev unter mq-Steuerung gestellt werden (z. B. qimport --rev .
-n Patch stellt die aktuelle Revision unter mq-Steuerung). Mit -g/--git, Patches
importiert mit --rev verwendet das git diff-Format. Weitere Informationen finden Sie im Diffs-Hilfethema
warum dies wichtig ist, um Umbenennungs-/Kopierinformationen und Berechtigungsänderungen beizubehalten.
Verwenden Sie die hg qfertig um Änderungssätze aus der mq-Steuerung zu entfernen.

Um einen Patch aus der Standardeingabe zu importieren, übergeben Sie - als Patch-Datei. Beim Import aus
Standardeingabe muss ein Patch-Name mit dem Flag --name angegeben werden.

So importieren Sie einen vorhandenen Patch, während Sie ihn umbenennen:

hg qimport -e bestehender Patch -n neuer Name

Gibt 0 zurück, wenn der Import erfolgreich war.

Zubehör:

-e, --bestehende
import-Datei im Patch-Verzeichnis

-nicht,--Name
Name der Patch-Datei

-F, --Macht
Bestehende Dateien überschreiben

-R,--rev
Platzieren Sie vorhandene Revisionen unter mq-Steuerung

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

-P, --drücken
qpush nach dem Importieren

[+] markierte Option kann mehrfach angegeben werden

qinit
init ein neues Warteschlangen-Repository (VERALTET):

hg qinit [-c]

Das Warteschlangen-Repository ist standardmäßig nicht versioniert. Wenn -c/--create-repo angegeben ist, qinit
erstellt ein separates verschachteltes Repository für Patches (qinit -c kann auch später ausgeführt werden
Konvertieren Sie ein unversioniertes Patch-Repository in ein versioniertes Repository). Sie können qcommit verwenden
Änderungen an diesem Warteschlangen-Repository festschreiben.

Dieser Befehl ist veraltet. Ohne -c wird es von anderen relevanten Befehlen impliziert. Mit -c,
- hg init --mq stattdessen.

Zubehör:

-C, --create-repo
Warteschlangen-Repository erstellen

neu
Erstellen Sie einen neuen Patch:

hg qnew [-e] [-m TEXT] [-l DATEI] PATCH [DATEI]...

qnew erstellt einen neuen Patch über dem aktuell angewendeten Patch (falls vorhanden). Der Patch wird
mit ausstehenden Änderungen im Arbeitsverzeichnis initialisiert. Sie können auch verwenden
-I/--include, -X/--exclude und/oder eine Liste von Dateien nach dem Patch-Namen, die nur hinzugefügt werden sollen
Änderungen an übereinstimmenden Dateien mit dem neuen Patch, wobei der Rest als nicht festgeschriebene Änderungen belassen wird.

-u/--user und -d/--date können verwendet werden, um den (gegebenen) Benutzer bzw. das Datum zu setzen.
-U/--aktuellerBenutzer und -D/--aktuellesDatum setzt den Benutzer auf den aktuellen Benutzer und das Datum auf das aktuelle Datum.

-e/--edit, -m/--message oder -l/--logfile setzt den Patch-Header sowie den Commit
Botschaft. Wenn nichts angegeben ist, ist der Header leer und die Commit-Nachricht lautet '[mq]:
PATCH'.

Verwenden Sie die Option -g/--git, um den Patch im erweiterten Git-Diff-Format zu belassen. Lesen Sie die Unterschiede
Hilfethema für weitere Informationen darüber, warum dies wichtig ist, um Berechtigungsänderungen beizubehalten
und Informationen kopieren/umbenennen.

Gibt 0 zurück, wenn ein neuer Patch erfolgreich erstellt wurde.

Zubehör:

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-F, --Macht
Nicht festgeschriebene Änderungen importieren (VERALTET)

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

-U, --aktuellerBenutzer
füge "Von: " etwas verbessern

-du,--Benutzer
füge "Von: " etwas verbessern

-D, --aktuelles Datum
Datum hinzufügen: " etwas verbessern

-D,--Datum
Datum hinzufügen: " etwas verbessern

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

[+] markierte Option kann mehrfach angegeben werden

qweiter
den Namen des nächsten pushbaren Patches ausgeben:

hg qweiter [-s]

Gibt bei Erfolg 0 zurück.

Zubehör:

-S, --Zusammenfassung
erste Zeile des Patch-Headers drucken

qpop
holen Sie den aktuellen Patch vom Stack:

hg qpop [-a] [-f] [PATCH | INDEX]

Ohne Argument springt es von der Spitze des Patch-Stacks ab. Wenn ein Patch-Name angegeben wird, behält er bei
Entfernen von Patches, bis sich der benannte Patch ganz oben auf dem Stapel befindet.

Standardmäßig abbrechen, wenn das Arbeitsverzeichnis nicht festgeschriebene Änderungen enthält. Mit
--keep-changes, nur abbrechen, wenn sich die nicht festgeschriebenen Dateien mit gepatchten Dateien überschneiden. Mit
-f/--Änderungen an solchen Dateien erzwingen, sichern und verwerfen.

Bei Erfolg 0 zurückgeben.

Zubehör:

-a, --alle
Pop alle Patches

-nicht,--Name
Warteschlangenname zum Pop (VERALTET)

--behalte die Änderungen bei
tolerieren nicht widersprüchliche lokale Änderungen

-F, --Macht
Vergessen Sie alle lokalen Änderungen an gepatchten Dateien

--keine Sicherung
keine Sicherungskopien von Dateien speichern

qprev
Drucken Sie den Namen des zuvor angewendeten Patches:

hg qprev [-s]

Gibt bei Erfolg 0 zurück.

Zubehör:

-S, --Zusammenfassung
erste Zeile des Patch-Headers drucken

qdrücken
Schieben Sie den nächsten Patch auf den Stapel:

hg qpush [-f] [-l] [-a] [--move] [PATCH | INDEX]

Standardmäßig abbrechen, wenn das Arbeitsverzeichnis nicht festgeschriebene Änderungen enthält. Mit
--keep-changes, nur abbrechen, wenn sich die nicht festgeschriebenen Dateien mit gepatchten Dateien überschneiden. Mit
-f/--force, Backup und Patch über nicht festgeschriebene Änderungen.

Bei Erfolg 0 zurückgeben.

Zubehör:

--behalte die Änderungen bei
tolerieren nicht widersprüchliche lokale Änderungen

-F, --Macht
gelten zusätzlich zu den lokalen Änderungen

-e, --genau
Wenden Sie den Ziel-Patch auf seinen aufgezeichneten Elternteil an

- l, --aufführen
Listen Sie den Patch-Namen im Commit-Text auf

-a, --alle
Wenden Sie alle Patches an

-M, --verschmelzen
aus einer anderen Warteschlange zusammenführen (VERALTET)

-nicht,--Name
Name der Zusammenführungswarteschlange (VERALTET)

--Bewegung Patch-Serien neu anordnen und nur den Patch anwenden

--keine Sicherung
keine Sicherungskopien von Dateien speichern

Warteschlange
mehrere Patch-Warteschlangen verwalten:

hg qqueue [OPTION] [WARTESCHLANGE]

Unterstützt das Wechseln zwischen verschiedenen Patch-Warteschlangen sowie das Erstellen neuer Patch-Warteschlangen
und vorhandene löschen.

Wenn Sie einen Warteschlangennamen weglassen oder -l/--list angeben, werden Ihnen die registrierten Warteschlangen angezeigt - von
Standardmäßig ist die "normale" Patch-Warteschlange registriert. Die derzeit aktive Warteschlange wird sein
mit "(aktiv)" gekennzeichnet. Wenn Sie --active angeben, wird nur der Name der aktiven Warteschlange gedruckt.

Um eine neue Warteschlange zu erstellen, verwenden Sie -c/--create. Die Warteschlange wird automatisch aktiviert, außer in
der Fall, in dem angewendete Patches aus der derzeit aktiven Warteschlange in der
Repository. Dann wird die Warteschlange nur erstellt und das Umschalten schlägt fehl.

Um eine vorhandene Warteschlange zu löschen, verwenden Sie --delete. Sie können die derzeit aktive Warteschlange nicht löschen.

Gibt bei Erfolg 0 zurück.

Zubehör:

- l, --aufführen
listet alle verfügbaren Warteschlangen auf

--aktiv
Druckname der aktiven Warteschlange

-C, --schaffen
neue Warteschlange erstellen

--umbenennen
aktive Warteschlange umbenennen

--löschen
Verweis auf Warteschlange löschen

--säubern
Warteschlange löschen und Patch-Verzeichnis entfernen

qaktualisieren
aktualisiere den aktuellen Patch:

hg qrefresh [-I] [-X] [-e] [-m TEXT] [-l DATEI] [-s] [DATEI]...

Wenn Dateimuster bereitgestellt werden, enthält der aktualisierte Patch nur die Änderungen
die zu diesen Mustern passen; die verbleibenden Modifikationen bleiben in Bearbeitung
Verzeichnis.

Wenn -s/--short angegeben ist, werden die aktuell im Patch enthaltenen Dateien nur aktualisiert
wie abgeglichene Dateien und verbleiben im Patch.

Wenn -e/--edit angegeben ist, startet Mercurial Ihren konfigurierten Editor, damit Sie a eingeben können
Botschaft. Falls qrefresh fehlschlägt, finden Sie eine Sicherungskopie Ihrer Nachricht in
.hg/letzte-Nachricht.txt.

hg add/remove/copy/rename funktioniert wie gewohnt, obwohl Sie vielleicht Patches im Git-Stil verwenden möchten
(-g/--git oder [diff] git=1), um Kopien und Umbenennungen zu verfolgen. Weitere Informationen finden Sie im Diffs-Hilfethema
Informationen zum git diff-Format.

Gibt bei Erfolg 0 zurück.

Zubehör:

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

-S, --kurz
aktualisiere nur Dateien, die sich bereits im Patch befinden, und bestimmte Dateien

-U, --aktuellerBenutzer
Autorenfeld im Patch mit aktuellem Benutzer hinzufügen/aktualisieren

-du,--Benutzer
Autorenfeld im Patch mit gegebenem Benutzer hinzufügen/aktualisieren

-D, --aktuelles Datum
Datumsfeld im Patch mit aktuellem Datum hinzufügen/aktualisieren

-D,--Datum
Datumsfeld im Patch mit dem angegebenen Datum hinzufügen/aktualisieren

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

[+] markierte Option kann mehrfach angegeben werden

qumbenennen
Patch umbenennen:

hg qrename PATCH1 [PATCH2]

Benennt mit einem Argument den aktuellen Patch in PATCH1 um. Mit zwei Argumenten umbenennen
PATCH1 bis PATCH2.

Gibt bei Erfolg 0 zurück.

Aliase: qmv

qwiederherstellen
Stellen Sie den durch eine Revision gespeicherten Warteschlangenstatus wieder her (DEPRECATED):

hg qrestore [-d] [-u] REV

Dieser Befehl ist veraltet, verwenden hg zurückweisen stattdessen.

Zubehör:

-D, --löschen
löschen Eintrag speichern

-du, --aktualisieren
Arbeitsverzeichnis der Warteschlange aktualisieren

qspeichern
aktuellen Warteschlangenstatus speichern (VERALTET):

hg qsave [-m TEXT] [-l DATEI] [-c] [-n NAME] [-e] [-f]

Dieser Befehl ist veraltet, verwenden hg zurückweisen stattdessen.

Zubehör:

-C, --Kopieren
Patch-Verzeichnis kopieren

-nicht,--Name
Verzeichnisnamen kopieren

-e, --leer
Statusdatei der Warteschlange löschen

-F, --Macht
Kopie erzwingen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

SAUSWAHL
setze oder drucke geschützte Patches zum Pushen:

hg qWählen Sie [OPTIONEN]... [WÄCHTER]...

Verwenden Sie das hg qwache Befehl zum Setzen oder Drucken von Guards auf Patch, dann verwenden Sie qselect, um mq mitzuteilen
welche Wachen zu verwenden sind. Ein Patch wird gepusht, wenn er keine Guards oder positive Guards hat
mit dem aktuell ausgewählten Guard übereinstimmen, werden aber nicht verschoben, wenn negative Guards übereinstimmen
die jetzige Wache. Zum Beispiel:

qguard foo.patch -- -stable (negativer Wächter)
qguard bar.patch +stable (positiver Schutz)
qstabil auswählen

Dadurch wird der „Stable“-Wächter aktiviert. mq überspringt foo.patch (weil es eine negative
match), aber push bar.patch (weil es eine positive Übereinstimmung hat).

Gibt ohne Argumente die derzeit aktiven Guards aus. Setzt mit einem Argument das aktive
bewachen.

Verwenden Sie -n/--none, um Wächter zu deaktivieren (keine weiteren Argumente erforderlich). Wenn keine Wachen sind
aktiv, Patches mit positiven Guards werden übersprungen und Patches mit negativen Guards werden übersprungen
geschoben.

qselect kann die Guards auf angewendeten Patches ändern. Es knallt keine bewachten Patches vorbei
Ursprünglich. Verwenden Sie --pop, um zum zuletzt angewendeten Patch zurückzukehren, der nicht überwacht wird. Verwenden
--reapply (was --pop impliziert), um danach zum aktuellen Patch zurückzukehren, aber zu überspringen
bewachte Patches.

Verwenden Sie -s/--series, um eine Liste aller Guards in der Seriendatei auszugeben (keine anderen Argumente
erforderlich). Verwenden Sie -v für weitere Informationen.

Gibt bei Erfolg 0 zurück.

Zubehör:

-nicht, --keiner
alle Wächter deaktivieren

-S, --Serie
listet alle Wachen in der Seriendatei auf

--Pop Pop zu vor dem ersten bewachten angewendeten Patch

--erneut bewerben
Pop, und wenden Sie die Patches erneut an

qserie
Drucken Sie die gesamte Seriendatei:

hg qseries [-ms]

Gibt bei Erfolg 0 zurück.

Zubehör:

-M, --fehlen
Druckpatches nicht in Serie

-S, --Zusammenfassung
erste Zeile des Patch-Headers drucken

oben
gibt den Namen des aktuellen Patches aus:

hg qtop [-s]

Gibt bei Erfolg 0 zurück.

Zubehör:

-S, --Zusammenfassung
erste Zeile des Patch-Headers drucken

qunangewendet
Drucken Sie die noch nicht angewendeten Patches:

hg qunapplied [-1] [-s] [PATCH]

Gibt bei Erfolg 0 zurück.

Zubehör:

-1, --Erste
zeigt nur den ersten Patch

-S, --Zusammenfassung
erste Zeile des Patch-Headers drucken

benachrichtigen
Hooks zum Senden von E-Mail-Push-Benachrichtigungen

Diese Erweiterung implementiert Hooks zum Senden von E-Mail-Benachrichtigungen, wenn Changesets gesendet werden
oder vom lokalen Repository empfangen werden.

Aktivieren Sie zunächst die Erweiterung wie in beschrieben hg Hilfe Erweiterungen, und registrieren Sie den Haken Sie
laufen wollen. eingehende und Gruppe ändern Hooks werden ausgeführt, wenn Changesets empfangen werden, während
abgehenden Hooks sind für Changesets, die an ein anderes Repository gesendet werden:

[Haken]
# eine E-Mail für jeden eingehenden Changeset
eingehende.notify = python:hgext.notify.hook
# eine E-Mail für alle eingehenden Änderungssätze
changegroup.notify = python:hgext.notify.hook

# eine E-Mail für alle ausgehenden Changesets
ausgehend.notify = python:hgext.notify.hook

Dies registriert die Haken. Um die Benachrichtigung zu aktivieren, müssen Abonnenten zugewiesen werden
Lagerstätten. Das [usersubs] Abschnitt ordnet mehrere Repositories einem bestimmten Empfänger zu. Das
[repos] Abschnitt ordnet mehrere Empfänger einem einzigen Repository zu:

[usersubs]
Der #-Schlüssel ist die E-Mail-Adresse des Abonnenten, der Wert ist eine durch Kommas getrennte Liste von Repo-Mustern
Benutzer@Host = Muster

[repos]
# Schlüssel ist Repo-Muster, Wert ist eine durch Kommas getrennte Liste von Abonnenten-E-Mails
Muster = Benutzer@Host

A Anleitungen ist eine Klacks Übereinstimmung mit dem absoluten Pfad zu einem Repository, optional kombiniert mit a
revset-Ausdruck. Ein Revset-Ausdruck, sofern vorhanden, wird durch einen Hash vom Glob getrennt.
Beispiel:

[repos]
*/widgets#branch(release) = [E-Mail geschützt]

Dies sendet an [E-Mail geschützt] immer wenn ein changeset auf der Release Verzweigung löst a
Benachrichtigung in jedem Repository mit der Endung widgets.

Um sie unter direkte Benutzerverwaltung zu stellen, [usersubs] und [repos] Abschnitte
kann separat platziert werden hgrc Datei und durch Verweis aufgenommen:

[benachrichtigen]
config = /path/to/subscriptionsfile

Benachrichtigungen werden erst am verschickt benachrichtigen.test Wert ist auf eingestellt falsch; siehe unten.

Der Inhalt der Benachrichtigungen kann mit den folgenden Konfigurationseinträgen angepasst werden:

benachrichtigen.test
If Wahre, Nachrichten an stdout ausgeben, anstatt sie zu senden. Standard: True.

benachrichtigen.Quellen
Durch Leerzeichen getrennte Liste der Änderungsquellen. Benachrichtigungen werden nur aktiviert, wenn a
Die Quelle des Änderungssatzes befindet sich in dieser Liste. Quellen können sein:

brauchen

über http oder ssh empfangene Änderungssätze

ziehen

erhaltene Änderungssätze per hg ziehen

aufschlüsseln

erhaltene Änderungssätze per hg aufschlüsseln

drücken

Änderungssätze gesendet oder empfangen über hg drücken

bündeln

Änderungssätze gesendet per hg aufschlüsseln

Standard: dienen.

benachrichtigen.strip
Anzahl der führenden Schrägstriche, die von URL-Pfaden entfernt werden sollen. Standardmäßig Benachrichtigungen
Referenz-Repositories mit ihrem absoluten Pfad. benachrichtigen.strip lässt Sie sie drehen
in relative Pfade. Zum Beispiel, benachrichtigen.strip=3 wird sich ändern /long/Pfad/Repository
in Quelle. Standard: 0.

benachrichtigen.domain
Standard-E-Mail-Domäne für Absender oder Empfänger ohne explizite Domäne.

benachrichtigen.stil
Stildatei, die beim Formatieren von E-Mails verwendet werden soll.

benachrichtigen.vorlage
Vorlage zum Formatieren von E-Mails.

benachrichtigen.eingehend
Vorlage, die verwendet werden soll, wenn sie als eingehender Hook ausgeführt wird, überschreibt benachrichtigen.vorlage.

benachrichtigen.ausgehend
Vorlage, die verwendet werden soll, wenn sie als ausgehender Hook ausgeführt wird, überschreibt benachrichtigen.vorlage.

benachrichtigen.Gruppe ändern
Vorlage, die verwendet werden soll, wenn sie als Änderungsgruppen-Hook ausgeführt wird, überschreibt benachrichtigen.vorlage.

benachrichtigen.maxdiff
Maximale Anzahl von Diff-Zeilen, die in die Benachrichtigungs-E-Mail aufgenommen werden sollen. Zum Deaktivieren auf 0 setzen
der Diff oder -1, um alles einzuschließen. Standard: 300.

benachrichtigen.maxsubject
Maximale Anzahl von Zeichen in der Betreffzeile der E-Mail. Standard: 67.

Benachrichtigung.diffstat
Auf True setzen, um ein Diffstat vor dem Diff-Inhalt einzuschließen. Standard: True.

benachrichtigen.zusammenführen
Wenn „True“, Benachrichtigungen zum Zusammenführen von Changesets senden. Standard: True.

Benachrichtigung.mbox
Wenn gesetzt, werden E-Mails an diese mbox-Datei angehängt, anstatt sie zu senden. Standard: Keine.

Benachrichtigen.vonAutor
Wenn gesetzt, verwende den Committer des ersten Änderungssatzes in einer Änderungsgruppe für das "Von".
Feld der Benachrichtigungsmail. Wenn nicht festgelegt, nehmen Sie den Benutzer aus dem Push-Repo.
Standard: Falsch.

Wenn gesetzt, werden die folgenden Einträge auch verwendet, um die Benachrichtigungen anzupassen:

E-Mail von
E-Mail Aus zu verwendende Adresse, wenn keine im generierten E-Mail-Inhalt gefunden werden kann.

web.baseurl
Root-Repository-URL, die beim Erstellen von Referenzen mit Repository-Pfad kombiniert werden soll. Sehen
ebenfalls benachrichtigen.strip.

zahlen
Durchsuchen Sie die Befehlsausgabe mit einem externen Pager

Um den zu verwendenden Pager festzulegen, setzen Sie die Anwendungsvariable:

[Pager]
Pager = weniger -FRX

Wenn kein Pager gesetzt ist, verwenden die Pager-Erweiterungen die Umgebungsvariable $PAGER. Wenn weder
pager.pager noch $PAGER gesetzt ist, wird kein Pager verwendet.

Sie können den Pager für bestimmte Befehle deaktivieren, indem Sie sie zur pager.ignore-Liste hinzufügen:

[Pager]
Ignorieren = Version, Hilfe, Update

Sie können den Pager auch nur für bestimmte Befehle mit pager.attend aktivieren. Unten ist die
Standardliste der Befehle, die ausgelagert werden sollen:

[Pager]
teilnehmen = kommentieren, cat, diff, exportieren, glog, log, qdiff

Wenn Sie pager.attend auf einen leeren Wert setzen, werden alle Befehle ausgelagert.

Wenn pager.attend vorhanden ist, wird pager.ignore ignoriert.

Schließlich können Sie das Paging für einzelne Befehle mit aktivieren und deaktivieren
teilnehmen- Möglichkeit. Diese Einstellung hat Vorrang vor vorhandenen Teilnahmen und Ignorieren
Optionen und Voreinstellungen:

[Pager]
teilnehmen-Katze = falsch

Um globale Befehle wie zu ignorieren hg Version or hg Hilfe, müssen Sie sie in Ihrer angeben
Benutzerkonfigurationsdatei.

Um zu steuern, ob der Pager überhaupt für einen einzelnen Befehl verwendet wird, können Sie verwenden
--pager= :

- nach Bedarf verwenden: `auto`.
- fordert den Pager an: `yes` oder `on`.
- den Pager unterdrücken: `no` oder `off` (jeder unbekannte Wert
geht auch).

Patchbombe
Befehl zum Senden von Änderungssätzen als (eine Reihe von) Patch-E-Mails

Die Serie beginnt mit einer „[PATCH 0 von N]“-Einleitung, die die Serie beschreibt
als Ganzes.

Jede Patch-E-Mail hat eine Betreffzeile von „[PATCH M of N] …“, wobei die erste Zeile der verwendet wird
Changeset-Beschreibung als Betrefftext. Die Nachricht enthält zwei oder drei Textteile:

· Die Changeset-Beschreibung.

· [Optional] Das Ergebnis der Ausführung von diffstat auf dem Patch.

· Der Patch selbst, wie generiert von hg exportieren.

Jede Nachricht bezieht sich auf die erste in der Reihe unter Verwendung von In-Reply-To und References
Kopfzeilen, sodass sie als Sequenz in Mail-Threads und Newsreadern sowie in Mail angezeigt werden
Archiv.

Um andere Standardeinstellungen zu konfigurieren, fügen Sie Ihrer Konfigurationsdatei einen Abschnitt wie diesen hinzu:

[Email]
von = Mein Name
an = Empfänger1, Empfänger2, ...
cc = cc1, cc2, ...
bcc = bcc1, bcc2, ...
Antwort an = Adresse1, Adresse2, ...

Verwenden Sie die [Patchbombe] als Name des Konfigurationsabschnitts, wenn Sie global überschreiben müssen [Email]
Adresseinstellungen.

Dann können Sie die verwenden hg E-Mail Befehl, eine Reihe von Änderungssätzen als Patchbomb zu versenden.

Sie können auch entweder die Methodenoption im E-Mail-Bereich als sendmail konfigurieren
kompatiblen Mailer oder füllen Sie den Abschnitt [smtp] aus, damit die Patchbomb-Erweiterung verwendet werden kann
automatisch Patchbomben direkt von der Kommandozeile senden. Siehe [email] und [smtp]
Abschnitte in hgrc(5) für Details.

Standardmäßig hg E-Mail wird nach a fragen Zu or CC Kopfzeile, wenn Sie keine über angeben
Konfiguration oder die Kommandozeile. Sie können dies durch Konfigurieren außer Kraft setzen, sodass nie eine Eingabeaufforderung angezeigt wird
ein leerer Wert:

[Email]
cc =

Sie können die standardmäßige Einbeziehung einer Einführungsnachricht mit steuern patchbomb.intro
Konfigurationsmöglichkeit. Die Konfiguration wird immer durch Kommandozeilen-Flags wie überschrieben
--intro und --desc:

[Patchbombe]
intro=auto # Einführungsnachricht einfügen, wenn mehr als 1 Patch vorhanden ist (Standard)
intro=never # niemals eine Einführungsnachricht einfügen
intro=always # Immer eine Einführungsnachricht enthalten

Sie können Patchbomb so einstellen, dass Sie immer nach einer Bestätigung fragen, indem Sie die Einstellung vornehmen patchbomb.confirm zu wahr.

Befehle
E-Mail
Änderungssätze per E-Mail senden:

hg E-Mail [OPTION]... [ZIEL]...

Standardmäßig werden Diffs in dem Format gesendet, das von generiert wurde hg exportieren, eine pro Nachricht. Das
Die Serie beginnt mit einer „[PATCH 0 von N]“-Einleitung, die die Serie als Ganzes beschreibt.

Jede Patch-E-Mail hat eine Betreffzeile von „[PATCH M of N] …“, wobei die erste Zeile der verwendet wird
Changeset-Beschreibung als Betrefftext. Die Nachricht besteht aus zwei oder drei Teilen.
Zuerst die Changeset-Beschreibung.

Mit der Option -d/--diffstat wird, wenn das diffstat-Programm installiert ist, das Ergebnis der Ausführung
diffstat auf dem Patch wird eingefügt.

Schließlich der Patch selbst, wie er von generiert wird hg exportieren.

Mit den Optionen -d/--diffstat oder --confirm erhalten Sie eine abschließende Zusammenfassung von
alle Nachrichten und bat um Bestätigung, bevor die Nachrichten gesendet werden.

Standardmäßig wird der Patch zur einfachen Überprüfung als Text in den E-Mail-Text eingefügt. Verwendung der
Die Option -a/--attach erstellt stattdessen einen Anhang für den Patch. Mit -i/--inline an
Inline-Anhang wird erstellt. Sie können einen Patch sowohl als Text in den E-Mail-Text einfügen
und als regulärer oder Inline-Anhang durch Kombinieren von -a/--attach oder -i/--inline with
die Option --body.

Mit -o/--outgoing werden E-Mails für Patches generiert, die nicht im Ziel gefunden werden
Repository (oder nur diejenigen, die Vorfahren der angegebenen Revisionen sind, falls vorhanden
bereitgestellt)

Mit -b/--bundle werden Changesets wie bei --outgoing ausgewählt, enthalten aber eine einzelne E-Mail
Es wird ein binäres Mercurial-Bundle als Anhang gesendet. Verwenden Sie die patchbomb.bundletype
config-Option, um den Bündeltyp wie bei zu steuern hg bündeln --Typ.

Mit -m/--mbox, anstatt jede Patchbomb-Nachricht in einem Pager in der Vorschau anzuzeigen oder die
Nachrichten direkt, wird eine UNIX-Postfachdatei mit den Patch-E-Mails erstellt. Dieses Postfach
Die Datei kann mit jedem E-Mail-Benutzeragenten, der UNIX-mbox-Dateien unterstützt, in der Vorschau angezeigt werden.

Mit -n/--test werden alle Schritte ausgeführt, aber keine E-Mail gesendet. Sie werden dazu aufgefordert
eine E-Mail-Empfängeradresse, einen Betreff und eine einleitende Nachricht, die die Patches beschreibt
deiner Patchbombe. Wenn alles fertig ist, werden Patchbomb-Meldungen angezeigt. Wenn der Pager
Umgebungsvariable gesetzt ist, wird Ihr Pager einmal für jede Patchbomb-Nachricht gestartet,
damit Sie überprüfen können, ob alles in Ordnung ist.

Falls der E-Mail-Versand fehlschlägt, finden Sie eine Sicherungskopie Ihrer Serieneinführungsnachricht in
.hg/letzte-e-mail.txt.

Das Standardverhalten dieses Befehls kann durch Konfiguration angepasst werden. (Sehen hg Hilfe
Patchbombe für Details)

Beispiele:

hg email -r 3000 # Nur Patch 3000 senden
hg email -r 3000 -r 3001 # Patches 3000 und 3001 senden
hg email -r 3000:3005 # Patches 3000 bis 3005 senden
hg email 3000 # Patch 3000 senden (veraltet)

hg email -o # alle nicht standardmäßigen Patches senden
hg email -o DEST # alle Patches senden, die nicht in DEST sind
hg email -o -r 3000 # sende alle Vorfahren von 3000 nicht im Default
hg email -o -r 3000 DEST # sende alle Vorfahren von 3000 nicht in DEST

hg email -b # Paket aller nicht standardmäßigen Patches senden
hg email -b DEST # Bündel aller Patches senden, die nicht in DEST sind
hg email -b -r 3000 # Bündel aller Vorfahren von 3000 nicht im Standard
hg email -b -r 3000 DEST # Bündel aller Vorfahren von 3000 nicht in DEST

hg email -o -m mbox && # eine mbox-Datei generieren...
mutt -R -f mbox # ... und mit Mutt anzeigen
hg email -o -m mbox && # eine mbox-Datei erzeugen ...
formail -s sendmail \ # ... und verwenden Sie formail, um von der mbox zu senden
-bm -t < mbox # ... mit sendmail

Bevor Sie diesen Befehl verwenden, müssen Sie E-Mail in Ihrem hgrc aktivieren. Siehe die [E-Mail]
Abschnitt in hgrc(5) für Details.

Zubehör:

-G, --git
Verwenden Sie das erweiterte Diff-Format von Git

--schlicht
hg-Patch-Header weglassen

-Ö, - ausgehend
Änderungen senden, die nicht im Ziel-Repository gefunden wurden

-B, --bündeln
Änderungen nicht im Ziel als Binärpaket senden

--bundlename
Name der Bundle-Anhangsdatei (Standard: Bundle)

-R,--rev
eine Überarbeitung zu senden

--Macht
auch ausführen, wenn das entfernte Repository nicht verwandt ist (mit -b/--bundle)

--Base
ein Basis-Änderungssatz, der anstelle eines Ziels angegeben werden soll (mit -b/--bundle)

--Einführung
Senden Sie eine Einführungs-E-Mail für einen einzelnen Patch

--Körper Patches als Inline-Nachrichtentext senden (Standard)

-a, --anfügen
Patches als Anhang senden

-ich, --im Einklang
Senden Sie Patches als Inline-Anhänge

--bcc
E-Mail-Adressen von Empfängern von Blindkopien

-C,--cc
E-Mail-Adressen der Kopienempfänger

--bestätigen Sie
vor dem Absenden um Bestätigung bitten

-D, --diffstat
Diffstat-Ausgabe zu Nachrichten hinzufügen

--Datum
Verwenden Sie das angegebene Datum als Sendedatum

--beschr
Verwenden Sie die angegebene Datei als Serienbeschreibung

-F,--aus
E-Mail-Adresse des Absenders

-nicht, --Prüfung
Drucken Sie Nachrichten, die gesendet werden würden

-M,--mbox
Schreiben Sie Nachrichten in die mbox-Datei, anstatt sie zu senden

--Antwort an
E-Mail-Adressen, an die Antworten gesendet werden sollen

-S,--Gegenstand
Betreff der ersten Nachricht (Intro oder Einzelpatch)

--als Antwort auf
Nachrichtenkennung, auf die geantwortet werden soll

--Flagge
Flags zum Hinzufügen in Betreffpräfixen

-T,--zu
E-Mail-Adressen der Empfänger

-e,--ssh
Geben Sie den zu verwendenden ssh-Befehl an

--remotecmd
Geben Sie den hg-Befehl an, der auf der Remote-Seite ausgeführt werden soll

--unsicher
Serverzertifikat nicht überprüfen (web.cacerts config ignorieren)

[+] markierte Option kann mehrfach angegeben werden

Säuberung
Befehl zum Löschen nicht verfolgter Dateien aus dem Arbeitsverzeichnis

Befehle
Säuberung
entfernt Dateien, die nicht von Mercurial verfolgt werden:

hg löschen [OPTION]... [DIR]...

Löschen Sie Dateien, die Mercurial nicht bekannt sind. Dies ist nützlich, um lokale und nicht festgeschriebene Änderungen zu testen
in einem ansonsten sauberen Quellbaum.

Dies bedeutet, dass purge standardmäßig Folgendes löscht:

· Unbekannte Dateien: Dateien, die mit "?" durch hg Status

· Leere Verzeichnisse: Tatsächlich ignoriert Mercurial Verzeichnisse, es sei denn, sie enthalten Dateien darunter
Verwaltung der Quellcodeverwaltung

Aber es bleibt unberührt:

· Geänderte und unveränderte verfolgte Akten

· Ignorierte Dateien (sofern nicht --all angegeben ist)

· Neue Dateien zum Repository hinzugefügt (mit hg hinzufügen)

Die Optionen --files und --dirs können verwendet werden, um die Bereinigung so zu steuern, dass nur Dateien gelöscht werden
Verzeichnisse oder beides. Wenn keine Option angegeben ist, werden beide gelöscht.

Wenn Verzeichnisse auf der Kommandozeile angegeben werden, werden nur Dateien in diesen Verzeichnissen angegeben
in Betracht gezogen.

Seien Sie vorsichtig mit dem Löschen, da Sie einige Dateien, die Sie vergessen haben, zu ergänzen, unwiderruflich löschen könnten
das Depot. Wenn Sie nur die Liste der Dateien drucken möchten, die dieses Programm verwenden würde
löschen, verwenden Sie die Option --print.

Zubehör:

-a, --abort-on-err
abbrechen, wenn ein Fehler auftritt

--alle auch ignorierte Dateien löschen

--dir leere Verzeichnisse löschen

--Dateien
Dateien löschen

-P, --drucken
Dateinamen drucken, anstatt sie zu löschen

-0, --print0
Beenden Sie Dateinamen mit NUL, zur Verwendung mit xargs (impliziert -p/--print)

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

Aliase: sauber

zurückweisen
Befehl zum Verschieben von Revisionssätzen auf einen anderen Vorfahren

Mit dieser Erweiterung können Sie Changesets in einem bestehenden Mercurial-Repository rebasen.

Weitere Informationen: https://mercurial-scm.org/wiki/RebaseExtension

Befehle
zurückweisen
Changeset (und Nachkommen) in einen anderen Zweig verschieben:

hg-Rebase [-s REV | -b REV] [-d REV] [OPTION]

Rebase verwendet wiederholtes Zusammenführen, um Änderungssätze aus einem Teil des Verlaufs (der Quelle) zu übertragen.
auf ein anderes (das Ziel). Dies kann für die Linearisierung nützlich sein aus einer regionalen ändert sich relativ
zu einem Master-Entwicklungsbaum.

Veröffentlichte Commits können nicht rebasiert werden (siehe hg Hilfe Phasen). Um Commits zu kopieren, siehe hg Hilfe
Graft.

Wenn Sie kein Ziel-Changeset angeben (-d/--dest), verwendet rebase den aktuellen Zweig
Tipp als Ziel. (Der Ziel-Änderungssatz wird durch das Rebasing nicht geändert, sondern neu
Änderungssätze werden als Nachkommen hinzugefügt.)

So wählen Sie Änderungssätze aus:

1. Wählen Sie sie explizit mit aus --rev.

2. Benutzen --Quelle , um ein Root-Änderungsset auszuwählen und alle seine Nachkommen einzubeziehen.

3. Benutzen --Base um einen Änderungssatz auszuwählen; rebase findet Vorfahren und deren Nachkommen
die nicht auch Vorfahren des Ziels sind.

4. Wenn Sie keine von angeben --rev, Quelle, oder --Base, rebase wird verwendet --Base . as
zu teilen.

Rebase wird ursprüngliche Änderungssätze zerstören, es sei denn, Sie verwenden --halten. Es wird auch Sie bewegen
Lesezeichen (selbst wenn Sie dies tun).

Einige Änderungssätze können gelöscht werden, wenn sie keine Änderungen beitragen (z. B. Zusammenführungen aus der
Zielfiliale).

Im Gegensatz zu fusionieren, rebase wird nichts tun, wenn Sie sich an der Zweigspitze eines benannten Zweigs mit befinden
zwei Köpfe. Sie müssen Quelle und/oder Ziel explizit angeben.

Wenn ein Rebase unterbrochen wird, um einen Konflikt manuell zu lösen, kann es fortgesetzt werden
--continue/-c oder mit --abort/-a abgebrochen.

Beispiele:

· "lokale Änderungen" (aktueller Commit zurück zum Verzweigungspunkt) zur aktuellen Verzweigungsspitze verschieben
nach einem Zug:

hg rebase

· ein einzelnes Changeset in den Stable-Zweig verschieben:

hg rebase -r 5f493448 -d stabil

· einen Commit und alle seine Nachkommen in einen anderen Teil der Historie einfügen:

hg rebase --source c0c3 --dest 4cf9

· Rebase alles auf einem Zweig, der durch ein Lesezeichen markiert ist, auf den Standardzweig:

hg rebase --base myfeature --dest Standard

· eine Folge von Änderungen zu einem einzigen Commit zusammenfassen:

hg rebase --collapse -r 1520:1525 -d .

· Verschieben eines benannten Zweigs unter Beibehaltung seines Namens:

hg rebase -r "branch(featureX)" -d 1.3 --keepbranches

Gibt bei Erfolg 0 zurück, 1, wenn es nichts zu rebasen gibt oder es ungelöste Konflikte gibt.

Zubehör:

-S,--Quelle
rebase das angegebene Changeset und die Nachkommen

-B,--Base
rebasieren Sie alles vom Verzweigungspunkt des angegebenen Änderungssatzes

-R,--rev
rebasieren Sie diese Revisionen

-D,- Ziel
Rebase auf den angegebenen Changeset

--Zusammenbruch
reduzieren Sie die rebasierten Änderungssätze

-M,--Botschaft
Verwenden Sie Text als Commit-Nachricht zum Einklappen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

- l,--Logdatei
Lesen Sie die Commit-Nachricht zum Zusammenbruch aus der Datei

-k, --halten
ursprüngliche Änderungssätze beibehalten

--keepbranches
Behalten Sie die ursprünglichen Zweignamen bei

-D, --ablösen
(VERALTET)

-ich, --interaktiv
(VERALTET)

-T,--Werkzeug
Zusammenführungswerkzeug angeben

-C, --fortsetzen
Setzen Sie eine unterbrochene Rebase fort

-a, --abbrechen
einen unterbrochenen Rebase abbrechen

--Stil
Anzeige mit Vorlagenzuordnungsdatei (VERALTET)

-T,--Vorlage
Anzeige mit Vorlage

[+] markierte Option kann mehrfach angegeben werden

Rekord
Befehle zum interaktiven Auswählen von Änderungen für Commit/qrefresh

Befehle
qrecord
interaktiv einen neuen Patch aufzeichnen:

hg qrecord [OPTION]... PATCH [DATEI]...

See hg Hilfe neu & hg Hilfe Rekord für weitere Informationen und Nutzung.

Rekord
interaktiv Änderungen auswählen, die übernommen werden sollen:

hg record [OPTION]... [DATEI]...

Wenn eine Liste von Dateien weggelassen wird, werden alle Änderungen gemeldet von hg Status werden Kandidaten für sein
Aufzeichnung.

See hg Hilfe Datteln für eine Liste der Formate, die für -d/--date gültig sind.

Sie werden gefragt, ob Änderungen an jeder geänderten Datei und für Dateien aufgezeichnet werden sollen
mit mehreren Änderungen, für jede Änderung zu verwenden. Für jede Abfrage sind die folgenden Antworten
möglich:

y - Diese Änderung aufzeichnen
n - diese Änderung überspringen
e - Bearbeiten Sie diese Änderung manuell

s - verbleibende Änderungen an dieser Datei überspringen
f - Verbleibende Änderungen an dieser Datei aufzeichnen

d - fertig, verbleibende Änderungen und Dateien überspringen
a - Alle Änderungen an allen verbleibenden Dateien aufzeichnen
q - beenden, keine Änderungen aufzeichnen

? - Hilfe anzeigen

Dieser Befehl ist beim Festschreiben einer Zusammenführung nicht verfügbar.

Zubehör:

-EIN, --addremove
Markiere neue/fehlende Dateien als hinzugefügt/entfernt, bevor du sie festlegst

--Zweig schließen
einen Zweigkopf als geschlossen markieren

--ändern
das übergeordnete Element des Arbeitsverzeichnisses ändern

-S, --Geheimnis
Nutze die geheime Phase zum Begehen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

-M,--Botschaft
Text als Commit-Nachricht verwenden

- l,--Logdatei
Commit-Nachricht aus Datei lesen

-D,--Datum
das angegebene Datum als Commit-Datum aufzeichnen

-du,--Benutzer
den angegebenen Benutzer als Committer aufnehmen

-S, --subrepos
Rekurs in Unterverzeichnisse

-w, --ignore-all-space
ignoriere Leerzeichen beim Vergleichen von Zeilen

-B, --ignore-space-change
Ignorieren Sie Änderungen in der Menge des Leerraums

-B, --leerzeilen ignorieren
Ignoriere Änderungen, deren Zeilen alle leer sind

[+] markierte Option kann mehrfach angegeben werden

neu verlinken
stellt Hardlinks zwischen Repository-Klonen wieder her

Befehle
neu verlinken
Erstellen Sie Hardlinks zwischen zwei Repositories neu:

hg relink [URSPRUNG]

Wenn Repositorys lokal geklont werden, werden ihre Datendateien fest verknüpft, sodass sie
Verwenden Sie nur den Speicherplatz eines einzelnen Repositorys.

Leider werden bei nachfolgenden Pulls in beide Repositorys Hardlinks für alle Dateien unterbrochen
von den neuen Änderungssätzen berührt, auch wenn beide Repositories am Ende die gleichen Änderungen abrufen.

Ebenso werden beim Übergeben von --rev an "hg clone" keine Hardlinks verwendet, sondern es wird auf a zurückgegriffen
vollständige Kopie des Quell-Repositorys.

Mit diesem Befehl können Sie diese Hardlinks neu erstellen und diesen verschwendeten Speicherplatz zurückgewinnen.

Dieses Repository wird neu verknüpft, um den Speicherplatz mit ORIGIN zu teilen, das sich auf demselben befinden muss
lokale Festplatte. Wenn ORIGIN weggelassen wird, wird in [Pfade] nach „default-relink“ und dann nach „default“ gesucht.

Versuchen Sie keine Leseoperationen für dieses Repository, während der Befehl ausgeführt wird. (Beide
Repositories werden gegen Schreibvorgänge gesperrt.)

Regelungen
Schemas mit Verknüpfungen zu Repository-Schwärmen erweitern

Mit dieser Erweiterung können Sie Verknüpfungen für übergeordnete URLs mit vielen Repositorys angeben
sich wie ein Schema verhalten, zum Beispiel:

[Schemata]
py = http://code.python.org/hg/

Danach können Sie es wie folgt verwenden:

hg Klon py://trunk/

Zusätzlich gibt es Unterstützung für einige komplexere Schemas, die beispielsweise von Google verwendet werden
Code:

[Schemata]
gcode = http://{1}.googlecode.com/hg/

Die Syntax stammt aus Mercurial-Vorlagen, und Sie haben eine unbegrenzte Anzahl von Variablen.
beginnen mit 1 {} und weiter mit 2 {}, 3 {} usw. Diese Variablen erhalten
Teile der gelieferten URL, geteilt durch /. Alles, was nicht als angegeben ist {Teil} wird einfach angehängt
zu einer URL.

Der Einfachheit halber fügt die Erweiterung standardmäßig diese Schemata hinzu:

[Schemata]
py = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://[E-Mail geschützt] /
gcode = https://{1}.googlecode.com/hg/
Brennofen = https://{1}.kilnhg.com/Repo/

Sie können ein vordefiniertes Schema überschreiben, indem Sie ein neues Schema mit demselben Namen definieren.

Teilen
teilen eine gemeinsame Geschichte zwischen mehreren Arbeitsverzeichnissen

automatische Gepoolt Lagerung für Klone
Wenn diese Erweiterung aktiv ist, hg klonen kann so konfiguriert werden, dass es automatisch geteilt/poolt
Speicherung über mehrere Klone hinweg. Dieser Modus konvertiert effektiv hg klonen zu hg klonen + hg
Teilen. Der Vorteil bei der Verwendung dieses Modus ist die automatische Verwaltung von Speicherpfaden und
Intelligentes Poolen verwandter Repositories.

Folgende Aktien. Konfigurationsoptionen beeinflussen diese Funktion:

teilen.pool

Dateisystempfad, in dem gemeinsam genutzte Repository-Daten gespeichert werden. Wenn definiert, hg klonen
verwendet automatisch den gemeinsam genutzten Repository-Speicher, anstatt einen internen Speicher zu erstellen
jeder Klon.

share.poolbenennung

Wie Verzeichnisnamen in teilen.pool konstruiert sind.

„Identität“ bedeutet, dass der Name von der ersten Änderungsmenge im Repository abgeleitet wird. Im
In diesem Modus teilen sich verschiedene Remotes den Speicher, wenn ihr Root-/Anfangs-Changeset ist
identisch. In diesem Modus ist das lokale gemeinsam genutzte Repository ein Aggregat aller
gefundene Remote-Repositories.

„remote“ bedeutet, dass der Name vom Pfad oder der URL des Quell-Repositorys abgeleitet wird. Im
In diesem Modus wird der Speicher nur freigegeben, wenn der Pfad oder die URL in der angeforderten hg klonen
Der Befehl stimmt genau mit einem zuvor geklonten Repository überein.

Der Standard-Benennungsmodus ist „Identität“.

Befehle
Teilen
Erstellen Sie ein neues gemeinsames Repository:

hg teilen [-U] [-B] QUELLE [DEST]

Initialisieren Sie ein neues Repository und Arbeitsverzeichnis, das seinen Verlauf (und optional
Lesezeichen) mit einem anderen Repository.

Beachten Sie die Verwendung von Rollback oder Erweiterungen, die den Verlauf (mq, rebase usw.) zerstören/modifizieren können
erhebliche Verwirrung mit gemeinsam genutzten Klonen verursachen. Insbesondere, wenn zwei geteilt werden
Klone werden beide auf denselben Änderungssatz aktualisiert, und einer von ihnen zerstört diesen
changeset mit Rollback, der andere Klon hört plötzlich auf zu arbeiten: alle Operationen
schlägt mit "abort: working directory has unknown parent" fehl. Die einzige bekannte
Die Problemumgehung besteht darin, debugsetparents für den defekten Klon zu verwenden, um ihn auf einen Änderungssatz zurückzusetzen
das gibt es noch.

Zubehör:

-U, --kein Update
Erstellen Sie kein Arbeitsverzeichnis

-B, --Lesezeichen
auch Lesezeichen teilen

aufheben
Konvertieren Sie ein gemeinsam genutztes Repository in ein normales:

hg nicht teilen

Kopieren Sie die Store-Daten in das Repository und entfernen Sie die Sharedpath-Daten.

zurückstellen
Änderungen im Arbeitsverzeichnis speichern und wiederherstellen

Der Befehl "hg shelve" speichert Änderungen, die am Arbeitsverzeichnis vorgenommen wurden, und macht diese rückgängig
Änderungen, Zurücksetzen des Arbeitsverzeichnisses auf einen sauberen Zustand.

Später stellt der Befehl "hg unshelve" die von "hg shelve" gespeicherten Änderungen wieder her. Änderungen können
auch nach der Aktualisierung auf einen anderen Elternteil wiederhergestellt werden, in diesem Fall Mercurials Mercurial
Maschinen werden Konflikte bei Bedarf lösen.

Sie können mehr als ein ausstehendes Wechselgeld gleichzeitig haben; jede zurückgestellte Änderung hat eine
eindeutiger Name. Einzelheiten finden Sie in der Hilfe zu „hg Regal“.

Befehle
zurückstellen
Änderungen aus dem Arbeitsverzeichnis speichern und beiseite legen:

hg Regal [OPTION]... [DATEI]...

Shelving nimmt Dateien, die "hg status" als nicht sauber meldet, speichert die Änderungen in a
Bundle (eine zurückgestellte Änderung) und stellt die Dateien wieder her, so dass ihr Zustand in der Arbeit ist
Verzeichnis wird sauber.

Um diese Änderungen im Arbeitsverzeichnis wiederherzustellen, verwenden Sie "hg unshelve"; das wird funktionieren
auch wenn Sie zu einem anderen Commit wechseln.

Wenn keine Dateien angegeben sind, speichert "hg shelve" alle nicht sauberen Dateien. Wenn bestimmte Dateien bzw
Verzeichnisse benannt sind, werden nur Änderungen an diesen Dateien zurückgestellt.

Jede zurückgestellte Änderung hat einen Namen, der das spätere Auffinden erleichtert. Der Name eines Regals
Ändern Sie die Standardeinstellungen so, dass sie auf dem aktiven Lesezeichen basieren, oder wenn kein aktives Lesezeichen vorhanden ist.
der aktuell benannte Zweig. Um einen anderen Namen anzugeben, verwenden Sie --Name.

Um eine Liste vorhandener zurückgestellter Änderungen anzuzeigen, verwenden Sie die --aufführen Möglichkeit. Für jede zurückgestellte Änderung,
Dadurch werden Name, Alter und Beschreibung gedruckt. verwenden - Patch or -stat für weitere Informationen an.

Um bestimmte zurückgestellte Änderungen zu löschen, verwenden Sie --löschen. Um alle zurückgestellten Änderungen zu löschen, verwenden Sie
--Aufräumen.

Zubehör:

-EIN, --addremove
Markieren Sie neue/fehlende Dateien als hinzugefügt/entfernt, bevor Sie sie zurückstellen

-du, --Unbekannt
Unbekannte Dateien im Regal ablegen

--Aufräumen
alle zurückgestellten Änderungen löschen

--Datum
mit dem angegebenen Commit-Datum einlagern

-D, --löschen
Löschen Sie die benannte(n) zurückgestellte(n) Änderung(en)

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

- l, --aufführen
aktuelle Regale auflisten

-M,--Botschaft
Text als Shelf-Meldung verwenden

-nicht,--Name
Verwenden Sie den angegebenen Namen für das zurückgestellte Commit

-P, - Patch
Patch anzeigen

-ich, --interaktiv
Interaktiver Modus, funktioniert nur beim Erstellen eines Regals

-stat Zusammenfassung der Änderungen im Diffstat-Stil ausgeben

-ICH,--enthalten
Fügen Sie Namen ein, die den angegebenen Mustern entsprechen

-X,--ausschließen
Namen ausschließen, die den angegebenen Mustern entsprechen

[+] markierte Option kann mehrfach angegeben werden

aus dem Regal nehmen
Stellen Sie eine abgelegte Änderung im Arbeitsverzeichnis wieder her:

hg aus dem Regal

Dieser Befehl akzeptiert einen optionalen Namen einer zurückgestellten Änderung, die wiederhergestellt werden soll. Wenn keine angegeben ist,
die letzte zurückgestellte Änderung wird verwendet.

Wenn eine zurückgestellte Änderung erfolgreich angewendet wird, wird das Bundle, das die zurückgestellten Änderungen enthält
an einen Backup-Speicherort verschoben wird (.hg/shelve-backup).

Da Sie eine zurückgestellte Änderung zusätzlich zu einem beliebigen Commit wiederherstellen können, ist dies möglich
Unshelving führt zu einem Konflikt zwischen Ihren Änderungen und den Commits, die Sie sind
Unregal auf. In diesem Fall müssen Sie den Konflikt lösen und dann verwenden --fortsetzen zu
Schließen Sie den Unshelf-Vorgang ab. (Das Bündel wird erst verschoben, wenn Sie erfolgreich sind
vervollständigen Sie das Unregal.)

(Alternativ können Sie auch verwenden --abbrechen ein Unregal aufgeben, das einen Konflikt verursacht. Dies
macht die nicht zurückgestellten Änderungen rückgängig und lässt das Bundle an Ort und Stelle.)

Nach einem erfolgreichen Unsheve werden die abgelegten Änderungen in einem Backup-Verzeichnis gespeichert. Nur
die N neusten Sicherungen werden aufbewahrt. N ist standardmäßig 10, kann aber mit überschrieben werden
shelve.maxbackups Konfigurationsoption.

Der Zeitstempel in Sekunden wird verwendet, um die Reihenfolge der Sicherungen festzulegen. Mehr als maximale Backups Sicherungen sind
aus Sicherheitsgründen beibehalten, wenn der gleiche Zeitstempel verhindert, dass die genaue Reihenfolge bestimmt wird.

Zubehör:

-a, --abbrechen
einen unvollständigen Unshelf-Vorgang abbrechen

-C, --fortsetzen
einen unvollständigen Unshelf-Vorgang fortsetzen

-k, --halten
nach dem Auspacken ins Regal stellen

-T,--Werkzeug
Zusammenführungswerkzeug angeben

--Datum
Datum für temporäre Festschreibungen festlegen (VERALTET)

abstreifen
Changesets und ihre Nachkommen aus der Geschichte entfernen

Mit dieser Erweiterung können Sie Changesets und alle ihre Nachkommen aus der entfernen
Repository. Einzelheiten finden Sie in der Befehlshilfe.

Befehle
abstreifen
Entfernen Sie Changesets und alle ihre Nachkommen aus dem Repository:

hg strip [-k] [-f] [-B Lesezeichen] [-r] REV...

Der Strip-Befehl entfernt die angegebenen Changesets und alle ihre Nachkommen. Wenn die
Arbeitsverzeichnis nicht festgeschriebene Änderungen enthält, wird der Vorgang abgebrochen, es sei denn, die Datei --force
Flag geliefert wird, in diesem Fall werden Änderungen verworfen.

Wenn ein übergeordnetes Element des Arbeitsverzeichnisses entfernt wird, wird das Arbeitsverzeichnis entfernt
automatisch auf den neuesten verfügbaren Vorfahren des entfernten Elternteils aktualisiert
nach Abschluss der Operation.

Alle entfernten Änderungssätze werden in gespeichert .hg/strip-backup als Bündel (vgl hg Hilfe bündeln und
hg Hilfe aufschlüsseln). Sie können durch Ausführen wiederhergestellt werden hg aufschlüsseln .hg/strip-backup/BUNDLE,
wobei BUNDLE die vom Strip erstellte Bundle-Datei ist. Beachten Sie die lokalen Revisionsnummern
wird im Allgemeinen nach der Wiederherstellung anders sein.

Verwenden Sie die Option --no-backup, um das Sicherungspaket zu verwerfen, sobald der Vorgang abgeschlossen ist.

Strip ist kein Vorgang zum Umschreiben des Verlaufs und kann für Changesets in der Öffentlichkeit verwendet werden
Phase. Wenn die entfernten Änderungssätze jedoch in ein Remote-Repository verschoben wurden, werden Sie dies tun
wahrscheinlich ziehen sie wieder.

Bei Erfolg 0 zurückgeben.

Zubehör:

-R,--rev
Angegebene Revision entfernen (optional, kann Revisionen ohne diese Option angeben)

-F, --Macht
Entfernen von Änderungssätzen erzwingen, nicht festgeschriebene Änderungen verwerfen (kein Backup)

--keine Sicherung
keine Sicherungen

--keine Sicherung
keine Backups (VERALTET)

-n ignoriert (VERALTET)

-k, --halten
Ändern Sie das Arbeitsverzeichnis während des Strips nicht

-B,--Lesezeichen
Drehzahlen entfernen, die nur über das angegebene Lesezeichen erreichbar sind

[+] markierte Option kann mehrfach angegeben werden

Transplantation
Befehl zum Transplantieren von Changesets von einem anderen Zweig

Mit dieser Erweiterung können Sie Änderungen in eine andere übergeordnete Revision übertragen, möglicherweise in
ein anderes Depot. Die Transplantation erfolgt mit „Diff“-Patches.

Transplantierte Patches werden in .hg/transplant/transplants als Karte aus einem Änderungssatz aufgezeichnet
Hash zu seinem Hash im Quell-Repository.

Befehle
Transplantation
Änderungssätze aus einem anderen Zweig übertragen:

hg Transplantation [-s REPO] [-b ZWEIG [-a]] [-p REV] [-m REV] [REV]...

Ausgewählte Änderungssätze werden auf das aktuelle Arbeitsverzeichnis mit dem Protokoll angewendet
des ursprünglichen Änderungssatzes. Die Änderungssätze werden kopiert und erscheinen daher zweimal in der
Geschichte mit unterschiedlichen Identitäten.

Erwägen Sie die Verwendung des Befehls graft, wenn sich alles im selben Repository befindet - es wird verwendet
verschmilzt und liefert normalerweise ein besseres Ergebnis. Verwenden Sie die Rebase-Erweiterung, wenn die changesets
unveröffentlicht sind und Sie sie verschieben möchten, anstatt sie zu kopieren.

Wenn --log angegeben ist, wird an Protokollnachrichten ein Kommentar in der Form angehängt:

(transplantiert von CHANGESETHASH)

Sie können die Changelog-Nachricht mit der Option --filter umschreiben. Sein Argument wird sein
aufgerufen mit der aktuellen Changelog-Nachricht als $1 und dem Patch als $2.

--source/-s gibt ein anderes Repository an, das zum Auswählen von Änderungssätzen verwendet werden soll, so als ob es
vorübergehend gezogen worden. Wenn --branch/-b angegeben ist, werden diese Revisionen verwendet als
Köpfe bei der Entscheidung, welche Änderungssätze übertragen werden sollen, so als ob nur diese Überarbeitungen vorhanden wären
gezogen worden. Wenn --all/-a angegeben ist, alle Revisionen bis zu den mit angegebenen Überschriften
--Zweig wird verpflanzt.

Beispiel:

· Transplantieren Sie alle Änderungen bis REV auf Ihre aktuelle Revision:

hg transplant --Zweig REV --all

Sie können optional ausgewählte übertragene Änderungssätze als Zusammenführungs-Änderungssätze markieren. Du wirst nicht
Sie werden aufgefordert, alle Vorfahren einer zusammengeführten Transplantation zu transplantieren, und Sie können zusammenführen
Nachkommen von ihnen normalerweise, anstatt sie zu verpflanzen.

Merge-Änderungssätze können direkt übertragen werden, indem der richtige Eltern-Änderungssatz durch angegeben wird
Aufruf hg Transplantation --Elternteil.

Wenn keine Zusammenführungen oder Überarbeitungen bereitgestellt werden, hg Transplantation startet einen interaktiven Änderungssatz
Browser.

Wenn eine Changeset-Anwendung fehlschlägt, können Sie die Zusammenführung manuell reparieren und dann an der gewünschten Stelle fortfahren
habe mit dem Anrufen aufgehört hg Transplantation --continue/-c.

Zubehör:

-S,--Quelle
Transplantationsänderungssätze von REPO

-B,--Zweig
Verwenden Sie diesen Quell-Changeset als Head

-a, --alle
Ziehen Sie alle Änderungssätze bis zu den --branch-Revisionen

-P,--Pflaume
überspringen REV

-M,--verschmelzen
bei REV zusammenführen

--Elternteil
Eltern, die beim Umpflanzen zusammengeführt werden sollen

-e, --bearbeiten
Editor für Commit-Nachrichten aufrufen

--Protokoll Hängen Sie Transplantationsinformationen an die Protokollnachricht an

-C, --fortsetzen
Setzen Sie die letzte Transplantationssitzung fort, nachdem Konflikte behoben wurden

--Filter
Changesets per Befehl filtern

[+] markierte Option kann mehrfach angegeben werden

win32mbcs
erlauben die Verwendung von MBCS-Pfaden mit problematischen Codierungen

Einige MBCS-Kodierungen eignen sich nicht für bestimmte Pfadoperationen (z. B. Aufteilen von Pfaden, Groß- und Kleinschreibung).
Konvertierung usw.) mit seinen codierten Bytes. Wir nennen eine solche Kodierung (also „shift_jis“ und „
big5) als „problematische Kodierung“. Diese Erweiterung kann verwendet werden, um das Problem damit zu beheben
Codierungen durch Umschließen einiger Funktionen, die vor der Pfadoperation in einen Unicode-String konvertiert werden sollen.

Diese Erweiterung ist nützlich für:

· Japanische Windows-Benutzer verwenden die Shift_jis-Kodierung.

· Chinesische Windows-Benutzer verwenden die Big5-Kodierung.

· Alle Benutzer, die ein Repository mit einer problematischen Kodierung verwenden, bei der die Groß-/Kleinschreibung nicht beachtet wird
Dateisystem.

Diese Erweiterung wird nicht benötigt für:

· Jeder Benutzer, der im Pfad nur ASCII-Zeichen verwendet.

· Jeder Benutzer, der keine problematischen Kodierungen verwendet.

Beachten Sie, dass es bei der Verwendung dieser Erweiterung einige Einschränkungen gibt:

· Sie sollten eine einzelne Kodierung in einem Repository verwenden.

· Wenn der Repository-Pfad mit 0x5c endet, kann .hg/hgrc nicht gelesen werden.

· win32mbcs ist nicht mit der Erweiterung fixutf8 kompatibel.

Standardmäßig verwendet win32mbcs die von Mercurial festgelegte Kodierung.encoding. Sie können die angeben
Kodierung durch Konfigurationsoption:

[win32mbcs]
Kodierung = sjis

Dies ist nützlich für Benutzer, die ein Commit mit UTF-8-Protokollnachrichten durchführen möchten.

win32text
Automatische Zeilenumwandlung durchführen (VERALTET)

Veraltet: Die Win32text-Erweiterung erfordert, dass jeder Benutzer die Erweiterung konfiguriert
Dies muss bei jedem Klon immer wieder wiederholt werden, da die Konfiguration beim Klonen nicht kopiert wird.

Deshalb haben wir das gemacht eol als Alternative. Der eol verwendet eine versionierte Version
Datei für seine Konfiguration und jeder Klon verwendet daher die richtigen Einstellungen von
der Anfang.

Um eine automatische Zeilenumbruchkonvertierung durchzuführen, verwenden Sie:

[Erweiterungen]
win32text =
[kodieren]
** = cleverencode:
# oder ** = Macencode:

[dekodieren]
** = cleverdecode:
# oder ** = Macdecode:

Wenn Sie keine Konvertierung durchführen, stellen Sie sicher, dass Sie CRLF/CR nicht versehentlich festschreiben:

[Haken]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf
# oder pretxncommit.cr = python:hgext.win32text.forbidcr

Um die gleiche Prüfung auf einem Server durchzuführen, um zu verhindern, dass CRLF/CR gepusht oder gezogen wird:

[Haken]
pretxnchangegroup.crlf = python:hgext.win32text.forbidcrlf
# oder pretxnchangegroup.cr = python:hgext.win32text.forbidcr

zeroconf
Repositorys im lokalen Netzwerk entdecken und bewerben

Die Zeroconf-Erweiterung wird Werbung machen hg brauchen Instanzen über DNS-SD, damit sie sein können
entdeckt mit der hg Pfade Befehl ausführen, ohne die Adresse des Servers zu kennen.

Damit andere Personen Ihr Repository mithilfe von „run“ entdecken können hg brauchen in Ihrem Repository:

$ cd-Test
$ hg servieren

Sie können Zeroconf-fähige Repositorys entdecken, indem Sie ausführen hg Pfade:

$ hg Pfade
zc-test = http://example.com:8000/Test

Nutzen Sie hg online über die Dienste von onworks.net