Questo è il comando hg che può essere eseguito nel provider di hosting gratuito OnWorks utilizzando una delle nostre molteplici postazioni di lavoro online gratuite come Ubuntu Online, Fedora Online, emulatore online Windows o emulatore online MAC OS
PROGRAMMA:
NOME
hg - Sistema di gestione del codice sorgente Mercurial
SINOSSI
hg command [opzione]... [argomento] ...
DESCRIZIONE
I hg command fornisce un'interfaccia a riga di comando al sistema Mercurial.
COMANDO ELEMENTI
File...
indica uno o più nomi di file o relativi nomi di file di percorso; vedere Schemi di nomi di file
per informazioni sul pattern matching
sentiero indica un percorso sulla macchina locale
revisione
indica un insieme di modifiche che può essere specificato come numero di revisione dell'insieme di modifiche, tag,
o una sottostringa univoca del valore hash del changeset
deposito sentiero
il percorso di un repository locale o l'URI di un repository remoto.
VERSIONI
-R,--archivio
directory radice del repository o nome del file del pacchetto di sovrapposizione
--cwd
cambia directory di lavoro
-sì, --non interattivo
non chiedere, scegli automaticamente la prima scelta per tutte le richieste
-Q, --silenzioso
sopprimere l'uscita
-in, --verboso
abilitare l'uscita aggiuntiva
--config
set/override config option (usa 'section.name=value')
- debug
abilitare l'output di debug
--debugger
avvia il debugger
- codifica
imposta la codifica del set di caratteri (predefinito: UTF-8)
--modalità di codifica
imposta la modalità di codifica del set di caratteri (predefinito: strict)
--rintracciare
stampa sempre un traceback in caso di eccezione
--tempo tempo quanto tempo impiega il comando
--profilo
stampa il profilo di esecuzione del comando
--versione
mostra informazioni sulla versione ed esce
-H, --Aiuto
visualizza la guida ed esci
--nascosto
considera i changeset nascosti
[+] l'opzione contrassegnata può essere specificata più volte
COMANDI
aggiungere
aggiungi i file specificati al prossimo commit:
hg aggiungi [OPZIONE]... [FILE]...
Pianifica i file per essere controllati dalla versione e aggiunti al repository.
I file verranno aggiunti al repository al prossimo commit. Per annullare un'aggiunta precedente,
vedere hg dimenticare.
Se non viene fornito alcun nome, aggiungi tutti i file al repository (tranne i file corrispondenti .hgignora).
Consigli d'uso:
· I nuovi file (sconosciuti) vengono aggiunti automaticamente da hg aggiungere:
$ l
foo.c
$ hg stato
? foo.c
$ hg aggiungere
aggiungendo foo.c
$ hg stato
Un foo.c
· È possibile specificare file specifici da aggiungere:
$ l
bar.c pippo.c
$ hg stato
? bar.c
? foo.c
$ hg aggiungi bar.c
$ hg stato
Un bar.c
? foo.c
Restituisce 0 se tutti i file sono stati aggiunti con successo.
Opzioni:
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-S, --sottorepos
ricorrono in sottorepository
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
[+] l'opzione contrassegnata può essere specificata più volte
Aggiungi Rimuovi
aggiungi tutti i nuovi file, elimina tutti i file mancanti:
hg addremove [OPZIONE]... [FILE]...
Aggiungi tutti i nuovi file e rimuovi tutti i file mancanti dal repository.
A meno che non vengano dati nomi, i nuovi file vengono ignorati se corrispondono a uno dei modelli in
.hgignora. Come con add, queste modifiche hanno effetto al prossimo commit.
Utilizzare l'opzione -s/--similarity per rilevare i file rinominati. Questa opzione richiede una percentuale
tra 0 (disabilitato) e 100 (i file devono essere identici) come parametro. Con un parametro
maggiore di 0, confronta ogni file rimosso con ogni file aggiunto e registra quelli
abbastanza simili come rinomina. Rilevare file rinominati in questo modo può essere costoso. Dopo l'uso
questa opzione, hg status -C può essere utilizzato per verificare quali file sono stati identificati come spostati o
rinominato. Se non specificato, -s/--similarity è predefinito su 100 e solo rinomina di identico
vengono rilevati i file.
Consigli d'uso:
· Alcuni file (bar.c e foo.c) sono nuovi, mentre foobar.c è stato rimosso (senza
utilizzando hg rimuovere) dall'archivio:
$ l
bar.c pippo.c
$ hg stato
! foobar.c
? bar.c
? foo.c
$ hg addrimuovi
aggiungendo bar.c
aggiungendo foo.c
rimozione foobar.c
$ hg stato
Un bar.c
Un foo.c
R foobar.c
· Un file foobar.c è stato spostato in foo.c senza usarlo hg rinominare. In seguito, è stato
modificato leggermente:
$ l
foo.c
$ hg stato
! foobar.c
? foo.c
$ hg addremove --similarità 90
rimozione foobar.c
aggiungendo foo.c
registrazione rimozione di foobar.c come rinomina in foo.c (94% simile)
$ hg stato -C
Un foo.c
foobar.c
R foobar.c
Restituisce 0 se tutti i file sono stati aggiunti con successo.
Opzioni:
-S,--somiglianza
indovina i file rinominati per somiglianza (0<=s<=100)
-S, --sottorepos
ricorrono in sottorepository
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
[+] l'opzione contrassegnata può essere specificata più volte
annotare
mostra le informazioni del changeset per riga per ogni file:
hg annotate [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] FILE...
Elenca le modifiche nei file, mostrando l'ID di revisione responsabile per ogni riga.
Questo comando è utile per scoprire quando è stata apportata una modifica e da chi.
Se includi --file, --user o --date, il numero di revisione viene soppresso a meno che tu non sia
includi anche --number.
Senza l'opzione -a/--text, annotate eviterà di elaborare i file che rileva come binari.
Con -a, annotate annoterà comunque il file, anche se probabilmente i risultati saranno
né utile né desiderabile.
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
annota la revisione specificata
--Seguire
segui le copie/rinomina ed elenca il nome del file (DEPRECATO)
--non seguire
non seguire copie e rinomina
-un, --testo
tratta tutti i file come testo
-tu, --utente
elenca l'autore (lungo con -v)
-F, --file
elenca il nome del file
-D, --Data
elenca la data (in breve con -q)
-N, --numero
elenca il numero di revisione (predefinito)
-C, --changeset
elencare il changeset
-l, --numero-riga
mostra il numero di riga alla prima apparizione
-w, --ignora-tutto-spazio
ignora gli spazi bianchi quando confronti le righe
-B, --ignora-spazio-cambiamento
ignora i cambiamenti nella quantità di spazio bianco
-B, --ignora-linee-vuote
ignora le modifiche le cui righe sono tutte vuote
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-T,--modello
display con template (SPERIMENTALE)
[+] l'opzione contrassegnata può essere specificata più volte
alias: colpa
archiviare
creare un archivio senza versione di una revisione del repository:
hg archivio [OPZIONE]... DEST
Per impostazione predefinita, la revisione utilizzata è la madre della directory di lavoro; usa -r/--rev per
specificare una revisione diversa.
Il tipo di archivio viene rilevato automaticamente in base all'estensione del file (per sovrascrivere, utilizzare
-t/--tipo).
Consigli d'uso:
· creare un file zip contenente la versione 1.0:
hg archivio -r 1.0 progetto-1.0.zip
· creare un tarball escludendo i file .hg:
hg archivio progetto.tar.gz -X ".hg*"
I tipi validi sono:
file
una directory piena di file (impostazione predefinita)
tar
archivio tar, non compresso
tbz2
archivio tar, compresso con bzip2
tgz
archivio tar, compresso con gzip
uzip
archivio zip, non compresso
chiusura
zip, compresso con deflate
Il nome esatto dell'archivio o della directory di destinazione viene fornito utilizzando una stringa di formato; vedere
hg Aiuto export per i dettagli.
Ogni membro aggiunto a un file di archivio ha un prefisso di directory anteposto. Usa -p/--prefix per
specificare una stringa di formato per il prefisso. L'impostazione predefinita è il nome di base dell'archivio, con
suffissi rimossi.
Restituisce 0 in caso di successo.
Opzioni:
--no-decodifica
non passare i file attraverso i decoder
-P,--prefisso
prefisso della directory per i file nell'archivio
-R,--rev
revisione da distribuire
-T,--genere
tipo di distribuzione da creare
-S, --sottorepos
ricorrono in sottorepository
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
indietro
effetto inverso del precedente changeset:
hg backout [OPZIONE]... [-r] REV
Preparare un nuovo changeset con l'effetto di REV undone nella directory di lavoro corrente. Se
non sono stati riscontrati conflitti, verrà commesso immediatamente.
Se REV è il genitore della directory di lavoro, allora viene eseguito il commit di questo nuovo changeset
automaticamente (a meno che non sia specificato --no-commit).
Note: hg indietro non può essere utilizzato per correggere un'unione indesiderata o errata.
Consigli d'uso:
· Invertire l'effetto del genitore della directory di lavoro. Questo ritiro sarà
commesso immediatamente:
hg ritiro -r .
· Invertire l'effetto della precedente revisione errata 23:
hg backout -r 23
· Annullare l'effetto della precedente revisione errata 23 e lasciare le modifiche non salvate:
hg backout -r 23 --no-commit
hg commit -m "Annulla revisione 23"
Per impostazione predefinita, il changeset in sospeso avrà un genitore, mantenendo una cronologia lineare. Con
--merge, il changeset in sospeso avrà invece due genitori: il vecchio genitore del
directory di lavoro e un nuovo figlio di REV che annulla semplicemente REV.
Prima della versione 1.7, il comportamento senza --merge era equivalente a specificare --merge
seguito da hg update --pulire . annullare la fusione e lasciare a capo il figlio di REV
da unire separatamente.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
See hg Aiuto ritornare per un modo per ripristinare i file allo stato di un'altra revisione.
Restituisce 0 in caso di successo, 1 se non si esegue il backup o ci sono file non risolti.
Opzioni:
--unisci
fondersi con il vecchio genitore dirstate dopo il ritiro
--commettere
commit se non sono stati riscontrati conflitti (DEPRECATO)
--senza impegno
non impegnarti
--genitore
genitore da scegliere quando si esegue il backup dell'unione (DEPRECATO)
-R,--rev
revisione per ritirarsi
-e, --modificare
invoca l'editor sui messaggi di commit
-T,--attrezzo
specificare lo strumento di unione
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
[+] l'opzione contrassegnata può essere specificata più volte
bisecare
ricerca per suddivisione dei changeset:
hg biseca [-gbsr] [-U] [-c CMD] [REV]
Questo comando aiuta a trovare i changeset che introducono problemi. Per utilizzare, contrassegnare il primo
il changeset che conosci mostra il problema come grave, quindi contrassegna l'ultimo changeset che è
libero dal problema come buono. Bisect aggiornerà la tua directory di lavoro con una revisione per
testing (a meno che non sia specificata l'opzione -U/--noupdate). Dopo aver eseguito i test,
contrassegna la directory di lavoro come buona o cattiva e bisect si aggiornerà su un'altra
candidato changeset o annuncia di aver trovato la revisione errata.
Come scorciatoia, puoi anche usare l'argomento revisione per contrassegnare una revisione come buona o cattiva
senza verificarlo prima.
Se fornisci un comando, verrà utilizzato per la bisezione automatica. L'ambiente
la variabile HG_NODE conterrà l'ID del changeset da testare. Lo stato di uscita del
il comando verrà utilizzato per contrassegnare le revisioni come buone o cattive: lo stato 0 significa buono, 125 significa per
salta la revisione, 127 (comando non trovato) interromperà la bisezione e qualsiasi altra
uno stato di uscita diverso da zero indica che la revisione è errata.
Qualche esempio:
· iniziare una bisezione con nota cattiva revisione 34 e buona revisione 12:
hg bisect --cattiva 34
hg bisect --buono 12
· avanzare la bisezione corrente contrassegnando la revisione corrente come buona o cattiva:
hg bisect --buono
hg bisect --cattivo
· contrassegnare la revisione corrente, o una revisione nota, da saltare (ad es. se tale revisione è
non utilizzabile a causa di un altro problema):
hg bisect --salta
hg bisect --salta 23
· salta tutte le revisioni che non toccano le directory foo or bar:
hg bisect --skip "!( file('percorso:pippo') & file('percorso:bar') )"
· dimentica la bisezione attuale:
hg bisect --reset
· usa 'make && make test' per trovare automaticamente la prima revisione non funzionante:
hg bisect --reset
hg bisect --cattiva 34
hg bisect --buono 12
hg bisect --comando "crea && effettua test"
· vedere tutti i changeset i cui stati sono già noti nella bisezione corrente:
hg log -r "bisect(potato)"
· vedere il changeset attualmente diviso in due (particolarmente utile se si esegue con
-U/--nessun aggiornamento):
hg log -r "bisect(corrente)"
· vedere tutti i changeset che hanno preso parte alla bisezione attuale:
hg log -r "bisect(intervallo)"
· puoi anche ottenere un bel grafico:
hg log --graph -r "bisect(intervallo)"
See hg Aiuto revisioni per ulteriori informazioni sul bisecare() parola chiave.
Restituisce 0 in caso di successo.
Opzioni:
-R, --Ripristina
resettare lo stato di bisezione
-G, --Buona
segnare changeset buono
-B, --cattivo
contrassegnare il changeset come errato
-S, --Salta
salta il set di modifiche del test
-e, --estendere
estendere l'intervallo di bisezione
-C,--comando
usa il comando per controllare lo stato del changeset
-U, --nessun aggiornamento
non aggiornare al target
segnalibri
crea un nuovo segnalibro o elenca i segnalibri esistenti:
hg segnalibri [OPZIONI]... [NOME]...
I segnalibri sono etichette sui changeset per aiutare a tenere traccia delle linee di sviluppo. I segnalibri sono
unversioned e può essere spostato, rinominato ed eliminato. L'eliminazione o lo spostamento di un segnalibro non ha
effetto sui changeset associati.
La creazione o l'aggiornamento di un segnalibro fa sì che venga contrassegnato come "attivo". L'attivo
segnalibro è indicato con un '*'. Quando viene effettuato un commit, il segnalibro attivo avanzerà
al nuovo commit. Un piano hg update avanzerà anche un segnalibro attivo, se possibile.
L'aggiornamento da un segnalibro ne causerà la disattivazione.
I segnalibri possono essere spinti e tirati tra i repository (vedi hg Aiuto spingere ed hg Aiuto tirare
). Se un segnalibro condiviso è divergente, un nuovo 'segnalibro divergente' nella forma 'nome@percorso'
verrà creato. Usando hg unire risolverà la divergenza.
Un segnalibro denominato '@' ha la proprietà speciale che hg clonare lo controllerà per impostazione predefinita
se esiste.
Consigli d'uso:
· creare un segnalibro attivo per una nuova linea di sviluppo:
hg book nuova funzione
· creare un segnalibro inattivo come segnaposto:
hg book -i recensito
· creare un segnalibro inattivo su un altro changeset:
hg book -r .^ testato
· rinomina il segnalibro tacchino in cena:
hg book -m cena di tacchino
· sposta il segnalibro '@' da un altro ramo:
hg libro -f @
Opzioni:
-F, --vigore
forza
-R,--rev
revisione per l'azione del segnalibro
-D, --Elimina
eliminare un determinato segnalibro
-M,--rinominare
rinominare un determinato segnalibro
-io, --inattivo
contrassegnare un segnalibro come inattivo
-T,--modello
display con template (SPERIMENTALE)
alias: segnalibro
ramo
imposta o mostra il nome del ramo corrente:
hg branch [-fC] [NOME]
Nota I nomi dei rami sono permanenti e globali. Uso hg segnalibro per creare un peso leggero
segnalibro invece. Vedere hg Aiuto glossario per ulteriori informazioni sui rami denominati
e segnalibri.
Senza argomenti, mostra il nome del ramo corrente. Con un argomento, imposta il funzionamento
nome del ramo di directory (il ramo non esisterà nel repository fino al prossimo commit).
La pratica standard raccomanda che lo sviluppo primario avvenga sul ramo "predefinito".
A meno che non sia specificato -f/--force, branch non ti permetterà di impostare un nome di ramo che già
esiste.
Usa -C/--clean per reimpostare il ramo della directory di lavoro su quello del genitore del lavoro
directory, negando una precedente modifica del ramo.
Usa il comando hg update per passare a una filiale esistente. Uso hg commettere --chiudi-ramo a
contrassegna questa testa di ramo come chiusa. Quando tutti i capi di un ramo sono chiusi, il ramo sarà
considerarsi chiuso.
Restituisce 0 in caso di successo.
Opzioni:
-F, --vigore
imposta il nome del ramo anche se nasconde un ramo esistente
-C, --pulire
reimposta il nome del ramo sul nome del ramo principale
rami
elenca i rami del repository denominati:
hg rami [-c]
Elenca i rami denominati del repository, indicando quali sono inattivi. Se -c/--chiuso
è specificato, elenca anche i rami che sono stati contrassegnati come chiusi (vedi hg commettere
--chiudi-ramo).
Usa il comando hg update per passare a una filiale esistente.
Restituisce 0.
Opzioni:
-un, --attivo
mostra solo rami con teste non unite (DEPRECATO)
-C, --Chiuso
mostra rami normali e chiusi
-T,--modello
display con template (SPERIMENTALE)
fascio
creare un file changegroup:
hg bundle [-f] [-t TIPO] [-a] [-r REV]... [--base REV]... FILE [DEST]
Genera un file changegroup che raccolga i changeset da aggiungere a un repository.
Per creare un bundle contenente tutti i changeset, usa -a/--all (o --base null). Altrimenti, hg
presuppone che la destinazione avrà tutti i nodi specificati con i parametri --base.
Altrimenti, hg presumerà che il repository abbia tutti i nodi nella destinazione, oppure
default-push/default se non viene specificata alcuna destinazione.
Puoi cambiare il formato del pacchetto con l'opzione -t/--type. È possibile specificare una compressione, a
versione bundle o entrambi utilizzando un trattino (versione comp). I metodi di compressione disponibili sono:
none, bzip2 e gzip (per impostazione predefinita, i bundle vengono compressi utilizzando bzip2). Il disponibile
i formati sono: v1, v2 (predefinito al più adatto).
Il file bundle può quindi essere trasferito con mezzi convenzionali e applicato a un altro
repository con il comando unbundle o pull. Questo è utile quando sono presenti push e pull diretti
non disponibile o quando l'esportazione di un intero repository non è desiderabile.
L'applicazione dei bundle preserva tutti i contenuti del changeset inclusi permessi, copia/rinomina
informazioni e cronologia delle revisioni.
Restituisce 0 in caso di successo, 1 se non vengono trovate modifiche.
Opzioni:
-F, --vigore
corri anche quando la destinazione non è correlata
-R,--rev
un changeset destinato ad essere aggiunto alla destinazione
-B,--ramo
un ramo specifico che vorresti raggruppare
--base
un changeset di base che si presume sia disponibile a destinazione
-un, --tutti
raggruppare tutti i changeset nel repository
-T,--genere
tipo di compressione bundle da utilizzare (predefinito: bzip2)
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
gatto
emettere la revisione corrente o data dei file:
hg cat [OPZIONE]... FILE...
Stampa i file specificati come erano alla data revisione. Se non viene fornita alcuna revisione, il
genitore della directory di lavoro viene utilizzato.
L'output può essere un file, nel qual caso il nome del file viene fornito utilizzando un formato
corda. Le regole di formattazione come segue:
%%
carattere "%" letterale
%s
nome base del file da stampare
%d
dirname del file da stampare, o '.' se nella root del repository
%p
nome del percorso relativo alla radice del file da stampare
%H
hash changeset (40 cifre esadecimali)
%R
numero di revisione del changeset
%h
hash changeset in forma breve (12 cifre esadecimali)
%r
numero di revisione del changeset con riempimento zero
%b
nome di base del repository di esportazione
Restituisce 0 in caso di successo.
Opzioni:
-oh,--produzione
stampa l'output su file con nome formattato
-R,--rev
stampa la revisione data
--decodificare
applica qualsiasi filtro di decodifica corrispondente
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
clonare
fai una copia di un repository esistente:
hg clone [OPZIONE]... SORGENTE [DEST]
Crea una copia di un repository esistente in una nuova directory.
Se non viene specificato alcun nome di directory di destinazione, il valore predefinito è il nome di base dell'origine.
La posizione della sorgente viene aggiunta a quella del nuovo repository .hg/hgrc file, come predefinito
da utilizzare per futuri pull.
Solo percorsi locali e ss:// Gli URL sono supportati come destinazioni. Per ss:// destinazioni,
nessuna directory di lavoro o .hg/hgrc verrà creato sul lato remoto.
Se il repository di origine ha un segnalibro chiamato '@' impostato, quella revisione verrà verificata
nel nuovo repository per impostazione predefinita.
Per controllare una versione particolare, usa -u/--update o -U/--noupdate per creare un clone
senza directory di lavoro.
Per estrarre solo un sottoinsieme di modifiche, specificare uno o più identificatori di revisione con
-r/--rev o rami con -b/--branch. Il clone risultante conterrà solo lo specificato
changeset e i loro antenati. Queste opzioni (o 'clone src#rev dest') implicano --pull, even
per i repository di sorgenti locali.
Nota Specificare un tag includerà il changeset taggato ma non il changeset che contiene
il cartellino.
Per efficienza, gli hardlink vengono utilizzati per la clonazione ogni volta che l'origine e la destinazione sono attive
lo stesso filesystem (nota che questo vale solo per i dati del repository, non per il lavoro
rubrica). Alcuni filesystem, come AFS, implementano l'hardlinking in modo errato, ma non lo fanno
segnalare errori. In questi casi, usa l'opzione --pull per evitare l'hardlinking.
In alcuni casi, puoi clonare i repository e la directory di lavoro utilizzando hardlink completi
con
$ cp -al REPO REPOCLONE
Questo è il modo più veloce per clonare, ma non è sempre sicuro. L'operazione non è atomica
(assicurarsi che REPO non venga modificato durante l'operazione dipende da te) e devi farlo
assicurati che il tuo editor interrompa gli hardlink (Emacs e la maggior parte degli strumenti del kernel Linux lo fanno). Inoltre, questo è
non compatibile con alcune estensioni che inseriscono i propri metadati nella directory .hg,
come mq.
Mercurial aggiornerà la directory di lavoro alla prima revisione applicabile da questa
elenco:
un. null se -U o il repository di origine non ha changeset
B. se tu . e il repository di origine è locale, il primo genitore del repository di origine
directory di lavoro
C. il changeset specificato con -u (se un nome di ramo, questo significa l'ultimo capo di quello
ramo)
D. il changeset specificato con -r
e. la testa più in punta specificata con -b
F. l'intestazione più in alto specificata con la sintassi sorgente url#branch
G. la revisione contrassegnata dal segnalibro '@', se presente
h. la testa più punta del ramo predefinito
io. Consiglio
Durante la clonazione da server che lo supportano, Mercurial può recuperare dati pre-generati da a
URL pubblicizzato dal server. Fatto ciò, gli hook operano sui changeset in entrata e
i changegroup possono attivarsi due volte, una volta per il bundle recuperato dall'URL e un'altra per qualsiasi
dati aggiuntivi non recuperati da questo URL. Inoltre, se si verifica un errore, il repository
può essere riportato a un clone parziale. Questo comportamento potrebbe cambiare nelle versioni future. Vedere hg
Aiuto -e clonebundle per saperne di più.
Consigli d'uso:
· clonare un repository remoto in una nuova directory denominata hg/:
clone hg http://selenic.com/hg
· creare un clone locale leggero:
hg clone progetto/ funzione-progetto/
· clone da un percorso assoluto su un server ssh (nota la doppia barra):
hg clone ssh://utente@server//home/progetti/alpha/
· eseguire un clone ad alta velocità su una LAN mentre si verifica una versione specificata:
hg clone --non compresso http://server/repo -u 1.5
· creare un repository senza changeset dopo una particolare revisione:
hg clone -r 04e544 sperimentale/ buono/
· clonare (e tracciare) un particolare ramo denominato:
clone hg http://selenic.com/hg#stabile
See hg Aiuto urls per i dettagli sulla specifica degli URL.
Restituisce 0 in caso di successo.
Opzioni:
-U, --nessun aggiornamento
il clone includerà una directory di lavoro vuota (solo un repository)
-tu,--updaterev
revisione, tag o ramo da verificare
-R,--rev
includi il changeset specificato
-B,--ramo
clona solo il ramo specificato
--tiro usa il protocollo pull per copiare i metadati
--non compresso
utilizzare il trasferimento non compresso (veloce su LAN)
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
commettere
commit dei file specificati o di tutte le modifiche in sospeso:
hg commit [OPZIONE]... [FILE]...
Conferma le modifiche ai file specificati nel repository. A differenza di un SCM centralizzato, questo
l'operazione è un'operazione locale. Vedere hg spingere per un modo per distribuire attivamente le modifiche.
Se un elenco di file viene omesso, tutte le modifiche riportate da hg status sarà commesso.
Se stai eseguendo il commit del risultato di un'unione, non fornire alcun nome di file o -I/-X
filtri.
Se non viene specificato alcun messaggio di commit, Mercurial avvia il tuo editor configurato dove puoi
inserire un messaggio. Se il tuo commit fallisce, troverai un backup del tuo messaggio in
.hg/ultimo-messaggio.txt.
Il flag --close-branch può essere utilizzato per contrassegnare la chiusura del ramo corrente. Quando tutte le teste
di una filiale sono chiuse, la filiale sarà considerata chiusa e non più quotata.
Il flag --amend può essere usato per modificare il genitore della directory di lavoro con un nuovo
commit che contiene le modifiche nel genitore oltre a quelle attualmente riportate da
hg status, Se ce ne sono. Il vecchio commit è archiviato in un pacchetto di backup in
.hg/strip-backup (Vedi hg Aiuto fascio ed hg Aiuto unbundle su come ripristinarlo).
Messaggio, utente e data sono presi dal commit modificato se non diversamente specificato. Quando un messaggio
non è specificato sulla riga di comando, l'editor si aprirà con il messaggio della modifica
commettere.
Non è possibile modificare i changeset pubblici (vedi hg Aiuto fasi) o changeset che hanno
bambini.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Restituisce 0 in caso di successo, 1 se non è cambiato nulla.
Consigli d'uso:
· commit di tutti i file che terminano con .py:
hg commit --include "set:**.py"
· commit di tutti i file non binari:
hg commit --exclude "set:binary()"
· modificare il commit corrente e impostare la data ad ora:
hg commit --amend --date ora
Opzioni:
-UN, --Aggiungi Rimuovi
contrassegna i file nuovi/mancanti come aggiunti/rimossi prima di eseguire il commit
--chiudi-ramo
contrassegnare una testa di ramo come chiusa
--modifica
modificare il genitore della directory di lavoro
-S, --segreto
usa la fase segreta per impegnarti
-e, --modificare
invoca l'editor sui messaggi di commit
-io, --interattivo
usa la modalità interattiva
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
alias: ci
config
mostra le impostazioni di configurazione combinate da tutti i file hgrc:
hg config [-u] [NOME]...
Senza argomenti, stampa nomi e valori di tutti gli elementi di configurazione.
Con un argomento della forma sezione.nome, stampa solo il valore di quell'elemento di configurazione.
Con più argomenti, stampa i nomi e i valori di tutti gli elementi di configurazione con la sezione corrispondente
nomi.
Con --edit, avvia un editor sul file di configurazione a livello di utente. Con --global, modifica il
file di configurazione a livello di sistema. Con --local, modifica il file di configurazione a livello di repository.
Con --debug, viene stampata la sorgente (nome file e numero di riga) per ogni elemento di configurazione.
See hg Aiuto config per ulteriori informazioni sui file di configurazione.
Restituisce 0 in caso di successo, 1 se NAME non esiste.
Opzioni:
-tu, --non fidato
mostra opzioni di configurazione non attendibili
-e, --modificare
modifica la configurazione dell'utente
-l, --Locale
modifica la configurazione del repository
-G, --globale
modifica la configurazione globale
alias: showconfig debugconfig
copia
contrassegna i file come copiati per il prossimo commit:
hg copy [OPZIONE]... [SORGENTE]... DEST
Contrassegna come destinazione con copie dei file di origine. Se dest è una directory, le copie vengono messe in quella
directory. Se dest è un file, l'origine deve essere un singolo file.
Per impostazione predefinita, questo comando copia il contenuto dei file così come esistono nel lavoro
directory. Se invocato con -A/--after, l'operazione viene registrata, ma non viene eseguita alcuna copia
eseguita.
Questo comando ha effetto con il prossimo commit. Per annullare una copia prima, vedere hg ritornare.
Restituisce 0 in caso di successo, 1 se vengono rilevati errori.
Opzioni:
-UN, --dopo
registrare una copia già avvenuta
-F, --vigore
copiare forzatamente su un file gestito esistente
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
[+] l'opzione contrassegnata può essere specificata più volte
alias: cp
diff
repository diff (o file selezionati):
hg diff [OPZIONE]... ([-c REV] | [-r REV1 [-r REV2]]) [FILE]...
Mostra le differenze tra le revisioni per i file specificati.
Le differenze tra i file vengono mostrate utilizzando il formato diff unificato.
Note: hg diff può generare risultati imprevisti per le unioni, poiché verrà impostato automaticamente sul confronto
contro il primo changeset genitore della directory di lavoro se non ci sono revisioni
specificato.
Quando vengono forniti due argomenti di revisione, vengono mostrate le modifiche tra quelle revisioni. Se
viene specificata solo una revisione, quindi quella revisione viene confrontata con la directory di lavoro,
e, quando non vengono specificate revisioni, i file della directory di lavoro vengono confrontati con i suoi
primo genitore.
In alternativa puoi specificare -c/--change con una revisione per vedere le modifiche in questo
changeset rispetto al suo primo genitore.
Senza l'opzione -a/--text, diff eviterà di generare differenze di file che rileva come
binario. Con -a, diff genererà comunque un diff, probabilmente con risultati indesiderabili.
Usa l'opzione -g/--git per generare differenze nel formato diff esteso git. Per più
informazioni, leggi hg Aiuto diff.
Consigli d'uso:
· confrontare un file nella directory di lavoro corrente con il suo genitore:
hg diff foo.c
· confrontare due versioni storiche di una directory, con informazioni di ridenominazione:
hg diff --git -r 1.0:1.2 lib/
· ottenere statistiche di modifica relative all'ultima modifica in una data:
hg diff --stat -r "data('2 maggio')"
· diff tutti i file appena aggiunti che contengono una parola chiave:
hg diff "set:added() e grep(GNU)"
· confrontare una revisione e i suoi genitori:
hg diff -c 9353 # confronta con il primo genitore
hg diff -r 9353^:9353 # stesso usando la sintassi revset
hg diff -r 9353^2:9353 # confronta con il secondo genitore
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
revisione
-C,--modificare
modifica apportata dalla revisione
-un, --testo
tratta tutti i file come testo
-G, --idiota
usa il formato diff esteso git
--nodate
ometti le date dalle intestazioni diff
--noprefisso
ometti i prefissi a/ e b/ dai nomi dei file
-P, --show-funzione
mostra in quale funzione si trova ogni modifica
--inversione
produrre un diff che annulla le modifiche
-w, --ignora-tutto-spazio
ignora gli spazi bianchi quando confronti le righe
-B, --ignora-spazio-cambiamento
ignora i cambiamenti nella quantità di spazio bianco
-B, --ignora-linee-vuote
ignora le modifiche le cui righe sono tutte vuote
-U,--unificato
numero di righe di contesto da mostrare
--statistica output di riepilogo delle modifiche in stile diffstat
--radice
produrre differenze relative alla sottodirectory
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
export
scarica l'intestazione e le differenze per uno o più set di modifiche:
hg export [OPZIONE]... [-o OUTFILESPEC] [-r] [REV]...
Stampa l'intestazione del changeset e le differenze per una o più revisioni. Se non viene fornita alcuna revisione,
viene utilizzato il genitore della directory di lavoro.
Le informazioni mostrate nell'intestazione del changeset sono: autore, data, nome del ramo (se
non predefinito), hash del changeset, genitore/i e commento di commit.
Note: hg export potrebbe generare un output diff imprevisto per i changeset di unione, come succederà
confrontare il changeset di unione solo con il suo primo genitore.
L'output può essere un file, nel qual caso il nome del file viene fornito utilizzando un formato
corda. Le regole di formattazione sono le seguenti:
%%
carattere "%" letterale
%H
hash changeset (40 cifre esadecimali)
%N
numero di patch generate
%R
numero di revisione del changeset
%b
nome di base del repository di esportazione
%h
hash changeset in forma breve (12 cifre esadecimali)
%m
prima riga del messaggio di commit (solo caratteri alfanumerici)
%n
numero di sequenza riempito con zero, a partire da 1
%r
numero di revisione del changeset con riempimento zero
Senza l'opzione -a/--text, l'esportazione eviterà di generare differenze di file che rileva come
binario. Con -a, l'esportazione genererà comunque una differenza, probabilmente con risultati indesiderati.
Usa l'opzione -g/--git per generare differenze nel formato diff esteso git. Vedere hg Aiuto
diff per maggiori informazioni.
Con l'opzione --switch-parent, la differenza sarà contro il secondo genitore. Può essere
utile per rivedere un'unione.
Consigli d'uso:
· utilizzare l'esportazione e l'importazione per trapiantare un bugfix nel ramo corrente:
hg export -r 9353 | hg importazione -
· esportare tutti i changeset tra due revisioni in un file con informazioni di ridenominazione:
hg export --git -r 123:150 > modifiche.txt
· suddividere le modifiche in uscita in una serie di patch con nomi descrittivi:
hg export -r "in uscita()" -o "%n-%m.patch"
Restituisce 0 in caso di successo.
Opzioni:
-oh,--produzione
stampa l'output su file con nome formattato
--cambia-genitore
diff contro il secondo genitore
-R,--rev
revisioni da esportare
-un, --testo
tratta tutti i file come testo
-G, --idiota
usa il formato diff esteso git
--nodate
ometti le date dalle intestazioni diff
[+] l'opzione contrassegnata può essere specificata più volte
file
elenca i file monitorati:
hg file [OPTION]... [PATTERN]...
Stampa i file sotto il controllo di Mercurial nella directory di lavoro o nella revisione specificata la cui
i nomi corrispondono ai modelli dati (esclusi i file rimossi).
Se non vengono dati modelli da abbinare, questo comando stampa i nomi di tutti i file sotto
Controllo Mercurial nella directory di lavoro.
Consigli d'uso:
· elenca tutti i file nella directory corrente:
hg file .
· mostra dimensioni e bandiere per la revisione corrente:
hg file -vr .
· elenca tutti i file denominati README:
hg file -I "**/README"
· elenca tutti i file binari:
hg file "set:binary()"
· trova file contenenti un'espressione regolare:
hg files "set:grep('bob')"
· cercare i contenuti dei file tracciati con xargs e grep:
hg file -0 | xargs -0 grep foo
See hg Aiuto modelli ed hg Aiuto set di file per ulteriori informazioni sulla specifica del file
modelli.
Restituisce 0 se viene trovata una corrispondenza, 1 altrimenti.
Opzioni:
-R,--rev
cerca nel repository così com'è in REV
-0, --print0
terminare i nomi dei file con NUL, per l'uso con xargs
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-T,--modello
display con template (SPERIMENTALE)
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
dimenticare
dimentica i file specificati al prossimo commit:
hg forget [OPZIONE]... FILE...
Contrassegna i file specificati in modo che non vengano più tracciati dopo il prossimo commit.
Questo rimuove solo i file dal ramo corrente, non dall'intera cronologia del progetto e
non li elimina dalla directory di lavoro.
Per eliminare il file dalla directory di lavoro, vedere hg rimuovere.
Per annullare una dimenticanza prima del prossimo commit, vedere hg aggiungere.
Consigli d'uso:
· dimentica i file binari appena aggiunti:
hg forget "set:added() e binary()"
· dimenticare i file che verrebbero esclusi da .hgignore:
hg forget "set:hgignore()"
Restituisce 0 in caso di successo.
Opzioni:
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
Graft
copia le modifiche da altri rami nel ramo corrente:
hg innesto [OPZIONE]... [-r REV]... REV...
Questo comando usa la logica di unione di Mercurial per copiare singole modifiche da altri rami
senza unire i rami nel grafico storico. Questo è talvolta noto come "backporting" o
'raccogliere le ciliegie'. Per impostazione predefinita, l'innesto copierà l'utente, la data e la descrizione dalla fonte
modifiche.
Changeset che sono antenati della revisione corrente, che sono già stati innestati, oppure
che sono le unioni verranno ignorate.
Se viene specificato --log, ai messaggi di registro verrà aggiunto un commento del modulo:
(innestato da CHANGESETHASH)
Se viene specificato --force, le revisioni verranno innestate anche se sono già antenati di
o sono stati innestati alla destinazione. Questo è utile quando le revisioni hanno da
stato ritirato.
Se un'unione di innesto provoca conflitti, il processo di innesto viene interrotto in modo che il
l'unione corrente può essere risolta manualmente. Una volta risolti tutti i conflitti, l'innesto
il processo può essere continuato con l'opzione -c/--continue.
Nota L'opzione -c/--continue non riapplica le opzioni precedenti, ad eccezione di --force.
Consigli d'uso:
· copiare una singola modifica nel ramo stabile e modificarne la descrizione:
hg update stabile
hg innesto --edit 9393
· innestare una serie di modifiche con un'eccezione, aggiornando le date:
hg innesto -D "2085::2093 e non 2091"
· continuare un innesto dopo aver risolto i conflitti:
hg innesto -c
· mostrare la fonte di un changeset innestato:
hg log --debug -r.
· mostra le revisioni ordinate per data:
hg log -r 'sort(all(), date)'
See hg Aiuto ed hg Aiuto revisioni per ulteriori informazioni sulla specifica delle revisioni.
Restituisce 0 in caso di completamento con successo.
Opzioni:
-R,--rev
revisioni a innesto
-C, --Continua
riprendere l'innesto interrotto
-e, --modificare
invoca l'editor sui messaggi di commit
--tronco d'albero aggiungi le informazioni sull'innesto al messaggio di registro
-F, --vigore
innesto forzato
-D, --data odierna
registra la data corrente come data di commit
-U, --utente corrente
registra l'utente corrente come committer
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
-T,--attrezzo
specificare lo strumento di unione
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
[+] l'opzione contrassegnata può essere specificata più volte
grep
cerca un modello in file e revisioni specificati:
hg grep [OPZIONE]... MODELLO [FILE]...
Cerca le revisioni dei file per un'espressione regolare.
Questo comando si comporta in modo diverso da Unix grep. Accetta solo espressioni regolari Python/Perl. Esso
cerca la cronologia del repository, non la directory di lavoro. Stampa sempre la revisione
numero in cui compare una corrispondenza.
Per impostazione predefinita, grep stampa solo l'output per la prima revisione di un file in cui trova a
corrispondere. Per farlo stampare ogni revisione che contiene un cambiamento nello stato di corrispondenza ("-" per a
corrispondenza che diventa una non corrispondenza, o "+" per una non corrispondenza che diventa una corrispondenza), utilizzare il
--all bandiera.
Restituisce 0 se viene trovata una corrispondenza, 1 altrimenti.
Opzioni:
-0, --print0
campi finali con NUL
--tutti stampa tutte le revisioni che corrispondono
-un, --testo
tratta tutti i file come testo
-F, --Seguire
seguire la cronologia delle modifiche o la cronologia dei file tra copie e rinominazioni
-io, --ignora-caso
ignora maiuscole/minuscole durante la corrispondenza
-l, --file-con-corrispondenze
stampa solo nomi di file e revisioni che corrispondono
-N, --numero-riga
stampa i numeri di riga corrispondenti
-R,--rev
cerca solo i file modificati all'interno dell'intervallo di revisione
-tu, --utente
elenca l'autore (lungo con -v)
-D, --Data
elenca la data (in breve con -q)
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
teste
mostra le teste dei rami:
hg teste [-ct] [-r STARTREV] [REV]...
Senza argomenti, mostra tutti i rami aperti nel repository. Le teste dei rami sono
changeset che non hanno discendenti sullo stesso ramo. Sono dove lo sviluppo
generalmente ha luogo e sono gli obiettivi abituali per le operazioni di aggiornamento e unione.
Se vengono forniti uno o più REV aprire solo i capolinea sui rami associati al
vengono visualizzati i changeset specificati. Questo significa che puoi usare hg teste . per vedere le teste su
la filiale attualmente in check-out.
Se viene specificato -c/--closed, mostra anche le teste di diramazione contrassegnate come chiuse (vedi hg commettere
--chiudi-ramo).
Se viene specificato STARTREV, solo le teste che sono discendenti di STARTREV saranno
visualizzato.
Se viene specificato -t/--topo, le meccaniche del ramo con nome verranno ignorate e saranno solo topologiche
verranno mostrate teste (changeset senza figli).
Restituisce 0 se vengono trovate teste corrispondenti, 1 in caso contrario.
Opzioni:
-R,--rev
mostra solo le teste che discendono da STARTREV
-T, --top
mostra solo teste topologiche
-un, --attivo
mostra solo le diramazioni attive (DEPRECATO)
-C, --Chiuso
mostra le teste dei rami normali e chiuse
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
Aiuto
mostra la guida per un determinato argomento o una panoramica della guida:
hg help [-ecks] [ARGOMENTO]
Senza argomenti, stampa un elenco di comandi con brevi messaggi di aiuto.
Dato un argomento, un'estensione o un nome di comando, stampa la guida per quell'argomento.
Restituisce 0 in caso di successo.
Opzioni:
-e, --estensione
mostra solo l'aiuto per le estensioni
-C, --comando
mostra solo l'aiuto per i comandi
-K, --parola chiave
mostra argomenti corrispondenti alla parola chiave
-S,--sistema
mostra aiuto per piattaforme specifiche
[+] l'opzione contrassegnata può essere specificata più volte
identificare
identificare la directory di lavoro o la revisione specificata:
hg identifica [-nibtB] [-r REV] [SORGENTE]
Stampa un riepilogo che identifica lo stato del repository su REV utilizzando uno o due hash genitori
identificatori, seguito da un "+" se la directory di lavoro ha modifiche non salvate, il
nome del ramo (se non predefinito), un elenco di tag e un elenco di segnalibri.
Quando REV non viene fornito, stampa un riepilogo dello stato corrente del repository.
Specificare un percorso per una radice del repository o un bundle Mercurial farà sì che la ricerca funzioni su
quel repository/bundle.
Consigli d'uso:
· generare un identificatore di build per la directory di lavoro:
hg id --id > build-id.dat
· trovare la revisione corrispondente a un tag:
hg id -n -r 1.3
· controllare la revisione più recente di un repository remoto:
hg id -r suggerimento http://selenic.com/hg/
See hg ceppo per generare maggiori informazioni su revisioni specifiche, incluso l'hash completo
identificatori.
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
identificare la revisione specificata
-N, --num
mostra il numero di revisione locale
-io, --ID
mostra l'ID revisione globale
-B, --ramo
mostra ramo
-T, --tag
mostra tag
-B, --segnalibri
mostra segnalibri
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
alias: id
importare
importare un set ordinato di patch:
hg import [OPZIONE]... PATCH...
Importa un elenco di patch e salvale individualmente (a meno che non sia specificato --no-commit).
Per leggere una patch dallo standard input, utilizzare "-" come nome della patch. Se viene specificato un URL, il
la patch verrà scaricata da lì.
L'importazione prima applica le modifiche alla directory di lavoro (a meno che non sia specificato --bypass),
l'importazione verrà interrotta se ci sono modifiche in sospeso.
Usa --bypass per applicare e confermare le patch direttamente nel repository, senza influire sul
directory di lavoro. Senza --exact, le patch verranno applicate sopra il lavoro
revisione padre directory.
Puoi importare una patch direttamente da un messaggio di posta. Anche le patch come allegati funzionano (per
usa la parte del corpo, deve avere il tipo text/plain o text/x-patch). Intestazioni Da e Oggetto
del messaggio di posta elettronica vengono utilizzati come committer predefinito e messaggio di commit. Tutto il testo/corpo normale
le parti prima della prima differenza vengono aggiunte al messaggio di commit.
Se la patch importata è stata generata da hg export, utente e descrizione dall'override della patch
valori dalle intestazioni e dal corpo del messaggio. Valori forniti sulla riga di comando con -m/--message e
-u/--user li sovrascrive.
Se viene specificato --exact, import imposterà la directory di lavoro come padre di ogni patch
prima di applicarlo e si interromperà se il changeset risultante ha un ID diverso dal
uno registrato nella patch. Ciò può accadere a causa di problemi con il set di caratteri o altro
carenze nel formato della patch di testo.
Usa --partial per assicurarti che un changeset venga creato dalla patch anche se alcuni pezzi falliscono
applicare. I fusti che non si candidano verranno scritti su a file .rej. Conflitti
può quindi essere risolto a mano prima hg commettere --modifica viene eseguito per aggiornare il creato
set di modifiche. Questo flag esiste per consentire alle persone di importare patch che si applicano parzialmente senza
perdere i metadati associati (autore, data, descrizione, ...).
Nota Quando nessun pezzo si applica in modo pulito, hg importare --parziale creerà un changeset vuoto,
importando solo i metadati della patch.
Con -s/--similarità, hg tenterà di scoprire i nomi e le copie nella patch nel
allo stesso modo di hg Aggiungi Rimuovi.
È possibile utilizzare programmi di patch esterni per eseguire la patch impostando il ui.patch
opzione di configurazione. Per lo strumento interno predefinito, il fuzz può essere configurato anche tramite
patch.fuzz. Vedere hg Aiuto config per ulteriori informazioni sui file di configurazione e su come
utilizzare queste opzioni.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Consigli d'uso:
· importare una patch tradizionale da un sito Web e rilevare i nomi:
hg import -s 80 http://example.com/bugfix.patch
· importare un changeset da un server hgweb:
hg importazione http://www.selenic.com/hg/rev/5ca8c111e9aa
· importare tutte le patch in una mbox in stile Unix:
hg importa patch-in-arrivo.mbox
· tentare di ripristinare esattamente un changeset esportato (non sempre possibile):
hg import --exact proposto-fix.patch
· utilizzare uno strumento esterno per applicare una patch che è troppo sfocata per lo strumento interno predefinito.
hg import --config ui.patch="patch --merge" fuzzy.patch
· modificare il fuzzing predefinito da 2 a 7 . meno rigoroso
hg import --config ui.fuzz=7 fuzz.patch
Restituisce 0 in caso di successo, 1 in caso di successo parziale (vedi --partial).
Opzioni:
-P,--striscia
opzione striscia di directory per patch. Questo ha lo stesso significato del corrispondente
opzione patch (predefinito: 1)
-B,--base
percorso base (DEPRECATO)
-e, --modificare
invoca l'editor sui messaggi di commit
-F, --vigore
salta il controllo delle modifiche non confermate in sospeso (DEPRECATO)
--senza impegno
non eseguire il commit, aggiorna solo la directory di lavoro
--circonvallazione
applica la patch senza toccare la directory di lavoro
--parziale
impegnarsi anche se alcuni pezzi falliscono
--esatto
applicare la patch ai nodi da cui è stata generata
--prefisso
applica la patch alla sottodirectory
--import-ramo
usa qualsiasi informazione di ramo nella patch (implicata da --exact)
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
-S,--somiglianza
indovina i file rinominati per somiglianza (0<=s<=100)
alias: patch
in arrivo
mostra i nuovi changeset trovati nel sorgente:
hg incoming [-p] [-n] [-M] [-f] [-r REV]... [--bundle FILENAME] [SORGENTE]
Mostra i nuovi changeset trovati nel percorso/URL specificato o nella posizione di pull predefinita. Queste
sono i changeset che sarebbero stati ritirati in caso di pull nel momento in cui hai emesso questo
comando.
Vedere pull per i dettagli sul formato di origine valido.
Con -B/--bookmarks, il risultato del confronto dei segnalibri tra locale e remoto
vengono visualizzati i repository. Con -v/--verbose, lo stato viene visualizzato anche per ogni segnalibro
come di seguito:
BM1 01234567890a aggiunto
BM2 1234567890ab avanzato
BM3 234567890abc divergente
BM4 34567890abcd modificato
L'azione intrapresa localmente durante il pull dipende dallo stato di ciascun segnalibro:
aggiunto
pull lo creerà
Avanzate
pull lo aggiornerà
divergevano
pull creerà un segnalibro divergente
cambiato
il risultato dipende dai changeset remoti
Dal punto di vista del comportamento di trazione, segnalibro esistente solo nel telecomando
repository sono trattati come aggiunto, anche se di fatto è cancellato localmente.
Per il repository remoto, l'utilizzo di --bundle evita di scaricare i changeset due volte se
in entrata è seguito da un pull.
Consigli d'uso:
· mostra le modifiche in arrivo con patch e descrizione completa:
hg in entrata -vp
· mostra le modifiche in arrivo escluse le unioni, memorizza un pacchetto:
hg in -vpM --bundle in arrivo.hg
hg pull in arrivo.hg
· elencare brevemente le modifiche all'interno di un pacchetto:
hg in modifiche.hg -T "{desc|prima riga}\n"
Restituisce 0 se ci sono modifiche in arrivo, 1 altrimenti.
Opzioni:
-F, --vigore
esegui anche se il repository remoto non è correlato
-N, --prima il più nuovo
mostra prima il record più recente
--fascio
file in cui archiviare i bundle
-R,--rev
un changeset remoto destinato ad essere aggiunto
-B, --segnalibri
confronta i segnalibri
-B,--ramo
un ramo specifico che vorresti tirare
-P, --toppa
mostra la patch
-G, --idiota
usa il formato diff esteso git
-l,--limite
limitare il numero di modifiche visualizzate
-M, --no-fusioni
non mostrare le unioni
--statistica output di riepilogo delle modifiche in stile diffstat
-G, --grafico
mostra la revisione DAG
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
alias: in
init
creare un nuovo repository nella directory data:
hg init [-e CMD] [--remotecmd CMD] [DEST]
Inizializza un nuovo repository nella directory data. Se la directory indicata non esiste,
sarà creato.
Se non viene fornita alcuna directory, viene utilizzata la directory corrente.
È possibile specificare un ss:// URL come destinazione. Vedere hg Aiuto urls per maggiori
informazioni.
Restituisce 0 in caso di successo.
Opzioni:
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
individuare
individuare i file che corrispondono a modelli specifici (DEPRECATO):
hg individuare [OPTION]... [PATTERN]...
Stampa i file sotto il controllo di Mercurial nella directory di lavoro i cui nomi corrispondono a quelli dati
modelli.
Per impostazione predefinita, questo comando ricerca tutte le directory nella directory di lavoro. Per cercare solo
la directory corrente e le sue sottodirectory, usa "--include .".
Se non vengono dati modelli da abbinare, questo comando stampa i nomi di tutti i file sotto
Controllo Mercurial nella directory di lavoro.
Se vuoi inserire l'output di questo comando nel comando "xargs", usa l'opzione -0
sia a questo comando che a "xargs". Questo eviterà il problema di "xargs" trattando single
nomi di file che contengono spazi bianchi come più nomi di file.
See hg Aiuto file per un comando più versatile.
Restituisce 0 se viene trovata una corrispondenza, 1 altrimenti.
Opzioni:
-R,--rev
cerca nel repository così com'è in REV
-0, --print0
terminare i nomi dei file con NUL, per l'uso con xargs
-F, --percorso completo
stampa percorsi completi dalla radice del filesystem
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
ceppo
mostra la cronologia delle revisioni dell'intero repository o dei file:
hg log [OPZIONE]... [FILE]
Stampa la cronologia delle revisioni dei file specificati o dell'intero progetto.
Se non viene specificato alcun intervallo di revisione, il valore predefinito è suggerimento: 0 a meno che non sia impostato --follow, in cui
caso la directory di lavoro genitore viene utilizzata come revisione iniziale.
La cronologia dei file viene mostrata senza dover rinominare o copiare la cronologia dei file. Usa -f/--follow
con un nome file per seguire la cronologia tra rinomina e copie. --follow senza un nome di file
mostrerà solo antenati o discendenti della revisione iniziale.
Per impostazione predefinita, questo comando stampa il numero di revisione e l'ID del changeset, i tag, non banali
genitori, utente, data e ora e un riepilogo per ogni commit. Quando l'opzione -v/--verbose
viene utilizzato, vengono mostrati l'elenco dei file modificati e il messaggio di commit completo.
Con --graph le revisioni sono mostrate come un DAG ASCII art con il changeset più recente a
la cima. "o" è un changeset, "@" è un genitore di directory di lavoro, "x" è obsoleto e "+"
rappresenta un fork in cui il changeset dalle righe sottostanti è un genitore dell'unione 'o' su
la stessa linea.
Note: hg ceppo --toppa potrebbe generare un output diff imprevisto per i changeset di unione, come succederà
confrontare solo il changeset di unione con il suo primo genitore. Inoltre, solo file
diverso da ENTRAMBI i genitori apparirà nei file:.
Nota Per motivi di prestazioni, hg ceppo RISORSE può omettere modifiche duplicate effettuate sui rami
e non mostrerà le rimozioni o le modifiche alla modalità. Per vedere tutti questi cambiamenti, usa il
--interruttore rimosso.
Qualche esempio:
· changeset con descrizioni complete ed elenchi di file:
hg ceppo -v
· modifiche ancestrali alla directory di lavoro:
hg ceppo -f
· ultimi 10 commit sul ramo corrente:
hg log -l 10 -b .
· changeset che mostrano tutte le modifiche di un file, incluse le rimozioni:
hg log --file rimosso.c
· tutti i changeset che toccano una directory, con diff, escluse le unioni:
hg log -Mp lib/
· tutti i numeri di revisione che corrispondono a una parola chiave:
hg log -k bug --template "{rev}\n"
· l'identificatore hash completo del genitore della directory di lavoro:
hg log -r . --template "{nodo}\n"
· elenca i modelli di registro disponibili:
hg log -T lista
· controlla se un dato changeset è incluso in una release con tag:
hg log -r "a21ccf e antenato(1.9)"
· trova tutte le modifiche apportate da un utente in un intervallo di date:
hg log -k alice -d "da maggio 2008 a luglio 2008"
· riepilogo di tutti i changeset dopo l'ultimo tag:
hg log -r "last(tagged())::" --template "{desc|firstline}\n"
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
See hg Aiuto ed hg Aiuto revisioni per ulteriori informazioni su come specificare e ordinare
revisioni.
See hg Aiuto modelli per ulteriori informazioni sugli stili preconfezionati e sulla specifica di modelli personalizzati.
Restituisce 0 in caso di successo.
Opzioni:
-F, --Seguire
seguire la cronologia delle modifiche o la cronologia dei file tra copie e rinominazioni
--segui-prima
segui solo il primo genitore dei changeset di unione (DEPRECATO)
-D,--Data
mostra le revisioni corrispondenti alle specifiche della data
-C, --copie
mostra i file copiati
-K,--parola chiave
eseguire una ricerca senza distinzione tra maiuscole e minuscole per un determinato testo
-R,--rev
mostra la revisione o il revset specificato
--RIMOSSO
includere le revisioni in cui i file sono stati rimossi
-M, --solo-unisce
mostra solo unioni (DEPRECATO)
-tu,--utente
revisioni commesse dall'utente
--solo-ramo
mostra solo i changeset all'interno del ramo nominato specificato (DEPRECATO)
-B,--ramo
mostra i changeset all'interno del ramo nominato dato
-P,--fesso
non visualizzare la revisione o nessuno dei suoi antenati
-P, --toppa
mostra la patch
-G, --idiota
usa il formato diff esteso git
-l,--limite
limitare il numero di modifiche visualizzate
-M, --no-fusioni
non mostrare le unioni
--statistica output di riepilogo delle modifiche in stile diffstat
-G, --grafico
mostra la revisione DAG
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
alias: storia
manifesto
emettere la revisione corrente o data del manifest del progetto:
hg manifesto [-r REV]
Stampa un elenco di file controllati dalla versione per la revisione data. Se non viene fornita alcuna revisione,
viene utilizzato il primo genitore della directory di lavoro, o la revisione nulla se nessuna revisione è
controllato.
Con -v, stampa i permessi dei file, il collegamento simbolico e i bit eseguibili. Con --debug, stampa il file
hash di revisione.
Se viene specificata l'opzione --all, viene stampato l'elenco di tutti i file di tutte le revisioni. Questo
include file eliminati e rinominati.
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
revisione da visualizzare
--tutti elenca i file di tutte le revisioni
-T,--modello
display con template (SPERIMENTALE)
unire
unire un'altra revisione nella directory di lavoro:
hg unione [-P] [[-r] REV]
La directory di lavoro corrente viene aggiornata con tutte le modifiche apportate nella revisione richiesta
dall'ultima revisione comune del predecessore.
I file che sono stati modificati tra entrambi i genitori sono contrassegnati come modificati per il commit successivo e a
il commit deve essere eseguito prima che siano consentiti ulteriori aggiornamenti al repository. Il
il prossimo commit avrà due genitori.
--attrezzo può essere utilizzato per specificare lo strumento di unione utilizzato per le unioni di file. Ignora il
Variabile di ambiente HGMERGE e i tuoi file di configurazione. Vedere hg Aiuto strumenti di fusione per
opzioni.
Se non viene specificata alcuna revisione, il genitore della directory di lavoro è una revisione principale e il
il ramo corrente contiene esattamente un'altra testa, l'altra testa è unita per impostazione predefinita.
In caso contrario, deve essere fornita una revisione esplicita con cui fondersi.
See hg Aiuto risolvere per informazioni sulla gestione dei conflitti di file.
Per annullare un'unione di cui non è stato eseguito il commit, utilizzare hg update --pulire . che controllerà una copia pulita di
il genitore di unione originale, perdendo tutte le modifiche.
Restituisce 0 in caso di successo, 1 se sono presenti file non risolti.
Opzioni:
-F, --vigore
forzare un'unione comprese le modifiche in sospeso (DEPRECATO)
-R,--rev
revisione da unire
-P, --anteprima
rivedere le revisioni da unire (non viene eseguita alcuna unione)
-T,--attrezzo
specificare lo strumento di unione
uscente
mostra i changeset non trovati nella destinazione:
hg in uscita [-M] [-p] [-n] [-f] [-r REV]... [DEST]
Mostra le modifiche non trovate nel repository di destinazione specificato o nel push predefinito
Posizione. Questi sono i changeset che verrebbero inviati se fosse richiesto un push.
Vedere pull per i dettagli sui formati di destinazione validi.
Con -B/--bookmarks, il risultato del confronto dei segnalibri tra locale e remoto
vengono visualizzati i repository. Con -v/--verbose, lo stato viene visualizzato anche per ogni segnalibro
come di seguito:
BM1 01234567890a aggiunto
BM2 cancellato
BM3 234567890abc avanzato
BM4 34567890abcd divergente
BM5 4567890abcde modificato
L'azione intrapresa durante il push dipende dallo stato di ciascun segnalibro:
aggiunto
spingere con -B lo creerà
cancellato
spingere con -B lo cancellerò
Avanzate
push lo aggiornerà
divergevano
spingere con -B lo aggiornerò
cambiato
spingere con -B lo aggiornerò
Dal punto di vista del comportamento di spinta, i segnalibri esistenti solo nel telecomando
repository sono trattati come cancellato, anche se di fatto viene aggiunto a distanza.
Restituisce 0 se ci sono modifiche in uscita, 1 altrimenti.
Opzioni:
-F, --vigore
corri anche quando la destinazione non è correlata
-R,--rev
un changeset destinato ad essere incluso nella destinazione
-N, --prima il più nuovo
mostra prima il record più recente
-B, --segnalibri
confronta i segnalibri
-B,--ramo
un ramo specifico che vorresti spingere
-P, --toppa
mostra la patch
-G, --idiota
usa il formato diff esteso git
-l,--limite
limitare il numero di modifiche visualizzate
-M, --no-fusioni
non mostrare le unioni
--statistica output di riepilogo delle modifiche in stile diffstat
-G, --grafico
mostra la revisione DAG
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
alias: fuori
genitori
mostra i genitori della directory di lavoro o della revisione (DEPRECATO):
hg genitori [-r REV] [FILE]
Stampa le revisioni padre della directory di lavoro. Se viene data una revisione tramite -r/--rev, il
genitore di quella revisione verrà stampato. Se viene fornito un argomento file, la revisione in
quale il file è stato modificato l'ultima volta (prima della revisione della directory di lavoro o dell'argomento a
--rev se fornito) viene stampato.
Questo comando è equivalente a:
hg log -r "p1()+p2()" o
hg log -r "p1(REV)+p2(REV)" o
hg log -r "max(::p1() e file(FILE))+max(::p2() e file(FILE))" o
hg log -r "max(::p1(REV) e file(FILE))+max(::p2(REV) e file(FILE))"
See hg sommario ed hg Aiuto revisioni per informazioni correlate.
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
mostra i genitori della revisione specificata
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
percorsi
mostra gli alias per i repository remoti:
hg percorsi [NOME]
Mostra la definizione del nome del percorso simbolico NAME. Se non viene fornito alcun nome, mostra la definizione di tutto
nomi disponibili.
L'opzione -q/--quiet sopprime tutto l'output durante la ricerca di NAME e mostra solo il percorso
nomi quando si elencano tutte le definizioni.
I nomi dei percorsi sono definiti nella sezione [percorsi] del file di configurazione e in
/etc/mercurial/hgrc. Se eseguito all'interno di un repository, .hg/hgrc viene utilizzato anche.
I nomi dei percorsi difetto ed push predefinito avere un significato speciale. Quando si esegue una spinta o
operazione pull, vengono utilizzati come fallback se non viene specificata alcuna posizione sul
riga di comando. quando push predefinito è impostato, verrà utilizzato per push e difetto sarà usato
per tirare; altrimenti difetto viene utilizzato come fallback per entrambi. Quando si clona un repository,
il sorgente clone è scritto come difetto in .hg/hgrc.
Note: difetto ed push predefinito si applica a tutti i messaggi in entrata (ad es hg in arrivo) e in uscita
(per esempio hg uscente, hg email ed hg fascio) operazioni.
See hg Aiuto urls per maggiori informazioni.
Restituisce 0 in caso di successo.
Opzioni:
-T,--modello
display con template (SPERIMENTALE)
fase
imposta o mostra il nome della fase corrente:
hg fase [-p|-d|-s] [-f] [-r] [REV...]
Senza argomenti, mostra il nome della fase delle revisioni correnti.
Con uno tra -p/--public, -d/--draft o -s/--secret, cambia il valore di fase del
revisioni specificate.
A meno che non sia specificato -f/--force, hg fase non sposterà il changeset da una fase inferiore a un
fase superiore. Le fasi sono ordinate come segue:
pubblico < bozza < segreto
Restituisce 0 in caso di successo, 1 se alcune fasi non possono essere modificate.
(Per ulteriori informazioni sul concetto di fasi, vedere hg Aiuto fasi.)
Opzioni:
-P, --pubblico
imposta la fase changeset su public
-D, --brutta copia
imposta la fase changeset su bozza
-S, --segreto
imposta la fase del changeset su segreto
-F, --vigore
consentire di spostare il confine all'indietro
-R,--rev
revisione dell'obiettivo
[+] l'opzione contrassegnata può essere specificata più volte
tirare
estrarre le modifiche dalla fonte specificata:
hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [FONTE]
Estrarre le modifiche da un repository remoto a uno locale.
Questo trova tutte le modifiche dal repository nel percorso o nell'URL specificato e le aggiunge a a
repository locale (quello corrente a meno che non sia specificato -R). Per impostazione predefinita, questo non lo fa
aggiornare la copia del progetto nella directory di lavoro.
Usa il hg in arrivo se vuoi vedere cosa sarebbe stato aggiunto da un pull nel momento in cui tu
impartito questo comando. Se poi decidi di aggiungere queste modifiche al repository, dovresti
uso hg tirare -r X where X è l'ultimo changeset elencato da hg in arrivo.
Se SOURCE viene omesso, verrà utilizzato il percorso "predefinito". Vedere hg Aiuto urls per maggiori
informazioni.
Restituisce 0 in caso di successo, 1 se un aggiornamento contiene file non risolti.
Opzioni:
-tu, --aggiornare
aggiornamento alla nuova testata del ramo se sono stati estratti i changeset
-F, --vigore
eseguito anche quando il repository remoto non è correlato
-R,--rev
un changeset remoto destinato ad essere aggiunto
-B,--segnalibro
segnalibro da tirare
-B,--ramo
un ramo specifico che vorresti tirare
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
spingere
spingere le modifiche alla destinazione specificata:
hg push [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [DEST]
Invia i changeset dal repository locale alla destinazione specificata.
Questa operazione è simmetrica al pull: è identica a un pull nella destinazione
repository da quello attuale.
Per impostazione predefinita, il push non consentirà la creazione di nuove teste a destinazione, poiché multiple
teste renderebbe poco chiaro quale testa usare. In questa situazione, si consiglia di
tirare e unire prima di spingere.
Usa --new-branch se vuoi consentire a push di creare un nuovo ramo denominato che non lo è
presente a destinazione. Questo ti permette di creare solo un nuovo ramo senza forzare
altre modifiche.
Nota Occorre prestare particolare attenzione con l'opzione -f/--force, che spingerà tutto il nuovo
teste su tutti i rami, un'azione che quasi sempre creerà confusione per
collaboratori.
Se si usa -r/--rev, la revisione specificata e tutti i suoi predecessori verranno spostati al
archivio remoto.
Se viene utilizzato -B/--bookmark, la revisione contrassegnata con segnalibro specificata, i suoi antenati e il
il segnalibro verrà inviato al repository remoto.
Si prega di consultare hg Aiuto urls per dettagli importanti su ss:// URL. Se DESTINAZIONE è
omesso, verrà utilizzato un percorso predefinito.
Restituisce 0 se il push ha avuto successo, 1 se non è stato eseguito il push.
Opzioni:
-F, --vigore
forza spinta
-R,--rev
un changeset destinato ad essere incluso nella destinazione
-B,--segnalibro
segnalibro per spingere
-B,--ramo
un ramo specifico che vorresti spingere
--nuovo-ramo
permettere di spingere un nuovo ramo
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
recuperare
eseguire il rollback di una transazione interrotta:
hg recuperare
Recupero da un commit o pull interrotto.
Questo comando tenta di correggere lo stato del repository dopo un'operazione interrotta. Dovrebbe
essere necessario solo quando Mercurial lo suggerisce.
Restituisce 0 in caso di successo, 1 se nulla da recuperare o verificare non riesce.
rimuovere
rimuovi i file specificati al prossimo commit:
hg rimuovi [OPZIONE]... FILE...
Pianifica i file indicati per la rimozione dal ramo corrente.
Questo comando pianifica la rimozione dei file al prossimo commit. Per annullare una rimozione
prima di questo, vedi hg ritornare. Per annullare i file aggiunti, vedere hg dimenticare.
-A/--after può essere utilizzato per rimuovere solo i file che sono già stati eliminati, -f/--force può
essere usato per forzare la cancellazione e -Af può essere usato per rimuovere i file dalla prossima revisione
senza eliminarli dalla directory di lavoro.
La tabella seguente descrive il comportamento di rimozione per diversi stati di file (colonne) e
combinazioni di opzioni (righe). Gli stati del file sono Aggiunto [A], Pulito [C], Modificato [M] e
Manca [!] (come riportato da hg status). Le azioni sono Avvisa, Rimuovi (dal ramo) e
Elimina (dal disco):
?
opt/state │ A │ C │ M │ ! ?
?
│nessuno │ W │ RD │ W │ R │
?
│-f │ R │ RD │ RD │ R │
?
│-LA │ W │ W │ W │ R │
?
│-Af │ R │ R │ R │ R │
?
Note: hg rimuovere non elimina mai i file nello stato Aggiunto [A] dalla directory di lavoro, no
anche se --vigore è specificato.
Restituisce 0 in caso di successo, 1 se vengono rilevati avvisi.
Opzioni:
-UN, --dopo
registra l'eliminazione per i file mancanti
-F, --vigore
rimuovere (ed eliminare) il file anche se aggiunto o modificato
-S, --sottorepos
ricorrono in sottorepository
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
alias: rm
rinominare
rinominare i file; equivalente di copia + rimuovi:
hg rinomina [OPZIONE]... SORGENTE... DEST
Contrassegna destinazione come copie di fonti; contrassegnare le fonti per l'eliminazione. Se dest è una directory, copie
vengono inseriti in quella directory. Se dest è un file, può esserci solo un'origine.
Per impostazione predefinita, questo comando copia il contenuto dei file così come esistono nel lavoro
directory. Se invocato con -A/--after, l'operazione viene registrata, ma non viene eseguita alcuna copia
eseguita.
Questo comando ha effetto al prossimo commit. Per annullare una ridenominazione precedente, vedere hg ritornare.
Restituisce 0 in caso di successo, 1 se vengono rilevati errori.
Opzioni:
-UN, --dopo
registrare una ridenominazione che è già avvenuta
-F, --vigore
copiare forzatamente su un file gestito esistente
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
[+] l'opzione contrassegnata può essere specificata più volte
alias: sposta mv
risolvere
ripetere le unioni o impostare/visualizzare lo stato di unione dei file:
hg risolve [OPZIONE]... [FILE]...
Le unioni con conflitti irrisolti sono spesso il risultato di unioni non interattive che utilizzano il
interno:unione impostazione di configurazione o uno strumento di unione della riga di comando come diff3. La determinazione
comando viene utilizzato per gestire i file coinvolti in un'unione, dopo hg unire è stato eseguito, e
prima hg commettere viene eseguito (cioè la directory di lavoro deve avere due genitori). Vedere hg Aiuto
strumenti di fusione per informazioni sulla configurazione degli strumenti di unione.
Il comando resolve può essere utilizzato nei seguenti modi:
· hg risolvere [--attrezzo ATTREZZO] FILETTO...: tenta di unire nuovamente i file specificati, scartandoli
eventuali precedenti tentativi di unione. La riunione non viene eseguita per i file già contrassegnati come
risolto. Uso --tutti/-a per selezionare tutti i file non risolti. --attrezzo può essere utilizzato per specificare il
strumento di unione utilizzato per i file forniti. Sostituisce la variabile d'ambiente HGMERGE e
i tuoi file di configurazione Il contenuto del file precedente viene salvato con a .origine suffisso.
· hg risolvere -m [FILE]: contrassegna un file come risolto (ad es. dopo averlo manualmente
sistemati i file). L'impostazione predefinita è contrassegnare tutti i file non risolti.
· hg risolvere -u [FILE]...: contrassegna un file come non risolto. L'impostazione predefinita è contrassegnare tutto come risolto
File.
· hg risolvere -l: elenca i file che hanno avuto o hanno ancora conflitti. Nella lista stampata, U =
irrisolto e R = risolto.
Nota Mercurial non ti consentirà di eseguire il commit di file con conflitti di unione non risolti. Devi
uso hg risolvere -m ... prima di poter eseguire il commit dopo un'unione in conflitto.
Restituisce 0 in caso di successo, 1 se alcuni file falliscono un tentativo di risoluzione.
Opzioni:
-un, --tutti
seleziona tutti i file non risolti
-l, --elenco
elenca lo stato dei file che necessitano di unione
-M, --segnare
contrassegna i file come risolti
-tu, --deselezionare
contrassegna i file come irrisolti
-N, --nessuno Stato
nascondi il prefisso di stato
-T,--attrezzo
specificare lo strumento di unione
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-T,--modello
display con template (SPERIMENTALE)
[+] l'opzione contrassegnata può essere specificata più volte
ritornare
ripristinare i file al loro stato di checkout:
hg revert [OPZIONE]... [-r REV] [NOME]...
Nota Per controllare le revisioni precedenti, dovresti usare hg update REV. Per cancellare un
unione non confermata (e perdi le modifiche), usa hg update --pulire ..
Senza alcuna revisione specificata, ripristina i file o le directory specificati ai contenuti che hanno
aveva nel genitore della directory di lavoro. Questo ripristina il contenuto dei file su un
stato non modificato e non pianificato aggiunge, rimuove, copia e rinomina. Se il lavoro
directory ha due genitori, è necessario specificare esplicitamente una revisione.
Usando le opzioni -r/--rev o -d/--date, ripristina i file o le directory specificati nella loro
afferma a partire da una specifica revisione. Perché il ripristino non cambia la directory di lavoro
genitori, questo farà apparire questi file modificati. Questo può essere utile per "tirarsi indietro"
alcune o tutte le modifiche precedenti. Vedere hg indietro per un metodo correlato.
I file modificati vengono salvati con un suffisso .orig prima di essere ripristinati. Per disabilitare questi backup,
usa --no-backup.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
See hg Aiuto indietro per un modo per invertire l'effetto di un changeset precedente.
Restituisce 0 in caso di successo.
Opzioni:
-un, --tutti
ripristina tutte le modifiche quando non vengono forniti argomenti
-D,--Data
data di corrispondenza della revisione più importante
-R,--rev
tornare alla revisione specificata
-C, --nessun backup
non salvare copie di backup dei file
-io, --interattivo
selezionare interattivamente le modifiche (SPERIMENTALE)
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
[+] l'opzione contrassegnata può essere specificata più volte
rollback
eseguire il rollback dell'ultima transazione (PERICOLOSA) (DEPRECATA):
hg rollback
Si prega di utilizzare hg commettere --modifica invece del rollback per correggere gli errori nell'ultimo commit.
Questo comando deve essere usato con cautela. C'è solo un livello di rollback, e c'è
nessun modo per annullare un rollback. Ripristinerà anche il dirstate al momento dell'ultimo
transazione, perdendo da quel momento qualsiasi modifica dirstate. Questo comando non altera il
directory di lavoro.
Le transazioni sono usate per incapsulare gli effetti di tutti i comandi che creano nuovi
changeset o propagare i changeset esistenti in un repository.
Ad esempio, i seguenti comandi sono transazionali e i loro effetti possono essere rollati
indietro:
· commettere
· importare
· tiro
· push (con questo repository come destinazione)
· disaggregare
Per evitare la perdita permanente dei dati, il rollback rifiuterà di eseguire il rollback di una transazione di commit se
non è verificato. Usa --force per ignorare questa protezione.
Questo comando non è destinato all'uso su repository pubblici. Una volta che le modifiche sono visibili per
pull da altri utenti, il rollback di una transazione localmente non è efficace (qualcun altro potrebbe
hanno già ritirato le modifiche). Inoltre è possibile una gara con i lettori del
deposito; ad esempio, un pull in corso dal repository potrebbe non riuscire se viene eseguito un rollback
eseguita.
Restituisce 0 in caso di successo, 1 se non sono disponibili dati di rollback.
Opzioni:
-N, --funzionamento a secco
non eseguire azioni, stampa solo l'output
-F, --vigore
ignorare le misure di sicurezza
radice
stampa la radice (in alto) della directory di lavoro corrente:
hg radice
Stampa la directory principale del repository corrente.
Restituisce 0 in caso di successo.
servire
avvia un server web autonomo:
hg serve [OPZIONE]...
Avvia un browser di repository HTTP locale e pull server. Puoi usarlo per la condivisione ad hoc
e la navigazione dei repository. Si consiglia di utilizzare un vero server web per servire a
deposito per periodi di tempo più lunghi.
Si prega di notare che il server non implementa il controllo degli accessi. Ciò significa che, per
per impostazione predefinita, chiunque può leggere dal server e nessuno può scriverci sopra. Impostare il
web.allow_push opzione a * per consentire a tutti di eseguire il push al server. Dovresti usare un vero
server web se è necessario autenticare gli utenti.
Per impostazione predefinita, il server registra gli accessi a stdout e gli errori a stderr. Utilizzare il
-A/--accesslog e -E/--errorlog opzioni per accedere ai file.
Per fare in modo che il server scelga un numero di porta libera su cui ascoltare, specificare un numero di porta pari a 0; in
in questo caso, il server stamperà il numero di porta che utilizza.
Restituisce 0 in caso di successo.
Opzioni:
-UN,--log di accesso
nome del file di registro di accesso su cui scrivere
-D, --demone
esegui il server in background
--daemon-pipefds
usato internamente dalla modalità demone
- Ehi,--errolog
nome del file di registro degli errori su cui scrivere
-P,--porta
porta su cui ascoltare (predefinito: 8000)
-un,--indirizzo
indirizzo su cui ascoltare (predefinito: tutte le interfacce)
--prefisso
percorso del prefisso da cui servire (predefinito: radice del server)
-N,--nome
nome da mostrare nelle pagine web (predefinito: directory di lavoro)
--web-conf
nome del file di configurazione di hgweb (vedi "hg help hgweb")
--webdir-conf
nome del file di configurazione di hgweb (DEPRECATO)
--file-pid
nome del file su cui scrivere l'ID del processo
--stdio
per clienti remoti
--cmdserver
per clienti remoti
-T,--modelli
modelli web da utilizzare
--stile
stile del modello da usare
-6, --ipv6
usa IPv6 oltre a IPv4
--certificato
File del certificato SSL
status
mostra i file modificati nella directory di lavoro:
hg status [OPZIONE]... [FILE]...
Mostra lo stato dei file nel repository. Se vengono dati nomi, solo i file che corrispondono sono
mostrato. I file che sono puliti o ignorati o l'origine di un'operazione di copia/spostamento, non lo sono
elencato a meno che non siano indicati -c/--clean, -i/--ignored, -C/--copies o -A/--all. Salvo opzioni
descritte con "mostra solo ..." vengono fornite, vengono utilizzate le opzioni -mardu.
L'opzione -q/--quiet nasconde i file non tracciati (sconosciuti e ignorati) a meno che non venga richiesto esplicitamente
con -u/--sconosciuto o -i/--ignorato.
Note: hg status potrebbe sembrare in disaccordo con diff se le autorizzazioni sono cambiate o un'unione
è successo. Il formato diff standard non riporta modifiche ai permessi e diff
riporta solo le modifiche relative a un genitore di unione.
Se viene fornita una revisione, viene utilizzata come revisione di base. Se vengono fornite due revisioni,
vengono mostrate le differenze tra loro. L'opzione --change può essere usata anche come scorciatoia
per elencare i file modificati di una revisione dal primo genitore.
I codici utilizzati per mostrare lo stato dei file sono:
M = modificato
A = aggiunto
R = rimosso
C = pulito
! = mancante (cancellato da un comando non-hg, ma ancora tracciato)
? = non tracciato
I = ignorato
= origine del file precedente (con --copies)
Consigli d'uso:
· mostra le modifiche nella directory di lavoro relative a un changeset:
stato hg --rev 9353
· mostra le modifiche nella directory di lavoro rispetto alla directory corrente (vedi hg Aiuto
modelli per maggiori informazioni):
stato hg re:
· mostra tutte le modifiche incluse le copie in un changeset esistente:
hg status --copie --change 9353
· ottenere un elenco separato da NUL di file aggiunti, adatto per xargs:
hg stato -an0
Restituisce 0 in caso di successo.
Opzioni:
-UN, --tutti
mostra lo stato di tutti i file
-M, --modificato
mostra solo i file modificati
-un, --aggiunto
mostra solo i file aggiunti
-R, --RIMOSSO
mostra solo i file rimossi
-D, --cancellato
mostra solo i file cancellati (ma tracciati)
-C, --pulire
mostra solo i file senza modifiche
-tu, --sconosciuto
mostra solo file sconosciuti (non tracciati)
-io, --ignorato
mostra solo i file ignorati
-N, --nessuno Stato
nascondi il prefisso di stato
-C, --copie
mostra l'origine dei file copiati
-0, --print0
terminare i nomi dei file con NUL, per l'uso con xargs
--rev
mostra la differenza dalla revisione
--modificare
elenca i file modificati di una revisione
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-S, --sottorepos
ricorrono in sottorepository
-T,--modello
display con template (SPERIMENTALE)
[+] l'opzione contrassegnata può essere specificata più volte
alias: st
sommario
riepiloga lo stato della directory di lavoro:
hg sommario [--remote]
Questo genera un breve riepilogo dello stato della directory di lavoro, inclusi i genitori, il ramo,
stato del commit, fase e aggiornamenti disponibili.
Con l'opzione --remote, questo controllerà i percorsi predefiniti per l'ingresso e l'uscita
i cambiamenti. Questo può richiedere molto tempo.
Restituisce 0 in caso di successo.
Opzioni:
--a distanza
controlla se spingi e tira
alias: somma
etichetta
aggiungi uno o più tag per la revisione corrente o data:
hg tag [-f] [-l] [-m TESTO] [-d DATA] [-u UTENTE] [-r REV] NOME...
Assegna un nome a una revisione particolare usando .
I tag sono usati per nominare particolari revisioni del repository e sono molto utili per
confrontare diverse revisioni, tornare a versioni precedenti significative o contrassegnare un ramo
punti come rilasci, ecc. La modifica di un tag esistente normalmente non è consentita; usa -f/--force
sovrascrivere.
Se non viene fornita alcuna revisione, viene utilizzato il genitore della directory di lavoro.
Per facilitare il controllo della versione, la distribuzione e l'unione dei tag, vengono archiviati come
file denominato ".hgtags" che è gestito in modo simile ad altri file di progetto e può essere
se necessario modificati a mano. Ciò significa anche che il tagging crea un nuovo commit. Il file
".hg/localtags" viene utilizzato per i tag locali (non condivisi tra i repository).
I commit dei tag vengono solitamente effettuati all'inizio di un ramo. Se il genitore del lavoratore
la directory non è una testata di ramo, hg etichetta aborti; usa -f/--force per forzare il commit del tag a
essere basato su un changeset non capo.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Poiché i nomi dei tag hanno la priorità sui nomi dei rami durante la ricerca delle revisioni, utilizzando un esistente
il nome del ramo come nome di tag è sconsigliato.
Restituisce 0 in caso di successo.
Opzioni:
-F, --vigore
tag di forza
-l, --Locale
rendere il tag locale
-R,--rev
revisione da taggare
--rimuovere
rimuovere un tag
-e, --modificare
invoca l'editor sui messaggi di commit
-M,--Messaggio
usa il testo come messaggio di commit
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
tag
elenca i tag del repository:
tag hg
Questo elenca sia i tag normali che quelli locali. Quando si usa l'opzione -v/--verbose, un terzo
la colonna "local" viene stampata per i tag locali. Quando viene utilizzato l'interruttore -q/--quiet, solo il
viene stampato il nome del tag.
Restituisce 0 in caso di successo.
Opzioni:
-T,--modello
display con template (SPERIMENTALE)
tipo
mostra la revisione della punta (DEPRECATA):
hg punta [-p] [-g]
La revisione del suggerimento (di solito chiamata semplicemente suggerimento) è l'insieme di modifiche aggiunto più di recente al
repository (e quindi l'intestazione modificata più di recente).
Se hai appena effettuato un commit, quel commit sarà il suggerimento. Se hai appena tirato
modifiche da un altro repository, il tip di quel repository diventa il tip corrente. Il
Il tag "tip" è speciale e non può essere rinominato o assegnato a un changeset diverso.
Questo comando è deprecato, per favore usa hg teste anziché.
Restituisce 0 in caso di successo.
Opzioni:
-P, --toppa
mostra la patch
-G, --idiota
usa il formato diff esteso git
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
unbundle
applicare uno o più file changegroup:
hg unbundle [-u] FILE...
Applicare uno o più file changegroup compressi generati dal comando bundle.
Restituisce 0 in caso di successo, 1 se un aggiornamento ha file non risolti.
Opzioni:
-tu, --aggiornare
aggiornamento alla nuova testata del ramo se i changeset sono stati disaggregati
update
aggiorna la directory di lavoro (o cambia le revisioni):
hg update [-c] [-C] [-d DATA] [[-r] REV]
Aggiorna la directory di lavoro del repository con il changeset specificato. Se nessun changeset è
specificato, aggiorna alla punta del ramo con nome corrente e sposta il segnalibro attivo (vedi
hg Aiuto segnalibri).
Aggiorna imposta la revisione padre della directory di lavoro sul changeset specificato (vedi hg
Aiuto genitori).
Se il changeset non è un discendente o un antenato del genitore della directory di lavoro, il
l'aggiornamento viene interrotto. Con l'opzione -c/--check, viene controllata la directory di lavoro
modifiche non impegnate; se non ne viene trovato nessuno, la directory di lavoro viene aggiornata a quella specificata
set di modifiche.
Le seguenti regole si applicano quando la directory di lavoro contiene modifiche non salvate:
1. Se non è specificato né -c/--check né -C/--clean e se il changeset richiesto è an
antenato o discendente del genitore della directory di lavoro, le modifiche non salvate sono
unito al changeset richiesto e il risultato unito non viene salvato. Se la
il changeset richiesto non è un antenato o un discendente (cioè è su un altro
branch), l'aggiornamento viene interrotto e le modifiche non salvate vengono conservate.
2. Con l'opzione -c/--check, l'aggiornamento viene interrotto e le modifiche non salvate sono
conservato.
3. Con l'opzione -C/--clean, le modifiche non salvate vengono scartate e la directory di lavoro
viene aggiornato al changeset richiesto.
Per annullare un'unione non salvata (e perdere le modifiche), utilizzare hg update --pulire ..
Usa null come changeset per rimuovere la directory di lavoro (come hg clonare -U).
Se vuoi ripristinare solo un file a una revisione precedente, usa hg ritornare [-R REV] NOME.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Restituisce 0 in caso di successo, 1 se sono presenti file non risolti.
Opzioni:
-C, --pulire
scarta le modifiche non salvate (nessun backup)
-C, --dai un'occhiata
aggiornamento tra le filiali se non ci sono modifiche non confermate
-D,--Data
data di corrispondenza della revisione più importante
-R,--rev
revisione
-T,--attrezzo
specificare lo strumento di unione
alias: su checkout co
verificare
verificare l'integrità del repository:
hg verifica
Verificare l'integrità del repository corrente.
Questo eseguirà un controllo approfondito dell'integrità del repository, convalidando gli hash
e checksum di ogni voce nel log delle modifiche, manifest e file tracciati, così come il
integrità dei loro collegamenti incrociati e indici.
Si prega di consultare https://mercurial-scm.org/wiki/RepositoryCorruption per ulteriori informazioni su
ripristino dalla corruzione del repository.
Restituisce 0 in caso di successo, 1 se vengono rilevati errori.
versione
versione di output e informazioni sul copyright:
versione hg
versione di output e informazioni sul copyright
DATA FORMATI
Alcuni comandi consentono all'utente di specificare una data, ad esempio:
· backout, commit, import, tag: specificare la data di commit.
· Registra, ripristina, aggiorna: Seleziona le revisioni per data.
Sono validi molti formati di data. Ecco alcuni esempi:
· Mer. Dicembre 6 13:18:29 2006 (si presume il fuso orario locale)
· Dicembre 6 13:18 all'0600 ottobre (anno presunto, offset temporale fornito)
· Dicembre 6 13:18 UTC (UTC e GMT sono alias per +0000)
· Dicembre 6 (mezzanotte)
· 13:18 (oggi ipotizzato)
· 3:39 (3:39 si presume)
· 3: 39pm (15: 39)
· 2006-12-06 13:18:29 (formato ISO 8601)
· 2006-12-6 13:18
· 2006-12-6
· 12-6
· 12/6
· 12/6/6 (6 dic 2006)
· oggi (mezzanotte)
· ieri (mezzanotte)
· adesso - proprio adesso
Infine, c'è il formato interno di Mercurial:
· 1165411109 0 (mer 6 dic 13:18:29 2006 UTC)
Questo è il formato di rappresentazione interna per le date. Il primo numero è il numero di
secondi dall'epoca (1970-01-01 00:00 UTC). Il secondo è l'offset del locale
fuso orario, in secondi a ovest dell'UTC (negativo se il fuso orario è a est dell'UTC).
Il comando log accetta anche intervalli di date:
· <DATA - alla o prima di una determinata data/ora
· >DATA - in o dopo una determinata data/ora
· DATA a DATA - un intervallo di date, compreso
· -GIORNI - entro un determinato numero di giorni da oggi
DIFF FORMATI
Il formato predefinito di Mercurial per mostrare i cambiamenti tra due versioni di un file è
compatibile con il formato unificato di GNU diff, che può essere utilizzato da GNU patch e molti
altri strumenti standard.
Sebbene questo formato standard sia spesso sufficiente, non codifica le seguenti informazioni:
· stato eseguibile e altri bit di autorizzazione
· copiare o rinominare le informazioni
· modifiche nei file binari
· creazione o cancellazione di file vuoti
Mercurial supporta anche il formato diff esteso dal git VCS che si occupa di questi
limitazioni. Il formato git diff non viene prodotto di default a causa di alcuni strumenti diffusi
ancora non capisco questo formato.
Ciò significa che quando si generano differenze da un repository Mercurial (ad esempio con hg export),
dovresti stare attento a cose come copie e rinomina di file o altre cose menzionate
sopra, perché quando si applica una differenza standard a un repository diverso, questo extra
le informazioni sono perse. Le operazioni interne di Mercurial (come push and pull) non sono interessate
da questo, perché usano un formato binario interno per comunicare i cambiamenti.
Per fare in modo che Mercurial produca il formato git extended diff, usa l'opzione --git disponibile per
molti comandi, o imposta 'git = True' nella sezione [diff] del tuo file di configurazione. Voi
non è necessario impostare questa opzione quando si importano differenze in questo formato o si utilizzano nel mq
estensione.
AMBIENTE VARIABILI
HG Percorso dell'eseguibile 'hg', passato automaticamente durante l'esecuzione di hook, estensioni o
strumenti esterni. Se non impostato o vuoto, questo è il nome dell'eseguibile hg se è bloccato,
o un eseguibile chiamato 'hg' (con %PATHEXT% [predefinito su COM/EXE/BAT/CMD]
estensioni su Windows) viene cercata.
HGEDITORE
Questo è il nome dell'editor da eseguire durante il commit. Vedi EDITORE.
(deprecato, usa il file di configurazione)
CODIFICA HGEN
Questo sovrascrive l'impostazione locale predefinita rilevata da Mercurial. Questa impostazione è
utilizzato per convertire i dati inclusi nomi utente, descrizioni di changeset, nomi di tag e
rami. Questa impostazione può essere sovrascritta con l'opzione della riga di comando --encoding.
HGENCODINGMODAL
Questo imposta il comportamento di Mercurial per la gestione dei caratteri sconosciuti durante la transcodifica
input dell'utente. L'impostazione predefinita è "strict", che fa sì che Mercurial abortisca se non può farlo
mappare un personaggio. Altre impostazioni includono "sostituisci", che sostituisce sconosciuto
caratteri e "ignora", che li elimina. Questa impostazione può essere sovrascritta con il
--encodingmode opzione della riga di comando.
HGENCODINGAMBIGUO
Questo imposta il comportamento di Mercurial per la gestione dei caratteri con larghezze "ambigue" come
caratteri latini accentati con caratteri dell'Asia orientale. Per impostazione predefinita, Mercurial presume
i caratteri ambigui sono stretti, imposta questa variabile su "largo" se tali caratteri
causare problemi di formattazione.
HGMERGE
Un eseguibile da utilizzare per risolvere i conflitti di unione. Il programma verrà eseguito
con tre argomenti: file locale, file remoto, file antenato.
(deprecato, usa il file di configurazione)
HGRCPATH
Un elenco di file o directory in cui cercare i file di configurazione. Il separatore di elementi è
":" su Unix, ";" Su Windows. Se HGRCPATH non è impostato, percorso di ricerca predefinito della piattaforma
si usa. Se vuoto, viene letto solo il file .hg/hgrc del repository corrente.
Per ogni elemento in HGRCPATH:
· se è una directory, vengono aggiunti tutti i file che terminano con .rc
· in caso contrario, verrà aggiunto il file stesso
HGPLAIN
Quando impostato, disabilita tutte le impostazioni di configurazione che potrebbero cambiare Mercurial's
uscita predefinita. Ciò include la codifica, le impostazioni predefinite, la modalità dettagliata, la modalità di debug, la quiete
modalità, traceback e localizzazione. Questo può essere utile quando si esegue lo scripting contro
Mercurial rispetto alla configurazione utente esistente.
Le opzioni equivalenti impostate tramite flag della riga di comando o variabili di ambiente non lo sono
sovrascritto.
HGPLAINEEXCEPT
Questo è un elenco di funzionalità separate da virgole da preservare quando HGPLAIN è abilitato.
Attualmente sono supportati i seguenti valori:
alias
Non rimuovere gli alias.
i18n
Preservare l'internazionalizzazione.
revsetalie
Non rimuovere gli alias di revset.
L'impostazione di HGPLAINEXCEPT su qualsiasi cosa (anche una stringa vuota) abiliterà la modalità normale.
HGUSER Questa è la stringa utilizzata come autore di un commit. Se non impostato, valori disponibili
saranno considerati in questo ordine:
· HGUSER (obsoleto)
· file di configurazione da HGRCPATH
· prompt interattivo
· LOGNAME (con @Nome host in allegato)
(deprecato, usa il file di configurazione)
E-MAIL Può essere utilizzato come autore di un commit; vedi HGUSER.
NOMELOGO
Può essere utilizzato come autore di un commit; vedi HGUSER.
VISIVO Questo è il nome dell'editor da utilizzare durante il commit. Vedi EDITORE.
EDITOR A volte Mercurial ha bisogno di aprire un file di testo in un editor affinché un utente possa modificarlo,
per esempio quando si scrivono messaggi di commit. L'editor che usa è determinato da
guardando le variabili d'ambiente HGEDITOR, VISUAL e EDITOR, in questo ordine.
Viene scelto il primo non vuoto. Se sono tutti vuoti, l'editor per impostazione predefinita è
'editore sensibile'.
PITONE PERCORSO
Questo è usato da Python per trovare i moduli importati e potrebbe dover essere impostato
in modo appropriato se questo Mercurial non è installato a livello di sistema.
UTILIZZO SUPPLEMENTARI CARATTERISTICHE
Mercurial ha la capacità di aggiungere nuove funzionalità attraverso l'uso di estensioni. estensioni
può aggiungere nuovi comandi, aggiungere opzioni a comandi esistenti, modificare il comportamento predefinito di
comandi o implementare hook.
Per abilitare l'estensione "foo", fornita con Mercurial o nel percorso di ricerca di Python,
crea una voce per esso nel tuo file di configurazione, in questo modo:
[estensioni]
pippo =
Puoi anche specificare il percorso completo di un'estensione:
[estensioni]
mia caratteristica = ~/.hgext/myfeature.py
See hg Aiuto config per ulteriori informazioni sui file di configurazione.
Le estensioni non vengono caricate di default per una serie di motivi: possono aumentare l'avvio
spese generali; possono essere pensati solo per uso avanzato; possono fornire potenzialmente
abilità pericolose (come permetterti di distruggere o modificare la storia); potrebbero non essere
pronto per la prima serata; oppure possono alterare alcuni comportamenti usuali di Mercurial stock. è
quindi spetta all'utente attivare le estensioni secondo necessità.
Per disabilitare in modo esplicito un'estensione abilitata in un file di configurazione di ambito più ampio,
anteponi il suo percorso con !:
[estensioni]
# disabilitare la barra di estensione che risiede in /path/to/extension/bar.py
bar = !/percorso/a/estensione/bar.py
# idem, ma non è stato fornito alcun percorso per l'estensione baz
bazz = !
estensioni disabilitate:
ACL ganci per il controllo dell'accesso al repository
scatola nera
registra gli eventi del repository in una blackbox per il debug
bugzilla
ganci per l'integrazione con Bugzilla bug tracker
censurare cancella il contenuto del file a una data revisione
zangola comando per visualizzare le statistiche sulla cronologia del repository
clonebundle
pubblicizzare bundle pre-generati per seminare cloni
colore colora l'output di alcuni comandi
convertire
importare revisioni da repository VCS esteri in Mercurial
eol gestire automaticamente le nuove righe nei file del repository
extdiff
comando per consentire ai programmi esterni di confrontare le revisioni
factotum
Autenticazione http con factotum
gpg comandi per firmare e verificare i changeset
hcia ganci per l'integrazione con il servizio di notifica CIA.vc
HGK sfoglia il repository in modo grafico
evidenziare
evidenziazione della sintassi per hgweb (richiede Pygments)
storico
modifica della cronologia interattiva
parola chiave
espandere le parole chiave nei file monitorati
file di grandi dimensioni
tenere traccia di file binari di grandi dimensioni
mq gestire una pila di patch
notificare ganci per l'invio di notifiche push e-mail
cercapersone sfoglia l'output del comando con un cercapersone esterno
patchbomba
comando per inviare i changeset come (una serie di) email di patch
purga comando per eliminare i file non tracciati dalla directory di lavoro
rebase comando per spostare serie di revisioni su un antenato diverso
record comandi per selezionare in modo interattivo le modifiche per commit/qrefresh
ricollegare ricrea i collegamenti fisici tra i cloni del repository
schemi
estendere gli schemi con collegamenti agli sciami di repository
Share condividere una storia comune tra diverse directory di lavoro
accantonare salvare e ripristinare le modifiche alla directory di lavoro
striscia spogliare i changeset e i loro discendenti dalla storia
trapianto
comando per trapiantare i changeset da un altro ramo
win32mbcs
consentire l'uso di percorsi MBCS con codifiche problematiche
zeroconf
scoprire e pubblicizzare i repository sulla rete locale
SPECIFICANDO RISORSE SETS
Mercurial supporta un linguaggio funzionale per la selezione di un insieme di file.
Come altri modelli di file, questo tipo di modello è indicato da un prefisso, 'set:'. La lingua
supporta un numero di predicati uniti da operatori infissi. La parentesi può essere
utilizzato per il raggruppamento.
Identificatori come nomi di file o modelli devono essere citati con virgolette singole o doppie se
contengono caratteri al di fuori di [.*{}[]?/\_a-zA-Z0-9\x80-\xff] o se corrispondono a uno di
i predicati predefiniti. Questo generalmente si applica ai modelli di file diversi dai glob e
argomenti per i predicati.
I caratteri speciali possono essere utilizzati negli identificatori tra virgolette mediante l'escape, ad es. \n is
interpretato come una nuova riga. Per evitare che vengano interpretate, le stringhe possono essere precedute
con r, per esempio R'...'.
Esiste un unico operatore di prefisso:
non x
File non in x. La forma breve è ! x.
Questi sono gli operatori infissi supportati:
x ed y
L'intersezione dei file in x e y. La forma breve è x & y.
x or y
L'unione dei file in x e y. Esistono due forme brevi alternative: x | y ed x +
y.
x - y
File in x ma non in y.
Sono supportati i seguenti predicati:
aggiunto()
File che viene aggiunto in base a hg status.
binario()
File che sembra essere binario (contiene byte NUL).
pulito()
File che è pulito secondo hg status.
copiato()
File registrato come copiato.
cancellato()
Alias per mancante().
codifica (nome)
Il file può essere decodificato con successo con la codifica dei caratteri data. Potrebbe non essere
utile per codifiche diverse da ASCII e UTF-8.
eol (stile)
Il file contiene le nuove righe dello stile specificato (dos, unix, mac). I file binari sono
esclusi, i file con terminazioni di riga miste corrispondono a più stili.
exec ()
File contrassegnato come eseguibile.
grep (regex)
Il file contiene l'espressione regolare data.
ignorare()
File che corrisponde al modello .hgignore attivo.
ignorato()
File che viene ignorato in base a hg status. Questi file verranno presi in considerazione solo se
si usa questo predicato.
mancante()
File mancante secondo hg status.
modificati()
File che viene modificato in base a hg status.
portatile()
File che ha un nome portatile. (Questo non include i nomi di file con maiuscole e minuscole
collisioni.)
RIMOSSO()
File che viene rimosso in base a hg status.
risolto()
File contrassegnato come risolto in base a hg risolvere -l.
dimensione (espressione)
La dimensione del file corrisponde all'espressione data. Esempi:
· 1k (file da 1024 a 2047 byte)
· < 20k (file inferiori a 20480 byte)
· >= 5 MB (file di almeno 524288 byte)
· 4k - 1MB (file da 4096 byte a 1048576 byte)
subrepo([schema])
Sottorepository i cui percorsi corrispondono al modello specificato.
collegamento simbolico()
File contrassegnato come collegamento simbolico.
sconosciuto()
File sconosciuto secondo hg status. Questi file verranno presi in considerazione solo se
si usa questo predicato.
irrisolto()
File contrassegnato come non risolto in base a hg risolvere -l.
Alcune query di esempio:
· Mostra lo stato dei file che sembrano essere binari nella directory di lavoro:
hg status -A "set:binary()"
· Dimentica i file che sono in .hgignore ma sono già tracciati:
hg forget "set:hgignore() e non ignorato()"
· Trova file di testo che contengono una stringa:
hg file "imposta:grep(magico) e non binario()"
· Trova file C in una codifica non standard:
hg files "set:**.c and not encoding('UTF-8')"
· Ripristina copie di file binari di grandi dimensioni:
hg revert "set:copied() e binary() e size('>1M')"
· Rimuovere i file elencati in foo.lst che contengono la lettera aob:
hg remove "set: 'listfile:foo.lst' e (**a* o **b*)"
Vedi anche hg Aiuto modelli.
GLOSSARIO
Antenato
Qualsiasi changeset che può essere raggiunto da una catena ininterrotta di changeset padre da a
dato changeset. Più precisamente, gli antenati di un changeset possono essere definiti da due
proprietà: un genitore di un changeset è un antenato e un genitore di un antenato è
un antenato. Vedi anche: 'Discendente'.
Segnalibro
I segnalibri sono puntatori a determinati commit che si spostano durante il commit. Sono
simile ai tag in quanto è possibile utilizzare i nomi dei segnalibri in tutti i luoghi in cui
Mercurial si aspetta un ID changeset, ad esempio con hg update. A differenza dei tag, i segnalibri si spostano
insieme quando fai un commit.
I segnalibri possono essere rinominati, copiati ed eliminati. I segnalibri sono locali, a meno che non lo siano
spinto o tirato esplicitamente tra i repository. Spingere e tirare i segnalibri
consentono di collaborare con altri su un ramo senza creare un ramo denominato.
Branch di società (Sostantivo) Un changeset figlio che è stato creato da un genitore che non è una testa.
Questi sono noti come rami topologici, vedere 'Ramo, topologico'. Se un
ramo topologico è denominato, diventa un ramo denominato. Se un ramo topologico è
non nominato, diventa un ramo anonimo. Vedi 'Filiale, anonimo' e 'Filiale,
di nome'.
È possibile creare rami quando le modifiche vengono prelevate o inviate a un dispositivo remoto
repository, poiché queste operazioni possono creare nuove teste. Nota che il termine
ramo può anche essere usato informalmente per descrivere un processo di sviluppo in cui
certo sviluppo è fatto indipendentemente da altri sviluppi. Questo è a volte
fatto esplicitamente con un ramo denominato, ma può anche essere fatto localmente, usando
segnalibri o cloni e rami anonimi.
Esempio: "Il ramo sperimentale".
(Verbo) L'azione di creare un changeset figlio che fa sì che il genitore abbia
più di un bambino.
Esempio: "Sto andando a ramificare a X."
Ramo, anonimo
Ogni volta che viene creato un nuovo changeset figlio da un genitore che non è una testa e
il nome del ramo non viene modificato, viene creato un nuovo ramo anonimo.
Ramo, chiuso
Un ramo con nome le cui testate sono state tutte chiuse.
Ramo, difetto
Il ramo assegnato a un changeset quando non è stato precedentemente assegnato alcun nome.
Branch di società capo
Vedi 'Testa, ramo'.
Ramo, inattivo
Se un ramo denominato non ha teste topologiche, è considerato inattivo. come un
esempio, un ramo di funzioni diventa inattivo quando viene unito all'impostazione predefinita
ramo. Il hg rami Il comando mostra i rami inattivi per impostazione predefinita, anche se possono
essere nascosto con hg rami --attivo.
NOTA: questo concetto è deprecato perché troppo implicito. I rami dovrebbero ora
essere esplicitamente chiuso usando hg commettere --chiudi-ramo quando non sono più necessari.
Ramo, detto
Una raccolta di changeset che hanno lo stesso nome di ramo. Per impostazione predefinita, i figli di
un changeset in un ramo denominato appartiene allo stesso ramo denominato. Un bambino può essere
esplicitamente assegnato a un altro ramo. Vedere hg Aiuto ramo, hg Aiuto rami ed
hg commettere --chiudi-ramo per maggiori informazioni sulla gestione delle filiali.
I rami con nome possono essere pensati come una sorta di spazio dei nomi, che divide la raccolta di
changeset che compongono il repository in una raccolta di sottoinsiemi disgiunti. UN
il ramo denominato non è necessariamente un ramo topologico. Se un nuovo ramo denominato è
creato dalla testa di un altro ramo denominato, o il ramo predefinito, ma no
ulteriori changeset vengono aggiunti a quel ramo precedente, quindi a quel ramo precedente
sarà una filiale solo di nome.
Branch di società tipo
Vedi 'Suggerimento, ramo'.
Ramo, topologica
Ogni volta che viene creato un nuovo changeset figlio da un genitore che non è una testa, un nuovo
viene creato il ramo topologico. Se un ramo topologico è nominato, diventa un nome
ramo. Se un ramo topologico non viene nominato, diventa un ramo anonimo del
ramo corrente, possibilmente predefinito.
changelog
Un record delle serie di modifiche nell'ordine in cui sono state aggiunte al repository.
Ciò include dettagli come l'ID del changeset, l'autore, il messaggio di commit, la data e l'elenco
dei file modificati.
Set di modifiche
Uno snapshot dello stato del repository utilizzato per registrare una modifica.
Modifica, bambino
Il contrario del changeset genitore: se P è un genitore di C, allora C è un figlio di P.
Non c'è limite al numero di figli che può avere un changeset.
Set di modifiche id
Un hash SHA-1 che identifica in modo univoco un changeset. Può essere rappresentato come
una stringa "lunga" di 40 cifre esadecimali o una stringa "corta" di 12 cifre esadecimali.
Modifica, unire
Un changeset con due genitori. Ciò si verifica quando viene eseguito il commit di un'unione.
Modifica, genitore
Una revisione su cui si basa un changeset figlio. Nello specifico, un changeset genitore
di un changeset C è un changeset il cui nodo precede immediatamente C nel DAG.
I changeset hanno al massimo due genitori.
Procedi all'acquisto
(Sostantivo) La directory di lavoro in fase di aggiornamento a una revisione specifica. Questo uso dovrebbe
probabilmente essere evitato ove possibile, poiché il changeset è molto più appropriato di
check out in questo contesto.
Esempio: "Sto usando il checkout X."
(Verbo) Aggiornamento della directory di lavoro a un changeset specifico. Vedere hg Aiuto update.
Esempio: "Vado a controllare il changeset X."
Bambino changeset
Vedi 'Changeset, bambino'.
Chiudi changeset
Vedi 'Testa, ramo chiuso'.
Chiuso ramo
Vedi 'Filiale, chiusa'.
clone (Sostantivo) Una copia intera o parziale di un repository. Il clone parziale deve essere nella
forma di una revisione e dei suoi antenati.
Esempio: "Il tuo clone è aggiornato?"
(Verbo) Il processo di creazione di un clone, usando hg clonare.
Esempio: "Clonerò il repository."
Chiuso ramo capo
Vedi 'Testa, ramo chiuso'.
Commettere (Sostantivo) Sinonimo di changeset.
Esempio: "Il bug è stato corretto nel tuo recente commit?"
(Verbo) L'atto di registrare le modifiche in un repository. Quando i file sono impegnati in a
directory di lavoro, Mercurial trova le differenze tra i file sottoposti a commit e
il loro changeset genitore, creando un nuovo changeset nel repository.
Esempio: "Dovresti confermare le modifiche ora".
Cset Abbreviazione comune del termine changeset.
GIORNO Il repository dei changeset di un DVCS (Distributed Version Control System) può essere
descritto come un grafo aciclico diretto (DAG), costituito da nodi e archi, dove
i nodi corrispondono ai changeset e gli archi implicano una relazione genitore -> figlio. Questo
grafico può essere visualizzato da strumenti grafici come hg ceppo --grafico. In Mercuriale,
il DAG è limitato dal requisito per i bambini di avere al massimo due genitori.
deprecato
Funzionalità rimossa dalla documentazione, ma non pianificata per la rimozione.
Predefinito ramo
Vedere 'Ramo, impostazione predefinita'.
discendente
Qualsiasi changeset che può essere raggiunto da una catena di changeset figlio da un dato
set di modifiche. Più precisamente, i discendenti di un changeset possono essere definiti da due
proprietà: il figlio di un changeset è un discendente e il figlio di un discendente
è un discendente. Vedi anche: 'Antenato'.
Diff (Sostantivo) La differenza tra i contenuti e gli attributi dei file in due
changeset o un changeset e la directory di lavoro corrente. La differenza è
solitamente rappresentato in una forma standard chiamata "diff" o "patch". Il "git diff"
formato viene utilizzato quando le modifiche includono copie, rinomina o modifiche al file
attributi, nessuno dei quali può essere rappresentato/gestito dai classici "diff" e "patch".
Esempio: "Hai visto la mia correzione nel diff?"
(Verbo) Diffing due changeset è l'azione di creare un diff o una patch.
Esempio: "Se diffondi con changeset X, vedrai cosa intendo."
Elenco, lavoro
La directory di lavoro rappresenta lo stato dei file tracciati da Mercurial, che
verrà registrato nel prossimo commit. La directory di lavoro inizialmente corrisponde a
l'istantanea su un changeset esistente, noto come genitore della lavorazione
directory. Vedere 'Genitore, directory di lavoro'. Lo stato può essere modificato da modifiche a
i file introdotti manualmente o da una fusione. I metadati del repository esistono nel
.hg directory all'interno della directory di lavoro.
Pescaggio Le modifiche nella fase di bozza non sono state condivise con i repository di pubblicazione e
può quindi essere modificato in modo sicuro da estensioni che modificano la cronologia. Vedere hg Aiuto fasi.
Sperimentale
Funzionalità che potrebbe cambiare o essere rimossa in un secondo momento.
Grafico Vedere DAG e hg ceppo --grafico.
Head Il termine 'head' può essere usato per riferirsi sia a un branch head che a un repository head,
a seconda del contesto. Vedi 'Head, branch' e 'Head, repository' per specifiche
definizioni.
Le teste sono il luogo in cui generalmente avviene lo sviluppo e sono i soliti obiettivi per
operazioni di aggiornamento e unione.
Capo, ramo
Un changeset senza discendenti sullo stesso ramo denominato.
Capo, chiuso ramo
Un changeset che segna una testa come non più interessante. La testa chiusa è no
più elencato da hg teste. Un ramo si considera chiuso quando tutte le sue teste lo sono
chiuso e di conseguenza non è elencato da hg rami.
Le teste chiuse possono essere riaperte eseguendo il commit di un nuovo changeset come figlio del
changeset che contrassegna una testa come chiusa.
Capo, deposito
Una testa topologica che non è stata chiusa.
Capo, topologica
Un changeset senza figli nel repository.
Storia, immutabile
Una volta confermati, i changeset non possono essere modificati. Estensioni che sembrano cambiare
la cronologia in realtà crea nuovi set di modifiche che sostituiscono quelli esistenti e quindi li distruggono
i vecchi changeset. Farlo nei repository pubblici può causare vecchi set di modifiche
essere reintrodotto nel repository.
Storia, riscrittura
I changeset in un repository sono immutabili. Tuttavia, le estensioni a Mercurial possono
essere usato per alterare il repository, di solito in modo tale da preservare il changeset
contenuto.
Immutabile storia
Vedi 'Storia, immutabile'.
Unire changeset
Vedi 'Modifica, unisci'.
Manifesto
Ogni changeset ha un manifest, che è l'elenco dei file che vengono tracciati dal
set di modifiche.
Unire Utilizzato per riunire rami di lavoro divergenti. Quando aggiorni a un changeset
e poi unisci un altro changeset, porti la cronologia di quest'ultimo changeset
nella tua directory di lavoro. Una volta che i conflitti sono stati risolti (e contrassegnati), questa unione
può essere eseguito il commit come un insieme di modifiche di unione, riunendo due rami nel DAG.
Detto ramo
Vedere 'Ramo, denominato'.
Nullo changeset
Il changeset vuoto. È lo stato padre dei repository appena inizializzati e
repository senza revisione estratta. È quindi il genitore di root changeset
e l'antenato effettivo quando si uniscono changeset non correlati. Può essere specificato da
l'alias 'null' o dall'ID changeset '000000000000'.
Genitore Vedi 'Set di modifiche, genitore'.
Genitore changeset
Vedi 'Set di modifiche, genitore'.
Genitore, lavoro elenco
Il genitore della directory di lavoro riflette una revisione virtuale che è il figlio del
changeset (o due changeset con un'unione non salvata) mostrato da hg genitori. Questo
è cambiato con hg update. Altri comandi per vedere la directory di lavoro genitore sono
hg sommario ed hg id. Può essere specificato dall'alias ".".
Toppa (Sostantivo) Il prodotto di un'operazione diff.
Esempio: "Ti ho inviato la mia patch".
(Verbo) Il processo di utilizzo di un file di patch per trasformare un changeset in un altro.
Esempio: "Dovrai correggere quella revisione."
Fase Uno stato per changeset che tiene traccia di come il changeset è stato o dovrebbe essere condiviso. Vedere
hg Aiuto fasi.
Pubblico Le modifiche nella fase pubblica sono state condivise con i repository di pubblicazione e
sono quindi considerati immutabili. Vedere hg Aiuto fasi.
Tirare Un'operazione in cui changeset in un repository remoto che non sono nel locale
repository vengono portati nel repository locale. Notare che questa operazione senza
argomenti speciali aggiorna solo il repository, non aggiorna i file nel
directory di lavoro. Vedere hg Aiuto tirare.
Spingi Un'operazione in cui changeset in un repository locale che non sono in un remoto
repository vengono inviati al repository remoto. Nota che questa operazione aggiunge solo
changeset che sono stati salvati localmente nel repository remoto. non impegnato
le modifiche non vengono inviate. Vedere hg Aiuto spingere.
Repository
I metadati che descrivono tutti gli stati registrati di una raccolta di file. Ogni registrato
lo stato è rappresentato da un changeset. Un repository viene solitamente (ma non sempre) trovato
nel .hg sottodirectory di una directory di lavoro. Qualsiasi stato registrato può essere ricreato
"aggiornando" una directory di lavoro a un changeset specifico.
Repository capo
Vedere 'Testa, repository'.
Revisione
Uno stato del repository in un determinato momento. Le revisioni precedenti possono essere aggiornate
a usando hg update. Vedi anche 'Numero di revisione'; Vedere anche 'Set di modifiche'.
Revisione numero
Questo numero intero identifica in modo univoco un changeset in un repository specifico. Esso
rappresenta l'ordine in cui i changeset sono stati aggiunti a un repository, iniziando con
numero di revisione 0. Si noti che il numero di revisione può essere diverso in ogni clone di
un deposito. Per identificare i changeset in modo univoco tra diversi cloni, vedere
'ID modifica'.
Revlog Meccanismo di memorizzazione della cronologia utilizzato da Mercurial. È una forma di codifica delta, con
occasionali revisioni complete dei dati seguite da delta di ogni successiva revisione. Esso
include dati e un indice che punta ai dati.
riscrittura storia
Vedi 'Storia, riscrittura'.
Radice Un changeset che ha solo il changeset null come padre. La maggior parte dei repository ha
solo un singolo changeset radice.
Segreto Le modifiche nella fase segreta non possono essere condivise tramite push, pull o clone. Vedere hg
Aiuto fasi.
Etichetta Un nome alternativo dato a un changeset. I tag possono essere utilizzati in tutti i luoghi in cui
Mercurial si aspetta un ID changeset, ad esempio con hg update. La creazione di un tag è
memorizzato nella cronologia e verrà quindi automaticamente condiviso con altri utilizzando push
e tirare.
Consiglio Il changeset con il numero di revisione più alto. È il changeset più recente
aggiunto in un repository.
Consiglio, ramo
Il capo di un determinato ramo con il numero di revisione più alto. Quando il nome di un ramo è
utilizzato come identificatore di revisione, si riferisce al suggerimento del ramo. Vedi anche 'Ramo,
testa'. Nota che poiché i numeri di revisione possono essere diversi in repository diversi
cloni, la punta del ramo può essere diversa in diversi repository clonati.
Aggiornanento (Sostantivo) Un altro sinonimo di changeset.
Esempio: "Ho inviato un aggiornamento".
(Verbo) Questo termine viene solitamente utilizzato per descrivere l'aggiornamento dello stato di lavorazione
directory a quella di un changeset specifico. Vedere hg Aiuto update.
Esempio: "Dovresti aggiornare".
lavoro elenco
Vedi 'Rubrica, funzionante'.
lavoro elenco genitore
Vedere 'Genitore, directory di lavoro'.
SINTASSI PER MERCURIALE IGNORARE FILE
Sinossi
Il sistema Mercurial usa un file chiamato .hgignora nella directory principale di un repository per
controlla il suo comportamento quando cerca file che non sta attualmente monitorando.
Descrizione
La directory di lavoro di un repository Mercurial conterrà spesso file che non dovrebbero
essere rintracciato da Mercurial. Questi includono file di backup creati da editor e prodotti di build
creato dai compilatori. Questi file possono essere ignorati elencandoli in a .hgignora file nella
la radice della directory di lavoro. Il .hgignora il file deve essere creato manualmente. è
tipicamente messo sotto il controllo della versione, in modo che le impostazioni si propaghino ad altri
repository con push and pull.
Un file non tracciato viene ignorato se il suo percorso relativo alla directory radice del repository o qualsiasi
prefisso percorso di quel percorso, viene confrontato con qualsiasi modello in .hgignora.
Ad esempio, supponiamo di avere un file non tracciato, file.c, a a/b/file.c all'interno del nostro archivio.
Mercurial ignorerà file.c se c'è qualche modello in .hgignora fiammiferi a/b/file.c, a / b or a.
Inoltre, un file di configurazione di Mercurial può fare riferimento a un insieme di dati per utente o globali
ignora i file Vedi il ignorare chiave di configurazione sul [ui] sezione di hg Aiuto config per
dettagli su come configurare questi file.
Per controllare la gestione dei file che Mercurial gestisce, molti comandi supportano il -I ed
-X opzioni; vedere hg Aiuto ed hg Aiuto modelli per i dettagli.
I file già tracciati non sono interessati da .hgignore, anche se appaiono in
.hgignore. Un file X non tracciato può essere aggiunto esplicitamente con hg aggiungere X, anche se X fosse
escluso da un pattern in .hgignore.
Sintassi
Un file ignora è un file di testo semplice costituito da un elenco di modelli, con un modello per
linea. Le righe vuote vengono saltate. Il # carattere viene trattato come un carattere di commento e il
\ carattere viene trattato come un carattere di escape.
Mercurial supporta diverse sintassi di pattern. La sintassi predefinita utilizzata è in stile Python/Perl
espressioni regolari.
Per modificare la sintassi utilizzata, utilizzare una riga della forma seguente:
sintassi: NOME
where NOME è uno dei seguenti:
regexp
Espressione regolare, sintassi Python/Perl.
glob
Globo in stile conchiglia.
La sintassi scelta rimane in vigore durante l'analisi di tutti i modelli che seguono, fino a quando un altro
sintassi è selezionata.
Né i pattern glob né regexp sono radicati. Un modello di sintassi glob della forma *.C volere
corrisponde a un file che termina con .c in qualsiasi directory e un modello regexp del modulo \.c$ andrà bene
lo stesso. Per eseguire il root di un pattern regexp, avvialo con ^.
Le sottodirectory possono avere le proprie impostazioni .hgignore aggiungendo
subinclude:percorso/a/subdir/.hgignore alla radice .hgignora. Vedere hg Aiuto modelli per
dettagli su sottoincludere: ed includono:.
Nota Pattern specificati in diversi da .hgignora sono sempre radicati. Perfavore guarda hg Aiuto
modelli per i dettagli.
Esempio
Ecco un esempio di file ignora.
# usa la sintassi glob.
sintassi: glob
*.El c
*.pyc
*~
# passa alla sintassi dell'espressione regolare.
sintassi: espressione regolare
^\.pc/
CONFIGURAZIONE HGWEB
Il server web interno di Mercurial, hgweb, può servire un singolo repository o un albero di
repository. Nel secondo caso, i percorsi del repository e le opzioni globali possono essere definiti utilizzando
un file di configurazione dedicato comune a hg servire, hgweb.wsgi, hgweb.cgi ed hgweb.fcgi.
Questo file usa la stessa sintassi degli altri file di configurazione di Mercurial ma riconosce solo
le seguenti sezioni:
· ragnatela
· percorsi
· collezioni
I sito web le opzioni sono descritte dettagliatamente in hg Aiuto config.
I percorsi la sezione associa i percorsi URL ai percorsi dei repository nel filesystem. hgweb lo farà
non esporre direttamente il filesystem - solo i repository Mercurial possono essere pubblicati e solo
secondo la configurazione.
Il lato sinistro è il percorso nell'URL. Nota che hgweb riserva sottopercorsi come rev or
filetto, prova a usare nomi diversi per i repository nidificati per evitare effetti confusi.
Il lato destro è il percorso nel filesystem. Se il percorso specificato termina con * or **
il filesystem verrà cercato in modo ricorsivo per i repository al di sotto di quel punto. Con * it
non ricorrerà nei repository che trova (tranne che per .hg/patch). Con ** lo farà
cercare anche all'interno delle directory di lavoro del repository e possibilmente trovare sottorepository.
In questo esempio:
[percorsi]
/progetti/a = /srv/tmprepos/a
/progetti/b = c:/repos/b
/ = /srv/repo/*
/utente/bob = /home/bob/repos/**
· Le prime due voci fanno apparire due repository in directory diverse sotto il
stessa directory nell'interfaccia web
· La terza voce pubblicherà tutti i repository Mercurial trovati in /srv/repo/, Per
esempio il repository /srv/repos/quux/ apparirà come http://server/quux/
· La quarta voce pubblicherà entrambi http://server/user/bob/quux/ ed
http://server/user/bob/quux/testsubrepo/
I collezioni la sezione è deprecata ed è stata sostituita da percorsi.
URL ed Uncommon argomenti
Gli URL sotto ogni repository hanno la forma /{comando}[/{argomenti}] where {comando}
rappresenta il nome di un comando o gestore e {argomenti} rappresenta un numero qualsiasi di
parametri URL aggiuntivi a quel comando.
Al server web è associato uno stile predefinito. Gli stili vengono mappati a una raccolta di nomi
modelli. Ogni modello viene utilizzato per eseguire il rendering di un dato specifico, come un changeset
o diff.
Lo stile per la richiesta corrente può essere sovrascritto in due modi. Primo, se {comando}
contiene un trattino (-), il testo prima del trattino definisce lo stile. Per esempio,
/atomo-log renderà il ceppo gestore di comandi con il atomo stile. Il secondo modo per impostare
lo stile è con il style argomento della stringa di query. Per esempio, /log?stile=atomo.
il parametro URL con trattino è preferito.
Non tutti i modelli sono disponibili per tutti gli stili. Il tentativo di utilizzare uno stile che non lo fa
avere tutti i modelli definiti può causare un errore nel rendering della pagina.
Molti comandi prendono a {revisione} Parametro dell'URL. Questo definisce il changeset su cui operare.
Questo è comunemente specificato come la breve abbreviazione esadecimale di 12 cifre per l'intero 40
identificatore di revisione univoco del carattere. Tuttavia, qualsiasi valore descritto da hg Aiuto
tipicamente funziona.
Comandi ed URL
Sono disponibili i seguenti comandi Web e i relativi URL:
/annotate/{revisione}/{percorso}
Mostra le informazioni sul changeset per ogni riga in un file.
I annotare file il modello è reso.
/archive/{revisione}.{formato}[/{percorso}]
Ottenere un archivio dei contenuti del repository.
Il contenuto e il tipo dell'archivio sono definiti da un parametro di percorso URL. formato Europe è
estensione del file del tipo di archivio da generare. per esempio chiusura or tar.bz2. Non tutto l'archivio
tipi possono essere consentiti dalla configurazione del server.
Facoltativo sentiero Il parametro URL controlla il contenuto da includere nell'archivio. Se omesso,
ogni file nella revisione specificata è presente nell'archivio. Se incluso, solo il
il file specificato oi contenuti della directory specificata verranno inclusi nell'archivio.
Nessun modello viene utilizzato per questo gestore. Viene generato contenuto binario grezzo.
/segnalibri
Mostra informazioni sui segnalibri.
Non si accettano argomenti.
I segnalibri il modello è reso.
/rami
Mostra informazioni sui rami.
Tutti i rami conosciuti sono contenuti nell'output, anche quelli chiusi.
Non si accettano argomenti.
I rami il modello è reso.
/log modifiche[/{revisione}]
Mostra informazioni su più changeset.
Se l'opzionale revisione L'argomento URL è assente, iniziano le informazioni su tutti i changeset
at tipo sarà reso. Se la revisione l'argomento è presente, verranno mostrati i changeset
a partire dalla revisione specificata.
If revisione è assente, il rev l'argomento della stringa di query può essere definito. Questo eseguirà un
cercare i changeset.
L'argomento per rev può essere una singola revisione, un insieme di revisioni o una parola chiave letterale per
cerca nei dati del changeset (equivalente a hg ceppo -k).
I contagiri L'argomento della stringa di query definisce il numero massimo di changeset di cui eseguire il rendering.
Per le non ricerche, il changelog modello verrà reso.
/modifica[/{revisione}]
Mostra informazioni su un singolo changeset.
Un argomento del percorso URL è l'identificatore del changeset da mostrare. Vedere hg Aiuto per
valori possibili. Se non definito, il tipo verrà mostrato il changeset.
I changeset il modello è reso. Contenuto del modifica modifica, changesetsegnalibro,
filenodelink, filenolink, e i molti modelli relativi alle differenze possono essere utilizzati per
produrre l'output.
/comparison/{revisione}/{percorso}
Mostra un confronto tra la vecchia e la nuova versione di un file dalle modifiche apportate su a
revisione particolare.
Questo è simile al diff gestore. Tuttavia, questo modulo presenta una suddivisione o affiancato
diff piuttosto che un diff unificato.
I contesto L'argomento della stringa di query può essere utilizzato per controllare le righe di contesto nel file diff.
I confronto file il modello è reso.
/diff/{revisione}/{percorso}
Mostra come un file è cambiato in un particolare commit.
I filediff il modello è reso.
Questo gestore è registrato sia sotto il /differenza ed /filediff percorsi. /differenza è usato in
codice moderno.
/file/{revisione}[/{percorso}]
Mostra informazioni su una directory o un file nel repository.
Informazioni sul sentiero fornito come parametro URL verrà visualizzato.
If sentiero è una directory, verranno visualizzate le informazioni sulle voci in quella directory.
Questa forma è equivalente a manifesto gestore.
If sentiero è un file, le informazioni su quel file verranno mostrate tramite il revisione file
modello.
If sentiero non è definito, verranno visualizzate le informazioni sulla directory principale.
/diff/{revisione}/{percorso}
Mostra come un file è cambiato in un particolare commit.
I filediff il modello è reso.
Questo gestore è registrato sia sotto il /differenza ed /filediff percorsi. /differenza è usato in
codice moderno.
/filelog/{revisione}/{percorso}
Mostra informazioni sulla cronologia di un file nel repository.
I contagiri l'argomento della stringa di query può essere definito per controllare il numero massimo di voci
mostrare.
I registro di file modello verrà reso.
/grafico[/{revisione}]
Mostra informazioni sulla topologia grafica del repository.
Le informazioni rese da questo gestore possono essere utilizzate per creare rappresentazioni visive di
topologia del deposito.
I revisione Il parametro URL controlla il changeset iniziale.
I contagiri l'argomento della stringa di query può definire il numero di changeset per mostrare le informazioni
per.
Questo gestore renderà il grafico modello.
/aiuto[/{argomento}]
Rendi la documentazione di aiuto.
Questo comando web è più o meno equivalente a hg Aiuto. Se una argomento è definito, quell'argomento di aiuto
sarà reso. In caso contrario, verrà visualizzato un indice degli argomenti della guida disponibili.
I Aiuto modello verrà visualizzato quando si richiede aiuto per un argomento. argomenti di aiuto sarà
reso per l'indice degli argomenti della guida.
/log[/{revisione}[/{percorso}]]
Mostra il repository o la cronologia dei file.
Per gli URL del modulo /log/{revisione}, un elenco di changeset che iniziano dal punto specificato
viene mostrato l'identificatore del changeset. Se {revisione} non è definito, il valore predefinito è tipo. Questa forma
è equivalente a changelog gestore.
Per gli URL del modulo /log/{revisione}/{file}, la cronologia di un file specifico sarà
mostrato. Questa forma è equivalente a registro di file gestore.
/manifest[/{revisione}[/{percorso}]]
Mostra informazioni su una directory.
Se gli argomenti del percorso dell'URL vengono omessi, le informazioni sulla directory principale per il tipo
verrà mostrato il changeset.
Poiché questo gestore può mostrare solo le informazioni per le directory, si consiglia di utilizzare
, il filetto handler, in quanto può gestire sia le directory che i file.
I manifesto modello verrà reso per questo gestore.
/modifica[/{revisione}]
Mostra informazioni su un singolo changeset.
Un argomento del percorso URL è l'identificatore del changeset da mostrare. Vedere hg Aiuto per
valori possibili. Se non definito, il tipo verrà mostrato il changeset.
I changeset il modello è reso. Contenuto del modifica modifica, changesetsegnalibro,
filenodelink, filenolink, e i molti modelli relativi alle differenze possono essere utilizzati per
produrre l'output.
/ shortlog
Mostra le informazioni di base su una serie di modifiche.
Questo accetta gli stessi parametri del changelog gestore. L'unica differenza è il
cortocircuito il modello verrà visualizzato al posto di changelog modello.
/riepilogo
Mostra un riepilogo dello stato del repository.
Le informazioni sugli ultimi set di modifiche, segnalibri, tag e rami vengono catturate da questo
gestore.
I sommario il modello è reso.
/tag
Mostra informazioni sui tag.
Non si accettano argomenti.
I tag il modello è reso.
TECNICO IMPLEMENTAZIONE ARGOMENTI
pachetti sconto
contenitore per lo scambio dei dati del repository
cambiagruppo
rappresentazione dei dati di Revlog
revlog
meccanismo di archiviazione delle revisioni
MERGE STRUMENTI
Per unire i file Mercurial utilizza strumenti di unione.
Uno strumento di unione combina due diverse versioni di un file in un file unito. Gli strumenti di unione sono
dati i due file e il più grande antenato comune delle due versioni di file, quindi possono
determinare le modifiche apportate su entrambi i rami.
Gli strumenti di unione vengono utilizzati sia per hg risolvere, hg unire, hg update, hg indietro e in diversi
estensioni.
Di solito, lo strumento di unione cerca di riconciliare automaticamente i file combinando tutti
cambiamenti non sovrapposti avvenuti separatamente nelle due diverse evoluzioni del
stesso file di base iniziale. Inoltre, alcuni programmi di unione interattivi rendono più facile
risolvere manualmente le unioni in conflitto, in modo grafico o inserendone alcune
indicatori di conflitto. Mercurial non include alcun programma di unione interattivo ma si basa su
strumenti esterni per questo.
Disponibile unire strumenti
Gli strumenti di unione esterni e le loro proprietà sono configurati nella configurazione degli strumenti di unione
sezione - vedi hgr(5) - ma spesso possono essere nominati semplicemente dal loro eseguibile.
Uno strumento di unione è generalmente utilizzabile se il suo eseguibile può essere trovato nel sistema e se è
può gestire l'unione. L'eseguibile viene trovato se è un eseguibile assoluto o relativo
percorso o il nome di un'applicazione nel percorso di ricerca dell'eseguibile. Si presume che lo strumento
essere in grado di gestire l'unione se può gestire i collegamenti simbolici se il file è un collegamento simbolico, se può
gestire i file binari se il file è binario e se è disponibile una GUI se lo strumento lo richiede
una GUI.
Esistono alcuni strumenti di unione interni che possono essere utilizzati. Gli strumenti di unione interni sono:
:scarico
Crea tre versioni dei file da unire, contenenti i contenuti di local,
altro e base. Questi file possono quindi essere utilizzati per eseguire manualmente un'unione. Se la
il file da unire è denominato un.txt, questi file saranno di conseguenza denominati
a.txt.locale, a.txt.altro ed a.txt.base e saranno messi nello stesso
directory come un.txt.
:fallire
Invece di tentare di unire file che sono stati modificati su entrambi i rami, contrassegna
loro come irrisolti. Il comando resolve deve essere utilizzato per risolvere questi conflitti.
:Locale
Utilizza la versione locale dei file come versione unita.
:unire
Utilizza l'algoritmo di unione semplice non interattivo interno per unire i file. Lo farà
fallisce in caso di conflitti e lascia i marcatori nel file parzialmente unito.
I marcatori avranno due sezioni, una per ogni lato dell'unione.
:fusione-locale
Come: unisci, ma risolvi tutti i conflitti in modo non interattivo a favore del locale
modifiche.
:unione-altro
Come: unisci, ma risolvi tutti i conflitti in modo non interattivo a favore dell'altro
modifiche.
:unisci3
Utilizza l'algoritmo di unione semplice non interattivo interno per unire i file. Lo farà
fallisce in caso di conflitti e lascia i marcatori nel file parzialmente unito.
Il marker avrà tre sezioni, una da ciascun lato dell'unione e una per il
contenuto di base.
:Altro
Utilizza l'altra versione dei file come versione unita.
:richiesta
Chiede all'utente quale versione locale o dell'altra mantenere come unita
versione.
:tagmerge
Utilizza l'algoritmo di unione dei tag interni (sperimentale).
:unione
Utilizza l'algoritmo di unione semplice non interattivo interno per unire i file. Lo farà
utilizzare entrambi i lati sinistro e destro per le regioni di conflitto. Nessun marcatore inserito.
Gli strumenti interni sono sempre disponibili e non richiedono una GUI ma per impostazione predefinita non lo faranno
gestire collegamenti simbolici o file binari.
La scelta di a unire
Mercurial utilizza queste regole per decidere quale strumento di unione utilizzare:
1. Se è stato specificato uno strumento con l'opzione --tool per unire o risolvere, viene utilizzato.
Se è il nome di uno strumento nella configurazione degli strumenti di unione, la sua configurazione è
Usato. Altrimenti lo strumento specificato deve essere eseguibile dalla shell.
2. Se la HGMERGE la variabile di ambiente è presente, il suo valore viene utilizzato e deve essere
eseguibile dalla shell.
3. Se il nome del file da unire corrisponde a uno qualsiasi dei modelli nella
sezione di configurazione dei modelli di unione, il primo strumento di unione utilizzabile corrispondente a a
viene utilizzato il modello corrispondente. Qui, le funzionalità binarie dello strumento di unione non lo sono
considerato.
4. Se ui.merge è impostato, verrà considerato successivamente. Se il valore non è il nome di a
strumento configurato, viene utilizzato il valore specificato e deve essere eseguibile dalla shell.
Altrimenti viene utilizzato lo strumento denominato se è utilizzabile.
5. Se sono presenti strumenti di unione utilizzabili nella sezione di configurazione degli strumenti di unione, quello
con la priorità più alta viene utilizzato.
6. Se un programma chiamato hgmerge può essere trovato nel sistema, è usato - ma lo farà
il valore predefinito non può essere utilizzato per collegamenti simbolici e file binari.
7. Se il file da unire non è binario e non è un collegamento simbolico, allora internal :unire is
Usato.
8. L'unione del file non riesce e deve essere risolta prima del commit.
Nota Dopo aver selezionato un programma di unione, per impostazione predefinita Mercurial tenterà di unire i
file utilizzando prima un semplice algoritmo di unione. Solo se non riesce a causa di
modifiche in conflitto Mercurial eseguirà effettivamente il programma di unione. Se
utilizzare prima il semplice algoritmo di unione può essere controllato dall'impostazione di premerge di
lo strumento di unione. Premerge è abilitato per impostazione predefinita a meno che il file non sia binario o a
collegamento simbolico.
Vedi gli strumenti di unione e le sezioni dell'interfaccia utente di hgr(5) per i dettagli sulla configurazione dell'unione
strumenti.
SPECIFICANDO MULTIPLA REVISIONI
Quando Mercurial accetta più di una revisione, possono essere specificate singolarmente, oppure
fornito come un intervallo topologicamente continuo, separato dal carattere ":".
La sintassi della notazione dell'intervallo è [BEGIN]:[END], dove BEGIN e END sono revisioni
identificatori. Sia BEGIN che END sono opzionali. Se BEGIN non è specificato, il valore predefinito è
numero di revisione 0. Se END non è specificato, il valore predefinito è il suggerimento. L'intervallo ":" quindi
significa "tutte le revisioni".
Se BEGIN è maggiore di END, le revisioni vengono trattate in ordine inverso.
Un intervallo agisce come un intervallo chiuso. Ciò significa che un intervallo di 3:5 dà 3, 4 e 5.
Allo stesso modo, un intervallo di 9:6 fornisce 9, 8, 7 e 6.
RISORSE NOME MODELLI
Mercurial accetta diverse notazioni per identificare uno o più file alla volta.
Per impostazione predefinita, Mercurial tratta i nomi dei file come modelli glob estesi in stile shell.
Le notazioni del modello alternativo devono essere specificate in modo esplicito.
Nota Pattern specificati in .hgignora non sono radicati. Perfavore guarda hg Aiuto hgignora per
dettagli.
Per utilizzare un nome di percorso semplice senza alcuna corrispondenza di modello, inizia con sentiero:. questi percorsi
i nomi devono corrispondere completamente a partire dalla radice del repository corrente.
Per utilizzare un glob esteso, inizia un nome con globo:. I globi sono radicati nella corrente
elenco; un glob come *.C corrisponderà solo ai file nella directory corrente che terminano con
.c.
Le estensioni di sintassi glob supportate sono ** per far corrispondere qualsiasi stringa tra separatori di percorso e
{a, b} significare "a o b".
Per usare un'espressione regolare Perl/Python, inizia un nome con re:. Corrispondenza del modello Regexp
è ancorato alla radice del repository.
Per leggere i modelli di nomi da un file, usa file di elenco: or fileelenco0:. Quest'ultimo si aspetta null
modelli delimitati mentre il primo prevede feed di riga. Ogni stringa letta dal file è
stesso trattato come un modello di file.
Per leggere una serie di modelli da un file, usa includono: or sottoincludere:. includono: userà tutto
i modelli dal file dato e trattarli come se fossero stati passati manualmente.
sottoincludere: applicherà i modelli solo ai file che si trovano sotto la sottoinclusione
directory del file. Vedere hg Aiuto hgignora per i dettagli sul formato di questi file.
Tutti i modelli, tranne globo: specificato nella riga di comando (non per -I or -X opzioni), può
corrispondenza anche con le directory: i file nelle directory corrispondenti vengono trattati come corrispondenti.
Esempi semplici:
path:foo/bar una barra del nome in una directory chiamata foo nella root
del deposito
percorso:percorso:nome un file o una directory denominata "percorso:nome"
Esempi di globi:
glob:*.c qualsiasi nome che termina con ".c" nella directory corrente
*.c qualsiasi nome che termina con ".c" nella directory corrente
**.c qualsiasi nome che termina in ".c" in qualsiasi sottodirectory del
directory corrente incluso se stesso.
foo/*.c qualsiasi nome che termina con ".c" nella directory foo
foo/**.c qualsiasi nome che termina in ".c" in qualsiasi sottodirectory di foo
compreso se stesso.
Esempi di espressioni regolari:
re:.*\.c$ qualsiasi nome che termina con ".c", ovunque nel repository
Esempi di file:
listfile:list.txt legge l'elenco da list.txt con un modello di file per riga
listfile0:list.txt legge l'elenco da list.txt con delimitatori di byte nulli
Vedi anche hg Aiuto set di file.
Includi esempi:
include:path/to/mypatternfile legge i pattern da applicare a tutti i percorsi
subinclude:path/to/subignorefile legge i modelli specificamente per i percorsi nel
sottodirectory
LAVORO CON FASI
Che sono fasi?
Le fasi sono un sistema per tenere traccia di quali changeset sono stati o dovrebbero essere condivisi. Questo
aiuta a prevenire errori comuni durante la modifica della cronologia (ad esempio, con mq o rebase
estensioni).
Ogni changeset in un repository si trova in una delle seguenti fasi:
· public : il changeset è visibile su un server pubblico
· bozza: il changeset non è ancora stato pubblicato
· segreto: il changeset non deve essere spinto, tirato o clonato
Queste fasi sono ordinate (pubblica < bozza < segreta) e nessun changeset può trovarsi in una posizione inferiore
fase rispetto ai suoi antenati. Ad esempio, se un changeset è pubblico, tutti i suoi antenati lo sono
anche pubblico. Infine, le fasi del changeset dovrebbero essere modificate solo verso la fase pubblica.
Come sono fasi gestito?
Per la maggior parte, le fasi dovrebbero funzionare in modo trasparente. Per impostazione predefinita, viene creato un changeset in
la fase di bozza e viene spostata nella fase pubblica quando viene spinta in un'altra
repository.
Una volta che i changeset diventano pubblici, estensioni come mq e rebase si rifiuteranno di operare su
loro per evitare la creazione di changeset duplicati. Le fasi possono anche essere manipolate manualmente
con la hg fase comando se necessario. Vedere hg Aiuto -v fase per esempio.
Per rendere segreti i tuoi commit per impostazione predefinita, inserisci questo nel file di configurazione:
[fasi]
new-commit = segreto
Fasi ed server
Normalmente, tutti i server sono editoriale per impostazione predefinita. Questo significa:
- tutti i changeset di bozza estratti o clonati vengono visualizzati in fase
pubblico sul cliente
- tutte le bozze di changeset inviate appaiono come pubbliche su entrambi
client e server
- i changeset segreti non vengono né spinti, tirati o clonati
Nota L'estrazione di una bozza di changeset da un server di pubblicazione non la contrassegna come pubblica su
lato server a causa della natura di sola lettura del pull.
A volte può essere desiderabile spingere e tirare le modifiche nella fase di bozza per condividerle
lavoro incompiuto. Questo può essere fatto impostando un repository per disabilitare la pubblicazione nel suo
file di configurazione:
[fasi]
pubblicare = falso
See hg Aiuto config per ulteriori informazioni sui file di configurazione.
Nota I server che eseguono versioni precedenti di Mercurial sono trattati come pubblicazione.
Nota I changeset in fase segreta non vengono scambiati con il server. Questo vale per il loro
contenuto: nomi di file, contenuti di file e metadati di changeset. Per motivi tecnici,
l'identificatore (es. d825e4025e39) del changeset segreto può essere comunicato a
il server.
Esempi
· lista modifiche in fase bozza o segreta:
hg log -r "non pubblico()"
· cambia tutte le modifiche segrete in bozza:
hg fase --draft "segreto()"
· spostare forzatamente l'attuale changeset e i discendenti dal pubblico alla bozza:
hg fase --force --draft .
· mostrare un elenco di revisione e fase del changeset:
hg log --template "{rev} {fase}\n"
· risincronizzare i changeset delle bozze relativi a un repository remoto:
hg fase -fd "in uscita (URL)"
See hg Aiuto fase per ulteriori informazioni sulla manipolazione manuale delle fasi.
SPECIFICANDO SINGLE REVISIONI
Mercurial supporta diversi modi per specificare revisioni individuali.
Un intero normale viene trattato come un numero di revisione. Gli interi negativi sono trattati come
offset sequenziali dalla punta, con -1 che denota la punta, -2 che denota la revisione precedente
alla punta, e così via.
Una stringa esadecimale di 40 cifre viene considerata come un identificatore di revisione univoco.
Una stringa esadecimale di lunghezza inferiore a 40 caratteri viene trattata come una revisione univoca
identificatore ed è indicato come identificatore in forma abbreviata. Un identificatore in forma breve è solo
valido se è il prefisso di esattamente un identificatore a lunghezza intera.
Qualsiasi altra stringa viene trattata come un segnalibro, un tag o un nome di ramo. Un segnalibro è un mobile
puntatore a una revisione. Un tag è un nome permanente associato a una revisione. Un nome di filiale
denota la testa del ramo più aperta di quel ramo - o se sono tutti chiusi, il
capo più chiuso del ramo. I nomi dei segnalibri, dei tag e dei rami non devono contenere il
":" carattere.
Il nome riservato "tip" identifica sempre la revisione più recente.
Il nome riservato "null" indica la revisione nulla. Questa è la revisione di un vuoto
repository e il genitore della revisione 0.
Il nome riservato "." indica il genitore della directory di lavoro. Se nessuna directory di lavoro è
estratto, è equivalente a null. Se è in corso un'unione senza commit, "." è il
revisione del primo genitore.
SPECIFICANDO REVISIONE SETS
Mercurial supporta un linguaggio funzionale per la selezione di un insieme di revisioni.
Il linguaggio supporta una serie di predicati uniti da operatori infissi.
Le parentesi possono essere utilizzate per il raggruppamento.
Gli identificatori come i nomi dei rami potrebbero dover essere citati con virgolette singole o doppie se sono
contenere caratteri come - o se corrispondono a uno dei predicati predefiniti.
I caratteri speciali possono essere utilizzati negli identificatori tra virgolette mediante l'escape, ad es. \n is
interpretato come una nuova riga. Per evitare che vengano interpretate, le stringhe possono essere precedute
con r, per esempio R'...'.
Esiste un unico operatore di prefisso:
non x
Modifiche non in x. La forma breve è ! x.
Questi sono gli operatori infissi supportati:
x::y
Un intervallo DAG, ovvero tutti i changeset che sono discendenti di x e antenati di y,
inclusi xey stessi. Se il primo endpoint viene omesso, questo è equivalente
a antenati (i), se il secondo viene omesso equivale a discendenti(x).
Una sintassi alternativa è x..y.
x: y
Tutti i changeset con numeri di revisione compresi tra x e y, inclusi. o
endpoint può essere omesso, il valore predefinito è 0 e tip.
x ed y
L'intersezione dei changeset in x e y. La forma breve è x & y.
x or y
L'unione di changeset in x e y. Esistono due forme brevi alternative: x | y
ed x + y.
x - y
Changeset in x ma non in y.
x^n
L'ennesimo genitore di x, n == 0, 1 o 2. Per n == 0, x; per n == 1, il primo genitore
di ogni changeset in x; per n == 2, il secondo genitore del changeset in x.
x~n
L'ennesimo primo antenato di x; x~0 è x; x~3 is x^^^.
C'è un unico operatore suffisso:
x^
Equivalente a x ^ 1, il primo genitore di ogni changeset in x.
Sono supportati i seguenti predicati:
aggiunge (schema)
Changeset che aggiungono un modello di corrispondenza del file.
Il modello senza tipo esplicito come globo: dovrebbe essere relativo al
directory corrente e confronta con un file o una directory.
tutti()
Tutti i changeset, lo stesso di 0:suggerimento.
antenato(*modifica)
Un grande antenato comune dei changeset.
Accetta 0 o più modifiche. Restituirà un elenco vuoto quando non vengono passati argomenti.
Il più grande antenato comune di un singolo changeset è quel changeset.
antenati (insieme)
Insiemi di modifiche che sono antenati di un insieme di modifiche in un insieme.
autore (stringa)
Alias per utente (stringa).
bisezione (stringa)
Changeset contrassegnati nello stato bisect specificato:
· buono, male, Salta: cset esplicitamente contrassegnati come buono/cattivo/salta
· merce, cattivi : cset topologicamente buono/cattivo
· gamma : cset che partecipano alla bisezione
· potati : cset che sono buoni, cattivi o saltati
· non testato : cset il cui destino è ancora sconosciuto
· ignorati : cset ignorati a causa della topologia DAG
· corrente : il cset attualmente in fase di bisezione
segnalibro ([nome])
Il segnalibro con nome o tutti i segnalibri.
If Nome inizia con re:, il resto del nome viene trattato come un normale
espressione. Per abbinare un segnalibro che inizia effettivamente con re:, usa il prefisso
letterale:.
ramo(stringa or set)
Tutti i changeset appartenenti al ramo dato o ai rami del dato
modifiche.
If stringa inizia con re:, il resto del nome viene trattato come un normale
espressione. Per abbinare un ramo che inizia effettivamente con re:, usa il prefisso
letterale:.
punto di diramazione()
Changeset con più di un figlio.
urtato()
Insiemi di modifiche mutevoli contrassegnati come successori di insiemi di modifiche pubblici.
Solo i changeset non pubblici e non obsoleti possono essere urtato.
fascio()
Modifiche nel pacchetto.
Il pacchetto deve essere specificato dall'opzione -R.
bambini (insieme)
Insiemi di modifiche figlio di insiemi di modifiche nell'insieme.
Chiuso()
Il set di modifiche è chiuso.
contiene (schema)
Il manifesto della revisione contiene un modello di corrispondenza del file (ma potrebbe non modificarlo).
See hg Aiuto modelli per informazioni sui modelli di file.
Il modello senza tipo esplicito come globo: dovrebbe essere relativo al
directory corrente e confrontarlo con un file esattamente per l'efficienza.
convertito ([id])
Changeset convertiti dall'identificatore dato nel vecchio repository, se presente, oppure
tutti i changeset convertiti se non viene specificato alcun identificatore.
data (intervallo)
Modifiche all'interno dell'intervallo, vedere hg Aiuto DATE.
desc(stringa)
Cerca il messaggio di commit per la stringa. La corrispondenza non fa distinzione tra maiuscole e minuscole.
discendenti (insieme)
Changeset che sono discendenti di changeset in set.
destinazione ([imposta])
Changeset che sono stati creati da un'operazione di innesto, trapianto o rebase, con il
date revisioni specificate come fonte. L'omissione del set opzionale equivale a
passando tutto().
divergente()
Successori finali di changeset con un insieme alternativo di successori finali.
brutta copia()
Changeset in fase di bozza.
estinto()
Changeset obsoleti solo con discendenti obsoleti.
extra (etichetta, [valore])
Changeset con l'etichetta data nei metadati extra, con l'optional dato
valore.
If APPREZZIAMO inizia con re:, il resto del valore viene trattato come un normale
espressione. Per abbinare un valore che inizia effettivamente con re:, usa il prefisso
letterale:.
file (schema)
Modifiche che interessano i file abbinati al modello.
Per un risultato più veloce ma meno accurato, considera l'utilizzo filelog() anziché.
Questo predicato usa globo: come tipo di modello predefinito.
filelog (schema)
Changeset connesso al filelog specificato.
Per motivi di prestazioni, visita solo le revisioni menzionate nel filelog a livello di file,
piuttosto che filtrare tutti i changeset (molto più velocemente, ma non include
elimina o duplica le modifiche). Per un risultato più lento e accurato, utilizzare file().
Il modello senza tipo esplicito come globo: dovrebbe essere relativo al
directory corrente e confrontarlo con un file esattamente per l'efficienza.
Se qualche linkrev punta a revisioni filtrate dalla repoview corrente, lavoreremo
intorno per restituire un valore non filtrato.
prima (impostare, [N])
Un alias per limit().
seguire ([schema])
Un alias per ::. (antenati del primo genitore della directory di lavoro). Se modello
è specificato, viene seguita la cronologia dei file che corrispondono al modello dato, incluso
copie.
grep (regex)
Come parola chiave (stringa) ma accetta una regex. Uso grep(r'...') per garantire una fuga speciale
i caratteri sono gestiti correttamente. a differenza di parola chiave (stringa), la partita è
maiuscole e minuscole.
testa()
Changeset è una testa di ramo denominata.
teste (insieme)
Membri del set senza figli nel set.
nascosto()
Modifiche nascoste.
ID (stringa)
Revisione specificata in modo non ambiguo dal prefisso della stringa esadecimale specificato.
parola chiave (stringa)
Cerca messaggio di commit, nome utente e nomi dei file modificati per la stringa. La partita
non fa distinzione tra maiuscole e minuscole.
ultimo (insieme, [N])
Ultimi n membri dell'insieme, per impostazione predefinita a 1.
limite(imposta[, N[, compensare]])
Primi n membri dell'insieme, per impostazione predefinita a 1, a partire dall'offset.
corrispondenza (revisione) [, campo])
Insiemi di modifiche in cui un determinato insieme di campi corrisponde all'insieme di campi nel selezionato
revisione o set.
Per abbinare più di un campo passare l'elenco dei campi da abbinare separati da spazi
(per esempio autore descrizione).
I campi validi sono la maggior parte dei campi di revisione regolari e alcuni campi speciali.
I campi di revisione regolari sono descrizione, autore, ramo, quando, file, fase,
genitori, sottostato, Utente ed diff. Nota che autore ed Utente sono sinonimi. diff
si riferisce al contenuto della revisione. Due revisioni corrispondenti alle loro diff sarà anche
abbinare il loro file.
I campi speciali sono sommario ed metadati: sommario corrisponde alla prima riga di
descrizione. metadati è equivalente a corrispondere descrizione Utente quando (cioè è
corrisponde ai principali campi di metadati).
metadati è il campo predefinito che viene utilizzato quando non viene specificato alcun campo. Puoi
abbinare più di un campo alla volta.
massimo (impostato)
Changeset con il numero di revisione più alto nel set.
unire()
Changeset è un changeset di unione.
minimo (impostato)
Changeset con il numero di revisione più basso nel set.
modifica (schema)
Changeset che modificano i file abbinati al modello.
Il modello senza tipo esplicito come globo: dovrebbe essere relativo al
directory corrente e confronta con un file o una directory.
nome (spazio dei nomi)
I changeset in un dato namespace.
If namespace inizia con re:, il resto della stringa viene trattato come un normale
espressione. Per abbinare uno spazio dei nomi che inizia effettivamente con re:, usa il prefisso
letterale:.
obsoleto()
Changeset mutabile con una versione più recente.
solo (impostare, [impostato])
Changeset che sono antenati del primo set che non sono antenati di nessun altro
testa nel repo. Se viene specificato un secondo set, il risultato sono gli antenati del
primo insieme che non sono antenati del secondo insieme (cioè :: - :: ).
origine ([insieme])
Changeset che sono stati specificati come fonte per gli innesti, i trapianti o i rebase
che ha creato le revisioni fornite. Omettere il set opzionale equivale a passare
tutto(). Se un changeset creato da queste operazioni è esso stesso specificato come sorgente
per una di queste operazioni, solo il changeset sorgente per la prima operazione è
selezionato.
in uscita ([percorso])
Set di modifiche non trovati nel repository di destinazione specificato o nel push predefinito
posizione.
p1([imposta])
Primo genitore di changeset in set, o la directory di lavoro.
p2([imposta])
Secondo genitore di changeset in set, o la directory di lavoro.
genitori ([set])
L'insieme di tutti i genitori per tutti i changeset nel set o la directory di lavoro.
presente (impostato)
Un set vuoto, se non viene trovata alcuna revisione nel set; in caso contrario, tutte le revisioni nel set.
Se una delle revisioni specificate non è presente nel repository locale, la query è
normalmente interrotto. Ma questo predicato consente alla query di continuare anche in tale
casi.
pubblico()
Changeset in fase pubblica.
remoto([id [,sentiero]])
Revisione locale che corrisponde all'identificatore dato in un repository remoto, se
regalo. Qui, il '.' identificatore è un sinonimo per il ramo locale corrente.
rimuove (schema)
Changeset che rimuovono i file che corrispondono al modello.
Il modello senza tipo esplicito come globo: dovrebbe essere relativo al
directory corrente e confronta con un file o una directory.
giro(numero)
Revisione con l'identificatore numerico indicato.
invertire (impostare)
Ordine inverso di serie.
radici (insieme)
Insiemi di modifiche nell'insieme senza insieme di modifiche padre nell'insieme.
segreto()
Changeset in fase segreta.
ordina(imposta[, [-]chiave...])
Ordina impostato per tasti. L'ordinamento predefinito è crescente, specificare una chiave come -chiave a
ordina in ordine decrescente.
Le chiavi possono essere:
· rev per il numero di revisione,
· ramo per il nome della filiale,
· disc per il messaggio di commit (descrizione),
· Utente per nome utente (autore può essere usato come alias),
· quando per la data del commit
subrepo([schema])
Changeset che aggiungono, modificano o rimuovono il subrepo specificato. Se nessun modello di subrepo è
named, vengono restituite tutte le modifiche al sottorepo.
etichetta([nome])
Il tag specificato per nome o tutte le revisioni con tag se non viene fornito alcun nome.
If Nome inizia con re:, il resto del nome viene trattato come un normale
espressione. Per abbinare un tag che inizia effettivamente con re:, usa il prefisso letterale:.
instabile()
Changeset non obsoleti con antenati obsoleti.
utente (stringa)
Il nome utente contiene una stringa. La corrispondenza non fa distinzione tra maiuscole e minuscole.
If stringa inizia con re:, il resto della stringa viene trattato come un normale
espressione. Per abbinare un utente che contiene effettivamente re:, usa il prefisso letterale:.
È possibile definire nuovi predicati (noti come "alias"), utilizzando qualsiasi combinazione di esistenti
predicati o altri alias. Una definizione di alias ha il seguente aspetto:
=
nel revsetalie sezione di un file di configurazione di Mercurial. Argomenti della forma $1,
$2, ecc. sono sostituiti dall'alias nella definizione.
Per esempio,
[rivendicazione]
h = teste()
d($1) = sort($1, data)
rs($1, $2) = reverse(ordina($1, $2))
definisce tre alias, h, de rs. rs(0:suggerimento, autore) è esattamente equivalente a
reverse(sort(0:suggerimento, autore)).
Un operatore infisso ## può concatenare stringhe e identificatori in un'unica stringa. Per esempio:
[rivendicazione]
problema($1) = grep(r'\bissue[ :]?' ## $1 ## r'\b|\bbug\(' ## $1 ## r'\)')
problema(1234) è equivalente grep(r'\bissue[ :]?1234\b|\bbug\(1234\)') in questo caso. Questo
corrisponde a tutti i "issue 1234", "issue:1234", "issue1234" e "insetto(1234)".
Tutti gli altri operatori di prefisso, infisso e suffisso hanno una priorità inferiore a ##. Per esempio, $1
## $ 2 ~ 2 è equivalente ($ 1 ## $ 2) ~ 2.
Equivalenti della riga di comando per hg ceppo:
-f -> ::.
-dx -> data(x)
-kx -> parola chiave (x)
-m -> unisci()
-ux -> utente(x)
-bx -> ramo(x)
-P x -> !::x
-lx -> limite (espr, x)
Alcune query di esempio:
· Changeset sul ramo predefinito:
hg log -r "ramo (predefinito)"
· Changesets sul ramo predefinito dal tag 1.5 (escluse le unioni):
hg log -r "branch(default) and 1.5:: and not merge()"
· Filiali aperte:
hg log -r "head() e not closed()"
· Modifiche tra i tag 1.3 e 1.5 che menzionano "bug" che influiscono hgext/*:
hg log -r "1.3::1.5 and keyword(bug) and file('hgext/*')"
· Modifiche commesse a maggio 2008, ordinate per utente:
hg log -r "sort(date('Maggio 2008'), utente)"
· Modifiche che menzionano "bug" o "problema" che non sono in una versione con tag:
hg log -r "(parola chiave(bug) o parola chiave(problema)) e non antenati(tag())"
UTILIZZO MERCURIALE DA SCRIPT E AUTOMAZIONE
È comune per le macchine (al contrario degli umani) consumare Mercurial. Questo argomento di aiuto
descrive alcune delle considerazioni per interfacciare le macchine con Mercurial.
La scelta di an Interfaccia
Le macchine possono scegliere tra diversi metodi per interfacciarsi con Mercurial. Questi includono:
· L'esecuzione del hg processi
· Interrogazione di un server HTTP
· Chiamare un server di comando
Esecuzione hg è molto simile al modo in cui gli umani interagiscono con Mercurial nel guscio.
Dovrebbe già esserti familiare.
hg servire può essere utilizzato per avviare un server. Per impostazione predefinita, questo avvierà un server HTTP "hgweb".
Questo server HTTP supporta l'output leggibile dalla macchina, come JSON. Per di più, vedi hg
Aiuto hgweb.
hg servire può anche avviare un "server di comando". I client possono connettersi a questo server ed emettere
Comandi Mercurial su un protocollo speciale. Per maggiori dettagli sul server dei comandi,
inclusi i collegamenti alle librerie client, vedere https://mercurial.selenic.com/wiki/CommandServer.
hg servire le interfacce basate su hgweb e i server di comando hanno il vantaggio rispetto a semplici
hg elaborare le chiamate in quanto sono probabilmente più efficienti. Questo perché c'è
sovraccarico significativo per generare nuovi processi Python.
Suggerimento Se è necessario invocarne più di uno hg processi in breve tempo e/o le prestazioni sono
importante per te, l'uso di un'interfaccia basata su server è altamente raccomandato.
Ambiente Variabili
Come documentato in hg Aiuto ambiente, varie variabili ambientali influenzano il
funzionamento di Mercurial. Quanto segue è particolarmente rilevante per le macchine che consumano
Mercuriale:
HGPLAIN
Se non è impostato, l'output di Mercurial potrebbe essere influenzato dalle impostazioni di configurazione che
influire sulla sua codifica, modalità dettagliata, localizzazione, ecc.
Si consiglia vivamente alle macchine di impostare questa variabile durante l'invocazione hg
processi.
CODIFICA HGEN
Se non è impostato, le impostazioni internazionali utilizzate da Mercurial verranno rilevate dall'ambiente. Se
la localizzazione determinata non supporta la visualizzazione di determinati caratteri, Mercurial potrebbe
rende queste sequenze di caratteri in modo errato (spesso usando "?" come segnaposto
per caratteri non validi nelle impostazioni internazionali correnti).
L'impostazione esplicita di questa variabile di ambiente è una buona pratica da garantire
risultati coerenti. "utf-8" è una buona scelta in ambienti simili a UNIX.
HGRCPATH
Se non è impostato, Mercurial erediterà le opzioni di configurazione dai file di configurazione utilizzando il pulsante
processo descritto in hg Aiuto config. Ciò include l'ereditarietà dell'utente o dell'intero sistema
file di configurazione.
Quando si desidera il massimo controllo sulla configurazione Mercurial, il valore di
HGRCPATH può essere impostato su un file esplicito con configurazioni valide note. In rari casi, il
il valore può essere impostato su un file vuoto o sul dispositivo nullo (spesso / Dev / null) per bypassare
caricamento di qualsiasi file di configurazione utente o di sistema. Si noti che questi approcci possono avere
conseguenze indesiderate, poiché i file di configurazione dell'utente e del sistema spesso definiscono le cose
come il nome utente e le estensioni che potrebbero essere necessarie per interfacciarsi con a
repository.
Consumare Comando Uscita
È comune che le macchine debbano analizzare l'output dei comandi Mercurial per rilevanti
dati. Questa sezione descrive le varie tecniche per farlo.
parsing Crudo Comando Uscita
Probabilmente la soluzione più semplice ed efficace per consumare l'output del comando è semplicemente
invocare hg comandi come faresti come utente e analizza il loro output.
L'output di molti comandi può essere facilmente analizzato con strumenti come grep, setee awk.
Un potenziale svantaggio dell'analisi dell'output del comando è che l'output dei comandi può cambiare
quando Mercurial viene aggiornato. Mentre Mercurial generalmente si sforza per un forte all'indietro
compatibilità, l'output del comando cambia occasionalmente. Avere test per il tuo automatizzato
interazioni con hg comandi è generalmente consigliato, ma è ancora più importante quando
è coinvolta l'analisi dell'output del comando raw.
utilizzando Modelli a Control Uscita
Molti hg i comandi supportano l'output con modelli tramite il -T/--modello discussione. Per di più, vedi
hg Aiuto modelli.
I modelli sono utili per controllare esplicitamente l'output in modo da ottenere esattamente i dati
vuoi formattato come vuoi. Per esempio, ceppo -T {nodo}\n può essere utilizzato per stampare a
elenco delimitato da nuova riga di nodi changeset invece di un output personalizzato contenente
autori, date, descrizioni, ecc.
Suggerimento Se l'analisi dell'output del comando non elaborato è troppo complicata, considera l'utilizzo di modelli per creare
la tua vita più facile.
I -T/--modello argomento consente di specificare stili predefiniti. Mercurial navi con il
stili leggibili dalla macchina json ed xml, che forniscono rispettivamente output JSON e XML.
Questi sono utili per produrre un output leggibile dalla macchina così com'è.
Consigli
I json ed xml gli stili sono considerati sperimentali. Anche se possono essere attraenti
da utilizzare per ottenere facilmente un output leggibile dalla macchina, il loro comportamento può cambiare in
versioni successive.
Questi stili possono anche mostrare risultati imprevisti quando si tratta di certi
codifiche. Mercurial tratta cose come i nomi di file come una serie di byte e
normalizzare determinate sequenze di byte su JSON o XML con determinate impostazioni di codifica
può riservare sorprese.
Comando server Uscita
Se usi il server dei comandi per interagire con Mercurial, probabilmente stai usando un'esistente
libreria/API che astrae i dettagli di implementazione del server dei comandi. Se è così, questo
il livello di interfaccia può eseguire l'analisi per te, risparmiandoti il lavoro di implementazione
te stesso.
Uscita Verbosità
I comandi hanno spesso una verbosità di output variabile, anche quando sono in corso stili leggibili dalla macchina
usato (es -T json). aggiungendo -v/--prolisso ed - debug agli argomenti del comando can
aumentare la quantità di dati esposti da Mercurial.
Un modo alternativo per ottenere i dati necessari è specificare in modo esplicito un modello.
Altro Argomenti
revisioni
Gli insiemi di revisioni sono un linguaggio di interrogazione funzionale per la selezione di un insieme di revisioni.
Pensalo come SQL per i repository Mercurial. Le revisioni sono utili per le query
repository per dati specifici.
See hg Aiuto revisioni per saperne di più.
Share estensione
I Share estensione fornisce funzionalità per la condivisione dei dati del repository attraverso
numerose copie funzionanti. Può anche "aggregare" automaticamente l'archiviazione logicamente
repository correlati durante la clonazione.
Configurazione di Share l'estensione può portare a un utilizzo significativo delle risorse
riduzione, in particolare intorno allo spazio su disco e alla rete. Questo è particolarmente vero
per ambienti di integrazione continua (CI).
See hg Aiuto -e Share per saperne di più.
SOTTOREPOSITORI
I sottorepository ti consentono di annidare repository o progetti esterni in un Mercurial genitore
repository e fare in modo che i comandi operino su di essi come un gruppo.
Mercurial attualmente supporta i sottorepository Mercurial, Git e Subversion.
I sottorepository sono costituiti da tre componenti:
1. Prelievi di repository nidificati. Possono apparire ovunque nella directory di lavoro padre.
2. Riferimenti a repository nidificati. Sono definiti in .hgsub, che dovrebbe essere inserito nel
root della directory di lavoro e indica da dove provengono i checkout del sottorepository.
I sottorepository Mercurial sono referenziati come:
percorso/a/annidato = https://example.com/nidificato/repo/percorso
Sono supportati anche i subrepos Git e Subversion:
percorso/a/annidato = [git]git://esempio.com/annidato/repo/percorso
percorso/a/annidato = [svn]https://example.com/annidato/trunk/percorso
where percorso/a/annidato è la posizione di checkout rispetto alla radice Mercurial genitore,
ed https://example.com/nested/repo/path è il percorso del repository di origine. La fonte può
fa anche riferimento a un percorso del filesystem.
Si noti che .hgsub non esiste di default nei repository Mercurial, devi
crearlo e aggiungerlo al repository padre prima di utilizzare i sottorepository.
3. Stati del repository nidificato. Sono definiti in .hgsubstate, che è posto nella radice
della directory di lavoro e acquisire tutte le informazioni necessarie per ripristinare il
sottorepository allo stato in cui è stato eseguito il commit in un changeset del repository padre.
Mercurial registra automaticamente gli stati dei repository nidificati durante il commit nel
archivio padre.
Note:
I .hgsubstate il file non deve essere modificato manualmente.
Aggiunta a Sottorepository
If .hgsub non esiste, crealo e aggiungilo al repository principale. Clona o controlla
i progetti esterni in cui desideri che risieda nel repository padre. Modificare .hgsub ed
aggiungi la voce del sottorepository come descritto sopra. A questo punto, il sottorepository è
tracciato e il prossimo commit registrerà il suo stato in .hgsubstate e legarlo al
insieme di modifiche impegnato.
Sincronizzazione a Sottorepository
I sottorepo non tengono automaticamente traccia dell'ultimo changeset delle loro fonti. Invece, loro
vengono aggiornati al changeset che corrisponde al changeset estratto nel
set di modifiche di primo livello. In questo modo gli sviluppatori ottengono sempre un set coerente di codice compatibile
e biblioteche quando si aggiornano.
Pertanto, l'aggiornamento dei sottorepo è un processo manuale. Basta controllare il subrepo di destinazione su
revisione desiderata, testare nel repository di livello superiore, quindi eseguire il commit nel repository padre per
registrare la nuova combinazione.
Eliminazione a Sottorepository
Per rimuovere un sottorepository dal repository padre, elimina il suo riferimento da .hgsub,
quindi rimuovere i suoi file.
Interazione con mutevole Comandi
aggiungere add non ricorre nei subrepos a meno che non sia specificato -S/--subrepos. Tuttavia, se
specifichi il percorso completo di un file in un sottorepo, verrà aggiunto anche senza
-S/--sottorepository specificato. I sottorepository Subversion sono attualmente silenziosi
ignorato.
Aggiungi Rimuovi
addremove non ricorre in subrepos a meno che non sia specificato -S/--subrepos.
Tuttavia, se specifichi il percorso completo di una directory in un sottorepo, addremove lo farà
essere eseguito su di esso anche senza specificare -S/--subrepos. Git e Subversion
i sottorepository stamperanno un avviso e continueranno.
archiviare
archive non ricorre nei sottorepository a meno che non sia specificato -S/--subrepos.
gatto cat attualmente gestisce solo le corrispondenze esatte di file nei sottorepo. Sovversione
i sottorepository sono attualmente ignorati.
commettere commit crea un'istantanea coerente dello stato dell'intero progetto e dei suoi
sottorepository. Se sono stati modificati dei sottorepository, Mercurial si interromperà.
Si può fare in modo che Mercurial effettui il commit di tutti i sottorepositori modificati specificando
-S/--subrepos, o impostando "ui.commitsubrepos=True" in un file di configurazione (vedi hg
Aiuto config). Dopo che non ci sono più sottorepository modificati, registra
il loro stato e infine lo impegna nel repository padre. Il --addremove
L'opzione rispetta anche l'opzione -S/--subrepos. Tuttavia, Git e Subversion
i sottorepository stamperanno un avviso e si interromperanno.
diff diff non ricorre nei subrepos a meno che non sia specificato -S/--subrepos. I cambiamenti sono
visualizzato come di consueto, sugli elementi dei sottorepository. I sottorepository di Subversion sono
attualmente silenziosamente ignorato.
file files non ricorre in subrepos a meno che non sia specificato -S/--subrepos. Tuttavia,
se specifichi il percorso completo di un file o di una directory in un sottorepo, sarà
visualizzato anche senza che sia stato specificato -S/--subrepos. Git e Subversion
i sottorepository sono attualmente ignorati silenziosamente.
dimenticare forget attualmente gestisce solo le corrispondenze esatte di file nei sottorepo. Git e Subversion
i sottorepository sono attualmente ignorati silenziosamente.
in arrivo
incoming non ricorre nei subrepos a meno che non sia specificato -S/--subrepos. Git e
I sottorepository Subversion sono attualmente ignorati silenziosamente.
uscente
outgoing non ricorre nei subrepos a meno che non sia specificato -S/--subrepos. Git e
I sottorepository Subversion sono attualmente ignorati silenziosamente.
tirare pull non è ricorsivo poiché non è chiaro cosa tirare prima della corsa hg update
. Elencare e recuperare tutte le modifiche ai sottorepository a cui fa riferimento il genitore
i changeset estratti dal repository sono nella migliore delle ipotesi costosi, impossibili in Subversion
Astuccio.
spingere Mercurial spingerà automaticamente prima tutti i sottorepository quando il genitore
il repository è in fase di push. Ciò garantisce la disponibilità di nuove modifiche al sottorepository
quando referenziato da repository di primo livello. Push non è un'opzione per Subversion
sottorepository.
status status non ricorre nei sottorepository a meno che non sia specificato -S/--subrepos.
Le modifiche al sottorepository vengono visualizzate come normali modifiche Mercurial sul
elementi di sottorepository. I sottorepository Subversion sono attualmente ignorati silenziosamente.
rimuovere remove non ricorre nei sottorepository a meno che non sia specificato -S/--subrepos.
Tuttavia, se si specifica un percorso di file o directory in un sottorepo, verrà rimosso
anche senza -S/--subrepos. I sottorepository Git e Subversion sono attualmente
silenziosamente ignorato.
update update ripristina i sottorepo nello stato in cui sono stati originariamente commessi in target
set di modifiche. Se il changeset registrato non è disponibile nel sottorepository corrente,
Mercurial lo inserirà prima dell'aggiornamento. Ciò significa che l'aggiornamento può
richiedono l'accesso alla rete quando si utilizzano i sottorepository.
rimappatura Sottorepository fonti
Una posizione di origine di un sottorepository può cambiare durante la vita di un progetto, invalidando i riferimenti
memorizzato nella cronologia del repository padre. Per risolvere questo problema, è possibile definire regole di riscrittura in
repository principale hgr file o nella configurazione di Mercurial. Vedi il [sottopercorsi] sezione in
hgr(5) per maggiori dettagli.
MODELLO USO
Mercurial ti consente di personalizzare l'output dei comandi tramite i modelli. Puoi anche
passare un modello o selezionare uno stile modello esistente dalla riga di comando, tramite il pulsante
--opzione modello.
Puoi personalizzare l'output per qualsiasi comando "simile a un registro": log, in uscita, in entrata, suggerimento,
genitori e capi.
Alcuni stili incorporati sono inclusi in Mercurial. Questi possono essere elencati con hg ceppo
--modello stratagemma. Esempio di utilizzo:
$ hg log -r1.0::1.1 --template changelog
Un modello è una parte di testo, con markup per invocare l'espansione della variabile:
$ hg log -r1 --template "{nodo}\n"
b56ce7b07c52de7d5fd79fb89701ea538af65746
Le stringhe tra parentesi graffe sono chiamate parole chiave. La disponibilità delle parole chiave dipende dal
contesto esatto del templater. Queste parole chiave sono generalmente disponibili per il modello a
comando tipo log:
segnalibro attivo
Corda. Il segnalibro attivo, se è associato al changeset
autore Corda. L'autore non modificato del changeset.
bisecare Corda. Lo stato di bisezione del changeset.
segnalibri
Elenco delle stringhe. Eventuali segnalibri associati al changeset. Imposta anche 'attivo',
il nome del segnalibro attivo.
ramo Corda. Il nome del ramo su cui è stato eseguito il commit del changeset.
modifiche dall'ultimo tag
Numero intero. Tutti gli antenati non presenti nell'ultimo tag.
bambini
Elenco delle stringhe. I figli del changeset.
quando Informazioni sulla data. La data in cui è stato eseguito il commit del changeset.
disc Corda. Il testo della descrizione del changeset.
diffstat
Corda. Statistiche delle modifiche con il seguente formato: "file modificati:
+aggiunte/-rimosse righe"
extra Elenco di dicts con chiave, voci di valore del campo 'extra' di questo changeset.
file_aggiunge
Elenco delle stringhe. File aggiunti da questo changeset.
file_copie
Elenco delle stringhe. File copiati in questo changeset con le loro fonti.
interruttore_copie_file
Elenco delle stringhe. Come "file_copies" ma visualizzato solo se l'opzione --copied è
impostato.
file_dels
Elenco delle stringhe. File rimossi da questo changeset.
file_mods
Elenco delle stringhe. File modificati da questo changeset.
file Elenco delle stringhe. Tutti i file modificati, aggiunti o rimossi da questo changeset.
nodo grafo
Corda. Il carattere che rappresenta il nodo changeset in un grafico di revisione ASCII
ultimo tag
Elenco delle stringhe. I tag globali sul più recente antenato globalmente taggato di
questo set di modifiche.
ultimatagdistanza
Numero intero. Percorso più lungo per l'ultimo tag.
spazi dei nomi
Detto di liste. Nomi allegati a questo changeset per spazio dei nomi.
nodo Corda. L'hash di identificazione del changeset, come stringa di 40 cifre esadecimali.
p1nodo Corda. L'hash di identificazione del primo genitore del changeset, come 40 cifre
stringa esadecimale. Se il changeset non ha genitori, tutte le cifre sono 0.
p1riv Numero intero. Il numero di revisione locale del repository del primo genitore del changeset, oppure
-1 se il changeset non ha genitori.
p2nodo Corda. L'hash di identificazione del secondo genitore del changeset, come 40 cifre
stringa esadecimale. Se il changeset non ha un secondo genitore, tutte le cifre sono 0.
p2riv Numero intero. Il numero di revisione locale del repository del secondo genitore del changeset, oppure
-1 se il changeset non ha un secondo genitore.
genitori
Elenco delle stringhe. I genitori del changeset in formato "rev:node". Se la
changeset ha solo un genitore "naturale" (la revisione del predecessore) niente è
mostrato.
fase Corda. Il nome della fase changeset.
idfasex
Numero intero. L'indice di fase changeset.
rev Numero intero. Il numero di revisione del changeset locale del repository.
sottorepository
Elenco delle stringhe. Sottorepository aggiornati nel changeset.
tag Elenco delle stringhe. Qualsiasi tag associato al changeset.
La parola chiave "date" non produce un output leggibile. Se vuoi usare una data in
il tuo output, puoi utilizzare un filtro per elaborarlo. I filtri sono funzioni che restituiscono a
stringa in base alla variabile di input. Assicurati di usare prima il filtro stringify quando sei
applicare un filtro di input stringa a una variabile di input di tipo elenco. Puoi anche usare una catena di
filtri per ottenere l'output desiderato:
$ hg tip --template "{date|isodate}\n"
2008-08-21 18:22 +0000
Elenco dei filtri:
aggiunte
Qualsiasi testo. Aggiungi un XHTML " " tag prima della fine di ogni riga tranne l'ultima.
Data. Restituisce una differenza di data/ora leggibile dall'uomo tra la data/ora specificata e
la data/ora corrente.
nome di base
Qualsiasi testo. Tratta il testo come un tracciato e restituisce l'ultimo componente del tracciato
dopo la divisione dal separatore di percorso (ignorando i separatori finali). Per esempio,
"foo/bar/baz" diventa "baz" e "foo/bar//" diventa "bar".
contare Elenco o testo. Restituisce la lunghezza come numero intero.
dominio Qualsiasi testo. Trova la prima stringa che assomiglia a un indirizzo email ed estrae
solo il componente del dominio. Esempio: Utente <[email protected]> diventa example.com.
email Qualsiasi testo. Estrae la prima stringa che assomiglia a un indirizzo di posta elettronica. Esempio: Utente
<[email protected]> diventa [email protected].
utente di posta elettronica
Qualsiasi testo. Restituisce la parte utente di un indirizzo email.
fuga Qualsiasi testo. Sostituisce i caratteri speciali XML/XHTML "&", "<" e ">" con XML
entità e filtra i caratteri NUL.
FILL68 Qualsiasi testo. Avvolge il testo per adattarsi a 68 colonne.
FILL76 Qualsiasi testo. Avvolge il testo per adattarsi a 76 colonne.
prima linea
Qualsiasi testo. Restituisce la prima riga di testo.
hex Qualsiasi testo. Converti un identificatore di nodo Mercurial binario nel suo lungo esadecimale
rappresentazione.
data Data. Restituisce la data come coppia di numeri: "1157407993 25200" (timestamp Unix,
differenza di fuso orario).
isodato
Data. Restituisce la data in formato ISO 8601: "2009-08-18 13:00 +0200".
isodate sec
Data. Restituisce la data in formato ISO 8601, inclusi i secondi: "2009-08-18 13:00:13
+0200". Vedere anche il filtro rfc3339date.
inferiore Qualsiasi testo. Converte il testo in minuscolo.
non vuota
Qualsiasi testo. Restituisce '(nessuno)' se la stringa è vuota.
confondere
Qualsiasi testo. Restituisce il testo di input reso come una sequenza di entità XML.
persona Qualsiasi testo. Restituisce il nome prima di un indirizzo email, interpretandolo come da RFC
5322
rivivere
Qualsiasi testo. Esegue l'escape di tutti i caratteri "speciali", tranne @. Le barre in avanti sono sfuggite
due volte per impedire ai server Web di sbloccarli prematuramente. Ad esempio, "@pippo
bar/baz" diventa "@foo%20bar%252Fbaz".
rfc3339data
Data. Restituisce una data utilizzando il formato data Internet specificato in RFC 3339:
"2009-08-18T13:00:13+02:00".
rfc822data
Data. Restituisce una data utilizzando lo stesso formato utilizzato nelle intestazioni dei messaggi di posta elettronica: "Mar, 18 agosto 2009
13:00:13 +0200".
corto Hash dell'insieme di modifiche. Restituisce la forma breve di un hash changeset, cioè un 12 esadecimale
stringa di cifre.
bisettrice
Qualsiasi testo. tratta testo come stato di bisezione e restituisce un carattere singolo
che rappresenta lo stato (G: buono, B: cattivo, S: saltato, U: non testato, I: ignorato).
Restituisce lo spazio singolo se testo non è uno stato di bisezione valido.
breve data
Data. Restituisce una data come "2006-09-18".
linee spezzate
Qualsiasi testo. Dividi il testo in un elenco di righe.
stringere
Qualsiasi tipo. Trasforma il valore in testo convertendo i valori in testo e
concatenandoli.
spogliarello
Considera il testo come percorso ed elimina un livello di directory, se possibile. Ad esempio, "pippo"
e "foo/bar" diventa "foo".
tabellone
Qualsiasi testo. Restituisce il testo, con ogni riga non vuota tranne la prima iniziale
con un carattere di tabulazione.
superiore Qualsiasi testo. Converte il testo in maiuscolo.
urlescape
Qualsiasi testo. Esegue l'escape di tutti i caratteri "speciali". Ad esempio, "foo bar" diventa
"foo%20bar".
Utente Qualsiasi testo. Restituisce una breve rappresentazione di un nome utente o di un indirizzo e-mail.
Nota che un filtro non è altro che una chiamata di funzione, ad es espr|filtro è equivalente
a filtro (espr).
Oltre ai filtri, ci sono alcune funzioni integrate di base:
data(data[, fmt])
Formatta una data. Vedere hg Aiuto DATE per la formattazione delle stringhe. L'impostazione predefinita è una data Unix
formato, incluso il fuso orario: "Mon Sep 04 15:13:13 2006 0700".
diff([include pattern [, modello di esclusione]])
Mostra una differenza, specificando facoltativamente i file da includere o escludere.
fill(testo[, larghezza[, identificatore iniziale[, pendenti]]])
Riempi molti paragrafi con rientri facoltativi. Vedi il filtro "riempi".
ottenere (dettare, chiave)
Ottieni un attributo/chiave da un oggetto. Alcune parole chiave sono tipi complessi. Questa funzione
permette di ottenere il valore di un attributo su questi tipi.
if(espr, poi[, altro])
Esegui condizionalmente in base al risultato di un'espressione.
ifcontains(cerca, cosa, poi[, altro])
Esegui condizionalmente in base al fatto che l'elemento "cerca" sia in "cosa".
ifeq(espr1, espr2, poi[, altro])
Esegui condizionalmente in base al fatto che 2 elementi siano equivalenti.
trattino(testo, caratteri di rientro[, prima linea])
Rientra tutte le righe non vuote con i caratteri forniti nella stringa indentchars. Un
il terzo parametro opzionale sovrascriverà il rientro per la prima riga solo se
presente.
unisciti (elenco, settembre)
Unisci elementi in un elenco con un delimitatore.
etichetta(etichetta, espr)
Applicare un'etichetta al contenuto generato. Il contenuto con un'etichetta applicata può risultare
post-elaborazione aggiuntiva, come la colorazione automatica.
lasttag([modello])
I tag globali che corrispondono al modello specificato sul tag globale più recente
antenato di questo changeset.
datalocale(data[, zz])
Converte una data nel fuso orario specificato. L'impostazione predefinita è la data locale.
pad(testo, larghezza[, fillchar=' '[, destra=Falso]])
Riempi il testo con un carattere di riempimento.
revset(interrogazione[, formattarg...])
Eseguire una query del set di revisioni. Vedere hg Aiuto capovolgere.
rstdoc(testo, stile)
Formatta testo strutturato.
più corto(nodo, lunghezza minima=4)
Ottieni la rappresentazione più breve di un nodo.
inizia con (modello, testo)
Restituisce il valore dall'argomento "testo" se inizia con il contenuto di
argomento "modello".
striscia(testo[, caratteri])
Elimina i caratteri da una stringa. Per impostazione predefinita, rimuove tutte le iniziali e le finali
spazio bianco.
sub(modello, sostituzione, espressione)
Eseguire la sostituzione del testo utilizzando le espressioni regolari.
parola(numero, testo[, separatore])
Restituisce l'ennesima parola da una stringa.
Inoltre, per qualsiasi espressione che restituisce un elenco, esiste un operatore elenco:
espr % "{modello}"
Come visto nell'esempio sopra, {modello} viene interpretato come un modello. Per impedirlo
essendo interpretato, puoi usare un carattere di escape \{ o un prefisso di stringa non elaborato, R'...'.
Alcuni modelli di riga di comando di esempio:
· Formatta elenchi, ad es. file:
$ hg log -r 0 --template "files:\n{files % ' {file}\n'}"
· Unisciti all'elenco dei file con un ", ":
$ hg log -r 0 --template "files: {join(files, ', ')}\n"
· Modifica ogni riga di una descrizione del commit:
$ hg log --template "{splitlines(desc) % '**** {line}\n'}"
· Formato data:
$ hg log -r 0 --template "{data(data, '%Y')}\n"
· Visualizza la data in UTC:
$ hg log -r 0 --template "{localdate(data, 'UTC')|data}\n"
· Emetti la descrizione impostata su una larghezza di riempimento di 30:
$ hg log -r 0 --template "{fill(desc, 30)}"
· Utilizzare un condizionale per verificare il ramo predefinito:
$ hg log -r 0 --template "{ifeq(branch, 'default', 'on the main branch',
'sul ramo {ramo}')}\n"
· Aggiungi una nuova riga se non vuota:
$ hg tip --template "{if(author, '{author}\n')}"
· Etichettare l'output da utilizzare con l'estensione del colore:
$ hg log -r 0 --template "{label('changeset.{phase}', node|short)}\n"
· Invertire il filtro della prima riga, ovvero tutto tranne la prima riga:
$ hg log -r 0 --template "{sub(r'^.*\n?\n?', '', desc)}\n"
· Visualizza il contenuto del campo 'extra', uno per riga:
$ hg log -r 0 --template "{join(extras, '\n')}\n"
· Contrassegna il segnalibro attivo con '*':
$ hg log --template "{segnalibri % '{segnalibro}{ifeq(segnalibro, attivo, '*')} '}\n"
· Trova il tag candidato alla versione precedente, la distanza e le modifiche rispetto al tag:
$ hg log -r . --template "{latesttag('re:^.*-rc$') % '{tag}, {changes}, {distance}'}\n"
· Contrassegna il genitore della copia di lavoro con '@':
$ hg log --template "{ifcontains(rev, revset('.'), '@')}\n"
· Mostra i dettagli delle revisioni principali:
$ hg log --template "{revset('parents(%d)', rev) % '{desc|firstline}\n'}"
· Mostra solo le descrizioni dei commit che iniziano con "template":
$ hg log --template "{startswith('template', firstline(desc))}\n"
· Stampa la prima parola di ogni riga di un messaggio di commit:
$ hg log --template "{word(0, desc)}\n"
URL PERCORSI
Gli URL validi sono nella forma:
locale/filesystem/percorso[#revisione]
file://local/filesystem/percorso[#revisione]
http://[user[:pass]@]host[:port]/[path][#revision]
https://[user[:pass]@]host[:port]/[path][#revision]
ssh://[utente@]host[:porta]/[percorso][#revisione]
I percorsi nel filesystem locale possono puntare a repository Mercurial o raggruppare
file (come creato da hg fascio or hg in arrivo --fascio). Guarda anche hg Aiuto percorsi.
Un identificatore facoltativo dopo # indica un particolare ramo, tag o set di modifiche da utilizzare
dal repository remoto. Guarda anche hg Aiuto .
Alcune funzionalità, come il push di URL http:// e https://, sono possibili solo se l'estensione
funzione è esplicitamente abilitata sul server Mercurial remoto.
Tieni presente che la sicurezza degli URL HTTPS dipende dalla corretta configurazione di web.cacerts.
Alcune note sull'utilizzo di SSH con Mercurial:
· SSH richiede un account shell accessibile sul computer di destinazione e una copia di hg in
il percorso remoto o specificato con as remotecmd.
· il percorso è relativo alla home directory dell'utente remoto per impostazione predefinita. Usa una barra in più a
l'inizio di un percorso per specificare un percorso assoluto:
ssh://example.com//tmp/repository
· Mercurial non utilizza la propria compressione tramite SSH; la cosa giusta da fare è configurare
nel tuo ~ / .ssh / config, per esempio:
Ospita *.mylocalnetwork.example.com
Compressione n
Ospite *
Compressione si
In alternativa, specifica "ssh -C" come comando ssh nel file di configurazione o con
l'opzione della riga di comando --ssh.
Questi URL possono essere tutti archiviati nel tuo file di configurazione con alias di percorso in
sezione [percorsi] in questo modo:
[percorsi]
alias1 = URL1
alias2 = URL2
...
È quindi possibile utilizzare l'alias per qualsiasi comando che utilizza un URL (ad esempio hg tirare alias1
sarà trattato come hg tirare URL1).
Due alias di percorso sono speciali perché vengono utilizzati come predefiniti quando non si fornisce l'estensione
URL a un comando:
di default:
Quando crei un repository con hg clone, il comando clone salva la posizione di
il repository di origine come percorso "predefinito" del nuovo repository. Questo viene quindi utilizzato
quando si omette il percorso dai comandi di tipo push e pull (inclusi incoming e
estroverso).
push predefinito:
Il comando push cercherà un percorso chiamato 'default-push' e lo preferirà
'predefinito' se entrambi sono definiti.
ESTENSIONI
Questa sezione contiene la guida per le estensioni distribuite insieme a Mercurial.
La guida per altre estensioni è disponibile nel sistema di guida.
ACL
ganci per il controllo dell'accesso al repository
Questo hook consente di consentire o negare l'accesso in scrittura a determinati rami e percorsi di a
repository quando si ricevono i set di modifiche in entrata tramite pretxnchangegroup e pretxncommit.
L'autorizzazione è abbinata in base al nome utente locale sul sistema in cui l'hook
viene eseguito e non il committer del changeset originale (poiché quest'ultimo è semplicemente
Informativo).
Il gancio acl è meglio utilizzato insieme a un guscio limitato come hgsh, prevenendo
autenticare gli utenti dal fare qualcosa di diverso dal push o pull. Il gancio no
sicuro da usare se gli utenti hanno accesso alla shell interattiva, poiché possono quindi disabilitare l'hook. Né
è sicuro se gli utenti remoti condividono un account, perché non c'è modo di distinguerlo
Loro.
L'ordine in cui vengono eseguiti i controlli di accesso è:
1. Nega elenco per le filiali (sezione acl.deny.branches)
2. Elenco Consenti per filiali (sezione acl.allow.rami)
3. Nega l'elenco per i percorsi (sezione acl.nega)
4. Elenco Consenti per percorsi (sezione acl.consenti)
Le sezioni Consenti e Nega accettano coppie chiave-valore.
Basato su filiale accesso a Control
Usa il acl.deny.branches ed acl.allow.rami sezioni per avere accesso basato sulle filiali
controllo. Le chiavi in queste sezioni possono essere:
· un nome di filiale, o
· un asterisco, da abbinare a qualsiasi ramo;
I valori corrispondenti possono essere:
· un elenco separato da virgole contenente utenti e gruppi, o
· un asterisco, per abbinare chiunque;
Puoi aggiungere il "!" prefisso al nome di un utente o di un gruppo per invertire il senso della corrispondenza.
Basato sul percorso accesso a Control
Usa il acl.nega ed acl.consenti sezioni per avere il controllo dell'accesso basato sul percorso. Chiavi in queste
le sezioni accettano un modello di sottoalbero (con una sintassi glob per impostazione predefinita). Il corrispondente
i valori seguono la stessa sintassi delle altre sezioni precedenti.
ATTIVITA' E GRUPPI
I nomi dei gruppi devono essere preceduti da un @ simbolo. Specificare un nome di gruppo ha lo stesso effetto
come specificando tutti gli utenti in quel gruppo.
È possibile definire i membri del gruppo in acl.gruppi sezione. Se un nome di gruppo non è definito
lì, e Mercurial funziona con un sistema simile a Unix, l'elenco degli utenti verrà preso
dal sistema operativo. In caso contrario, verrà sollevata un'eccezione.
Esempio Configurazione
[ganci]
# Usalo se vuoi controllare le restrizioni di accesso al momento del commit
pretxncommit.acl = python:hgext.acl.hook
# Usalo se vuoi controllare le restrizioni di accesso per pull, push,
# impacchetta e servi.
pretxnchangegroup.acl = python:hgext.acl.hook
[ac]
# Consenti o nega l'accesso per le modifiche in arrivo solo se la loro origine è
# elencati qui, lasciali passare altrimenti. La fonte è "servire" per tutti
# accesso remoto (http o ssh), "push", "pull" o "bundle" quando il
# i comandi correlati vengono eseguiti localmente.
# Predefinito: servire
fonti = servire
[acl.deny.branche]
# Tutti sono negati al ramo congelato:
ramo-congelato = *
# Un utente errato viene negato su tutti i rami:
* = utente non valido
[acl.allow.rami]
# Alcuni utenti sono ammessi su branch-a:
ramo-a = utente-1, utente-2, utente-3
# È consentito un solo utente sul ramo-b:
ramo-b = utente-1
# Il super utente è autorizzato su qualsiasi ramo:
* = superutente
# Tutti sono ammessi su branch-for-test:
branch-for-test = *
[acl.nega]
# Questo elenco viene prima verificato. Se viene trovata una corrispondenza, acl.allow non lo è
# controllato. A tutti gli utenti viene concesso l'accesso se acl.deny non è presente.
# Formato per entrambi gli elenchi: modello glob = utente, ..., @gruppo, ...
# Per abbinare tutti, usa un asterisco per l'utente:
# mio/glob/modello = *
# utente6 non avrà accesso in scrittura a nessun file:
** = utente6
# Il gruppo "hg-denied" non avrà accesso in scrittura a nessun file:
** = @hg-negato
# Nessuno sarà in grado di modificare "DONT-TOUCH-THIS.txt", nonostante
# tutti possono modificare tutti gli altri file. Vedi sotto.
src/main/resources/DONT-TOUCH-THIS.txt = *
[acl.consenti]
# se acl.allow non è presente, tutti gli utenti sono autorizzati per impostazione predefinita
# vuoto acl.allow = nessun utente consentito
# L'utente "doc_writer" ha accesso in scrittura a qualsiasi file sotto "docs"
# cartella:
docs/** = scrittore_doc
# L'utente "jack" e il gruppo "designer" hanno accesso in scrittura a qualsiasi file
# nella cartella "immagini":
immagini/** = jack, @designers
# Tutti (tranne "user6" e "@hg-denied" - vedi acl.deny sopra)
# avrà accesso in scrittura a qualsiasi file nella cartella "risorse".
# (tranne 1 file. Vedi acl.deny):
sorgente/principale/risorse/** = *
.hgtags = ingegnere_rilascio
Esempi utilizzando , il ! prefisso
Supponiamo che ci sia un ramo a cui solo un determinato utente (o gruppo) dovrebbe essere in grado di eseguire il push, e
non vuoi limitare l'accesso a nessun altro ramo che potrebbe essere creato.
Il "!" prefisso ti consente di impedire a chiunque tranne un determinato utente o gruppo di eseguire il push
changeset in un determinato ramo o percorso.
Negli esempi seguenti: 1) Negheremo l'accesso al ramo "ring" a chiunque tranne l'utente
"gollum" 2) Negare l'accesso al ramo "lago" a chiunque tranne che ai membri del gruppo "hobbit" 3)
Nega l'accesso a un file a chiunque tranne l'utente "gollum"
[acl.allow.rami]
# Vuoto
[acl.deny.branche]
# 1) solo 'gollum' può impegnarsi nel ramo 'ring';
# 'gollum' e chiunque altro può ancora impegnarsi in qualsiasi altro ramo.
anello = !gollum
# 2) solo i membri del gruppo 'hobbit' possono impegnarsi nel ramo 'lago';
# I membri 'hobbit' e chiunque altro possono ancora impegnarsi in qualsiasi altro ramo.
lago = !@hobbit
# Puoi anche negare l'accesso in base ai percorsi dei file:
[acl.consenti]
# Vuoto
[acl.nega]
# 3) solo 'gollum' può modificare il file sottostante;
# 'gollum' e chiunque altro può comunque modificare qualsiasi altro file.
/nebbioso/montagne/grotta/anello = !gollum
scatola nera
registra gli eventi del repository in una blackbox per il debug
Registra le informazioni sugli eventi in .hg/blackbox.log per aiutare a eseguire il debug e diagnosticare i problemi. Il
gli eventi che vengono registrati possono essere configurati tramite la chiave di configurazione blackbox.track. Esempi:
[scatola nera]
traccia = *
[scatola nera]
track = comando, commandfinish, commandexception, exthook, pythonhook
[scatola nera]
traccia = in arrivo
[scatola nera]
# limitare la dimensione di un file di registro
dimensione massima = 1.5 MB
# ruota fino a N file di registro quando quello attuale diventa troppo grande
maxfile = 3
Comandi
scatola nera
visualizza gli eventi recenti del repository:
hg blackbox [OPZIONE]...
visualizzare gli eventi recenti del repository
Opzioni:
-l,--limite
il numero di eventi da mostrare (predefinito: 10)
bugzilla
ganci per l'integrazione con Bugzilla bug tracker
Questa estensione hook aggiunge commenti sui bug in Bugzilla quando i set di modifiche si riferiscono a bug
by Bugzilla ID vengono visualizzati. Il commento è formattato utilizzando il meccanismo del modello Mercurial.
I riferimenti ai bug possono opzionalmente includere un aggiornamento per Bugzilla delle ore trascorse
lavorando sul bug. I bug possono anche essere contrassegnati come risolti.
Sono previste tre modalità di accesso di base a Bugzilla:
1. Accesso tramite l'interfaccia Bugzilla XMLRPC. Richiede Bugzilla 3.4 o successivo.
2. Controlla i dati tramite l'interfaccia Bugzilla XMLRPC e invia la modifica del bug via e-mail a
Interfaccia e-mail di Bugzilla. Richiede Bugzilla 3.4 o successivo.
3. Scrivere direttamente nel database di Bugzilla. Solo le installazioni di Bugzilla che utilizzano MySQL lo sono
supportato. Richiede Python MySQLdb.
La scrittura diretta nel database è soggetta a modifiche dello schema e si basa su a
Bugzilla contrib script per inviare e-mail di notifica di modifica dei bug. Questo script viene eseguito come
l'utente che esegue Mercurial, deve essere eseguito sull'host con l'installazione di Bugzilla, e
richiede l'autorizzazione per leggere i dettagli di configurazione di Bugzilla e l'utente MySQL necessario
e password per avere i diritti di accesso completo al database Bugzilla. Per questi motivi questo
la modalità di accesso è ora considerata deprecata e non verrà aggiornata per il nuovo Bugzilla
versioni future. In questa modalità di accesso è supportata solo l'aggiunta di commenti.
L'accesso tramite XMLRPC richiede un nome utente e una password Bugzilla da specificare nel file
configurazione. I commenti vengono aggiunti sotto quel nome utente. Poiché la configurazione deve essere
leggibile da tutti gli utenti Mercurial, si raccomanda che i diritti di quell'utente lo siano
limitato in Bugzilla al minimo necessario per aggiungere commenti. Errori di marcatura corretti
richiede Bugzilla 4.0 e versioni successive.
L'accesso tramite XMLRPC/e-mail utilizza XMLRPC per interrogare Bugzilla, ma invia e-mail a Bugzilla
interfaccia di posta elettronica per inviare commenti ai bug. L'indirizzo Da: nell'e-mail è impostato su
indirizzo email dell'utente Mercurial, quindi il commento sembra provenire da Mercurial
utente. Nel caso in cui l'e-mail dell'utente Mercurial non venga riconosciuta da Bugzilla come a
Utente Bugzilla, l'e-mail associata al nome utente Bugzilla utilizzato per accedere a Bugzilla
viene invece utilizzato come fonte del commento. La marcatura dei bug corretti funziona su tutti i dispositivi supportati
Versioni Bugzilla.
Elementi di configurazione comuni a tutte le modalità di accesso:
bugzilla.versione
Il tipo di accesso da utilizzare. I valori riconosciuti sono:
xmlrpc
Interfaccia Bugzilla XMLRPC.
xmlrpc+e-mail
Bugzilla XMLRPC e interfacce e-mail.
3.0
Accesso a MySQL, Bugzilla 3.0 e versioni successive.
2.18
Accesso a MySQL, Bugzilla 2.18 e versioni successive, ma non incluso, 3.0.
2.16
Accesso a MySQL, Bugzilla 2.16 e versioni successive, ma non incluso, 2.18.
bugzilla.regexp
Espressione regolare per abbinare gli ID bug per l'aggiornamento nel messaggio di commit del changeset. Esso
deve contenere un gruppo denominato "()". contenente gli ID bug separati da
caratteri non numerici. Può anche contenere un gruppo denominato con una
numero a virgola mobile che indica le ore lavorate sul bug. Se non lo sono gruppi denominati
al momento, si presume che il primo gruppo "()" contenga gli ID bug e il tempo di lavoro lo sia
non aggiornato. L'espressione predefinita corrisponde Insetto 1234, Insetto no. 1234, Insetto numero
1234, Bugs 1234,5678, Insetto 1234 ed 5678 e loro variazioni, seguite da an
numero delle ore preceduto da h or ore, per esempio ore 1.5. La corrispondenza non fa distinzione tra maiuscole e minuscole.
bugzilla.fixregexp
Espressione regolare per abbinare gli ID bug per il contrassegno corretto nel messaggio di commit del changeset.
Questo deve contenere un gruppo denominato "()". ` contenente , il insetto ID diviso by
non cifra caratteri. It può anche contenere a detto gruppo `` con una
numero a virgola mobile che indica le ore lavorate sul bug. Se non lo sono gruppi denominati
al momento, si presume che il primo gruppo "()" contenga gli ID bug e il tempo di lavoro lo sia
non aggiornato. L'espressione predefinita corrisponde Correzioni 1234, Correzioni insetto 1234, Correzioni bug
1234,5678, Correzioni 1234 ed 5678 e relative variazioni, seguite da un numero di ore
preceduto da h or ore, per esempio ore 1.5. La corrispondenza non fa distinzione tra maiuscole e minuscole.
bugzilla.fixstatus
Lo stato su cui impostare un bug quando si contrassegna come corretto. Predefinito RISOLTI.
risoluzione bugzilla.fix
La risoluzione per impostare un bug quando si contrassegna la correzione. Predefinito FISSO.
bugzilla.style
Il file di stile da utilizzare durante la formattazione dei commenti.
bugzilla.template
Modello da utilizzare durante la formattazione dei commenti. Sostituisce lo stile se specificato. Inoltre
alle solite parole chiave Mercurial, l'estensione specifica:
{insetto}
L'ID bug di Bugzilla.
{radice}
Il percorso completo del repository Mercurial.
{webroot}
Percorso spogliato del repository Mercurial.
{hgweb}
URL di base per la navigazione nei repository Mercurial.
Predefinito changeset {nodo|breve} in pronti contro termine {radice} si riferisce a insetto
{bug}.\dettagli:\n\t{desc|tabindent}
bugzilla.strip
Il numero di caratteri separatori di percorso da rimuovere dalla parte anteriore del Mercurial
percorso del repository ({radice} nei modelli) da produrre {webroot}. Ad esempio, a
repository con {radice} /var/local/il mio-progetto con una striscia di 2 dà un valore per
{webroot} of il mio progetto. Predefinito 0.
URL.web.base
URL di base per la navigazione nei repository Mercurial. Riferito da modelli come {hgweb}.
Elementi di configurazione comuni alle modalità di accesso XMLRPC+e-mail e MySQL:
bugzilla.usermap
Percorso del file contenente l'e-mail del committente Mercurial alle mappature e-mail dell'utente Bugzilla.
Se specificato, il file dovrebbe contenere una mappatura per riga:
committer = utente Bugzilla
Vedi anche il [mappa utente] .
I [mappa utente] la sezione viene utilizzata per specificare le mappature dell'e-mail di Mercurial committer a Bugzilla
e-mail dell'utente. Guarda anche bugzilla.usermap. Contiene le voci del modulo committer = Bugzilla
Utente.
Configurazione della modalità di accesso XMLRPC:
bugzilla.bzurl
L'URL di base per l'installazione di Bugzilla. Predefinito http://localhost/bugzilla.
bugzilla.utente
Il nome utente da utilizzare per accedere a Bugzilla tramite XMLRPC. Predefinito bug.
bugzilla.password
La password per l'accesso a Bugzilla.
XMLRPC+modalità di accesso e-mail utilizza gli elementi di configurazione della modalità di accesso XMLRPC e inoltre:
bugzilla.bzemail
L'indirizzo e-mail di Bugzilla.
Inoltre, devono essere configurate le impostazioni e-mail di Mercurial. Vedere la documentazione in
hgr(5), sez [e-mail] ed [smp].
Configurazione della modalità di accesso MySQL:
bugzilla.host
Nome host del server MySQL che contiene il database Bugzilla. Predefinito localhost.
bugzilla.db
Nome del database Bugzilla in MySQL. Predefinito bug.
bugzilla.utente
Nome utente da utilizzare per accedere al server MySQL. Predefinito bug.
bugzilla.password
Password da utilizzare per accedere al server MySQL.
bugzilla.timeout
Timeout di connessione al database (secondi). Predefinito 5.
utente bugzilla.bz
Nome utente di Fallback Bugzilla con cui registrare i commenti, se il committer del changeset non può
essere trovato come utente Bugzilla.
bugzilla.bzdir
Directory di installazione di Bugzilla. Utilizzato per impostazione predefinita notifica. Predefinito /var/www/html/bugzilla.
bugzilla.notifica
Il comando da eseguire per fare in modo che Bugzilla invii e-mail di notifica di modifica dei bug.
Sostituisce da una mappa con 3 chiavi, bzdir, id (ID bug) e Utente (commissario bugzilla
e-mail). L'impostazione predefinita dipende dalla versione; da 2.18 è "cd %(bzdir)s && perl -T
contrib/sendbugmail.pl %(id)s %(user)s".
Attivazione dell'estensione:
[estensioni]
bugzilla =
[ganci]
# esegui bugzilla hook su ogni modifica prelevata o inserita qui
incoming.bugzilla = python:hgext.bugzilla.hook
Esempi di configurazioni:
Esempio di configurazione XMLRPC. Questo utilizza Bugzilla a http://my-project.org/bugzilla,
accedendo come utente [email protected] con password spina. Si usa con a
raccolta di archivi Mercurial in /var/local/hg/repos/, con un'interfaccia web all'indirizzo
http://my-project.org/hg.
[bugzilla]
bzurl=http://my-project.org/bugzilla
utente=[email protected]
password=spina
versione=xmlrpc
template=Insieme di modifiche {nodo|short} in {root|basename}.
{hgweb}/{webroot}/rev/{node|breve}\n
{dec}\n
striscia=5
[ragnatela]
URL base=http://my-project.org/hg
Esempio di configurazione XMLRPC+e-mail. Questo utilizza Bugzilla a
http://my-project.org/bugzilla, accedendo come utente [email protected] con password
spina. Viene utilizzato con una raccolta di repository Mercurial in /var/local/hg/repos/,
con un'interfaccia web su http://my-project.org/hg. I commenti sui bug vengono inviati a Bugzilla
indirizzo email [email protected].
[bugzilla]
bzurl=http://my-project.org/bugzilla
utente=[email protected]
password=spina
versione=xmlrpc+email
bzemail=[email protected]
template=Insieme di modifiche {nodo|short} in {root|basename}.
{hgweb}/{webroot}/rev/{node|breve}\n
{dec}\n
striscia=5
[ragnatela]
URL base=http://my-project.org/hg
[mappa utente]
[email protected]=[email protected]
Esempio di configurazione di MySQL. Questo ha un'installazione Bugzilla 3.2 locale in
/opt/bugzilla-3.2. Il database MySQL è attivo localhost, il nome del database Bugzilla è bug
e si accede a MySQL con il nome utente MySQL bug parola d'ordine XYZY. Si usa con a
raccolta di archivi Mercurial in /var/local/hg/repos/, con un'interfaccia web all'indirizzo
http://my-project.org/hg.
[bugzilla]
host=host locale
parola d'ordine=XYZZY
versione=3.0
utentebz=[email protected]
bzdir=/opt/bugzilla-3.2
template=Insieme di modifiche {nodo|short} in {root|basename}.
{hgweb}/{webroot}/rev/{node|breve}\n
{dec}\n
striscia=5
[ragnatela]
URL base=http://my-project.org/hg
[mappa utente]
[email protected]=[email protected]
Tutto quanto sopra aggiunge un commento al record di bug di Bugzilla del modulo:
Changeset 3b16791d6642 in nome-repository.
http://my-project.org/hg/repository-name/rev/3b16791d6642
Commento al commit del changeset. Bug 1234.
censurare
cancella il contenuto del file a una data revisione
Il comando di censura ordina a Mercurial di cancellare tutto il contenuto di un file a una data revisione
senza aggiornamento , il changeset hash. Ciò consente alla cronologia esistente di rimanere valida finché
impedendo a futuri cloni/pull di ricevere i dati cancellati.
Gli usi tipici della censura sono dovuti a requisiti di sicurezza o legali, tra cui:
* Password, chiavi private, materiale crittografico
* Dati/codice/librerie concessi in licenza per i quali la licenza è scaduta
* Informazioni di identificazione personale o altri dati privati
I nodi censurati possono interrompere il funzionamento tipico di mercurial ogni volta che i dati escissi hanno bisogno
da materializzare. Alcuni comandi, come hg gatto/hg ritornare, fallisci semplicemente quando richiesto
produrre dati censurati. Altri, come hg verificare ed hg update, deve essere in grado di tollerare
dati censurati per continuare a funzionare in modo significativo. Tali comandi tollerano solo
revisioni di file censurate se consentite dall'opzione di configurazione "censor.policy=ignore".
Comandi
censurare
hg censor -r REV [-t TESTO] [FILE]
Opzioni:
-R,--rev
file di censura dalla revisione specificata
-T,--lapide
dati della lapide di sostituzione
chgserver
estensione del server di comando per cHg (SPERIMENTALE)
'S' canale (leggere scrivere)
propaga la richiesta ui.system() al client
'attacchio' command
allega lo stdio del client passato da sendmsg()
'chdir' command
cambia la directory corrente
'getpage' command
controlla se il cercapersone è abilitato e quale cercapersone deve essere eseguito
'setenv' command
sostituire completamente os.environ
'SORRISO' segnale
ricaricare i file di configurazione
bambini
comando per visualizzare i changeset figlio (DEPRECATO)
Questa estensione è obsoleta. Dovresti usare hg ceppo -r "bambini (REV)" anziché.
Comandi
bambini
mostra ai figli della revisione della directory data o di lavoro:
hg bambini [-r REV] [FILE]
Stampa i figli delle revisioni della directory di lavoro. Se viene data una revisione tramite
-r/--rev, verranno stampati i figli di quella revisione. Se viene fornito un argomento di file,
revisione in cui il file è stato modificato l'ultima volta (dopo la revisione della directory di lavoro o il file
viene stampato l'argomento in --rev se fornito).
Si prega di utilizzare hg ceppo anziché:
hg figli => hg log -r 'bambini ()'
hg children -r REV => hg log -r 'children(REV)'
See hg Aiuto ceppo ed hg Aiuto revset.bambini.
Opzioni:
-R,--rev
mostra i figli della revisione specificata
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
zangola
comando per visualizzare le statistiche sulla cronologia del repository
Comandi
zangola
istogramma delle modifiche al repository:
hg churn [-d DATE] [-r REV] [--alias FILE] [FILE]
Questo comando visualizzerà un istogramma che rappresenta il numero di righe modificate o
revisioni, raggruppate in base al modello fornito. Il modello predefinito si raggrupperà
modifiche per autore. L'opzione --dateformat può essere utilizzata per raggruppare i risultati per data
anziché.
Le statistiche si basano sul numero di righe modificate o, in alternativa, sul numero di
revisioni corrispondenti se è specificata l'opzione --changesets.
Consigli d'uso:
# mostra il conteggio delle righe modificate per ogni committente
hg churn -t "{autore|email}"
# visualizza il grafico dell'attività giornaliera
hg abbandono -f "%H" -s -c
# mostra l'attività degli sviluppatori per mese
hg abbandono -f "%Y-%m" -s -c
# visualizza il conteggio delle righe modificate in ogni anno
hg abbandono -f "%Y" -s
È possibile mappare indirizzi email alternativi a un indirizzo principale fornendo un file
utilizzando il seguente formato:
=
Tale file può essere specificato con l'opzione --aliases, altrimenti lo sarà un file .hgchurn
cercato nella directory di lavoro root. Gli alias verranno divisi dall'estrema destra "=".
Opzioni:
-R,--rev
tasso di conteggio per la revisione o il revset specificato
-D,--Data
tasso di conteggio per le revisioni corrispondenti alle specifiche della data
-T,--vecchio modello
modello per raggruppare i set di modifiche (DEPRECATO)
-T,--modello
modello per raggruppare i set di modifiche (predefinito: {author|email})
-F,--formato data
formato compatibile con strftime per il raggruppamento per data
-C, --changeset
tasso di conteggio per numero di set di modifiche
-S, --ordinare
ordina per chiave (predefinito: ordina per conteggio)
--diffstat
visualizzare le righe aggiunte/rimosse separatamente
--alias
file con alias email
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
clonebundle
pubblicizzare bundle pre-generati per seminare cloni
"clonebundles" è un'estensione lato server utilizzata per pubblicizzare l'esistenza di
file bundle pregenerati, ospitati esternamente ai client che stanno clonando in modo che la clonazione
può essere più veloce, più affidabile e richiedere meno risorse sul server.
La clonazione può essere un'operazione intensiva di CPU e I/O sui server. Tradizionalmente, il server, in
risposta alla richiesta di clonazione di un client, genera dinamicamente un bundle contenente il file
contenuto dell'intero repository e lo invia al client. Non c'è memorizzazione nella cache sul server
e il server dovrà generare in modo ridondante lo stesso bundle in uscita in risposta a
ogni richiesta di clonazione. Per i server con repository di grandi dimensioni o con un volume di clonazione elevato, il file
il carico dei cloni può rendere la scalabilità del server difficile e costosa.
Questa estensione offre agli operatori server la possibilità di scaricare potenzialmente costosi
clonare il carico su un servizio esterno. Ecco come funziona.
1. Un operatore del server stabilisce un meccanismo per rendere disponibili i file bundle su a
servizio di hosting dove i clienti Mercurial possono recuperarli.
2. Viene aggiunto un file manifest che elenca gli URL bundle disponibili e alcuni metadati opzionali
il repository Mercurial sul server.
3. Un client avvia un clone su un server compatibile con bundle clone.
4. Il client vede che il server sta pubblicizzando bundle di cloni e recupera il manifest
elencando i pacchetti disponibili.
5. Il client filtra e ordina i bundle disponibili in base a ciò che supporta e
preferisce.
6. Il client scarica e applica un bundle disponibile dall'URL specificato dal server.
7. Il client si riconnette al server originale ed esegue l'equivalente di hg tirare a
recuperare tutti i dati del repository non nel bundle. (Il repository potrebbe essere stato aggiornato
tra quando è stato creato il bundle e quando il client ha avviato il clone.)
Invece di generare bundle di repository completi per ogni richiesta di clone, il server
genera bundle completi una volta e vengono successivamente riutilizzati per avviare nuovi cloni. Il
il server può ancora trasferire i dati in fase di clonazione. Tuttavia, questi sono solo i dati che sono stati
aggiunto/modificato da quando è stato creato il pacchetto. Per grandi archivi consolidati, questo can
ridurre il carico del server per i cloni a meno dell'1% dell'originale.
Per funzionare, questa estensione richiede i seguenti operatori del server:
· Generazione di file bundle di contenuto del repository (in genere periodicamente, ad esempio una volta per
giorno).
· Un file server a cui i client hanno accesso in rete e con cui Python sa come parlare
attraverso la sua normale funzione di gestione degli URL (tipicamente un server HTTP).
· Un processo per mantenere sincronizzato il manifest dei bundle con i file di bundle disponibili.
A rigor di termini, l'utilizzo di un server di hosting di file statico non è richiesto: un operatore del server
potrebbe utilizzare un servizio dinamico per il recupero dei dati in bundle. Tuttavia, l'hosting di file statici
i servizi sono semplici e scalabili e dovrebbero essere sufficienti per la maggior parte delle esigenze.
I file bundle possono essere generati con hg fascio comando. Tipicamente hg fascio --tutti is
utilizzato per produrre un bundle dell'intero repository.
hg debugcreatestreamclonebundle può essere utilizzato per produrre uno speciale Streaming clonare fascio.
Si tratta di file bundle estremamente efficienti da produrre e consumare (leggi: veloce).
Tuttavia, sono più grandi dei tradizionali formati bundle e richiedono il supporto dei client
l'esatto insieme di formati di archivio dati del repository in uso dal repository che li ha creati.
In genere, un server più recente può fornire dati compatibili con i client meno recenti. Tuttavia,
Streaming clonare pachetti sconto non hanno questa garanzia server Operatori bisogno a be consapevole che
più nuovo versioni of mutevole può produrre Streaming clonare pachetti sconto incompatibile con maggiore
mutevole versioni.
Un operatore del server è responsabile della creazione di un file .hg/clonebundles.manifest file contenente
l'elenco dei file bundle disponibili adatti per il seeding dei cloni. Se questo file non lo fa
esiste, il repository non pubblicizzerà l'esistenza di bundle clone quando i client
connessione.
Il file manifest contiene un elenco di voci delimitato da una nuova riga ( ).
Ogni riga in questo file definisce un bundle disponibile. Le righe hanno il formato:
[ = [ = ]]
Cioè, un URL seguito da un elenco facoltativo delimitato da spazi di coppie chiave=valore che descrivono
proprietà aggiuntive di questo pacchetto. Sia le chiavi che i valori sono codificati in URI.
Le chiavi in MAIUSCOLO sono riservate all'uso da parte di Mercurial e sono definite di seguito. Tutti
le chiavi non maiuscole possono essere utilizzate dalle installazioni del sito. Un esempio di utilizzo per le proprietà personalizzate
è usare il datacenter attributo per definire in quale data center è ospitato un file.
I clienti potrebbero quindi preferire un server nel data center più vicino a loro.
Attualmente sono definite le seguenti chiavi riservate:
SPECIFICHE DEL PACCHETTO
Una stringa di "specifica del pacchetto" che descrive il tipo di pacchetto.
Questi sono valori di stringa accettati dall'argomento "--type" di hg fascio.
I valori vengono analizzati in modalità rigorosa, il che significa che devono essere di
" - " modulo. Per ulteriori informazioni, vedere mercurial.exchange.parsebundlespec()
dettagli.
hg pacchetto di debug --spec può essere utilizzato per stampare la stringa della specifica del bundle per a
fascicolo. L'output di questo comando può essere utilizzato testualmente per il valore di
SPECIFICHE DEL PACCHETTO (è già scappato).
I clienti filtreranno automaticamente le specifiche sconosciute o
non supportato, quindi non tenteranno di scaricare qualcosa che probabilmente non si applicherà.
Il valore effettivo non influisce sul comportamento del cliente al di là del filtraggio: lo faranno i clienti
annusare ancora il tipo di pacchetto dall'intestazione dei file scaricati.
Usa il of questo chiave is vivamente raccomandato, in quanto consente ai clienti di saltare facilmente
bundle non supportati. Se questa chiave non è definita, un vecchio client potrebbe tentare di applicare
un fascio che non è in grado di leggere.
RICHIESTA
Indica se è necessaria l'indicazione del nome del server (SNI) per connettersi all'URL. SNI consente
server per utilizzare più certificati sullo stesso IP. È piuttosto comune nei CDN
e altri fornitori di hosting. Le versioni precedenti di Python non supportano SNI. definizione
questo attributo consente ai client con versioni precedenti di Python di filtrare questa voce
senza che si verifichi un errore SSL opaco al momento della connessione.
Se è definito, è importante pubblicizzare un URL o client di fallback non SNI
l'esecuzione di versioni precedenti di Python potrebbe non essere in grado di clonare con i clonebundles
struttura.
Il valore dovrebbe essere "vero".
I manifesti possono contenere più voci. Supponendo che i metadati siano definiti, i client filtreranno
voci dal manifest che non supportano. Le voci rimanenti sono facoltative
ordinato in base alle preferenze del cliente (Experimental.clonebundleprefers opzione di configurazione). Il cliente
quindi tenta di recuperare il pacchetto al primo URL nell'elenco rimanente.
errori quando il download a fascio volere fallire , il intero clonare funzionamento: clienti do non
automaticamente cadere precedente a a tradizionale clone. La ragione di ciò è che se un server è
usando i bundle di cloni, probabilmente lo sta facendo perché la funzione è necessaria per aiutarlo
scala. In altre parole, si presume che il carico del clone venga scaricato su un altro
service e che il server Mercurial non è responsabile di servire questo carico di cloni. Se
che altri problemi di servizio sperimentano e che i clienti iniziano a ricadere in massa all'originale
Server Mercurial, il carico di clonazione aggiunto potrebbe sovraccaricare il server a causa di un carico imprevisto
e portalo offline in modo efficace. Non avere client ricadono automaticamente sulla clonazione
dal server originale attenua questo scenario.
Perché non esiste un fallback automatico del server Mercurial in caso di guasto del bundle di hosting
servizio, è importante che gli operatori del server visualizzino il servizio di bundle di hosting come un
estensione del server Mercurial in termini di disponibilità e accordi sui livelli di servizio:
se il servizio di bundle di hosting si interrompe, anche la possibilità per i client di clonare si interrompe. Nota:
i client vedranno un messaggio che li informa su come bypassare la funzione dei bundle di cloni quando a
si verifica il fallimento. Quindi gli operatori del server dovrebbero prepararsi affinché alcune persone li seguano
istruzioni quando si verifica un guasto, portando così più carico al Mercurial originale
server quando il servizio di bundle di hosting non riesce.
colore
colora l'output di alcuni comandi
L'estensione del colore colora l'output di diversi comandi Mercurial. Ad esempio, il
Il comando diff mostra le aggiunte in verde e le eliminazioni in rosso, mentre il comando status mostra
file modificati in magenta. Molti altri comandi hanno colori analoghi. È possibile
personalizza questi colori.
effetti
Sono disponibili anche altri effetti oltre al colore, come il testo in grassetto e sottolineato. Di
di default, il database terminfo viene utilizzato per trovare i codici terminali utilizzati per cambiare colore e
effetto. Se terminfo non è disponibile, gli effetti vengono resi con l'ECMA-48 SGR
funzione di controllo (aka codici di escape ANSI).
Gli effetti disponibili in modalità terminfo sono 'blink', 'bold', 'dim', 'inverse', 'invisible',
'corsivo', 'eccezionale' e 'sottolineato'; in modalità ECMA-48, le opzioni sono 'grassetto', 'inverso',
'corsivo' e 'sottolineato'. Il modo in cui ciascuno viene visualizzato dipende dall'emulatore di terminale. Alcuni
potrebbe non essere disponibile per un determinato tipo di terminale e verrà ignorato silenziosamente.
per il tuo brand
Il testo riceve effetti di colore a seconda delle etichette che ha. Molti hanno predefinito Mercurial
i comandi emettono testo etichettato. Puoi anche definire le tue etichette nei modelli usando
funzione etichetta, vedi hg Aiuto modelli. Una singola porzione di testo può averne più di una
etichetta. In tal caso, gli effetti assegnati all'ultima etichetta prevarranno su tutti gli altri effetti. Questo
include l'effetto speciale "nessuno", che annulla altri effetti.
Le etichette sono normalmente invisibili. Per vedere queste etichette e la loro posizione nel
testo, usa l'opzione --color=debug globale. Lo stesso anchor text può essere associato a
più etichette, ad es
[log.changeset changeset.secret|changeset: 22611:6f0a53c8f587]
Di seguito sono riportati gli effetti predefiniti per alcune etichette predefinite. Gli effetti predefiniti possono essere
sovrascritto dal tuo file di configurazione:
[colore]
status.modified = sottolineatura in grassetto blu sfondo_rosso
status.added = grassetto verde
status.removed = rosso grassetto sfondo_blu
status.deleted = sottolineatura grassetto ciano
status.unknown = sottolineatura grassetto magenta
status.ignored = grassetto nero
# 'nessuno' disattiva tutti gli effetti
status.clean = nessuno
stato.copiato = nessuno
qseries.applied = sottolineatura in grassetto blu
qseries.unapplied = grassetto nero
qseries.missing = grassetto rosso
diff.diffline = grassetto
diff.extended = ciano grassetto
diff.file_a = grassetto rosso
diff.file_b = grassetto verde
diff.pezzo = magenta
diff.cancellato = rosso
diff.inserito = verde
diff.cambiato = bianco
diff.tab =
diff.trailingwhitespace = sfondo_rosso in grassetto
# Vuoto in modo che erediti lo stile dell'etichetta circostante
changeset.pubblico =
changeset.bozza =
changeset.segreto =
resolve.unresolved = grassetto rosso
resolve.resolved = grassetto verde
bookmarks.active = verde
branch.active = nessuno
branch.closed = grassetto nero
branch.current = verde
branch.inactive = nessuno
tags.normal = verde
tags.local = grassetto nero
rebase.rebased = blu
rebase.remaining = grassetto rosso
shelve.age = ciano
shelve.newest = grassetto verde
shelve.name = grassetto blu
histedit.remaining = grassetto rosso
Custom Colori
Poiché ci sono solo otto colori standard, questo modulo consente di definire i nomi dei colori
per altri slot colore che potrebbero essere disponibili per il tuo tipo di terminale, assumendo terminfo
modalità. Per esempio:
colore.blu brillante = 12
colore.rosa = 207
colore.arancione = 202
per impostare 'blu brillante' sullo slot colore 12 (utile per terminali a 16 colori che hanno colori più luminosi
colori definiti negli otto superiori) e, "rosa" e "arancione" per i colori in xterm a 256 colori
cubo di colore predefinito. Questi colori definiti possono quindi essere utilizzati come uno qualsiasi dei predefiniti
otto, inclusa l'aggiunta di '_background' per impostare lo sfondo su quel colore.
Modalità
Per impostazione predefinita, l'estensione del colore utilizzerà la modalità ANSI (o la modalità win32 su Windows), se presente
rileva un terminale. Per ignorare la modalità automatica (per abilitare la modalità terminfo, ad esempio), impostare il
seguente opzione di configurazione:
[colore]
modalità = terminfo
Qualsiasi valore diverso da "ansi", "win32", "terminfo" o "auto" disabiliterà il colore.
Si noti che su alcuni sistemi, la modalità terminfo può causare problemi quando si utilizza il colore con il
estensione cercapersone e meno -R. meno con l'opzione -R visualizzerà solo il colore ECMA-48
codici e la modalità terminfo a volte può emettere codici che meno non capisce. Puoi
aggirare questo problema utilizzando la modalità ansi (o modalità automatica) o utilizzando less -r (che lo farà
passare attraverso tutti i codici di controllo del terminale, non solo i codici di controllo del colore).
Su alcuni sistemi (come MSYS in Windows), il terminale potrebbe supportare una modalità colore diversa
rispetto al cercapersone (attivato tramite l'estensione "cercapersone"). È possibile definire separati
modalità a seconda che il cercapersone sia attivo:
[colore]
modalità = automatico
pagermode = ansi
If modalità cercapersone non è definito, il modo verrà utilizzato.
Comandi
convertire
importare revisioni da repository VCS esteri in Mercurial
Comandi
convertire
convertire un repository SCM straniero in uno Mercurial.:
hg convert [OPZIONE]... FONTE [DEST [REVMAP]]
Formati sorgente accettati [identificatori]:
· Mercuriale [hg]
· CVS [CV]
· Darc [darc]
· git [git]
· Sovversione [svn]
· Monotono [mtn]
· GNU Arch [gnuarca]
· Bazar [bzr]
· Perforza [p4]
Formati di destinazione accettati [identificatori]:
· Mercuriale [hg]
· Subversion [svn] (la storia sui rami non è conservata)
Se non viene fornita alcuna revisione, tutte le revisioni verranno convertite. Altrimenti, converti solo volontà
importare fino alla revisione denominata (data in un formato compreso dalla fonte).
Se non viene specificato alcun nome di directory di destinazione, per impostazione predefinita viene utilizzato il nome di base dell'origine
con -hg allegato. Se il repository di destinazione non esiste, verrà creato.
Per impostazione predefinita, tutte le fonti eccetto Mercurial utilizzeranno --branchsort. Usi mercuriali
--sourcesort per preservare l'ordine dei numeri di revisione originale. Le modalità di ordinamento hanno le seguenti
effetti:
--branchsort
convertire da genitore a revisione figlio quando possibile, il che significa che i rami lo sono
di solito convertiti uno dopo l'altro. Genera repository più compatti.
--datasort
ordinare le revisioni per data. I repository convertiti hanno dei log delle modifiche di bell'aspetto, ma lo sono
spesso un ordine di grandezza maggiore degli stessi generati da --branchsort.
--sourcesort
cerca di preservare l'ordine delle revisioni dei sorgenti, supportato solo dai sorgenti Mercurial.
--closesort
prova a spostare le revisioni chiuse il più vicino possibile ai rami principali, solo
supportati da fonti mercuriali.
If REVMAP non viene fornito, verrà messo in una posizione predefinita (/.hg/shamap by
predefinito). Il REVMAP è un semplice file di testo che mappa ogni ID commit di origine su
ID di destinazione per quella revisione, in questo modo:
Se il file non esiste, viene creato automaticamente. Viene aggiornato su ogni commit copiato,
so hg convertire può essere interrotto e può essere eseguito ripetutamente per copiare nuovi commit.
L'authormap è un semplice file di testo che associa ogni autore del commit di origine a una destinazione
autore del commit. È utile per gli SCM di origine che utilizzano accessi unix per identificare gli autori (ad esempio:
CVS). Una riga per mappatura dell'autore e il formato della riga è:
autore di origine = autore di destinazione
Righe vuote e righe che iniziano con a # sono ignorati
Il filemap è un file che consente di filtrare e rimappare file e directory. Ogni
la riga può contenere una delle seguenti direttive:
includi percorso/di/file-o-dir
escludi percorso/di/file-o-dir
rinomina percorso/per/percorso sorgente/per/destinazione
Le righe di commento iniziano con #. Un percorso specificato corrisponde se è uguale al nome relativo completo
di un file o di una delle sue directory principali. Il includere or escludere direttiva con il
si applica il percorso di corrispondenza più lungo, quindi l'ordine delle righe non ha importanza.
I includere La direttiva fa sì che un file, o tutti i file in una directory, vengano inclusi nella
repository di destinazione. L'impostazione predefinita se non ci sono includere dichiarazioni deve includere
Tutto quanto. Se ce ne sono includere dichiarazioni, nient'altro è incluso. Il escludere
direttiva fa sì che i file o le directory vengano omessi. Il rinominare la direttiva rinomina un file
o directory se è stato convertito. Per rinominare da una sottodirectory nella radice di
deposito, uso . come percorso da rinominare.
--completo si assicurerà che i set di modifiche convertiti contengano esattamente i file corretti con
contenuto giusto. Farà una conversione completa di tutti i file, non solo di quelli che hanno
cambiato. I file che sono già corretti non verranno modificati. Questo può essere utilizzato per fare domanda
filemap cambia durante la conversione incrementale. Questo è attualmente supportato solo per
Mercuriale e Sovversione.
La splicemap è un file che permette l'inserimento della cronologia sintetica, permettendoti di specificare
i genitori di una revisione. Questo è utile se vuoi, ad esempio, dare a Subversion unire due
genitori, o innestare insieme due serie disconnesse di storia. Ogni voce contiene una chiave,
seguito da uno spazio, seguito da uno o due valori separati da virgole:
chiave genitore1, genitore2
La chiave è l'ID di revisione nel sistema di controllo della revisione della fonte di cui dovrebbero essere i genitori
modificato (stesso formato di una chiave in .hg/shamap). I valori sono gli ID di revisione (in entrambi
il sistema di controllo della revisione di origine o di destinazione) che dovrebbero essere utilizzati come nuovi genitori
per quel nodo. Ad esempio, se hai unito "release-1.0" in "trunk", dovresti farlo
specificare la revisione su "trunk" come primo genitore e quella su "release-1.0"
ramo come il secondo.
La branchmap è un file che ti permette di rinominare un branch quando viene importato
da qualsiasi repository esterno. Se utilizzato insieme a una splicemap, consente
per una potente combinazione per aiutare a riparare anche i repository più mal gestiti e
trasformali in repository Mercurial ben strutturati. La branchmap contiene righe di
il modulo:
nome_ramo_originale nome_ramo_nuovo
dove "original_branch_name" è il nome del ramo nel repository di origine e
"new_branch_name" è il nome del ramo è il repository di destinazione. Nessuno spazio bianco
è consentito nei nomi delle filiali. Questo può essere utilizzato (ad esempio) per spostare il codice in uno
repository da "predefinito" a un ramo denominato.
mutevole Fonte
La fonte Mercurial riconosce le seguenti opzioni di configurazione, che puoi impostare
la riga di comando con --config:
convert.hg.ignoreerrors
ignora gli errori di integrità durante la lettura. Usalo per riparare i repository Mercurial con
revlog mancanti, convertendo da e verso Mercurial. L'impostazione predefinita è False.
convert.hg.saverv
memorizza l'ID di revisione originale nel changeset (forza la modifica degli ID di destinazione). Ci vuole un
argomento booleano e il valore predefinito è False.
convert.hg.startrev
specificare la revisione Mercurial iniziale. Il valore predefinito è 0.
convert.hg.giri
revset che specifica le revisioni di origine da convertire.
CVS Fonte
La sorgente CVS utilizzerà una sandbox (cioè una copia ritirata) da CVS per indicare l'inizio
punto di ciò che verrà convertito. Non è necessario l'accesso diretto ai file del repository,
a meno che ovviamente il repository non lo sia :Locale:. La conversione utilizza la directory di livello superiore in
nella sandbox per trovare il repository CVS, quindi utilizza i comandi CVS rlog per trovare i file
convertire. Ciò significa che, a meno che non venga fornita una mappa di file, tutti i file nella directory iniziale
verrà convertito e che qualsiasi riorganizzazione della directory nella sandbox CVS venga ignorata.
Le seguenti opzioni possono essere utilizzate con --config:
convert.cvsp.cache
Impostare su False per disabilitare la memorizzazione nella cache dei registri remota, a scopo di test e debug.
L'impostazione predefinita è Vero.
convert.cvsp.fuzz
Specificare il tempo massimo (in secondi) consentito tra i commit con
utente identico e messaggio di registro in un unico changeset. Quando erano file molto grandi
archiviato come parte di un set di modifiche, l'impostazione predefinita potrebbe non essere abbastanza lunga. Il
il valore predefinito è 60.
convert.cvsps.mergeto
Specificare un'espressione regolare a cui corrispondono i messaggi di log di commit. Se una partita
si verifica, quindi il processo di conversione inserirà una revisione fittizia unendo il ramo
su cui questo messaggio di registro si presenta al ramo indicato nella regex. L'impostazione predefinita è
{{mergetobranch ([-\w]+)}}
convert.cvsps.mergefrom
Specificare un'espressione regolare a cui corrispondono i messaggi di log di commit. Se una partita
si verifica, il processo di conversione aggiungerà la revisione più recente sul ramo
indicato nella regex come il secondo genitore del changeset. L'impostazione predefinita è
{{mergefrombranch ([-\w]+)}}
convert.localtimezone
utilizzare l'ora locale (come determinato dalla variabile di ambiente TZ) per il set di modifiche
data/ora. L'impostazione predefinita è False (usa UTC).
hooks.cvslog
Specificare una funzione Python da chiamare al termine della raccolta del registro CVS. Il
alla funzione viene passato un elenco con le voci di registro e può modificare le voci
sul posto o aggiungerli o eliminarli.
hooks.cvschangesets
Specificare una funzione Python da chiamare dopo che i set di modifiche sono stati calcolati da
Registro CVS. Alla funzione viene passato un elenco con le voci del changeset e può essere modificato
le serie di modifiche sul posto o aggiungerle o eliminarle.
Un ulteriore comando Mercurial "debugcvsps" consente al codice di fusione del set di modifiche integrato
essere eseguito senza eseguire una conversione. I suoi parametri e l'output sono simili a quelli di cvsp
2.1. Si prega di consultare la guida ai comandi per maggiori dettagli.
Sovversione Fonte
La fonte di Subversion rileva i layout classici di trunk/rami/tag. Per impostazione predefinita, il fornito
svn://repo/percorso/ l'URL di origine viene convertito come un unico ramo. Se svn://repo/percorso/trunk
esiste sostituisce il ramo predefinito. Se svn://repo/percorso/rami esiste, il suo
le sottodirectory sono elencate come possibili rami. Se svn://repo/percorso/tag esiste, è
cercato tag che fanno riferimento a rami convertiti. Predefinito tronco, rami ed tag valori
può essere sovrascritto con le seguenti opzioni. Impostali su percorsi relativi all'URL di origine o
lasciali vuoti per disabilitare il rilevamento automatico.
È possibile impostare le seguenti opzioni con --config:
convert.svn.branch
specificare la directory contenente i rami. L'impostazione predefinita è rami.
convertire.svn.tags
specificare la directory contenente i tag. L'impostazione predefinita è tag.
convert.svn.trunk
specificare il nome del ramo del tronco. L'impostazione predefinita è tronco.
convert.localtimezone
utilizzare l'ora locale (come determinato dalla variabile di ambiente TZ) per il set di modifiche
data/ora. L'impostazione predefinita è False (usa UTC).
La cronologia di origine può essere recuperata a partire da una revisione specifica, invece di essere
convertito integralmente. Sono supportate solo le conversioni di ramo singolo.
convert.svn.startrev
specifica il numero di revisione di inizio Subversion. Il valore predefinito è 0.
Idiota Fonte
L'importatore Git converte i commit da tutti i rami raggiungibili (refs in refs/heads) e
telecomandi (riferimenti in riferimenti/telecomandi) a Mercurial. I rami vengono convertiti in segnalibri con l'estensione
stesso nome, con i primi "refs/heads" spogliati. I sottomoduli Git vengono convertiti in Git
subrepo in Mercurial.
È possibile impostare le seguenti opzioni con --config:
convert.git.similarità
specificare come devono essere importati file simili modificati in un commit come rinomina o
copie, come percentuale tra 0 (disabilitato) e 100 (i file devono essere identici). Per
esempio, 90 significa che una coppia elimina/aggiungi verrà importata come rinomina se più di
Il 90% del file non è cambiato. L'impostazione predefinita è 50.
convert.git.findcopysharder
durante il rilevamento delle copie, guarda tutti i file nella copia di lavoro anziché solo
quelli cambiati. Questo è molto costoso per progetti di grandi dimensioni ed è efficace solo quando
convert.git.similarità è maggiore di 0. L'impostazione predefinita è False.
convert.git.remoteprefix
i riferimenti remoti vengono convertiti come segnalibri con convert.git.remoteprefix come prefisso
seguita da una /. L'impostazione predefinita è "remoto".
convert.git.skipsubmodules
non converte file .gitmodules di livello radice o file con indicazione della modalità 160000
un sottomodulo. L'impostazione predefinita è False.
necessariamente Fonte
All'importatore Perforce (P4) può essere assegnato un percorso di deposito p4 o una specifica client come
fonte. Convertirà tutti i file nel sorgente in un repository Mercurial piatto, ignorando
etichette, rami e integrazioni. Nota che quando ti viene fornito un percorso di deposito, di solito
dovrebbe specificare una directory di destinazione, perché altrimenti la destinazione potrebbe essere denominata ...-hg.
È possibile impostare le seguenti opzioni con --config:
convert.p4.codifica
specificare la codifica da utilizzare durante la decodifica dell'output standard del comando Perforce
strumento di linea. L'impostazione predefinita è la codifica di sistema predefinita.
convert.p4.startrev
specificare la revisione iniziale di Perforce (un numero dell'elenco di modifiche di Perforce).
mutevole Nei Dintorni
La destinazione Mercurial riconoscerà i sottorepository Mercurial nella destinazione
directory e aggiorna automaticamente il file .hgsubstate se la destinazione
i sottorepository contengono il / /.hg/file shamap. Conversione di un repository con
sottorepository richiede la conversione di un singolo repository alla volta, dal basso verso l'alto.
Un esempio che mostra come convertire un repository con sottorepository:
# quindi convert conosce il tipo quando vede una destinazione non vuota
$ hg init convertito
$ hg converti orig/sub1 convertito/sub1
$ hg converti orig/sub2 convertito/sub2
$ hg converti orig convertito
Sono supportate le seguenti opzioni:
convert.hg.clonebranches
inviare rami di origine in cloni separati. L'impostazione predefinita è Falso.
convert.hg.tagsbranch
nome del ramo per le revisioni dei tag, il valore predefinito è difetto.
convert.hg.usebranchnames
conservare i nomi dei rami. L'impostazione predefinita è Vero.
convert.hg.nomeorigine
registra la stringa data come valore extra 'convert_source' su ogni commit effettuato
il repository di destinazione. L'impostazione predefinita è Nessuno.
Tutti Destinazioni
Tutti i tipi di destinazione accettano le seguenti opzioni:
converti.skiptags
non converte i tag dal repository di origine al repository di destinazione. L'impostazione predefinita è
Falso.
Opzioni:
--autori
nome file mappatura nome utente (DEPRECATED) (usa invece --authormap)
-S,--tipo-sorgente
tipo di repository di origine
-D,--tipo-dest
tipo di repository di destinazione
-R,--rev
importare fino alla revisione sorgente REV
-UN,--authormap
rimappare i nomi utente utilizzando questo file
--filemap
rimappare i nomi dei file usando il contenuto del file
--completo applica le modifiche alla mappa dei file convertendo nuovamente tutti i file
--splicemap
splice sintetizzato la storia al suo posto
--branchmap
cambia i nomi dei rami durante la conversione
--branchsort
prova a ordinare i changeset per branch
--datasort
prova a ordinare i set di modifiche per data
--sourcesort
conserva l'ordine dei set di modifiche di origine
--closesort
prova a riordinare le revisioni chiuse
[+] l'opzione contrassegnata può essere specificata più volte
eol
gestire automaticamente le nuove righe nei file del repository
Questa estensione consente di gestire il tipo di terminazioni di riga (CRLF o LF) utilizzate in
nel repository e nella directory di lavoro locale. In questo modo puoi ottenere le terminazioni di riga CRLF
su Windows e LF su Unix/Mac, consentendo così a tutti di utilizzare le terminazioni di riga native del sistema operativo.
L'estensione legge la sua configurazione da un versionato .hgeol file di configurazione trovato in
la radice della directory di lavoro. Il .hgeol il file usa la stessa sintassi di tutti gli altri
File di configurazione Mercurial. Utilizza due sezioni, [modelli] ed [deposito].
I [modelli] la sezione specifica come le terminazioni di riga devono essere convertite tra le lavorazioni
directory e il repository. Il formato è specificato da un modello di file. La prima partita
viene utilizzato, quindi metti prima i modelli più specifici. Le terminazioni di riga disponibili sono LF, CRLFe
BIN.
File con il formato dichiarato di CRLF or LF vengono sempre estratti e archiviati nel
repository in quel formato e file dichiarati binari (BIN) rimangono invariati.
Inoltre, nativo è un alias per il check-out nella riga predefinita della piattaforma che termina:
LF su Unix (incluso Mac OS X) e CRLF Su Windows. Notare che BIN (non fare nulla per allineare
finali) è il comportamento predefinito di Mercurial; è necessario solo se è necessario sovrascrivere a
in seguito, modello più generale.
Facoltativo [deposito] la sezione specifica le terminazioni di riga da utilizzare per i file archiviati
il deposito. Ha un'unica impostazione, nativo, che determina le terminazioni della riga di archiviazione
per i file dichiarati come nativo nel [modelli] sezione. Può essere impostato su LF or CRLF.
l'impostazione predefinita è LF. Ad esempio, ciò significa che su Windows i file configurati come nativo (CRLF
per impostazione predefinita) verrà convertito in LF quando archiviato nel repository. File dichiarati come LF,
CRLF, o BIN nel [modelli] le sezioni sono sempre archiviate così come sono nel repository.
Esempio con versione .hgeol file:
[modelli]
**.py = nativo
**.vcproj = CRLF
**.txt = nativo
Makefile = LF
**.jpg = CESTINO
[deposito]
nativo = LF
Nota Le regole si applicano per la prima volta quando i file vengono toccati nella directory di lavoro, ad esempio da
l'aggiornamento a null e torna alla mancia per toccare tutti i file.
L'estensione utilizza un optional [eolo] sezione letta sia dal normale Mercurial
file di configurazione e il .hgeol file, con quest'ultimo che prevale sul primo. Puoi
usa quella sezione per controllare il comportamento generale. Ci sono tre impostazioni:
· eol.nativo (predefinito os.linesep) può essere impostato su LF or CRLF per sovrascrivere l'impostazione predefinita
interpretazione di nativo per il check-out. Questo può essere utilizzato con hg archiviare su Unix, diciamo, a
generare un archivio in cui i file hanno terminazioni di riga per Windows.
· eol.solo-coerente (valore predefinito True) può essere impostato su False per convertire l'estensione
file con EOL incoerenti. Incoerente significa che ci sono entrambi CRLF ed LF presenti
nel file. Tali file normalmente non vengono toccati partendo dal presupposto che lo siano
EOL misti di proposito.
· eol.fix-trailing-newline (predefinito False) può essere impostato su True per garantire che sia convertito
i file terminano con un carattere EOL (o \n or \ R \ n secondo i modelli configurati).
L'estensione fornisce codice intelligente: ed decodifica intelligente: filtri come il deprecato
l'estensione win32text lo fa. Ciò significa che puoi disabilitare win32text e abilitare eol e
i tuoi filtri continueranno a funzionare. Hai solo bisogno di questi filtri fino a quando non hai preparato a
.hgeol file.
I win32text.forbid* gli hook forniti dall'estensione win32text sono stati unificati in a
gancio singolo denominato eol.checkheadshook. L'hook cercherà le terminazioni di riga previste da
, il .hgeol file, il che significa che devi migrare a .hgeol prima di utilizzare il file
gancio. eol.checkheadshook solo i test di verifica, verranno inviate le revisioni intermedie non valide.
Per vietarli completamente, usa il eol.checkallhook gancio. Questi ganci sono meglio usati come
gruppo pretxnchange ganci.
See hg Aiuto modelli per ulteriori informazioni sui modelli glob utilizzati.
extdiff
comando per consentire ai programmi esterni di confrontare le revisioni
L'estensione Mercurial extdiff ti consente di utilizzare programmi esterni per confrontare revisioni,
o revisione con directory di lavoro. I programmi diff esterni sono chiamati con a
insieme configurabile di opzioni e due argomenti non opzionali: percorsi alle directory contenenti
istantanee di file da confrontare.
L'estensione extdiff consente anche di configurare nuovi comandi diff, quindi non è necessario
digitare hg extdiff -p kdiff3 sempre.
[diff. est.]
# aggiungi un nuovo comando che esegue GNU diff(1) in modalità 'differenza contestuale'
cdiff = gdiff -Nprc5
## o alla vecchia maniera:
#cmd.cdiff = gdiff
#opts.cdiff = -Nprc5
# aggiungi un nuovo comando chiamato meld, esegue meld (non c'è bisogno di nominare due volte). Se
# l'eseguibile di fusione non è disponibile, lo strumento di fusione in [merge-tools]
# verrà utilizzato, se disponibile
fusione =
# aggiungi un nuovo comando chiamato vimdiff, esegue gvimdiff con il plugin DirDiff
# (vedere http://www.vim.org/scripts/script.php?script_id=102) No
# Utente inglese, assicurati di inserire "let g:DirDiffDynamicDiffText = 1".
# il tuo .vimrc
vimdiff = gvim -f "+successivo" \
"+esegui 'DirDiff' fnameescape(arv(0)) fnomeescape(arv(1))"
Gli argomenti dello strumento possono includere variabili che vengono espanse in fase di esecuzione:
$parent1, $plabel1 - nome file, etichetta descrittiva del primo genitore
$child, $clabel - nome file, etichetta descrittiva della revisione figlio
$parent2, $plabel2 - nome file, etichetta descrittiva del secondo genitore
$ root - radice del repository
$parent è un alias per $parent1.
L'estensione extdiff cercherà nelle sezioni [diff-tools] e [merge-tools] diff
argomenti dello strumento, quando nessuno è specificato in [extdiff].
[diff. est.]
kdiff3 =
[strumenti differenziali]
kdiff3.diffargs=--L1 '$label1' --L2 '$label' $parent $figlio
Puoi usare -I/-X e un elenco di nomi di file o directory come di consueto hg diff comando. Il
extdiff crea istantanee dei soli file necessari, quindi eseguendo il diff esterno
il programma sarà effettivamente piuttosto veloce (almeno più veloce del dover confrontare l'intero
albero).
Comandi
extdiff
usa un programma esterno per differenziare il repository (o i file selezionati):
hg extdiff [OPT]... [FILE]...
Mostra le differenze tra le revisioni per i file specificati, utilizzando un programma esterno. Il
il programma predefinito utilizzato è diff, con le opzioni predefinite "-Npru".
Per selezionare un programma diverso, utilizzare l'opzione -p/--programma. Il programma sarà superato il
nomi di due directory da confrontare. Per passare opzioni aggiuntive al programma, utilizzare
-o/--opzione. Questi verranno passati prima dei nomi delle directory da confrontare.
Quando vengono forniti due argomenti di revisione, vengono mostrate le modifiche tra quelle revisioni. Se
viene specificata solo una revisione, quindi quella revisione viene confrontata con la directory di lavoro,
e, quando non vengono specificate revisioni, i file della directory di lavoro vengono confrontati con i suoi
genitore.
Opzioni:
-P,--programma
programma di confronto da eseguire
-oh,--opzione
passare l'opzione al programma di confronto
-R,--rev
revisione
-C,--modificare
modifica apportata dalla revisione
--toppa
confrontare le patch per due revisioni
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
factotum
Autenticazione http con factotum
Questa estensione consente il factotum(4) struttura sul piano 9 dalle piattaforme Bell Labs a
fornire informazioni di autenticazione per l'accesso HTTP. Voci di configurazione specificate in
auth e le informazioni di autenticazione fornite nell'URL del repository sono
pienamente supportato. Se non viene specificato alcun prefisso, verrà assunto un valore di "*".
Per impostazione predefinita, le chiavi sono specificate come:
proto=servizio passato=prefisso hg= utente= !password=
Se l'estensione factotum non è in grado di leggere la chiave richiesta, ne verrà richiesta una
in modo interattivo.
È disponibile una sezione di configurazione per personalizzare il comportamento di runtime. Per impostazione predefinita, questi
le voci sono:
[factotum]
eseguibile = /bin/auth/factotum
punto di montaggio = /mnt/factotum
servizio = hg
La voce eseguibile definisce il percorso completo del binario factotum. La voce del punto di montaggio
definisce il percorso del servizio file factotum. Infine, la voce di servizio controlla il
nome del servizio utilizzato durante la lettura delle chiavi.
andare a prendere
estrai, aggiorna e unisci in un unico comando (DEPRECATO)
Comandi
andare a prendere
estrarre le modifiche da un repository remoto, unire le nuove modifiche se necessario.:
hg fetch [FONTE]
Questo trova tutte le modifiche dal repository nel percorso o nell'URL specificato e le aggiunge a
il deposito locale.
Se le modifiche estratte aggiungono una nuova testa di ramo, la testa viene automaticamente unita e il file
risultato dell'unione viene commesso. In caso contrario, la directory di lavoro viene aggiornata per includere
le nuove modifiche.
Quando è necessaria un'unione, la directory di lavoro viene prima aggiornata al nuovo estratto
i cambiamenti. Le modifiche locali vengono quindi unite nelle modifiche estratte. Per cambiare l'ordine di unione,
usa --switch-parent.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
una revisione specifica che vorresti estrarre
-e, --modificare
invoca l'editor sui messaggi di commit
--force-editor
modifica messaggio di commit (DEPRECATO)
--cambia-genitore
cambiare genitore durante la fusione
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
gpg
comandi per firmare e verificare i changeset
Comandi
sigcheck
verificare tutte le firme eventualmente presenti per una particolare revisione:
hg sigcheck REV
verificare tutte le firme eventualmente presenti per una particolare revisione
segno
aggiungi una firma per la revisione corrente o data:
segno hg [OPZIONE]... [REV]...
Se non viene fornita alcuna revisione, viene utilizzato il genitore della directory di lavoro o il suggerimento se no
la revisione è verificata.
I gpg.cmd config può essere utilizzata per specificare il comando da eseguire. Può essere una chiave predefinita
specificato con chiave.gpg.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Opzioni:
-l, --Locale
fare la firma locale
-F, --vigore
sign anche se il sigfile è stato modificato
--senza impegno
non eseguire il commit del sigfile dopo la firma
-K,--chiave
l'ID chiave con cui firmare
-M,--Messaggio
usa il testo come messaggio di commit
-e, --modificare
invoca l'editor sui messaggi di commit
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
sig
elenca gli insiemi di modifiche firmati:
hg sig
elenca gli insiemi di modifiche firmati
grafogramma
comando per visualizzare i grafici di revisione da una shell (DEPRECATO)
La funzionalità di questa estensione è stata inclusa nel core Mercurial dalla versione 2.3.
Si prega di utilizzare hg ceppo -G ... anziché.
Questa estensione aggiunge un'opzione --graph ai comandi in entrata, in uscita e di registro. Quando questo
opzioni, viene mostrata anche una rappresentazione ASCII del grafico di revisione.
Comandi
biancospino
mostra la cronologia delle revisioni insieme a un grafico di revisione ASCII:
hg glog [OPZIONE]... [FILE]
Stampa una cronologia delle revisioni insieme a un grafico delle revisioni disegnato con caratteri ASCII.
I nodi stampati come un carattere @ sono genitori della directory di lavoro.
Questo è un alias per hg ceppo -G.
Opzioni:
-F, --Seguire
seguire la cronologia delle modifiche o la cronologia dei file tra copie e rinominazioni
--segui-prima
segui solo il primo genitore dei changeset di unione (DEPRECATO)
-D,--Data
mostra le revisioni corrispondenti alle specifiche della data
-C, --copie
mostra i file copiati
-K,--parola chiave
eseguire una ricerca senza distinzione tra maiuscole e minuscole per un determinato testo
-R,--rev
mostra la revisione o il revset specificato
--RIMOSSO
includere le revisioni in cui i file sono stati rimossi
-M, --solo-unisce
mostra solo unioni (DEPRECATO)
-tu,--utente
revisioni commesse dall'utente
--solo-ramo
mostra solo i changeset all'interno del ramo nominato specificato (DEPRECATO)
-B,--ramo
mostra i changeset all'interno del ramo nominato dato
-P,--fesso
non visualizzare la revisione o nessuno dei suoi antenati
-P, --toppa
mostra la patch
-G, --idiota
usa il formato diff esteso git
-l,--limite
limitare il numero di modifiche visualizzate
-M, --no-fusioni
non mostrare le unioni
--statistica output di riepilogo delle modifiche in stile diffstat
-G, --grafico
mostra la revisione DAG
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
hcia
ganci per l'integrazione con il servizio di notifica CIA.vc
Questo è pensato per essere eseguito come gruppo di modifiche o hook in entrata. Per configurarlo, impostare il
seguenti opzioni nel tuo hgrc:
[cia]
# il tuo nome utente CIA registrato
utente = pippo
# il nome del progetto in CIA
progetto = pippo
# il modulo (sottoprogetto) (opzionale)
#modulo = pippo
# Aggiungi un diffstat al messaggio di registro (opzionale)
#diffstat = Falso
# Modello da utilizzare per i messaggi di registro (opzionale)
#template = {desc}\n{baseurl}{webroot}/rev/{nodo}-- {diffstat}
# Stile da utilizzare (opzionale)
#stile = pippo
# L'URL del servizio di notifica CIA (opzionale)
# È possibile utilizzare mailto: URL da inviare tramite e-mail, ad es
# mailto:[email protected]
# Assicurati di impostare email.from se lo fai.
#URL = http://cia.vc/
# stampa il messaggio invece di inviarlo (opzionale)
#test = Falso
# numero di barre da rimuovere per i percorsi URL
#striscia = 0
[ganci]
# uno di questi:
changegroup.cia = python:hgcia.hook
#incoming.cia = python:hgcia.hook
[ragnatela]
# Se desideri collegamenti ipertestuali (opzionale)
URL di base = http://server/path/to/repo
HGK
sfoglia il repository in modo grafico
L'estensione hgk consente di sfogliare la cronologia di un repository in modo grafico. Esso
richiede Tcl/Tk versione 8.4 o successiva. (Tcl/Tk non è distribuito con Mercurial.)
hgk è composto da due parti: uno script Tcl che esegue la visualizzazione e l'interrogazione di
informazioni e un'estensione di Mercurial denominata hgk.py, che fornisce hook a cui hgk
ottenere informazioni. hgk può essere trovato nella directory contrib e l'estensione viene fornita
nel repository hgext e deve essere abilitato.
I hg vista il comando avvierà lo script hgk Tcl. Affinché questo comando funzioni, hgk deve essere
nel tuo percorso di ricerca. In alternativa, puoi specificare il percorso di hgk nella tua configurazione
file:
[cazzo]
percorso = /posizione/di/hgk
hgk può utilizzare l'estensione extdiff per visualizzare le revisioni. Supponendo che tu l'abbia fatto
comando extdiff vdiff già configurato, basta aggiungere:
[cazzo]
vdiff=vdiff
Il menu di scelta rapida delle revisioni ora mostrerà voci aggiuntive per attivare vdiff al passaggio del mouse e
revisioni selezionate.
Comandi
vista
avviare il visualizzatore di cronologia interattivo:
hg view [-l LIMITE] [REVRANGE]
avviare il visualizzatore di cronologia interattivo
Opzioni:
-l,--limite
limitare il numero di modifiche visualizzate
evidenziare
evidenziazione della sintassi per hgweb (richiede Pygments)
Dipende dalla libreria di evidenziazione della sintassi di Pygments: http://pygments.org/
Sono disponibili le seguenti opzioni di configurazione:
[ragnatela]
stile_pigmenti = (default: colorful)
file di evidenziazione = (predefinito: dimensione('<5M'))
highlightonlymatchnomefile = (predefinito Falso)
highlightonlymatchnomefile evidenzierà i file solo se il loro tipo può essere identificato da
il loro nome file. Quando questo non è abilitato (impostazione predefinita), Pigments si sforzerà di farlo
identificare il tipo di file dal contenuto e qualsiasi corrispondenza (anche corrispondenze con un livello di confidenza basso
punteggio) verrà utilizzato.
storico
modifica della cronologia interattiva
Con questa estensione installata, Mercurial ottiene un nuovo comando: histedit. L'uso è come
segue, assumendo la seguente storia:
@ 3[suggerimento] 7c2fd3b9020c 2009-04-27 18:04 -0500 durin42
| Aggiungi delta
|
o 2 030b686bedc4 2009-04-27 18:04 -0500 Durin42
| Aggiungi gamma
|
o 1 c561b4e977df 2009-04-27 18:04 -0500 durin42
| Aggiungi beta
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 durin42
Aggiungi alfa
Se dovessi correre hg storico c561b4e977df, vedresti il seguente file aperto nel tuo
editore:
scegli c561b4e977df Aggiungi beta
scegli 030b686bedc4 Aggiungi gamma
scegli 7c2fd3b9020c Aggiungi delta
# Modifica cronologia tra c561b4e977df e 7c2fd3b9020c
#
# I commit sono elencati dal meno al più recente
#
# Comandi:
# p, scegli = usa il commit
# e, edit = usa commit, ma fermati per modificare
# f, fold = usa commit, ma combinalo con quello sopra
# r, roll = like fold, ma scarta la descrizione di questo commit
# d, drop = rimuove il commit dalla cronologia
# m, mess = modifica il messaggio di commit senza modificare il contenuto del commit
#
In questo file, le righe che iniziano con # vengono ignorati. È necessario specificare una regola per ciascuno
revisione nella tua storia. Ad esempio, se intendevi aggiungere gamma prima della beta e poi
se volessi aggiungere delta nella stessa revisione della versione beta, riorganizzeresti il file in modo che appaia
come questo:
scegli 030b686bedc4 Aggiungi gamma
scegli c561b4e977df Aggiungi beta
piega 7c2fd3b9020c Aggiungi delta
# Modifica cronologia tra c561b4e977df e 7c2fd3b9020c
#
# I commit sono elencati dal meno al più recente
#
# Comandi:
# p, scegli = usa il commit
# e, edit = usa commit, ma fermati per modificare
# f, fold = usa commit, ma combinalo con quello sopra
# r, roll = like fold, ma scarta la descrizione di questo commit
# d, drop = rimuove il commit dalla cronologia
# m, mess = modifica il messaggio di commit senza modificare il contenuto del commit
#
A quel punto chiudi l'editor e storico inizia a funzionare. Quando si specifica a piega
funzionamento, storico aprirà un editor quando piega insieme quelle revisioni, offrendo
hai la possibilità di ripulire il messaggio di commit:
Aggiungi beta
***
Aggiungi delta
Modifica il messaggio di commit a tuo piacimento, quindi chiudi l'editor. Per questo esempio, proviamo
presupporre che il messaggio di commit sia stato modificato in Aggiungi beta ed delta. Dopo che histedit è stato eseguito
e ha avuto la possibilità di rimuovere eventuali revisioni vecchie o temporanee di cui aveva bisogno, la cronologia sembra
come questo:
@ 2[suggerimento] 989b4d060121 2009-04-27 18:04 -0500 durin42
| Aggiungi beta e delta.
|
o 1 081603921c3f 2009-04-27 18:04 -0500 durin42
| Aggiungi gamma
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 durin42
Aggiungi alfa
Si noti che storico effettua non rimuovere eventuali revisioni (anche quelle temporanee) fino a dopo
ha completato tutte le operazioni di editing, quindi probabilmente eseguirà diverse strip
operazioni quando è fatto. Per l'esempio sopra, ha dovuto eseguire strip due volte. La striscia può essere
lento a seconda di una varietà di fattori, quindi potrebbe essere necessario essere un po' pazienti. Puoi
scegli di mantenere le revisioni originali passando il --mantenere bandiera.
I edit operazione ti riporterà a un prompt dei comandi, consentendoti di modificare i file
liberamente, o addirittura utilizzare hg record per eseguire il commit di alcune modifiche come commit separato. Quando tu sei
fatto, anche eventuali modifiche rimanenti non vincolate verranno salvate. Quando hai finito, corri hg
storico --Continua per completare questo passaggio. Ti verrà richiesto un nuovo messaggio di commit, ma
il messaggio di commit predefinito sarà il messaggio originale per il edit revisione ed.
I messaggio operazione ti darà la possibilità di rivedere un messaggio di commit senza cambiarlo
i contenuti. È una scorciatoia per fare edit immediatamente seguito da hg storico
--continua`.
If storico incontra un conflitto quando si sposta una revisione (durante la gestione scegliere or piega),
si fermerà in modo simile a edit con la differenza che non ti chiederà a
messaggio di commit una volta terminato. Se decidi a questo punto che non ti piace quanto lavoro
sarà per riorganizzare la cronologia, o che hai commesso un errore, puoi usare hg storico --abortire
abbandonare le nuove modifiche apportate e tornare allo stato prima del tentativo
modifica la tua cronologia.
Se cloniamo il repository di esempio con istedit sopra e aggiungiamo altre quattro modifiche, in tal modo
abbiamo la seguente storia:
@ 6[suggerimento] 038383181893 2009-04-27 18:04 -0500 stefan
| Aggiungi theta
|
o 5 140988835471 2009-04-27 18:04 -0500 stefan
| Aggiungi eta
|
o 4 122930637314 2009-04-27 18:04 -0500 stefan
| Aggiungi zeta
|
o 3 836302820282 2009-04-27 18:04 -0500 stefan
| Aggiungi epsilon
|
o 2 989b4d060121 2009-04-27 18:04 -0500 durante42
| Aggiungi beta e delta.
|
o 1 081603921c3f 2009-04-27 18:04 -0500 durin42
| Aggiungi gamma
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 durin42
Aggiungi alfa
Se corri hg storico --estroverso sul clone allora è lo stesso che in esecuzione hg storico
836302820282. Se hai bisogno di pianificare il push a un repository che Mercurial non rileva
essere correlato al repository di origine, puoi aggiungere a --vigore opzione.
Config
Per impostazione predefinita, le righe della regola Histedit vengono troncate a 80 caratteri. Puoi personalizzarlo
comportamento impostando una lunghezza diversa nel file di configurazione:
[istedit]
linelen = 120 # tronca le righe della regola a 120 caratteri
hg storico tenta di scegliere automaticamente una revisione di base appropriata da utilizzare. a
cambia quale revisione di base viene utilizzata, definisci un revset nel tuo file di configurazione:
[istedit]
defaultrev = solo(.) & bozza()
Per impostazione predefinita, ogni revisione modificata deve essere presente nei comandi histedit. Rimuovere
revisione che devi usare cadere operazione. È possibile configurare il drop in modo che sia implicito
commit mancanti aggiungendo:
[istedit]
dropmissing = Vero
Comandi
storico
modifica interattivamente la cronologia del changeset:
hg histedit [OPZIONI] ([ANCESTOR] | --outgoing [URL])
Questo comando consente di modificare una serie lineare di changeset (fino alla lavorazione
directory, che dovrebbe essere pulita). Puoi:
· scegliere per [ri]ordinare un changeset
· cadere per omettere changeset
· pasticcio per riformulare il messaggio di commit del changeset
· piega per combinarlo con il changeset precedente
· rotolare come fold, ma scartando la descrizione di questo commit
· edit per modificare questo changeset
Esistono diversi modi per selezionare il changeset radice:
· Specificare direttamente ANCESTOR
· Usa --outgoing -- sarà il primo changeset lineare non incluso nella destinazione.
(Vedere hg Aiuto config.default-push)
· Altrimenti, il valore dell'opzione di configurazione "histedit.defaultrev" viene utilizzato come revset a
selezionare la revisione di base quando ANCESTOR non è specificato. La prima revisione restituita da
viene utilizzato il revset. Per impostazione predefinita, questo seleziona la cronologia modificabile che è univoca per il
ascendenza della directory di lavoro.
Se usi --outgoing, questo comando si interromperà se ci sono revisioni ambigue in uscita.
Ad esempio, se sono presenti più rami contenenti revisioni in uscita.
Usa "min(outgoing() and ::.)" o una specifica revset simile invece di --outgoing to
specificare la revisione della destinazione di modifica esattamente in tale situazione ambigua. Vedere hg Aiuto revisioni per
dettagli sulla selezione delle revisioni.
Consigli d'uso:
· Sono state apportate numerose modifiche. La revisione 3 non è più necessaria.
Inizia la modifica della cronologia dalla revisione 3:
hg histedit -r 3
Si apre un editor, contenente l'elenco delle revisioni, con specifiche azioni specificate:
scegli 5339bf82f0ca 3 Zworgle il foobar
pick 8ef592ce7cc4 4 Attacca lo zerlog
pick 0a9639fcda9d 5 Morgificare la cromulanza
Ulteriori informazioni sulle possibili azioni da intraprendere vengono visualizzate sotto l'elenco di
revisioni.
Per rimuovere la revisione 3 dalla cronologia, la sua azione (all'inizio del relativo
riga) è cambiato in 'rilascia':
drop 5339bf82f0ca 3 Zworgle il foobar
pick 8ef592ce7cc4 4 Attacca lo zerlog
pick 0a9639fcda9d 5 Morgificare la cromulanza
· Sono state apportate numerose modifiche. Le revisioni 2 e 4 devono essere sostituite.
Inizia la modifica della cronologia dalla revisione 2:
hg histedit -r 2
Si apre un editor, contenente l'elenco delle revisioni, con specifiche azioni specificate:
pick 252a1af424ad 2 Blorb un morgwazzle
scegli 5339bf82f0ca 3 Zworgle il foobar
pick 8ef592ce7cc4 4 Attacca lo zerlog
Per scambiare la revisione 2 e 4, le sue righe vengono scambiate nell'editor:
pick 8ef592ce7cc4 4 Attacca lo zerlog
scegli 5339bf82f0ca 3 Zworgle il foobar
pick 252a1af424ad 2 Blorb un morgwazzle
Restituisce 0 in caso di successo, 1 se è richiesto l'intervento dell'utente (non solo per "modifica" intenzionale
comando, ma anche per risolvere conflitti imprevisti).
Opzioni:
--comandi
leggere le modifiche della cronologia dal file specificato
-C, --Continua
continuare una modifica già in corso
--modifica-piano
modificare l'elenco delle azioni rimanenti
-K, --mantenere
non rimuovere i vecchi nodi al termine della modifica
--abortire
annullare una modifica in corso
-oh, --estroverso
changeset non trovati nella destinazione
-F, --vigore
forzare l'uscita anche per repository non correlati
-R,--rev
prima revisione da modificare
[+] l'opzione contrassegnata può essere specificata più volte
parola chiave
espandere le parole chiave nei file monitorati
Questa estensione espande $Keywords$ simili a RCS/CVS o auto-personalizzate nei file di testo tracciati
selezionato dalla tua configurazione.
Le parole chiave vengono espanse solo nei repository locali e non vengono archiviate nella cronologia delle modifiche. Il
Il meccanismo può essere considerato una comodità per l'utente corrente o per l'archivio
distribuzione.
Le parole chiave si espandono ai dati del set di modifiche relativi all'ultima modifica relativa a
directory di lavoro padre di ogni file.
La configurazione viene eseguita nelle sezioni [keyword], [keywordset] e [keywordmaps] di hgrc
File.
Esempio:
[parola chiave]
# espandi le parole chiave in ogni file python eccetto quelle corrispondenti a "x*"
**.py =
x* = ignora
[insieme di parole chiave]
# preferire le keywordmap predefinite simili a svn su cvs
svn = Vero
Nota Più sei specifico nei modelli dei nomi dei file, meno perdi velocità in modo enorme
repository.
Per [keywordmaps] la mappatura del modello e la dimostrazione dell'espansione e il controllo vengono eseguiti hg demo.
See hg Aiuto modelli per un elenco di modelli e filtri disponibili.
Sono forniti tre filtri di modelli di data aggiuntivi:
utcdate
"2006/09/18 15:13:13"
svnutcdate
"2006-09-18 15:13:13Z"
svnisodate
"2006-09-18 08:13:13 -700 (lun, 18 set 2006)"
I mapping dei modelli predefiniti (visualizza con hg demo -d) può essere sostituito con personalizzato
parole chiave e modelli. Di nuovo, corri hg demo per controllare i risultati della tua configurazione
modifiche.
Prima di modificare/disabilitare le parole chiave attive, è necessario eseguire hg strizzacervelli per evitare la conservazione
parole chiave estese nella cronologia delle modifiche.
Per forzare l'espansione dopo averla abilitata o una modifica alla configurazione, eseguire hg kwexpand.
Le espansioni che coprono più di una riga e le espansioni incrementali, come $Log$ di CVS, lo sono
non supportato. Una mappa del modello di parole chiave "Log = {desc}" si espande alla prima riga di
descrizione del gruppo di modifiche.
Comandi
demo
print [keywordmaps] configurazione e un esempio di espansione:
hg kwdemo [-d] [-f RCFILE] [TEMPLATEMAP]...
Mostra le mappe dei modelli di parole chiave correnti, personalizzate o predefinite e le relative espansioni.
Estendi la configurazione corrente specificando le mappe come argomenti e usando -f/--rcfile to
fonte di un file hgrc esterno.
Utilizzare -d/--default per disabilitare la configurazione corrente.
See hg Aiuto modelli per informazioni su modelli e filtri.
Opzioni:
-D, --predefinito
mostra le mappe dei modelli di parole chiave predefinite
-F,--rcfile
leggi le mappe da rcfile
kwexpand
espandi le parole chiave nella directory di lavoro:
hg kwexpand [OPZIONE]... [FILE]...
Esegui dopo aver (ri)attivato l'espansione delle parole chiave.
kwexpand si rifiuta di eseguire se determinati file contengono modifiche locali.
Opzioni:
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
kwfile
mostra i file configurati per l'espansione delle parole chiave:
hg kwfiles [OPZIONE]... [FILE]...
Elenca quali file nella directory di lavoro corrispondono alla configurazione [parola chiave].
modelli.
Utile per prevenire l'espansione involontaria delle parole chiave e per velocizzare l'esecuzione includendo
solo i file che sono effettivamente candidati per l'espansione.
See hg Aiuto parola chiave su come costruire modelli sia per l'inclusione che per l'esclusione di
File.
Con -A/--all e -v/--verbose i codici utilizzati per mostrare lo stato dei file sono:
K = candidato all'espansione delle parole chiave
k = candidato all'espansione delle parole chiave (non tracciato)
I = ignorato
i = ignorato (non tracciato)
Opzioni:
-UN, --tutti
mostra i flag di stato delle parole chiave di tutti i file
-io, --ignorare
mostra i file esclusi dall'espansione
-tu, --sconosciuto
mostra solo file sconosciuti (non tracciati).
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
strizzacervelli
ripristinare le parole chiave espanse nella directory di lavoro:
hg kwshrink [OPZIONE]... [FILE]...
Deve essere eseguito prima di modificare/disabilitare le parole chiave attive.
kwshrink si rifiuta di essere eseguito se determinati file contengono modifiche locali.
Opzioni:
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
file di grandi dimensioni
tenere traccia di file binari di grandi dimensioni
I file binari di grandi dimensioni tendono a non essere molto comprimibili, non molto diffabili e per niente
unificabile. Tali file non vengono gestiti in modo efficiente dal formato di archiviazione di Mercurial (revlog),
che si basa su delta binari compressi; memorizzare regolarmente file binari di grandi dimensioni
I file Mercurial sprecano larghezza di banda e spazio su disco e aumentano l'utilizzo della memoria di Mercurial.
L'estensione largefiles risolve questi problemi aggiungendo un client-server centralizzato
layer sopra Mercurial: i file large vivono in a centrale Tornare al suo account fuori in rete
da qualche parte, e prendi solo le revisioni di cui hai bisogno quando ne hai bisogno.
largefiles funziona mantenendo un "file permanente" in .hglf/ per ogni largefile. Il
gli standin sono piccoli (41 byte: un hash SHA-1 più newline) e sono tracciati da Mercurial.
Le revisioni di file di grandi dimensioni sono identificate dall'hash SHA-1 del loro contenuto, che è scritto
allo stallo. largefiles usa quell'ID revisione per ottenere/mettere revisioni di file large da/a
il negozio centrale. Ciò consente di risparmiare spazio su disco e larghezza di banda, poiché non è necessario
recuperare tutte le revisioni storiche di file di grandi dimensioni durante la clonazione o il pull.
Per avviare un nuovo repository o aggiungere nuovi file binari di grandi dimensioni, aggiungi --large al tuo hg aggiungere
comando. Per esempio:
$ dd if=/dev/urandom of=conteggio dati casuali=2000
$ hg aggiungi --large randomdata
$ hg commit -m 'aggiungi dati casuali come file di grandi dimensioni'
Quando si esegue il push di un changeset che aggiunge/modifica file di grandi dimensioni a un repository remoto, è
le revisioni di file large verranno caricate insieme ad esso. Nota che il Mercurial remoto deve
avere anche l'estensione largefiles abilitata affinché funzioni.
Quando si estrae un changeset che interessa largefiles da un repository remoto, largefiles
per impostazione predefinita, il changeset non verrà tirato giù. Tuttavia, quando si esegue l'aggiornamento a tale
revisione, tutti i file di grandi dimensioni necessari per quella revisione vengono scaricati e memorizzati nella cache (se hanno
mai stato scaricato prima). Un modo per estrarre file di grandi dimensioni durante l'estrazione è quindi utilizzare
--update, che aggiornerà la tua copia di lavoro all'ultima revisione ritirata (e quindi
scaricare eventuali nuovi file di grandi dimensioni).
Se vuoi estrarre file di grandi dimensioni di cui non hai ancora bisogno per l'aggiornamento, puoi usare pull with
, il --lfrev opzione o il hg lftirare comando.
Se sai che stai estraendo da una posizione non predefinita e desideri scaricare tutti i file
largefile che corrispondono contemporaneamente ai nuovi changeset, quindi puoi eseguire il pull con
--lfrev "tirato()".
Se vuoi solo assicurarti di avere i file di grandi dimensioni necessari per unire o rebase
con nuove teste che stai tirando, quindi puoi tirare con --lfrev "testa(tirato())" bandiera
per scaricare preventivamente tutti i file di grandi dimensioni che sono nuovi nelle teste che stai tirando.
Tieni presente che ora potrebbe essere necessario l'accesso alla rete per eseguire l'aggiornamento ai set di modifiche di cui disponi
non precedentemente aggiornato a. La natura dell'estensione largefiles significa che l'aggiornamento è
non è più garantito che sia un'operazione solo locale.
Se hai già file di grandi dimensioni monitorati da Mercurial senza l'estensione largefiles, tu
dovrà convertire il tuo repository per beneficiare di file di grandi dimensioni. Questo è fatto
con la hg lfconvert comando:
$ hg lfconvert --size 10 vecchio repository nuovo repository
Nei repository che contengono già file di grandi dimensioni, qualsiasi nuovo file superiore a 10 MB lo farà
essere aggiunto automaticamente come file di grandi dimensioni. Per modificare questa soglia, impostare filegrandi.dimensione minima in
il tuo file di configurazione Mercurial alla dimensione minima in megabyte da tracciare come file di grandi dimensioni, o
usa l'opzione --lfsize per il comando add (anche in megabyte):
[file grandi]
taglia minima = 2
$ hg aggiungi --lfsize 2
I file di grandi dimensioni.patterns L'opzione config consente di specificare un elenco di modelli di nomi di file
(Vedi hg Aiuto modelli) che dovrebbe essere sempre tracciato come file di grandi dimensioni:
[file grandi]
modelli =
* .jpg
re:.*\.(png|bmp)$
libreria.zip
contenuto/audio/*
I file che corrispondono a uno di questi modelli verranno aggiunti come file di grandi dimensioni indipendentemente dal loro
dimensione.
I filegrandi.dimensione minima ed file di grandi dimensioni.patterns le opzioni di configurazione verranno ignorate per qualsiasi
repository che non contengono già un file di grandi dimensioni. Per aggiungere il primo file di grandi dimensioni a
repository, devi farlo esplicitamente con il flag --large passato a hg aggiungere comando.
Comandi
lfconvert
convertire un repository normale in un repository largefiles:
hg lfconvert FONTE DEST [FILE ...]
Converti il repository SOURCE in un nuovo repository DEST, identico a SOURCE tranne quello
alcuni file verranno convertiti come file di grandi dimensioni: in particolare, qualsiasi file che corrisponde a qualsiasi
MODELLO or la cui dimensione è superiore alla soglia di dimensione minima viene convertito in un file di grandi dimensioni. Il
size utilizzata per determinare se tracciare o meno un file poiché un file di grandi dimensioni è la dimensione di
prima versione del file. La dimensione minima può essere specificata con --size o in
configurazione come filegrandi.dimensione.
Dopo aver eseguito questo comando, dovrai assicurarti che largefiles sia abilitato ovunque
intendi eseguire il push del nuovo repository.
Usa --to-normal per riconvertire file di grandi dimensioni in file normali; dopo questo, il DEST
repository può essere utilizzato senza file di grandi dimensioni.
Opzioni:
-S,--dimensione
dimensione minima (MB) per i file da convertire come file di grandi dimensioni
--to-normale
convertire da un repository largefiles a un repository normale
lftirare
pull largefiles per le revisioni specificate dall'origine specificata:
hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [FONTE]
Estrarre file di grandi dimensioni a cui si fa riferimento da set di modifiche locali ma mancanti localmente, tirando
da un repository remoto alla cache locale.
Se SOURCE viene omesso, verrà utilizzato il percorso "predefinito". Vedere hg Aiuto urls per maggiori
informazioni.
Qualche esempio:
· estrarre file di grandi dimensioni per tutte le teste di ramo:
hg lfpull -r "head() e non chiuso()"
· pull largefiles sul ramo predefinito:
hg lfpull -r "ramo(predefinito)"
Opzioni:
-R,--rev
pull file di grandi dimensioni per queste revisioni
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
mq
gestire una pila di patch
Questa estensione ti consente di lavorare con una pila di patch in un repository Mercurial. Gestisce
due pile di patch: tutte le patch note e le patch applicate (sottoinsieme di patch note).
Le patch note sono rappresentate come file di patch nella directory .hg/patches. Patch applicati
sono sia file di patch che set di modifiche.
Compiti comuni (usare hg Aiuto command per ulteriori dettagli):
crea una nuova patch qnew
importa la patch esistente qimport
stampa patch serie qseries
stampa patch applicate qapplied
aggiungi una patch nota allo stack applicato qpush
rimuovere la patch dallo stack applicato qpop
aggiorna il contenuto della patch applicata in alto qrefresh
Per impostazione predefinita, mq utilizzerà automaticamente le patch git quando richiesto per evitare di perdere la modalità file
modifiche, copie di record, file binari o creazioni o eliminazioni di file vuoti. Questo comportamento
può essere configurato con:
[mq]
git = auto/mantieni/sì/no
Se impostato su 'keep', mq obbedirà alla configurazione della sezione [diff] pur mantenendo esistente
git patch su qrefresh. Se impostato su 'yes' o 'no', mq sovrascriverà la sezione [diff].
e genera sempre git o patch regolari, eventualmente perdendo dati nel secondo caso.
Può essere desiderabile che i set di modifiche mq vengano mantenuti nella fase segreta (vedi hg Aiuto fasi),
che può essere abilitato con la seguente impostazione:
[mq]
segreto = Vero
Per impostazione predefinita, gestirai una coda di patch denominata "patch". Puoi crearne altri,
code di patch indipendenti con hg coda comando.
Se la directory di lavoro contiene file non vincolati, qpush, qpop e qgoto abortiscono
subito. Se si utilizza -f/--force, le modifiche vengono annullate. Collocamento:
[mq]
keepchanges = Vero
falli comportare come se --keep-changes fosse passato e le modifiche locali non in conflitto lo faranno
essere tollerato e preservato. Se le opzioni incompatibili come -f/--force o --exact lo sono
superato, questa impostazione viene ignorata.
Questa estensione era utilizzata per fornire un comando strip. Questo comando ora risiede nella striscia
estensione.
Comandi
qapplicato
stampa le patch già applicate:
hg qapplicato [-1] [-s] [PATCH]
Restituisce 0 in caso di successo.
Opzioni:
-1, --Ultimo
mostra solo la patch precedente applicata
-S, --riepilogo
stampa la prima riga dell'intestazione della patch
qclone
clonare il repository principale e di patch contemporaneamente:
hg qclone [OPZIONE]... FONTE [DESTINAZIONE]
Se l'origine è locale, la destinazione non avrà patch applicate. Se la sorgente è remota, questo
comando non può verificare se le patch sono applicate nel sorgente, quindi non può garantire che le patch
non vengono applicati in destinazione. Se cloni il repository remoto, assicurati prima che lo sia
nessuna patch applicata.
Il repository della patch di origine viene cercato in /.hg/patch per impostazione predefinita. Usa -p a
cambiare.
La directory della patch deve essere un repository Mercurial nidificato, come verrebbe creato da hg init
--mq.
Restituisce 0 in caso di successo.
Opzioni:
--tiro usa il protocollo pull per copiare i metadati
-U, --nessun aggiornamento
non aggiornare le nuove directory di lavoro
--non compresso
utilizzare il trasferimento non compresso (veloce su LAN)
-P,--cerotti
posizione del repository di patch di origine
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
qcommit
eseguire il commit delle modifiche nel repository della coda (DEPRECATO):
hg qcommit [OPZIONE]... [FILE]...
Questo comando è deprecato; utilizzo hg commettere --mq anziché.
Opzioni:
-UN, --Aggiungi Rimuovi
contrassegna i file nuovi/mancanti come aggiunti/rimossi prima di eseguire il commit
--chiudi-ramo
contrassegnare una testa di ramo come chiusa
--modifica
modificare il genitore della directory di lavoro
-S, --segreto
usa la fase segreta per impegnarti
-e, --modificare
invoca l'editor sui messaggi di commit
-io, --interattivo
usa la modalità interattiva
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
-S, --sottorepos
ricorrono in sottorepository
[+] l'opzione contrassegnata può essere specificata più volte
alias: qci
qelimina
rimuovere le patch dalla coda:
hg qdelete [-k] [PATCH]...
Le patch non devono essere applicate ed è richiesta almeno una patch. Patch esatta
devono essere forniti gli identificatori. Con -k/--keep, i file di patch vengono conservati nella patch
directory.
Per interrompere la gestione di una patch e spostarla nella cronologia permanente, utilizzare il hg qfinire comando.
Opzioni:
-K, --mantenere
mantieni il file di patch
-R,--rev
interrompere la gestione di una revisione (DEPRECATO)
[+] l'opzione contrassegnata può essere specificata più volte
alias: qremove qrm
qdiff
diff della patch corrente e successive modifiche:
hg qdiff [OPZIONE]... [FILE]...
Mostra una differenza che include la patch corrente e tutte le modifiche apportate
nella directory di lavoro dall'ultimo aggiornamento (mostrando così cosa farebbe la patch corrente
diventare dopo un qrefresh).
Usa il hg diff se vuoi solo vedere le modifiche apportate dall'ultimo qrefresh, oppure hg export
qtip se vuoi vedere le modifiche apportate dalla patch corrente senza includere le modifiche apportate
dal qrefresh.
Restituisce 0 in caso di successo.
Opzioni:
-un, --testo
tratta tutti i file come testo
-G, --idiota
usa il formato diff esteso git
--nodate
ometti le date dalle intestazioni diff
--noprefisso
ometti i prefissi a/ e b/ dai nomi dei file
-P, --show-funzione
mostra in quale funzione si trova ogni modifica
--inversione
produrre un diff che annulla le modifiche
-w, --ignora-tutto-spazio
ignora gli spazi bianchi quando confronti le righe
-B, --ignora-spazio-cambiamento
ignora i cambiamenti nella quantità di spazio bianco
-B, --ignora-linee-vuote
ignora le modifiche le cui righe sono tutte vuote
-U,--unificato
numero di righe di contesto da mostrare
--statistica output di riepilogo delle modifiche in stile diffstat
--radice
produrre differenze relative alla sottodirectory
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
qfinire
sposta le patch applicate nella cronologia del repository:
hg qfine [-a] [REV]...
Termina le revisioni specificate (corrispondenti alle patch applicate) spostandole fuori
mq control nella normale cronologia del repository.
Accetta un intervallo di revisioni o l'opzione -a/--applicata. Se --applied è specificato, all
le revisioni di mq applicate vengono rimosse dal controllo di mq. In caso contrario, le revisioni fornite devono essere
alla base della pila di cerotti applicati.
Questo può essere particolarmente utile se le tue modifiche sono state applicate a un repository upstream,
o se stai per trasferire le modifiche a monte.
Restituisce 0 in caso di successo.
Opzioni:
-un, --applicato
terminare tutti i changeset applicati
qfold
piega le patch con nome nella patch corrente:
hg qfold [-e] [-k] [-m TESTO] [-l FILE] PATCH...
Le patch non devono ancora essere applicate. Ciascuna patch verrà applicata successivamente alla corrente
patch nell'ordine indicato. Se tutte le patch si applicano correttamente, lo sarà la patch corrente
aggiornato con la nuova patch cumulativa e le patch piegate verranno eliminate. Insieme a
-k/--keep, i file di patch piegati non verranno rimossi in seguito.
L'intestazione di ogni patch piegato verrà concatenata con l'intestazione della patch corrente,
separati da una linea di * * *.
Restituisce 0 in caso di successo.
Opzioni:
-e, --modificare
invoca l'editor sui messaggi di commit
-K, --mantenere
mantieni i file di patch piegati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
qgoto
push o pop patch finché la patch denominata non è in cima allo stack:
hg qgoto [OPZIONE]... PATCH
Restituisce 0 in caso di successo.
Opzioni:
--keep-modifiche
tollerare cambiamenti locali non in conflitto
-F, --vigore
sovrascrivere eventuali modifiche locali
--nessun backup
non salvare copie di backup dei file
qguard
impostare o stampare le protezioni per una patch:
hg qguard [-l] [-n] [PATCH] [-- [+GUARD]... [-GUARD]...]
Le guardie controllano se una patch può essere applicata. Una toppa senza guardie viene sempre spinta. UN
patch con una guardia positiva ("+pippo") viene premuto solo se il hg SELERAPID il comando ha
attivato. Una patch con una guardia negativa ("-foo") non viene mai spinta se l'estensione hg SELERAPID
il comando lo ha attivato.
Senza argomenti, stampa le guardie attualmente attive. Con gli argomenti, imposta le guardie per il
patch con nome.
Nota Specificare le protezioni negative ora richiede '--'.
Per impostare le guardie su un'altra patch:
hg qguard other.patch -- +2.6.17 -stable
Restituisce 0 in caso di successo.
Opzioni:
-l, --elenco
elenca tutte le patch e le guardie
-N, --nessuno
lascia cadere tutte le guardie
qheader
stampa l'intestazione della patch più in alto o specificata:
hg qheader [PATCH]
Restituisce 0 in caso di successo.
qimport
importare una patch o un changeset esistente:
hg qimport [-e] [-n NOME] [-f] [-g] [-P] [-r REV]... [FILE]...
Il cerotto viene inserito nella serie dopo l'ultimo cerotto applicato. Se non ci sono patch
stato applicato, qimport antepone la patch alla serie.
La patch avrà lo stesso nome del suo file sorgente a meno che non gliene venga assegnata una nuova
-n/--nome.
È possibile registrare una patch esistente all'interno della directory patch con il flag -e/--existing.
Con -f/--force, una patch esistente con lo stesso nome verrà sovrascritta.
Un changeset esistente può essere posto sotto controllo mq con -r/--rev (ad esempio qimport --rev .
-n patch collocherà la revisione corrente sotto controllo mq). Con -g/--git, patch
importato con --rev utilizzerà il formato git diff. Per informazioni, vedere l'argomento della guida diffs
sul motivo per cui questo è importante per preservare le informazioni di rinomina/copia e le modifiche alle autorizzazioni.
Usa il hg qfinire per rimuovere i changeset dal controllo mq.
Per importare una patch dallo standard input, passare - come file di patch. Durante l'importazione da
standard input, è necessario specificare un nome di patch usando il flag --name.
Per importare una patch esistente rinominandola:
hg qimport -e patch-esistente -n nuovo-nome
Restituisce 0 se l'importazione è riuscita.
Opzioni:
-e, --esistente
importa il file nella directory della patch
-N,--nome
nome del file di patch
-F, --vigore
sovrascrivere i file esistenti
-R,--rev
porre le revisioni esistenti sotto controllo di mq
-G, --idiota
usa il formato diff esteso git
-P, --spingere
qpush dopo l'importazione
[+] l'opzione contrassegnata può essere specificata più volte
qinit
avviare un nuovo repository di code (DEPRECATO):
hg qinit [-c]
Per impostazione predefinita, il repository della coda non è versione. Se è specificato -c/--create-repo, qinit
creerà un repository nidificato separato per le patch (qinit -c può anche essere eseguito in un secondo momento
convertire un repository di patch senza versione in uno con versione). Puoi usare qcommit to
eseguire il commit delle modifiche a questo repository di code.
Questo comando è deprecato. Senza -c, è implicito da altri comandi rilevanti. Con -c,
uso hg init --mq anziché.
Opzioni:
-C, --creare-repo
creare un repository di code
qnuovo
crea una nuova patch:
hg qnew [-e] [-m TESTO] [-l FILE] PATCH [FILE]...
qnew crea una nuova patch sopra la patch attualmente applicata (se presente). La patch sarà
inizializzato con eventuali modifiche in sospeso nella directory di lavoro. Puoi anche usare
-I/--include, -X/--exclude e/o un elenco di file dopo il nome della patch da aggiungere solo
modifiche ai file corrispondenti alla nuova patch, lasciando il resto come modifiche non salvate.
-u/--user e -d/--date possono essere usati per impostare rispettivamente l'utente (dato) e la data.
-U/--currentuser e -D/--currentdate impostano l'utente sull'utente corrente e la data sulla data corrente.
-e/--edit, -m/--message o -l/--logfile imposta l'intestazione della patch e il commit
Messaggio. Se non ne viene specificato nessuno, l'intestazione è vuota e il messaggio di commit è '[mq]:
TOPPA'.
Usa l'opzione -g/--git per mantenere la patch nel formato diff esteso git. Leggi le differenze
argomento della guida per ulteriori informazioni sul motivo per cui questo è importante per preservare le modifiche alle autorizzazioni
e copiare/rinominare le informazioni.
Restituisce 0 in caso di creazione riuscita di una nuova patch.
Opzioni:
-e, --modificare
invoca l'editor sui messaggi di commit
-F, --vigore
importare modifiche non confermate (DEPRECATO)
-G, --idiota
usa il formato diff esteso git
-U, --utente corrente
aggiungi "Da: " per rattoppare
-tu,--utente
aggiungi "Da: " per rattoppare
-D, --data odierna
aggiungi "Data: " per rattoppare
-D,--Data
aggiungi "Data: " per rattoppare
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
[+] l'opzione contrassegnata può essere specificata più volte
Qnext
stampa il nome della prossima patch pushabile:
hg qsuccessivo [-s]
Restituisce 0 in caso di successo.
Opzioni:
-S, --riepilogo
stampa la prima riga dell'intestazione della patch
qpop
estrai la patch corrente dallo stack:
hg qpop [-a] [-f] [PATCH | INDICE]
Senza argomenti, salta fuori dalla cima dello stack di patch. Se viene assegnato un nome di patch, mantiene
rimuovendo le patch fino a quando la patch denominata non è in cima allo stack.
Per impostazione predefinita, interrompe se la directory di lavoro contiene modifiche non salvate. Insieme a
--keep-changes, interrompe solo se i file non salvati si sovrappongono ai file patchati. Insieme a
-f/--forza, salva ed elimina le modifiche apportate a tali file.
Restituisce 0 in caso di successo.
Opzioni:
-un, --tutti
pop tutte le patch
-N,--nome
nome della coda da inserire (DEPRECATO)
--keep-modifiche
tollerare cambiamenti locali non in conflitto
-F, --vigore
dimentica tutte le modifiche locali ai file corretti
--nessun backup
non salvare copie di backup dei file
qprev
stampa il nome della precedente patch applicata:
hg qprev [-s]
Restituisce 0 in caso di successo.
Opzioni:
-S, --riepilogo
stampa la prima riga dell'intestazione della patch
qspingere
metti la patch successiva nello stack:
hg qpush [-f] [-l] [-a] [--move] [PATCH | INDICE]
Per impostazione predefinita, interrompe se la directory di lavoro contiene modifiche non salvate. Insieme a
--keep-changes, interrompe solo se i file non salvati si sovrappongono ai file patchati. Insieme a
-f/--force, backup e patch su modifiche non salvate.
Restituisce 0 in caso di successo.
Opzioni:
--keep-modifiche
tollerare cambiamenti locali non in conflitto
-F, --vigore
applicare in aggiunta alle modifiche locali
-e, --esatto
applica la patch di destinazione al suo genitore registrato
-l, --elenco
elenca il nome della patch nel testo del commit
-un, --tutti
applica tutte le patch
-M, --unisci
unisci da un'altra coda (DEPRECATO)
-N,--nome
nome della coda di unione (DEPRECATO)
--spostare riordina le serie di patch e applica solo la patch
--nessun backup
non salvare copie di backup dei file
coda
gestire più code di patch:
hg qqueue [OPZIONE] [CODA]
Supporta il passaggio tra diverse code di patch e la creazione di nuove code di patch
e cancellando quelli esistenti.
Omettendo un nome di coda o specificando -l/--list verranno mostrate le code registrate - by
di default la coda delle patch "normali" è registrata. La coda attualmente attiva sarà
contrassegnato con "(attivo)". Specificando --active verrà stampato solo il nome della coda attiva.
Per creare una nuova coda, usa -c/--create. La coda viene automaticamente resa attiva, tranne in
il caso in cui ci sono patch applicate dalla coda attualmente attiva nel file
deposito. Quindi la coda verrà solo creata e il passaggio avrà esito negativo.
Per eliminare una coda esistente, utilizzare --delete. Non è possibile eliminare la coda attualmente attiva.
Restituisce 0 in caso di successo.
Opzioni:
-l, --elenco
elenca tutte le code disponibili
--attivo
nome di stampa della coda attiva
-C, --creare
crea una nuova coda
--rinominare
rinominare la coda attiva
--Elimina
eliminare il riferimento alla coda
--epurazione
elimina la coda e rimuovi la directory della patch
qaggiornare
aggiorna la patch corrente:
hg qrefresh [-I] [-X] [-e] [-m TESTO] [-l FILE] [-s] [FILE]...
Se vengono forniti modelli di file, la patch aggiornata conterrà solo le modifiche
che corrispondono a quei modelli; le restanti modifiche rimarranno in lavorazione
directory.
Se viene specificato -s/--short, i file attualmente inclusi nella patch verranno aggiornati solo
come i file corrispondenti e rimangono nella patch.
Se è specificato -e/--edit, Mercurial avvierà il tuo editor configurato per consentirti di inserire a
Messaggio. Nel caso in cui qrefresh fallisse, troverai un backup del tuo messaggio in
.hg/ultimo-messaggio.txt.
hg add/remove/copy/rename funziona come al solito, anche se potresti voler usare patch in stile git
(-g/--git o [diff] git=1) per tenere traccia di copie e rinominazioni. Per ulteriori informazioni, vedere l'argomento della guida diffs
informazioni sul formato git diff.
Restituisce 0 in caso di successo.
Opzioni:
-e, --modificare
invoca l'editor sui messaggi di commit
-G, --idiota
usa il formato diff esteso git
-S, --breve
aggiorna solo i file già presenti nella patch e i file specificati
-U, --utente corrente
aggiungi/aggiorna il campo dell'autore nella patch con l'utente corrente
-tu,--utente
aggiungi/aggiorna il campo dell'autore nella patch con un determinato utente
-D, --data odierna
aggiungi/aggiorna il campo della data nella patch con la data corrente
-D,--Data
aggiungi/aggiorna il campo della data nella patch con la data specificata
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
[+] l'opzione contrassegnata può essere specificata più volte
qrename
rinominare una patch:
hg qrename PATCH1 [PATCH2]
Con un argomento, rinomina la patch corrente in PATCH1. Con due argomenti, rinomina
PATCH1 a PATCH2.
Restituisce 0 in caso di successo.
alias: qmv
qrestore
ripristinare lo stato della coda salvato da una revisione (DEPRECATO):
hg qrestore [-d] [-u] REV
Questo comando è deprecato, usa hg rebase anziché.
Opzioni:
-D, --Elimina
elimina salva voce
-tu, --aggiornare
aggiorna la directory di lavoro della coda
salva
salva lo stato della coda corrente (DEPRECATO):
hg qsave [-m TESTO] [-l FILE] [-c] [-n NOME] [-e] [-f]
Questo comando è deprecato, usa hg rebase anziché.
Opzioni:
-C, --copia
copia la directory delle patch
-N,--nome
copia il nome della directory
-e, --vuoto
cancella il file di stato della coda
-F, --vigore
copia forzata
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
SELERAPID
imposta o stampa patch protetti per spingere:
hg qselect [OPZIONE]... [GUARDA]...
Usa il hg qguard comando per impostare o stampare le protezioni sulla patch, quindi utilizzare qselect per dire a mq
quali protezioni usare. Una patch verrà applicata se non ha guardie o guardie positive
corrisponde alla guardia attualmente selezionata, ma non verrà spinta se le guardie negative corrispondono
l'attuale guardia. Per esempio:
qguard foo.patch -- -stable (guardia negativa)
qguard bar.patch +stabile (guardia positiva)
qseleziona stabile
Questo attiva la guardia "stabile". mq salterà foo.patch (perché ha un negativo
match) ma push bar.patch (perché ha una corrispondenza positiva).
Senza argomenti, stampa le guardie attualmente attive. Con un argomento, imposta l'attivo
guardia.
Usa -n/--none per disattivare le guardie (non sono necessari altri argomenti). Quando non ci sono guardie
attivo, le patch con guardie positive vengono saltate e le patch con guardie negative lo sono
spinto.
qselect può cambiare le protezioni sulle patch applicate. Non fa scoppiare le patch protette da
predefinito. Usa --pop per tornare all'ultima patch applicata che non è protetta. Uso
--reapply (che implica --pop) per tornare alla patch corrente in seguito, ma salta
toppe custodite.
Usa -s/--series per stampare un elenco di tutte le guardie nel file della serie (nessun altro argomento
necessario). Utilizzare -v per ulteriori informazioni.
Restituisce 0 in caso di successo.
Opzioni:
-N, --nessuno
disattivare tutte le guardie
-S, --serie
elenca tutte le guardie nel file della serie
--pop vai a prima della prima patch applicata protetta
--riapplica
pop, quindi riapplica le patch
qserie
stampa l'intero file della serie:
hg qserie [-ms]
Restituisce 0 in caso di successo.
Opzioni:
-M, --mancante
patch di stampa non in serie
-S, --riepilogo
stampa la prima riga dell'intestazione della patch
qtop
stampa il nome della patch corrente:
hg qtop [-s]
Restituisce 0 in caso di successo.
Opzioni:
-S, --riepilogo
stampa la prima riga dell'intestazione della patch
qnonapplicato
stampa le patch non ancora applicate:
hg qnon applicato [-1] [-s] [PATCH]
Restituisce 0 in caso di successo.
Opzioni:
-1, --primo
mostra solo la prima patch
-S, --riepilogo
stampa la prima riga dell'intestazione della patch
notificare
ganci per l'invio di notifiche push e-mail
Questa estensione implementa hook per inviare notifiche e-mail quando vengono inviati i set di modifiche
o ricevuto dal repository locale.
Innanzitutto, abilita l'estensione come spiegato in hg Aiuto estensionie registra il gancio
vuoi correre. in arrivo ed gruppo di cambiamento gli hook vengono eseguiti quando vengono ricevuti i set di modifiche, while
uscente gli hook sono per i changeset inviati a un altro repository:
[ganci]
# un'e-mail per ogni changeset in arrivo
incoming.notify = python:hgext.notify.hook
# un'e-mail per tutti i set di modifiche in arrivo
changegroup.notify = python:hgext.notify.hook
# un'e-mail per tutti i set di modifiche in uscita
outgoing.notify = python:hgext.notify.hook
Questo registra gli hook. Per abilitare la notifica, gli abbonati devono essere assegnati a
repository. Il [subutenti] la sezione associa più repository a un determinato destinatario. Il
[reposub] la sezione associa più destinatari a un unico repository:
[subutenti]
La chiave # è l'e-mail dell'abbonato, il valore è un elenco separato da virgole di modelli di repository
utente@host = modello
[reposub]
La chiave # è il modello di repository, il valore è un elenco separato da virgole di email di abbonati
modello = utente@host
A modello è un glob corrispondenza del percorso assoluto di un repository, opzionalmente combinato con a
reimpostare l'espressione. Un'espressione revset, se presente, è separata dal glob da un hash.
Esempio:
[reposub]
*/widget#branch(rilascio) = [email protected]
Questo invia a [email protected] ogni volta che un changeset sul rilasciare trigger di ramo a
notifica in qualsiasi repository che termina con widget.
Per metterli sotto la gestione diretta degli utenti, [subutenti] ed [reposub] sezioni
può essere collocato in un separato hgr file e incorporati per riferimento:
[notificare]
config = /percorso/a/file di iscrizione
Le notifiche non verranno inviate fino al notifica.test il valore è impostato su Falso; vedi sotto.
Il contenuto delle notifiche può essere modificato con le seguenti voci di configurazione:
notifica.test
If I veri, stampa i messaggi su stdout invece di inviarli. Predefinito: Vero.
notifica.fonti
Elenco separato da spazi delle origini delle modifiche. Le notifiche vengono attivate solo quando a
l'origine del changeset è in questo elenco. Le fonti possono essere:
servire
changeset ricevuti tramite http o ssh
tirare
changeset ricevuti tramite hg tirare
unbundle
changeset ricevuti tramite hg unbundle
spingere
changeset inviati o ricevuti tramite hg spingere
fascio
changeset inviati tramite hg unbundle
Predefinito: servire.
notifica.striscia
Numero di barre iniziali da rimuovere dai percorsi URL. Per impostazione predefinita, le notifiche
repository di riferimento con il loro percorso assoluto. notifica.striscia ti permette di girarli
in percorsi relativi. Per esempio, notifica.striscia=3 cambierà /lungo/percorso/repository
ai miglioramenti deposito. Predefinito: 0.
notifica.dominio
Dominio e-mail predefinito per mittente o destinatario senza dominio esplicito.
notifica.stile
File di stile da utilizzare durante la formattazione delle e-mail.
notifica.modello
Modello da utilizzare durante la formattazione delle email.
notifica.in arrivo
Modello da utilizzare quando viene eseguito come hook in ingresso, sovrascrivendo notifica.modello.
notificare.in uscita
Modello da utilizzare quando viene eseguito come hook in uscita, sovrascrivendo notifica.modello.
notifica.changegroup
Modello da utilizzare durante l'esecuzione come hook di changegroup, sovrascrivendo notifica.modello.
notifica.maxdiff
Numero massimo di linee differenziali da includere nell'e-mail di notifica. Impostare su 0 per disabilitare
il diff, o -1 per includerlo tutto. Predefinito: 300.
notifica.maxoggetto
Numero massimo di caratteri nella riga dell'oggetto dell'e-mail. Predefinito: 67.
notifica.diffstat
Impostare su True per includere un diffstat prima del contenuto diff. Predefinito: Vero.
notifica.unione
Se True, invia notifiche per unire i set di modifiche. Predefinito: Vero.
notifica.mbox
Se impostato, aggiungi i messaggi di posta a questo file mbox invece di inviarli. Predefinito: Nessuno.
notifica.dall'autore
Se impostato, usa il committer del primo changeset in un gruppo di modifiche per "Da"
campo della mail di notifica. Se non è impostato, preleva l'utente dal push repo.
Predefinito: falso.
Se impostato, per personalizzare le notifiche verranno utilizzate anche le seguenti voci:
e-mail.da
E-mail Da indirizzo da utilizzare se non è possibile trovarne uno nel contenuto dell'e-mail generata.
URL.web.base
URL del repository radice da combinare con i percorsi del repository durante la creazione di riferimenti. Vedere
anche notifica.striscia.
cercapersone
sfoglia l'output del comando con un cercapersone esterno
Per impostare il pager da utilizzare, impostare la variabile dell'applicazione:
[cercapersone]
cercapersone = meno -FRX
Se non è impostato alcun cercapersone, le estensioni del cercapersone utilizzano la variabile di ambiente $PAGER. Se nessuno dei due
pager.pager, né $PAGER è impostato, non viene utilizzato alcun pager.
Puoi disabilitare il pager per determinati comandi aggiungendoli all'elenco pager.ignore:
[cercapersone]
ignore = versione, guida, aggiornamento
Puoi anche abilitare il cercapersone solo per determinati comandi usando pager.attend. Di seguito è il
elenco predefinito di comandi da impaginare:
[cercapersone]
attend = annota, cat, diff, export, glog, log, qdiff
L'impostazione di pager.attend su un valore vuoto causerà il paging di tutti i comandi.
Se pager.attend è presente, pager.ignore verrà ignorato.
Infine, puoi abilitare e disabilitare il paging per i singoli comandi con il
frequentare- opzione. Questa impostazione ha la precedenza sull'esistente partecipa e ignora
opzioni e impostazioni predefinite:
[cercapersone]
attend-cat = falso
Per ignorare comandi globali come hg versione or hg Aiuto, devi specificarli nel tuo
file di configurazione utente.
Per controllare se il cercapersone viene utilizzato per un singolo comando, è possibile utilizzare
--cercapersone= :
- utilizzare secondo necessità: `auto`.
- richiedi il cercapersone: `yes` o `on`.
- sopprimere il cercapersone: `no` o `off` (qualsiasi valore non riconosciuto
funzionerà anche).
patchbomba
comando per inviare i changeset come (una serie di) email di patch
La serie inizia con un'introduzione "[PATCH 0 di N]", che descrive la serie
nel suo complesso.
Ogni e-mail di patch ha una riga Oggetto di "[PATCH M di N] ...", utilizzando la prima riga di
descrizione del changeset come testo dell'oggetto. Il messaggio contiene due o tre parti del corpo:
· La descrizione del gruppo di modifiche.
· [Facoltativo] Il risultato dell'esecuzione di diffstat sulla patch.
· La patch stessa, generata da hg export.
Ogni messaggio fa riferimento al primo della serie utilizzando In-Reply-To e Riferimenti
intestazioni, quindi verranno visualizzate come una sequenza nella posta in thread e nei lettori di notizie e nella posta
archivi.
Per configurare altre impostazioni predefinite, aggiungi una sezione come questa al tuo file di configurazione:
[e-mail]
da = Il mio nome
a = destinatario1, destinatario2, ...
cc = cc1, cc2, ...
bcc = bcc1, bcc2, ...
risposta-a = indirizzo1, indirizzo2, ...
Usa il [bomba patch] come nome della sezione di configurazione se è necessario sovrascrivere globale [e-mail]
impostazioni dell'indirizzo.
Quindi puoi usare il hg email comando per inviare una serie di changeset come patchbomb.
Puoi anche configurare l'opzione del metodo nella sezione email come sendmail
mailer compatibile o compilare la sezione [smtp] in modo che l'estensione patchbomb possa farlo
invia automaticamente patchbomb direttamente dalla riga di comando. Vedi [e-mail] e [smtp]
sezioni in hgr(5) per i dettagli.
Per impostazione predefinita, hg email richiederà un A or CC header se non ne fornisci uno tramite
configurazione o dalla riga di comando. È possibile ignorarlo per non richiedere mai tramite la configurazione
un valore vuoto:
[e-mail]
cc =
Puoi controllare l'inclusione predefinita di un messaggio introduttivo con il patchbomb.intro
opzione di configurazione. La configurazione viene sempre sovrascritta da flag della riga di comando come
--intro e --desc:
[bomba patch]
intro=auto # include il messaggio di introduzione se più di 1 patch (predefinito)
intro=mai # non include mai un messaggio di introduzione
intro=sempre # includi sempre un messaggio di introduzione
Puoi impostare patchbomb per chiedere sempre conferma impostando patchbomb.conferma vero.
Comandi
inviare i set di modifiche tramite e-mail:
hg email [OPZIONE]... [DESTINAZIONE]...
Per impostazione predefinita, le differenze vengono inviate nel formato generato da hg export, uno per messaggio. Il
la serie inizia con un'introduzione "[PATCH 0 di N]", che descrive la serie nel suo insieme.
Ogni e-mail di patch ha una riga Oggetto di "[PATCH M di N] ...", utilizzando la prima riga di
descrizione del changeset come testo dell'oggetto. Il messaggio contiene due o tre parti.
Innanzitutto, la descrizione del set di modifiche.
Con l'opzione -d/--diffstat, se il programma diffstat è installato, il risultato dell'esecuzione
diffstat sulla patch è inserito.
Infine, la patch stessa, generata da hg export.
Con le opzioni -d/--diffstat o --confirm, ti verrà presentato un riepilogo finale di
tutti i messaggi e ha chiesto conferma prima dell'invio dei messaggi.
Per impostazione predefinita, la patch è inclusa come testo nel corpo dell'e-mail per una facile revisione. Usando il
L'opzione -a/--attach creerà invece un allegato per la patch. Con -i/--inline an
verrà creato l'allegato inline. Puoi includere una patch sia come testo nel corpo dell'e-mail
e come allegato normale o in linea combinando -a/--attach o -i/--inline con
l'opzione --body.
Con -o/--in uscita, verranno generate e-mail per le patch non trovate nella destinazione
repository (o solo quelli che sono predecessori delle revisioni specificate, se presenti
fornito)
Con -b/--bundle, i changeset sono selezionati come per --outgoing, ma contiene una singola email
verrà inviato un pacchetto Mercurial binario come allegato. Utilizzare il patchbomb.bundletype
config opzione per controllare il tipo di pacchetto come con hg fascio --genere.
Con -m/--mbox, invece di visualizzare in anteprima ogni messaggio patchbomb in un cercapersone o inviare il file
messaggi direttamente, creerà un file di posta UNIX con le e-mail di patch. Questa casella di posta
il file può essere visualizzato in anteprima con qualsiasi agente utente di posta che supporti i file mbox UNIX.
Con -n/--test, tutti i passaggi verranno eseguiti, ma la posta non verrà inviata. Ti verrà richiesto
un indirizzo e-mail del destinatario, un oggetto e un messaggio introduttivo che descrive le patch
della tua patchbomb. Quindi, quando tutto è finito, vengono visualizzati i messaggi di patchbomb. Se il cercapersone
è impostata la variabile di ambiente, il tuo cercapersone verrà attivato una volta per ogni messaggio di patchbomb,
così puoi verificare che sia tutto a posto.
Nel caso in cui l'invio dell'e-mail non vada a buon fine, troverai un backup del messaggio introduttivo della tua serie in
.hg/ultima-email.txt.
Il comportamento predefinito di questo comando può essere personalizzato tramite la configurazione. (Vedere hg Aiuto
patchbomba per dettagli)
Consigli d'uso:
hg email -r 3000 # invia solo la patch 3000
hg email -r 3000 -r 3001 # invia patch 3000 e 3001
hg email -r 3000:3005 # invia le patch da 3000 a 3005
hg email 3000 # invia patch 3000 (obsoleto)
hg email -o # invia tutte le patch non predefinite
hg email -o DEST # invia tutte le patch non in DEST
hg email -o -r 3000 # invia tutti gli antenati di 3000 non in default
hg email -o -r 3000 DEST # invia tutti gli antenati di 3000 non in DEST
hg email -b # invia il pacchetto di tutte le patch non in default
hg email -b DEST # invia il bundle di tutte le patch non in DEST
hg email -b -r 3000 # bundle di tutti gli antenati di 3000 non in default
hg email -b -r 3000 DEST # bundle di tutti gli antenati di 3000 non in DEST
hg email -o -m mbox && # genera un file mbox...
mutt -R -f mbox # ... e visualizzalo con mutt
hg email -o -m mbox && # genera un file mbox ...
formail -s sendmail \ # ... e usa formail per inviare dalla mbox
-bm -t < mbox # ... usando sendmail
Prima di utilizzare questo comando, dovrai abilitare la posta elettronica nel tuo hgrc. Vedi la [e-mail]
sezione in hgr(5) per i dettagli.
Opzioni:
-G, --idiota
usa il formato diff esteso git
--pianura
omettere l'intestazione della patch hg
-oh, --estroverso
invia le modifiche non trovate nel repository di destinazione
-B, --fascio
invia le modifiche non nella destinazione come pacchetto binario
--nome bundle
nome del file allegato bundle (predefinito: bundle)
-R,--rev
una revisione da inviare
--vigore
eseguito anche quando il repository remoto non è correlato (con -b/--bundle)
--base
un set di modifiche di base da specificare invece di una destinazione (con -b/--bundle)
--introduzione
inviare un'e-mail di presentazione per una singola patch
--corpo invia le patch come testo del messaggio in linea (predefinito)
-un, --allegare
inviare patch come allegati
-io, --in linea
inviare patch come allegati inline
--ccn
indirizzi e-mail dei destinatari della copia carbone cieca
-C,--cc
indirizzi e-mail dei destinatari della copia
--Confermare
chiedere conferma prima di inviare
-D, --diffstat
aggiungi output diffstat ai messaggi
--Data
utilizzare la data indicata come data di invio
--desc
utilizzare il file fornito come descrizione della serie
-F,--a partire dal
indirizzo email del mittente
-N, --test
stampare i messaggi che sarebbero stati inviati
-M,--mbox
scrivi i messaggi nel file mbox invece di inviarli
--rispondi a
indirizzi email a cui devono essere inviate le risposte
-S,--soggetto
oggetto del primo messaggio (introduzione o patch singola)
--in risposta a
identificatore del messaggio a cui rispondere
--bandiera
flag da aggiungere nei prefissi degli argomenti
-T,--per
indirizzi email dei destinatari
-e,--ssh
specificare il comando ssh da usare
--remotecmd
specifica il comando hg da eseguire sul lato remoto
--insicuro
non verificare il certificato del server (ignorando la configurazione di web.cacerts)
[+] l'opzione contrassegnata può essere specificata più volte
purga
comando per eliminare i file non tracciati dalla directory di lavoro
Comandi
purga
rimuove i file non tracciati da Mercurial:
hg purge [OPZIONE]... [DIR]...
Elimina i file non noti a Mercurial. Questo è utile per testare le modifiche locali e non vincolate
in un albero di origine altrimenti pulito.
Ciò significa che l'eliminazione eliminerà quanto segue per impostazione predefinita:
· File sconosciuti: file contrassegnati con "?" di hg status
· Directory vuote: infatti Mercurial ignora le directory a meno che non contengano file sotto
gestione del controllo del codice sorgente
Ma lascerà intatto:
· File tracciati modificati e non modificati
· File ignorati (a meno che non sia specificato --all)
· Nuovi file aggiunti al repository (con hg aggiungere)
Le opzioni --files e --dirs possono essere utilizzate per eliminare direttamente solo i file
directory o entrambi. Se nessuna delle opzioni viene fornita, entrambe verranno eliminate.
Se le directory vengono fornite sulla riga di comando, lo sono solo i file in queste directory
considerato.
Fai attenzione con l'eliminazione, poiché potresti eliminare irreversibilmente alcuni file a cui hai dimenticato di aggiungere
il deposito. Se vuoi solo stampare l'elenco dei file che questo programma farebbe
elimina, usa l'opzione --print.
Opzioni:
-un, --abort-on-err
interrompere se si verifica un errore
--tutti elimina anche i file ignorati
--dir elimina le directory vuote
--File
elimina i file
-P, --Stampa
stampa i nomi dei file invece di eliminarli
-0, --print0
nomi di file finali con NUL, per l'uso con xargs (implica -p/--print)
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
alias: pulito
rebase
comando per spostare serie di revisioni su un antenato diverso
Questa estensione ti consente di reimpostare i set di modifiche in un repository Mercurial esistente.
Per ulteriori informazioni: https://mercurial-scm.org/wiki/RebaseExtension
Comandi
rebase
sposta changeset (e discendenti) in un ramo diverso:
hg rebase [-s REV | -b REV] [-d REV] [OPZIONE]
Rebase utilizza l'unione ripetuta per innestare i set di modifiche da una parte della cronologia (l'origine)
su un altro (la destinazione). Questo può essere utile per la linearizzazione locale modifiche relative
ad un albero di sviluppo principale.
I commit pubblicati non possono essere ribasati (vedi hg Aiuto fasi). Per copiare i commit, vedere hg Aiuto
Graft.
Se non specifichi un changeset di destinazione (-d/--destin), rebase utilizza il ramo corrente
punta come destinazione. (Il changeset di destinazione non viene modificato dal rebasing, ma nuovo
i changeset vengono aggiunti come suoi discendenti.)
Di seguito sono riportati i modi per selezionare i set di modifiche:
1. Selezionali esplicitamente usando --rev.
2. Utilizzare --fonte per selezionare un changeset radice e includere tutti i suoi discendenti.
3. Utilizzare --base per selezionare un changeset; rebase troverà gli antenati e i loro discendenti
che non sono anche antenati della destinazione.
4. Se non si specifica nessuno di --rev, source, o --base, utilizzerà rebase --base . as
sopra.
Rebase distruggerà i set di modifiche originali a meno che non li usi --mantenere. Sposterà anche il tuo
segnalibri (anche se lo fai).
Alcuni set di modifiche potrebbero essere eliminati se non apportano modifiche (ad esempio, unioni da file
ramo di destinazione).
a differenza di unire, rebase non farà nulla se ti trovi sulla punta del ramo di un ramo con nome con
due teste. Sarà necessario specificare esplicitamente l'origine e/o la destinazione.
Se un rebase viene interrotto per risolvere manualmente un conflitto, è possibile continuare con
--continue/-c o interrotto con --abort/-a.
Consigli d'uso:
· sposta "modifiche locali" (il commit corrente torna al punto di diramazione) al tip del ramo corrente
dopo un tiro:
rebase hg
· spostare un singolo changeset nel ramo stabile:
hg rebase -r 5f493448 -d stabile
· unire un commit e tutti i suoi discendenti in un'altra parte della storia:
hg rebase --source c0c3 --dest 4cf9
· ribasare tutto su un ramo contrassegnato da un segnalibro sul ramo predefinito:
hg rebase --base myfeature --dest predefinito
· comprime una sequenza di modifiche in un unico commit:
hg rebase --collapse -r 1520:1525 -d .
· spostare un ramo con nome mantenendone il nome:
hg rebase -r "branch(featureX)" -d 1.3 --keepbranches
Restituisce 0 in caso di successo, 1 se non c'è nulla da ribasare o ci sono conflitti irrisolti.
Opzioni:
-S,--fonte
ribasare il changeset e i discendenti specificati
-B,--base
ribasare tutto dal punto di diramazione del set di modifiche specificato
-R,--rev
rifondare queste revisioni
-D,--dest
rebase sul changeset specificato
--crollo
comprimere i changeset ribasati
-M,--Messaggio
usa il testo come messaggio di commit di compressione
-e, --modificare
invoca l'editor sui messaggi di commit
-l,--file di log
leggi il messaggio di commit di compressione dal file
-K, --mantenere
mantieni i set di modifiche originali
--mantieni i rami
mantieni i nomi dei rami originali
-D, --stacca
(DEPRECATO)
-io, --interattivo
(DEPRECATO)
-T,--attrezzo
specificare lo strumento di unione
-C, --Continua
continuare un rebase interrotto
-un, --abortire
interrompere un rebase interrotto
--stile
visualizzare utilizzando il file mappa modello (DEPRECATO)
-T,--modello
display con modello
[+] l'opzione contrassegnata può essere specificata più volte
record
comandi per selezionare in modo interattivo le modifiche per commit/qrefresh
Comandi
qrecord
registrare interattivamente una nuova patch:
hg qrecord [OPZIONE]... PATCH [FILE]...
See hg Aiuto qnuovo & hg Aiuto record per ulteriori informazioni e utilizzo.
record
seleziona interattivamente le modifiche da confermare:
hg record [OPZIONE]... [FILE]...
Se un elenco di file viene omesso, tutte le modifiche riportate da hg status saranno candidati per
registrazione.
See hg Aiuto DATE per un elenco di formati validi per -d/--date.
Ti verrà chiesto se registrare le modifiche a ciascun file modificato e ai file
con più modifiche, per ogni modifica da utilizzare. Per ogni query, le seguenti risposte sono
possibile:
y - registra questa modifica
n - salta questa modifica
e - modificare questa modifica manualmente
s - salta le modifiche rimanenti a questo file
f - registra le modifiche rimanenti in questo file
d - Fatto, salta le modifiche e i file rimanenti
a - registra tutte le modifiche a tutti i file rimanenti
q - esci, non registrando modifiche
? - visualizzare la guida
Questo comando non è disponibile quando si esegue il commit di un'unione.
Opzioni:
-UN, --Aggiungi Rimuovi
contrassegna i file nuovi/mancanti come aggiunti/rimossi prima di eseguire il commit
--chiudi-ramo
contrassegnare una testa di ramo come chiusa
--modifica
modificare il genitore della directory di lavoro
-S, --segreto
usa la fase segreta per impegnarti
-e, --modificare
invoca l'editor sui messaggi di commit
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
-M,--Messaggio
usa il testo come messaggio di commit
-l,--file di log
leggi il messaggio di commit dal file
-D,--Data
registra la data specificata come data di commit
-tu,--utente
registra l'utente specificato come committer
-S, --sottorepos
ricorrono in sottorepository
-w, --ignora-tutto-spazio
ignora gli spazi bianchi quando confronti le righe
-B, --ignora-spazio-cambiamento
ignora i cambiamenti nella quantità di spazio bianco
-B, --ignora-linee-vuote
ignora le modifiche le cui righe sono tutte vuote
[+] l'opzione contrassegnata può essere specificata più volte
ricollegare
ricrea i collegamenti fisici tra i cloni del repository
Comandi
ricollegare
ricreare gli hardlink tra due repository:
hg ricollega [ORIGIN]
Quando i repository vengono clonati localmente, i loro file di dati verranno collegati in modo rigido in modo che possano
utilizzare solo lo spazio di un singolo repository.
Sfortunatamente, i successivi pull in entrambi i repository interromperanno gli hardlink per tutti i file
toccato dai nuovi set di modifiche, anche se entrambi i repository finiscono per eseguire le stesse modifiche.
Allo stesso modo, il passaggio di --rev a "hg clone" non riuscirà a utilizzare alcun hardlink, ricadere su a
copia completa del repository di origine.
Questo comando ti consente di ricreare quei collegamenti fisici e recuperare lo spazio sprecato.
Questo repository verrà ricollegato per condividere lo spazio con ORIGIN, che deve essere sullo stesso
disco locale. Se ORIGIN viene omesso, cerca "default-relink", quindi "default", in [percorsi].
Non tentare alcuna operazione di lettura su questo repository mentre il comando è in esecuzione. (Tutti e due
i repository saranno bloccati contro le scritture.)
schemi
estendere gli schemi con collegamenti agli sciami di repository
Questa estensione ti consente di specificare scorciatoie per gli URL principali con molti repository
agire come uno schema, ad esempio:
[schemi]
pi = http://code.python.org/hg/
Dopodiché puoi usarlo come:
hg clone py://trunk/
Inoltre c'è il supporto per alcuni schemi più complessi, ad esempio utilizzati da Google
Codice:
[schemi]
codice g = http://{1}.googlecode.com/hg/
La sintassi è presa dai modelli Mercurial e hai un numero illimitato di variabili,
Iniziare con {} 1 e continuando con {} 2, {} 3 e così via. Riceveranno queste variabili
parti dell'URL fornito, suddivise per /. Tutto ciò che non è specificato come {parte} sarà appena aggiunto
a un URL.
Per comodità, l'estensione aggiunge questi schemi per impostazione predefinita:
[schemi]
pi = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://[email protected]/
codice g = https://{1}.googlecode.com/hg/
forno = https://{1}.kilnhg.com/Repo/
È possibile sovrascrivere uno schema predefinito definendo un nuovo schema con lo stesso nome.
Share
condividere una storia comune tra diverse directory di lavoro
Automatico In pool Archiviazione per cloni
Quando questa estensione è attiva, hg clonare può essere configurato per condividere/raggruppare automaticamente
archiviazione su più cloni. Questa modalità converte efficacemente hg clonare a hg clonare + hg
Share. Il vantaggio dell'utilizzo di questa modalità è la gestione automatica dei percorsi del negozio e
pooling intelligente di repository correlati.
Le seguenti Condividere. le opzioni di configurazione influenzano questa funzione:
condividi.piscina
Percorso del filesystem in cui verranno archiviati i dati del repository condiviso. Quando definito, hg clonare
utilizzerà automaticamente l'archiviazione del repository condiviso invece di creare un negozio all'interno
ogni clone.
condividi.nomepiscina
Come nomi di directory in condividi.piscina sono costruiti.
"identità" significa che il nome deriva dal primo changeset nel repository. In
in questa modalità, diversi telecomandi condividono l'archiviazione se il loro set di modifiche root/iniziale lo è
identico. In questa modalità, il repository condiviso locale è un aggregato di tutti
incontrato repository remoti.
"remoto" significa che il nome deriva dal percorso o dall'URL del repository di origine. In
questa modalità, l'archiviazione è condivisa solo se il percorso o l'URL richiesto nel file hg clonare
il comando corrisponde esattamente a un repository che è stato clonato in precedenza.
La modalità di denominazione predefinita è "identità".
Comandi
Share
creare un nuovo repository condiviso:
hg share [-U] [-B] FONTE [DEST]
Inizializza un nuovo repository e una directory di lavoro che ne condivide la cronologia (e facoltativamente
preferiti) con un altro repository.
Nota l'utilizzo di rollback o estensioni che distruggono/modificano la cronologia (mq, rebase, ecc.) Può
causare notevole confusione con i cloni condivisi. In particolare se due condivisi
i cloni vengono entrambi aggiornati allo stesso set di modifiche e uno di loro lo distrugge
changeset con rollback, l'altro clone smetterà improvvisamente di funzionare: tutte le operazioni
fallirà con "abort: la directory di lavoro ha un genitore sconosciuto". L'unico conosciuto
la soluzione alternativa consiste nell'usare debugsetparents sul clone rotto per reimpostarlo su un changeset
che esiste ancora.
Opzioni:
-U, --nessun aggiornamento
non creare una directory di lavoro
-B, --segnalibri
condividi anche i segnalibri
annullare la condivisione
convertire un repository condiviso in uno normale:
hg annulla condivisione
Copia i dati del negozio nel repository e rimuovi i dati del percorso condiviso.
accantonare
salvare e ripristinare le modifiche alla directory di lavoro
Il comando "hg shelve" salva le modifiche apportate alla directory di lavoro e le ripristina
modifiche, ripristinando la directory di lavoro in uno stato pulito.
Successivamente, il comando "hg unshelve" ripristina le modifiche salvate da "hg shelve". Le modifiche possono
essere ripristinato anche dopo l'aggiornamento a un genitore diverso, nel qual caso la fusione di Mercurial
macchinari risolveranno eventuali conflitti, se necessario.
Puoi avere più di una modifica accantonata in sospeso alla volta; ogni cambio accantonato ha a
nome distinto. Per i dettagli, vedere la guida per "hg shelve".
Comandi
accantonare
salva e metti da parte le modifiche dalla directory di lavoro:
hg shelve [OPZIONE]... [FILE]...
Shelving prende i file che "stato hg" segnala come non puliti, salva le modifiche in a
bundle (una modifica accantonata) e ripristina i file in modo che il loro stato nel lavoro
la directory diventa pulita.
Per ripristinare queste modifiche nella directory di lavoro, utilizzare "hg unshelve"; questo funzionerà
anche se passi a un commit diverso.
Quando non vengono specificati file, "hg shelve" salva tutti i file non puliti. Se file specifici o
le directory sono nominate, solo le modifiche a quei file vengono archiviate.
Ogni cambiamento accantonato ha un nome che lo rende più facile da trovare in seguito. Il nome di uno scaffale
cambia le impostazioni predefinite in base al segnalibro attivo o se non è presente alcun segnalibro attivo,
il ramo denominato corrente. Per specificare un nome diverso, utilizzare --nome.
Per visualizzare un elenco delle modifiche archiviate esistenti, utilizzare il --elenco opzione. Per ogni cambio accantonato,
questo ne stamperà il nome, l'età e la descrizione; uso --toppa or --statistica per ulteriori dettagli.
Per eliminare specifiche modifiche archiviate, utilizzare --Elimina. Per eliminare tutte le modifiche archiviate, utilizzare
--ripulire.
Opzioni:
-UN, --Aggiungi Rimuovi
contrassegnare i file nuovi/mancanti come aggiunti/rimossi prima dell'archiviazione
-tu, --sconosciuto
archiviare i file sconosciuti nello scaffale
--ripulire
eliminare tutte le modifiche archiviate
--Data
accantonare con la data di commit specificata
-D, --Elimina
eliminare le modifiche accantonate con nome
-e, --modificare
invoca l'editor sui messaggi di commit
-l, --elenco
elenca gli scaffali correnti
-M,--Messaggio
usa il testo come messaggio da scaffale
-N,--nome
usa il nome dato per il commit accantonato
-P, --toppa
mostra la patch
-io, --interattivo
modalità interattiva, funziona solo durante la creazione di uno scaffale
--statistica output di riepilogo delle modifiche in stile diffstat
-IO,--includere
includi nomi che corrispondono ai modelli dati
-X,--escludere
escludere i nomi che corrispondono ai modelli dati
[+] l'opzione contrassegnata può essere specificata più volte
sciogliere
ripristinare una modifica archiviata nella directory di lavoro:
hg unshelf [SHELVED]
Questo comando accetta un nome facoltativo di una modifica archiviata da ripristinare. Se nessuno è dato,
viene utilizzata la modifica accantonata più recente.
Se una modifica accantonata viene applicata correttamente, il pacchetto che contiene le modifiche archiviate
viene spostato in una posizione di backup (.hg/shelve-backup).
Dal momento che puoi ripristinare una modifica accantonata su un commit arbitrario, è possibile che
l'annullamento degli scaffali comporterà un conflitto tra le modifiche e i commit che sei
smontando. Se ciò si verifica, è necessario risolvere il conflitto, quindi utilizzare --Continua a
completare l'operazione di sblocco. (Il pacchetto non verrà spostato fino a quando non avrai avuto successo
completare lo scaffale.)
(In alternativa, puoi usare --abortire abbandonare uno scaffale che causa un conflitto. Questo
annulla le modifiche non archiviate e lascia il pacchetto in posizione.)
Dopo un'operazione di rimozione dallo scaffale riuscita, le modifiche archiviate vengono archiviate in una directory di backup. Solo
vengono conservati gli N backup più recenti. Il valore predefinito di N è 10 ma può essere sovrascritto utilizzando il
shelve.maxbackups opzione di configurazione.
Timestamp in secondi viene utilizzato per decidere l'ordine dei backup. Più di maxbackup i backup sono
conservati, se lo stesso timestamp impedisce di deciderne l'ordine esatto, per sicurezza.
Opzioni:
-un, --abortire
interrompere un'operazione di rimozione dallo scaffale incompleta
-C, --Continua
continuare un'operazione di rimozione dallo scaffale incompleta
-K, --mantenere
tenere accantonato dopo aver smontato
-T,--attrezzo
specificare lo strumento di unione
--Data
data fissata per commit temporanei (DEPRECATO)
striscia
spogliare i changeset e i loro discendenti dalla storia
Questa estensione ti consente di rimuovere i changeset e tutti i loro discendenti dal file
deposito. Vedere la guida ai comandi per i dettagli.
Comandi
striscia
strip changeset e tutti i loro discendenti dal repository:
striscia hg [-k] [-f] [-B segnalibro] [-r] REV...
Il comando strip rimuove i changeset specificati e tutti i loro discendenti. Se la
directory di lavoro ha modifiche non salvate, l'operazione viene interrotta a meno che il --force
viene fornito il flag, nel qual caso le modifiche verranno annullate.
Se un genitore della directory di lavoro viene rimosso, la directory di lavoro lo farà
essere aggiornato automaticamente all'antenato più recente disponibile del genitore rimosso
al termine dell'operazione.
Tutti i set di modifiche eliminati vengono archiviati in .hg/strip-backup in blocco (vedi hg Aiuto fascio ed
hg Aiuto unbundle). Possono essere ripristinati eseguendo hg unbundle .hg/strip-backup/BUNDLE,
dove BUNDLE è il file bundle creato dalla striscia. Si noti che i numeri di revisione locali
sarà generalmente diverso dopo il ripristino.
Utilizzare l'opzione --no-backup per eliminare il bundle di backup una volta completata l'operazione.
Strip non è un'operazione di riscrittura della cronologia e può essere utilizzata su set di modifiche nel pubblico
fase. Ma se i set di modifiche rimossi sono stati inviati a un repository remoto, lo farai
probabilmente tirarli di nuovo.
Restituisce 0 in caso di successo.
Opzioni:
-R,--rev
elimina la revisione specificata (opzionale, può specificare le revisioni senza questa opzione)
-F, --vigore
forzare la rimozione dei set di modifiche, eliminare le modifiche non salvate (nessun backup)
--nessun backup
nessun backup
--nessun backup
nessun backup (DEPRECATO)
-n ignorato (DEPRECATO)
-K, --mantenere
non modificare la directory di lavoro durante lo strip
-B,--segnalibro
rimuovi i giri raggiungibili solo da un determinato segnalibro
[+] l'opzione contrassegnata può essere specificata più volte
trapianto
comando per trapiantare i changeset da un altro ramo
Questa estensione ti consente di trapiantare le modifiche in un'altra revisione genitore, possibilmente in
un altro deposito. Il trapianto viene eseguito utilizzando cerotti "diff".
Le patch trapiantate vengono registrate in .hg/transplant/transplants, come mappa da un changeset
hash al suo hash nel repository di origine.
Comandi
trapianto
trapianti changeset da un altro ramo:
trapianto di hg [-s REPO] [-b BRANCH [-a]] [-p REV] [-m REV] [REV]...
I set di modifiche selezionati verranno applicati in cima alla directory di lavoro corrente con il registro
del changeset originale. I changeset vengono copiati e quindi appariranno due volte nel file
storia con identità diverse.
Prendi in considerazione l'utilizzo del comando innesto se tutto si trova all'interno dello stesso repository: lo utilizzerà
si unisce e di solito darà un risultato migliore. Usa l'estensione rebase se le modifiche vengono impostate
non sono pubblicati e si desidera spostarli invece di copiarli.
Se viene specificato --log, ai messaggi di registro verrà aggiunto un commento del modulo:
(trapiantato da CHANGESETHASH)
Puoi riscrivere il messaggio del log delle modifiche con l'opzione --filter. Il suo argomento sarà
invocato con il messaggio del changelog corrente come $1 e la patch come $2.
--source/-s specifica un altro repository da utilizzare per selezionare i changeset, proprio come se fosse
era stato temporaneamente ritirato. Se viene specificato --branch/-b, queste revisioni verranno utilizzate come
testa al momento di decidere quali changeset trapiantare, proprio come se solo queste revisioni avessero avuto
stato tirato. Se viene specificato --all/-a, tutte le revisioni fino alle teste specificate con
--il ramo verrà trapiantato.
Esempio:
· trapiantare tutte le modifiche fino a REV in aggiunta alla revisione corrente:
hg trapianto --branch REV --all
È possibile facoltativamente contrassegnare i changeset trapiantati selezionati come unisci i changeset. Non lo farai
viene richiesto di trapiantare tutti gli antenati di un trapianto unito e puoi unire
loro discendenti normalmente invece di trapiantarli.
Unisci i set di modifiche possono essere trapiantati direttamente specificando il corretto set di modifiche padre da
chiamata hg trapianto --genitore.
Se non vengono fornite fusioni o revisioni, hg trapianto avvierà un changeset interattivo
browser.
Se un'applicazione changeset non riesce, puoi correggere manualmente l'unione e quindi riprendere da dove sei
interrotto chiamando hg trapianto --continua/-c.
Opzioni:
-S,--fonte
trapianti changeset da REPO
-B,--ramo
usa questo changeset sorgente come head
-un, --tutti
trascina tutti i set di modifiche fino alle revisioni --branch
-P,--fesso
salta REV
-M,--unisci
fondersi a REV
--genitore
genitore da scegliere durante il trapianto di fusione
-e, --modificare
invoca l'editor sui messaggi di commit
--tronco d'albero aggiungi le informazioni sul trapianto per registrare il messaggio
-C, --Continua
continuare l'ultima sessione di trapianto dopo aver risolto i conflitti
--filtro
filtra i set di modifiche tramite il comando
[+] l'opzione contrassegnata può essere specificata più volte
win32mbcs
consentire l'uso di percorsi MBCS con codifiche problematiche
Alcune codifiche MBCS non sono adatte per alcune operazioni sui percorsi (ad esempio, la divisione del percorso, case
conversione, ecc.) con i suoi byte codificati. Chiamiamo tale codifica (cioè shift_jis e
big5) come "codifica problematica". Questa estensione può essere utilizzata per risolvere il problema con quelli
codifiche avvolgendo alcune funzioni da convertire in stringa Unicode prima dell'operazione sul percorso.
Questa estensione è utile per:
· Utenti Windows giapponesi che utilizzano la codifica shift_jis.
· Utenti Windows cinesi che utilizzano la codifica big5.
· Tutti gli utenti che utilizzano un repository con una delle codifiche problematiche senza distinzione tra maiuscole e minuscole
file system.
Questa estensione non è necessaria per:
· Qualsiasi utente che utilizza solo caratteri ASCII nel percorso.
· Qualsiasi utente che non utilizza nessuna delle codifiche problematiche.
Tieni presente che ci sono alcune limitazioni sull'utilizzo di questa estensione:
· Dovresti usare una codifica singola in un repository.
· Se il percorso del repository termina con 0x5c, non è possibile leggere .hg/hgrc.
· win32mbcs non è compatibile con l'estensione fixutf8.
Per impostazione predefinita, win32mbcs utilizza encoding.encoding deciso da Mercurial. È possibile specificare il
codifica per opzione di configurazione:
[win32mbcs]
codifica = sjis
È utile per gli utenti che desiderano eseguire il commit con il messaggio di registro UTF-8.
testo win32
eseguire la conversione automatica di una nuova riga (DEPRECATO)
Deprecazione: l'estensione win32text richiede che ogni utente configuri l'estensione
ancora e ancora per ogni clone poiché la configurazione non viene copiata durante la clonazione.
Abbiamo quindi realizzato il eol in alternativa. Il eol utilizza una versione controllata
file per la sua configurazione e ogni clone utilizzerà quindi le impostazioni corrette da
la partenza.
Per eseguire la conversione automatica di una nuova riga, utilizzare:
[estensioni]
win32testo =
[codificare]
** = codifica intelligente:
# o ** = codice macen:
[decodificare]
** = decodifica intelligente:
# o ** = macdecode:
Se non stai effettuando la conversione, per assicurarti di non commettere CRLF/CR per sbaglio:
[ganci]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf
# o pretxncommit.cr = python:hgext.win32text.forbidcr
Per eseguire lo stesso controllo su un server per impedire il push o il pull di CRLF/CR:
[ganci]
pretxnchangegroup.crlf = python:hgext.win32text.forbidcrlf
# o pretxnchangegroup.cr = python:hgext.win32text.forbidcr
zeroconf
scoprire e pubblicizzare i repository sulla rete locale
L'estensione zeroconf farà pubblicità hg servire istanze su DNS-SD in modo che possano essere
scoperto utilizzando il hg percorsi comando senza conoscere l'indirizzo del server.
Per consentire ad altre persone di scoprire il tuo repository usando run hg servire nel tuo archivio:
$ prova cd
$ hg servire
Puoi scoprire i repository abilitati per Zeroconf eseguendo hg percorsi:
$ hg percorsi
zc-test = http://example.com:8000/prova
Usa hg online usando i servizi onworks.net
