hg - Online na nuvem

PROGRAMA:

NOME

hg - Sistema de gerenciamento de código-fonte Mercurial

SINOPSE

hg comando [opção] ... [argumento] ...

DESCRIÇÃO

A hg comando fornece uma interface de linha de comando para o sistema Mercurial.

COMANDO ELEMENTOS

arquivos...
indica um ou mais nomes de arquivo ou nomes de arquivo de caminho relativo; veja Padrões de Nome de Arquivo
para obter informações sobre correspondência de padrões

caminho indica um caminho na máquina local

revisão
indica um changeset que pode ser especificado como um número de revisão do changeset, uma tag,
ou uma substring única do valor hash do changeset

repositório caminho
o nome do caminho de um repositório local ou o URI de um repositório remoto.

OPÇÕES

-R,--repositório
diretório raiz do repositório ou nome do arquivo de pacote de sobreposição

--cwd
mudar o diretório de trabalho

- sim, --não interativo
não solicitar, escolha automaticamente a primeira escolha para todos os prompts

-q, --quieto
suprimir saída

-dentro, --verbose
habilitar saída adicional

--config
definir / substituir opção de configuração (use 'section.name = value')

--depurar
habilitar saída de depuração

--depurador
iniciar o depurador

--codificação
definir a codificação do conjunto de caracteres (padrão: UTF-8)

--modo de codificação
definir o modo de codificação do conjunto de caracteres (padrão: estrito)

--traceback
sempre imprime um traceback na exceção

--Tempo tempo quanto tempo o comando leva

--perfil
imprimir perfil de execução de comando

--versão
informações de saída da versão e sai

-h, --Socorro
exibir ajuda e sair

--escondido
considere conjuntos de alterações ocultos

A opção marcada [+] pode ser especificada várias vezes

COMANDOS

adicionar
adicione os arquivos especificados no próximo commit:

hg add [OPÇÃO] ... [ARQUIVO] ...

Agende arquivos para serem controlados por versão e adicionados ao repositório.

Os arquivos serão adicionados ao repositório no próximo commit. Para desfazer um acréscimo antes disso,
Vejo hg esquecer.

Se nenhum nome for fornecido, adicione todos os arquivos ao repositório (exceto os arquivos correspondentes .hgignore).

Exemplos:

· Novos arquivos (desconhecidos) são adicionados automaticamente por hg adicionar:

$ls
foo.c
status de $ hg
? foo.c
$ hg adicionar
adicionando foo.c
status de $ hg
Um foo.c

· Arquivos específicos a serem adicionados podem ser especificados:

$ls
bar.c foo.c
status de $ hg
? bar.c
? foo.c
$ hg adicionar bar.c
status de $ hg
Um bar.c
? foo.c

Retorna 0 se todos os arquivos forem adicionados com sucesso.

opções:

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-S, --subrepos
Recurso para subrepositórios

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

A opção marcada [+] pode ser especificada várias vezes

adicionar remover
adicione todos os novos arquivos, exclua todos os arquivos ausentes:

hg addremove [OPÇÃO] ... [ARQUIVO] ...

Adicione todos os novos arquivos e remova todos os arquivos ausentes do repositório.

A menos que nomes sejam fornecidos, os novos arquivos são ignorados se corresponderem a qualquer um dos padrões em
.hgignore. Tal como acontece com add, essas mudanças entram em vigor no próximo commit.

Use a opção -s / - similarity para detectar arquivos renomeados. Esta opção leva uma porcentagem
entre 0 (desabilitado) e 100 (os arquivos devem ser idênticos) como parâmetro. Com um parâmetro
maior que 0, isso compara cada arquivo removido com cada arquivo adicionado e registra aqueles
semelhante o suficiente como renomeia. Detectar arquivos renomeados dessa forma pode ser caro. Depois de usar
esta opção, hg estado -C pode ser usado para verificar quais arquivos foram identificados como movidos ou
renomeado. Se não for especificado, -s / - similaridade é padronizado para 100 e apenas renomeia os idênticos
arquivos são detectados.

Exemplos:

· Vários arquivos (bar.c e foo.c) são novos, enquanto foobar.c foi removido (sem
utilização hg remover) do repositório:

$ls
bar.c foo.c
status de $ hg
! foobar.c
? bar.c
? foo.c
$ hg addremove
adicionando bar.c
adicionando foo.c
removendo foobar.c
status de $ hg
Um bar.c
Um foo.c
R foobar.c

· Um arquivo foobar.c foi movido para foo.c sem usar hg rebatizar. Depois foi
editado ligeiramente:

$ls
foo.c
status de $ hg
! foobar.c
? foo.c
$ hg addremove --similaridade 90
removendo foobar.c
adicionando foo.c
gravação de remoção de foobar.c como renomear para foo.c (94% semelhante)
$hg status -C
Um foo.c
foobar.c
R foobar.c

Retorna 0 se todos os arquivos forem adicionados com sucesso.

opções:

-sim,--semelhança
suponha que arquivos renomeados por similaridade (0 <= s <= 100)

-S, --subrepos
Recurso para subrepositórios

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

A opção marcada [+] pode ser especificada várias vezes

anotada
mostrar informações do changeset por linha para cada arquivo:

hg anotar [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] ARQUIVO ...

Lista as alterações nos arquivos, mostrando o id de revisão responsável por cada linha.

Este comando é útil para descobrir quando uma mudança foi feita e por quem.

Se você incluir --file, --user ou --date, o número da revisão é suprimido a menos que você
também inclui --number.

Sem a opção -a / - text, a anotação evitará o processamento de arquivos que detecta como binários.
Com -a, annotate irá anotar o arquivo de qualquer maneira, embora os resultados provavelmente serão
nem útil nem desejável.

Retorna 0 em caso de sucesso.

opções:

-r,--rev
anotar a revisão especificada

--Segue
seguir cópias / renomear e listar o nome do arquivo (USO SUSPENSO)

--não siga
não siga cópias e renomeie

-uma, --texto
tratar todos os arquivos como texto

-você, --do utilizador
liste o autor (longo com -v)

-f, --Arquivo
liste o nome do arquivo

-d, --data
liste a data (abrevie com -q)

-n, --número
liste o número da revisão (padrão)

-c, --changeset
liste o changeset

-eu, --número da linha
mostrar o número da linha na primeira aparição

-C, --ignore-todo-espaço
ignore o espaço em branco ao comparar as linhas

-b, --ignore-espaço-mudança
ignorar as mudanças na quantidade de espaço em branco

-B, --ignore-linhas em branco
ignore as mudanças cujas linhas estão todas em branco

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-T,--modelo
exibir com modelo (EXPERIMENTAL)

A opção marcada [+] pode ser especificada várias vezes

aliases: culpa

arquivo
crie um arquivo não versionado de uma revisão do repositório:

arquivo hg [OPÇÃO] ... DEST

Por padrão, a revisão usada é o pai do diretório de trabalho; use -r / - rev para
especificar uma revisão diferente.

O tipo de arquivo é detectado automaticamente com base na extensão do arquivo (para substituir, use
-t / - tipo).

Exemplos:

· Criar um arquivo zip contendo a versão 1.0:

arquivo hg -r 1.0 projeto-1.0.zip

· Criar um tarball excluindo arquivos .hg:

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

Os tipos válidos são:

arquivos

um diretório cheio de arquivos (padrão)

alcatrão

arquivo tar, descompactado

tbz2

arquivo tar, compactado usando bzip2

tgz

arquivo tar, compactado usando gzip

uzip

arquivo zip, descompactado

zip

arquivo zip, compactado usando deflate

O nome exato do arquivo ou diretório de destino é fornecido usando uma string de formato; Vejo
hg ajudar exportar para obter detalhes.

Cada membro adicionado a um arquivo morto tem um prefixo de diretório anexado. Use o prefixo -p / - para
especifique uma string de formato para o prefixo. O padrão é o nome de base do arquivo, com
sufixos removidos.

Retorna 0 em caso de sucesso.

opções:

--sem decodificação
não passe os arquivos pelos decodificadores

-p,--prefixo
prefixo de diretório para arquivos em arquivo

-r,--rev
revisão para distribuir

-t,--modelo
tipo de distribuição para criar

-S, --subrepos
Recurso para subrepositórios

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

voltar
efeito reverso do conjunto de alterações anterior:

hg backout [OPÇÃO] ... [-r] REV

Prepare um novo changeset com o efeito de REV desfeito no diretório de trabalho atual. Se
nenhum conflito foi encontrado, ele será confirmado imediatamente.

Se REV for o pai do diretório de trabalho, então este novo conjunto de alterações foi confirmado
automaticamente (a menos que --no-commit seja especificado).

Note hg voltar não pode ser usado para corrigir uma mesclagem indesejada ou incorreta.

Exemplos:

· Reverter o efeito do pai do diretório de trabalho. Este backout será
cometido imediatamente:

hg backout -r.

· Reverter o efeito da revisão anterior anterior anterior 23:

hg backout -r 23

· Reverter o efeito da revisão anterior anterior inválida 23 e deixar as alterações não confirmadas:

hg backout -r 23 --no-commit
hg commit -m "Revisão 23 do backout"

Por padrão, o changeset pendente terá um pai, mantendo um histórico linear. Com
--merge, o changeset pendente terá, em vez disso, dois pais: o pai antigo do
diretório de trabalho e um novo filho de REV que simplesmente desfaz REV.

Antes da versão 1.7, o comportamento sem --merge era equivalente a especificar --merge
seguido hg atualizar --limpar . para cancelar a mesclagem e deixar o filho de REV como chefe
a ser mesclado separadamente.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

See hg ajudar reverter para ver uma maneira de restaurar os arquivos ao estado de outra revisão.

Retorna 0 em caso de sucesso, 1 se nada para restaurar ou se houver arquivos não resolvidos.

opções:

--mesclar
fundir com o antigo dirstate pai após a restauração

--comprometer-se
confirmar se nenhum conflito for encontrado (DESCONTINUADO)

--sem compromisso
não se comprometa

--pai
pai para escolher ao desfazer a mesclagem (DESCONTINUADO)

-r,--rev
revisão para retroceder

-e --editar
invocar editor em mensagens de confirmação

-t,--ferramenta
especificar ferramenta de mesclagem

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

A opção marcada [+] pode ser especificada várias vezes

cortar
pesquisa de subdivisão de changesets:

hg bissecção [-gbsr] [-U] [-c CMD] [REV]

Este comando ajuda a encontrar conjuntos de alterações que apresentam problemas. Para usar, marque o mais antigo
conjunto de alterações que você conhece exibe o problema como ruim, então marque o conjunto de alterações mais recente que é
livre do problema tão bom. Bisect irá atualizar seu diretório de trabalho para uma revisão para
teste (a menos que a opção -U / - noupdate seja especificada). Depois de realizar os testes,
marcar o diretório de trabalho como bom ou ruim, e bisect irá atualizar para outro
candidato changeset ou anunciar que encontrou a revisão incorreta.

Como um atalho, você também pode usar o argumento de revisão para marcar uma revisão como boa ou ruim
sem verificar primeiro.

Se você fornecer um comando, ele será usado para bissecção automática. O ambiente
a variável HG_NODE conterá o ID do changeset que está sendo testado. O status de saída do
comando será usado para marcar as revisões como boas ou ruins: status 0 significa bom, 125 significa
pular a revisão, 127 (comando não encontrado) abortará a bissecção, e qualquer outro
status de saída diferente de zero significa que a revisão é ruim.

Alguns exemplos:

· Iniciar uma bissecção com a revisão 34 conhecida e boa revisão 12:

hg bisect --ruim 34
hg bisect - good 12

· Avançar a bissecção atual marcando a revisão atual como boa ou má:

hg bisect --bom
hg bisect --ruim

· Marcar a revisão atual, ou uma revisão conhecida, a ser ignorada (por exemplo, se essa revisão for
não utilizável devido a outro problema):

hg bisect --pular
hg bisect --pular 23

· Pular todas as revisões que não afetam os diretórios Foo or Barra:

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

· Esquecer a bissecção atual:

hg bisect --reset

· Use 'make && make tests' para encontrar automaticamente a primeira revisão quebrada:

hg bisect --reset
hg bisect --ruim 34
hg bisect - good 12
hg bisect --command "make && make tests"

· Ver todos os changesets cujos estados já são conhecidos na bissecção atual:

hg log -r "bisect (podado)"

· Ver o changeset atualmente sendo dividido ao meio (especialmente útil se estiver executando com
-U / - nupdate):

hg log -r "bisect (atual)"

· Ver todos os changesets que participaram da bissecção atual:

hg log -r "bisect (intervalo)"

· Você pode até obter um bom gráfico:

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

See hg ajudar reviravoltas para mais sobre o bisect () palavra chave.

Retorna 0 em caso de sucesso.

opções:

-r, --Redefinir
redefinir estado bisect

-g, --Boa
marcar o conjunto de mudanças como bom

-b, --mau
marcar o conjunto de mudanças como ruim

-sim, --pular
pular o conjunto de mudanças de teste

-e --ampliar
estenda o intervalo da bissetriz

-c,--comando
use o comando para verificar o estado do changeset

-VOCÊ, --sem atualização
não atualize para o alvo

bookmarks
crie um novo favorito ou liste os favoritos existentes:

favoritos hg [OPÇÕES] ... [NOME] ...

Marcadores são rótulos em changesets para ajudar a rastrear linhas de desenvolvimento. Marcadores são
sem versão e pode ser movido, renomeado e excluído. Excluir ou mover um favorito não tem
efeito sobre os changesets associados.

A criação ou atualização de um favorito faz com que ele seja marcado como 'ativo'. O ativo
o marcador é indicado com um '*'. Quando um commit é feito, o favorito ativo irá avançar
para o novo commit. Um plano hg atualizar também avançará um marcador ativo, se possível.
A atualização longe de um favorito fará com que ele seja desativado.

Os favoritos podem ser empurrados e puxados entre os repositórios (ver hg ajudar empurrar e hg ajudar puxar
) Se um marcador compartilhado divergiu, um novo 'marcador divergente' da forma 'nome @ caminho'
Será criado. Usando hg fundir irá resolver a divergência.

Um favorito chamado '@' tem a propriedade especial de hg clonar irá verificar por padrão
se existe.

Exemplos:

· Criar um marcador ativo para uma nova linha de desenvolvimento:

novo recurso livro hg

· Criar um favorito inativo como um marcador de lugar:

hg livro -i resenhado

· Criar um marcador inativo em outro changeset:

livro hg -r. ^ testado

· Renomear o favorito de peru para jantar:

hg book -m jantar de peru

· Mover o marcador '@' de outro ramo:

hg livro -f @

opções:

-f, --força
força

-r,--rev
revisão para ação de marcador

-d, --excluir
deletar um determinado favorito

-m,--renomear
renomear um determinado favorito

-eu, --inativo
marcar um favorito como inativo

-T,--modelo
exibir com modelo (EXPERIMENTAL)

aliases: marcador

ramo
definir ou mostrar o nome do branch atual:

ramo hg [-fC] [NOME]

Nota Os nomes das filiais são permanentes e globais. Usar hg marcador para criar um peso leve
marcador em vez disso. Ver hg ajudar glossário para mais informações sobre ramos nomeados
e marcadores.

Sem nenhum argumento, mostra o nome do branch atual. Com um argumento, defina o funcionamento
nome do branch do diretório (o branch não existirá no repositório até o próximo commit).
A prática padrão recomenda que o desenvolvimento primário ocorra no branch 'padrão'.

A menos que -f / - force seja especificado, branch não permitirá que você defina um nome de branch que já
existe.

Use -C / - clean para redefinir o branch do diretório de trabalho para o pai do diretório de trabalho
diretório, negando uma alteração de branch anterior.

Use o comando hg atualizar para mudar para uma ramificação existente. Usar hg commit --filial próximo para
marque esta cabeça de ramo como fechada. Quando todos os chefes de uma filial são fechados, a filial irá
ser considerado fechado.

Retorna 0 em caso de sucesso.

opções:

-f, --força
definir o nome do ramo mesmo que sombreie um ramo existente

-C, --limpar
redefinir o nome da filial para o nome da filial principal

ramos
listar repositório denominado branches:

ramos hg [-c]

Liste os ramos nomeados do repositório, indicando quais estão inativos. Se -c / - fechado
é especificado, também lista os ramos que foram marcados como fechados (ver hg commit
--filial próximo).

Use o comando hg atualizar para mudar para uma ramificação existente.

Retorna 0.

opções:

-uma, --ativo
mostrar apenas branches que têm cabeçotes não mesclados (DESCONTINUADO)

-c, --fechado
mostrar ramos normais e fechados

-T,--modelo
exibir com modelo (EXPERIMENTAL)

empacotar
crie um arquivo de grupo de mudanças:

pacote hg [-f] [-t TYPE] [-a] [-r REV] ... [--base REV] ... ARQUIVO [DEST]

Gere um arquivo changegroup coletando conjuntos de alterações a serem adicionados a um repositório.

Para criar um pacote contendo todos os conjuntos de alterações, use -a / - all (ou --base null). Caso contrário, hg
assume que o destino terá todos os nós que você especificar com os parâmetros --base.
Caso contrário, hg irá assumir que o repositório tem todos os nós no destino, ou
default-push / default se nenhum destino for especificado.

Você pode alterar o formato do pacote com a opção -t / - type. Você pode especificar uma compressão, um
versão do pacote ou ambos usando um traço (versão comp). Os métodos de compressão disponíveis são:
none, bzip2 e gzip (por padrão, os pacotes são compactados usando bzip2). O disponível
os formatos são: v1, v2 (padrão para mais adequado).

O arquivo do pacote pode então ser transferido usando meios convencionais e aplicado a outro
repositório com o comando unbundle ou pull. Isso é útil quando o push e pull direto são
não disponível ou quando exportar um repositório inteiro é indesejável.

A aplicação de bundles preserva todo o conteúdo do changeset, incluindo permissões, copiar / renomear
informações e histórico de revisão.

Retorna 0 em caso de sucesso, 1 se nenhuma alteração for encontrada.

opções:

-f, --força
correr mesmo quando o destino não está relacionado

-r,--rev
um changeset destinado a ser adicionado ao destino

-b,--filial
um branch específico que você gostaria de agrupar

--base
um conjunto de alterações de base assumido como disponível no destino

-uma, --tudo
agrupar todos os conjuntos de alterações no repositório

-t,--modelo
tipo de compactação de pacote a ser usado (padrão: bzip2)

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

gato
produza a revisão atual ou dada dos arquivos:

hg cat [OPÇÃO] ... ARQUIVO ...

Imprime os arquivos especificados como estavam na revisão fornecida. Se nenhuma revisão for fornecida, o
pai do diretório de trabalho é usado.

A saída pode ser para um arquivo, caso em que o nome do arquivo é fornecido usando um formato
fragmento. As regras de formatação são as seguintes:

%%

caractere literal "%"

%s

nome de base do arquivo sendo impresso

%d

dirname do arquivo que está sendo impresso ou '.' se na raiz do repositório

%p

nome do caminho relativo à raiz do arquivo sendo impresso

%H

hash de conjunto de alterações (40 dígitos hexadecimais)

%R

número de revisão do changeset

%h

hash de changeset abreviado (12 dígitos hexadecimais)

%r

número de revisão do changeset com zeros

%b

nome de base do repositório de exportação

Retorna 0 em caso de sucesso.

opções:

-ó,--resultado
imprimir saída para arquivo com nome formatado

-r,--rev
imprimir a revisão dada

--decodificar
aplique qualquer filtro de decodificação correspondente

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

clonar
faça uma cópia de um repositório existente:

clone hg [OPÇÃO] ... FONTE [DEST]

Crie uma cópia de um repositório existente em um novo diretório.

Se nenhum nome de diretório de destino for especificado, o padrão será o nome de base da origem.

A localização da fonte é adicionada ao novo repositório .hg / hgrc arquivo, como o padrão
para ser usado para puxões futuros.

Apenas caminhos locais e ssh: // URLs são suportados como destinos. Para ssh: // destinos,
nenhum diretório de trabalho ou .hg / hgrc será criado no lado remoto.

Se o repositório de origem tiver um marcador chamado '@' definido, essa revisão será retirada
no novo repositório por padrão.

Para verificar uma versão específica, use -u / - update ou -U / - noupdate para criar um clone
sem diretório de trabalho.

Para obter apenas um subconjunto de changesets, especifique um ou mais identificadores de revisão com
-r / - rev ou branches com -b / - branch. O clone resultante conterá apenas o
changesets e seus ancestrais. Essas opções (ou 'clone src # rev dest') implicam --pull, até mesmo
para repositórios de origem local.

Nota A especificação de uma tag incluirá o changeset marcado, mas não o changeset que contém
a etiqueta.

Para maior eficiência, hardlinks são usados ​​para clonagem sempre que a origem e o destino estão ativados
o mesmo sistema de arquivos (observe que isso se aplica apenas aos dados do repositório, não ao
diretório). Alguns sistemas de arquivos, como AFS, implementam hardlinking incorretamente, mas não
relatar erros. Nestes casos, use a opção --pull para evitar hardlinking.

Em alguns casos, você pode clonar repositórios e o diretório de trabalho usando hardlinks completos
com

$ cp -al REPO REPOCLONE

Essa é a maneira mais rápida de clonar, mas nem sempre é segura. A operação não é atômica
(certificar-se de que REPO não seja modificado durante a operação depende de você) e você deve fazer
certifique-se de que seu editor rompe os hardlinks (o Emacs e a maioria das ferramentas do kernel do Linux fazem isso). Além disso, este é
não é compatível com certas extensões que colocam seus metadados no diretório .hg,
como mq.

O Mercurial irá atualizar o diretório de trabalho para a primeira revisão aplicável deste
Lista:

uma. nulo se -U ou o repositório de origem não tem conjuntos de alterações

b. se você . e o repositório de origem é local, o primeiro pai do repositório de origem
diretório de trabalho

c. o conjunto de alterações especificado com -u (se for um nome de branch, isso significa o último cabeçalho daquele
filial)

d. o conjunto de alterações especificado com -r

e. a cabeça mais inclinada especificada com -b

f. o cabeçote mais avançado especificado com a sintaxe de origem url # branch

g. a revisão marcada com o marcador '@', se presente

h. a cabeça mais avançada do ramo padrão

eu. gorjeta

Ao clonar de servidores que o suportam, o Mercurial pode buscar dados pré-gerados de um
URL anunciado pelo servidor. Quando isso é feito, os ganchos operam nos changesets de entrada e
changegroups podem disparar duas vezes, uma para o pacote obtido da URL e outra para qualquer
dados adicionais não obtidos deste URL. Além disso, se ocorrer um erro, o repositório
pode ser revertido para um clone parcial. Este comportamento pode mudar em versões futuras. Ver hg
ajudar -e clonebundles para mais.

Exemplos:

· Clonar um repositório remoto para um novo diretório chamado hg /:

clone hg http://selenic.com/hg

· Criar um clone local leve:

hg clone project / project-feature /

· Clone de um caminho absoluto em um servidor ssh (observe barra dupla):

hg clone ssh: // usuário @ servidor // home / projects / alpha /

· Fazer um clone de alta velocidade em uma LAN enquanto verifica uma versão especificada:

clone hg - não compactado http://server/repo -u 1.5

· Criar um repositório sem changesets após uma revisão particular:

clone hg -r 04e544 experimental / bom /

· Clonar (e rastrear) um determinado ramo nomeado:

clone hg http://selenic.com/hg#estábulo

See hg ajudar URLs para obter detalhes sobre a especificação de URLs.

Retorna 0 em caso de sucesso.

opções:

-VOCÊ, --sem atualização
o clone incluirá um diretório de trabalho vazio (apenas um repositório)

-você,--updaterev
revisão, etiqueta ou ramificação para verificar

-r,--rev
inclui o changeset especificado

-b,--filial
clonar apenas o ramo especificado

--puxar use o protocolo pull para copiar metadados

- não comprimido
usar transferência descompactada (rápido pela LAN)

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

commit
confirmar os arquivos especificados ou todas as alterações pendentes:

hg commit [OPÇÃO] ... [ARQUIVO] ...

Confirme as alterações nos arquivos fornecidos no repositório. Ao contrário de um SCM centralizado, este
operação é uma operação local. Ver hg empurrar para obter uma maneira de distribuir ativamente suas alterações.

Se uma lista de arquivos for omitida, todas as alterações relatadas por hg estado será cometido.

Se você está confirmando o resultado de uma fusão, não forneça nenhum nome de arquivo ou -I / -X
filtros.

Se nenhuma mensagem de confirmação for especificada, o Mercurial inicia seu editor configurado onde você pode
digite uma mensagem. Caso seu commit falhe, você encontrará um backup de sua mensagem em
.hg / last-message.txt.

O sinalizador --close-branch pode ser usado para marcar o cabeçalho do branch atual fechado. Quando todas as cabeças
de uma filial forem encerradas, a filial será considerada encerrada e não será mais listada.

O sinalizador --amend pode ser usado para emendar o pai do diretório de trabalho com um novo
commit que contém as mudanças no pai, além daquelas atualmente relatadas por
hg estado, se houver algum. O antigo commit é armazenado em um pacote de backup em
.hg / strip-backup (Vejo hg ajudar empacotar e hg ajudar descompactar sobre como restaurá-lo).

A mensagem, o usuário e a data são retirados do commit alterado, a menos que especificado. Quando uma mensagem
não for especificado na linha de comando, o editor será aberto com a mensagem do alterado
comprometer-se.

Não é possível alterar conjuntos de alterações públicos (consulte hg ajudar fases) ou changesets que têm
crianças.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

Retorna 0 em caso de sucesso, 1 se nada mudou.

Exemplos:

· Confirmar todos os arquivos que terminam em .py:

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

· Confirmar todos os arquivos não binários:

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

· Alterar o commit atual e definir a data para agora:

hg commit --amend --date agora

opções:

-UMA, --addremove
marque os arquivos novos / ausentes como adicionados / removidos antes de confirmar

--filial próximo
marcar uma cabeça de ramo como fechada

- alterar
alterar o pai do diretório de trabalho

-sim, --segredo
use a fase secreta para comprometer

-e --editar
invocar editor em mensagens de confirmação

-eu, --interativo
use o modo interativo

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

apelidos: ci

configuração
mostre as configurações combinadas de todos os arquivos hgrc:

hg config [-u] [NOME] ...

Sem argumentos, imprime nomes e valores de todos os itens de configuração.

Com um argumento do formulário section.name, imprime apenas o valor desse item de configuração.

Com vários argumentos, imprime nomes e valores de todos os itens de configuração com a seção correspondente
nomes.

Com --edit, inicie um editor no arquivo de configuração de nível de usuário. Com --global, edite o
arquivo de configuração de todo o sistema. Com --local, edite o arquivo de configuração de nível de repositório.

Com --debug, a fonte (nome do arquivo e número da linha) é impressa para cada item de configuração.

See hg ajudar configuração para obter mais informações sobre os arquivos de configuração.

Retorna 0 em caso de sucesso, 1 se NAME não existir.

opções:

-você, - não confiável
mostrar opções de configuração não confiáveis

-e --editar
editar configuração do usuário

-eu, --local
editar configuração do repositório

-g, --global
editar configuração global

apelidos: showconfig debugconfig

cópia
marque os arquivos como copiados para o próximo commit:

cópia hg [OPÇÃO] ... [FONTE] ... DEST

Marque dest como tendo cópias dos arquivos de origem. Se dest é um diretório, as cópias são colocadas nesse
diretório. Se dest for um arquivo, a fonte deve ser um único arquivo.

Por padrão, este comando copia o conteúdo dos arquivos conforme existem no
diretório. Se invocado com -A / - depois, a operação é gravada, mas nenhuma cópia é
realizado.

Este comando entra em vigor na próxima confirmação. Para desfazer uma cópia antes disso, consulte hg reverter.

Retorna 0 em caso de sucesso, 1 se forem encontrados erros.

opções:

-UMA, --depois de
registre uma cópia que já ocorreu

-f, --força
copiar à força sobre um arquivo gerenciado existente

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

A opção marcada [+] pode ser especificada várias vezes

apelidos: cp

diff
repositório diff (ou arquivos selecionados):

hg diff [OPÇÃO] ... ([-c REV] | [-r REV1 [-r REV2]]) [ARQUIVO] ...

Mostra as diferenças entre as revisões dos arquivos especificados.

As diferenças entre os arquivos são mostradas usando o formato diff unificado.

Note hg diff pode gerar resultados inesperados para mesclagens, pois será o padrão para comparar
contra o primeiro changeset pai do diretório de trabalho se nenhuma revisão for
Especificadas.

Quando dois argumentos de revisão são fornecidos, as alterações são mostradas entre essas revisões. Se
apenas uma revisão é especificada, então essa revisão é comparada ao diretório de trabalho,
e, quando nenhuma revisão é especificada, os arquivos do diretório de trabalho são comparados com seus
primeiro pai.

Alternativamente, você pode especificar -c / - change com uma revisão para ver as mudanças naquele
conjunto de alterações em relação ao seu primeiro pai.

Sem a opção -a / - text, diff evitará gerar diffs de arquivos que detecta como
binário. Com -a, o diff irá gerar um diff de qualquer maneira, provavelmente com resultados indesejáveis.

Use a opção -g / - git para gerar diffs no formato de diff estendido git. Para mais
informação, leia hg ajudar diferenças.

Exemplos:

· Comparar um arquivo no diretório de trabalho atual com seu pai:

hg diff foo.c

· Comparar duas versões históricas de um diretório, com informações de renomeação:

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

· Obter estatísticas de mudança em relação à última mudança em alguma data:

hg diff --stat -r "data ('2 de maio')"

· Diff todos os arquivos recém-adicionados que contêm uma palavra-chave:

hg diff "set: Added () and grep (GNU)"

· Comparar uma revisão e seus pais:

hg diff -c 9353 # comparar com o primeiro progenitor
hg diff -r 9353 ^: 9353 # mesmo usando a sintaxe revset
hg diff -r 9353 ^ 2: 9353 # compare com o segundo progenitor

Retorna 0 em caso de sucesso.

opções:

-r,--rev
revisão

-c,--mudança
mudança feita por revisão

-uma, --texto
tratar todos os arquivos como texto

-g, --git
usar formato de diff estendido git

--nodates
omitir datas de cabeçalhos de diferenças

--sem prefixo
omitir os prefixos a / eb / dos nomes dos arquivos

-p, --show-função
mostrar em qual função cada mudança está

--marcha ré
produz um diff que desfaz as mudanças

-C, --ignore-todo-espaço
ignore o espaço em branco ao comparar as linhas

-b, --ignore-espaço-mudança
ignorar as mudanças na quantidade de espaço em branco

-B, --ignore-linhas em branco
ignore as mudanças cujas linhas estão todas em branco

-VOCÊ,--unificado
número de linhas de contexto para mostrar

--Estado saída de resumo de mudanças no estilo diffstat

--raiz
produz diffs em relação ao subdiretório

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

exportar
despeje o cabeçalho e diffs para um ou mais changesets:

exportar hg [OPÇÃO] ... [-o OUTFILESPEC] [-r] [REV] ...

Imprima o cabeçalho do changeset e diffs para uma ou mais revisões. Se nenhuma revisão for fornecida,
o pai do diretório de trabalho é usado.

As informações mostradas no cabeçalho do changeset são: autor, data, nome do ramo (se
não padrão), hash do changeset, pai (s) e comentário de confirmação.

Note hg exportar pode gerar uma saída diff inesperada para conjuntos de alterações de mesclagem, uma vez que irá
compare o changeset de mesclagem com seu primeiro pai apenas.

A saída pode ser para um arquivo, caso em que o nome do arquivo é fornecido usando um formato
fragmento. As regras de formatação são as seguintes:

%%

caractere literal "%"

%H

hash de conjunto de alterações (40 dígitos hexadecimais)

%N

número de patches sendo gerados

%R

número de revisão do changeset

%b

nome de base do repositório de exportação

%h

hash de changeset abreviado (12 dígitos hexadecimais)

%m

primeira linha da mensagem de confirmação (apenas caracteres alfanuméricos)

%n

número de sequência preenchido com zeros, começando em 1

%r

número de revisão do changeset com zeros

Sem a opção -a / - text, a exportação evitará a geração de diffs de arquivos que detecta como
binário. Com -a, a exportação irá gerar uma diferença de qualquer maneira, provavelmente com resultados indesejáveis.

Use a opção -g / - git para gerar diffs no formato de diff estendido git. Ver hg ajudar
diferenças para obter mais informações.

Com a opção --switch-parent, o diff será contra o segundo pai. Pode ser
útil para revisar uma mesclagem.

Exemplos:

· Use exportar e importar para transplantar uma correção de bug para o branch atual:

exportação de hg -r 9353 | importação de hg -

· Exportar todos os changesets entre duas revisões para um arquivo com informações de renomeação:

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

· Dividir as alterações de saída em uma série de patches com nomes descritivos:

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

Retorna 0 em caso de sucesso.

opções:

-ó,--resultado
imprimir saída para arquivo com nome formatado

--switch-pai
diff contra o segundo pai

-r,--rev
revisões para exportar

-uma, --texto
tratar todos os arquivos como texto

-g, --git
usar formato de diff estendido git

--nodates
omitir datas de cabeçalhos de diferenças

A opção marcada [+] pode ser especificada várias vezes

arquivos
listar arquivos rastreados:

arquivos hg [OPÇÃO] ... [PADRÃO] ...

Imprimir arquivos sob controle do Mercurial no diretório de trabalho ou revisão especificada cujo
os nomes correspondem aos padrões fornecidos (excluindo os arquivos removidos).

Se nenhum padrão for fornecido para corresponder, este comando imprime os nomes de todos os arquivos sob
Controle mercurial no diretório de trabalho.

Exemplos:

· Listar todos os arquivos no diretório atual:

arquivos hg.

· Mostra tamanhos e sinalizadores para a revisão atual:

arquivos hg -vr.

· Liste todos os arquivos chamados README:

arquivos hg -I "** / README"

· Liste todos os arquivos binários:

arquivos hg "set: binary ()"

· Encontrar arquivos contendo uma expressão regular:

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

· Pesquisar o conteúdo do arquivo rastreado com xargs e grep:

arquivos hg -0 | xargs -0 grep foo

See hg ajudar padrões e hg ajudar conjuntos de arquivos para obter mais informações sobre como especificar o arquivo
padrões.

Retorna 0 se uma correspondência for encontrada, 1 caso contrário.

opções:

-r,--rev
procure o repositório como está em REV

-0, --print0
terminar nomes de arquivos com NUL, para uso com xargs

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-T,--modelo
exibir com modelo (EXPERIMENTAL)

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

esquecer
esqueça os arquivos especificados no próximo commit:

hg esqueça [OPÇÃO] ... ARQUIVO ...

Marque os arquivos especificados para que não sejam mais rastreados após o próximo commit.

Isso remove apenas os arquivos do branch atual, não de todo o histórico do projeto, e
ele não os exclui do diretório de trabalho.

Para excluir o arquivo do diretório de trabalho, consulte hg remover.

Para desfazer um esquecimento antes do próximo commit, veja hg adicionar.

Exemplos:

· Esqueça os arquivos binários recém-adicionados:

hg esqueça "set: Added () and binary ()"

· Esquecer os arquivos que seriam excluídos por .hgignore:

hg esqueça "set: hgignore ()"

Retorna 0 em caso de sucesso.

opções:

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

enxerto
copie as alterações de outros branches para o branch atual:

enxerto hg [OPÇÃO] ... [-r REV] ... REV ...

Este comando usa a lógica de mesclagem do Mercurial para copiar mudanças individuais de outros ramos
sem mesclar ramos no gráfico de histórico. Isso às vezes é conhecido como 'backporting' ou
'apanhar cerejas'. Por padrão, o graft irá copiar o usuário, data e descrição da fonte
conjuntos de alterações.

Conjuntos de alterações que são ancestrais da revisão atual, que já foram enxertados ou
que são mesclagens serão ignoradas.

Se --log for especificado, as mensagens de log terão um comentário anexado no formato:

(enxertado de CHANGESETHASH)

Se --force for especificado, as revisões serão enxertadas mesmo se já forem ancestrais de
ou foram enxertados no destino. Isso é útil quando as revisões desde
foi retirado.

Se uma fusão de enxerto resultar em conflitos, o processo de enxerto é interrompido para que o
a fusão atual pode ser resolvida manualmente. Uma vez que todos os conflitos são resolvidos, o enxerto
o processo pode ser continuado com a opção -c / - continue.

Nota A opção -c / - continue não reaplica as opções anteriores, exceto para --force.

Exemplos:

· Copiar uma única mudança para o branch estável e editar sua descrição:

atualização estável do hg
enxerto hg --edit 9393

· Enxertar uma série de changesets com uma exceção, atualizando as datas:

hg graft -D "2085 :: 2093 e não 2091"

· Continuar um enxerto depois de resolver os conflitos:

hg enxerto -c

· Mostrar a fonte de um changeset enxertado:

hg log --debug -r.

· Mostrar revisões classificadas por data:

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

See hg ajudar revisões e hg ajudar reviravoltas para mais informações sobre como especificar revisões.

Retorna 0 na conclusão bem-sucedida.

opções:

-r,--rev
revisões para enxerto

-c, --Prosseguir
retomar o enxerto interrompido

-e --editar
invocar editor em mensagens de confirmação

--registro anexar informações de enxerto à mensagem de registro

-f, --força
enxerto de força

-D, --data atual
registre a data atual como data de confirmação

-VOCÊ, --usuário atual
registrar o usuário atual como committer

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

-t,--ferramenta
especificar ferramenta de mesclagem

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

A opção marcada [+] pode ser especificada várias vezes

grep
procure um padrão em arquivos e revisões especificados:

hg grep [OPÇÃO] ... PADRÃO [ARQUIVO] ...

Pesquise revisões de arquivos para uma expressão regular.

Este comando se comporta de maneira diferente do grep do Unix. Ele só aceita expressões regulares Python / Perl. Isto
pesquisa o histórico do repositório, não o diretório de trabalho. Sempre imprime a revisão
número em que uma correspondência aparece.

Por padrão, grep apenas imprime a saída para a primeira revisão de um arquivo no qual ele encontra um
partida. Para fazer com que ele imprima todas as revisões que contenham uma mudança no status da partida ("-" para um
correspondência que se torna uma não correspondência ou "+" para uma não correspondência que se torna uma correspondência), use o
--todos os sinalizadores.

Retorna 0 se uma correspondência for encontrada, 1 caso contrário.

opções:

-0, --print0
campos finais com NUL

--tudo imprimir todas as revisões que correspondem

-uma, --texto
tratar todos os arquivos como texto

-f, --Segue
siga o histórico do changeset ou o histórico do arquivo entre cópias e renomeações

-eu, --ignorar caso
ignorar maiúsculas e minúsculas ao combinar

-eu, --arquivos com correspondências
imprimir apenas nomes de arquivos e revisões que correspondam

-n, --número da linha
imprimir números de linha correspondentes

-r,--rev
apenas arquivos de pesquisa alterados dentro do intervalo de revisão

-você, --do utilizador
liste o autor (longo com -v)

-d, --data
liste a data (abrevie com -q)

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

cabeças
mostrar cabeças de filiais:

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

Sem argumentos, mostra todos os cabeçalhos de ramificação abertos no repositório. Chefes de filial são
changesets que não possuem descendentes no mesmo branch. Eles estão onde o desenvolvimento
geralmente ocorre e são os alvos usuais para as operações de atualização e mesclagem.

Se um ou mais REVs forem fornecidos, abra apenas os cabeçotes de ramificação nas ramificações associadas ao
changesets especificados são mostrados. Isso significa que você pode usar hg cabeças . para ver as cabeças
o branch atualmente em check-out.

Se -c / - fechado for especificado, também mostra os cabeçotes de ramificação marcados como fechados (consulte hg commit
--filial próximo).

Se STARTREV for especificado, apenas as cabeças que são descendentes de STARTREV serão
exibido.

Se -t / - topo for especificado, a mecânica do ramo nomeado será ignorada e apenas topológica
heads (changesets sem filhos) serão mostrados.

Retorna 0 se cabeças correspondentes forem encontradas, 1 se não forem.

opções:

-r,--rev
mostrar apenas cabeças que são descendentes de STARTREV

-t, --topo
mostrar apenas cabeças topológicas

-uma, --ativo
mostrar branchheads ativos apenas (DESCONTINUADO)

-c, --fechado
mostrar cabeças de ramificação normais e fechadas

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

ajudar
mostre a ajuda para um determinado tópico ou uma visão geral da ajuda:

hg ajuda [-ecks] [TOPIC]

Sem argumentos, imprime uma lista de comandos com mensagens curtas de ajuda.

Dado um tópico, extensão ou nome de comando, imprima a ajuda para esse tópico.

Retorna 0 se for bem-sucedido.

opções:

-e --extensão
mostrar apenas ajuda para extensões

-c, --comando
mostrar apenas ajuda para comandos

-k, --palavra-chave
mostrar tópicos que correspondem a palavras-chave

-sim,--sistema
mostrar ajuda para plataforma (s) específica (s)

A opção marcada [+] pode ser especificada várias vezes

identificar
identificar o diretório de trabalho ou revisão especificada:

hg identificar [-nibtB] [-r REV] [FONTE]

Imprime um resumo identificando o estado do repositório em REV usando um ou dois hash pai
identificadores, seguido por um "+" se o diretório de trabalho tiver alterações não confirmadas, o
nome do ramo (se não for o padrão), uma lista de marcas e uma lista de favoritos.

Quando REV não é fornecido, imprime um resumo do estado atual do repositório.

Especificar um caminho para uma raiz de repositório ou pacote Mercurial fará com que o lookup opere
esse repositório / pacote.

Exemplos:

· Gerar um identificador de compilação para o diretório de trabalho:

hg id --id> build-id.dat

· Encontrar a revisão correspondente a uma tag:

hg id -n -r 1.3

· Verificar a revisão mais recente de um repositório remoto:

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

See hg log para gerar mais informações sobre revisões específicas, incluindo hash completo
identificadores.

Retorna 0 se for bem-sucedido.

opções:

-r,--rev
identificar a revisão especificada

-n, --num
mostrar número de revisão local

-eu, --Eu iria
mostrar id de revisão global

-b, --filial
mostrar ramo

-t, --Tag
mostrar tags

-B, --favoritos
mostrar favoritos

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

apelidos: id

importar
importe um conjunto ordenado de patches:

hg import [OPTION] ... PATCH ...

Importe uma lista de patches e envie-os individualmente (a menos que --no-commit seja especificado).

Para ler um patch da entrada padrão, use "-" como o nome do patch. Se um URL for especificado, o
patch será baixado de lá.

Import primeiro aplica as mudanças ao diretório de trabalho (a menos que --bypass seja especificado),
a importação será abortada se houver alterações pendentes.

Use --bypass para aplicar e enviar patches diretamente para o repositório, sem afetar o
diretório de trabalho. Sem --exact, os patches serão aplicados na parte superior do trabalho
revisão pai do diretório.

Você pode importar um patch diretamente de uma mensagem de e-mail. Até mesmo patches como anexos funcionam (para
usar a parte do corpo, deve ter tipo text / plain ou text / x-patch). De e cabeçalhos de assunto
de mensagem de e-mail são usados ​​como committer padrão e mensagem de confirmação. Todo o texto / corpo simples
partes antes do primeiro diff são adicionadas à mensagem de confirmação.

Se o patch importado foi gerado por hg exportar, usuário e descrição da substituição do patch
valores dos cabeçalhos e corpo da mensagem. Valores fornecidos na linha de comando com -m / - mensagem e
-u / - o usuário substitui estes.

Se --exact for especificado, import irá definir o diretório de trabalho para o pai de cada patch
antes de aplicá-lo, e será abortado se o changeset resultante tiver um ID diferente do
um gravado no patch. Isso pode acontecer devido a problemas de conjunto de caracteres ou outros
deficiências no formato do patch de texto.

Use --partial para garantir que um changeset seja criado a partir do patch, mesmo se alguns blocos falharem
aplicar. Os itens que não se aplicam serão gravados em um arquivo .rej. Conflitos
pode então ser resolvido manualmente antes hg commit - alterar é executado para atualizar o criado
conjunto de mudanças. Este sinalizador existe para permitir que as pessoas importem patches que se aplicam parcialmente, sem
perder os metadados associados (autor, data, descrição, ...).

Nota Quando nenhum pedaço se aplica de forma limpa, hg importar --parcial irá criar um changeset vazio,
importando apenas os metadados do patch.

Com -s / - similarity, hg tentará descobrir renomeações e cópias no patch no
da mesma forma que hg adicionar remover.

É possível usar programas de patch externos para realizar o patch configurando o ui.patch
opção de configuração. Para a ferramenta interna padrão, o fuzz também pode ser configurado via
patch.fuzz. Ver hg ajudar configuração para obter mais informações sobre os arquivos de configuração e como
use essas opções.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

Exemplos:

· Importar um patch tradicional de um site e detectar renomeações:

hg importação -s 80 http://example.com/bugfix.patch

· Importar um changeset de um servidor hgweb:

importação de hg http://www.selenic.com/hg/rev/5ca8c111e9aa

· Importar todos os patches em uma mbox estilo Unix:

hg import appear-patches.mbox

· Tentar restaurar exatamente um changeset exportado (nem sempre possível):

hg import --exact proposto-fix.patch

· Usar uma ferramenta externa para aplicar um patch que é muito difuso para a ferramenta interna padrão.

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

· Alterar o fuzzing padrão de 2 para um menos estrito 7

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

Retorna 0 em caso de sucesso, 1 em sucesso parcial (consulte --parcial).

opções:

-p,--faixa
opção de faixa de diretório para patch. Isso tem o mesmo significado que o correspondente
opção de patch (padrão: 1)

-b,--base
caminho de base (DESCONTINUADO)

-e --editar
invocar editor em mensagens de confirmação

-f, --força
ignorar a verificação de alterações não confirmadas pendentes (USO SUSPENSO)

--sem compromisso
não cometa, apenas atualize o diretório de trabalho

--desviar
aplicar patch sem tocar no diretório de trabalho

--parcial
cometa mesmo que alguns pedaços falhem

--exato
aplicar patch aos nós dos quais foi gerado

--prefixo
aplicar patch ao subdiretório

--import-branch
usar qualquer informação de branch no patch (implícito por --exact)

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

-sim,--semelhança
suponha que arquivos renomeados por similaridade (0 <= s <= 100)

apelido: patch

entrada
mostrar novos conjuntos de alterações encontrados na fonte:

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

Mostra os novos changesets encontrados no caminho / URL especificado ou no local de recebimento padrão. Esses
são os changesets que teriam sido puxados se um pull no momento em que você emitiu este
comando.

Veja pull para detalhes de formato de fonte válido.

Com marcadores -B / -, o resultado da comparação de marcadores entre locais e remotos
repositórios é exibido. Com -v / - verbose, o status também é exibido para cada favorito
como abaixo:

BM1 01234567890a adicionado
BM2 1234567890ab avançado
BM3 234567890abc divergiu
BM4 34567890abcd alterado

A ação realizada localmente ao puxar depende do status de cada favorito:

adicionado

puxar irá criar

avançado

pull irá atualizá-lo

divergiu

puxar irá criar um favorito divergente

mudado

o resultado depende de conjuntos de mudanças remotos

Do ponto de vista do comportamento de puxar, marcador existente apenas no controle remoto
repositório são tratados como adicionado, mesmo que seja de fato excluído localmente.

Para repositório remoto, usar --bundle evita baixar os changesets duas vezes se o
a entrada é seguida por um puxão.

Exemplos:

· Mostrar as mudanças recebidas com patches e descrição completa:

hg entrando -vp

· Mostrar as mudanças recebidas, excluindo fusões, armazenar um pacote:

hg em -vpM --bundle coming.hg
hg pull coming.hg

· Listar resumidamente as mudanças dentro de um pacote:

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

Retorna 0 se houver mudanças de entrada, 1 caso contrário.

opções:

-f, --força
executado mesmo se o repositório remoto não estiver relacionado

-n, --Os mais novos primeiro
mostrar o recorde mais recente primeiro

--agrupar
arquivo para armazenar os pacotes em

-r,--rev
um changeset remoto destinado a ser adicionado

-B, --favoritos
comparar favoritos

-b,--filial
um branch específico que você gostaria de puxar

-p, --correção
mostrar patch

-g, --git
usar formato de diff estendido git

-eu,--limite
número limite de alterações exibidas

-M, --sem mesclas
não mostrar mesclagens

--Estado saída de resumo de mudanças no estilo diffstat

-G, --gráfico
mostrar a revisão DAG

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

aliases: em

o init
crie um novo repositório no diretório fornecido:

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

Inicialize um novo repositório no diretório fornecido. Se o diretório fornecido não existir,
será criado.

Se nenhum diretório for fornecido, o diretório atual será usado.

É possível especificar um ssh: // URL como destino. Ver hg ajudar URLs para mais
informações.

Retorna 0 em caso de sucesso.

opções:

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

localizar
localizar arquivos que correspondam a padrões específicos (DESCONTINUADO):

hg localizar [OPÇÃO] ... [PADRÃO] ...

Imprime arquivos sob controle do Mercurial no diretório de trabalho cujos nomes correspondem ao dado
padrões.

Por padrão, este comando pesquisa todos os diretórios no diretório de trabalho. Para pesquisar apenas
o diretório atual e seus subdiretórios, use "--include.".

Se nenhum padrão for fornecido para corresponder, este comando imprime os nomes de todos os arquivos sob
Controle mercurial no diretório de trabalho.

Se você deseja alimentar a saída deste comando no comando "xargs", use a opção -0
para este comando e "xargs". Isso evitará o problema de "xargs" tratar
nomes de arquivos que contêm espaços em branco como vários nomes de arquivos.

See hg ajudar arquivos para um comando mais versátil.

Retorna 0 se uma correspondência for encontrada, 1 caso contrário.

opções:

-r,--rev
procure o repositório como está em REV

-0, --print0
terminar nomes de arquivos com NUL, para uso com xargs

-f, --caminho completo
imprimir caminhos completos da raiz do sistema de arquivos

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

log
mostrar o histórico de revisão de todo o repositório ou arquivos:

log hg [OPÇÃO] ... [ARQUIVO]

Imprime o histórico de revisão dos arquivos especificados ou de todo o projeto.

Se nenhum intervalo de revisão for especificado, o padrão é dica: 0 a menos que --follow seja definido, no qual
caso o diretório de trabalho pai seja usado como revisão inicial.

O histórico do arquivo é mostrado sem renomear ou copiar o histórico dos arquivos. Use -f / - siga
com um nome de arquivo para seguir o histórico de renomeações e cópias. --siga sem um nome de arquivo
só mostrará ancestrais ou descendentes da revisão inicial.

Por padrão, este comando imprime o número da revisão e id do changeset, tags, não triviais
pais, usuário, data e hora e um resumo de cada commit. Quando a opção -v / - verbose
é usado, a lista de arquivos alterados e a mensagem de confirmação completa são mostradas.

Com --graph as revisões são mostradas como um ASCII art DAG com o changeset mais recente em
o topo. 'o' é um changeset, '@' é um pai do diretório de trabalho, 'x' é obsoleto e '+'
representa uma bifurcação onde o changeset das linhas abaixo é um pai do 'o' merge em
a mesma linha.

Note hg log --correção pode gerar uma saída diff inesperada para conjuntos de alterações de mesclagem, uma vez que irá
compare apenas o changeset de mesclagem com seu primeiro pai. Além disso, apenas arquivos
diferente de AMBOS os pais aparecerá nos arquivos :.

Nota Por motivos de desempenho, hg log ARQUIVO pode omitir alterações duplicadas feitas nos ramos
e não mostrará remoções ou mudanças de modo. Para ver todas essas mudanças, use o
- interruptor removido.

Alguns exemplos:

· Changesets com descrições completas e listas de arquivos:

hg log -v

· Conjuntos de alterações ancestrais ao diretório de trabalho:

hg log -f

· Últimos 10 commits no branch atual:

hg log -l 10 -b.

· Conjuntos de alterações mostrando todas as modificações de um arquivo, incluindo remoções:

hg log - arquivo removido.c

· Todos os changesets que tocam em um diretório, com diffs, excluindo merges:

hg log -Mp lib /

· Todos os números de revisão que correspondem a uma palavra-chave:

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

· O identificador hash completo do pai do diretório de trabalho:

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

· Lista os modelos de registro disponíveis:

hg log -T lista

· Verificar se um determinado changeset está incluído em uma versão marcada:

hg log -r "a21ccf e ancestral (1.9)"

· Encontrar todos os changesets de algum usuário em um intervalo de datas:

hg log -k alice -d "maio de 2008 a julho de 2008"

· Resumo de todos os changesets após a última tag:

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

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

See hg ajudar revisões e hg ajudar reviravoltas para mais informações sobre como especificar e solicitar
revisões.

See hg ajudar modelos para mais informações sobre estilos pré-embalados e especificação de modelos personalizados.

Retorna 0 em caso de sucesso.

opções:

-f, --Segue
siga o histórico do changeset ou o histórico do arquivo entre cópias e renomeações

--seguir primeiro
siga apenas o primeiro pai dos conjuntos de alterações de mesclagem (DESCONTINUADO)

-d,--data
mostrar revisões que correspondem às especificações da data

-C, --cópias
mostrar arquivos copiados

-k,--palavra-chave
faça uma pesquisa sem distinção entre maiúsculas e minúsculas para um determinado texto

-r,--rev
mostra a revisão ou revset especificada

--removido
incluir revisões onde os arquivos foram removidos

-m, --only-merge
mostrar apenas mesclagens (DESCONTINUADO)

-você,--do utilizador
revisões cometidas pelo usuário

--só-ramo
mostrar apenas changesets dentro do branch nomeado fornecido (DESCONTINUADO)

-b,--filial
mostrar changesets dentro de um determinado branch nomeado

-P,--ameixa seca
não exibe revisão ou qualquer um de seus ancestrais

-p, --correção
mostrar patch

-g, --git
usar formato de diff estendido git

-eu,--limite
número limite de alterações exibidas

-M, --sem mesclas
não mostrar mesclagens

--Estado saída de resumo de mudanças no estilo diffstat

-G, --gráfico
mostrar a revisão DAG

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

aliases: história

manifestar
enviar a revisão atual ou dada do manifesto do projeto:

manifesto hg [-r REV]

Imprime uma lista de arquivos controlados por versão para a revisão fornecida. Se nenhuma revisão for fornecida,
o primeiro pai do diretório de trabalho é usado, ou a revisão nula se nenhuma revisão for
verificado.

Com -v, imprime permissões de arquivo, link simbólico e bits executáveis. Com --debug, imprimir arquivo
hashes de revisão.

Se a opção --all for especificada, a lista de todos os arquivos de todas as revisões é impressa. Esse
inclui arquivos excluídos e renomeados.

Retorna 0 em caso de sucesso.

opções:

-r,--rev
revisão para exibir

--tudo listar arquivos de todas as revisões

-T,--modelo
exibir com modelo (EXPERIMENTAL)

fundir
mesclar outra revisão no diretório de trabalho:

hg mesclar [-P] [[-r] REV]

O diretório de trabalho atual é atualizado com todas as mudanças feitas na revisão solicitada
desde a última revisão predecessora comum.

Os arquivos que mudaram entre os pais são marcados como alterados para o próximo commit e um
o commit deve ser executado antes que quaisquer atualizações adicionais no repositório sejam permitidas. o
próximo commit terá dois pais.

--ferramenta pode ser usado para especificar a ferramenta de mesclagem usada para mesclagens de arquivos. Ele substitui o
Variável de ambiente HGMERGE e seus arquivos de configuração. Ver hg ajudar ferramentas de fusão para
opções.

Se nenhuma revisão for especificada, o pai do diretório de trabalho é uma revisão principal, e o
o ramo atual contém exatamente um outro cabeçote, o outro cabeçote é mesclado por padrão.
Caso contrário, uma revisão explícita com a qual se fundir deve ser fornecida.

See hg ajudar resolver para obter informações sobre como lidar com conflitos de arquivos.

Para desfazer uma mesclagem não confirmada, use hg atualizar --limpar . que irá verificar uma cópia limpa de
o pai de mesclagem original, perdendo todas as alterações.

Retorna 0 em caso de sucesso, 1 se houver arquivos não resolvidos.

opções:

-f, --força
forçar uma mesclagem incluindo alterações pendentes (USO SUSPENSO)

-r,--rev
revisão para mesclar

-P, --preview
revisar as revisões para mesclar (nenhuma mesclagem é realizada)

-t,--ferramenta
especificar ferramenta de mesclagem

cessante
mostrar changesets não encontrados no destino:

hg de saída [-M] [-p] [-n] [-f] [-r REV] ... [DEST]

Mostrar changesets não encontrados no repositório de destino especificado ou no push padrão
localização. Estes são os changesets que seriam enviados se um push fosse solicitado.

Veja pull para detalhes de formatos de destino válidos.

Com marcadores -B / -, o resultado da comparação de marcadores entre locais e remotos
repositórios é exibido. Com -v / - verbose, o status também é exibido para cada favorito
como abaixo:

BM1 01234567890a adicionado
BM2 excluído
BM3 234567890abc avançado
BM4 34567890abcd divergiu
BM5 4567890abcde alterado

A ação realizada ao enviar depende do status de cada favorito:

adicionado

empurre com -B irá criá-lo

excluído

empurre com -B irá apagá-lo

avançado

push irá atualizá-lo

divergiu

empurre com -B irá atualizá-lo

mudado

empurre com -B irá atualizá-lo

Do ponto de vista do comportamento de envio, marcadores existentes apenas no controle remoto
repositório são tratados como excluído, mesmo que seja de fato adicionado remotamente.

Retorna 0 se houver alterações de saída, 1 caso contrário.

opções:

-f, --força
correr mesmo quando o destino não está relacionado

-r,--rev
um changeset destinado a ser incluído no destino

-n, --Os mais novos primeiro
mostrar o recorde mais recente primeiro

-B, --favoritos
comparar favoritos

-b,--filial
um branch específico que você gostaria de empurrar

-p, --correção
mostrar patch

-g, --git
usar formato de diff estendido git

-eu,--limite
número limite de alterações exibidas

-M, --sem mesclas
não mostrar mesclagens

--Estado saída de resumo de mudanças no estilo diffstat

-G, --gráfico
mostrar a revisão DAG

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

pseudônimos: fora

pais
mostrar os pais do diretório de trabalho ou revisão (DESCONTINUADO):

pais hg [-r REV] [FILE]

Imprima as revisões pai do diretório de trabalho. Se uma revisão é fornecida via -r / - rev, o
pai dessa revisão será impresso. Se um argumento de arquivo é fornecido, a revisão em
qual o arquivo foi alterado pela última vez (antes da revisão do diretório de trabalho ou o argumento para
--rev se fornecido) é impresso.

Este comando é equivalente a:

hg log -r "p1 () + p2 ()" ou
hg log -r "p1 (REV) + p2 (REV)" ou
hg log -r "max (:: p1 () e arquivo (FILE)) + max (:: p2 () e arquivo (FILE))" ou
hg log -r "max (:: p1 (REV) e arquivo (FILE)) + max (:: p2 (REV) e arquivo (FILE))"

See hg resumo e hg ajudar reviravoltas para obter informações relacionadas.

Retorna 0 em caso de sucesso.

opções:

-r,--rev
mostrar os pais da revisão especificada

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

caminhos
mostrar aliases para repositórios remotos:

caminhos hg [NOME]

Mostra a definição do nome do caminho simbólico NAME. Se nenhum nome for fornecido, mostra a definição de todos
nomes disponíveis.

A opção -q / - quiet suprime todas as saídas ao procurar por NOME e mostra apenas o caminho
nomes ao listar todas as definições.

Os nomes dos caminhos são definidos na seção [caminhos] do seu arquivo de configuração e em
/ etc / mercurial / hgrc. Se executado dentro de um repositório, .hg / hgrc também é usado.

Os nomes dos caminhos omissão e push-padrão têm um significado especial. Ao realizar um push ou
operação pull, eles são usados ​​como substitutos se nenhum local for especificado no
linha de comando. Quando push-padrão estiver definido, ele será usado para push e omissão será usado
para puxar; de outra forma omissão é usado como substituto para ambos. Ao clonar um repositório,
a fonte do clone é escrita como omissão in .hg / hgrc.

Note omissão e push-padrão aplicam-se a todos os inbound (por exemplo, hg entrada) e de saída
(por exemplo: hg cessante, hg email e hg empacotar) operações.

See hg ajudar URLs para obter mais informações.

Retorna 0 em caso de sucesso.

opções:

-T,--modelo
exibir com modelo (EXPERIMENTAL)

fase
definir ou mostrar o nome da fase atual:

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

Sem argumento, mostra o nome da fase da (s) revisão (ões) atual (is).

Com um de -p / - public, -d / - draft ou -s / - secret, altere o valor de fase do
revisões especificadas.

A menos que -f / - force seja especificado, hg fase não moverá o changeset de uma fase inferior para uma
fase superior. As fases são ordenadas da seguinte forma:

public <draft <secret

Retorna 0 em caso de sucesso, 1 se algumas fases não puderam ser alteradas.

(Para obter mais informações sobre o conceito de fases, consulte hg ajudar fases.)

opções:

-p, --público
definir a fase do changeset para público

-d, --esboço, projeto
definir a fase do changeset para rascunhar

-sim, --segredo
definir a fase do changeset para secreta

-f, --força
permite mover o limite para trás

-r,--rev
revisão alvo

A opção marcada [+] pode ser especificada várias vezes

puxar
extrair alterações da fonte especificada:

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

Puxe as alterações de um repositório remoto para um local.

Isso encontra todas as mudanças do repositório no caminho ou URL especificado e as adiciona a um
repositório local (o atual, a menos que -R seja especificado). Por padrão, isso não
atualize a cópia do projeto no diretório de trabalho.

Use hg entrada se você quiser ver o que teria sido adicionado por um puxão no momento em que
emitiu este comando. Se você decidir adicionar essas mudanças ao repositório, você deve
usar hg puxar -r X onde X é o último conjunto de alterações listado por hg entrada.

Se SOURCE for omitido, o caminho 'padrão' será usado. Ver hg ajudar URLs para mais
informações.

Retorna 0 em caso de sucesso, 1 se uma atualização teve arquivos não resolvidos.

opções:

-você, --atualizar
atualizar para o novo branch head se os changesets forem puxados

-f, --força
executado mesmo quando o repositório remoto não está relacionado

-r,--rev
um changeset remoto destinado a ser adicionado

-B,--marca páginas
marcador para puxar

-b,--filial
um branch específico que você gostaria de puxar

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

empurrar
push alterações para o destino especificado:

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

Envie conjuntos de alterações do repositório local para o destino especificado.

Esta operação é simétrica para puxar: é idêntica a puxar no destino
repositório do atual.

Por padrão, o push não permitirá a criação de novos cabeçotes no destino, uma vez que vários
cabeças não deixariam claro qual delas usar. Nesta situação, é recomendado
puxe e mescle antes de empurrar.

Use --new-branch se quiser permitir que o push crie um novo branch nomeado que não seja
presente no destino. Isso permite que você crie apenas um novo ramo sem forçar
outras mudanças.

Observação: cuidado extra deve ser tomado com a opção -f / - force, que irá empurrar todos os novos
cabeças em todos os ramos, uma ação que quase sempre causará confusão para
colaboradores.

Se -r / - rev for usado, a revisão especificada e todos os seus ancestrais serão enviados para o
repositório remoto.

Se o marcador -B / - for usado, a revisão marcada como favorita, seus ancestrais e o
favorito será enviado para o repositório remoto.

Por favor, veja hg ajudar URLs para detalhes importantes sobre ssh: // URLs. Se DESTINATION for
omitido, um caminho padrão será usado.

Retorna 0 se o push foi bem-sucedido, 1 se nada para empurrar.

opções:

-f, --força
empurrão de força

-r,--rev
um changeset destinado a ser incluído no destino

-B,--marca páginas
favorito para empurrar

-b,--filial
um branch específico que você gostaria de empurrar

--novo-ramo
permitir empurrar um novo ramo

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

recuperar
reverter uma transação interrompida:

hg recuperar

Recupere-se de um commit ou pull interrompido.

Este comando tenta corrigir o status do repositório após uma operação interrompida. Deveria
só será necessário quando o Mercurial o sugerir.

Retorna 0 se for bem-sucedido, 1 se nada para recuperar ou verificar falhar.

remover
remova os arquivos especificados no próximo commit:

hg remove [OPÇÃO] ... ARQUIVO ...

Agende os arquivos indicados para remoção da filial atual.

Este comando agenda os arquivos a serem removidos no próximo commit. Para desfazer uma remoção
antes disso, veja hg reverter. Para desfazer os arquivos adicionados, consulte hg esquecer.

-A / - depois pode ser usado para remover apenas arquivos que já foram excluídos, -f / - force pode
ser usado para forçar a exclusão, e -Af pode ser usado para remover arquivos da próxima revisão
sem excluí-los do diretório de trabalho.

A tabela a seguir detalha o comportamento de remover para diferentes estados de arquivo (colunas) e
combinações de opções (linhas). Os estados do arquivo são Adicionado [A], Limpar [C], Modificado [M] e
Faltando [!] (Conforme relatado por hg estado) As ações são Avisar, Remover (do ramo) e
Excluir (do disco):

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

Note hg remover nunca exclui arquivos no estado Adicionado [A] do diretório de trabalho, não
mesmo se --força é especificado.

Retorna 0 em caso de sucesso, 1 se for encontrado algum aviso.

opções:

-UMA, --depois de
exclusão de registro para arquivos perdidos

-f, --força
remover (e excluir) o arquivo, mesmo se adicionado ou modificado

-S, --subrepos
Recurso para subrepositórios

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

apelidos: rm

rebatizar
renomear arquivos; equivalente a copiar + remover:

hg renomear [OPÇÃO] ... FONTE ... DEST

Marque o destino como cópias das fontes; marque as fontes para exclusão. Se dest for um diretório, copia
são colocados nesse diretório. Se dest for um arquivo, pode haver apenas uma fonte.

Por padrão, este comando copia o conteúdo dos arquivos conforme existem no
diretório. Se invocado com -A / - depois, a operação é gravada, mas nenhuma cópia é
realizado.

Este comando entra em vigor na próxima confirmação. Para desfazer uma renomeação antes disso, consulte hg reverter.

Retorna 0 em caso de sucesso, 1 se forem encontrados erros.

opções:

-UMA, --depois de
registrar uma renomeação que já ocorreu

-f, --força
copiar à força sobre um arquivo gerenciado existente

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

A opção marcada [+] pode ser especificada várias vezes

aliases: mover mv

resolver
refazer mesclagens ou definir / visualizar o status de mesclagem de arquivos:

hg resolve [OPÇÃO] ... [ARQUIVO] ...

As fusões com conflitos não resolvidos são frequentemente o resultado de fusões não interativas usando o
interno: mesclar definição de configuração ou uma ferramenta de combinação de linha de comando como diferença3. A resolução
comando é usado para gerenciar os arquivos envolvidos em uma fusão, após hg fundir foi executado, e
antes hg commit é executado (ou seja, o diretório de trabalho deve ter dois pais). Ver hg ajudar
ferramentas de fusão para obter informações sobre como configurar ferramentas de mesclagem.

O comando resolve pode ser usado das seguintes maneiras:

· hg resolver [--ferramenta FERRAMENTA] ARQUIVO...: tentativa de mesclar novamente os arquivos especificados, descartando
quaisquer tentativas de mesclagem anteriores. A nova fusão não é realizada para arquivos já marcados como
resolvido. Usar --todos / -a para selecionar todos os arquivos não resolvidos. --ferramenta pode ser usado para especificar o
ferramenta de mesclagem usada para os arquivos fornecidos. Ele substitui a variável de ambiente HGMERGE e
seus arquivos de configuração. O conteúdo do arquivo anterior é salvo com um .orig sufixo.

· hg resolver -m [ARQUIVO]: marca um arquivo como tendo sido resolvido (por exemplo, depois de manualmente
consertou os arquivos). O padrão é marcar todos os arquivos não resolvidos.

· hg resolver -u [ARQUIVO]...: marca um arquivo como não resolvido. O padrão é marcar tudo resolvido
arquivos.

· hg resolver -l: lista os arquivos que tiveram ou ainda têm conflitos. Na lista impressa, U =
não resolvido e R = resolvido.

Nota O Mercurial não permitirá que você envie arquivos com conflitos de mesclagem não resolvidos. Você deve
usar hg resolver -m ... antes de enviar após uma mesclagem conflitante.

Retorna 0 em caso de sucesso, 1 se algum arquivo falhar na tentativa de resolução.

opções:

-uma, --tudo
selecione todos os arquivos não resolvidos

-eu, --Lista
estado da lista de arquivos que precisam ser mesclados

-m, --marca
marcar arquivos como resolvidos

-você, --desmarcar
marcar arquivos como não resolvidos

-n, --sem status
ocultar prefixo de status

-t,--ferramenta
especificar ferramenta de mesclagem

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-T,--modelo
exibir com modelo (EXPERIMENTAL)

A opção marcada [+] pode ser especificada várias vezes

reverter
restaurar arquivos para seu estado de checkout:

hg reverter [OPÇÃO] ... [-r REV] [NOME] ...

Nota Para verificar as revisões anteriores, você deve usar hg atualizar REV. Para cancelar um
mesclagem não confirmada (e perder suas alterações), use hg atualizar --limpar ..

Sem nenhuma revisão especificada, reverte os arquivos ou diretórios especificados para o conteúdo que eles
tinha no pai do diretório de trabalho. Isso restaura o conteúdo dos arquivos para um
estado não modificado e não programado adiciona, remove, copia e renomeia. Se o trabalho
diretório tem dois pais, você deve especificar explicitamente uma revisão.

Usando as opções -r / - rev ou -d / - date, reverta os arquivos ou diretórios fornecidos para seus
estados a partir de uma revisão específica. Porque a reversão não muda o diretório de trabalho
pais, isso fará com que esses arquivos pareçam modificados. Isso pode ser útil para "recuar"
algumas ou todas as alterações anteriores. Ver hg voltar para um método relacionado.

Os arquivos modificados são salvos com um sufixo .orig antes de serem revertidos. Para desativar esses backups,
use --no-backup.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

See hg ajudar voltar para ver uma maneira de reverter o efeito de um conjunto de alterações anterior.

Retorna 0 em caso de sucesso.

opções:

-uma, --tudo
reverter todas as mudanças quando nenhum argumento for fornecido

-d,--data
data de correspondência de revisão mais recente

-r,--rev
reverter para a revisão especificada

-C, --sem backup
não salve cópias de backup de arquivos

-eu, --interativo
selecione interativamente as alterações (EXPERIMENTAL)

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

A opção marcada [+] pode ser especificada várias vezes

rollback
reverter a última transação (PERIGOSO) (USO SUSPENSO):

reversão hg

Por favor, use hg commit - alterar em vez de rollback para corrigir erros no último commit.

Este comando deve ser usado com cuidado. Há apenas um nível de reversão, e há
nenhuma maneira de desfazer uma reversão. Ele também irá restaurar o dirstate no momento do último
transação, perdendo quaisquer alterações dirstate desde aquele tempo. Este comando não altera o
diretório de trabalho.

As transações são usadas para encapsular os efeitos de todos os comandos que criam novos
conjuntos de alterações ou propague conjuntos de alterações existentes em um repositório.

Por exemplo, os seguintes comandos são transacionais e seus efeitos podem ser rolados
de volta:

· comprometer-se

· Importar

· puxar

· Push (com este repositório como destino)

· Descompactar

Para evitar a perda permanente de dados, a reversão se recusará a reverter uma transação de confirmação se ela
não foi verificado. Use --force para cancelar esta proteção.

Este comando não se destina ao uso em repositórios públicos. Assim que as alterações estiverem visíveis para
puxada por outros usuários, reverter uma transação localmente é ineficaz (outra pessoa pode
já puxou as mudanças). Além disso, uma corrida é possível com os leitores do
repositório; por exemplo, um pull em andamento do repositório pode falhar se uma reversão for
realizado.

Retorna 0 em caso de sucesso, 1 se nenhum dado de rollback estiver disponível.

opções:

-n, --funcionamento a seco
não execute ações, apenas imprima o resultado

-f, --força
ignorar medidas de segurança

raiz
imprima a raiz (parte superior) do diretório de trabalho atual:

raiz hg

Imprima o diretório raiz do repositório atual.

Retorna 0 em caso de sucesso.

servir
iniciar servidor da web autônomo:

hg serve [OPÇÃO] ...

Inicie um navegador de repositório HTTP local e receba o servidor. Você pode usar isso para compartilhamento ad-hoc
e navegação em repositórios. Recomenda-se usar um servidor web real para servir a um
repositório por longos períodos de tempo.

Observe que o servidor não implementa controle de acesso. Isso significa que, por
padrão, qualquer pessoa pode ler do servidor e ninguém pode escrever nele por padrão. Colocou o
web.allow_push opção para * para permitir que todos façam push para o servidor. Você deve usar um verdadeiro
servidor da web se você precisar autenticar usuários.

Por padrão, o servidor registra acessos a stdout e erros a stderr. Use o
-A / - accesslog e -E / - opções de errorlog para registrar em arquivos.

Para que o servidor escolha um número de porta livre para escutar, especifique um número de porta 0; dentro
neste caso, o servidor imprimirá o número da porta que usa.

Retorna 0 em caso de sucesso.

opções:

-UMA,--log de acesso
nome do arquivo de log de acesso para gravar

-d, --daemon
executar o servidor em segundo plano

--daemon-pipefds
usado internamente pelo modo daemon

- Ah,--errorlog
nome do arquivo de log de erro para gravar

-p,--porta
porta para escutar (padrão: 8000)

-uma,--Morada
endereço para ouvir (padrão: todas as interfaces)

--prefixo
caminho de prefixo de onde servir (padrão: raiz do servidor)

-n,--nome
nome para mostrar nas páginas da web (padrão: diretório de trabalho)

--web-conf
nome do arquivo de configuração hgweb (consulte "hg help hgweb")

--webdir-conf
nome do arquivo de configuração hgweb (USO SUSPENSO)

--pid-arquivo
nome do arquivo para gravar o ID do processo para

--stdio
para clientes remotos

--cmdserver
para clientes remotos

-t,--modelos
modelos da web para usar

--estilo
estilo de modelo para usar

-6, --ipv6
use IPv6 além de IPv4

--certificado
Arquivo de certificado SSL

estado
mostrar os arquivos alterados no diretório de trabalho:

status hg [OPÇÃO] ... [ARQUIVO] ...

Mostra o status dos arquivos no repositório. Se nomes forem fornecidos, apenas os arquivos correspondentes serão
mostrando. Os arquivos que são limpos ou ignorados ou a origem de uma operação de copiar / mover, não são
listado a menos que -c / - clean, -i / - ignorado, -C / - cópias ou -A / - todos sejam fornecidos. A menos que opções
descritos com "show only ..." são fornecidos, as opções -mardu são usadas.

A opção -q / - quiet oculta arquivos não rastreados (desconhecidos e ignorados), a menos que seja explicitamente solicitado
com -u / - desconhecido ou -i / - ignorado.

Note hg estado pode parecer discordar de diff se as permissões foram alteradas ou uma fusão
ocorreu. O formato diff padrão não relata mudanças de permissão e diff
relata apenas mudanças em relação a um pai de mesclagem.

Se uma revisão for fornecida, ela será usada como a revisão base. Se duas revisões forem fornecidas,
as diferenças entre eles são mostradas. A opção --change também pode ser usada como um atalho
para listar os arquivos alterados de uma revisão de seu primeiro pai.

Os códigos usados ​​para mostrar o status dos arquivos são:

M = modificado
A = adicionado
R = removido
C = limpo
! = ausente (excluído por comando não-hg, mas ainda rastreado)
? = não rastreado
I = ignorado
= origem do arquivo anterior (com --copies)

Exemplos:

· Mostrar mudanças no diretório de trabalho em relação a um changeset:

status hg --rev 9353

· Mostrar as mudanças no diretório de trabalho em relação ao diretório atual (ver hg ajudar
padrões Para maiores informações):

status hg re:

· Mostrar todas as alterações, incluindo cópias em um conjunto de alterações existente:

hg status --cópias --mudança 9353

· Obter uma lista separada de NUL de arquivos adicionados, adequada para xargs:

status hg -an0

Retorna 0 em caso de sucesso.

opções:

-UMA, --tudo
mostrar o status de todos os arquivos

-m, - modificado
mostrar apenas arquivos modificados

-uma, --adicionado
mostrar apenas arquivos adicionados

-r, --removido
mostrar apenas arquivos removidos

-d, - excluído
mostrar apenas arquivos excluídos (mas rastreados)

-c, --limpar
mostrar apenas arquivos sem alterações

-você, --desconhecido
mostrar apenas arquivos desconhecidos (não rastreados)

-eu, - ignorado
mostrar apenas arquivos ignorados

-n, --sem status
ocultar prefixo de status

-C, --cópias
mostrar a fonte dos arquivos copiados

-0, --print0
terminar nomes de arquivos com NUL, para uso com xargs

--rev
mostrar diferença da revisão

--mudança
lista os arquivos alterados de uma revisão

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-S, --subrepos
Recurso para subrepositórios

-T,--modelo
exibir com modelo (EXPERIMENTAL)

A opção marcada [+] pode ser especificada várias vezes

pseudônimos: st

resumo
resumir o estado do diretório de trabalho:

resumo de hg [--remote]

Isso gera um breve resumo do estado do diretório de trabalho, incluindo pais, ramo,
status de confirmação, fase e atualizações disponíveis.

Com a opção --remote, isso irá verificar os caminhos padrão para entrada e saída
alterar. Isso pode ser demorado.

Retorna 0 em caso de sucesso.

opções:

--controlo remoto
verifique se há empurrar e puxar

aliases: soma

etiqueta
adicione uma ou mais tags para a revisão atual ou dada:

tag hg [-f] [-l] [-m TEXTO] [-d DATA] [-u USUÁRIO] [-r REV] NOME ...

Nomeie uma revisão particular usando .

Tags são usadas para nomear revisões particulares do repositório e são muito úteis para
comparar diferentes revisões, para voltar a versões anteriores significativas ou para marcar o ramo
pontos como lançamentos, etc. Alterar uma tag existente normalmente não é permitido; use -f / - force
para substituir.

Se nenhuma revisão for fornecida, o pai do diretório de trabalho é usado.

Para facilitar o controle de versão, distribuição e mesclagem de tags, eles são armazenados como um
arquivo chamado ".hgtags" que é gerenciado de forma semelhante a outros arquivos de projeto e pode ser
editado manualmente, se necessário. Isso também significa que a marcação cria um novo commit. O arquivo
".hg / localtags" é usado para tags locais (não compartilhadas entre os repositórios).

Os commits de tag geralmente são feitos no cabeçalho de um branch. Se o pai do trabalhador
diretório não é um branch head, hg etiqueta aborta; use -f / - force para forçar o comprometimento da tag com
ser baseado em um changeset não principal.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

Uma vez que os nomes das tags têm prioridade sobre os nomes dos ramos durante a pesquisa de revisão, usando um existente
nome do ramo como um nome de tag é desencorajado.

Retorna 0 em caso de sucesso.

opções:

-f, --força
forçar etiqueta

-eu, --local
tornar a tag local

-r,--rev
revisão para tag

--retirar
remover uma tag

-e --editar
invocar editor em mensagens de confirmação

-m,--mensagem
usar texto como mensagem de confirmação

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

Tag
listar tags de repositório:

tags hg

Isso lista as tags regulares e locais. Quando a opção -v / - verbose é usada, um terceiro
a coluna "local" é impressa para tags locais. Quando a opção -q / - quiet é usada, apenas o
o nome da marca é impresso.

Retorna 0 em caso de sucesso.

opções:

-T,--modelo
exibir com modelo (EXPERIMENTAL)

tipo
mostrar a revisão da dica (DESCONTINUADO):

dica hg [-p] [-g]

A revisão da dica (geralmente chamada apenas de dica) é o conjunto de alterações adicionado mais recentemente ao
repositório (e, portanto, o cabeçalho alterado mais recentemente).

Se você acabou de fazer um commit, esse commit será a dica. Se você acabou de puxar
mudanças de outro repositório, a dica desse repositório se torna a dica atual. O
A tag "tip" é especial e não pode ser renomeada ou atribuída a um changeset diferente.

Este comando está obsoleto, por favor, use hg cabeças ao invés.

Retorna 0 em caso de sucesso.

opções:

-p, --correção
mostrar patch

-g, --git
usar formato de diff estendido git

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

descompactar
aplique um ou mais arquivos changegroup:

hg unbundle [-u] FILE ...

Aplique um ou mais arquivos de changegroup compactados gerados pelo comando bundle.

Retorna 0 em caso de sucesso, 1 se uma atualização tiver arquivos não resolvidos.

opções:

-você, --atualizar
atualizar para o novo chefe de filial se os conjuntos de alterações foram desagregados

atualizar
atualize o diretório de trabalho (ou troque as revisões):

atualização hg [-c] [-C] [-d DATA] [[-r] REV]

Atualize o diretório de trabalho do repositório para o changeset especificado. Se nenhum conjunto de mudanças for
especificado, atualize para a ponta do ramo nomeado atual e mova o marcador ativo (consulte
hg ajudar bookmarks).

A atualização configura a revisão pai do diretório de trabalho para o conjunto de mudanças especificado (veja hg
ajudar pais).

Se o changeset não for um descendente ou ancestral do pai do diretório de trabalho, o
a atualização foi abortada. Com a opção -c / - check, o diretório de trabalho é verificado para
mudanças não comprometidas; se nenhum for encontrado, o diretório de trabalho é atualizado para o especificado
conjunto de mudanças.

As seguintes regras se aplicam quando o diretório de trabalho contém alterações não confirmadas:

1. Se nem -c / - check nem -C / - clean for especificado, e se o changeset solicitado é um
ancestral ou descendente do pai do diretório de trabalho, as mudanças não confirmadas são
mesclado no conjunto de alterações solicitado e o resultado mesclado não é confirmado. Se o
o conjunto de alterações solicitado não é um ancestral ou descendente (ou seja, está em outro
branch), a atualização é abortada e as alterações não confirmadas são preservadas.

2. Com a opção -c / - check, a atualização é abortada e as alterações não confirmadas são
preservado.

3. Com a opção -C / - clean, as alterações não confirmadas são descartadas e o diretório de trabalho
é atualizado para o conjunto de alterações solicitado.

Para cancelar uma mesclagem não confirmada (e perder suas alterações), use hg atualizar --limpar ..

Use null como o changeset para remover o diretório de trabalho (como hg clonar -U).

Se você quiser reverter apenas um arquivo para uma revisão mais antiga, use hg reverter [-r REV] NOME.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

Retorna 0 em caso de sucesso, 1 se houver arquivos não resolvidos.

opções:

-C, --limpar
descartar alterações não confirmadas (sem backup)

-c, --Verifica
atualizar entre ramos se não houver mudanças não confirmadas

-d,--data
data de correspondência de revisão mais recente

-r,--rev
revisão

-t,--ferramenta
especificar ferramenta de mesclagem

apelidos: up checkout co

verificar
verifique a integridade do repositório:

verificar hg

Verifique a integridade do repositório atual.

Isto irá realizar uma extensa verificação da integridade do repositório, validando os hashes
e somas de verificação de cada entrada no log de mudanças, manifesto e arquivos rastreados, bem como o
integridade de suas ligações cruzadas e índices.

Consulte https://mercurial-scm.org/wiki/RepositoryCorruption para obter mais informações sobre
recuperação de corrupção do repositório.

Retorna 0 em caso de sucesso, 1 se forem encontrados erros.

versão
versão de saída e informações de direitos autorais:

versão hg

versão de saída e informações de direitos autorais

INFORMAÇÃO FORMATOS

Alguns comandos permitem que o usuário especifique uma data, por exemplo:

· Backout, commit, import, tag: Especifique a data de confirmação.

· Registrar, reverter, atualizar: Selecione revisão (ões) por data.

Muitos formatos de data são válidos. aqui estão alguns exemplos:

· Quar Dez 6 13:18:29 2006 (fuso horário local assumido)

· Dez 6 13:18 -0600 (ano assumido, compensação de tempo fornecida)

· Dez 6 13:18 UTC (UTC e GMT são apelidos para +0000)

· Dez 6 (meia-noite)

· 13:18 (hoje assumido)

· 3:39 (3:39 presumido)

· 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 de dezembro de 2006)

· hoje (meia-noite)

· ontem (meia-noite)

· agora - agora mesmo

Por último, existe o formato interno do Mercurial:

· 1165411109 0 (Quarta-feira, 6 de dezembro 13:18:29 de 2006 UTC)

Este é o formato de representação interna para datas. O primeiro número é o número de
segundos desde a época (1970-01-01 00:00 UTC). O segundo é o deslocamento do local
fuso horário, em segundos a oeste do UTC (negativo se o fuso horário for a leste do UTC).

O comando log também aceita intervalos de datas:

· <DATE - em ou antes de uma determinada data / hora

· > DATA - em ou após uma determinada data / hora

· INFORMAÇÃO para INFORMAÇÃO - um intervalo de datas, inclusive

· -DIAS - dentro de um determinado número de dias a partir de hoje

DIFF FORMATOS

O formato padrão do Mercurial para mostrar as alterações entre duas versões de um arquivo é
compatível com o formato unificado do GNU diff, que pode ser usado pelo patch GNU e muitos
outras ferramentas padrão.

Embora esse formato padrão seja frequentemente suficiente, ele não codifica as seguintes informações:

· Status executável e outros bits de permissão

· Copiar ou renomear informações

· Mudanças em arquivos binários

· Criação ou exclusão de arquivos vazios

O Mercurial também suporta o formato diff estendido do git VCS que aborda esses
limitações. O formato git diff não é produzido por padrão devido a algumas ferramentas difundidas
ainda não entendo este formato.

Isso significa que ao gerar diffs de um repositório Mercurial (por exemplo, com hg exportar),
você deve ter cuidado com coisas como cópias e renomeações de arquivos ou outras coisas mencionadas
acima, porque ao aplicar um diff padrão a um repositório diferente, este extra
informações são perdidas. As operações internas do Mercurial (como empurrar e puxar) não são afetadas
com isso, porque eles usam um formato binário interno para comunicar as mudanças.

Para fazer o Mercurial produzir o formato de diff estendido git, use a opção --git disponível para
muitos comandos, ou defina 'git = True' na seção [diff] do seu arquivo de configuração. Você
não precisa definir esta opção ao importar diffs neste formato ou usá-los no mq
extensão.

MEIO AMBIENTE VARIÁVEIS

HG Caminho para o executável 'hg', passado automaticamente ao executar ganchos, extensões ou
ferramentas externas. Se não estiver definido ou vazio, este é o nome do executável hg se estiver congelado,
ou um executável chamado 'hg' (com% PATHEXT% [padronizado para COM / EXE / BAT / CMD]
extensões no Windows) é pesquisado.

EDITOR HG
Este é o nome do editor a ser executado durante a confirmação. Veja EDITOR.

(obsoleto, usar arquivo de configuração)

CODIFICAÇÃO HGEN
Isso substitui a configuração de localidade padrão detectada pelo Mercurial. Esta configuração é
usado para converter dados, incluindo nomes de usuário, descrições de conjunto de alterações, nomes de tag e
galhos. Esta configuração pode ser substituída com a opção de linha de comando --encoding.

HGENCODINGMODE
Isso define o comportamento do Mercurial para lidar com caracteres desconhecidos durante a transcodificação
entrada do usuário. O padrão é "estrito", o que faz com que o Mercurial aborte se não puder
mapear um personagem. Outras configurações incluem "substituir", que substitui desconhecido
caracteres e "ignorar", que os descarta. Esta configuração pode ser substituída pelo
Opção de linha de comando --encodingmode.

HGENCODINGAMBIGUOUS
Isso define o comportamento do Mercurial para lidar com caracteres com larguras "ambíguas" como
caracteres latinos acentuados com fontes do leste asiático. Por padrão, o Mercurial assume
caracteres ambíguos são estreitos, defina esta variável como "ampla" se tais caracteres
causar problemas de formatação.

HGMERGE
Um executável a ser usado para resolver conflitos de mesclagem. O programa será executado
com três argumentos: arquivo local, arquivo remoto, arquivo ancestral.

(obsoleto, usar arquivo de configuração)

HGRCPATH
Uma lista de arquivos ou diretórios para pesquisar arquivos de configuração. O separador de itens é
":" no Unix, ";" no Windows. Se HGRCPATH não estiver definido, o caminho de pesquisa padrão da plataforma
é usado. Se estiver vazio, apenas o .hg / hgrc do repositório atual é lido.

Para cada elemento em HGRCPATH:

· Se for um diretório, todos os arquivos que terminam com .rc são adicionados

· Caso contrário, o próprio arquivo será adicionado

HGPLAIN
Quando definido, isso desativa qualquer definição de configuração que pode alterar o Mercurial
saída padrão. Isso inclui codificação, padrões, modo detalhado, modo de depuração, silencioso
modo, rastreamentos e localização. Isso pode ser útil ao criar scripts contra
Mercurial em face da configuração do usuário existente.

Opções equivalentes definidas por meio de sinalizadores de linha de comando ou variáveis ​​de ambiente não são
substituído.

HGPLAINEXCETO
Esta é uma lista separada por vírgulas de recursos a serem preservados quando HGPLAIN está ativado.
Atualmente, os seguintes valores são suportados:

aliás

Não remova apelidos.

I18n

Preserve a internacionalização.

revsetálias

Não remova apelidos revset.

Definir HGPLAINEXCEPT para qualquer coisa (mesmo uma string vazia) habilitará o modo simples.

HGUSER Esta é a string usada como autor de um commit. Se não for definido, os valores disponíveis
será considerado nesta ordem:

· HGUSER (obsoleto)

· Arquivos de configuração do HGRCPATH

· O EMAIL

· Prompt interativo

· LOGNAME (com @nome de anfitrião anexado)

(obsoleto, usar arquivo de configuração)

EMAIL Pode ser usado como autor de um commit; veja HGUSER.

NOME DO LOG
Pode ser usado como autor de um commit; veja HGUSER.

VISUAL Este é o nome do editor a ser usado ao enviar. Veja EDITOR.

EDITOR Às vezes, o Mercurial precisa abrir um arquivo de texto em um editor para um usuário modificar,
por exemplo, ao escrever mensagens de confirmação. O editor que ele usa é determinado por
olhando as variáveis ​​de ambiente HGEDITOR, VISUAL e EDITOR, nessa ordem.
O primeiro não vazio é escolhido. Se todos eles estiverem vazios, o padrão do editor é
'editor sensato'.

PITONPATO
Isso é usado pelo Python para encontrar módulos importados e pode precisar ser definido
apropriadamente se este Mercurial não estiver instalado em todo o sistema.

USANDO ADICIONAL CARATERÍSTICAS

O Mercurial tem a capacidade de adicionar novos recursos por meio do uso de extensões. Extensões
pode adicionar novos comandos, adicionar opções aos comandos existentes, alterar o comportamento padrão do
comandos ou implementa ganchos.

Para habilitar a extensão "foo", enviada com o Mercurial ou no caminho de pesquisa do Python,
crie uma entrada para ele em seu arquivo de configuração, como este:

[extensões]
foo =

Você também pode especificar o caminho completo para uma extensão:

[extensões]
meurecurso = ~ / .hgext / myfeature.py

See hg ajudar configuração para obter mais informações sobre os arquivos de configuração.

As extensões não são carregadas por padrão por vários motivos: elas podem aumentar a inicialização
a sobrecarga; eles podem ser destinados apenas para uso avançado; eles podem fornecer potencialmente
habilidades perigosas (como permitir que você destrua ou modifique a história); eles podem não ser
pronto para o horário nobre; ou podem alterar alguns comportamentos usuais do estoque do Mercurial. Isto é
portanto, cabe ao usuário ativar as extensões conforme necessário.

Para desabilitar explicitamente uma extensão habilitada em um arquivo de configuração de escopo mais amplo,
prefixe seu caminho com!:

[extensões]
# desabilitando a barra de extensão residente em /path/to/extension/bar.py
bar =! /path/to/extension/bar.py
# idem, mas nenhum caminho foi fornecido para a extensão baz
baz =!

extensões desativadas:

acl ganchos para controlar o acesso ao repositório

blackbox
registrar eventos do repositório em uma caixa preta para depuração

Bugzilla
ganchos para integração com o bug tracker Bugzilla

censurar apagar o conteúdo do arquivo em uma determinada revisão

agitação comando para exibir estatísticas sobre o histórico do repositório

clonebundles
anunciar pacotes pré-gerados para sementes de clones

cor colorir a saída de alguns comandos

converter
importar revisões de repositórios VCS estrangeiros para o Mercurial

eol gerenciar automaticamente novas linhas em arquivos de repositório

extdiff
comando para permitir que programas externos comparem as revisões

faz-tudo
autenticação http com factotum

gpg comandos para assinar e verificar changesets

hgcia ganchos para integração com o serviço de notificação CIA.vc

hgk navegue no repositório de forma gráfica

realçar
destaque de sintaxe para hgweb (requer pigmentos)

histórico
edição de história interativa

palavra chave
expandir palavras-chave em arquivos rastreados

arquivos grandes
rastrear grandes arquivos binários

mq gerenciar uma pilha de patches

notificar ganchos para enviar notificações push por e-mail

pager navegar pela saída do comando com um pager externo

bomba de remendo
comando para enviar changesets como (uma série de) e-mails de patch

purga comando para excluir arquivos não rastreados do diretório de trabalho

rebase comando para mover conjuntos de revisões para um ancestral diferente

registro comandos para selecionar mudanças interativamente para commit / qrefresh

religar recria hardlinks entre clones de repositório

esquemas
estender esquemas com atalhos para enxames de repositório

share compartilham uma história comum entre vários diretórios de trabalho

arquivar salvar e restaurar as alterações no diretório de trabalho

tira tira os changesets e seus descendentes da história

transplante
comando para transplantar changesets de outro ramo

win32mbcs
permitir o uso de caminhos MBCS com codificações problemáticas

Zeroconf
descobrir e anunciar repositórios na rede local

ESPECIFICANDO ARQUIVO CONJUNTOS

O Mercurial oferece suporte a uma linguagem funcional para selecionar um conjunto de arquivos.

Como outros padrões de arquivo, este tipo de padrão é indicado por um prefixo, 'set:'. O idioma
suporta uma série de predicados que são unidos por operadores infixos. Parênteses pode ser
usado para agrupamento.

Identificadores como nomes de arquivos ou padrões devem ser citados com aspas simples ou duplas se
eles contêm caracteres fora de [. * {} []? / \ _ a-zA-Z0-9 \ x80- \ xff] ou se eles correspondem a um de
os predicados predefinidos. Isso geralmente se aplica a padrões de arquivo diferentes de globs e
argumentos para predicados.

Caracteres especiais podem ser usados ​​em identificadores entre aspas, escapando deles, por exemplo, \n is
interpretado como uma nova linha. Para evitar que sejam interpretados, strings podem ser prefixadas
com r, por exemplo r '...'.

Existe um único operador de prefixo:

não x

Arquivos que não estão em x. O formato curto é ! x.

Estes são os operadores infixados com suporte:

x e y

A interseção de arquivos em xe y. O formato curto é x & y.

x or y

A união de arquivos em xe y. Existem duas formas alternativas de abreviação: x | y e x +
y.

x - y

Arquivos em x, mas não em y.

Os seguintes predicados são suportados:

adicionado()

Arquivo que é adicionado de acordo com hg estado.

binário()

Arquivo que parece ser binário (contém bytes NUL).

limpar \ limpo()

Arquivo que está limpo de acordo com hg estado.

copiado ()

Arquivo registrado como copiado.

excluído ()

Alias ​​para ausente().

codificação (nome)

O arquivo pode ser decodificado com sucesso com a codificação de caracteres fornecida. Talvez não seja
útil para codificações diferentes de ASCII e UTF-8.

eol (estilo)

O arquivo contém novas linhas do estilo fornecido (dos, unix, mac). Arquivos binários são
excluídos, os arquivos com terminações de linha mistas correspondem a vários estilos.

exec ()

Arquivo marcado como executável.

grep (regex)

O arquivo contém a expressão regular fornecida.

hgignore ()

Arquivo que corresponde ao padrão .hgignore ativo.

ignorado ()

Arquivo que é ignorado de acordo com hg estado. Esses arquivos só serão considerados se
este predicado é usado.

ausente()

Arquivo que está faltando de acordo com hg estado.

modificado ()

Arquivo que é modificado de acordo com hg estado.

portátil()

Arquivo com nome portátil. (Isso não inclui nomes de arquivos com maiúsculas
colisões.)

removido()

Arquivo removido de acordo com hg estado.

resolvido()

Arquivo marcado como resolvido de acordo com hg resolver -l.

tamanho (expressão)

O tamanho do arquivo corresponde à expressão fornecida. Exemplos:

· 1k (arquivos de 1024 a 2047 bytes)

· <20k (arquivos com menos de 20480 bytes)

·> = 5 MB (arquivos de pelo menos 524288 bytes)

· 4k - 1 MB (arquivos de 4096 bytes a 1048576 bytes)

subrepo ([padrão])

Subrepositórios cujos caminhos correspondem ao padrão fornecido.

link simbólico ()

Arquivo marcado como link simbólico.

desconhecido()

Arquivo que é desconhecido de acordo com hg estado. Esses arquivos só serão considerados se
este predicado é usado.

não resolvido ()

Arquivo marcado como não resolvido de acordo com hg resolver -l.

Alguns exemplos de consultas:

· Mostrar o status dos arquivos que parecem ser binários no diretório de trabalho:

hg status -A "set: binary ()"

· Esqueça os arquivos que estão em .hgignore, mas já foram rastreados:

hg esqueça "set: hgignore () e não ignorado ()"

· Encontre arquivos de texto que contenham uma string:

arquivos hg "definido:grep(mágica) e não binária () "

· Encontre arquivos C em uma codificação não padrão:

arquivos hg "definido: **. c e sem codificação ('UTF-8')"

· Reverter cópias de grandes arquivos binários:

hg revert "conjunto: copiado () e binário () e tamanho ('> 1M')"

· Remova os arquivos listados em foo.lst que contêm a letra a ou b:

hg remove "set: 'listfile: foo.lst' e (** a * ou ** b *)"

Veja também hg ajudar padrões.

GLOSSÁRIO

Antepassado
Qualquer conjunto de alterações que pode ser alcançado por uma cadeia ininterrupta de conjuntos de alterações pai de um
dado conjunto de alterações. Mais precisamente, os ancestrais de um changeset podem ser definidos por dois
propriedades: um pai de um changeset é um ancestral, e um pai de um ancestral é
um ancestral. Veja também: 'Descendente'.

Bookmark
Os favoritos são ponteiros para certos commits que se movem durante o commit. Eles são
semelhante a tags, pois é possível usar nomes de favoritos em todos os lugares onde
O Mercurial espera um código de conjunto de mudanças, por exemplo, com hg atualizar. Ao contrário das tags, os favoritos se movem
junto quando você faz um commit.

Os favoritos podem ser renomeados, copiados e excluídos. Os favoritos são locais, a menos que sejam
empurrado ou puxado explicitamente entre repositórios. Empurrando e puxando favoritos
permitem que você colabore com outras pessoas em um branch sem criar um branch nomeado.

Ramo (Substantivo) Um changeset filho que foi criado de um pai que não é um chefe.
Eles são conhecidos como ramos topológicos, consulte 'Ramo, topológico'. Se um
ramo topológico é nomeado, ele se torna um ramo nomeado. Se um ramo topológico é
não nomeado, torna-se um branch anônimo. Consulte 'Ramificação, anônimo' e 'Ramificação,
nomeado '.

Ramificações podem ser criadas quando as alterações são puxadas ou enviadas para um controle remoto
repositório, uma vez que novas cabeças podem ser criadas por essas operações. Observe que o termo
ramo também pode ser usado informalmente para descrever um processo de desenvolvimento no qual
determinado desenvolvimento é feito independentemente de outro desenvolvimento. Às vezes é
feito explicitamente com um branch nomeado, mas também pode ser feito localmente, usando
marcadores ou clones e ramos anônimos.

Exemplo: "O ramo experimental."

(Verbo) A ação de criar um changeset filho que resulta em seu pai tendo
mais de uma criança.

Exemplo: "Vou ramificar em X."

Galho, anônimo
Cada vez que um novo changeset filho é criado de um pai que não é um chefe e
o nome da ramificação não é alterado, uma nova ramificação anônima é criada.

Galho, fechado
Uma ramificação nomeada cujos cabeçalhos de ramificação foram todos fechados.

Galho, omissão
A ramificação atribuída a um changeset quando nenhum nome foi atribuído anteriormente.

Ramo cabeça
Consulte 'Cabeça, ramo'.

Galho, inativo
Se uma ramificação nomeada não tiver cabeçotes topológicos, ela será considerada inativa. Como um
exemplo, um ramo de recurso se torna inativo quando é mesclado com o padrão
filial. o hg ramos comando mostra ramos inativos por padrão, embora eles possam
estar escondido com hg ramos --ativo.

NOTA: este conceito está obsoleto porque é muito implícito. Ramos devem agora
ser explicitamente fechado usando hg commit --filial próximo quando eles não são mais necessários.

Galho, nomeado
Uma coleção de changesets que possuem o mesmo nome de branch. Por padrão, filhos de
um changeset em um branch nomeado pertence ao mesmo branch nomeado. Uma criança pode ser
explicitamente atribuído a um ramo diferente. Ver hg ajudar ramo, hg ajudar ramos e
hg commit --filial próximo para obter mais informações sobre como gerenciar filiais.

Ramificações nomeadas podem ser consideradas como uma espécie de namespace, dividindo a coleção de
conjuntos de alterações que abrangem o repositório em uma coleção de subconjuntos separados. UMA
ramo nomeado não é necessariamente um ramo topológico. Se um novo ramo nomeado é
criado a partir do cabeçalho de outro branch nomeado, ou o branch padrão, mas não
mais changesets são adicionados àquele branch anterior, então aquele branch anterior
será uma filial apenas no nome.

Ramo tipo
Veja 'Dica, ramificação'.

Galho, topológico
Cada vez que um novo changeset filho é criado de um pai que não é um chefe, um novo
ramo topológico é criado. Se um ramo topológico é nomeado, ele se torna um nomeado
ramo. Se um ramo topológico não for nomeado, ele se tornará um ramo anônimo do
atual, possivelmente padrão, ramo.

Changelog
Um registro dos changesets na ordem em que foram incluídos no repositório.
Isso inclui detalhes como id do changeset, autor, mensagem de confirmação, data e lista
de arquivos alterados.

Conjunto de alterações
Um instantâneo do estado do repositório usado para registrar uma mudança.

Conjunto de alterações, criança
O inverso do changeset pai: se P é um pai de C, então C é um filho de P.
Não há limite para o número de filhos que um changeset pode ter.

Conjunto de alterações id
Um hash SHA-1 que identifica exclusivamente um changeset. Pode ser representado como
uma string "longa" de 40 dígitos hexadecimais ou uma string "curta" de 12 dígitos hexadecimais.

Conjunto de alterações, fundir
Um changeset com dois pais. Isso ocorre quando uma mesclagem é confirmada.

Conjunto de alterações, principal
Uma revisão na qual um changeset filho é baseado. Especificamente, um conjunto de mudanças pai
de um changeset C é um changeset cujo nó precede imediatamente C no DAG.
Os conjuntos de alterações têm no máximo dois pais.

Finalizar compra
(Substantivo) O diretório de trabalho sendo atualizado para uma revisão específica. Este uso deve
provavelmente ser evitado sempre que possível, pois o changeset é muito mais apropriado do que
checkout neste contexto.

Exemplo: "Estou usando o checkout X."

(Verbo) Atualizando o diretório de trabalho para um changeset específico. Ver hg ajudar atualizar.

Exemplo: "Vou verificar o changeset X."

Criança changeset
Consulte 'Conjunto de alterações, filho'.

Fechar changeset
Veja 'Cabeça, ramo fechado'.

Fechadas ramo
Consulte 'Filial, fechada'.

clone (Substantivo) Uma cópia total ou parcial de um repositório. O clone parcial deve estar no
forma de uma revisão e seus ancestrais.

Exemplo: "Seu clone está atualizado?"

(Verbo) O processo de criação de um clone, usando hg clonar.

Exemplo: "Vou clonar o repositório."

Fechadas ramo cabeça
Veja 'Cabeça, ramo fechado'.

COMPROMETA-SE (Substantivo) Um sinônimo para changeset.

Exemplo: "O bug foi corrigido em seu commit recente?"

(Verbo) O ato de registrar alterações em um repositório. Quando os arquivos são confirmados em um
diretório de trabalho, o Mercurial encontra as diferenças entre os arquivos confirmados e
seu changeset pai, criando um novo changeset no repositório.

Exemplo: "Você deve confirmar essas alterações agora."

Cset Uma abreviatura comum do termo changeset.

DAG O repositório de changesets de um sistema de controle de versão distribuído (DVCS) pode ser
descrito como um grafo acíclico direcionado (DAG), consistindo em nós e arestas, onde
os nós correspondem a conjuntos de alterações e as arestas implicam em uma relação pai -> filho. Isto
gráfico pode ser visualizado por ferramentas gráficas, como hg log --gráfico. No Mercurial,
o DAG é limitado pela exigência de que os filhos tenham no máximo dois pais.

Obsoleto
Recurso removido da documentação, mas não programado para remoção.

Padrão ramo
Veja 'Branch, default'.

Descendente
Qualquer conjunto de alterações que pode ser alcançado por uma cadeia de conjuntos de alterações filho de um determinado
conjunto de mudanças. Mais precisamente, os descendentes de um changeset podem ser definidos por dois
propriedades: o filho de um changeset é um descendente e o filho de um descendente
é um descendente. Veja também: 'Ancestral'.

Dif (Substantivo) A diferença entre o conteúdo e os atributos dos arquivos em dois
changesets ou um changeset e o diretório de trabalho atual. A diferença é
geralmente representado em uma forma padrão chamada "diff" ou "patch". O "git diff"
formato é usado quando as alterações incluem cópias, renomeações ou alterações no arquivo
atributos, nenhum dos quais pode ser representado / tratado pelos clássicos "diff" e "patch".

Exemplo: "Você viu minha correção no diff?"

(Verbo) Diferenciar dois changesets é a ação de criar um diff ou patch.

Exemplo: "Se você diferenciar com o changeset X, você verá o que quero dizer."

Diretório, trabalhar
O diretório de trabalho representa o estado dos arquivos rastreados pelo Mercurial, que
será registrado no próximo commit. O diretório de trabalho corresponde inicialmente a
o instantâneo em um conjunto de alterações existente, conhecido como o pai do trabalho
diretório. Consulte 'Pai, diretório de trabalho'. O estado pode ser modificado por mudanças em
os arquivos introduzidos manualmente ou por mesclagem. Os metadados do repositório existem no
.hg diretório dentro do diretório de trabalho.

Rascunho Os conjuntos de alterações na fase de rascunho não foram compartilhados com os repositórios de publicação e
pode, portanto, ser alterado com segurança por extensões de modificação de histórico. Ver hg ajudar fases.

experimental
Recurso que pode ser alterado ou removido posteriormente.

Gráfico Veja DAG e hg log --gráfico.

Head O termo 'head' pode ser usado para se referir a um branch ou a um repositório,
dependendo do contexto. Veja 'Cabeça, ramo' e 'Cabeça, repositório' para informações específicas
definições.

Cabeças são onde o desenvolvimento geralmente ocorre e são os alvos usuais para
atualizar e mesclar operações.

Cabeça, ramo
Um changeset sem descendentes no mesmo branch nomeado.

Cabeça, fechado ramo
Um changeset que marca uma cabeça como não mais interessante. A cabeça fechada é não
mais listado por hg cabeças. Uma filial é considerada fechada quando todas as suas cabeças estão
fechado e, conseqüentemente, não é listado por hg ramos.

Cabeças fechadas podem ser reabertas com a confirmação de um novo changeset como filho do
conjunto de mudanças que marca uma cabeça como fechada.

Cabeça, repositório
Uma cabeça topológica que não foi fechada.

Cabeça, topológico
Um changeset sem filhos no repositório.

História, imutável
Uma vez confirmados, os changesets não podem ser alterados. Extensões que parecem mudar
histórico, na verdade, cria novos conjuntos de alterações que substituem os existentes e, em seguida, destroem
os conjuntos de alterações antigos. Fazer isso em repositórios públicos pode resultar em conjuntos de alterações antigos
sendo reintroduzido no repositório.

História, reescrevendo
Os conjuntos de alterações em um repositório são imutáveis. No entanto, extensões para Mercurial podem
ser usado para alterar o repositório, geralmente de forma a preservar o conjunto de alterações
conteúdos.

Imutável história
Veja 'História, imutável'.

ir changeset
Consulte 'Changeset, merge'.

Manifesto
Cada conjunto de alterações tem um manifesto, que é a lista de arquivos rastreados pelo
conjunto de mudanças.

ir Usado para reunir ramos de trabalho divergentes. Quando você atualiza para um changeset
e, em seguida, mesclar outro conjunto de alterações, você traz o histórico do último conjunto de alterações
em seu diretório de trabalho. Uma vez que os conflitos são resolvidos (e marcados), esta fusão
pode ser confirmado como um changeset de mesclagem, trazendo duas ramificações juntas no DAG.

Nomeado ramo
Consulte 'Branch, named'.

Nulo changeset
O changeset vazio. É o estado pai de repositórios recém-inicializados e
repositórios sem revisão em check-out. É, portanto, o pai dos conjuntos de alterações raiz
e o ancestral efetivo ao mesclar conjuntos de alterações não relacionados. Pode ser especificado por
o alias 'null' ou pelo changeset ID '000000000000'.

Principal Consulte 'Conjunto de alterações, pai'.

Principal changeset
Consulte 'Conjunto de alterações, pai'.

Pai, trabalhar anuário
O pai do diretório de trabalho reflete uma revisão virtual que é filha do
conjunto de alterações (ou dois conjuntos de alterações com uma mesclagem não confirmada) mostrado por hg pais. Este
é alterado com hg atualizar. Outros comandos para ver o diretório de trabalho pai são
hg resumo e hg id. Pode ser especificado pelo alias ".".

Remendo (Substantivo) O produto de uma operação diff.

Exemplo: "Enviei meu patch para você."

(Verbo) O processo de usar um arquivo de patch para transformar um changeset em outro.

Exemplo: "Você precisará corrigir essa revisão."

Fase Um estado por conjunto de alterações rastreando como o conjunto de alterações foi ou deve ser compartilhado. Ver
hg ajudar fases.

Público Os conjuntos de alterações na fase pública foram compartilhados com repositórios de publicação e
são, portanto, considerados imutáveis. Ver hg ajudar fases.

Puxe Uma operação em que os conjuntos de alterações em um repositório remoto que não estão no local
repositório são trazidos para o repositório local. Observe que esta operação sem
argumentos especiais apenas atualizam o repositório, não atualiza os arquivos no
diretório de trabalho. Ver hg ajudar puxar.

Empurrar Uma operação em que os conjuntos de alterações em um repositório local que não estão em um local remoto
repositório são enviados para o repositório remoto. Observe que esta operação apenas adiciona
conjuntos de alterações que foram confirmados localmente no repositório remoto. Não comprometido
as alterações não são enviadas. Ver hg ajudar empurrar.

Repositório
Os metadados que descrevem todos os estados registrados de uma coleção de arquivos. Cada gravado
estado é representado por um changeset. Um repositório é geralmente (mas nem sempre) encontrado
no .hg subdiretório de um diretório de trabalho. Qualquer estado registrado pode ser recriado
"atualizando" um diretório de trabalho para um changeset específico.

Repositório cabeça
Veja 'Cabeça, repositório'.

Revisão
Um estado do repositório em algum momento. As revisões anteriores podem ser atualizadas
para usar hg atualizar. Consulte também 'Número da revisão'; Veja também 'Changeset'.

Revisão número
Este inteiro identifica exclusivamente um changeset em um repositório específico. Isto
representa a ordem em que os changesets foram adicionados a um repositório, começando com
número de revisão 0. Observe que o número de revisão pode ser diferente em cada clone de
um repositório. Para identificar conjuntos de alterações exclusivamente entre diferentes clones, consulte
'Id do changeset'.

Revlog Mecanismo de armazenamento de histórico usado pelo Mercurial. É uma forma de codificação delta, com
revisão completa ocasional de dados seguida de delta de cada revisão sucessiva. Isto
inclui dados e um índice apontando para os dados.

Reescrevendo história
Consulte 'História, reescrevendo'.

Raiz Um changeset que tem apenas o changeset nulo como seu pai. A maioria dos repositórios tem
apenas um único changeset raiz.

Segredo Os conjuntos de alterações na fase secreta não podem ser compartilhados por push, pull ou clone. Ver hg
ajudar fases.

etiqueta Um nome alternativo dado a um changeset. As tags podem ser usadas em todos os lugares onde
O Mercurial espera um código de conjunto de mudanças, por exemplo, com hg atualizar. A criação de uma tag é
armazenados no histórico e, portanto, serão automaticamente compartilhados com outros usando push
e puxe.

Dica O changeset com o maior número de revisão. É o changeset mais recente
adicionado em um repositório.

Dica, ramo
O chefe de um determinado ramo com o maior número de revisão. Quando o nome de uma filial é
usado como um identificador de revisão, ele se refere à ponta do ramo. Veja também 'Branch,
cabeça'. Observe que, porque os números de revisão podem ser diferentes em repositórios diferentes
clones, a ponta do ramo pode ser diferente em diferentes repositórios clonados.

Atualizar (Substantivo) Outro sinônimo de changeset.

Exemplo: "Eu enviei uma atualização."

(Verbo) Este termo é geralmente usado para descrever a atualização do estado do trabalho
diretório para aquele de um changeset específico. Ver hg ajudar atualizar.

Exemplo: "Você deve atualizar."

Trabalho anuário
Consulte 'Diretório em funcionamento'.

Trabalho anuário principal
Consulte 'Pai, diretório de trabalho'.

SINTAXE PARA MERCURIAL IGNORAR ARQUIVOS

Sinopse
O sistema Mercurial usa um arquivo chamado .hgignore no diretório raiz de um repositório para
controlar seu comportamento ao procurar arquivos que não esteja rastreando no momento.

Descrição
O diretório de trabalho de um repositório Mercurial geralmente contém arquivos que não devem
ser rastreado pelo Mercurial. Isso inclui arquivos de backup criados por editores e produtos de construção
criado por compiladores. Esses arquivos podem ser ignorados, listando-os em um .hgignore arquivo em
a raiz do diretório de trabalho. O .hgignore arquivo deve ser criado manualmente. Isto é
normalmente colocado sob controle de versão, de modo que as configurações se propaguem para outros
repositórios com push e pull.

Um arquivo não rastreado é ignorado se seu caminho relativo ao diretório raiz do repositório, ou qualquer
caminho de prefixo desse caminho, é comparado com qualquer padrão em .hgignore.

Por exemplo, digamos que temos um arquivo não rastreado, arquivo.c, em a / b / arquivo.c dentro de nosso repositório.
Mercurial irá ignorar arquivo.c se houver algum padrão em .hgignore fósforos a / b / arquivo.c, a / b or a.

Além disso, um arquivo de configuração do Mercurial pode fazer referência a um conjunto de itens por usuário ou globais
ignorar arquivos. Veja o ignorar chave de configuração no [ui] Seção de hg ajudar configuração para
detalhes de como configurar esses arquivos.

Para controlar o manuseio de arquivos que ele gerencia pelo Mercurial, muitos comandos suportam o -I e
-X opções; Vejo hg ajudar e hg ajudar padrões para obter detalhes.

Os arquivos já rastreados não são afetados por .hgignore, mesmo que apareçam em
.hgignore. Um arquivo X não rastreado pode ser adicionado explicitamente com hg adicionar X, mesmo se X fosse
excluído por um padrão em .hgignore.

Sintaxe
Um arquivo para ignorar é um arquivo de texto simples que consiste em uma lista de padrões, com um padrão por
linha. As linhas vazias são ignoradas. O # caractere é tratado como um caractere de comentário, e o
\ caractere é tratado como um caractere de escape.

O Mercurial oferece suporte a várias sintaxes de padrão. A sintaxe padrão usada é o estilo Python / Perl
expressões regulares.

Para alterar a sintaxe usada, use uma linha com o seguinte formato:

sintaxe: NAME

onde NOME é um dos seguintes:

regexp

Expressão regular, sintaxe Python / Perl.

glob

Glob ao estilo Shell.

A sintaxe escolhida permanece em vigor ao analisar todos os padrões que se seguem, até outro
sintaxe é selecionada.

Nem os padrões glob nem regexp têm raízes. Um padrão de sintaxe glob do formulário * .c precisarão
corresponder a um arquivo que termina em .c em qualquer diretório, e um padrão regexp do formulário \ .c $ vai fazer
o mesmo. Para enraizar um padrão regexp, comece com ^.

Subdiretórios podem ter suas próprias configurações .hgignore adicionando
subinclude: caminho / para / subdir / .hgignore à raiz .hgignore. Ver hg ajudar padrões para
detalhes sobre subincluir: e incluem:.

Padrões de nota especificados em outros que não .hgignore estão sempre enraizados. Por favor, veja hg ajudar
padrões para obter detalhes.

Exemplo
Aqui está um exemplo de arquivo para ignorar.

# use a sintaxe glob.
sintaxe: glob

* .elc
* .pyc
*~

# muda para a sintaxe regexp.
sintaxe: regexp
^ \. pc /

CONFIGURANDO HGWEB

O servidor web interno do Mercurial, hgweb, pode servir a um único repositório ou a uma árvore de
repositórios. No segundo caso, os caminhos do repositório e as opções globais podem ser definidos usando
um arquivo de configuração dedicado comum a hg servir, hgweb.wsgi, hgweb.cgi e hgweb.fcgi.

Este arquivo usa a mesma sintaxe de outros arquivos de configuração do Mercurial, mas reconhece apenas
as seguintes seções:

· rede

· Caminhos

· Coleções

A web as opções são completamente descritas em hg ajudar configuração.

A caminhos seção mapeia caminhos de URL para caminhos de repositórios no sistema de arquivos. hgweb vai
não expor o sistema de arquivos diretamente - apenas repositórios Mercurial podem ser publicados e apenas
de acordo com a configuração.

O lado esquerdo é o caminho no URL. Observe que hgweb reserva subcaminhos como rev or
lima, tente usar nomes diferentes para repositórios aninhados para evitar efeitos confusos.

O lado direito é o caminho no sistema de arquivos. Se o caminho especificado termina com * or **
o sistema de arquivos será pesquisado recursivamente por repositórios abaixo desse ponto. Com * it
não irá recursivamente nos repositórios que encontrar (exceto para .hg / patches) Com ** ele vai
também pesquise dentro dos diretórios de trabalho do repositório e possivelmente encontre subrepositórios.

Neste exemplo:

[caminhos]
/ projects / a = / srv / tmprepos / a
/ projetos / b = c: / repos / b
/ = / srv / repos / *
/ user / bob = / home / bob / repos / **

· As duas primeiras entradas fazem com que dois repositórios em diretórios diferentes apareçam sob o
mesmo diretório na interface da web

· A terceira entrada publicará todos os repositórios Mercurial encontrados em / srv / repos /, Por
instância do repositório / srv / repos / quux / aparecerá como http://server/quux/

· A quarta entrada publicará ambos http://server/user/bob/quux/ e
http://server/user/bob/quux/testsubrepo/

A coleções seção está obsoleta e foi substituída por caminhos.

URLs e comum Argumentos
URLs em cada repositório têm a forma / {comando} [/ {argumentos}] onde {comando}
representa o nome de um comando ou manipulador e {argumentos} representa qualquer número de
parâmetros de URL adicionais para esse comando.

O servidor da web possui um estilo padrão associado a ele. Os estilos são mapeados para uma coleção de
modelos. Cada template é usado para renderizar um dado específico, como um changeset
ou diff.

O estilo da solicitação atual pode ser substituído de duas maneiras. Primeiro, se {comando}
contém um hífen (-), o texto antes do hífen define o estilo. Por exemplo,
/ atom-log irá renderizar o log manipulador de comando com o átomo estilo. A segunda maneira de definir
o estilo está com o estilo argumento da string de consulta. Por exemplo, / log? style = átomo. O
O parâmetro de URL hifenizado é preferido.

Nem todos os modelos estão disponíveis para todos os estilos. Tentar usar um estilo que não
ter todos os modelos definidos pode resultar em um erro de renderização da página.

Muitos comandos levam um {revisão} Parâmetro de URL. Isso define o changeset no qual operar.
Isso é comumente especificado como a abreviatura hexadecimal curta de 12 dígitos para os 40 completos
identificador de revisão exclusivo do caractere. No entanto, qualquer valor descrito por hg ajudar revisões
normalmente funciona.

comandos e URLs
Os seguintes comandos da web e seus URLs estão disponíveis:

/ annotate / {revisão} / {caminho}
Mostra as informações do changeset para cada linha em um arquivo.

A anotar o modelo é renderizado.

/arquivo/{revisão}.{formato}[/{caminho}]
Obtenha um arquivo do conteúdo do repositório.

O conteúdo e o tipo do arquivo são definidos por um parâmetro de caminho de URL. formato é o
extensão de arquivo do tipo de arquivo a ser gerado. por exemplo zip or tar.bz2. Nem todos os arquivos
tipos podem ser permitidos pela configuração do seu servidor.

O opcional caminho O parâmetro de URL controla o conteúdo a ser incluído no arquivo. Se omitido,
cada arquivo na revisão especificada está presente no arquivo. Se incluído, apenas o
o arquivo especificado ou o conteúdo do diretório especificado será incluído no arquivo.

Nenhum modelo é usado para este manipulador. O conteúdo bruto e binário é gerado.

/favoritos
Mostra informações sobre favoritos.

Nenhum argumento é aceito.

A bookmarks o modelo é renderizado.

/galhos
Mostra informações sobre ramos.

Todas as ramificações conhecidas estão contidas na saída, mesmo as ramificações fechadas.

Nenhum argumento é aceito.

A ramos o modelo é renderizado.

/ changelog [/ {revisão}]
Mostra informações sobre vários changesets.

Se o opcional revisão O argumento de URL está ausente, informações sobre todos os conjuntos de alterações começando
at tipo será processado. Se o revisão o argumento está presente, os conjuntos de alterações serão mostrados
começando da revisão especificada.

If revisão está ausente, o rev o argumento da string de consulta pode ser definido. Isso irá realizar um
procure por changesets.

O argumento para rev pode ser uma única revisão, um conjunto de revisões ou uma palavra-chave literal para
pesquisar nos dados do changeset (equivalente a hg log -k).

A contagem de rotações O argumento da string de consulta define o número máximo de conjuntos de alterações a serem processados.

Para não pesquisas, o changelog o modelo será renderizado.

/ changeset [/ {revisão}]
Mostra informações sobre um único changeset.

Um argumento de caminho de URL é o identificador do changeset a ser mostrado. Ver hg ajudar revisões para
valores possíveis. Se não for definido, o tipo conjunto de alterações será mostrado.

A changeset o modelo é renderizado. Conteúdo do changesettag, marcador do conjunto de alterações,
arquivonodelink, arquivonolink, e os muitos modelos relacionados a diffs podem ser usados ​​para
produzir a saída.

/ comparação / {revisão} / {caminho}
Mostra uma comparação entre as versões antigas e novas de um arquivo a partir das alterações feitas em um
revisão particular.

Isso é semelhante ao diff manipulador. No entanto, este formulário apresenta uma divisão ou lado a lado
diff em vez de um diff unificado.

A contexto O argumento da string de consulta pode ser usado para controlar as linhas de contexto no diff.

A comparação de arquivos o modelo é renderizado.

/ diff / {revisão} / {caminho}
Mostre como um arquivo mudou em um commit particular.

A arquivista o modelo é renderizado.

Este manipulador está registrado em ambos / diff e / filediff caminhos. / diff é utilizado em
código moderno.

/ arquivo / {revisão} [/ {caminho}]
Mostra informações sobre um diretório ou arquivo no repositório.

Informações sobre o caminho fornecido como um parâmetro de URL será processado.

If caminho é um diretório, as informações sobre as entradas nesse diretório serão processadas.
Este formulário é equivalente ao manifestar manipulador.

If caminho é um arquivo, as informações sobre esse arquivo serão mostradas por meio do revisão de arquivo
template.

If caminho não for definido, as informações sobre o diretório raiz serão renderizadas.

/ diff / {revisão} / {caminho}
Mostre como um arquivo mudou em um commit particular.

A arquivista o modelo é renderizado.

Este manipulador está registrado em ambos / diff e / filediff caminhos. / diff é utilizado em
código moderno.

/ filelog / {revisão} / {caminho}
Mostra informações sobre o histórico de um arquivo no repositório.

A contagem de rotações o argumento da string de consulta pode ser definido para controlar o número máximo de entradas
mostrar.

A registro de arquivo o modelo será renderizado.

/ gráfico [/ {revisão}]
Mostra informações sobre a topologia gráfica do repositório.

As informações processadas por este manipulador podem ser usadas para criar representações visuais de
topologia do repositório.

A revisão O parâmetro de URL controla o changeset inicial.

A contagem de rotações o argumento da string de consulta pode definir o número de conjuntos de alterações para mostrar informações
para.

Este manipulador irá renderizar o gráfico template.

/tópico de ajuda}]
Renderize a documentação de ajuda.

Este comando da web é aproximadamente equivalente a hg ajudar. Se um tópico é definido, esse tópico de ajuda
será processado. Caso contrário, um índice de tópicos de ajuda disponíveis será renderizado.

A ajudar o modelo será renderizado ao solicitar ajuda para um tópico. tópicos de ajuda será
renderizado para o índice de tópicos de ajuda.

/ log [/ {revisão} [/ {caminho}]]
Mostra o histórico do repositório ou arquivo.

Para URLs do formulário / log / {revisão}, uma lista de changesets começando no especificado
o identificador do changeset é mostrado. Se {revisão} não está definido, o padrão é tipo. Essa forma
é equivalente ao changelog manipulador.

Para URLs do formulário / log / {revisão} / {arquivo}, o histórico de um arquivo específico será
mostrando. Este formulário é equivalente ao registro de arquivo manipulador.

/ manifest [/ {revisão} [/ {caminho}]]
Mostra informações sobre um diretório.

Se os argumentos do caminho do URL forem omitidos, as informações sobre o diretório raiz do tipo
conjunto de alterações será mostrado.

Como esse manipulador só pode mostrar informações para diretórios, é recomendável usar
que o lima handler em vez disso, já que pode lidar com diretórios e arquivos.

A manifestar o modelo será renderizado para este manipulador.

/ changeset [/ {revisão}]
Mostra informações sobre um único changeset.

Um argumento de caminho de URL é o identificador do changeset a ser mostrado. Ver hg ajudar revisões para
valores possíveis. Se não for definido, o tipo conjunto de alterações será mostrado.

A changeset o modelo é renderizado. Conteúdo do changesettag, marcador do conjunto de alterações,
arquivonodelink, arquivonolink, e os muitos modelos relacionados a diffs podem ser usados ​​para
produzir a saída.

/ shortlog
Mostra informações básicas sobre um conjunto de changesets.

Isso aceita os mesmos parâmetros do changelog manipulador. A única diferença é o
shortlog modelo será renderizado em vez do changelog template.

/resumo
Mostra um resumo do estado do repositório.

Informações sobre os últimos changesets, marcadores, tags e branches são capturados por este
manipulador.

A resumo o modelo é renderizado.

/Tag
Mostra informações sobre tags.

Nenhum argumento é aceito.

A Tag o modelo é renderizado.

ANÁLISE IMPLEMENTAÇÃO TÓPICOS

Pacotes
recipiente para troca de dados do repositório

grupos de mudanças
representação dos dados do revlog

registros de revlogs
mecanismo de armazenamento de revisão

MERGE FERRAMENTAS

Para mesclar arquivos, o Mercurial usa ferramentas de mesclagem.

Uma ferramenta de mesclagem combina duas versões diferentes de um arquivo em um arquivo mesclado. Ferramentas de mesclagem são
dados os dois arquivos e o maior ancestral comum das duas versões de arquivo, para que eles possam
determinar as alterações feitas em ambos os ramos.

Ferramentas de mesclagem são usadas para hg resolver, hg fundir, hg atualizar, hg voltar e os vários
extensões.

Normalmente, a ferramenta de mesclagem tenta reconciliar automaticamente os arquivos combinando todos
mudanças não sobrepostas que ocorreram separadamente nas duas diferentes evoluções do
mesmo arquivo base inicial. Além disso, alguns programas de mesclagem interativos tornam mais fácil
resolver manualmente mesclagens conflitantes, de forma gráfica ou inserindo alguns
marcadores de conflito. O Mercurial não inclui nenhum programa interativo de mesclagem, mas depende de
ferramentas externas para isso.

Disponível fundir ferramentas
Ferramentas de mesclagem externas e suas propriedades são configuradas na configuração de ferramentas de mesclagem
seção - ver hgrc(5) - mas muitas vezes eles podem apenas ser nomeados por seu executável.

Uma ferramenta de mesclagem é geralmente utilizável se seu executável puder ser encontrado no sistema e se
pode lidar com a mesclagem. O executável é encontrado se for um executável absoluto ou relativo
caminho ou o nome de um aplicativo no caminho de pesquisa do executável. A ferramenta é assumida para
ser capaz de lidar com a fusão se puder lidar com links simbólicos se o arquivo for um link simbólico, se puder
lidar com arquivos binários se o arquivo for binário e se uma GUI estiver disponível se a ferramenta exigir
uma GUI.

Existem algumas ferramentas de mesclagem internas que podem ser usadas. As ferramentas de mesclagem internas são:

:jogar fora

Cria três versões dos arquivos a serem mesclados, contendo o conteúdo do local,
outro e base. Esses arquivos podem então ser usados ​​para realizar uma mesclagem manualmente. Se o
arquivo a ser mesclado é nomeado a.txt, esses arquivos serão devidamente nomeados
a.txt.local, a.txt.outro e a.txt.base e eles serão colocados no mesmo
diretório como a.txt.

:falhou

Em vez de tentar mesclar arquivos que foram modificados em ambas as ramificações, ele marca
eles como não resolvidos. O comando resolve deve ser usado para resolver esses conflitos.

:local

Usa a versão local dos arquivos como a versão mesclada.

: mesclar

Usa o algoritmo de mesclagem simples não interativo interno para mesclar arquivos. Ele vai
falhará se houver algum conflito e deixará marcadores no arquivo parcialmente mesclado.
Os marcadores terão duas seções, uma para cada lado da fusão.

: merge-local

Como: mesclar, mas resolver todos os conflitos de forma não interativa em favor do local
alterações.

: merge-other

Como: mesclar, mas resolver todos os conflitos de forma não interativa em favor do outro
alterações.

: merge3

Usa o algoritmo de mesclagem simples não interativo interno para mesclar arquivos. Ele vai
falhará se houver algum conflito e deixará marcadores no arquivo parcialmente mesclado.
O marcador terá três seções, uma de cada lado da fusão e uma para o
conteúdo básico.

:de outros

Usa a outra versão de arquivos como a versão mesclada.

:mensagem

Pergunta ao usuário qual versão local ou outra versão deve ser mantida como a
versão.

: tagmerge

Usa o algoritmo de mesclagem de tag interno (experimental).

:União

Usa o algoritmo de mesclagem simples não interativo interno para mesclar arquivos. Ele vai
use os lados esquerdo e direito para regiões de conflito. Nenhum marcador é inserido.

Ferramentas internas estão sempre disponíveis e não requerem uma GUI, mas por padrão não
lidar com links simbólicos ou arquivos binários.

Escolher a fundir ferramenta
O Mercurial usa essas regras ao decidir qual ferramenta de mesclagem usar:

1. Se uma ferramenta tiver sido especificada com a opção --tool para mesclar ou resolver, ela será usada.
Se for o nome de uma ferramenta na configuração das ferramentas de mesclagem, sua configuração é
usava. Caso contrário, a ferramenta especificada deve ser executável pelo shell.

2. Se o HGMERGE variável de ambiente está presente, seu valor é usado e deve ser
executável pelo shell.

3. Se o nome do arquivo a ser mesclado corresponder a qualquer um dos padrões no
seção de configuração de padrões de mesclagem, a primeira ferramenta de mesclagem utilizável correspondente a um
padrão de correspondência é usado. Aqui, os recursos binários da ferramenta de mesclagem não são
considerado.

4. Se ui.merge for definido, ele será considerado o próximo. Se o valor não for o nome de um
ferramenta configurada, o valor especificado é usado e deve ser executável pelo shell.
Caso contrário, a ferramenta nomeada é usada se for utilizável.

5. Se alguma ferramenta de mesclagem utilizável estiver presente na seção de configuração de ferramentas de mesclagem, aquela
com a prioridade mais alta é usado.

6. Se um programa chamado hgmerge pode ser encontrado no sistema, ele é usado - mas será por
padrão não deve ser usado para links simbólicos e arquivos binários.

7. Se o arquivo a ser mesclado não for binário e não for um link simbólico, então interno : mesclar is
usava.

8. A mesclagem do arquivo falha e deve ser resolvida antes do commit.

Nota Depois de selecionar um programa de mesclagem, o Mercurial tentará, por padrão, mesclar o
arquivos usando um algoritmo de mesclagem simples primeiro. Só se não der certo por causa de
mudanças conflitantes O Mercurial realmente executará o programa de mesclagem. Se para
usar o algoritmo de mesclagem simples primeiro pode ser controlado pela configuração pré-emergir de
a ferramenta de mesclagem. Premerge é habilitado por padrão, a menos que o arquivo seja binário ou um
link simbólico.

Veja as ferramentas de mesclagem e as seções de interface do usuário de hgrc(5) para obter detalhes sobre a configuração de fusão
ferramentas.

ESPECIFICANDO MÚLTIPLO REVISÕES

Quando o Mercurial aceita mais de uma revisão, elas podem ser especificadas individualmente, ou
fornecido como um intervalo topologicamente contínuo, separado pelo caractere ":".

A sintaxe da notação de intervalo é [BEGIN]: [END], onde BEGIN e END são revisão
identificadores. Ambos BEGIN e END são opcionais. Se BEGIN não for especificado, o padrão é
revisão número 0. Se END não for especificado, o padrão é a dica. O intervalo ":" assim
significa "todas as revisões".

Se BEGIN for maior que END, as revisões serão tratadas na ordem inversa.

Um intervalo atua como um intervalo fechado. Isso significa que um intervalo de 3: 5 resulta em 3, 4 e 5.
Da mesma forma, um intervalo de 9: 6 resulta em 9, 8, 7 e 6.

ARQUIVO NOME PADRÕES

O Mercurial aceita várias notações para identificar um ou mais arquivos por vez.

Por padrão, o Mercurial trata os nomes de arquivos como padrões glob estendidos no estilo shell.

As notações de padrão alternativo devem ser especificadas explicitamente.

Padrões de nota especificados em .hgignore não estão enraizados. Por favor, veja hg ajudar Hgignore para
Detalhes.

Para usar um nome de caminho simples sem nenhuma correspondência de padrão, comece com caminho:. Este caminho
os nomes devem corresponder completamente a partir da raiz do repositório atual.

Para usar um glob estendido, comece um nome com globo:. Globs estão enraizados no atual
diretório; um globo como * .c irá corresponder apenas a arquivos no diretório atual terminando com
.c.

As extensões de sintaxe glob suportadas são ** para corresponder a qualquer string entre separadores de caminho e
{a, b} para significar "a ou b".

Para usar uma expressão regular Perl / Python, comece um nome com RE:. Correspondência de padrão regexp
está ancorado na raiz do repositório.

Para ler os padrões de nome de um arquivo, use arquivo de listagem: or listaarquivo0:. O último espera nulo
padrões delimitados, enquanto o anterior espera avanços de linha. Cada string lida do arquivo é
em si tratada como um padrão de arquivo.

Para ler um conjunto de padrões de um arquivo, use incluem: or subincluir:. incluem: vai usar tudo
os padrões do arquivo fornecido e tratá-los como se tivessem sido transmitidos manualmente.
subincluir: irá apenas aplicar os padrões contra os arquivos que estão sob o subinclude
diretório do arquivo. Ver hg ajudar Hgignore para obter detalhes sobre o formato desses arquivos.

Todos os padrões, exceto para globo: especificado na linha de comando (não para -I or -X opções), pode
corresponder também a diretórios: os arquivos em diretórios correspondidos são tratados como correspondidos.

Exemplos simples:

caminho: foo / bar uma barra de nome em um diretório chamado foo na raiz
do repositório
caminho: caminho: nomeie um arquivo ou diretório chamado "caminho: nome"

Exemplos Glob:

glob: *. c qualquer nome terminado em ".c" no diretório atual
* .c qualquer nome terminado em ".c" no diretório atual
**. c qualquer nome terminado em ".c" em qualquer subdiretório do
diretório atual incluindo ele mesmo.
foo / *. c qualquer nome terminado em ".c" no diretório foo
foo / **. c qualquer nome terminado em ".c" em qualquer subdiretório de foo
incluindo a si mesmo.

Exemplos de regexp:

re:. * \. c $ qualquer nome terminado em ".c", em qualquer lugar do repositório

Exemplos de arquivos:

listfile: list.txt leia a lista de list.txt com um padrão de arquivo por linha
listfile0: list.txt lista de leitura de list.txt com delimitadores de bytes nulos

Veja também hg ajudar conjuntos de arquivos.

Incluir exemplos:

incluem: padrões de leitura de path / to / mypatternfile a serem aplicados a todos os caminhos
subinclude: path / to / subignorefile lê padrões especificamente para caminhos no
subdiretório

TRABALHO COM FASES

O Quê e guarante que os mesmos estão fases?
As fases são um sistema para rastrear quais changesets foram ou deveriam ser compartilhados. Isto
ajuda a evitar erros comuns ao modificar o histórico (por exemplo, com o mq ou rebase
extensões).

Cada conjunto de alterações em um repositório está em uma das seguintes fases:

· Público: o conjunto de alterações é visível em um servidor público

· Rascunho: o conjunto de alterações ainda não foi publicado

· Segredo: o changeset não deve ser empurrado, puxado ou clonado

Essas fases são ordenadas (público <rascunho <segredo) e nenhum conjunto de alterações pode estar em um nível inferior
fase do que seus ancestrais. Por exemplo, se um changeset é público, todos os seus ancestrais são
também público. Por último, as fases do changeset só devem ser alteradas para a fase pública.

Como funciona o dobrador de carta de canal e guarante que os mesmos estão fases gerenciou?
Na maioria das vezes, as fases devem funcionar de forma transparente. Por padrão, um changeset é criado em
a fase de rascunho e passa para a fase pública quando é empurrado para outro
repositório.

Uma vez que os changesets se tornem públicos, extensões como mq e rebase se recusarão a operar em
para evitar a criação de changesets duplicados. As fases também podem ser manipuladas manualmente
com o hg fase comando se necessário. Ver hg ajudar -v fase por exemplo.

Para tornar seus commits secretos por padrão, coloque isso em seu arquivo de configuração:

[fases]
new-commit = segredo

Fases e Servidores
Normalmente, todos os servidores são publicação por padrão. Isso significa:

- todos os conjuntos de alterações de rascunho puxados ou clonados aparecem em fase
público no cliente

- todos os conjuntos de alterações de rascunho que são enviados aparecem como públicos em ambos
cliente e servidor

- changesets secretos não são empurrados, puxados ou clonados

Nota Puxar um changeset de rascunho de um servidor de publicação não o marca como público em
do lado do servidor devido à natureza somente leitura do pull.

Às vezes, pode ser desejável enviar e receber changesets na fase de rascunho para compartilhar
trabalho inacabado. Isso pode ser feito configurando um repositório para desativar a publicação em seu
arquivo de configuração:

[fases]
publicar = falso

See hg ajudar configuração para obter mais informações sobre os arquivos de configuração.

Nota Os servidores que executam versões mais antigas do Mercurial são tratados como publicação.

Nota Os conjuntos de alterações na fase secreta não são trocados com o servidor. Isso se aplica a seus
conteúdo: nomes de arquivo, conteúdo de arquivo e metadados de conjunto de alterações. Por razões técnicas,
o identificador (por exemplo, d825e4025e39) do changeset secreto pode ser comunicado a
o servidor.

Exemplos
· Listar as alterações em fase de rascunho ou secreta:

hg log -r "não público ()"

· Alterar todos os changesets secretos para rascunho:

fase hg - rascunho "secreto ()"

· Mover à força o changeset atual e descendentes de público para rascunho:

fase hg --force --draft.

· Mostrar uma lista de revisão e fase do changeset:

hg log --template "{rev} {phase} \ n"

· Ressincronizar changesets de rascunho em relação a um repositório remoto:

hg phase -fd "saída (URL)"

See hg ajudar fase para obter mais informações sobre como manipular manualmente as fases.

ESPECIFICANDO ÚNICA REVISÕES

O Mercurial oferece suporte a várias maneiras de especificar revisões individuais.

Um inteiro simples é tratado como um número de revisão. Inteiros negativos são tratados como
deslocamentos sequenciais da ponta, com -1 denotando a ponta, -2 denotando a revisão anterior
até a ponta e assim por diante.

Uma string hexadecimal de 40 dígitos é tratada como um identificador de revisão exclusivo.

Uma string hexadecimal com menos de 40 caracteres é tratada como uma revisão única
identificador e é referido como um identificador de forma abreviada. Um identificador de formato curto é apenas
válido se for o prefixo de exatamente um identificador de comprimento total.

Qualquer outra string é tratada como um marcador, tag ou nome de ramificação. Um marcador é um móvel
ponteiro para uma revisão. Uma tag é um nome permanente associado a uma revisão. Um nome de filial
denota a ponta mais aberta do galho desse galho - ou, se todos estiverem fechados, o
ponta mais fechada do galho. Nomes de marcadores, tags e ramificações não devem conter o
":" personagem.

O nome reservado "dica" sempre identifica a revisão mais recente.

O nome reservado "nulo" indica a revisão nula. Esta é a revisão de um vazio
repositório e o pai da revisão 0.

O nome reservado "." indica o pai do diretório de trabalho. Se nenhum diretório de trabalho for
verificado, é equivalente a nulo. Se uma mesclagem não confirmada estiver em andamento, "." é o
revisão do primeiro pai.

ESPECIFICANDO REVISÃO CONJUNTOS

O Mercurial oferece suporte a uma linguagem funcional para selecionar um conjunto de revisões.

A linguagem suporta vários predicados que são unidos por operadores infixos.
Os parênteses podem ser usados ​​para agrupamento.

Identificadores como nomes de ramos podem precisar ser citados com aspas simples ou duplas se eles
contém personagens como - ou se eles correspondem a um dos predicados predefinidos.

Caracteres especiais podem ser usados ​​em identificadores entre aspas, escapando deles, por exemplo, \n is
interpretado como uma nova linha. Para evitar que sejam interpretados, strings podem ser prefixadas
com r, por exemplo r '...'.

Existe um único operador de prefixo:

não x

Conjuntos de alterações não em x. O formato curto é ! x.

Estes são os operadores infixados com suporte:

x :: y

Um intervalo DAG, significando todos os conjuntos de alterações que são descendentes de xe ancestrais de y,
incluindo os próprios xey. Se o primeiro ponto final for deixado de fora, isso é equivalente
para ancestrais (y), se o segundo for omitido, é equivalente a descendentes (x).

Uma sintaxe alternativa é x..y.

x: y

Todos os changesets com números de revisão entre xey, ambos inclusivos. Qualquer
o endpoint pode ser omitido, o padrão é 0 e tip.

x e y

A interseção de changesets em xe y. O formato curto é x & y.

x or y

A união de conjuntos de mudanças em x e y. Existem duas formas alternativas de abreviação: x | y
e x + y.

x - y

Conjuntos de alterações em x, mas não em y.

x ^ n

O enésimo pai de x, n == 0, 1 ou 2. Para n == 0, x; para n == 1, o primeiro pai
de cada changeset em x; para n == 2, o segundo pai do changeset em x.

x ~ n

O enésimo primeiro ancestral de x; x ~ 0 é x; x ~ 3 is x ^^^.

Existe um único operador Postfix:

x^

Equivalente a x ^ 1, o primeiro pai de cada changeset em x.

Os seguintes predicados são suportados:

adiciona (padrão)

Conjuntos de alterações que adicionam um padrão de correspondência de arquivo.

O padrão sem tipo explícito como globo: é esperado que seja relativo ao
diretório atual e corresponder a um arquivo ou diretório.

todo()

Todos os changesets, o mesmo que 0: dica.

ancestral (* changeset)

O maior ancestral comum dos changesets.

Aceita 0 ou mais changesets. Retornará uma lista vazia quando nenhum argumento for passado.
O maior ancestral comum de um único changeset é esse changeset.

ancestrais (conjunto)

Conjuntos de alterações que são ancestrais de um conjunto de alterações no conjunto.

autor (string)

Alias ​​para usuário (string).

bisect (string)

Conjuntos de alterações marcados no status da bissetriz especificada:

· Bom estado, com sinais de uso, ruim, pular: csets marcados explicitamente como bom / mau / pular

· bens, coisas ruins : csets topologicamente bom / ruim

· alcance : csets participando da bissecção

· podada : csets que são bons, ruins ou ignorados

· não testado : csets cujo destino ainda é desconhecido

· ignoradas : csets ignorados devido à topologia DAG

· atual : o cset está sendo dividido ao meio

marcador ([nome])

O marcador nomeado ou todos os marcadores.

If nome começa com RE:, o restante do nome é tratado como um
expressão. Para corresponder a um favorito que realmente começa com RE:, use o prefixo
literal:.

ramo (corda or definido)

Todos os changesets pertencentes a um determinado ramo ou ramos de determinado
conjuntos de alterações.

If corda começa com RE:, o restante do nome é tratado como um
expressão. Para combinar um branch que realmente começa com RE:, use o prefixo
literal:.

branchpoint ()

Conjuntos de alterações com mais de um filho.

bateu ()

Changesets mutáveis ​​marcados como sucessores de changesets públicos.

Apenas conjuntos de alterações não públicos e não obsoletos podem ser colidido.

agrupar()

Conjuntos de alterações no pacote.

O pacote deve ser especificado pela opção -R.

crianças (conjunto)

Changesets filho de changesets no conjunto.

fechado()

O conjunto de alterações está fechado.

contém (padrão)

O manifesto da revisão contém um padrão de correspondência de arquivo (mas não pode modificá-lo).
See hg ajudar padrões para obter informações sobre padrões de arquivo.

O padrão sem tipo explícito como globo: é esperado que seja relativo ao
diretório atual e compara com um arquivo exatamente para eficiência.

convertido ([id])

Conjuntos de alterações convertidos do identificador fornecido no repositório antigo, se presente, ou
todos os conjuntos de alterações convertidos se nenhum identificador for especificado.

data (intervalo)

Conjuntos de alterações dentro do intervalo, consulte hg ajudar datas.

desc (string)

Pesquisar mensagem de confirmação para string. A correspondência não diferencia maiúsculas de minúsculas.

descendentes (conjunto)

Conjuntos de alterações que são descendentes de conjuntos de alterações no conjunto.

destino ([definir])

Conjuntos de alterações que foram criados por uma operação de enxerto, transplante ou rebase, com o
determinadas revisões especificadas como a fonte. Omitir o conjunto opcional é o mesmo que
passando todos ().

divergente()

Sucessores finais de changesets com um conjunto alternativo de sucessores finais.

rascunho()

Conjunto de alterações na fase de rascunho.

extinto()

Changesets obsoletos apenas com descendentes obsoletos.

extra (etiqueta, [valor])

Conjuntos de alterações com o rótulo fornecido nos metadados extras, com o opcional fornecido
valor.

If valor começa com RE:, o restante do valor é tratado como um
expressão. Para corresponder a um valor que realmente começa com RE:, use o prefixo
literal:.

arquivo (padrão)

Conjuntos de alterações afetando arquivos correspondidos por padrão.

Para um resultado mais rápido, mas menos preciso, considere usar filelog () ao invés.

Este predicado usa globo: como o tipo de padrão padrão.

filelog (padrão)

Conjuntos de alterações conectados ao filelog especificado.

Por motivos de desempenho, visita apenas as revisões mencionadas no registro de arquivos em nível de arquivo,
em vez de filtrar por todos os conjuntos de alterações (muito mais rápido, mas não inclui
exclui ou duplica alterações). Para um resultado mais lento e preciso, use Arquivo().

O padrão sem tipo explícito como globo: é esperado que seja relativo ao
diretório atual e compara com um arquivo exatamente para eficiência.

Se algum linkrev apontar para revisões filtradas pela revisão atual, nós trabalharemos
em torno dele para retornar um valor não filtrado.

primeiro set, [n])

Um alias para limit ().

seguir ([padrão])

Um alias para ::. (ancestrais do primeiro pai do diretório de trabalho). Se padrão
é especificado, o histórico de arquivos que correspondem a um determinado padrão é seguido, incluindo
cópias.

grep (regex)

Como palavra-chave (string) mas aceita um regex. Usar grep (r '...') para garantir uma fuga especial
os caracteres são tratados corretamente. diferente palavra-chave (string), a partida é
maiúsculas e Minúsculas.

cabeça()

O conjunto de alterações é um cabeçalho de ramificação nomeado.

cabeças (conjunto)

Membros do conjunto sem filhos no conjunto.

escondido()

Changesets ocultos.

id (string)

Revisão especificada de forma não ambígua pelo prefixo hexadecimal fornecido.

palavra-chave (string)

Pesquise a mensagem de confirmação, o nome do usuário e os nomes dos arquivos alterados para a string. O jogo
não faz distinção entre maiúsculas e minúsculas.

último (conjunto, [n])

Últimos n membros do conjunto, padronizado para 1.

limite (definir [, n [, Deslocamento]])

Primeiros n membros do conjunto, padronizado para 1, começando do deslocamento.

correspondência (revisão [, campo])

Conjuntos de alterações em que um determinado conjunto de campos corresponde ao conjunto de campos no selecionado
revisão ou conjunto.

Para corresponder a mais de um campo passe a lista de campos a combinar separados por espaços
(por exemplo: autor descrição).

Os campos válidos são a maioria dos campos de revisão regulares e alguns campos especiais.

Os campos de revisão regular são descrição, autor, ramo, dados, arquivos, fase,
pais, subestado, usuário e diff. Observe que autor e usuário são sinônimos. diff
refere-se ao conteúdo da revisão. Duas revisões combinando com seus diff também vai
combinar com eles arquivos.

Campos especiais são resumo e metadados: resumo corresponde à primeira linha do
descrição. metadados é equivalente a combinar descrição usuário dados (isto é
corresponde aos principais campos de metadados).

metadados é o campo padrão que é usado quando nenhum campo é especificado. Você pode
corresponder a mais de um campo por vez.

max (set)

Conjunto de alterações com maior número de revisão no conjunto.

mesclar ()

O conjunto de alterações é um conjunto de alterações de mesclagem.

min (set)

Conjunto de alterações com o menor número de revisão no conjunto.

modifica (padrão)

Conjuntos de alterações modificando arquivos correspondidos por padrão.

O padrão sem tipo explícito como globo: é esperado que seja relativo ao
diretório atual e corresponder a um arquivo ou diretório.

nomeado (namespace)

Os conjuntos de alterações em um determinado namespace.

If namespace começa com RE:, o restante da string é tratado como um
expressão. Para corresponder a um namespace que realmente começa com RE:, use o prefixo
literal:.

obsoleto()

Changeset mutável com uma versão mais recente.

apenas (definir, [definir])

Conjuntos de alterações que são ancestrais do primeiro conjunto que não são ancestrais de nenhum outro
cabeça no repo. Se um segundo conjunto for especificado, o resultado serão ancestrais do
primeiro conjunto que não são ancestrais do segundo conjunto (ou seja: - :: )

origem ([definir])

Conjuntos de alterações que foram especificados como uma fonte para os enxertos, transplantes ou rebases
que criou as revisões fornecidas. Omitir o conjunto opcional é o mesmo que passar
tudo(). Se um conjunto de alterações criado por essas operações for ele próprio especificado como uma fonte
para uma dessas operações, apenas o changeset de origem para a primeira operação é
selecionado.

saída ([caminho])

Conjuntos de alterações não encontrados no repositório de destino especificado ou no push padrão
localização.

p1 ([definir])

Primeiro pai dos conjuntos de alterações no conjunto ou o diretório de trabalho.

p2 ([definir])

Segundo pai de changesets em conjunto ou o diretório de trabalho.

pais ([set])

O conjunto de todos os pais para todos os conjuntos de alterações no conjunto ou o diretório de trabalho.

presente (conjunto)

Um conjunto vazio, se qualquer revisão no conjunto não for encontrada; caso contrário, todas as revisões no conjunto.

Se alguma das revisões especificadas não estiver presente no repositório local, a consulta é
normalmente abortado. Mas este predicado permite que a consulta continue mesmo em tais
casos.

público()

Conjunto de alterações em fase pública.

remoto ([id [,caminho]])

Revisão local que corresponde ao identificador fornecido em um repositório remoto, se
presente. Aqui o '.' identificador é um sinônimo para a filial local atual.

remove (padrão)

Conjuntos de alterações que removem arquivos que correspondem ao padrão.

O padrão sem tipo explícito como globo: é esperado que seja relativo ao
diretório atual e corresponder a um arquivo ou diretório.

rev (número)

Revisão com o identificador numérico fornecido.

reverso (conjunto)

Ordem inversa do conjunto.

raízes (conjunto)

Conjuntos de alterações em conjunto sem conjunto de alterações pai no conjunto.

segredo()

Conjunto de alterações em fase secreta.

classificar (definir [, [-]chave...])

Classificar conjunto por chaves. A ordem de classificação padrão é crescente, especifique uma chave como -chave para
classificar em ordem decrescente.

As chaves podem ser:

· rev para o número de revisão,

· ramo para o nome da filial,

· desc para a mensagem de confirmação (descrição),

· usuário para nome de usuário (autor pode ser usado como um alias),

· dados para a data de confirmação

subrepo ([padrão])

Conjuntos de alterações que adicionam, modificam ou removem o subrepo fornecido. Se nenhum padrão de subrepo for
nomeado, todas as alterações do subrepo são retornadas.

tag ([nome])

A marca especificada por nome, ou todas as revisões marcadas se nenhum nome for fornecido.

If nome começa com RE:, o restante do nome é tratado como um
expressão. Para corresponder a uma tag que realmente começa com RE:, use o prefixo literal:.

instável()

Changesets não obsoletos com ancestrais obsoletos.

usuário (string)

O nome de usuário contém string. A correspondência não diferencia maiúsculas de minúsculas.

If corda começa com RE:, o restante da string é tratado como um
expressão. Para corresponder a um usuário que realmente contém RE:, use o prefixo literal:.

Novos predicados (conhecidos como "aliases") podem ser definidos, usando qualquer combinação de
predicados ou outros apelidos. Uma definição de alias se parece com:

=

no revsetálias seção de um arquivo de configuração do Mercurial. Argumentos da forma $1,
$2, etc. são substituídos do alias na definição.

Por exemplo,

[revsetálias]
h = cabeças ()
d ($ 1) = classificação ($ 1, data)
rs ($ 1, $ 2) = reverso (ordenar ($ 1, $ 2))

define três aliases, h, d e rs. rs (0: dica, autor) é exatamente equivalente a
reverso (classificar (0: dica, autor)).

Um operador infixo ## pode concatenar strings e identificadores em uma string. Por exemplo:

[revsetálias]
problema ($ 1) = grep (r '\ bissue [:]?' ## $ 1 ## r '\ b | \ bbug \ (' ## $ 1 ## r '\)')

emitem(1234) é equivalente a grep (r '\ bissue [ :]? 1234 \ b | \ bbug \ (1234 \) ') nesse caso. Isto
corresponde a todos os "problema 1234", "problema: 1234", "problema 1234" e "erro(1234) ".

Todos os outros operadores prefix, infix e postfix têm prioridade mais baixa do que ##. Por exemplo, a $1
## $ 2 ~ 2 é equivalente a ($ 1 ## $ 2) ~ 2.

Equivalentes de linha de comando para hg log:

-f -> ::.
-dx -> data (x)
-kx -> palavra-chave (x)
-m -> mesclar ()
-ux -> usuário (x)
-bx -> branch (x)
-P x ->! :: x
-lx -> limite (expr, x)

Alguns exemplos de consultas:

· Conjuntos de alterações no branch padrão:

hg log -r "branch (padrão)"

· Changesets no branch padrão desde a tag 1.5 (excluindo merges):

hg log -r "branch (padrão) e 1.5 :: and not merge ()"

· Cabeças de filial abertas:

hg log -r "cabeça () e não fechada ()"

· Conjuntos de alterações entre as tags 1.3 e 1.5 mencionando "bug" que afetam hgext / *:

hg log -r "1.3 :: 1.5 e palavra-chave (bug) e arquivo ('hgext / *')"

· Conjuntos de alterações comprometidos em maio de 2008, classificados por usuário:

hg log -r "sort (date ('May 2008'), user)"

· Conjuntos de alterações mencionando "bug" ou "problema" que não estão em uma versão marcada:

hg log -r "(palavra-chave (bug) ou palavra-chave (problema)) e não ancestrais (tag ())"

USANDO MERCURIAL A PARTIR DE CRITÉRIOS E AUTOMAÇÃO

É comum que máquinas (ao contrário de humanos) consumam Mercurial. Este tópico de ajuda
descreve algumas das considerações para fazer a interface de máquinas com o Mercurial.

Escolher an Interface
As máquinas podem escolher vários métodos para fazer a interface com o Mercurial. Esses incluem:

· Executando o hg processo

· Consultando um servidor HTTP

· Chamada para um servidor de comando

Executando hg processos é muito semelhante a como os humanos interagem com o Mercurial na casca.
Já deve ser familiar para você.

hg servir pode ser usado para iniciar um servidor. Por padrão, isso iniciará um servidor HTTP "hgweb".
Este servidor HTTP tem suporte para saída legível por máquina, como JSON. Para mais, veja hg
ajudar hgweb.

hg servir também pode iniciar um "servidor de comando". Os clientes podem se conectar a este servidor e emitir
Comandos Mercurial sobre um protocolo especial. Para obter mais detalhes sobre o servidor de comando,
incluindo links para bibliotecas de cliente, consulte https://mercurial.selenic.com/wiki/CommandServer.

hg servir interfaces baseadas (o hgweb e servidores de comando) têm a vantagem sobre o simples
hg processe invocações no sentido de que são provavelmente mais eficientes. Isso é porque há
sobrecarga significativa para gerar novos processos Python.

Dica Se você precisar invocar vários hg processos em curto prazo e / ou desempenho é
importante para você, o uso de uma interface baseada em servidor é altamente recomendado.

Meio Ambiente Variáveis
Conforme documentado em hg ajudar meio Ambiente, várias variáveis ​​de ambiente influenciam o
operação do Mercurial. Os itens a seguir são particularmente relevantes para máquinas que consomem
Mercurial:

HGPLAIN
Se não for definido, a saída do Mercurial pode ser influenciada por definições de configuração que
impactar sua codificação, modo detalhado, localização, etc.

É altamente recomendado que as máquinas definam esta variável ao invocar hg
processos.

CODIFICAÇÃO HGEN
Se não for definido, o local usado pelo Mercurial será detectado no ambiente. Se
a localidade determinada não suporta a exibição de certos caracteres, o Mercurial pode
renderizar essas sequências de caracteres incorretamente (geralmente usando "?" como um espaço reservado
para caracteres inválidos no local atual).

Definir explicitamente esta variável de ambiente é uma boa prática para garantir
resultados consistentes. "utf-8" é uma boa escolha em ambientes do tipo UNIX.

HGRCPATH
Se não for definido, o Mercurial herdará as opções de configuração dos arquivos de configuração usando o
processo descrito em hg ajudar configuração. Isso inclui herdar o usuário ou todo o sistema
arquivos de configuração.

Quando o controle máximo sobre a configuração do Mercurial é desejado, o valor de
HGRCPATH pode ser definido como um arquivo explícito com configurações boas conhecidas. Em casos raros, o
valor pode ser definido como um arquivo vazio ou dispositivo nulo (frequentemente / dev / null) para contornar
carregamento de qualquer usuário ou arquivo de configuração do sistema. Observe que essas abordagens podem ter
consequências indesejadas, já que os arquivos de configuração do usuário e do sistema costumam definir as coisas
como o nome de usuário e as extensões que podem ser necessárias para fazer a interface com um
repositório.

Consumir Command saída
É comum que as máquinas precisem analisar a saída dos comandos do Mercurial para dados relevantes
dados. Esta seção descreve as várias técnicas para fazer isso.

Análise Cru Command saída
Provavelmente, a solução mais simples e eficaz para consumir a saída do comando é simplesmente
invocar hg comandos como você faria como um usuário e analise sua saída.

A saída de muitos comandos pode ser facilmente analisada com ferramentas como grep, sede e awk.

Uma desvantagem potencial com a análise da saída do comando é que a saída dos comandos pode mudar
quando o Mercurial é atualizado. Embora o Mercurial geralmente se esforce para obter um forte retrocesso
compatibilidade, a saída do comando muda ocasionalmente. Ter testes para o seu
interações com hg comandos geralmente são recomendados, mas são ainda mais importantes quando
a análise bruta da saída do comando está envolvida.

utilização Modelos para Control saída
Muitos hg comandos suportam saída modelada por meio do -T / - modelo argumento. Para mais, veja
hg ajudar modelos.

Os modelos são úteis para controlar explicitamente a saída para que você obtenha exatamente os dados
você deseja formatado como você deseja. Por exemplo, log -T {nó} \ n pode ser usado para imprimir um
lista delimitada por nova linha de nós do changeset em vez de uma saída personalizada contendo
autores, datas, descrições, etc.

Dica Se analisar a saída do comando bruto é muito complicado, considere o uso de modelos para fazer
sua vida mais fácil.

A -T / - modelo argumento permite especificar estilos predefinidos. Mercurial navega com o
estilos legíveis por máquina json e xml, que fornecem saída JSON e XML, respectivamente.
Eles são úteis para produzir resultados legíveis por máquina no estado em que se encontram.

importante
A json e xml estilos são considerados experimentais. Embora possam ser atraentes
para usar para obter facilmente saída legível por máquina, seu comportamento pode mudar em
versões subsequentes.

Esses estilos também podem exibir resultados inesperados ao lidar com certos
codificações. O Mercurial trata coisas como nomes de arquivos como uma série de bytes e
normalizar certas sequências de bytes para JSON ou XML com certas configurações de codificação
pode levar a surpresas.

Command servidor saída
Se estiver usando o servidor de comando para interagir com o Mercurial, provavelmente você está usando um existente
biblioteca / API que abstrai os detalhes de implementação do servidor de comando. Se sim, este
camada de interface pode realizar a análise para você, poupando o trabalho de implementá-la
você mesmo.

saída Verbosidade
Os comandos muitas vezes têm verbosidade de saída variável, mesmo quando estilos legíveis por máquina estão sendo
usado (por exemplo -T json) Adicionando -v / - verboso e --depurar aos argumentos do comando podem
aumentar a quantidade de dados expostos pelo Mercurial.

Uma forma alternativa de obter os dados de que você precisa é especificando explicitamente um modelo.

Outros Temas
reviravoltas
Conjuntos de revisões é uma linguagem de consulta funcional para selecionar um conjunto de revisões.
Pense nisso como SQL para repositórios Mercurial. Revsets são úteis para consultar
repositórios para dados específicos.

See hg ajudar reviravoltas para mais.

share extensão
A share extensão fornece funcionalidade para compartilhar dados de repositório entre
várias cópias de trabalho. Ele pode até "agrupar" automaticamente o armazenamento para logicamente
repositórios relacionados durante a clonagem.

Configurando o share extensão pode levar a uma utilização significativa de recursos
redução, especialmente em torno do espaço em disco e da rede. Isso é especialmente verdade
para ambientes de integração contínua (CI).

See hg ajudar -e share para mais.

SUBREPOSITÓRIOS

Subrepositórios permitem que você aninhe repositórios externos ou projetos em um Mercurial pai
repositório, e comandos make operam neles como um grupo.

Mercurial atualmente suporta subrepositórios Mercurial, Git e Subversion.

Os subrepositórios são compostos por três componentes:

1. Verificações de repositório aninhado. Eles podem aparecer em qualquer lugar no diretório de trabalho pai.

2. Referências de repositório aninhado. Eles são definidos em .hgsub, que deve ser colocado no
raiz do diretório de trabalho e dizer de onde vêm os checkouts do subrepositório.
Subrepositórios mercuriais são referenciados como:

caminho / para / nested = https://example.com/nested/repo/path

Subrepos Git e Subversion também são suportados:

caminho / para / nested = [git] git: //example.com/nested/repo/path
caminho / para / nested = [svn] https://example.com/nested/trunk/path

onde caminho / para / aninhado é o local de checkout relativamente à raiz Mercurial pai,
e https://example.com/nested/repo/path é o caminho do repositório de origem. A fonte pode
também faz referência a um caminho do sistema de arquivos.

Observe que .hgsub não existe por padrão nos repositórios Mercurial, você deve
crie e adicione-o ao repositório pai antes de usar subrepositórios.

3. Estados do repositório aninhado. Eles são definidos em .hgsubstato, que é colocado na raiz
do diretório de trabalho e capturar todas as informações necessárias para restaurar o
subrepositórios para o estado em que foram confirmados em um changeset do repositório pai.
O Mercurial registra automaticamente os estados dos repositórios aninhados ao fazer o commit no
repositório pai.

Note
A .hgsubstato arquivo não deve ser editado manualmente.

Adicionando a Subrepositório
If .hgsub não existe, crie-o e adicione-o ao repositório pai. Clone ou checkout
os projetos externos onde você deseja que ele more no repositório pai. Editar .hgsub e
adicione a entrada do subrepositório conforme descrito acima. Neste ponto, o subrepositório é
rastreado e o próximo commit registrará seu estado em .hgsubstato e ligá-lo ao
conjunto de alterações confirmado.

Sincronizando a Subrepositório
Os subrepos não rastreiam automaticamente o conjunto de alterações mais recente de suas fontes. Em vez disso, eles
são atualizados para o conjunto de alterações que corresponde ao conjunto de alterações verificado no
changeset de nível superior. Isso ocorre para que os desenvolvedores sempre obtenham um conjunto consistente de códigos compatíveis
e bibliotecas quando são atualizados.

Portanto, a atualização de subrepostos é um processo manual. Basta verificar o subrepo de destino no
revisão desejada, teste no repositório de nível superior e, em seguida, confirme no repositório pai para
registre a nova combinação.

Excluindo a Subrepositório
Para remover um subrepositório do repositório pai, exclua sua referência de .hgsub,
em seguida, remova seus arquivos.

Interação com mercurial comandos
adicionar add não recursiva em subrepos, a menos que -S / - subrepos seja especificado. No entanto, se
você especifica o caminho completo de um arquivo em um subrepo, ele será adicionado mesmo sem
-S / - subrepos especificados. Os subrepositórios do Subversion estão atualmente silenciosos
ignorado.

adicionar remover
addremove não recursivamente em subrepostos, a menos que -S / - subrepos seja especificado.
No entanto, se você especificar o caminho completo de um diretório em um subrepo, addremove irá
ser executado nele mesmo sem -S / - subrepos sendo especificados. Git e Subversion
os subrepositórios imprimirão um aviso e continuarão.

arquivo
archive não recursiva em subrepositórios a menos que -S / - subrepos seja especificado.

gato cat atualmente só lida com correspondências de arquivo exatas em sub-repos. Subversão
subrepositórios são atualmente ignorados.

commit commit cria um instantâneo consistente do estado de todo o projeto e seu
subrepositórios. Se algum subrepositório tiver sido modificado, o Mercurial será abortado.
O Mercurial pode ser feito para, em vez disso, comprometer todos os subrepositórios modificados, especificando
-S / - subrepos, ou definindo "ui.commitsubrepos = True" em um arquivo de configuração (consulte hg
ajudar configuração) Depois que não houver mais subrepositórios modificados, ele registra
seu estado e, finalmente, o compromete no repositório pai. O --addremove
opção também honra a opção -S / - subrepos. No entanto, Git e Subversion
os subrepositórios irão imprimir um aviso e abortar.

diff diff não recursiva em subrepos a menos que -S / - subrepos seja especificado. Mudanças são
exibidos como de costume, nos elementos de subrepositórios. Subrepositórios do Subversion são
atualmente silenciosamente ignorado.

arquivos arquivos não recursivamente em subrepostos, a menos que -S / - subrepostos seja especificado. Contudo,
se você especificar o caminho completo de um arquivo ou diretório em um subrepo, será
exibido mesmo sem a especificação dos sub-repos -S / -. Git e Subversion
subrepositórios são atualmente ignorados silenciosamente.

esquecer esquecer atualmente só lida com correspondências de arquivo exatas em subrepos. Git e Subversion
subrepositórios são atualmente ignorados silenciosamente.

entrada
a entrada não recursiva em subrepostos, a menos que -S / - subrepostos seja especificado. Git e
Os subrepositórios do Subversion são silenciosamente ignorados.

cessante
de saída não recursiva em subrepos, a menos que -S / - subrepos seja especificado. Git e
Os subrepositórios do Subversion são silenciosamente ignorados.

puxar pull não é recursivo, pois não está claro o que puxar antes de executar hg atualizar
. Listar e recuperar todas as alterações de subrepositórios referenciadas pelo pai
conjuntos de alterações puxados do repositório são caros, na melhor das hipóteses, impossíveis no Subversion
caso.

empurrar O Mercurial enviará automaticamente todos os subrepositórios primeiro quando o pai
repositório está sendo enviado. Isso garante que novas mudanças de subrepositório estejam disponíveis
quando referenciado por repositórios de nível superior. Push é autônomo para o Subversion
subrepositórios.

estado o status não recursiva nos subrepositórios, a menos que -S / - subrepos seja especificado.
Mudanças de subrepositório são exibidas como mudanças regulares do Mercurial no
elementos subrepositórios. Os subrepositórios do Subversion são silenciosamente ignorados.

remover remove não recursiva em subrepositórios, a menos que -S / - subrepos seja especificado.
No entanto, se você especificar um caminho de arquivo ou diretório em um subrepo, ele será removido
mesmo sem -S / - subrepos. Subrepositórios Git e Subversion são atualmente
silenciosamente ignorado.

atualizar atualização restaura os subrepostos no estado em que foram originalmente comprometidos no destino
conjunto de mudanças. Se o changeset registrado não estiver disponível no subrepositório atual,
O Mercurial o puxará primeiro, antes de atualizar. Isso significa que a atualização pode
requer acesso à rede ao usar subrepositórios.

Remapeamento Subrepositórios Fontes
A localização de uma fonte de subrepositório pode mudar durante a vida do projeto, invalidando as referências
armazenados no histórico do repositório pai. Para corrigir isso, regras de reescrita podem ser definidas em
repositório pai hgrc arquivo ou na configuração Mercurial. Veja o [subcaminhos] seção em
hgrc(5) para obter mais detalhes.

MODELO USO

O Mercurial permite que você personalize a saída de comandos por meio de modelos. Você também pode
passe um modelo ou selecione um estilo de modelo existente na linha de comando, por meio do
opção --template.

Você pode personalizar a saída para qualquer comando "semelhante a log": log, saída, entrada, dica,
pais e chefes.

Alguns estilos integrados são fornecidos com o Mercurial. Estes podem ser listados com hg log
--modelo Lista. Exemplo de uso:

$ hg log -r1.0 :: 1.1 - changelog de modelo

Um modelo é um pedaço de texto, com marcação para invocar a expansão da variável:

$ hg log -r1 --template "{node} \ n"
b56ce7b07c52de7d5fd79fb89701ea538af65746

Strings entre colchetes são chamados de palavras-chave. A disponibilidade de palavras-chave depende do
contexto exato do templater. Essas palavras-chave geralmente estão disponíveis para modelagem de um
comando semelhante a log:

marcador ativo
Corda. O favorito ativo, se estiver associado ao conjunto de alterações

autor Corda. O autor não modificado do changeset.

cortar Corda. O status da bissecção do changeset.

bookmarks
Lista de strings. Quaisquer marcadores associados ao changeset. Também define 'ativo',
o nome do marcador ativo.

ramo Corda. O nome do branch no qual o changeset foi confirmado.

alterasincelatesttag
Inteiro. Todos os ancestrais não estão na marca mais recente.

crianças
Lista de strings. Os filhos do changeset.

dados Informação de data. A data em que o changeset foi confirmado.

desc Corda. O texto da descrição do changeset.

difstata
Corda. Estatísticas de mudanças com o seguinte formato: "arquivos modificados:
+ adicionadas / -linhas removidas "

extras Lista de dicts com entradas de chave e valor do campo 'extras' deste changeset.

arquivo_adiciona
Lista de strings. Arquivos adicionados por este changeset.

arquivo_cópias
Lista de strings. Arquivos copiados neste changeset com suas fontes.

arquivo_copies_switch
Lista de strings. Como "file_copies", mas exibido apenas se a opção --copied for
definido.

arquivo_dels
Lista de strings. Arquivos removidos por este changeset.

arquivo_mods
Lista de strings. Arquivos modificados por este changeset.

arquivos Lista de strings. Todos os arquivos modificados, adicionados ou removidos por este conjunto de alterações.

nó de gráfico
Corda. O caractere que representa o nó do changeset em um gráfico de revisão ASCII

mais recente
Lista de strings. As marcas globais no ancestral mais recente de
este changeset.

lasttagdistance
Inteiro. Caminho mais longo para a tag mais recente.

namespaces
Ditado de listas. Nomes anexados a este changeset por namespace.

nó Corda. O hash de identificação do changeset, como uma string de 40 dígitos hexadecimais.

nó1 Corda. O hash de identificação do primeiro pai do changeset, como um dígito de 40
string hexadecimal. Se o changeset não tiver pais, todos os dígitos serão 0.

p1rev Inteiro. O número de revisão local do repositório do primeiro pai do changeset, ou
-1 se o changeset não tiver pais.

nó2 Corda. O hash de identificação do segundo pai do changeset, como um dígito de 40
string hexadecimal. Se o changeset não tiver um segundo pai, todos os dígitos serão 0.

p2rev Inteiro. O número de revisão local do repositório do segundo pai do changeset, ou
-1 se o changeset não tiver um segundo pai.

pais
Lista de strings. Os pais do changeset no formato "rev: node". Se o
conjunto de mudanças tem apenas um pai "natural" (a revisão predecessora) nada é
mostrando.

fase Corda. O nome da fase do changeset.

faseidx
Inteiro. O índice de fase do changeset.

rev Inteiro. O número de revisão do changeset local do repositório.

subrepos
Lista de strings. Subrepositórios atualizados no changeset.

Tag Lista de strings. Quaisquer tags associadas ao changeset.

A palavra-chave "data" não produz uma saída legível. Se você quiser usar uma data em
sua saída, você pode usar um filtro para processá-la. Filtros são funções que retornam um
string com base na variável de entrada. Certifique-se de usar o filtro stringify primeiro quando estiver
aplicando um filtro de entrada de string a uma variável de entrada do tipo lista. Você também pode usar uma cadeia de
filtros para obter a saída desejada:

$ hg tip --modelo "{data | isodato} \ n"
2008-08-21 18:22 +0000

Lista de filtros:

addbreaks
Qualquer texto. Adicionar um XHTML " "tag antes do final de cada linha, exceto a última.

idade Encontro. Retorna uma diferença de data / hora legível entre a data / hora fornecida e
a data / hora atual.

nome de base
Qualquer texto. Trata o texto como um caminho e retorna o último componente do caminho
após a divisão pelo separador de caminho (ignorando os separadores à direita). Por exemplo,
"foo / bar / baz" torna-se "baz" e "foo / bar //" torna-se "bar".

contar Lista ou texto. Retorna o comprimento como um inteiro.

domínio Qualquer texto. Encontra a primeira string que se parece com um endereço de e-mail e extrai
apenas o componente de domínio. Exemplo: Utilizador <[email protegido]> torna-se example.com.

email Qualquer texto. Extrai a primeira string que se parece com um endereço de e-mail. Exemplo: Utilizador
<[email protegido]> torna-se [email protegido].

usuário de email
Qualquer texto. Retorna a parte do usuário de um endereço de e-mail.

escapar Qualquer texto. Substitui os caracteres XML / XHTML especiais "&", "<" e ">" por XML
entidades e filtra caracteres NUL.

preencher68 Qualquer texto. Quebra o texto para caber em 68 colunas.

preencher76 Qualquer texto. Quebra o texto para caber em 76 colunas.

primeira linha
Qualquer texto. Retorna a primeira linha do texto.

feitiço Qualquer texto. Converta um identificador de nó binário Mercurial em seu longo hexadecimal
representação.

data hg Encontro. Retorna a data como um par de números: "1157407993 25200" (carimbo de data / hora Unix,
deslocamento de fuso horário).

isodato
Encontro. Retorna a data no formato ISO 8601: "2009-08-18 13:00 +0200".

isodatesec
Encontro. Retorna a data no formato ISO 8601, incluindo segundos: "2009-08-18 13:00:13
+0200 ". Veja também o filtro rfc3339date.

diminuir Qualquer texto. Converte o texto em minúsculas.

não vazio
Qualquer texto. Retorna '(nenhum)' se a string estiver vazia.

ofuscar
Qualquer texto. Retorna o texto de entrada renderizado como uma sequência de entidades XML.

pessoa Qualquer texto. Retorna o nome antes de um endereço de e-mail, interpretando-o de acordo com RFC
5322.

reviver
Qualquer texto. Escapa todos os caracteres "especiais", exceto @. Barras não têm escape
duas vezes para evitar que os servidores web tirem o escape deles prematuramente. Por exemplo, "@foo
bar / baz "torna-se" @ foo% 20bar% 252Fbaz ".

rfc3339data
Encontro. Retorna uma data usando o formato de data da Internet especificado em RFC 3339:
"2009-08-18T13:00:13+02:00".

rfc822data
Encontro. Retorna uma data usando o mesmo formato usado nos cabeçalhos de e-mail: "Ter, 18 de agosto de 2009
13:00:13 +0200 ".

baixo Hash do conjunto de alterações. Retorna a forma abreviada de um hash de conjunto de alterações, ou seja, um hexadecimal 12
string de dígitos.

bisseto curto
Qualquer texto. Trata texto como um status de bissecção e retorna um único caractere
representando o status (G: bom, B: ruim, S: ignorado, U: não testado, I: ignorado).
Retorna um único espaço se texto não é um status de bissecção válido.

encontro curto
Encontro. Retorna uma data como "2006-09-18".

linhas de divisão
Qualquer texto. Divida o texto em uma lista de linhas.

restringir
Qualquer tipo. Transforma o valor em texto, convertendo valores em texto e
concatená-los.

stripdir
Trate o texto como caminho e retire um nível de diretório, se possível. Por exemplo, "foo"
e "foo / bar" torna-se "foo".

tabindente
Qualquer texto. Retorna o texto, com todas as linhas não vazias, exceto a primeira inicial
com um caractere de tabulação.

superior Qualquer texto. Converte o texto em maiúsculas.

urlscape
Qualquer texto. Escapa todos os caracteres "especiais". Por exemplo, "foo bar" torna-se
"foo% 20bar".

usuário Qualquer texto. Retorna uma representação curta de um nome de usuário ou endereço de e-mail.

Observe que um filtro nada mais é do que uma chamada de função, ou seja, expr | filtro é equivalente
para filtro (expr).

Além dos filtros, existem algumas funções internas básicas:

data (data [, fmt])
Formate uma data. Ver hg ajudar datas para formatação de strings. O padrão é uma data Unix
formato, incluindo o fuso horário: "Mon Sep 04 15:13:13 2006 0700".

diff ([incluir padrão [, excluir padrão]])
Mostra um diff, opcionalmente especificando arquivos a serem incluídos ou excluídos.

preencher (texto [, largura[, initialident [, pendente]]])
Preencha muitos parágrafos com recuo opcional. Veja o filtro "preencher".

obter (dict, chave)
Obtenha um atributo / chave de um objeto. Algumas palavras-chave são tipos complexos. Esta função
permite obter o valor de um atributo nesses tipos.

if (expr, então[, senão])
Executar condicionalmente com base no resultado de uma expressão.

ifcontains (pesquisa, coisa, então[, senão])
Executar condicionalmente com base no fato de o item "pesquisar" estar ou não em "coisa".

ifeq (expr1, exp2, então[, senão])
Executar condicionalmente com base na equivalência de 2 itens.

indent (texto, indentchars [, primeira linha])
Recua todas as linhas não vazias com os caracteres fornecidos na string indentchars. Um
o terceiro parâmetro opcional substituirá o recuo da primeira linha somente se
presente.

junte-se (lista, set)
Junte os itens em uma lista com um delimitador.

rótulo (rótulo, exp)
Aplique um rótulo ao conteúdo gerado. O conteúdo com um rótulo aplicado pode resultar em
pós-processamento adicional, como colorização automática.

lasttag ([padrão])
As marcas globais que correspondem ao padrão fornecido na marca global mais recente
ancestral deste changeset.

localdate (data [, tz])
Converte uma data no fuso horário especificado. O padrão é a data local.

pad (texto, largura[, fillchar = ' '[, direita = falso]])
Preencha o texto com um caractere de preenchimento.

revset (query [, formatargs ...])
Execute uma consulta de conjunto de revisão. Ver hg ajudar repor.

rstdoc (texto, estilo)
Formato ReStructuredText.

mais curto (nó, comprimento mínimo = 4)
Obtenha a representação mais curta de um nó.

começa com (padrão, texto)
Retorna o valor do argumento "texto" se começar com o conteúdo do
argumento "padrão".

tira (texto [, caracteres])
Retire os caracteres de uma string. Por padrão, remove todos os
espaço em branco.

sub (padrão, substituição, expressão)
Execute a substituição de texto usando expressões regulares.

palavra (número, texto[, separador])
Retorne a enésima palavra de uma string.

Além disso, para qualquer expressão que retorna uma lista, há um operador de lista:

expr% "{template}"

Como visto no exemplo acima, {modelo} é interpretado como um modelo. Para prevenir que
sendo interpretado, você pode usar um caractere de escape \{ ou um prefixo de string bruto, r '...'.

Alguns exemplos de modelos de linha de comando:

· Formatar listas, por exemplo, arquivos:

$ hg log -r 0 --template "arquivos: \ n {arquivos% '{arquivo} \ n'}"

· Junte-se à lista de arquivos com um ",":

$ hg log -r 0 --template "arquivos: {join (files, ',')} \ n"

· Modifique cada linha de uma descrição de confirmação:

$ hg log --template "{splitlines (desc)% '**** {line} \ n'}"

· Formatar data:

$ hg log -r 0 --modelo "{data (data, '% Y')} \ n"

· Data de exibição em UTC:

$ hg log -r 0 --template "{localdate (data, 'UTC') | data} \ n"

· Envie a descrição definida para uma largura de preenchimento de 30:

$ hg log -r 0 --modelo "{fill (desc, 30)}"

· Use uma condição para testar o branch padrão:

$ hg log -r 0 --template "{ifeq (branch, 'default', 'no branch principal',
'no branch {branch}')} \ n "

· Anexar uma nova linha se não estiver vazio:

$ hg tip --modelo "{if (autor, '{autor} \ n')}"

· Rotule a saída para uso com a extensão de cor:

$ hg log -r 0 --template "{label ('changeset. {phase}', node | short)} \ n"

· Inverta o filtro de primeira linha, ou seja, tudo menos a primeira linha:

$ hg log -r 0 --modelo "{sub (r '^. * \ n? \ n?', '', desc)} \ n"

· Exibir o conteúdo do campo 'extra', um por linha:

$ hg log -r 0 --template "{join (extras, '\ n')} \ n"

· Marque o favorito ativo com '*':

$ hg log --template "{bookmarks% '{bookmark} {ifeq (bookmark, ativo,' * ')}'} \ n"

· Encontre a tag do candidato a lançamento anterior, a distância e as mudanças desde a tag:

$ hg log -r. --template "{lasttag ('re: ^. * - rc $')% '{tag}, {changes}, {distance}'} \ n"

· Marque a cópia de trabalho pai com '@':

$ hg log --template "{ifcontains (rev, revset ('.'), '@')} \ n"

· Mostrar detalhes das revisões principais:

$ hg log --template "{revset ('pais (% d)', rev)% '{desc | primeira linha} \ n'}"

· Mostrar apenas descrições de commit que começam com "template":

$ hg log --template "{startswith ('template', firstline (desc))} \ n"

· Imprima a primeira palavra de cada linha de uma mensagem de confirmação:

$ hg log --template "{word (0, desc)} \ n"

URL CAMINHOS

Os URLs válidos têm o formato:

local / sistema de arquivos / caminho [# revisão]
arquivo: // local / sistema de arquivos / caminho [# revisão]
http://[user[:pass]@]host[:port]/[path][#revision]
https://[user[:pass]@]host[:port]/[path][#revision]
ssh: // [usuário @] host [: porta] / [caminho] [# revisão]

Os caminhos no sistema de arquivos local podem apontar para repositórios Mercurial ou agrupar
arquivos (conforme criado por hg empacotar or hg entrada --agrupar). Veja também hg ajudar caminhos.

Um identificador opcional após # indica um branch, tag ou conjunto de mudanças específico a ser usado
do repositório remoto. Veja também hg ajudar revisões.

Alguns recursos, como envio para URLs http: // e https: //, só são possíveis se o
recurso está explicitamente habilitado no servidor Mercurial remoto.

Observe que a segurança de URLs HTTPS depende da configuração adequada de web.cacerts.

Algumas notas sobre o uso de SSH com Mercurial:

· SSH requer uma conta shell acessível na máquina de destino e uma cópia do hg em
o caminho remoto ou especificado como remotecmd.

· O caminho é relativo ao diretório inicial do usuário remoto por padrão. Use uma barra extra em
o início de um caminho para especificar um caminho absoluto:

ssh: //example.com//tmp/repository

· O Mercurial não usa sua própria compressão via SSH; a coisa certa a fazer é configurar
isso em seu ~ / .ssh / config, por exemplo:

Host * .mylocalnetwork.example.com
Compressão não
Hospedeiro *
Compressão sim

Alternativamente, especifique "ssh -C" como seu comando ssh em seu arquivo de configuração ou com
a opção de linha de comando --ssh.

Esses URLs podem ser armazenados em seu arquivo de configuração com aliases de caminho sob o
seção [caminhos] assim:

[caminhos]
alias1 = URL1
alias2 = URL2
...

Você pode então usar o alias para qualquer comando que use uma URL (por exemplo hg puxar alias1
será tratado como hg puxar URL1).

Aliases de dois caminhos são especiais porque são usados ​​como padrões quando você não fornece o
URL para um comando:

default:
Quando você cria um repositório com clone hg, o comando clone salva a localização do
o repositório de origem como o caminho 'padrão' do novo repositório. Isso é então usado
quando você omite o caminho de comandos semelhantes a push e pull (incluindo entrada e
extrovertido).

push-default:
O comando push irá procurar por um caminho chamado 'default-push', e preferirá isso
'default' se ambos estiverem definidos.

EXTENSÕES

Esta seção contém ajuda para extensões que são distribuídas junto com o Mercurial.
A ajuda para outras extensões está disponível no sistema de ajuda.

acl
ganchos para controlar o acesso ao repositório

Este gancho torna possível permitir ou negar acesso de gravação a determinados ramos e caminhos de um
repositório ao receber conjuntos de alterações de entrada via pretxnchangegroup e pretxncommit.

A autorização é correspondida com base no nome do usuário local no sistema onde o gancho
é executado, e não o committer do changeset original (uma vez que o último é meramente
informativo).

O gancho acl é melhor usado junto com um shell restrito como hgsh, evitando
autenticar os usuários de fazer qualquer coisa diferente de empurrar ou puxar. O gancho não é
seguro de usar se os usuários tiverem acesso ao shell interativo, pois eles podem desabilitar o gancho. Nem
é seguro se os usuários remotos compartilham uma conta, porque então não há como distinguir
Eles.

A ordem em que as verificações de acesso são realizadas é:

1. Lista de negação para ramos (seção acl.deny.braches)

2. Lista de permissões para ramos (seção acl.allow.braches)

3. Negar lista para caminhos (seção acl.negar)

4. Lista de permissões para caminhos (seção acl.permitir)

As seções permitir e negar usam pares de valores-chave.

Baseado em filial Acesso a Control
Use o acl.deny.braches e acl.allow.braches seções para ter acesso baseado em filial
ao controle. As chaves nessas seções podem ser:

· Um nome de filial, ou

· Um asterisco, para corresponder a qualquer ramo;

Os valores correspondentes podem ser:

· Uma lista separada por vírgulas contendo usuários e grupos, ou

· Um asterisco, para corresponder a qualquer pessoa;

Você pode adicionar o "!" prefixo para um nome de usuário ou grupo para inverter o sentido da correspondência.

Baseado em caminho Acesso a Control
Use o acl.negar e acl.permitir seções para ter controle de acesso baseado em caminho. Chaves nestes
as seções aceitam um padrão de subárvore (com uma sintaxe glob por padrão). O correspondente
os valores seguem a mesma sintaxe das outras seções acima.

Grupos
Os nomes dos grupos devem ser prefixados com um @ símbolo. Especificar um nome de grupo tem o mesmo efeito
como especificando todos os usuários naquele grupo.

Você pode definir os membros do grupo no acl.grupos seção. Se um nome de grupo não for definido
lá, e o Mercurial está sendo executado em um sistema semelhante ao Unix, a lista de usuários será obtida
do sistema operacional. Caso contrário, uma exceção será gerada.

Exemplo Configuração
[ganchos]

# Use isto se você deseja verificar as restrições de acesso no momento do commit
pretxncommit.acl = python: hgext.acl.hook

# Use isto se quiser verificar as restrições de acesso para pull, push,
# agrupar e servir.
pretxnchangegroup.acl = python: hgext.acl.hook

[acl]
# Permitir ou negar acesso para mudanças recebidas apenas se sua fonte for
# listados aqui, deixe-os passar de outra forma. A fonte é "servir" para todos
# acesso remoto (http ou ssh), "push", "pull" ou "bundle" quando o
# comandos relacionados são executados localmente.
# Padrão: servir
fontes = servir

[acl.deny.braches]

# Todo mundo está negado ao ramo congelado:
ramo-congelado = *

# Um mau usuário é negado em todos os branches:
* = mau usuário

[acl.allow.braches]

# Alguns usuários são permitidos no branch-a:
branch-a = usuário-1, usuário-2, usuário-3

# Apenas um usuário é permitido no branch-b:
branch-b = usuário-1

# O superusuário tem permissão em qualquer ramo:
* = superusuário

# Todos são permitidos em branch-for-tests:
branch-para-testes = *

[acl.negar]
# Esta lista é verificada primeiro. Se uma correspondência for encontrada, acl.allow não é
# marcada. Todos os usuários têm acesso concedido se acl.deny não estiver presente.
# Formato para ambas as listas: glob pattern = user, ..., @group, ...

# Para corresponder a todos, use um asterisco para o usuário:
# my / glob / pattern = *

# user6 não terá acesso de gravação a nenhum arquivo:
** = usuário6

# O grupo "hg-denied" não terá acesso de gravação a nenhum arquivo:
** = @ hg-negado

# Ninguém será capaz de alterar "DONT-TOUCH-THIS.txt", apesar de
# todos podendo alterar todos os outros arquivos. Ver abaixo.
src / main / resources / DONT-TOUCH-THIS.txt = *

[acl.permitir]
# se acl.allow não estiver presente, todos os usuários são permitidos por padrão
# empty acl.allow = nenhum usuário permitido

# O usuário "doc_writer" tem acesso de gravação a qualquer arquivo na categoria "docs"
# pasta:
docs / ** = doc_writer

# O usuário "jack" e o grupo "designers" têm acesso de gravação a qualquer arquivo
# na pasta "imagens":
images / ** = jack, @designers

# Todos (exceto para "user6" e "@ hg-denied" - consulte acl.deny acima)
# terá acesso de gravação a qualquer arquivo na pasta "recursos"
# (exceto para 1 arquivo. Consulte acl.deny):
src / main / resources / ** = *

.hgtags = release_engineer

Exemplos utilização que o ! prefixo
Suponha que haja um branch para o qual apenas um determinado usuário (ou grupo) deve ser capaz de enviar por push, e
você não quer restringir o acesso a qualquer outro branch que possa ser criado.

O "!" prefixo permite que você impeça qualquer pessoa, exceto um determinado usuário ou grupo de enviar
conjuntos de alterações em um determinado ramo ou caminho.

Nos exemplos abaixo, iremos: 1) Negar acesso ao branch "ring" a qualquer pessoa, exceto ao usuário
"gollum" 2) Negar acesso ao ramal "lake" a qualquer pessoa, exceto aos membros do grupo "hobbit" 3)
Negar acesso a um arquivo a qualquer pessoa, exceto ao usuário "gollum"

[acl.allow.braches]
# Vazio

[acl.deny.braches]

# 1) apenas 'gollum' pode se comprometer com o branch 'ring';
# 'gollum' e qualquer outra pessoa ainda pode se comprometer com qualquer outro branch.
anel =! gollum

# 2) apenas membros do grupo 'hobbit' podem se comprometer com o ramo 'lago';
# Membros 'hobbit' e qualquer outra pessoa ainda podem se comprometer com qualquer outro ramo.
lago =! @hobbit

# Você também pode negar o acesso com base nos caminhos dos arquivos:

[acl.permitir]
# Vazio

[acl.negar]
# 3) apenas 'gollum' pode alterar o arquivo abaixo;
# 'gollum' e qualquer outra pessoa ainda pode alterar qualquer outro arquivo.
/ enevoado / montanhas / caverna / anel =! gollum

blackbox
registrar eventos do repositório em uma caixa preta para depuração

Registra informações de eventos em .hg / blackbox.log para ajudar a depurar e diagnosticar problemas. O
eventos que são registrados podem ser configurados por meio da chave de configuração blackbox.track. Exemplos:

[caixa preta]
trilha = *

[caixa preta]
track = comando, commandfinish, commandexception, exthook, pythonhook

[caixa preta]
trilha = entrada

[caixa preta]
# limitar o tamanho de um arquivo de log
maxsize = 1.5 MB
# gire até N arquivos de log quando o atual ficar muito grande
arquivos max = 3

comandos
blackbox
veja os eventos recentes do repositório:

caixa preta hg [OPÇÃO] ...

ver os eventos recentes do repositório

opções:

-eu,--limite
o número de eventos a serem mostrados (padrão: 10)

Bugzilla
ganchos para integração com o bug tracker Bugzilla

Esta extensão de gancho adiciona comentários sobre bugs no Bugzilla quando os conjuntos de alterações que se referem a bugs
por ID do Bugzilla são vistos. O comentário é formatado usando o mecanismo de template Mercurial.

As referências de bug podem opcionalmente incluir uma atualização para o Bugzilla das horas gastas
trabalhando no bug. Bugs também podem ser marcados como corrigidos.

Três modos básicos de acesso ao Bugzilla são fornecidos:

1. Acesse através da interface XMLRPC do Bugzilla. Requer Bugzilla 3.4 ou posterior.

2. Verifique os dados por meio da interface XMLRPC do Bugzilla e envie a alteração do bug por e-mail para
Interface de e-mail do Bugzilla. Requer Bugzilla 3.4 ou posterior.

3. Gravando diretamente no banco de dados do Bugzilla. Apenas as instalações do Bugzilla usando MySQL são
suportado. Requer Python MySQLdb.

Gravar diretamente no banco de dados é suscetível a alterações de esquema e depende de um
Script contrib do Bugzilla para enviar e-mails de notificação de alteração de bug. Este script é executado como
o usuário executando o Mercurial, deve ser executado no host com a instalação do Bugzilla, e
requer permissão para ler os detalhes de configuração do Bugzilla e o usuário MySQL necessário
e senha para ter direitos de acesso total ao banco de dados do Bugzilla. Por essas razões,
modo de acesso agora é considerado obsoleto e não será atualizado para o novo Bugzilla
versões daqui para frente. Apenas adicionar comentários é suportado neste modo de acesso.

O acesso via XMLRPC precisa de um nome de usuário e senha Bugzilla a serem especificados no
configuração. Os comentários são adicionados sob esse nome de usuário. Uma vez que a configuração deve ser
legível por todos os usuários do Mercurial, é recomendado que os direitos desse usuário sejam
restrito no Bugzilla ao mínimo necessário para adicionar comentários. Erros de marcação corrigidos
requer Bugzilla 4.0 e posterior.

O acesso via XMLRPC / e-mail usa XMLRPC para consultar o Bugzilla, mas envia e-mail para o Bugzilla
interface de e-mail para enviar comentários aos bugs. O endereço De: no e-mail é definido como
endereço de e-mail do usuário do Mercurial, então o comentário parece vir do Mercurial
do utilizador. No caso de o e-mail do usuário Mercurial não ser reconhecido pelo Bugzilla como um
Usuário do Bugzilla, o e-mail associado ao nome de usuário do Bugzilla usado para fazer login no Bugzilla
é usado como fonte do comentário. A marcação de bugs corrigidos funciona em todos os
Versões do Bugzilla.

Itens de configuração comuns a todos os modos de acesso:

bugzilla.versão
O tipo de acesso a ser usado. Os valores reconhecidos são:

xmlrpc

Interface Bugzilla XMLRPC.

xmlrpc + email

Interfaces de email e XMLRPC do Bugzilla.

3.0

Acesso MySQL, Bugzilla 3.0 e posterior.

2.18

Acesso MySQL, Bugzilla 2.18 e até mas não incluindo 3.0.

2.16

Acesso MySQL, Bugzilla 2.16 e até mas não incluindo 2.18.

bugzilla.regexp
Expressão regular para corresponder aos IDs de bug para atualização na mensagem de confirmação do changeset. Isto
deve conter um grupo nomeado "()" contendo os IDs de bug separados por
caracteres não dígitos. Também pode conter um grupo nomeado com uma
número de ponto flutuante informando as horas trabalhadas no bug. Se nenhum grupo nomeado for
presente, assume-se que o primeiro grupo "()" contém os IDs de bug e o tempo de trabalho é
não atualizado. A expressão padrão corresponde Bug 1234, Bug n. 1234, Bug número
1234, Erros 1234,5678, Bug 1234 e 5678 e suas variações, seguidas por um
número de horas prefixado por h or horas, por exemplo horas 1.5. A correspondência não diferencia maiúsculas de minúsculas.

bugzilla.fixregexp
Expressão regular para corresponder aos IDs de bug para marcação de corrigida na mensagem de confirmação do changeset.
Deve conter um grupo nomeado "()" ` contendo que o erro IDs separado by
não digito caracteres. It pode tb não contenho a nomeado grupo `` com uma
número de ponto flutuante informando as horas trabalhadas no bug. Se nenhum grupo nomeado for
presente, assume-se que o primeiro grupo "()" contém os IDs de bug e o tempo de trabalho é
não atualizado. A expressão padrão corresponde Correções 1234, Correções erro 1234, Correções erros
1234,5678, Correções 1234 e 5678 e suas variações, seguidas por um número de horas
prefixado por h or horas, por exemplo horas 1.5. A correspondência não diferencia maiúsculas de minúsculas.

bugzilla.fixstatus
O status para definir um bug ao marcar como corrigido. Padrão RESOLVEU.

bugzilla.fixresolução
A resolução para definir um bug ao marcar como corrigido. Padrão FIXO.

estilo bugzilla
O arquivo de estilo a ser usado ao formatar comentários.

bugzilla.template
Modelo a ser usado ao formatar comentários. Substitui o estilo, se especificado. Além disso
para as palavras-chave usuais do Mercurial, a extensão especifica:

{erro}

O ID do bug do Bugzilla.

{raiz}

O nome do caminho completo do repositório Mercurial.

{webroot}

Nome do caminho removido do repositório Mercurial.

{hgweb}

URL base para navegar nos repositórios do Mercurial.

Padrão changeset {nó | curto} in repo {raiz} refere-se para erro
{bug}. \ ndetalhes: \ n \ t {desc | tabindent}

bugzilla.strip
O número de caracteres separadores de caminho a serem retirados da frente do Mercurial
caminho do repositório ({raiz} em modelos) para produzir {webroot}. Por exemplo, um
repositório com {raiz} / var / local / my-project com uma faixa de 2 dá um valor para
{webroot} of meu projeto. Padrão 0.

web.baseurl
URL base para navegar nos repositórios do Mercurial. Referenciado a partir de modelos como {hgweb}.

Itens de configuração comuns aos modos de acesso XMLRPC + e-mail e MySQL:

bugzilla.usermap
Caminho do arquivo contendo o e-mail do committer do Mercurial para os mapeamentos de e-mail do usuário do Bugzilla.
Se especificado, o arquivo deve conter um mapeamento por linha:

committer = usuário Bugzilla

Veja também o [mapa do usuário] seção.

A [mapa do usuário] seção é usada para especificar mapeamentos de e-mail do committer do Mercurial para o Bugzilla
e-mail do usuário. Veja também bugzilla.usermap. Contém entradas do formulário committer = Bugzilla
usuário.

Configuração do modo de acesso XMLRPC:

bugzilla.bzurl
O URL base para a instalação do Bugzilla. Padrão http://localhost/bugzilla.

bugzilla.user
O nome de usuário a ser usado para fazer login no Bugzilla via XMLRPC. Padrão erros.

bugzilla.senha
A senha para login no Bugzilla.

O modo de acesso de e-mail XMLRPC + usa os itens de configuração do modo de acesso XMLRPC e também:

bugzilla.bzemail
O endereço de e-mail do Bugzilla.

Além disso, as configurações de e-mail do Mercurial devem ser definidas. Veja a documentação em
hgrc(5), seções [E-mail] e [smtp].

Configuração do modo de acesso MySQL:

bugzilla.host
Nome do host do servidor MySQL que mantém o banco de dados Bugzilla. Padrão localhost.

bugzilla.db
Nome do banco de dados Bugzilla em MySQL. Padrão erros.

bugzilla.user
Nome de usuário a ser usado para acessar o servidor MySQL. Padrão erros.

bugzilla.senha
Senha a ser usada para acessar o servidor MySQL.

bugzilla.timeout
Tempo limite de conexão do banco de dados (segundos). Padrão 5.

bugzilla.bzuser
Nome de usuário do Bugzilla substituto para registrar comentários, se o committer do changeset não puder
ser encontrado como um usuário Bugzilla.

bugzilla.bzdir
Diretório de instalação do Bugzilla. Usado por notificação padrão. Padrão / var / www / html / bugzilla.

bugzilla.notificar
O comando a ser executado para fazer com que o Bugzilla envie emails de notificação de alteração de bug.
Substitutos de um mapa com 3 chaves, bzdir, id (id do bug) e usuário (commissor bugzilla
o email). O padrão depende da versão; de 2.18 é "cd% (bzdir) s && perl -T
contrib / sendbugmail.pl% (id) s% (user) s ".

Ativando a extensão:

[extensões]
bugzila =

[ganchos]
# execute bugzilla hook em cada mudança puxada ou empurrada aqui
Entry.bugzilla = python: hgext.bugzilla.hook

Configurações de exemplo:

Configuração de exemplo XMLRPC. Isso usa o Bugzilla em http://my-project.org/bugzilla,
fazendo login como usuário [email protegido] com senha arrancar. É usado com um
coleção de repositórios Mercurial em / var / local / hg / repos /, com uma interface da web em
http://my-project.org/hg.

[bugzila]
bzurl =http://my-project.org/bugzilla
usuário =[email protegido]
senha = plugh
version = xmlrpc
template = Changeset {node | short} em {root | basename}.
{hgweb} / {webroot} / rev / {node | short} \ n
{desc} \ n
strip = 5

[rede]
baseurl =http://my-project.org/hg

Configuração de exemplo de email XMLRPC +. Isso usa o Bugzilla em
http://my-project.org/bugzilla, fazendo login como usuário [email protegido] com senha
arrancar. É usado com uma coleção de repositórios Mercurial em / var / local / hg / repos /,
com uma interface da web em http://my-project.org/hg. Comentários de bug são enviados para o Bugzilla
endereço de email [email protegido].

[bugzila]
bzurl =http://my-project.org/bugzilla
usuário =[email protegido]
senha = plugh
version = xmlrpc + email
bzemail =[email protegido]
template = Changeset {node | short} em {root | basename}.
{hgweb} / {webroot} / rev / {node | short} \ n
{desc} \ n
strip = 5

[rede]
baseurl =http://my-project.org/hg

[mapa do usuário]
[email protegido]=[email protegido]

Configuração de exemplo do MySQL. Este tem uma instalação local do Bugzilla 3.2 em
/opt/bugzilla-3.2. O banco de dados MySQL está ativado localhost, o nome do banco de dados Bugzilla é erros
e o MySQL é acessado com o nome de usuário MySQL erros senha XYZZY. É usado com um
coleção de repositórios Mercurial em / var / local / hg / repos /, com uma interface da web em
http://my-project.org/hg.

[bugzila]
host = localhost
senha = XYZZY
versão = 3.0
bzuser =[email protegido]
bzdir = / opt / bugzilla-3.2
template = Changeset {node | short} em {root | basename}.
{hgweb} / {webroot} / rev / {node | short} \ n
{desc} \ n
strip = 5

[rede]
baseurl =http://my-project.org/hg

[mapa do usuário]
[email protegido]=[email protegido]

Todos os itens acima adicionam um comentário ao registro de bug do Bugzilla do formulário:

Conjunto de alterações 3b16791d6642 no nome do repositório.
http://my-project.org/hg/repository-name/rev/3b16791d6642

Comentário de confirmação do conjunto de alterações. Bug 1234.

censurar
apagar o conteúdo do arquivo em uma determinada revisão

O comando censor instrui o Mercurial a apagar todo o conteúdo de um arquivo em uma determinada revisão
sem atualização que o changeset hash. Isso permite que o histórico existente permaneça válido enquanto
evitando que futuros clones / pulls recebam os dados apagados.

Os usos típicos de censor são devido a requisitos legais ou de segurança, incluindo:

* Senhas, chaves privadas, material criptográfico
* Dados / códigos / bibliotecas licenciados para os quais a licença expirou
* Informações de identificação pessoal ou outros dados privados

Nós censurados podem interromper a operação típica do mercurial sempre que os dados excisados ​​precisam
para ser materializado. Alguns comandos, como hg gato/hg reverter, simplesmente falhe quando for solicitado
produzir dados censurados. Outros gostam hg verificar e hg atualizar, deve ser capaz de tolerar
dados censurados para continuar a funcionar de forma significativa. Esses comandos apenas toleram
revisões de arquivos censurados se forem permitidas pela opção de configuração "censor.policy = ignore".

comandos
censurar
censor hg -r REV [-t TEXT] [FILE]

opções:

-r,--rev
censurar arquivo da revisão especificada

-t,--lápide
dados de substituição de marca de exclusão

chgserver
extensão do servidor de comando para cHg (EXPERIMENTAL)

'S' canal (ler escrever)
propagar solicitação ui.system () para o cliente

'attachio' comando
anexar stdio do cliente passado por sendmsg ()

'chdir' comando
mudar o diretório atual

'getpager' comando
verifica se o pager está habilitado e qual pager deve ser executado

'setenv' comando
substitua o os.environ completamente

'SIGHUP' sinal
recarregar arquivos de configuração

crianças
comando para exibir conjuntos de alterações filho (DESCONTINUADO)

Esta extensão está obsoleta. Você deveria usar hg log -r "crianças (REV)" ao invés.

comandos
crianças
mostrar os filhos da revisão dada ou do diretório de trabalho:

hg filhos [-r REV] [FILE]

Imprima os filhos das revisões do diretório de trabalho. Se uma revisão for dada via
-r / - rev, os filhos dessa revisão serão impressos. Se um argumento de arquivo for fornecido,
revisão na qual o arquivo foi alterado pela última vez (após a revisão do diretório de trabalho ou o
argumento para --rev se fornecido) é impresso.

Por favor, use hg log em vez de:

hg children => hg log -r 'children ()'
hg filhos -r REV => hg log -r 'filhos (REV)'

See hg ajudar log e hg ajudar revsets.crianças.

opções:

-r,--rev
mostrar os filhos da revisão especificada

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

agitação
comando para exibir estatísticas sobre o histórico do repositório

comandos
agitação
histograma de mudanças no repositório:

hg churn [-d DATA] [-r REV] [--aliases ARQUIVO] [ARQUIVO]

Este comando irá mostrar um histograma que representa o número de linhas alteradas ou
revisões, agrupadas de acordo com o modelo fornecido. O modelo padrão irá agrupar
alterações por autor. A opção --dateformat pode ser usada para agrupar os resultados por data
ao invés.

As estatísticas são baseadas no número de linhas alteradas ou, alternativamente, o número de
revisões correspondentes se a opção --changesets for especificada.

Exemplos:

# exibir contagem de linhas alteradas para cada committer
hg churn -t "{autor | email}"

# exibir gráfico de atividades diárias
hg churn -f "% H" -s -c

# atividade de exibição dos desenvolvedores por mês
hg churn -f "% Y-% m" -s -c

# exibir contagem de linhas alteradas a cada ano
hg churn -f "% Y" -s

É possível mapear endereços de e-mail alternativos para um endereço principal, fornecendo um arquivo
usando o seguinte formato:

=

Esse arquivo pode ser especificado com a opção --aliases, caso contrário, um arquivo .hgchurn será
procurado na raiz do diretório de trabalho. Os aliases serão divididos do "=" mais à direita.

opções:

-r,--rev
taxa de contagem para a revisão ou revset especificada

-d,--data
taxa de contagem para revisões que correspondem às especificações da data

-t,--modelo antigo
modelo para agrupar conjuntos de alterações (DESCONTINUADO)

-T,--modelo
modelo para agrupar conjuntos de alterações (padrão: {autor | email})

-f,--Formato de data
formato compatível com strftime para agrupamento por data

-c, --changesets
taxa de contagem por número de changesets

-sim, --ordenar
classificar por chave (padrão: classificar por contagem)

--diffstat
exibir linhas adicionadas / removidas separadamente

--apelido
arquivo com aliases de e-mail

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

clonebundles
anunciar pacotes pré-gerados para sementes de clones

"clonebundles" é uma extensão do lado do servidor usada para anunciar a existência de
arquivos de pacote pré-gerados e hospedados externamente para clientes que estão clonando para que a clonagem
pode ser mais rápido, mais confiável e exigir menos recursos no servidor.

A clonagem pode ser uma operação intensiva de CPU e E / S em servidores. Tradicionalmente, o servidor, em
resposta a um pedido do cliente para clonar, gera dinamicamente um pacote contendo o
todo o conteúdo do repositório e o envia ao cliente. Não há cache no servidor
e o servidor terá que gerar redundantemente o mesmo pacote de saída em resposta a
cada pedido de clone. Para servidores com grandes repositórios ou com alto volume de clones, o
a carga de clones pode tornar o dimensionamento do servidor desafiador e caro.

Esta extensão fornece aos operadores de servidor a capacidade de descarregar potencialmente caro
clone a carga para um serviço externo. É assim que funciona.

1. Um operador de servidor estabelece um mecanismo para disponibilizar arquivos de pacote em um
serviço de hospedagem onde os clientes Mercurial podem buscá-los.

2. Um arquivo de manifesto listando URLs de pacotes disponíveis e alguns metadados opcionais são adicionados a
o repositório Mercurial no servidor.

3. Um cliente inicia um clone em um servidor ciente de pacotes de clones.

4. O cliente vê que o servidor está anunciando pacotes de clones e busca o manifesto
listando os pacotes disponíveis.

5. O cliente filtra e classifica os pacotes disponíveis com base no que ele suporta e
prefere.

6. O cliente baixa e aplica um pacote disponível no URL especificado pelo servidor.

7. O cliente se reconecta ao servidor original e executa o equivalente a hg puxar para
recupere todos os dados do repositório que não estejam no pacote. (O repositório pode ter sido atualizado
entre quando o pacote foi criado e quando o cliente iniciou o clone.)

Em vez de o servidor gerar pacotes completos de repositório para cada solicitação de clone, ele
gera bundles completos uma vez e eles são subsequentemente reutilizados para inicializar novos clones. O
o servidor ainda pode transferir dados no momento da clonagem. No entanto, estes são apenas os dados que foram
adicionado / alterado desde a criação do pacote. Para repositórios grandes e estabelecidos, isso pode
reduza a carga do servidor para clones para menos de 1% do original.

Para funcionar, esta extensão requer os seguintes operadores de servidor:

· Gerar arquivos de pacote de conteúdo do repositório (normalmente periodicamente, como uma vez por
dia).

· Um servidor de arquivos ao qual os clientes têm acesso à rede e com o qual Python sabe como se comunicar
por meio de seu recurso normal de manipulação de URL (normalmente um servidor HTTP).

· Um processo para manter o manifesto de bundles em sincronia com os arquivos de bundles disponíveis.

Estritamente falando, não é necessário usar um servidor de hospedagem de arquivos estáticos: um operador de servidor
poderia usar um serviço dinâmico para recuperar dados do pacote. No entanto, hospedagem de arquivos estáticos
os serviços são simples e escaláveis ​​e devem ser suficientes para a maioria das necessidades.

Arquivos de pacote podem ser gerados com o hg empacotar comando. Tipicamente hg empacotar --tudo is
usado para produzir um pacote de todo o repositório.

hg debugcreatestreamclonebundle pode ser usado para produzir um especial de streaming clonar empacotar.
Esses são arquivos de pacote extremamente eficientes de produzir e consumir (leia-se: rápido).
No entanto, eles são maiores do que os formatos de pacote tradicionais e exigem que os clientes ofereçam suporte
o conjunto exato de formatos de armazenamento de dados de repositório em uso pelo repositório que os criou.
Normalmente, um servidor mais recente pode fornecer dados compatíveis com clientes mais antigos. Contudo,
de streaming clonar Pacotes não tem essa garantia. servidor operadores necessidade para be consciente que
mais novo versões of mercurial pode produzir de streaming clonar Pacotes incompatível com mais velho
mercurial versões.

Um operador de servidor é responsável por criar um .hg / clonebundles.manifest arquivo contendo
a lista de arquivos de pacote disponíveis adequados para a propagação de clones. Se este arquivo não
existir, o repositório não anunciará a existência de pacotes clone quando os clientes
conectar.

O arquivo de manifesto contém uma lista de entradas delimitada por nova linha ().

Cada linha neste arquivo define um pacote disponível. As linhas têm o formato:

[ = [ = ]]

Ou seja, um URL seguido por uma lista opcional delimitada por espaço de pares chave = valor que descrevem
propriedades adicionais deste pacote. Tanto as chaves quanto os valores são codificados por URI.

As chaves em MAIÚSCULAS são reservadas para uso pelo Mercurial e são definidas abaixo. Tudo
chaves não maiúsculas podem ser usadas pelas instalações do site. Um exemplo de uso para propriedades personalizadas
é usar o data centers atributo para definir em qual datacenter um arquivo está hospedado.
Os clientes podem então preferir um servidor no data center mais próximo a eles.

As seguintes chaves reservadas estão definidas atualmente:

BUNDLESPEC
Uma string de "especificação do pacote" que descreve o tipo do pacote.

Estes são valores de string que são aceitos pelo argumento "--type" de hg empacotar.

Os valores são analisados ​​em modo estrito, o que significa que devem ser do
" - "formulário. Veja mercurial.exchange.parsebundlespec () para mais
Detalhes.

hg pacote de depuração --especificação pode ser usado para imprimir a string de especificação do pacote para um
arquivo de pacote. A saída deste comando pode ser usada literalmente para o valor de
BUNDLESPEC (já escapou).

Os clientes filtrarão automaticamente as especificações que são desconhecidas ou
sem suporte para que eles não tentem fazer o download de algo que provavelmente não se aplica.

O valor real não afeta o comportamento do cliente além da filtragem: os clientes irão
ainda fareja o tipo de pacote no cabeçalho dos arquivos baixados.

Use of isto chave is altamente Recomenda, pois permite que os clientes ignorem facilmente
pacotes não suportados. Se esta chave não for definida, um cliente antigo pode tentar aplicar
um pacote que é incapaz de ler.

REQUISITOS
Se a Indicação do nome do servidor (SNI) é necessária para se conectar ao URL. SNI permite
servidores para usar vários certificados no mesmo IP. É um tanto comum em CDNs
e outros provedores de hospedagem. Versões mais antigas do Python não suportam SNI. Definindo
este atributo permite que clientes com versões Python mais antigas filtrem esta entrada
sem experimentar uma falha de SSL opaca no momento da conexão.

Se estiver definido, é importante anunciar um URL substituto não SNI ou clientes
rodar versões antigas do Python pode não conseguir clonar com os clonebundles
instalação.

O valor deve ser "verdadeiro".

Os manifestos podem conter várias entradas. Supondo que os metadados estejam definidos, os clientes filtrarão
entradas do manifesto que eles não suportam. As entradas restantes são opcionalmente
classificado pelas preferências do cliente (experimental.clonebundlepreferes opção de configuração). O cliente
em seguida, tenta buscar o pacote no primeiro URL da lista restante.

erros quando descarga a empacotar precisarão falhar que o todo clonar Operação: clientes do não
automaticamente cair em caminho duplo para a tradicional clonar. A razão para isso é que se um servidor é
usando pacotes clones, provavelmente está fazendo isso porque o recurso é necessário para ajudá-lo
régua. Em outras palavras, existe uma suposição de que a carga do clone será descarregada para outro
serviço e que o servidor Mercurial não é responsável por servir esta carga clone. Se
que outros problemas de serviço experimentam e os clientes começam a voltar em massa para o original
Servidor Mercurial, a carga de clone adicionada pode sobrecarregar o servidor devido a uma carga inesperada
e efetivamente colocá-lo off-line. Não ter clientes voltando automaticamente para a clonagem
do servidor original atenua esse cenário.

Porque não há fallback automático do servidor Mercurial em caso de falha do pacote de hospedagem
serviço, é importante para os operadores de servidor ver o serviço de hospedagem de pacote como um
extensão do servidor Mercurial em termos de disponibilidade e acordos de nível de serviço:
se o serviço de hospedagem do pacote cair, o mesmo acontecerá com a capacidade de clonagem dos clientes. Observação:
os clientes verão uma mensagem informando-os sobre como contornar o recurso de clone de pacotes quando um
falha ocorre. Portanto, os operadores de servidor devem se preparar para que algumas pessoas sigam estes
instruções quando ocorre uma falha, conduzindo assim mais carga ao Mercurial original
servidor quando o serviço de hospedagem do pacote falha.

cor
colorir a saída de alguns comandos

A extensão de cor coloriza a saída de vários comandos do Mercurial. Por exemplo, o
O comando diff mostra as adições em verde e as exclusões em vermelho, enquanto o comando de status mostra
arquivos modificados em magenta. Muitos outros comandos têm cores análogas. É possível
personalizar essas cores.

Efeito
Outros efeitos além da cor, como texto em negrito e sublinhado, também estão disponíveis. Por
padrão, o banco de dados terminfo é usado para encontrar os códigos de terminal usados ​​para mudar a cor e
efeito. Se o terminfo não estiver disponível, os efeitos são processados ​​com ECMA-48 SGR
função de controle (também conhecido como códigos de escape ANSI).

Os efeitos disponíveis no modo terminfo são 'piscar', 'negrito', 'escurecer', 'inverso', 'invisível',
'itálico', 'destaque' e 'sublinhado'; no modo ECMA-48, as opções são 'negrito', 'inverso',
'itálico' e 'sublinhado'. Como cada um é renderizado depende do emulador de terminal. Algum
pode não estar disponível para um determinado tipo de terminal e será ignorado silenciosamente.

Rótulos
O texto recebe efeitos de cor dependendo dos rótulos que possui. Muitos Mercurial padrão
comandos emitem texto rotulado. Você também pode definir seus próprios rótulos em modelos usando o
função de rótulo, veja hg ajudar modelos. Uma única parte do texto pode ter mais de um
etiqueta. Nesse caso, os efeitos dados ao último rótulo substituirão quaisquer outros efeitos. Isto
inclui o efeito especial "nenhum", que anula outros efeitos.

As etiquetas são normalmente invisíveis. Para ver esses rótulos e sua posição no
texto, use a opção global --color = debug. O mesmo texto âncora pode ser associado a
rótulos múltiplos, por exemplo

[log.changeset changeset.secret|changeset: 22611:6f0a53c8f587]

A seguir estão os efeitos padrão para alguns rótulos padrão. Os efeitos padrão podem ser
substituído em seu arquivo de configuração:

[cor]
status.modified = blue bold sublinhado red_background
status.added = verde negrito
status.removed = vermelho negrito blue_background
status.deleted = ciano sublinhado em negrito
status.unknown = sublinhado em negrito magenta
status.ignored = negrito preto

# 'nenhum' desativa todos os efeitos
status.clean = nenhum
status.copied = nenhum

qseries.applied = sublinhado em negrito azul
qseries.unapplied = negrito preto
qseries.missing = negrito vermelho

diff.diffline = negrito
diff.extended = ciano negrito
diff.file_a = negrito vermelho
diff.file_b = verde negrito
dif.hunk = magenta
diff.excluído = vermelho
diff.inserido = verde
diff.alterado = branco
diferença.tab =
diff.trailingwhitespace = negrito red_background

# Em branco para que herde o estilo do rótulo ao redor
conjunto de alterações.public =
changeset.rascunho =
conjunto de alterações.secret =

resolve.unresolved = negrito vermelho
resolve.resolved = verde em negrito

bookmarks.active = verde

branches.ativo = nenhum
branches.closed = preto em negrito
branches.current = verde
branches.inativo = nenhum

tags.normal = verde
tags.local = negrito preto

rebase.rebaseado = azul
rebase.remaining = vermelho negrito

prateleira.idade = ciano
shelve.newest = verde em negrito
shelve.name = negrito azul

histedit.remaining = negrito vermelho

Personalizadas cores
Como existem apenas oito cores padrão, este módulo permite que você defina nomes de cores
para outros slots de cores que podem estar disponíveis para o seu tipo de terminal, assumindo terminfo
modo. Por exemplo:

cor.brightblue = 12
cor.rosa = 207
cor.laranja = 202

para definir 'azul claro' para o slot de cor 12 (útil para terminais de 16 cores que possuem
cores definidas nas oito superiores) e, 'rosa' e 'laranja' para cores em xterm de 256 cores
cubo de cor padrão. Essas cores definidas podem então ser usadas como qualquer uma das
oito, incluindo anexar '_background' para definir o plano de fundo para essa cor.

Modos
Por padrão, a extensão de cor usará o modo ANSI (ou o modo win32 no Windows) se
detecta um terminal. Para substituir o modo automático (para ativar o modo terminfo, por exemplo), defina o
seguinte opção de configuração:

[cor]
modo = terminfo

Qualquer valor diferente de 'ansi', 'win32', 'terminfo' ou 'auto' desativará a cor.

Observe que em alguns sistemas, o modo terminfo pode causar problemas ao usar cores com o
extensão do pager e menos -R. menos com a opção -R exibirá apenas a cor ECMA-48
códigos e o modo terminfo podem, às vezes, emitir códigos que menos não entende. Você pode
contornar isso usando o modo ansi (ou modo automático) ou usando less -r (que irá
passar por todos os códigos de controle de terminal, não apenas códigos de controle de cores).

Em alguns sistemas (como MSYS no Windows), o terminal pode suportar um modo de cor diferente
do que o pager (ativado por meio do ramal "pager"). É possível definir separadamente
modos dependendo se o pager está ativo:

[cor]
modo = automático
modo de paginação = ansi

If modo de pager não está definido, o modo será usada.

comandos
converter
importar revisões de repositórios VCS estrangeiros para o Mercurial

comandos
converter
converter um repositório SCM estrangeiro em um Mercurial:

hg convert [OPÇÃO] ... FONTE [DEST [REVMAP]]

Formatos de origem aceitos [identificadores]:

· Mercúrio [hg]

· CVS [cvs]

· Darcos [darcos]

· Git [git]

· Subversão [svn]

· Monótono [mtn]

· Arco GNU [gnuarch]

· Bazar [bzr]

· Força [pág. 4]

Formatos de destino aceitos [identificadores]:

· Mercúrio [hg]

· Subversion [svn] (o histórico nos ramos não é preservado)

Se nenhuma revisão for fornecida, todas as revisões serão convertidas. Caso contrário, converter apenas
importar até a revisão nomeada (fornecida em um formato compreendido pela fonte).

Se nenhum nome de diretório de destino for especificado, o padrão é o nome de base da fonte
com -hg anexado. Se o repositório de destino não existir, ele será criado.

Por padrão, todas as fontes, exceto Mercurial, usarão --branchsort. Mercurial usa
--sourcesort para preservar a ordem dos números da revisão original. Os modos de classificação têm o seguinte
efeitos:

--branchsort
converter de revisão pai para filho quando possível, o que significa que os ramos são
geralmente convertido um após o outro. Ele gera repositórios mais compactos.

--datesort
classificar as revisões por data. Repositórios convertidos têm changelogs bonitos, mas são
frequentemente uma ordem de magnitude maior do que as mesmas geradas por --branchsort.

--sourcesort
tente preservar a ordem das revisões da fonte, apenas com o suporte de fontes do Mercurial.

--closesort
tente mover as revisões fechadas o mais próximo possível das ramificações principais, apenas
suportado por fontes Mercurial.

If REVMAP não for fornecido, ele será colocado em um local padrão (/.hg/shamap by
padrão). O REVMAP é um arquivo de texto simples que mapeia cada ID de confirmação de origem para o
ID de destino para essa revisão, como:



Se o arquivo não existir, ele será criado automaticamente. É atualizado a cada commit copiado,
so hg converter pode ser interrompido e executado repetidamente para copiar novos commits.

O authormap é um arquivo de texto simples que mapeia cada autor de commit de origem para um destino
cometer autor. É útil para SCMs de origem que usam logins unix para identificar os autores (por exemplo:
CVS). Uma linha por mapeamento de autor e o formato da linha é:

autor de origem = autor de destino

Linhas vazias e linhas começando com um # são ignorados.

O mapa de arquivos é um arquivo que permite filtrar e remapear arquivos e diretórios. Cada
linha pode conter uma das seguintes diretivas:

incluir caminho / para / arquivo-ou-dir

excluir caminho / para / arquivo-ou-dir

renomear caminho / para / caminho de origem / para / destino

As linhas de comentário começam com #. Um caminho especificado corresponde se for igual ao nome relativo completo
de um arquivo ou um de seus diretórios pai. O incluir or excluir diretiva com o
o caminho de correspondência mais longo se aplica, portanto a ordem da linha não importa.

A incluir diretiva faz com que um arquivo, ou todos os arquivos em um diretório, sejam incluídos no
repositório de destino. O padrão se não houver incluir declarações devem incluir
tudo. Se houver algum incluir declarações, nada mais é incluído. O excluir
diretiva faz com que arquivos ou diretórios sejam omitidos. O rebatizar diretiva renomeia um arquivo
ou diretório se for convertido. Para renomear de um subdiretório para a raiz do
repositório, use . como o caminho para renomear.

--cheio irá certificar-se de que os changesets convertidos contêm exatamente os arquivos corretos com o
conteúdo certo. Ele fará uma conversão completa de todos os arquivos, não apenas aqueles que têm
mudado. Os arquivos que já estão corretos não serão alterados. Isso pode ser usado para aplicar
o mapa de arquivos muda ao converter incrementalmente. No momento, isso é compatível apenas com
Mercurial e Subversion.

O splicemap é um arquivo que permite a inserção de histórico sintético, permitindo que você especifique
os pais de uma revisão. Isto é útil se você deseja, por exemplo, dar a um Subversion merge dois
pais, ou enxertar duas séries desconectadas de história juntas. Cada entrada contém uma chave,
seguido por um espaço, seguido por um ou dois valores separados por vírgula:

chave pai1, pai2

A chave é o ID de revisão no sistema de controle de revisão de origem, cujos pais devem ser
modificado (mesmo formato de uma chave em .hg / shamap). Os valores são os IDs de revisão (em qualquer
o sistema de controle de revisão de origem ou destino) que deve ser usado como os novos pais
para esse nó. Por exemplo, se você fundiu "release-1.0" em "trunk", então você deve
especifique a revisão em "trunk" como o primeiro pai e aquela no "release-1.0"
ramo como o segundo.

O branchmap é um arquivo que permite renomear uma ramificação quando ela está sendo trazida
de qualquer repositório externo. Quando usado em conjunto com um splicemap, permite
para uma combinação poderosa para ajudar a corrigir até mesmo os repositórios mais mal gerenciados e
transformá-los em repositórios Mercurial bem estruturados. O branchmap contém linhas de
a forma:

nome_da_filial original novo nome_da_filial

onde "original_branch_name" é o nome da ramificação no repositório de origem e
"new_branch_name" é o nome da ramificação que é o repositório de destino. Sem espaço em branco
é permitido nos nomes das ramificações. Isso pode ser usado para (por exemplo) mover o código em um
repositório de "padrão" para um branch nomeado.

mercurial fonte
A fonte Mercurial reconhece as seguintes opções de configuração, que você pode definir em
a linha de comando com --config:

convert.hg.ignoreerrors
ignore erros de integridade durante a leitura. Use-o para corrigir repositórios Mercurial com
revlogs ausentes, convertendo de e para Mercurial. O padrão é Falso.

converter.hg.saverev
armazene o ID de revisão original no changeset (força os IDs de destino a serem alterados). Leva um
argumento booleano e o padrão é False.

converter.hg.startrev
especifique a revisão inicial do Mercurial. O padrão é 0.

converter.hg.revs
revset especificando as revisões de origem a serem convertidas.

CVS fonte
A fonte do CVS usará uma sandbox (ou seja, uma cópia com check-out) do CVS para indicar o início
ponto do que será convertido. O acesso direto aos arquivos do repositório não é necessário,
a menos que o repositório seja :local:. A conversão usa o diretório de nível superior em
sandbox para encontrar o repositório CVS e, em seguida, usa os comandos CVS rlog para encontrar arquivos para
converter. Isso significa que, a menos que um mapa de arquivos seja fornecido, todos os arquivos no diretório inicial
será convertido e que qualquer reorganização de diretório na caixa de proteção CVS será ignorada.

As seguintes opções podem ser usadas com --config:

converter.cvsps.cache
Defina como False para desabilitar o cache de log remoto, para fins de teste e depuração.
O padrão é Verdadeiro.

converter.cvsps.fuzz
Especifique o tempo máximo (em segundos) permitido entre commits com
usuário idêntico e mensagem de log em um único changeset. Quando arquivos muito grandes foram
verificado como parte de um conjunto de alterações, o padrão pode não ser longo o suficiente. O
o padrão é 60.

convert.cvsps.mergeto
Especifique uma expressão regular à qual as mensagens de log de confirmação sejam correspondidas. Se uma partida
ocorrer, então o processo de conversão irá inserir uma revisão fictícia mesclando o branch
em que esta mensagem de log ocorre para a ramificação indicada na regex. O padrão é
{{mergetobranch ([-\w]+)}}

convert.cvsps.mergefrom
Especifique uma expressão regular à qual as mensagens de log de confirmação sejam correspondidas. Se uma partida
ocorrer, então o processo de conversão adicionará a revisão mais recente no branch
indicado na regex como o segundo pai do changeset. O padrão é
{{mergefrombranch ([-\w]+)}}

converter.localtimezone
use a hora local (conforme determinado pela variável de ambiente TZ) para o changeset
data/horas. O padrão é False (use UTC).

ganchos.cvslog
Especifique uma função Python a ser chamada no final da coleta do log CVS. O
função recebe uma lista com as entradas de log e pode modificar as entradas
no local ou adicioná-los ou excluí-los.

ganchos.cvschangesets
Especifique uma função Python a ser chamada após os conjuntos de alterações serem calculados a partir do
Registro CVS. A função recebe uma lista com as entradas do changeset e pode modificar
os conjuntos de alterações no local ou adicione ou exclua-os.

Um comando Mercurial "debugcvsps" adicional permite que o código de mesclagem do conjunto de alterações embutido
ser executado sem fazer uma conversão. Seus parâmetros e saída são semelhantes aos do cvsps
2.1. Consulte a ajuda do comando para obter mais detalhes.

Subversão fonte
A fonte do Subversion detecta layouts clássicos de tronco/ramificações/tags. Por padrão, o fornecido
svn://repo/caminho/ URL de origem é convertido como uma única ramificação. Se svn://repo/caminho/tronco
existe, ele substitui o branch padrão. Se svn://repo/caminho/branches existe, sua
subdiretórios são listados como possíveis ramificações. Se svn://repo/caminho/tags existe é
procurei por tags referenciando branches convertidos. Padrão tronco, ramos e Tag valores
pode ser substituído com as seguintes opções. Defina-os para caminhos relativos ao URL de origem ou
deixe-os em branco para desativar a detecção automática.

As seguintes opções podem ser definidas com --config:

convert.svn.braches
especifique o diretório que contém as ramificações. O padrão é ramos.

converter.svn.tags
especifique o diretório que contém as tags. O padrão é Tag.

converter.svn.trunk
especifique o nome da ramificação do tronco. O padrão é tronco.

converter.localtimezone
use a hora local (conforme determinado pela variável de ambiente TZ) para o changeset
data/horas. O padrão é False (use UTC).

O histórico de origem pode ser recuperado a partir de uma revisão específica, em vez de ser
convertido integralmente. Apenas conversões de ramificação única são suportadas.

converter.svn.startrev
especifique o número de revisão inicial do Subversion. O padrão é 0.

Git fonte
O importador Git converte commits de todos os branches acessíveis (refs em refs/heads) e
remotes (refs em refs/remotes) para Mercurial. As ramificações são convertidas em marcadores com o
mesmo nome, com os 'refs/heads' principais removidos. Os submódulos Git são convertidos para Git
subrepos no Mercurial.

As seguintes opções podem ser definidas com --config:

convert.git.similaridade
especificar como arquivos semelhantes modificados em um commit devem ser importados como renomeações ou
cópias, como uma porcentagem entre 0 (desativado) e 100 (os arquivos devem ser idênticos). Por
exemplo, 90 significa que um par excluir/adicionar será importado como uma renomeação se mais de
90% do arquivo não mudou. O padrão é 50.

convert.git.findcopiesharder
ao detectar cópias, veja todos os arquivos na cópia de trabalho em vez de apenas
os alterados. Isso é muito caro para grandes projetos e só é eficaz quando
convert.git.similaridade é maior que 0. O padrão é False.

convert.git.remoteprefix
refs remotos são convertidos como marcadores com convert.git.remoteprefix como um prefixo
seguido por um /. O padrão é 'remoto'.

convert.git.skipsubmodules
não converte arquivos .gitmodules de nível raiz ou arquivos com modo 160000 indicando
um submódulo. O padrão é Falso.

Forçar fonte
O importador Perforce (P4) pode receber um caminho de depósito p4 ou uma especificação de cliente como
fonte. Ele converterá todos os arquivos na fonte para um repositório Mercurial simples, ignorando
rótulos, ramificações e integrações. Observe que quando um caminho de depósito é fornecido, geralmente
deve especificar um diretório de destino, caso contrário o destino pode ser nomeado ...-hg.

As seguintes opções podem ser definidas com --config:

convert.p4.encoding
especifique a codificação a ser usada ao decodificar a saída padrão do comando Perforce
ferramenta de linha. O padrão é a codificação do sistema padrão.

converter.p4.startrev
especifique a revisão inicial do Perforce (um número da lista de alterações do Perforce).

mercurial Destino
O destino Mercurial reconhecerá os subrepositórios Mercurial no destino
diretório e atualize o arquivo .hgsubstate automaticamente se o destino
subrepositórios contêm o / /.hg/shamap arquivo. Convertendo um repositório com
subrepositórios requer a conversão de um único repositório por vez, de baixo para cima.

Um exemplo mostrando como converter um repositório com subrepositórios:

# então o convert sabe o tipo quando vê um destino não vazio
$ hg init convertido

$ hg converter original/sub1 convertido/sub1
$ hg converter original/sub2 convertido/sub2
$ hg converter original convertido

As seguintes opções são suportadas:

convert.hg.clonebranchs
despachar ramificações de origem em clones separados. O padrão é falso.

converter.hg.tagsbranch
nome da ramificação para revisões de tags, o padrão é omissão.

converter.hg.usebranchnames
preservar nomes de ramificações. O padrão é verdadeiro.

converter.hg.nomedafonte
registra a string dada como um valor extra 'convert_source' em cada commit feito em
o repositório de destino. O padrão é Nenhum.

Todos os Produtos Destinos
Todos os tipos de destino aceitam as seguintes opções:

converter.skiptags
não converte tags do repositório de origem para o repositório de destino. O padrão é
Falso.

opções:

--autores
nome de arquivo de mapeamento de nome de usuário (OBSOLETO) (use --authormap em vez disso)

-sim,--tipo-fonte
tipo de repositório de origem

-d,--dest-type
tipo de repositório de destino

-r,--rev
importar até a revisão da fonte REV

-UMA,--autormap
remapear nomes de usuário usando este arquivo

--filemap
remapear nomes de arquivos usando o conteúdo do arquivo

--cheio aplique alterações no mapa de arquivos convertendo todos os arquivos novamente

--splicemap
emendar a história sintetizada no lugar

--branchmap
alterar os nomes das ramificações durante a conversão

--branchsort
tente ordenar changesets por branches

--datesort
tente classificar conjuntos de alterações por data

--sourcesort
preservar a ordem dos conjuntos de alterações de origem

--closesort
tente reordenar revisões fechadas

A opção marcada [+] pode ser especificada várias vezes

eol
gerenciar automaticamente novas linhas em arquivos de repositório

Esta extensão permite que você gerencie o tipo de terminações de linha (CRLF ou LF) que são usadas em
no repositório e no diretório de trabalho local. Dessa forma, você pode obter terminações de linha CRLF
no Windows e LF no Unix/Mac, permitindo assim que todos usem suas terminações de linha nativas do sistema operacional.

A extensão lê sua configuração de uma versão .hgeol arquivo de configuração encontrado em
a raiz do diretório de trabalho. O .hgeol arquivo use a mesma sintaxe que todos os outros
Arquivos de configuração do Mercurial. Ele usa duas seções, [padrões] e [repositório].

A [padrões] seção especifica como os finais de linha devem ser convertidos entre o trabalho
diretório e o repositório. O formato é especificado por um padrão de arquivo. A primeira partida
é usado, então coloque padrões mais específicos primeiro. As terminações de linha disponíveis são LF, CRLF e
BIN.

Arquivos com o formato declarado de CRLF or LF são sempre verificados e armazenados no
repositório nesse formato e arquivos declarados como binários (BIN) permanecem inalterados.
Além disso, nativo é um alias para fazer check-out no final de linha padrão da plataforma:
LF no Unix (incluindo Mac OS X) e CRLF no Windows. Observe que BIN (não faça nada para alinhar
terminações) é o comportamento padrão do Mercurial; só é necessário se você precisar substituir um
mais tarde, um padrão mais geral.

O opcional [repositório] especifica as terminações de linha a serem usadas para arquivos armazenados em
o repositório. Possui uma configuração única, nativo, que determina as terminações da linha de armazenamento
para arquivos declarados como nativo no [padrões] seção. Pode ser definido para LF or CRLF. O
padrão é LF. Por exemplo, isso significa que no Windows, os arquivos configurados como nativo (CRLF
por padrão) será convertido para LF quando armazenado no repositório. Arquivos declarados como LF,
CRLFou BIN no [padrões] seção são sempre armazenados como estão no repositório.

Exemplo com versão .hgeol arquivo:

[padrões]
**.py = nativo
**.vcproj=CRLF
**.txt = nativo
Makefile=LF
**.jpg = BIN

[repositório]
nativo = LF

Nota As regras serão aplicadas primeiro quando os arquivos forem tocados no diretório de trabalho, por exemplo, por
atualizando para null e de volta para tip para tocar em todos os arquivos.

A extensão usa um opcional [eol] seção lida tanto do Mercurial normal
arquivos de configuração e o .hgeol arquivo, com o último substituindo o primeiro. Você pode
use essa seção para controlar o comportamento geral. Existem três configurações:

· eol.nativo (padrão os.linesep) pode ser definido para LF or CRLF para substituir o padrão
Interpretação de nativo para check-out. Isso pode ser usado com hg arquivo no Unix, digamos, para
gerar um arquivo onde os arquivos tenham terminações de linha para Windows.

· eol.somente consistente (padrão True) pode ser definido como False para converter a extensão
arquivos com EOLs inconsistentes. Inconsistente significa que há ambos CRLF e LF presente
no arquivo. Esses arquivos normalmente não são tocados sob a suposição de que eles
EOLs mistos de propósito.

· eol.fix-trailing-newline (padrão False) pode ser definido como True para garantir que
arquivos terminam com um caractere EOL (ou \n or \ R \ n conforme os padrões configurados).

A extensão fornece codificação inteligente: e decodificação inteligente: filtros como o obsoleto
extensão win32text faz. Isso significa que você pode desabilitar o win32text e habilitar eol e
seus filtros ainda funcionarão. Você só precisa desses filtros até ter preparado um
.hgeol arquivo.

A win32text.forbid* ganchos fornecidos pela extensão win32text foram unificados em um
único gancho chamado eol.checkheadsook. O gancho procurará os finais de linha esperados de
que o .hgeol arquivo, o que significa que você deve migrar para um .hgeol arquivo antes de usar o
gancho. eol.checkheadsook apenas verifica as cabeças, revisões inválidas intermediárias serão enviadas.
Para proibi-los completamente, use o eol.checkallook gancho. Esses ganchos são melhor usados ​​como
pretxnchangegroup ganchos.

See hg ajudar padrões para obter mais informações sobre os padrões glob usados.

extdiff
comando para permitir que programas externos comparem as revisões

A extensão extdiff Mercurial permite que você use programas externos para comparar revisões,
ou revisão com diretório de trabalho. Os programas de comparação externa são chamados com um
conjunto configurável de opções e dois argumentos não opcionais: caminhos para diretórios contendo
instantâneos de arquivos para comparar.

A extensão extdiff também permite configurar novos comandos diff, para que você não precise
digitar hg extdiff -p kdiff3 sempre.

[extdiff]
# adiciona um novo comando que executa o GNU diff(1) no modo 'diferença de contexto'
cdiff = gdiff -Nprc5
## ou da maneira antiga:
#cmd.cdiff = gdiff
#opts.cdiff = -Nprc5

# adiciona um novo comando chamado meld, executa o meld (não é necessário nomear duas vezes). Se
# o executável meld não está disponível, a ferramenta meld em [merge-tools]
# será usado, se disponível
fusão =

# adiciona um novo comando chamado vimdiff, executa o gvimdiff com o plugin DirDiff
# (Vejo http://www.vim.org/scripts/script.php?script_id=102) Não
# Usuário em inglês, certifique-se de colocar "let g:DirDiffDynamicDiffText = 1" em
# seu .vimrc
vimdiff = gvim -f "+próximo" \
"+execute 'DirDiff' fnameescape(argumento(0)) fnameescape(argumento(1)) "

Os argumentos da ferramenta podem incluir variáveis ​​que são expandidas em tempo de execução:

$parent1, $platel1 - nome do arquivo, rótulo descritivo do primeiro pai
$child, $clabel - nome do arquivo, rótulo descritivo da revisão filha
$parent2, $platel2 - nome do arquivo, rótulo descritivo do segundo pai
$root - raiz do repositório
$parent é um alias para $parent1.

A extensão extdiff irá procurar em suas seções [diff-tools] e [merge-tools] para diff
argumentos da ferramenta, quando nenhum for especificado em [extdiff].

[extdiff]
kdiff3 =

[ferramentas de diferenças]
kdiff3.diffargs=--L1 '$plabel1' --L2 '$classe' $pai $filho

Você pode usar -I/-X e lista de nomes de arquivos ou diretórios como normal hg diff comando. o
A extensão extdiff cria instantâneos apenas dos arquivos necessários, portanto, executando o diff externo
programa será realmente muito rápido (pelo menos mais rápido do que ter que comparar todo o
árvore).

comandos
extdiff
use um programa externo para diferenciar o repositório (ou arquivos selecionados):

hg extdiff [OPT]... [ARQUIVO]...

Mostre as diferenças entre as revisões dos arquivos especificados, usando um programa externo. O
programa padrão usado é diff, com opções padrão "-Npru".

Para selecionar um programa diferente, use a opção -p/--program. O programa será passado o
nomes de dois diretórios para comparar. Para passar opções adicionais ao programa, use
-o/--opção. Estes serão passados ​​antes dos nomes dos diretórios a serem comparados.

Quando dois argumentos de revisão são fornecidos, as alterações são mostradas entre essas revisões. Se
apenas uma revisão é especificada, então essa revisão é comparada ao diretório de trabalho,
e, quando nenhuma revisão é especificada, os arquivos do diretório de trabalho são comparados com seus
pai.

opções:

-p,--programa
programa de comparação para executar

-ó,--opção
opção de passagem para programa de comparação

-r,--rev
revisão

-c,--mudança
mudança feita por revisão

--correção
comparar patches para duas revisões

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

faz-tudo
autenticação http com factotum

Esta extensão permite que o faz-tudo(4) instalação no Plano 9 das plataformas Bell Labs para
fornecer informações de autenticação para acesso HTTP. As entradas de configuração especificadas no
auth, bem como as informações de autenticação fornecidas na URL do repositório são
totalmente suportado. Se nenhum prefixo for especificado, um valor de "*" será assumido.

Por padrão, as chaves são especificadas como:

proto=pass service=hg prefix= usuário= !senha=

Se a extensão fatotum não conseguir ler a chave necessária, uma será solicitada
interativamente.

Uma seção de configuração está disponível para personalizar o comportamento do tempo de execução. Por padrão, esses
entradas são:

[faz-tudo]
executável = /bin/auth/factotum
ponto de montagem = /mnt/factotum
serviço = hg

A entrada executável define o caminho completo para o binário factotum. A entrada do ponto de montagem
define o caminho para o serviço de arquivo fatotum. Por último, a entrada de serviço controla a
nome do serviço usado ao ler as chaves.

buscar
puxar, atualizar e mesclar em um comando (OBSOLETO)

comandos
buscar
puxe as alterações de um repositório remoto, mescle novas alterações, se necessário.:

hg buscar [FONTE]

Isso encontra todas as alterações do repositório no caminho ou URL especificado e as adiciona ao
o repositório local.

Se as alterações extraídas adicionarem um novo cabeçalho de ramificação, o cabeçalho será mesclado automaticamente e o
resultado da mesclagem é confirmado. Caso contrário, o diretório de trabalho é atualizado para incluir
as novas mudanças.

Quando uma mesclagem é necessária, o diretório de trabalho é atualizado primeiro para o diretório recém-puxado
alterar. As alterações locais são então mescladas nas alterações extraídas. Para mudar a ordem de mesclagem,
use --switch-parent.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

Retorna 0 em caso de sucesso.

opções:

-r,--rev
uma revisão específica que você gostaria de puxar

-e --editar
invocar editor em mensagens de confirmação

--force-editor
editar mensagem de confirmação (OBSOLETO)

--switch-pai
troque os pais ao mesclar

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

gpg
comandos para assinar e verificar changesets

comandos
sigcheck
verifique todas as assinaturas que possam existir para uma determinada revisão:

hg sigcheck REV

verificar todas as assinaturas que possam existir para uma determinada revisão

assinar
adicione uma assinatura para a revisão atual ou dada:

sinal hg [OPÇÃO]... [REV]...

Se nenhuma revisão for fornecida, o pai do diretório de trabalho será usado ou dica se não houver
revisão é verificada.

A gpg.cmd config pode ser usada para especificar o comando a ser executado. Uma chave padrão pode ser
especificado com gpg.key.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

opções:

-eu, --local
fazer a assinatura local

-f, --força
assinar mesmo se o sigfile for modificado

--sem compromisso
não confirme o sigfile depois de assinar

-k,--chave
o ID da chave para assinar

-m,--mensagem
usar texto como mensagem de confirmação

-e --editar
invocar editor em mensagens de confirmação

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

assinaturas
listar conjuntos de alterações assinados:

assinaturas hg

listar conjuntos de alterações assinados

registro gráfico
comando para visualizar gráficos de revisão de um shell (OBSOLETO)

A funcionalidade desta extensão foi incluída no núcleo Mercurial desde a versão 2.3.
Por favor, use hg log -G ... ao invés.

Esta extensão adiciona uma opção --graph aos comandos de entrada, saída e log. Quando isso
opções são fornecidas, uma representação ASCII do gráfico de revisão também é mostrada.

comandos
espinheiro
mostre o histórico de revisões ao lado de um gráfico de revisão ASCII:

hg glog [OPÇÃO]... [ARQUIVO]

Imprima um histórico de revisões ao lado de um gráfico de revisão desenhado com caracteres ASCII.

Os nós impressos como um caractere @ são pais do diretório de trabalho.

Este é um apelido para hg log -G.

opções:

-f, --Segue
siga o histórico do changeset ou o histórico do arquivo entre cópias e renomeações

--seguir primeiro
siga apenas o primeiro pai dos conjuntos de alterações de mesclagem (DESCONTINUADO)

-d,--data
mostrar revisões que correspondem às especificações da data

-C, --cópias
mostrar arquivos copiados

-k,--palavra-chave
faça uma pesquisa sem distinção entre maiúsculas e minúsculas para um determinado texto

-r,--rev
mostra a revisão ou revset especificada

--removido
incluir revisões onde os arquivos foram removidos

-m, --only-merge
mostrar apenas mesclagens (DESCONTINUADO)

-você,--do utilizador
revisões cometidas pelo usuário

--só-ramo
mostrar apenas changesets dentro do branch nomeado fornecido (DESCONTINUADO)

-b,--filial
mostrar changesets dentro de um determinado branch nomeado

-P,--ameixa seca
não exibe revisão ou qualquer um de seus ancestrais

-p, --correção
mostrar patch

-g, --git
usar formato de diff estendido git

-eu,--limite
número limite de alterações exibidas

-M, --sem mesclas
não mostrar mesclagens

--Estado saída de resumo de mudanças no estilo diffstat

-G, --gráfico
mostrar a revisão DAG

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

hgcia
ganchos para integração com o serviço de notificação CIA.vc

Isso deve ser executado como um grupo de mudanças ou gancho de entrada. Para configurá-lo, defina o
seguintes opções no seu hgrc:

[cia]
# seu nome de usuário registrado da CIA
usuário = fo
# o nome do projeto na CIA
projeto = fo
# o módulo (subprojeto) (opcional)
#módulo = foo
# Anexar um diffstat à mensagem de log (opcional)
#diffstat = Falso
# Modelo a ser usado para mensagens de log (opcional)
#template = {desc}\n{baseurl}{webroot}/rev/{node}-- {diffstat}
# Estilo a ser usado (opcional)
#estilo = fo
# A URL do serviço de notificação da CIA (opcional)
# Você pode usar mailto: URLs para enviar por e-mail, por exemplo
# mailto:[email protegido]
# Certifique-se de definir email.from se você fizer isso.
#url= http://cia.vc/
# imprime a mensagem ao invés de enviá-la (opcional)
#teste = Falso
# número de barras a serem removidas para caminhos de URL
#tira = 0

[ganchos]
# um desses:
changegroup.cia=python:hgcia.hook
#incoming.cia = python:hgcia.hook

[rede]
# Se você quiser hiperlinks (opcional)
urlbase = http://server/path/to/repo

hgk
navegue no repositório de forma gráfica

A extensão hgk permite navegar no histórico de um repositório de forma gráfica. Isto
requer Tcl/Tk versão 8.4 ou posterior. (Tcl/Tk não é distribuído com o Mercurial.)

hgk consiste em duas partes: um script Tcl que faz a exibição e consulta de
informações e uma extensão para Mercurial chamada hgk.py, que fornece ganchos para hgk para
obter informação. hgk pode ser encontrado no diretório contrib, e a extensão é enviada
no repositório hgext e precisa ser habilitado.

A hg view O comando iniciará o script hgk Tcl. Para que este comando funcione, hgk deve ser
no seu caminho de pesquisa. Como alternativa, você pode especificar o caminho para hgk em sua configuração
arquivo:

[hgk]
caminho = /local/de/hgk

hgk pode usar a extensão extdiff para visualizar revisões. Supondo que você tivesse
comando extdiff vdiff já configurado, basta adicionar:

[hgk]
vdiff=vdiff

O menu de contexto de revisões agora exibirá entradas adicionais para disparar o vdiff ao passar o mouse e
revisões selecionadas.

comandos
view
inicie o visualizador de histórico interativo:

hg visualização [-l LIMIT] [REVRANGE]

iniciar visualizador de histórico interativo

opções:

-eu,--limite
número limite de alterações exibidas

realçar
destaque de sintaxe para hgweb (requer pigmentos)

Depende da biblioteca de realce de sintaxe Pygments: http://pygments.org/

Existem as seguintes opções de configuração:

[rede]
pygments_style = (default: colorful)
arquivos de destaque = (padrão: tamanho('<5M'))
highlightonlymatchfilename = (padrão Falso)

destaqueapenasmatchfilename só irá destacar os arquivos se seu tipo puder ser identificado por
seu nome de arquivo. Quando isso não estiver ativado (o padrão), os Pigmentos tentarão muito
identificar o tipo de arquivo do conteúdo e qualquer correspondência (mesmo correspondências com baixa confiança
pontuação) será usado.

histórico
edição de história interativa

Com esta extensão instalada, o Mercurial ganha um novo comando: histedit. O uso é como
segue, assumindo o seguinte histórico:

@ 3[dica] 7c2fd3b9020c 2009-04-27 18:04-0500 durin42
| Adicionar delta
|
o 2 030b686bedc4 2009-04-27 18:04 -0500 durante42
| Adicionar gama
|
o 1 c561b4e977df 2009-04-27 18:04 -0500 durante42
| Adicionar beta
|
o 0 d8d2fcd0e319 2009/04/27 18:04 -0500 durin42
Adicionar alfa

Se você fosse correr hg histórico c561b4e977df, você veria o seguinte arquivo aberto em seu
editor:

escolha c561b4e977df Adicionar beta
escolha 030b686bedc4 Adicionar gama
escolha 7c2fd3b9020c Adicionar delta

# Editar histórico entre c561b4e977df e 7c2fd3b9020c
#
# Os commits são listados do menos para o mais recente
#
# Comandos:
# p, escolha = use commit
# e, edit = use commit, mas pare para corrigir
# f, fold = use commit, mas combine com o acima
# r, roll = like fold, mas descarta a descrição deste commit
# d, drop = remove commit do histórico
# m, mess = editar a mensagem do commit sem alterar o conteúdo do commit
#

Neste arquivo, as linhas que começam com # são ignorados. Você deve especificar uma regra para cada
revisão em sua história. Por exemplo, se você pretendia adicionar gama antes do beta e, em seguida,
queria adicionar delta na mesma revisão que beta, você reorganizaria o arquivo para parecer
como isso:

escolha 030b686bedc4 Adicionar gama
escolha c561b4e977df Adicionar beta
dobrar 7c2fd3b9020c Adicionar delta

# Editar histórico entre c561b4e977df e 7c2fd3b9020c
#
# Os commits são listados do menos para o mais recente
#
# Comandos:
# p, escolha = use commit
# e, edit = use commit, mas pare para corrigir
# f, fold = use commit, mas combine com o acima
# r, roll = like fold, mas descarta a descrição deste commit
# d, drop = remove commit do histórico
# m, mess = editar a mensagem do commit sem alterar o conteúdo do commit
#

Nesse ponto você fecha o editor e histórico começa a funcionar. Quando você especifica um dobrar
operação histórico abrirá um editor quando juntar essas revisões, oferecendo
você tem a chance de limpar a mensagem do commit:

Adicionar beta
***
Adicionar delta

Edite a mensagem de confirmação ao seu gosto e feche o editor. Para este exemplo, vamos
suponha que a mensagem de confirmação foi alterada para Adicionar beta e delta. Depois que o histedit for executado
e teve a chance de remover quaisquer revisões antigas ou temporárias necessárias, o histórico parece
como isso:

@ 2[dica] 989b4d060121 2009-04-27 18:04 -0500 durin42
| Adicione beta e delta.
|
o 1 081603921c3f 2009/04/27 18:04 -0500 durante42
| Adicionar gama
|
o 0 d8d2fcd0e319 2009/04/27 18:04 -0500 durin42
Adicionar alfa

Observe que histórico parece não remover quaisquer revisões (mesmo as temporárias) até depois
ele completou todas as operações de edição, então provavelmente executará várias tiras
operações quando terminar. Para o exemplo acima, ele teve que executar strip duas vezes. A tira pode ser
lento dependendo de uma variedade de fatores, então você pode precisar ser um pouco paciente. Você pode
optar por manter as revisões originais passando o --guarda bandeira.

A editar operação o levará de volta a um prompt de comando, permitindo que você edite arquivos
livremente, ou mesmo usar hg registro para confirmar algumas alterações como um commit separado. Quando você é
feito, quaisquer alterações não confirmadas restantes também serão confirmadas. Quando terminar, execute hg
histórico --Prosseguir para terminar esta etapa. Você será solicitado a fornecer uma nova mensagem de confirmação, mas
a mensagem de confirmação padrão será a mensagem original para o editar revisão ed.

A mensagem operação lhe dará a chance de revisar uma mensagem de commit sem alterar
o conteúdo. É um atalho para fazer editar imediatamente seguido por hg histórico
--continuar`.

If histórico encontra um conflito ao mover uma revisão (enquanto manipula escolher or dobrar),
ele vai parar de maneira semelhante a editar com a diferença de que não irá pedir-lhe uma
mensagem de commit quando terminar. Se você decidir neste momento que não gosta de quanto trabalho
será para reorganizar o histórico, ou que você cometeu um erro, você pode usar hg histórico --abortar
abandonar as novas alterações que você fez e retornar ao estado antes de tentar
edite seu histórico.

Se clonarmos o repositório de exemplo histedit-ed acima e adicionarmos mais quatro alterações, de modo que
temos o seguinte histórico:

@ 6[dica] 038383181893 2009-04-27 18:04 -0500 Stefan
| Adicionar teta
|
o 5 140988835471 2009-04-27 18:04 -0500 Stefan
| Adicionar eta
|
o 4 122930637314 2009-04-27 18:04 -0500 Stefan
| Adicionar zeta
|
o 3 836302820282 2009-04-27 18:04 -0500 Stefan
| Adicionar épsilon
|
o 2 989b4d060121 2009-04-27 18:04 -0500 durante42
| Adicione beta e delta.
|
o 1 081603921c3f 2009/04/27 18:04 -0500 durante42
| Adicionar gama
|
o 0 d8d2fcd0e319 2009/04/27 18:04 -0500 durin42
Adicionar alfa

Se você correr hg histórico --extrovertido no clone, então é o mesmo que executar hg histórico
836302820282. Se você precisa planejar enviar para um repositório que o Mercurial não detecta para
estar relacionado ao repositório de origem, você pode adicionar um --força opção.

Configuração
As linhas de regra Histedit são truncadas para 80 caracteres por padrão. Você pode personalizar isso
comportamento definindo um comprimento diferente em seu arquivo de configuração:

[histeditar]
linelen = 120 # truncar linhas de regra em 120 caracteres

hg histórico tenta escolher automaticamente uma revisão base apropriada para usar. Para
altere qual revisão base é usada, defina um revset em seu arquivo de configuração:

[histeditar]
defaultrev = only(.) & draft()

Por padrão, cada revisão editada precisa estar presente nos comandos histedit. Remover
revisão que você precisa usar cair Operação. Você pode configurar o drop para ser implícito para
commits ausentes adicionando:

[histeditar]
dropmissing = Verdadeiro

comandos
histórico
edite interativamente o histórico do conjunto de alterações:

hg histedit [OPÇÕES] ([ANCESTOR] | --outgoing [URL])

Este comando permite editar uma série linear de conjuntos de alterações (até e incluindo o trabalho
diretório, que deve estar limpo). Você pode:

· escolher para [re]ordenar um conjunto de alterações

· cair para omitir o conjunto de alterações

· confusão para reformular a mensagem de commit do changeset

· dobrar para combiná-lo com o conjunto de alterações anterior

· rolar como fold, mas descartando a descrição deste commit

· editar para editar este conjunto de alterações

Há várias maneiras de selecionar o changeset raiz:

· Especifique ANCESTRAL diretamente

· Use --outgoing -- será o primeiro changeset linear não incluído no destino.
(Veja hg ajudar config.default-push)

· Caso contrário, o valor da opção de configuração "histedit.defaultrev" é usado como um revset para
selecione a revisão base quando ANCESTOR não for especificado. A primeira revisão retornada por
o revset é usado. Por padrão, isso seleciona o histórico editável exclusivo do
ancestralidade do diretório de trabalho.

Se você usar --outgoing, este comando será abortado se houver revisões de saída ambíguas.
Por exemplo, se houver várias ramificações contendo revisões de saída.

Use "min(outgoing() and ::.)" ou especificação de revset semelhante em vez de --outgoing to
especifique a revisão do destino de edição exatamente em tal situação ambígua. Ver hg ajudar reviravoltas para
detalhes sobre a seleção de revisões.

Exemplos:

· Várias mudanças foram feitas. A revisão 3 não é mais necessária.

Inicie a edição do histórico a partir da revisão 3:

hg histedit -r 3

Um editor é aberto, contendo a lista de revisões, com ações específicas especificadas:

escolha 5339bf82f0ca 3 Zworgle o foobar
escolha 8ef592ce7cc4 4 Encante o zerlog
escolha 0a9639fcda9d 5 Morgificar a cromulancia

Informações adicionais sobre as possíveis ações a serem tomadas aparecem abaixo da lista de
revisões.

Para remover a revisão 3 do histórico, sua ação (no início do
line) é alterado para 'drop':

drop 5339bf82f0ca 3 Zworgle o foobar
escolha 8ef592ce7cc4 4 Encante o zerlog
escolha 0a9639fcda9d 5 Morgificar a cromulancia

· Várias mudanças foram feitas. As revisões 2 e 4 precisam ser trocadas.

Inicie a edição do histórico a partir da revisão 2:

hg histedit -r 2

Um editor é aberto, contendo a lista de revisões, com ações específicas especificadas:

escolha 252a1af424ad 2 Blorb a morgwazzle
escolha 5339bf82f0ca 3 Zworgle o foobar
escolha 8ef592ce7cc4 4 Encante o zerlog

Para trocar a revisão 2 e 4, suas linhas são trocadas no editor:

escolha 8ef592ce7cc4 4 Encante o zerlog
escolha 5339bf82f0ca 3 Zworgle o foobar
escolha 252a1af424ad 2 Blorb a morgwazzle

Retorna 0 em caso de sucesso, 1 se for necessária a intervenção do usuário (não apenas para "editar" intencional
comando, mas também para resolver conflitos inesperados).

opções:

--comandos
ler as edições do histórico do arquivo especificado

-c, --Prosseguir
continuar uma edição já em andamento

--edit-plano
editar lista de ações restantes

-k, --guarda
não retire nós antigos após a conclusão da edição

--abortar
abortar uma edição em andamento

-ó, --extrovertido
conjuntos de alterações não encontrados no destino

-f, --força
forçar a saída mesmo para repositórios não relacionados

-r,--rev
primeira revisão a ser editada

A opção marcada [+] pode ser especificada várias vezes

palavra chave
expandir palavras-chave em arquivos rastreados

Esta extensão expande $Keywords$ tipo RCS/CVS ou auto-personalizado em arquivos de texto rastreados
selecionado por sua configuração.

As palavras-chave são expandidas apenas em repositórios locais e não são armazenadas no histórico de alterações. O
mecanismo pode ser considerado como uma conveniência para o usuário atual ou para arquivamento
distribuição.

As palavras-chave se expandem para os dados do conjunto de alterações referentes à última alteração relativa ao
diretório de trabalho pai de cada arquivo.

A configuração é feita nas seções [keyword], [keywordset] e [keywordmaps] do hgrc
arquivos.

Exemplo:

[palavra-chave]
# expande palavras-chave em todos os arquivos python, exceto aqueles que correspondem a "x*"
**.py =
x* = ignorar

[conjunto de palavras-chave]
# prefere mapas de palavras-chave padrão do tipo svn- como cvs
sv = Verdadeiro

Nota Quanto mais específico você for em seus padrões de nome de arquivo, menos você perderá velocidade em
repositórios.

Para mapeamento de modelo [keywordmaps] e demonstração de expansão e execução de controle hg kwdemo.
See hg ajudar modelos para obter uma lista de modelos e filtros disponíveis.

Três filtros de modelo de data adicionais são fornecidos:

data utc

"2006/09/18 15:13:13"

svnutcdate

"2006-09-18 15:13:13Z"

svnisodato

"2006-09-18 08:13:13 -700 (seg, 18 de setembro de 2006)"

Os mapeamentos de modelo padrão (exibir com hg kwdemo -d) pode ser substituído por personalizado
palavras-chave e modelos. Novamente, corra hg kwdemo para controlar os resultados da sua configuração
alterações.

Antes de alterar/desativar palavras-chave ativas, você deve executar hg encolher para evitar o armazenamento
palavras-chave expandidas no histórico de alterações.

Para forçar a expansão após habilitá-la, ou uma mudança de configuração, execute hg kwexpandir.

Expansões que abrangem mais de uma linha e expansões incrementais, como $Log$ do CVS, são
não suportado. Um mapa de modelo de palavra-chave "Log = {desc}" se expande para a primeira linha do
descrição do conjunto de alterações.

comandos
kwdemo
print configuração de [keywordmaps] e um exemplo de expansão:

hg kwdemo [-d] [-f RCFILE] [MODELO]...

Mostre mapas de modelos de palavras-chave atuais, personalizados ou padrão e suas expansões.

Estenda a configuração atual especificando mapas como argumentos e usando -f/--rcfile para
fonte de um arquivo hgrc externo.

Use -d/--default para desabilitar a configuração atual.

See hg ajudar modelos para obter informações sobre modelos e filtros.

opções:

-d, --predefinição
mostrar mapas de modelo de palavra-chave padrão

-f,--rcfile
ler mapas do rcfile

kwexpandir
expanda palavras-chave no diretório de trabalho:

hg kwexpand [OPÇÃO]... [ARQUIVO]...

Execute após (re)ativar a expansão de palavras-chave.

O kwexpand se recusa a ser executado se os arquivos fornecidos contiverem alterações locais.

opções:

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

arquivos kw
mostre os arquivos configurados para expansão de palavras-chave:

hg kwfiles [OPÇÃO]... [ARQUIVO]...

Liste quais arquivos no diretório de trabalho correspondem à configuração da [palavra-chave]
padrões.

Útil para evitar a expansão inadvertida de palavras-chave e para acelerar a execução incluindo
apenas arquivos que são candidatos reais para expansão.

See hg ajudar palavra chave sobre como construir padrões tanto para inclusão quanto para exclusão de
arquivos.

Com -A/--all e -v/--verbose os códigos usados ​​para mostrar o status dos arquivos são:

K = candidato a expansão de palavra-chave
k = candidato a expansão de palavra-chave (não rastreado)
I = ignorado
i = ignorado (não rastreado)

opções:

-UMA, --tudo
mostrar sinalizadores de status de palavra-chave de todos os arquivos

-eu, --ignorar
mostrar arquivos excluídos da expansão

-você, --desconhecido
mostrar apenas arquivos desconhecidos (não rastreados)

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

encolher
reverter palavras-chave expandidas no diretório de trabalho:

hg kwshrink [OPÇÃO]... [ARQUIVO]...

Deve ser executado antes de alterar/desativar palavras-chave ativas.

O kwshrink se recusa a ser executado se os arquivos fornecidos contiverem alterações locais.

opções:

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

arquivos grandes
rastrear grandes arquivos binários

Arquivos binários grandes tendem a não ser muito compressíveis, não muito diffables e nem um pouco
mesclável. Esses arquivos não são tratados de forma eficiente pelo formato de armazenamento do Mercurial (revlog),
que é baseado em deltas binários compactados; armazenando arquivos binários grandes como regular
Os arquivos Mercurial desperdiçam largura de banda e espaço em disco e aumentam o uso de memória do Mercurial.
A extensão largefiles resolve esses problemas adicionando um cliente-servidor centralizado
camada em cima do Mercurial: arquivos grandes vivem em um central loja fora na rede
em algum lugar, e você só busca as revisões de que precisa quando precisa delas.

largefiles funciona mantendo um "arquivo standin" em .hglf/ para cada largefile. O
standins são pequenos (41 bytes: um hash SHA-1 mais nova linha) e são rastreados pelo Mercurial.
As revisões de arquivos grandes são identificadas pelo hash SHA-1 de seu conteúdo, que é escrito
para o stand. largefiles usa esse ID de revisão para obter/colocar revisões de largefile de/para
a loja central. Isso economiza espaço em disco e largura de banda, já que você não precisa
recupere todas as revisões históricas de arquivos grandes ao clonar ou extrair.

Para iniciar um novo repositório ou adicionar novos arquivos binários grandes, basta adicionar --large ao seu hg adicionar
comando. Por exemplo:

$ dd if=/dev/urandom of=contagem de dados aleatórios=2000
$ hg add --large dados aleatórios
$ hg commit -m 'adicionar dados aleatórios como um arquivo grande'

Quando você envia um changeset que adiciona/modifica arquivos grandes para um repositório remoto, seu
as revisões de arquivo grande serão carregadas junto com ele. Observe que o Mercurial remoto deve
também tem a extensão largefiles habilitada para que isso funcione.

Quando você puxa um changeset que afeta arquivos grandes de um repositório remoto, os arquivos grandes
para o changeset por padrão não será puxado para baixo. No entanto, quando você atualiza para um
revisão, quaisquer arquivos grandes necessários para essa revisão são baixados e armazenados em cache (se tiverem
nunca foi baixado antes). Uma maneira de puxar arquivos grandes ao puxar é usar
--update, que atualizará sua cópia de trabalho para a última revisão extraída (e, portanto,
baixar quaisquer novos arquivos grandes).

Se você deseja extrair arquivos grandes que ainda não precisa atualizar, pode usar pull com
que o --lfrev opção ou o hg lfpuxar comando.

Se você sabe que está extraindo de um local não padrão e deseja baixar todos os
largefiles que correspondem aos novos changesets ao mesmo tempo, então você pode puxar com
--lfrev "retirado()".

Se você quiser apenas garantir que terá os arquivos grandes necessários para mesclar ou rebase
com as novas cabeças que você está puxando, então você pode puxar com --lfrev "cabeça(puxada())" bandeira
para baixar preventivamente quaisquer arquivos grandes que sejam novos nas cabeças que você está puxando.

Lembre-se de que o acesso à rede agora pode ser necessário para atualizar os conjuntos de alterações que você possui
não atualizado anteriormente para. A natureza da extensão largefiles significa que a atualização é
não é mais garantido como uma operação somente local.

Se você já tem arquivos grandes rastreados pelo Mercurial sem a extensão largefiles, você
precisará converter seu repositório para se beneficiar dos largefiles. Isso está feito
com o hg lfconverter comando:

$ hg lfconvert --size 10 oldrepo newrepo

Em repositórios que já possuem arquivos grandes, qualquer novo arquivo com mais de 10 MB será
ser adicionado automaticamente como um arquivo grande. Para alterar este limite, defina arquivos grandes.minsize in
seu arquivo de configuração do Mercurial para o tamanho mínimo em megabytes para rastrear como um arquivo grande, ou
use a opção --lfsize para o comando add (também em megabytes):

[arquivos grandes]
tamanho mínimo = 2

$ hg adicionar --lfsize 2

A arquivos grandes.padrões config permite-lhe especificar uma lista de padrões de nomes de ficheiros
(Vejo hg ajudar padrões) que devem sempre ser rastreados como arquivos grandes:

[arquivos grandes]
padrões =
* .jpg
re:.*\.(png|bmp)$
biblioteca.zip
conteúdo/áudio/*

Os arquivos que correspondem a um desses padrões serão adicionados como arquivos grandes, independentemente de sua
tamanho.

A arquivos grandes.minsize e arquivos grandes.padrões opções de configuração serão ignoradas para qualquer
repositórios que ainda não contêm um arquivo grande. Para adicionar o primeiro arquivo grande a um
repositório, você deve fazê-lo explicitamente com o sinalizador --large passado para o hg adicionar comando.

comandos
lfconverter
converter um repositório normal em um repositório largefiles:

hg lfconvert FONTE DEST [ARQUIVO ...]

Converter o repositório SOURCE para um novo repositório DEST, idêntico a SOURCE, exceto que
certos arquivos serão convertidos como arquivos grandes: especificamente, qualquer arquivo que corresponda a qualquer
PADRONIZAR or cujo tamanho está acima do limite de tamanho mínimo é convertido como um arquivo grande. O
tamanho usado para determinar se um arquivo deve ou não ser rastreado como um arquivo grande é o tamanho do
primeira versão do arquivo. O tamanho mínimo pode ser especificado com --size ou em
configuração como arquivos grandes.tamanho.

Depois de executar este comando, você precisará ter certeza de que largefiles está ativado em qualquer lugar
você pretende enviar o novo repositório.

Use --to-normal para converter arquivos grandes de volta para arquivos normais; depois disso, o DEST
repositório pode ser usado sem arquivos grandes.

opções:

-sim,--Tamanho
tamanho mínimo (MB) para arquivos a serem convertidos como largefiles

--ao normal
converter de um repositório largefiles para um repositório normal

lfpuxar
extraia arquivos grandes para as revisões especificadas da fonte especificada:

hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [FONTE]

Extraia arquivos grandes que são referenciados de conjuntos de alterações locais, mas ausentes localmente, puxando
de um repositório remoto para o cache local.

Se SOURCE for omitido, o caminho 'padrão' será usado. Ver hg ajudar URLs para mais
informações.

Alguns exemplos:

· puxe arquivos grandes para todos os chefes de ramificação:

hg lfpull -r "head() e não closed()"

· puxe arquivos grandes na ramificação padrão:

hg lfpull -r "branch(padrão)"

opções:

-r,--rev
puxe arquivos grandes para essas revisões

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

mq
gerenciar uma pilha de patches

Esta extensão permite trabalhar com uma pilha de patches em um repositório Mercurial. Ele gerencia
duas pilhas de patches - todos os patches conhecidos e patches aplicados (subconjunto de patches conhecidos).

Os patches conhecidos são representados como arquivos de patch no diretório .hg/patches. Patches aplicados
são arquivos de patch e changesets.

Tarefas comuns (usar hg ajudar comando para mais detalhes):

criar novo patch qnew
importar patch existente qimport

imprimir patch série qseries
imprimir patches aplicados qapplied

adicionar patch conhecido à pilha aplicada qpush
remover patch da pilha aplicada qpop
atualizar o conteúdo do melhor patch aplicado qrefresh

Por padrão, o mq usará automaticamente os patches do git quando necessário para evitar a perda do modo de arquivo
alterações, cópias de registros, arquivos binários ou criações ou exclusões de arquivos vazios. Esse comportamento
pode ser configurado com:

[mq]
git = auto/manter/sim/não

Se definido como 'keep', mq obedecerá à configuração da seção [diff] preservando
git patches no qrefresh. Se definido como 'sim' ou 'não', mq substituirá a seção [diff]
e sempre gere git ou patches regulares, possivelmente perdendo dados no segundo caso.

Pode ser desejável que os changesets mq sejam mantidos na fase secreta (veja hg ajudar fases),
que pode ser ativado com a seguinte configuração:

[mq]
segredo = Verdadeiro

Por padrão, você estará gerenciando uma fila de patches chamada "patches". Você pode criar outros,
filas de patches independentes com o hg qfila comando.

Se o diretório de trabalho contiver arquivos não confirmados, qpush, qpop e qgoto abortar
imediatamente. Se -f/--force for usado, as alterações serão descartadas. Contexto:

[mq]
manter mudanças = Verdadeiro

fazê-los se comportar como se --keep-changes fossem passados, e mudanças locais não conflitantes
ser tolerado e preservado. Se opções incompatíveis como -f/--force ou --exact forem
passado, esta configuração é ignorada.

Esta extensão costumava fornecer um comando strip. Este comando agora vive na faixa
extensão.

comandos
qaplicado
imprima os patches já aplicados:

hg qaplicado [-1] [-s] [PATCH]

Retorna 0 em caso de sucesso.

opções:

-1, --último
mostrar apenas o patch aplicado anterior

-sim, --resumo
imprimir a primeira linha do cabeçalho do patch

qclone
clone o repositório principal e do patch ao mesmo tempo:

hg qclone [OPÇÃO]... FONTE [DEST]

Se a origem for local, o destino não terá patches aplicados. Se a fonte for remota, esta
O comando não pode verificar se os patches são aplicados no código-fonte, portanto, não pode garantir que os patches
não são aplicados no destino. Se você clonar repositório remoto, certifique-se antes de que ele tenha
nenhum patch aplicado.

O repositório de patches de origem é procurado em /.hg/patches por padrão. Usar -p para
alterar.

O diretório de patches deve ser um repositório Mercurial aninhado, como seria criado por hg o init
--mq.

Retorne 0 em caso de sucesso.

opções:

--puxar use o protocolo pull para copiar metadados

-VOCÊ, --sem atualização
não atualize os novos diretórios de trabalho

- não comprimido
usar transferência descompactada (rápido pela LAN)

-p,--patches
localização do repositório do patch de origem

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

qcommit
confirmar alterações no repositório de filas (OBSOLETO):

hg qcommit [OPÇÃO]... [ARQUIVO]...

Este comando está obsoleto; usar hg commit --mq ao invés.

opções:

-UMA, --addremove
marque os arquivos novos / ausentes como adicionados / removidos antes de confirmar

--filial próximo
marcar uma cabeça de ramo como fechada

- alterar
alterar o pai do diretório de trabalho

-sim, --segredo
use a fase secreta para comprometer

-e --editar
invocar editor em mensagens de confirmação

-eu, --interativo
use o modo interativo

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

-S, --subrepos
Recurso para subrepositórios

A opção marcada [+] pode ser especificada várias vezes

apelidos: qci

qdelete
remover patches da fila:

hg qdelete [-k] [PATCH]...

Os patches não devem ser aplicados, e pelo menos um patch é necessário. Patch exato
identificadores devem ser fornecidos. Com -k/--keep, os arquivos de patch são preservados no patch
diretório.

Para parar de gerenciar um patch e movê-lo para o histórico permanente, use o hg q terminar comando.

opções:

-k, --guarda
manter arquivo de patch

-r,--rev
parar de gerenciar uma revisão (OBSOLETO)

A opção marcada [+] pode ser especificada várias vezes

apelidos: qremove qrm

diferença
diff do patch atual e modificações subsequentes:

hg qdiff [OPÇÃO]... [ARQUIVO]...

Mostra um diff que inclui o patch atual, bem como todas as alterações que foram feitas
no diretório de trabalho desde a última atualização (mostrando assim o que o patch atual
tornar-se após um qrefresh).

Use hg diff se você quiser apenas ver as alterações feitas desde a última qrefresh, ou hg exportar
q dica se você quiser ver as alterações feitas pelo patch atual sem incluir as alterações feitas
desde o qrefresh.

Retorna 0 em caso de sucesso.

opções:

-uma, --texto
tratar todos os arquivos como texto

-g, --git
usar formato de diff estendido git

--nodates
omitir datas de cabeçalhos de diferenças

--sem prefixo
omitir os prefixos a / eb / dos nomes dos arquivos

-p, --show-função
mostrar em qual função cada mudança está

--marcha ré
produz um diff que desfaz as mudanças

-C, --ignore-todo-espaço
ignore o espaço em branco ao comparar as linhas

-b, --ignore-espaço-mudança
ignorar as mudanças na quantidade de espaço em branco

-B, --ignore-linhas em branco
ignore as mudanças cujas linhas estão todas em branco

-VOCÊ,--unificado
número de linhas de contexto para mostrar

--Estado saída de resumo de mudanças no estilo diffstat

--raiz
produz diffs em relação ao subdiretório

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

q terminar
mova os patches aplicados para o histórico do repositório:

hg qfinish [-a] [REV]...

Finaliza as revisões especificadas (correspondentes aos patches aplicados) movendo-os para fora
mq no histórico regular do repositório.

Aceita um intervalo de revisão ou a opção -a/--applied. Se --applied for especificado, todos
as revisões mq aplicadas são removidas do controle mq. Caso contrário, as revisões fornecidas devem ser
na base da pilha de patches aplicados.

Isso pode ser especialmente útil se suas alterações foram aplicadas a um repositório upstream,
ou se você estiver prestes a enviar suas alterações para upstream.

Retorna 0 em caso de sucesso.

opções:

-uma, --aplicado
terminar todos os changesets aplicados

qdobra
dobre os patches nomeados no patch atual:

hg qfold [-e] [-k] [-m TEXTO] [-l ARQUIVO] PATCH...

Patches ainda não devem ser aplicados. Cada patch será aplicado sucessivamente ao
remendo na ordem dada. Se todos os patches forem aplicados com sucesso, o patch atual será
atualizado com o novo patch cumulativo, e os patches dobrados serão excluídos. Com
-k/--keep, os arquivos de patch dobrados não serão removidos posteriormente.

O cabeçalho de cada patch dobrado será concatenado com o cabeçalho do patch atual,
separados por uma linha de * * *.

Retorna 0 em caso de sucesso.

opções:

-e --editar
invocar editor em mensagens de confirmação

-k, --guarda
manter arquivos de patch dobrados

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

qgoto
push ou pop patches até que o patch nomeado esteja no topo da pilha:

hg qgoto [OPÇÃO]... PATCH

Retorna 0 em caso de sucesso.

opções:

--manter-alterações
tolerar mudanças locais não conflitantes

-f, --força
substituir quaisquer alterações locais

--sem backup
não salve cópias de backup de arquivos

guarda
defina ou imprima guardas para um patch:

hg qguard [-l] [-n] [PATCH] [-- [+GUARD]... [-GUARD]...]

Os guardas controlam se um patch pode ser enviado. Um patch sem guardas é sempre empurrado. UMA
patch com uma guarda positiva ("+foo") é empurrado apenas se o hg qseleccione comando tem
o ativou. Um patch com uma guarda negativa ("-foo") nunca é empurrado se o hg qseleccione
comando o ativou.

Sem argumentos, imprima os guardas ativos no momento. Com argumentos, coloque guardas para o
patch nomeado.

Nota A especificação de guardas negativos agora requer '--'.

Para definir guardas em outro patch:

hg qguard outro.patch -- +2.6.17 -estável

Retorna 0 em caso de sucesso.

opções:

-eu, --Lista
liste todos os patches e guards

-n, --Nenhum
largar todos os guardas

cabeçalho
imprima o cabeçalho do patch mais alto ou especificado:

hg qheader [PATCH]

Retorna 0 em caso de sucesso.

qimportar
importe um patch ou changeset existente:

hg qimport [-e] [-n NOME] [-f] [-g] [-P] [-r REV]... [FILE]...

O patch é inserido na série após o último patch aplicado. Se nenhum remendo tiver
foi aplicado, qimport precede o patch para a série.

O patch terá o mesmo nome que seu arquivo de origem, a menos que você dê um novo com
-n/--nome.

Você pode registrar um patch existente dentro do diretório de patches com o sinalizador -e/--existing.

Com -f/--force, um patch existente com o mesmo nome será substituído.

Um conjunto de alterações existente pode ser colocado sob controle mq com -r/--rev (por exemplo, qimport --rev .
-n patch colocará a revisão atual sob controle mq). Com -g/--git, patches
importado com --rev usará o formato git diff. Consulte o tópico de ajuda de diferenças para obter informações
sobre por que isso é importante para preservar as informações de renomeação/cópia e alterações de permissão.
Use hg q terminar para remover conjuntos de alterações do controle mq.

Para importar um patch da entrada padrão, passe - como o arquivo de patch. Ao importar de
entrada padrão, um nome de patch deve ser especificado usando o sinalizador --name.

Para importar um patch existente ao renomeá-lo:

hg qimport -e patch existente -n novo nome

Retorna 0 se a importação for bem-sucedida.

opções:

-e --existir
importar arquivo no diretório de patch

-n,--nome
nome do arquivo de patch

-f, --força
Sobrescrever arquivos existentes

-r,--rev
colocar as revisões existentes sob controle mq

-g, --git
usar formato de diff estendido git

-P, --Empurre
qpush após importar

A opção marcada [+] pode ser especificada várias vezes

qinit
inicie um novo repositório de filas (OBSOLETO):

hg qinit [-c]

O repositório de filas não é versionado por padrão. Se -c/--create-repo for especificado, qinit
irácriar um repositório aninhado separado para patches (qinit -c também pode ser executado posteriormente para
converter um repositório de patches não versionado em um versionado). Você pode usar qcommit para
confirme as alterações neste repositório de filas.

Este comando está obsoleto. Sem -c, está implícito em outros comandos relevantes. Com -c,
usar hg o init --mq ao invés.

opções:

-c, --criar-repo
criar repositório de filas

qnovo
crie um novo patch:

hg qnew [-e] [-m TEXT] [-l ARQUIVO] PATCH [ARQUIVO]...

qnew cria um novo patch em cima do patch atualmente aplicado (se houver). O remendo será
inicializado com quaisquer alterações pendentes no diretório de trabalho. Você também pode usar
-I/--include, -X/--exclude e/ou uma lista de arquivos após o nome do patch para adicionar apenas
alterações nos arquivos correspondentes ao novo patch, deixando o restante como modificações não confirmadas.

-u/--user e -d/--date podem ser usados ​​para definir o usuário (dado) e a data, respectivamente.
-U/--currentuser e -D/--currentdate configuram o usuário para o usuário atual e a data para a data atual.

-e/--edit, -m/--message ou -l/--logfile define o cabeçalho do patch, bem como o commit
mensagem. Se nenhum for especificado, o cabeçalho estará vazio e a mensagem de confirmação será '[mq]:
CORREÇÃO'.

Use a opção -g/--git para manter o patch no formato git extended diff. Leia as diferenças
tópico de ajuda para obter mais informações sobre por que isso é importante para preservar as alterações de permissão
e copiar/renomear informações.

Retorna 0 na criação bem-sucedida de um novo patch.

opções:

-e --editar
invocar editor em mensagens de confirmação

-f, --força
importar alterações não confirmadas (OBSOLETO)

-g, --git
usar formato de diff estendido git

-VOCÊ, --usuário atual
adicione "De: " remendar

-você,--do utilizador
adicione "De: " remendar

-D, --data atual
adicione "Data: " remendar

-d,--data
adicione "Data: " remendar

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

A opção marcada [+] pode ser especificada várias vezes

Qnext
imprima o nome do próximo patch pushable:

hg qpróximo [-s]

Retorna 0 em caso de sucesso.

opções:

-sim, --resumo
imprimir a primeira linha do cabeçalho do patch

qpop
retire o patch atual da pilha:

hg qpop [-a] [-f] [PATCH | ÍNDICE]

Sem argumento, aparece no topo da pilha de patches. Se for dado um nome de patch, mantém
removendo patches até que o patch nomeado esteja no topo da pilha.

Por padrão, aborte se o diretório de trabalho contiver alterações não confirmadas. Com
--keep-changes, aborta apenas se os arquivos não confirmados se sobrepuserem aos arquivos corrigidos. Com
-f/--force, faça backup e descarte as alterações feitas nesses arquivos.

Retorne 0 em caso de sucesso.

opções:

-uma, --tudo
pop todos os patches

-n,--nome
nome da fila para pop (OBSOLETO)

--manter-alterações
tolerar mudanças locais não conflitantes

-f, --força
esqueça quaisquer alterações locais nos arquivos corrigidos

--sem backup
não salve cópias de backup de arquivos

qprev
imprima o nome do patch aplicado anterior:

hg qprev [-s]

Retorna 0 em caso de sucesso.

opções:

-sim, --resumo
imprimir a primeira linha do cabeçalho do patch

qpush
coloque o próximo patch na pilha:

hg qpush [-f] [-l] [-a] [--move] [PATCH | ÍNDICE]

Por padrão, aborte se o diretório de trabalho contiver alterações não confirmadas. Com
--keep-changes, aborta apenas se os arquivos não confirmados se sobrepuserem aos arquivos corrigidos. Com
-f/--force, backup e patch sobre alterações não confirmadas.

Retorne 0 em caso de sucesso.

opções:

--manter-alterações
tolerar mudanças locais não conflitantes

-f, --força
aplicar em cima das mudanças locais

-e --exato
aplique o patch de destino ao seu pai gravado

-eu, --Lista
listar o nome do patch no texto do commit

-uma, --tudo
aplicar todos os patches

-m, --mesclar
mesclar de outra fila (OBSOLETO)

-n,--nome
nome da fila de mesclagem (OBSOLETO)

--mover reordenar a série de patches e aplicar apenas o patch

--sem backup
não salve cópias de backup de arquivos

qfila
gerenciar várias filas de patches:

hg qqueue [OPÇÃO] [FILA]

Suporta alternar entre diferentes filas de patch, bem como criar novas filas de patch
e excluindo os existentes.

Omitir um nome de fila ou especificar -l/--list mostrará as filas registradas - por
padrão, a fila de patches "normal" é registrada. A fila atualmente ativa será
marcado com "(ativo)". Especificar --active imprimirá apenas o nome da fila ativa.

Para criar uma nova fila, use -c/--create. A fila é ativada automaticamente, exceto em
o caso em que há patches aplicados da fila atualmente ativa no
repositório. Então a fila só será criada e a comutação falhará.

Para excluir uma fila existente, use --delete. Você não pode excluir a fila atualmente ativa.

Retorna 0 em caso de sucesso.

opções:

-eu, --Lista
listar todas as filas disponíveis

--ativo
imprimir nome da fila ativa

-c, --Criar
criar nova fila

--renomear
renomear fila ativa

--excluir
excluir referência à fila

--purga
exclua a fila e remova o diretório do patch

atualizar
atualize o patch atual:

hg qrefresh [-I] [-X] [-e] [-m TEXTO] [-l ARQUIVO] [-s] [ARQUIVO]...

Se algum padrão de arquivo for fornecido, o patch atualizado conterá apenas as modificações
que correspondem a esses padrões; as modificações restantes permanecerão no trabalho
diretório.

Se -s/--short for especificado, os arquivos atualmente incluídos no patch serão atualizados apenas
como arquivos correspondentes e permanecem no patch.

Se -e/--edit for especificado, o Mercurial iniciará seu editor configurado para você inserir um
mensagem. Caso o qrefresh falhe, você encontrará um backup de sua mensagem em
.hg / last-message.txt.

hg add/remove/copy/rename funciona como de costume, embora você possa querer usar patches no estilo git
(-g/--git ou [diff] git=1) para rastrear cópias e renomeações. Veja o tópico de ajuda de diferenças para mais
informações sobre o formato git diff.

Retorna 0 em caso de sucesso.

opções:

-e --editar
invocar editor em mensagens de confirmação

-g, --git
usar formato de diff estendido git

-sim, --baixo
atualizar apenas os arquivos que já estão no patch e os arquivos especificados

-VOCÊ, --usuário atual
adicionar/atualizar o campo de autor no patch com o usuário atual

-você,--do utilizador
adicionar/atualizar o campo de autor no patch com determinado usuário

-D, --data atual
adicionar/atualizar campo de data no patch com a data atual

-d,--data
adicionar/atualizar campo de data no patch com data determinada

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

A opção marcada [+] pode ser especificada várias vezes

qrenomear
renomear um patch:

hg qrenome PATCH1 [PATCH2]

Com um argumento, renomeia o patch atual para PATCH1. Com dois argumentos, renomeia
PATCH1 para PATCH2.

Retorna 0 em caso de sucesso.

apelido: qmv

qrestore
restaurar o estado da fila salvo por uma revisão (OBSOLETO):

hg qrestore [-d] [-u] REV

Este comando está obsoleto, use hg rebase ao invés.

opções:

-d, --excluir
excluir salvar entrada

-você, --atualizar
atualizar o diretório de trabalho da fila

qsalvar
salvar o estado atual da fila (OBSOLETO):

hg qsave [-m TEXT] [-l ARQUIVO] [-c] [-n NOME] [-e] [-f]

Este comando está obsoleto, use hg rebase ao invés.

opções:

-c, --cópia de
copiar diretório de patches

-n,--nome
copiar nome do diretório

-e --vazio
limpar arquivo de status da fila

-f, --força
forçar cópia

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

qseleccione
definir ou imprimir patches protegidos para enviar:

hg qselecione [OPÇÃO]... [GUARDA]...

Use o hg guarda comando para definir ou imprimir guardas no patch, então use qselect para dizer ao mq
quais protetores usar. Um patch será enviado se não tiver guardas ou quaisquer guardas positivos
corresponde ao guarda selecionado atualmente, mas não será empurrado se algum guarda negativo corresponder
a guarda atual. Por exemplo:

qguard foo.patch -- -stable (guarda negativa)
qguard bar.patch +stable (guarda positiva)
qselecione estável

Isso ativa a guarda "estável". mq irá pular foo.patch (porque tem um negativo
match), mas pressione bar.patch (porque tem uma correspondência positiva).

Sem argumentos, imprime os guardas ativos no momento. Com um argumento, define o ativo
guarda.

Use -n/--none para desativar os guardas (não são necessários outros argumentos). Quando não há guardas
ativos, patches com proteções positivas são ignorados e patches com proteções negativas são
empurrado.

O qselect pode alterar as proteções em patches aplicados. Não estoura patches protegidos por
padrão. Use --pop para retornar ao último patch aplicado que não está protegido. Usar
--reapply (o que implica --pop) para retornar ao patch atual depois, mas pular
remendos guardados.

Use -s/--series para imprimir uma lista de todos os guardas no arquivo de série (nenhum outro argumento
precisava). Use -v para obter mais informações.

Retorna 0 em caso de sucesso.

opções:

-n, --Nenhum
desabilitar todos os guardas

-sim, --Series
listar todos os guardas no arquivo de série

- pop pop para antes do primeiro patch aplicado protegido

--reaplicar
pop, em seguida, reaplicar os patches

série q
imprima todo o arquivo da série:

hg série q [-ms]

Retorna 0 em caso de sucesso.

opções:

-m, --ausente
imprimir patches não em série

-sim, --resumo
imprimir a primeira linha do cabeçalho do patch

qtopo
imprima o nome do patch atual:

hg qtop [-s]

Retorna 0 em caso de sucesso.

opções:

-sim, --resumo
imprimir a primeira linha do cabeçalho do patch

aplicado
imprima os patches ainda não aplicados:

hg aplicado [-1] [-s] [PATCH]

Retorna 0 em caso de sucesso.

opções:

-1, --primeiro
mostrar apenas o primeiro patch

-sim, --resumo
imprimir a primeira linha do cabeçalho do patch

notificar
ganchos para enviar notificações push por e-mail

Esta extensão implementa ganchos para enviar notificações por email quando conjuntos de alterações são enviados de
ou recebido pelo repositório local.

Primeiro, ative a extensão conforme explicado em hg ajudar extensões, e registre o gancho que você
quer correr. entrada e grupo de mudança hooks são executados quando os changesets são recebidos, enquanto
cessante hooks são para changesets enviados para outro repositório:

[ganchos]
# um email para cada conjunto de alterações recebido
entrada.notify = python:hgext.notify.hook
# um email para todos os changesets recebidos
changegroup.notify=python:hgext.notify.hook

# um email para todos os changesets de saída
output.notify = python:hgext.notify.hook

Isso registra os ganchos. Para habilitar a notificação, os assinantes devem ser atribuídos a
repositórios. O [subscritores de usuários] seção mapeia vários repositórios para um determinado destinatário. O
[repostas] seção mapeia vários destinatários para um único repositório:

[subscritores de usuários]
# key é o email do assinante, value é uma lista separada por vírgulas de padrões de repositório
usuário@host = padrão

[repostas]
# key é padrão de repositório, valor é uma lista separada por vírgulas de e-mails de assinantes
padrão = usuário@host

A de cinto de segurança é um glob combinando o caminho absoluto para um repositório, opcionalmente combinado com um
expressão de reversão. Uma expressão de reversão, se presente, é separada do glob por um hash.
Exemplo:

[repostas]
*/widgets#branch(lançamento) = [email protegido]

Isso envia para [email protegido] sempre que um changeset no liberar ramo aciona um
notificação em qualquer repositório que termine em Widgets.

Para colocá-los sob gerenciamento direto de usuários, [subscritores de usuários] e [repostas] seções
pode ser colocado em separado hgrc arquivo e incorporado por referência:

[notificar]
config = /caminho/para/arquivo de assinaturas

As notificações não serão enviadas até que o notificar.teste o valor está definido para Falso; Veja abaixo.

O conteúdo das notificações pode ser ajustado com as seguintes entradas de configuração:

notificar.teste
If Verdadeiro, imprima mensagens para stdout em vez de enviá-las. Padrão: Verdadeiro.

fontes de notificação
Lista separada por espaço de fontes de mudança. As notificações são ativadas somente quando um
a fonte do changeset está nesta lista. As fontes podem ser:

servir

changesets recebidos via http ou ssh

puxar

conjuntos de alterações recebidos via hg puxar

descompactar

conjuntos de alterações recebidos via hg descompactar

empurrar

conjuntos de alterações enviados ou recebidos via hg empurrar

empacotar

conjuntos de alterações enviados por hg descompactar

Padrão: servir.

notificar.strip
Número de barras iniciais a serem removidas dos caminhos de URL. Por padrão, as notificações
repositórios de referência com seu caminho absoluto. notificar.strip permite que você os transforme
em caminhos relativos. Por exemplo, notificar.strip=3 mudará /longo/caminho/repositório
para dentro repositório. Padrão: 0.

notificar.domínio
Domínio de e-mail padrão para remetente ou destinatários sem domínio explícito.

estilo de notificação
Arquivo de estilo a ser usado ao formatar e-mails.

notificar.modelo
Modelo para usar ao formatar e-mails.

notificar.recebida
Modelo a ser usado quando executado como um gancho de entrada, substituindo notificar.modelo.

notificar.de saída
Modelo a ser usado quando executado como um gancho de saída, substituindo notificar.modelo.

notificar.alterargrupo
Modelo a ser usado ao executar como um gancho de grupo de mudanças, substituindo notificar.modelo.

notificar.maxdiff
Número máximo de linhas de comparação a serem incluídas no e-mail de notificação. Defina como 0 para desabilitar
o diff, ou -1 para incluir tudo isso. Padrão: 300.

notificar.maxsubject
Número máximo de caracteres na linha de assunto do email. Padrão: 67.

notificar.diffstat
Defina como True para incluir um diffstat antes do conteúdo do diff. Padrão: Verdadeiro.

notificar.merge
Se True, envie notificações para conjuntos de alterações de mesclagem. Padrão: Verdadeiro.

notificação.mbox
Se definido, anexa e-mails a este arquivo mbox em vez de enviar. Padrão: Nenhum.

notificar.do autor
Se definido, use o committer do primeiro changeset em um grupo de alterações para o "De"
campo do correio de notificação. Se não estiver definido, leve o usuário do repositório de envio.
Padrão: falso.

Se definido, as seguintes entradas também serão usadas para personalizar as notificações:

e-mail de
E-mail De endereço a ser usado se nenhum puder ser encontrado no conteúdo de e-mail gerado.

web.baseurl
URL do repositório raiz para combinar com os caminhos do repositório ao fazer referências. Ver
tb notificar.strip.

pager
navegar pela saída do comando com um pager externo

Para definir o pager que deve ser usado, defina a variável do aplicativo:

[pager]
pager = menos -FRX

Se nenhum pager for definido, as extensões do pager usarão a variável de ambiente $PAGER. Se nenhum dos dois
pager.pager, nem $PAGER é definido, nenhum pager é usado.

Você pode desabilitar o pager para certos comandos adicionando-os à lista pager.ignore:

[pager]
ignore = versão, ajuda, atualização

Você também pode habilitar o pager apenas para determinados comandos usando pager.attend. Abaixo está o
lista padrão de comandos a serem paginados:

[pager]
atender = anotar, cat, diff, export, glog, log, qdiff

Definir pager.attend como um valor vazio fará com que todos os comandos sejam paginados.

Se pager.attend estiver presente, pager.ignore será ignorado.

Por fim, você pode habilitar e desabilitar a paginação para comandos individuais com o
participar- opção. Esta configuração tem precedência sobre atender e ignorar existente
opções e padrões:

[pager]
atender-gato = false

Para ignorar comandos globais como hg versão or hg ajudar, você deve especificá-los em seu
arquivo de configuração do usuário.

Para controlar se o pager é usado para um comando individual, você pode usar
--pager= :

- use conforme necessário: `auto`.
- requer o pager: `yes` ou `on`.
- suprimir o pager: `no` ou `off` (qualquer valor não reconhecido
também funcionará).

bomba de remendo
comando para enviar changesets como (uma série de) e-mails de patch

A série começa com uma introdução "[PATCH 0 of N]", que descreve a série
como um todo.

Cada e-mail de patch tem uma linha de assunto de "[PATCH M of N] ...", usando a primeira linha do
descrição do changeset como o texto do assunto. A mensagem contém duas ou três partes do corpo:

· A descrição do conjunto de alterações.

· [Opcional] O resultado da execução do diffstat no patch.

· O próprio patch, conforme gerado por hg exportar.

Cada mensagem refere-se ao primeiro da série usando o In-Reply-To e Referências
cabeçalhos, para que apareçam como uma sequência em e-mails encadeados e leitores de notícias, e em e-mails
arquivos.

Para configurar outros padrões, adicione uma seção como esta ao seu arquivo de configuração:

[E-mail]
de = meu nome
para = destinatário1, destinatário2, ...
cc = cc1, cc2, ...
cc = cc1, cc2, ...
resposta-para = endereço1, endereço2, ...

Use [bomba de remendo] como nome da seção de configuração se você precisar substituir global [E-mail]
configurações de endereço.

Então você pode usar o hg email comando para enviar uma série de changesets como um patchbomb.

Você também pode configurar a opção de método na seção de email para ser um sendmail
mailer compatível ou preencha a seção [smtp] para que a extensão patchbomb possa
enviar patchbombs automaticamente diretamente da linha de comando. Veja o [e-mail] e [smtp]
seções em hgrc(5) para obter detalhes.

Por padrão, o hg email solicitará um Para or CC cabeçalho se você não fornecer um via
configuração ou a linha de comando. Você pode substituir isso para nunca avisar configurando
um valor vazio:

[E-mail]
cc =

Você pode controlar a inclusão padrão de uma mensagem de introdução com o patchbomb.intro
opção de configuração. A configuração é sempre substituída por sinalizadores de linha de comando como
--intro e --desc:

[bomba de remendo]
intro=auto # inclui mensagem de introdução se houver mais de 1 patch (padrão)
intro=never # nunca inclua uma mensagem de introdução
intro=always # sempre inclui uma mensagem de introdução

Você pode configurar o patchbomb para sempre pedir confirmação definindo patchbomb.confirmar a verdade.

comandos
email
enviar conjuntos de alterações por e-mail:

hg email [OPÇÃO]... [DEST]...

Por padrão, os diffs são enviados no formato gerado por hg exportar, um por mensagem. O
série começa com uma introdução "[PATCH 0 of N]", que descreve a série como um todo.

Cada e-mail de patch tem uma linha de assunto de "[PATCH M of N] ...", usando a primeira linha do
descrição do changeset como o texto do assunto. A mensagem contém duas ou três partes.
Primeiro, a descrição do changeset.

Com a opção -d/--diffstat, se o programa diffstat estiver instalado, o resultado da execução
diffstat no patch é inserido.

Por fim, o próprio patch, conforme gerado pelo hg exportar.

Com as opções -d/--diffstat ou --confirm, você receberá um resumo final de
todas as mensagens e pediu confirmação antes de as mensagens serem enviadas.

Por padrão, o patch é incluído como texto no corpo do e-mail para facilitar a revisão. Usando o
A opção -a/--attach criará um anexo para o patch. Com -i/--inline an
anexo embutido será criado. Você pode incluir um patch como texto no corpo do e-mail
e como um anexo regular ou embutido, combinando o -a/--attach ou -i/--inline com
a opção --body.

Com -o/--outgoing, serão gerados emails para patches não encontrados no destino
repositório (ou apenas aqueles que são ancestrais das revisões especificadas, se houver
forneceu)

Com -b/--bundle, changesets são selecionados como para --outgoing, mas um único email contendo
um pacote binário Mercurial como um anexo será enviado. Use o patchbomb.bundletype
opção de configuração para controlar o tipo de pacote como com hg empacotar --modelo.

Com -m/--mbox, em vez de visualizar cada mensagem de patchbomb em um pager ou enviar o
mensagens diretamente, ele criará um arquivo de caixa de correio UNIX com os e-mails de patch. Esta caixa de correio
arquivo pode ser visualizado com qualquer agente de usuário de correio que suporte arquivos mbox UNIX.

Com -n/--test, todas as etapas serão executadas, mas o email não será enviado. Você será solicitado
um endereço de destinatário de e-mail, um assunto e uma mensagem introdutória descrevendo os patches
de sua bomba de remendo. Então, quando tudo estiver pronto, as mensagens de patchbomb são exibidas. Se o PAGER
variável de ambiente estiver definida, seu pager será acionado uma vez para cada mensagem de patchbomb,
para que você possa verificar se está tudo bem.

Caso o envio de e-mail falhe, você encontrará um backup de sua mensagem introdutória da série em
.hg/último-email.txt.

O comportamento padrão deste comando pode ser customizado através da configuração. (Ver hg ajudar
bomba de remendo para detalhes)

Exemplos:

hg email -r 3000 # envia apenas patch 3000
hg email -r 3000 -r 3001 # envia patches 3000 e 3001
hg email -r 3000:3005 # envia patches de 3000 a 3005
hg email 3000 # enviar patch 3000 (obsoleto)

hg email -o # envia todos os patches que não estão no padrão
hg email -o DEST # envia todos os patches que não estão no DEST
hg email -o -r 3000 # envia todos os ancestrais de 3000 não padrão
hg email -o -r 3000 DEST # envia todos os ancestrais de 3000 que não estão em DEST

hg email -b # envia o pacote de todos os patches que não estão no padrão
hg email -b DEST # envia o pacote de todos os patches que não estão no DEST
hg email -b -r 3000 # pacote de todos os ancestrais de 3000 não padrão
hg email -b -r 3000 DEST # pacote de todos os ancestrais de 3000 que não estão em DEST

hg email -o -m mbox && # gera um arquivo mbox...
mutt -R -f mbox # ... e visualize com mutt
hg email -o -m mbox && # gera um arquivo mbox ...
formail -s sendmail \ # ... e use formail para enviar da mbox
-bm -t < mbox # ... usando sendmail

Antes de usar este comando, você precisará habilitar o email em seu hgrc. Veja o [e-mail]
seção em hgrc(5) para obter detalhes.

opções:

-g, --git
usar formato de diff estendido git

--plano
omitir cabeçalho de patch hg

-ó, --extrovertido
enviar alterações não encontradas no repositório de destino

-b, --agrupar
enviar alterações que não estão no destino como um pacote binário

--pacotename
nome do arquivo de anexo do pacote (padrão: pacote)

-r,--rev
uma revisão para enviar

--força
executado mesmo quando o repositório remoto não está relacionado (com -b/--bundle)

--base
um changeset básico para especificar em vez de um destino (com -b/--bundle)

--introdução
enviar um e-mail de introdução para um único patch

--corpo enviar patches como texto de mensagem embutido (padrão)

-uma, --anexar
enviar patches como anexos

-eu, --na linha
enviar patches como anexos embutidos

--Cco
endereços de e-mail de destinatários de cópias ocultas

-c,--cc
endereços de e-mail dos destinatários da cópia

--confirme
peça confirmação antes de enviar

-d, --diffstat
adicionar saída diffstat às mensagens

--data
use a data fornecida como a data de envio

--desc
use o arquivo fornecido como a descrição da série

-f,--a partir de
endereço de e-mail do remetente

-n, --teste
imprimir mensagens que seriam enviadas

-m,--mbox
escrever mensagens no arquivo mbox em vez de enviá-las

--responder a
endereços de e-mail as respostas devem ser enviadas para

-sim,--sujeito
assunto da primeira mensagem (intro ou patch único)

--em resposta a
identificador de mensagem para responder

--bandeira
sinalizadores para adicionar prefixos de assunto

-t,--para
endereços de e-mail dos destinatários

-e--ssh
especifique o comando ssh a usar

--remotecmd
especifique o comando hg para ser executado no lado remoto

--inseguro
não verifique o certificado do servidor (ignorando a configuração web.cacerts)

A opção marcada [+] pode ser especificada várias vezes

purga
comando para excluir arquivos não rastreados do diretório de trabalho

comandos
purga
remove arquivos não rastreados pelo Mercurial:

hg purgar [OPÇÃO]... [DIR]...

Exclua arquivos desconhecidos do Mercurial. Isso é útil para testar alterações locais e não confirmadas
em uma árvore de origem limpa.

Isso significa que a limpeza excluirá o seguinte por padrão:

· Arquivos desconhecidos: arquivos marcados com "?" por hg estado

· Diretórios vazios: de fato, o Mercurial ignora diretórios a menos que contenham arquivos sob
gerenciamento de controle de origem

Mas vai deixar intocado:

· Arquivos rastreados modificados e não modificados

· Arquivos ignorados (a menos que --all seja especificado)

· Novos arquivos adicionados ao repositório (com hg adicionar)

As opções --files e --dirs podem ser usadas para direcionar a limpeza para excluir apenas arquivos, apenas
diretórios, ou ambos. Se nenhuma opção for fornecida, ambas serão excluídas.

Se os diretórios forem fornecidos na linha de comando, apenas os arquivos nesses diretórios serão
considerado.

Tenha cuidado com a limpeza, pois você pode excluir irreversivelmente alguns arquivos que esqueceu de adicionar
o repositório. Se você deseja apenas imprimir a lista de arquivos que este programa
delete, use a opção --print.

opções:

-uma, --abortar ao errar
abortar se ocorrer um erro

--tudo limpar arquivos ignorados também

--dirs limpar diretórios vazios

--arquivos
limpar arquivos

-p, --imprimir
imprimir nomes de arquivos em vez de excluí-los

-0, --print0
finalize os nomes dos arquivos com NUL, para uso com xargs (implica -p/--print)

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

apelidos: limpo

rebase
comando para mover conjuntos de revisões para um ancestral diferente

Esta extensão permite rebasear conjuntos de alterações em um repositório Mercurial existente.

Para mais informações: https://mercurial-scm.org/wiki/RebaseExtension

comandos
rebase
mova o changeset (e descendentes) para um branch diferente:

hg rebase [-s REV | -b REV] [-d REV] [OPÇÃO]

O rebase usa mesclagem repetida para inserir conjuntos de alterações de uma parte do histórico (a fonte)
para outro (o destino). Isso pode ser útil para linearizar local muda em relação
para uma árvore de desenvolvimento mestre.

Os commits publicados não podem ser rebaseados (veja hg ajudar fases). Para copiar commits, veja hg ajudar
enxerto.

Se você não especificar um conjunto de alterações de destino (-d/--destino), o rebase usa o branch atual
ponta como destino. (O changeset de destino não é modificado pelo rebase, mas novo
changesets são adicionados como seus descendentes.)

Aqui estão as maneiras de selecionar conjuntos de alterações:

1. Selecione-os explicitamente usando --rev.

2. Usar --fonte para selecionar um changeset raiz e incluir todos os seus descendentes.

3. Usar --base para selecionar um conjunto de alterações; rebase encontrará ancestrais e seus descendentes
que também não são ancestrais do destino.

4. Se você não especificar nenhum --rev, fonteou --base, o rebase usará --base . as
acima.

O rebase destruirá os conjuntos de alterações originais, a menos que você use --guarda. Ele também moverá seu
marcadores (mesmo se você fizer isso).

Alguns conjuntos de alterações podem ser descartados se não contribuírem com alterações (por exemplo, mesclagens do
filial de destino).

Diferentemente dos fundir, o rebase não fará nada se você estiver na ponta da ramificação de uma ramificação nomeada com
duas cabeças. Você precisará especificar explicitamente a origem e/ou destino.

Se um rebase for interrompido para resolver manualmente um conflito, ele poderá ser continuado com
--continue/-c ou abortado com --abort/-a.

Exemplos:

· mover "alterações locais" (commit atual de volta ao ponto de ramificação) para a dica de ramificação atual
depois de um puxão:

hg rebase

· mover um único changeset para o branch estável:

hg rebase -r 5f493448 -d estável

· unir um commit e todos os seus descendentes em outra parte do histórico:

hg rebase --source c0c3 --dest 4cf9

· rebase tudo em uma ramificação marcada por um marcador para a ramificação padrão:

hg rebase --base myfeature --dest padrão

· recolher uma sequência de alterações em um único commit:

hg rebase --collapse -r 1520:1525 -d .

· mover um branch nomeado preservando seu nome:

hg rebase -r "branch(featureX)" -d 1.3 --keepbranch

Retorna 0 em caso de sucesso, 1 se não houver rebase ou se houver conflitos não resolvidos.

opções:

-sim,--fonte
rebase o conjunto de alterações e descendentes especificados

-b,--base
rebase tudo do ponto de ramificação do conjunto de alterações especificado

-r,--rev
rebase essas revisões

-d,--destino
rebase no conjunto de alterações especificado

--colapso
recolher os conjuntos de alterações rebaseados

-m,--mensagem
usar texto como mensagem de confirmação de recolhimento

-e --editar
invocar editor em mensagens de confirmação

-eu,--arquivo de log
ler a mensagem de confirmação de recolhimento do arquivo

-k, --guarda
manter conjuntos de alterações originais

--manter galhos
manter nomes de ramificações originais

-D, --separar
(DESCONTINUADA)

-eu, --interativo
(DESCONTINUADA)

-t,--ferramenta
especificar ferramenta de mesclagem

-c, --Prosseguir
continuar um rebase interrompido

-uma, --abortar
abortar um rebase interrompido

--estilo
exibir usando arquivo de mapa de modelo (DESCONTINUADO)

-T,--modelo
exibir com modelo

A opção marcada [+] pode ser especificada várias vezes

registro
comandos para selecionar mudanças interativamente para commit / qrefresh

comandos
qgravar
grave interativamente um novo patch:

hg qrecord [OPÇÃO]... PATCH [ARQUIVO]...

See hg ajudar qnovo & hg ajudar registro para mais informações e uso.

registro
selecione interativamente as alterações para confirmar:

hg gravar [OPÇÃO]... [ARQUIVO]...

Se uma lista de arquivos for omitida, todas as alterações relatadas por hg estado serão candidatos a
gravação.

See hg ajudar datas para obter uma lista de formatos válidos para -d / - date.

Você será solicitado a registrar as alterações em cada arquivo modificado e para arquivos
com várias alterações, para cada alteração a ser usada. Para cada consulta, as seguintes respostas são
possível:

y - gravar esta alteração
n - pule esta mudança
e - edite esta alteração manualmente

s - pula as alterações restantes neste arquivo
f - grava as alterações restantes neste arquivo

d - feito, pule as alterações e arquivos restantes
a - grava todas as alterações em todos os arquivos restantes
q - sai, não grava nenhuma alteração

? - exibir ajuda

Este comando não está disponível ao confirmar uma mesclagem.

opções:

-UMA, --addremove
marque os arquivos novos / ausentes como adicionados / removidos antes de confirmar

--filial próximo
marcar uma cabeça de ramo como fechada

- alterar
alterar o pai do diretório de trabalho

-sim, --segredo
use a fase secreta para comprometer

-e --editar
invocar editor em mensagens de confirmação

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

-m,--mensagem
usar texto como mensagem de confirmação

-eu,--arquivo de log
ler mensagem de confirmação do arquivo

-d,--data
registre a data especificada como data de confirmação

-você,--do utilizador
registrar o usuário especificado como committer

-S, --subrepos
Recurso para subrepositórios

-C, --ignore-todo-espaço
ignore o espaço em branco ao comparar as linhas

-b, --ignore-espaço-mudança
ignorar as mudanças na quantidade de espaço em branco

-B, --ignore-linhas em branco
ignore as mudanças cujas linhas estão todas em branco

A opção marcada [+] pode ser especificada várias vezes

religar
recria hardlinks entre clones de repositório

comandos
religar
recriar hardlinks entre dois repositórios:

hg relink [ORIGEM]

Quando os repositórios são clonados localmente, seus arquivos de dados serão vinculados para que eles
use apenas o espaço de um único repositório.

Infelizmente, pulls subsequentes em qualquer um dos repositórios quebrarão os hardlinks de qualquer arquivo
tocado pelos novos conjuntos de alterações, mesmo que ambos os repositórios acabem puxando as mesmas alterações.

Da mesma forma, passar --rev para "hg clone" não usará nenhum hardlink, voltando para um
cópia completa do repositório de origem.

Este comando permite que você recrie esses hardlinks e recupere o espaço desperdiçado.

Este repositório será revinculado para compartilhar espaço com ORIGIN, que deve estar no mesmo
disco local. Se ORIGIN for omitido, procura por "default-relink", depois "default", em [paths].

Não tente nenhuma operação de leitura neste repositório enquanto o comando estiver em execução. (Ambos
repositórios serão bloqueados contra gravações.)

esquemas
estender esquemas com atalhos para enxames de repositório

Esta extensão permite que você especifique atalhos para URLs pai com muitos repositórios
para agir como um esquema, por exemplo:

[esquemas]
pi = http://code.python.org/hg/

Depois disso, você pode usá-lo como:

hg clone py://trunk/

Além disso, há suporte para alguns esquemas mais complexos, por exemplo, usados ​​pelo Google
Código:

[esquemas]
gcode = http://{1}.googlecode.com/hg/

A sintaxe é retirada dos templates do Mercurial, e você tem um número ilimitado de variáveis,
começando com 1 {} e continuando com 2 {}, 3 {} e assim por diante. Esta variável receberá
partes do URL fornecidas, divididas por /. Qualquer coisa não especificada como {papel} será apenas anexado
para um URL.

Por conveniência, a extensão adiciona esses esquemas por padrão:

[esquemas]
pi = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://[email protegido]/
gcode = https://{1}.googlecode.com/hg/
forno = https://{1}.kilnhg.com/Repo/

Você pode substituir um esquema predefinido definindo um novo esquema com o mesmo nome.

share
compartilham uma história comum entre vários diretórios de trabalho

Automático Agrupado Armazenamento para clones
Quando esta extensão está ativa, hg clonar pode ser configurado para compartilhar/pool automaticamente
armazenamento em vários clones. Este modo converte efetivamente hg clonar para hg clonar + hg
share. A vantagem de usar este modo é o gerenciamento automático de caminhos de loja e
agrupamento inteligente de repositórios relacionados.

Os seguintes partes. opções de configuração influenciam este recurso:

compartilhar.pool

Caminho do sistema de arquivos onde os dados do repositório compartilhado serão armazenados. Quando definido, hg clonar
irá usar automaticamente o armazenamento de repositório partilhado em vez de criar um armazenamento dentro
cada clone.

compartilhar.poolnaming

Como os nomes dos diretórios em compartilhar.pool são construídos.

"identidade" significa que o nome é derivado do primeiro conjunto de alterações no repositório. Dentro
Neste modo, diferentes controles remotos compartilham o armazenamento se seu conjunto de alterações raiz/inicial for
idêntico. Neste modo, o repositório local compartilhado é um agregado de todos os
encontrou repositórios remotos.

"remoto" significa que o nome é derivado do caminho ou URL do repositório de origem. Dentro
Neste modo, o armazenamento só é compartilhado se o caminho ou URL solicitado no hg clonar
O comando corresponde exatamente a um repositório que foi clonado antes.

O modo de nomenclatura padrão é "identidade".

comandos
share
crie um novo repositório compartilhado:

hg compartilhar [-U] [-B] FONTE [DEST]

Inicialize um novo repositório e diretório de trabalho que compartilhe seu histórico (e opcionalmente
bookmarks) com outro repositório.

Observe que o uso de rollback ou extensões que destroem/modificam o histórico (mq, rebase, etc.)
causar confusão considerável com clones compartilhados. Em particular, se dois compartilharam
clones são ambos atualizados para o mesmo changeset, e um deles destrói aquele
changeset com rollback, o outro clone irá parar de funcionar de repente: todas as operações
falhará com "abortar: diretório de trabalho tem pai desconhecido". O único conhecido
solução alternativa é usar debugsetparents no clone quebrado para redefini-lo para um changeset
que ainda existe.

opções:

-VOCÊ, --sem atualização
não crie um diretório de trabalho

-B, --favoritos
também compartilhar favoritos

descompartilhar
converter um repositório compartilhado em um normal:

hg descompartilhar

Copie os dados da loja para o repositório e remova os dados do caminho compartilhado.

arquivar
salvar e restaurar as alterações no diretório de trabalho

O comando "hg shelve" salva as alterações feitas no diretório de trabalho e as reverte
alterações, redefinindo o diretório de trabalho para um estado limpo.

Mais tarde, o comando "hg unshelve" restaura as alterações salvas por "hg shelve". As alterações podem
ser restaurado mesmo após a atualização para um pai diferente, nesse caso a mesclagem do Mercurial
máquinas resolverão quaisquer conflitos, se necessário.

Você pode ter mais de uma alteração arquivada pendente por vez; cada mudança arquivada tem um
nome distinto. Para obter detalhes, consulte a ajuda de "hg shelve".

comandos
arquivar
salve e reserve as alterações do diretório de trabalho:

hg arquivar [OPÇÃO]... [ARQUIVO]...

O shelving pega os arquivos que o "status hg" informa como não limpos, salva as modificações em um
bundle (uma alteração arquivada) e reverte os arquivos para que seu estado na pasta de trabalho
diretório fica limpo.

Para restaurar essas alterações no diretório de trabalho, usando "hg unshelve"; isso vai funcionar
mesmo se você mudar para um commit diferente.

Quando nenhum arquivo é especificado, "hg shelve" salva todos os arquivos não limpos. Se arquivos específicos ou
diretórios são nomeados, apenas as alterações nesses arquivos são arquivadas.

Cada alteração arquivada tem um nome que facilita a localização posterior. O nome de uma estante
alterar o padrão para ser baseado no marcador ativo ou, se não houver um marcador ativo,
a ramificação nomeada atual. Para especificar um nome diferente, use --nome.

Para ver uma lista de alterações arquivadas existentes, use o --Lista opção. Para cada mudança arquivada,
isso imprimirá seu nome, idade e descrição; usar --correção or --Estado para mais detalhes.

Para excluir alterações arquivadas específicas, use --excluir. Para excluir todas as alterações arquivadas, use
--limpar.

opções:

-UMA, --addremove
marcar arquivos novos/ausentes como adicionados/removidos antes de arquivar

-você, --desconhecido
armazenar arquivos desconhecidos na prateleira

--limpar
excluir todas as alterações arquivadas

--data
arquivar com a data de confirmação especificada

-d, --excluir
excluir a(s) alteração(ões) arquivada(s) nomeada(s)

-e --editar
invocar editor em mensagens de confirmação

-eu, --Lista
listar prateleiras atuais

-m,--mensagem
usar texto como mensagem de arquivamento

-n,--nome
use o nome dado para o commit arquivado

-p, --correção
mostrar patch

-eu, --interativo
modo interativo, só funciona ao criar uma estante

--Estado saída de resumo de mudanças no estilo diffstat

-EU,--incluir
incluem nomes que correspondem aos padrões dados

-X,--excluir
excluir nomes que correspondam aos padrões fornecidos

A opção marcada [+] pode ser especificada várias vezes

desentocar
restaure uma alteração arquivada no diretório de trabalho:

hg desarquivar [SHELVE]

Este comando aceita um nome opcional de uma alteração arquivada para restauração. Se nenhum for dado,
a alteração arquivada mais recente é usada.

Se uma alteração arquivada for aplicada com sucesso, o pacote que contém as alterações arquivadas
é movido para um local de backup (.hg/shelve-backup).

Como você pode restaurar uma alteração arquivada em cima de um commit arbitrário, é possível que
desarquivar resultará em um conflito entre suas alterações e os commits que você está
desentupimento. Se isso ocorrer, você deve resolver o conflito, então use --Prosseguir para
concluir a operação de desarquivamento. (O pacote não será movido até que você
complete o desarquivamento.)

(Como alternativa, você pode usar --abortar abandonar um unshelf que causa um conflito. Isto
reverte as alterações não arquivadas e deixa o pacote no lugar.)

Após um desarquivamento bem-sucedido, as alterações arquivadas são armazenadas em um diretório de backup. Somente
os N backups mais recentes são mantidos. O padrão de N é 10, mas pode ser substituído usando o
arquivar.maxbackups opção de configuração.

O carimbo de data/hora em segundos é usado para decidir a ordem dos backups. Mais que backups máximos backups são
mantido, se o mesmo timestamp impedir de decidir a ordem exata deles, por segurança.

opções:

-uma, --abortar
abortar uma operação de desarquivamento incompleta

-c, --Prosseguir
continuar uma operação de desarquivamento incompleta

-k, --guarda
manter arquivar após desarquivar

-t,--ferramenta
especificar ferramenta de mesclagem

--data
definir data para commits temporários (OBSOLETO)

tira
tira os changesets e seus descendentes da história

Esta extensão permite remover conjuntos de alterações e todos os seus descendentes do
repositório. Consulte a ajuda do comando para obter detalhes.

comandos
tira
retire os changesets e todos os seus descendentes do repositório:

hg strip [-k] [-f] [-B marcador] [-r] REV...

O comando strip remove os changesets especificados e todos os seus descendentes. Se o
diretório de trabalho tem alterações não confirmadas, a operação é abortada a menos que o --force
sinalizador é fornecido, caso em que as alterações serão descartadas.

Se um pai do diretório de trabalho for removido, o diretório de trabalho será
ser atualizado automaticamente para o ancestral disponível mais recente do pai despojado
após a conclusão da operação.

Quaisquer conjuntos de alterações removidos são armazenados em .hg / strip-backup como um pacote (ver hg ajudar empacotar e
hg ajudar descompactar). Eles podem ser restaurados executando hg descompactar .hg/strip-backup/BUNDLE,
onde BUNDLE é o arquivo de pacote criado pela faixa. Observe que os números de revisão locais
geralmente será diferente após a restauração.

Use a opção --no-backup para descartar o pacote de backup assim que a operação for concluída.

Strip não é uma operação de reescrita de histórico e pode ser usado em changesets no público
Estágio. Mas se os conjuntos de alterações removidos foram enviados para um repositório remoto, você
provavelmente puxá-los novamente.

Retorne 0 em caso de sucesso.

opções:

-r,--rev
tira a revisão especificada (opcional, pode especificar revisões sem esta opção)

-f, --força
forçar a remoção de changesets, descartar alterações não confirmadas (sem backup)

--sem backup
sem backups

--sem backup
sem backups (OBSOLETO)

-n ignorado (OBSOLETO)

-k, --guarda
não modifique o diretório de trabalho durante a tira

-B,--marca páginas
remover rotações acessíveis apenas a partir de determinado marcador

A opção marcada [+] pode ser especificada várias vezes

transplante
comando para transplantar changesets de outro ramo

Esta extensão permite que você transfira as alterações para outra revisão pai, possivelmente em
outro repositório. O transplante é feito usando patches 'diff'.

As manchas transplantadas são registradas em .hg/transplant/transplants, como um mapa de um changeset
hash para seu hash no repositório de origem.

comandos
transplante
transplante changesets de outro branch:

hg transplante [-s REPO] [-b FILIAL [-a]] [-p REV] [-m REV] [REV]...

Os conjuntos de alterações selecionados serão aplicados no topo do diretório de trabalho atual com o log
do conjunto de alterações original. Os changesets são copiados e, portanto, aparecerão duas vezes no
história com identidades diferentes.

Considere usar o comando enxerto se tudo estiver dentro do mesmo repositório - ele usará
mescla e geralmente dará um resultado melhor. Use a extensão rebase se os changesets
não foram publicados e você deseja movê-los em vez de copiá-los.

Se --log for especificado, as mensagens de log terão um comentário anexado no formato:

(transplantado de CHANGESETHASH)

Você pode reescrever a mensagem do changelog com a opção --filter. Seu argumento será
invocado com a mensagem atual do changelog como $1 e o patch como $2.

--source/-s especifica outro repositório a ser usado para selecionar conjuntos de alterações, como se
foi temporariamente puxado. Se --branch/-b for especificado, essas revisões serão usadas como
cabeças ao decidir quais conjuntos de alterações transplantar, como se apenas essas revisões tivessem
foi puxado. Se --all/-a for especificado, todas as revisões até as cabeças especificadas com
--branch será transplantado.

Exemplo:

· transplantar todas as alterações até REV em cima de sua revisão atual:

transplante de hg --branch REV --all

Opcionalmente, você pode marcar conjuntos de alterações transplantados selecionados como conjuntos de alterações de mesclagem. Você não vai
ser solicitado a transplantar quaisquer ancestrais de um transplante mesclado, e você pode mesclar
descendentes deles normalmente em vez de transplantá-los.

Os conjuntos de alterações de mesclagem podem ser transplantados diretamente especificando o conjunto de alterações pai adequado por
chamada hg transplante --pai.

Se nenhuma mesclagem ou revisão for fornecida, hg transplante irá iniciar um changeset interativo
navegador.

Se um aplicativo de conjunto de alterações falhar, você pode corrigir a mesclagem manualmente e, em seguida, retomar onde você
deixou de ligar hg transplante --continua/-c.

opções:

-sim,--fonte
conjuntos de alterações de transplante do REPO

-b,--filial
use este conjunto de alterações de origem como head

-uma, --tudo
puxe todos os changesets para as revisões --branch

-p,--ameixa seca
pular REV

-m,--mesclar
mesclar em REV

--pai
pai para escolher ao transplantar mesclar

-e --editar
invocar editor em mensagens de confirmação

--registro anexar informações de transplante à mensagem de log

-c, --Prosseguir
continuar a última sessão de transplante após corrigir conflitos

--filtro
filtrar conjuntos de alterações através do comando

A opção marcada [+] pode ser especificada várias vezes

win32mbcs
permitir o uso de caminhos MBCS com codificações problemáticas

Algumas codificações MBCS não são boas para algumas operações de caminho (ou seja, divisão de caminho, caso
conversão, etc.) com seus bytes codificados. Chamamos essa codificação (ou seja, shift_jis e
big5) como "codificação problemática". Esta extensão pode ser usada para corrigir o problema com aqueles
codificações envolvendo algumas funções para converter em string Unicode antes da operação de caminho.

Esta extensão é útil para:

· Usuários japoneses do Windows usando a codificação shift_jis.

· Usuários chineses do Windows usando codificação big5.

· Todos os usuários que usam um repositório com uma das codificações problemáticas em maiúsculas e minúsculas
sistema de arquivo.

Esta extensão não é necessária para:

· Qualquer usuário que use apenas caracteres ASCII no caminho.

· Qualquer usuário que não use nenhuma das codificações problemáticas.

Observe que existem algumas limitações ao usar essa extensão:

· Você deve usar codificação única em um repositório.

· Se o caminho do repositório terminar com 0x5c, .hg/hgrc não poderá ser lido.

· win32mbcs não é compatível com a extensão fixutf8.

Por padrão, o win32mbcs usa encoding.encoding decidido pelo Mercurial. Você pode especificar o
codificação por opção de configuração:

[win32mbcs]
codificação = sjis

É útil para os usuários que desejam confirmar com a mensagem de log UTF-8.

texto win32
realizar conversão automática de nova linha (OBSOLETO)

Descontinuação: A extensão win32text requer que cada usuário configure a extensão
repetidamente para cada clone, pois a configuração não é copiada durante a clonagem.

Fizemos, portanto, a eol como uma alternativa. O eol usa uma versão controlada
arquivo para sua configuração e cada clone, portanto, usará as configurações corretas de
o começo.

Para realizar a conversão automática de nova linha, use:

[extensões]
win32texto =
[codificar]
** = codificação inteligente:
# ou ** = macencode:

[decodificar]
** = decodificação inteligente:
# ou ** = macdecode:

Se não estiver fazendo a conversão, para ter certeza de não cometer CRLF/CR por acidente:

[ganchos]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf
# ou pretxncommit.cr = python:hgext.win32text.forbidcr

Para fazer a mesma verificação em um servidor para evitar que o CRLF/CR seja enviado por push ou pull:

[ganchos]
pretxnchangegroup.crlf = python:hgext.win32text.forbidcrlf
# ou pretxnchangegroup.cr = python:hgext.win32text.forbidcr

Zeroconf
descobrir e anunciar repositórios na rede local

A extensão zeroconf anunciará hg servir instâncias sobre DNS-SD para que possam ser
descoberto usando o hg caminhos comando sem saber o endereço do servidor.

Para permitir que outras pessoas descubram seu repositório usando run hg servir em seu repositório:

teste de $ cd
$ hg servir

Você pode descobrir repositórios habilitados para Zeroconf executando hg caminhos:

caminhos de $ hg
teste zc = http://example.com:8000/teste

Use hg online usando os serviços onworks.net