hg - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

hg - система управління вихідним кодом Mercurial

СИНТАКСИС

hg команда [варіант]... [аргумент]...

ОПИС

Команда hg Команда забезпечує інтерфейс командного рядка до системи Mercurial.

КОМАНДА ЕЛЕМЕНТИ

файли ...
вказує одне або кілька назв файлу або відносний шлях імен файлів; див. Шаблони імен файлів
для отримання інформації про відповідність шаблону

шлях вказує шлях на локальній машині

перегляд
вказує набір змін, який можна вказати як номер редакції набору змін, тег,
або унікальний підрядок хеш-значення набору змін

Сховище шлях
або ім'я шляху до локального сховища, або URI віддаленого сховища.

ВАРІАНТИ

-Р,--сховище
кореневий каталог репозиторію або ім'я файлу пакету накладання

--cwd
змінити робочий каталог

-у, --неінтерактивні
не підказувати, автоматично вибирайте перший вибір для всіх підказок

-q, --спокійно
придушити вихід

-v, -багатослівний
увімкнути додатковий вихід

--config
встановити/перевизначити параметр конфігурації (використовуйте 'section.name=value')

--відлагоджувати
увімкнути вихід налагодження

--налагоджувач
запустити налагоджувач

--кодування
встановити кодування кодування (за замовчуванням: UTF-8)

--режим кодування
встановити режим кодування кодування (за замовчуванням: строгий)

--простежити
завжди друкуйте зворотне відстеження за винятком

--час час, скільки часу займає команда

--профіль
профіль виконання команд друку

-- версія
вивести інформацію про версію та вийти

-h, --допомога
відобразити довідку та вийти

--прихований
розглянути приховані набори змін

Позначений [+] параметр можна вказати кілька разів

КОМАНДИ

додавати
додайте вказані файли до наступного коміту:

hg додати [OPTION]... [FILE]...

Заплануйте файли для контролю версії та додавання їх у репозиторій.

Файли будуть додані до сховища під час наступного коміту. Щоб скасувати додавання перед цим,
побачити hg забувати.

Якщо імена не вказані, додайте всі файли до сховища (крім файлів, що відповідають .hgignore).

Приклади:

· Нові (невідомі) файли додаються автоматично hg додавати:

$ls
foo.c
$hg статус
? foo.c
$hg додати
додавання foo.c
$hg статус
А foo.c

· Можна вказати конкретні файли, які потрібно додати:

$ls
bar.c foo.c
$hg статус
? бар.ц
? foo.c
$hg додати bar.c
$hg статус
Бар.c
? foo.c

Повертає 0, якщо всі файли успішно додано.

варіанти:

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-S, --підтримка
повертатися в підрепозиторії

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

Позначений [+] параметр можна вказати кілька разів

видалення адреси
додати всі нові файли, видалити всі відсутні файли:

hg addremove [ПАРАМЕТР]... [ФАЙЛ]...

Додайте всі нові файли та видаліть усі відсутні файли зі сховища.

Якщо не вказано імена, нові файли ігноруються, якщо вони відповідають будь-якому шаблону в
.hgignore. Як і у випадку з додаванням, ці зміни вступають в силу при наступному коміті.

Використовуйте параметр -s/--similarity, щоб виявити перейменовані файли. Цей варіант займає відсоток
від 0 (вимкнено) до 100 (файли мають бути ідентичними) як його параметр. З параметром
більше 0, це порівнює кожен видалений файл з кожним доданим файлом і записує їх
досить схожі на перейменування. Виявлення перейменованих файлів таким чином може бути дорогим. Після використання
цей варіант, hg статус -C можна використовувати, щоб перевірити, які файли ідентифіковано як переміщені або
перейменовано. Якщо не вказано, -s/--подібність за замовчуванням дорівнює 100 і перейменовує лише ідентичні
файли виявлено.

Приклади:

· Деякі файли (bar.c і foo.c) є новими, а foobar.c видалено (без
використання hg видаляти) зі сховища:

$ls
bar.c foo.c
$hg статус
! foobar.c
? бар.ц
? foo.c
$hg addremove
додавання bar.c
додавання foo.c
видалення foobar.c
$hg статус
Бар.c
А foo.c
R foobar.c

· Файл foobar.c було переміщено до foo.c без використання hg перейменувати. Згодом це було
трохи відредаговано:

$ls
foo.c
$hg статус
! foobar.c
? foo.c
$ hg addremove --подібність 90
видалення foobar.c
додавання foo.c
запис видалення foobar.c як перейменування на foo.c (94% схоже)
$Hg статус -C
А foo.c
foobar.c
R foobar.c

Повертає 0, якщо всі файли успішно додано.

варіанти:

-так,-подібність
вгадати перейменовані файли за схожістю (0<=s<=100)

-S, --підтримка
повертатися в підрепозиторії

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

Позначений [+] параметр можна вказати кілька разів

коментувати
показати інформацію про набір змін за рядком для кожного файлу:

hg анотувати [-r REV] [-f] [-a] [-u] [-d] [-n] [-c] [-l] ФАЙЛ...

Перелік змін у файлах із зазначенням ідентифікатора редакції, відповідальної для кожного рядка.

Ця команда корисна для виявлення того, коли і ким була внесена зміна.

Якщо ви включите --file, --user або --date, номер версії буде приховано, якщо ви не
також включають --number.

Без параметра -a/--text, annotate уникає обробки файлів, які вона виявляє як двійкові.
За допомогою -a annotate все одно буде анотувати файл, хоча результати, ймовірно, будуть
ні корисним, ні бажаним.

У разі успіху повертає 0.

варіанти:

-р,--rev
анотувати зазначену редакцію

-- слідувати
дотримуйтесь копій/іменувань та перерахуйте ім’я файлу (ЗАСТАРІЛО)

--не слідувати
не слідкуйте за копіями та перейменуваннями

-а, --текст
розглядати всі файли як текст

-у, --користувач
вказати автора (довго з -v)

-f, --файл
вказати ім'я файлу

-d, --дата
перелік дати (коротко з -q)

-n, --число
укажіть номер версії (за замовчуванням)

-c, --набір змін
список змін

-л, --номер рядка
показати номер рядка при першому появі

-w, --ігнорувати-все-пробіл
ігноруйте пробіл під час порівняння рядків

-б, --ignore-space-change
ігнорувати зміни в кількості пробілів

-Б, --ignore-blank-lines
ігнорувати зміни, усі рядки яких порожні

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

Позначений [+] параметр можна вказати кілька разів

псевдоніми: звинувачувати

архів
створити неверсійний архів версії репозитарію:

hg архів [ПАРАЦІЯ]... ЦІЛЬ

За замовчуванням використовувана версія є батьківською для робочого каталогу; використовувати -r/--rev до
вкажіть іншу редакцію.

Тип архіву визначається автоматично на основі розширення файлу (щоб замінити, використовуйте
-t/--тип).

Приклади:

· створити zip-файл, що містить випуск 1.0:

hg archive -r 1.0 project-1.0.zip

· створити tar-архів, виключаючи файли .hg:

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

Допустимі типи:

файли

каталог, повний файлів (за замовчуванням)

дьоготь

tar архів, нестиснений

tbz2

tar архів, стиснутий за допомогою bzip2

tgz

tar архів, стиснутий за допомогою gzip

uzip

zip-архів, нестиснутий

ZIP

zip-архів, стиснутий за допомогою deflate

Точна назва цільового архіву або каталогу задається за допомогою рядка форматування; подивитися
hg допомога експорт for details.

Перед кожним членом, доданим до файлу архіву, додається префікс каталогу. Використовуйте префікс -p/-- для
вкажіть рядок форматування для префікса. За замовчуванням є базова назва архіву, с
суфікси вилучено.

У разі успіху повертає 0.

варіанти:

--не декодувати
не передавати файли через декодери

-p,--префікс
префікс каталогу для файлів в архіві

-р,--rev
редакція для поширення

-t,--тип
тип розповсюдження для створення

-S, --підтримка
повертатися в підрепозиторії

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

Повернись назад
зворотний ефект від попереднього набору змін:

hg backout [ПАРАМЕТР]... [-r] REV

Підготуйте новий набір змін з ефектом REV, скасованим у поточному робочому каталозі. Якщо
жодних конфліктів не виникло, буде здійснено негайно.

Якщо REV є батьківським для робочого каталогу, то цей новий набір змін фіксується
автоматично (якщо не вказано --no-commit).

примітки hg Повернись назад не можна використовувати для виправлення небажаного або неправильного злиття.

Приклади:

· Зворотний ефект батьківського робочого каталогу. Це відступ буде
вчинено негайно:

hg backout -r .

· Скасувати дію попередньої поганої редакції 23:

hg backout -r 23

· Скасувати дію попередньої поганої версії 23 і залишити зміни незафіксованими:

hg backout -r 23 --без фіксації
hg commit -m "Backout revision 23"

За замовчуванням набір змін, що очікує на розгляд, матиме одного з батьків, зберігаючи лінійну історію. З
--merge, набір змін, що очікує на розгляд, матиме двох батьків: старий батьківський елемент
робочий каталог і новий дочірній файл REV, який просто скасовує REV.

До версії 1.7 поведінка без --merge була еквівалентною вказівці --merge
подальшою hg оновлення --чистий . скасувати злиття та залишити дочірній елемент REV як керівник
об'єднати окремо.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Читати hg допомога повернути для способу відновлення файлів до стану іншої версії.

Повертає 0 у разі успіху, 1, якщо нічого не викачувати або є нерозв’язані файли.

варіанти:

-- об'єднати
злиття зі старим батьківським dirstate після повернення

--здійснити
зафіксувати, якщо не виникло жодних конфліктів (ЗАСТАРЕЛО)

--без фіксації
не здійснюйте

--батька
батьківський елемент, який можна вибрати під час відмовлення від злиття (ЗАСТАРЕЛО)

-р,--rev
ревізію для повернення

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-t,--інструмент
вказати інструмент об’єднання

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

Позначений [+] параметр можна вказати кілька разів

бісект
пошук підрозділу наборів змін:

hg розрізати навпіл [-gbsr] [-U] [-c CMD] [REV]

Ця команда допомагає знайти набори змін, які викликають проблеми. Для використання позначте найраніші
набір змін, який ви знаєте, демонструє проблему як погану, а потім позначте останній набір змін, який є
вільний від проблеми як добре. Bisect оновить ваш робочий каталог до версії для
тестування (якщо не вказано параметр -U/--noupdate). Після того, як ви провели тести,
позначте робочий каталог як хороший або поганий, і bisect або оновиться до іншого
набір змін кандидата або оголосити, що він виявив погану редакцію.

Як ярлик, ви також можете використовувати аргумент revision, щоб позначити ревізію як гарну чи погану
без попередньої перевірки.

Якщо ви введете команду, вона буде використана для автоматичного поділу навпіл. Навколишнє середовище
змінна HG_NODE міститиме ідентифікатор набору змін, що перевіряється. Вихідний статус
команда буде використовуватися для позначення ревізій як хороших чи поганих: статус 0 означає добре, 125 означає, що
пропустити ревізію, 127 (команда не знайдена) скасує поділ, а будь-яка інша
Ненульовий статус виходу означає, що версія погана.

Приклади:

· розпочати ділення навпіл з відомої поганої версії 34 і хорошої версії 12:

ртутний ртут навпіл --поганий 34
рт.ст. навпіл -- добре 12

· переміщення поточного розділу навпіл, позначаючи поточну редакцію як гарну чи погану:

hg бісект -- добре
hg бісект --поганий

· позначте поточну редакцію або відому редакцію, яку потрібно пропустити (наприклад, якщо ця редакція є
не можна використовувати через іншу проблему):

hg пополам --пропустити
рт. д. навпіл --пропустити 23

· пропустити всі редакції, які не стосуються каталогів Foo or бар:

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

· забудьте поточну ділення навпіл:

hg навпіл --скидання

· використовуйте 'make && make tests', щоб автоматично знайти першу зламану ревізію:

hg навпіл --скидання
ртутний ртут навпіл --поганий 34
рт.ст. навпіл -- добре 12
hg bisect --команда "зробити && зробити тести"

· переглянути всі набори змін, стани яких уже відомі в поточній бісекції:

hg log -r "розрізати навпіл (обрізати)"

· побачити набір змін, який в даний момент ділиться навпіл (особливо корисно, якщо працює з
-U/--noupdate):

hg log -r "поділ (поточний)"

· переглянути всі набори змін, які брали участь у поточній бісекції:

hg log -r "поділ (діапазон)"

· ви навіть можете отримати гарний графік:

hg log --graph -r "поділ (діапазон)"

Читати hg допомога ревсець щоб дізнатися більше про пополам() keyword.

У разі успіху повертає 0.

варіанти:

-р, --скидання
скинути стан бісекти

-g, -- добре
позначити набір змін як хороший

-б, --погано
позначити набір змін як поганий

-так, --пропустити
пропустити тестування набору змін

-е, -- розширити
розширити діапазон бісекти

-c,-- команда
використовуйте команду, щоб перевірити стан набору змін

-У, --noupdate
не оновлювати до цільової

закладки
створити нову закладку або список наявних закладок:

hg закладки [ПАРАЦІЇ]... [ІМ'Я]...

Закладки — це мітки на наборах змін, які допомагають відстежувати лінії розвитку. Закладки є
без версії і може бути переміщений, перейменований та видалений. Видалення або переміщення закладки не має
вплив на пов’язані набори змін.

Створення або оновлення закладки призводить до того, що вона буде позначена як «активна». Активний
закладка позначається символом «*». Коли зроблено фіксацію, активна закладка буде переміщена вперед
до нового коміту. Рівнина hg оновлення також передує активну закладку, якщо це можливо.
Оновлення від закладки призведе до її деактивації.

Закладки можна переміщувати та перетягувати між сховищами (див hg допомога штовхати та hg допомога тягнути
). Якщо спільна закладка розійшлася, створюється нова "розбіжна закладка" у формі "ім'я@шлях"
буде створено. Використання hg злиття вирішить розбіжність.

Закладка з назвою '@' має спеціальну властивість, що hg клон перевірить його за замовчуванням
якщо воно існує.

Приклади:

· створити активну закладку для нової лінії розробки:

hg книга нова функція

· створити неактивну закладку як маркер місця:

hg книга -я переглянув

· створити неактивну закладку на іншому наборі змін:

hg книга -r .^ перевірено

· перейменувати закладку індички на обід:

hg book -m вечеря з індички

· перемістити закладку «@» з іншої гілки:

hg книга -f @

варіанти:

-f, --сила
змусити

-р,--rev
перегляд для дії закладки

-d, --видалити
видалити задану закладку

-м,--перейменувати
перейменувати задану закладку

-я, --неактивний
позначити закладку неактивною

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

псевдоніми: закладка

філія
встановити або показати поточну назву гілки:

hg гілка [-fC] [ІМ'Я]

Примітка. Назви філій є постійними та глобальними. Використовуйте hg закладка для створення легкої ваги
замість закладки. Подивитися hg допомога глосарій для отримання додаткової інформації про названі гілки
та закладки.

Показуйте поточну назву гілки без аргументу. З одним аргументом налаштуйте робочий
ім'я гілки каталогу (гілка не буде існувати в репозиторії до наступного коміту).
Стандартна практика рекомендує, щоб первинна розробка відбувалася на гілці «за замовчуванням».

Якщо не вказано -f/--force, гілка не дозволить вам встановити назву гілки, яка вже є
існує

Використовуйте -C/--clean, щоб скинути гілку робочого каталогу до батьківської гілки робочого каталогу
каталогу, заперечуючи попередню зміну гілки.

Використовуйте команду hg оновлення щоб перейти до існуючої філії. Використовуйте hg commit --ближне відділення до
позначте цю головку гілки як закриту. Коли всі голови філії будуть закриті, філія буде закрита
вважати закритими.

У разі успіху повертає 0.

варіанти:

-f, --сила
встановити назву гілки, навіть якщо вона затінює існуючу гілку

-C, --чистий
скинути назву гілки до назви батьківської гілки

гілки
список сховища з іменами гілок:

hg гілки [-c]

Перерахуйте названі гілки сховища, вказавши, які з них неактивні. Якщо -c/--закрито
вказано, також перелічує гілки, які були позначені закритими (див hg commit
--ближне відділення).

Використовуйте команду hg оновлення щоб перейти до існуючої філії.

Повертає 0.

варіанти:

-а, --активний
показувати лише гілки, які мають не об’єднані заголовки (ЗАСТАРЕЛО)

-c, --зачинено
показати нормальні та закриті гілки

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

пакет
створити файл групи змін:

hg bundle [-f] [-t TYPE] [-a] [-r REV]... [--base REV]... ФАЙЛ [ЦІЛЬ]

Створіть файл групи змін, який збирає набори змін для додавання до сховища.

Щоб створити пакет, що містить усі набори змін, використовуйте -a/--all (або --base null). В іншому випадку, рт
передбачає, що в пункті призначення будуть всі вузли, які ви вкажете за допомогою параметрів --base.
Інакше hg вважатиме, що сховище має всі вузли в місці призначення, або
default-push/default, якщо не вказано місце призначення.

Ви можете змінити формат пакета за допомогою параметра -t/--type. Ви можете вказати стиснення, a
пакетна версія або обидві з використанням тире (comp-версія). Доступні методи стиснення:
none, bzip2 і gzip (за замовчуванням пакети стискаються за допомогою bzip2). Доступні
Формати: v1, v2 (за замовчуванням – найбільш підходящий).

Потім пакетний файл можна передати звичайними засобами та застосувати до іншого
репозиторій за допомогою команди unbundle або pull. Це корисно, коли є пряме натискання та витягування
недоступний або коли експорт всього сховища небажаний.

Застосування пакетів зберігає весь вміст набору змін, включаючи дозволи, копіювання/перейменування
інформація та історія переглядів.

Повертає 0 у разі успіху, 1, якщо змін не знайдено.

варіанти:

-f, --сила
виконувати, навіть якщо призначення не пов’язане

-р,--rev
набір змін, призначений для додавання до місця призначення

-б,-філія
конкретну гілку, яку ви хочете об’єднати

--база
базовий набір змін, який, як передбачається, доступний у місці призначення

-а, --все
об’єднати всі набори змін у сховищі

-t,--тип
Тип стиснення пакета, який потрібно використовувати (за замовчуванням: bzip2)

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

як
вивести поточну або задану редакцію файлів:

hg cat [ВАРІАНТ]... ФАЙЛ...

Роздрукуйте вказані файли так, як вони були під час даної редакції. Якщо перегляд не надано, то
використовується батько робочого каталогу.

Вихід може бути у файлі, у цьому випадку ім’я файлу задається за допомогою формату
рядок. Правила форматування такі:

%%

буквальний символ "%".

%s

базова назва файлу, що друкується

%d

ім'я файлу, що друкується, або '.' якщо в кореневому сховищі

%p

кореневий шлях до файлу, який друкується

%H

хеш змін (40 шістнадцяткових цифр)

%R

номер редакції набору змін

%h

короткий хеш набору змін (12 шістнадцяткових цифр)

%r

номер редакції набору змін із нульовим доповненням

%b

базове ім'я експортованого репозиторію

У разі успіху повертає 0.

варіанти:

-о,- вихід
роздрукувати вихід у файл із відформатованим ім'ям

-р,--rev
роздрукувати дану редакцію

--декодувати
застосувати будь-який відповідний фільтр декодування

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

клон
зробити копію існуючого сховища:

hg clone [OPTION]... ДЖЕРЕЛО [ЦІЛЬ]

Створіть копію існуючого сховища в новому каталозі.

Якщо ім’я каталогу призначення не вказано, за замовчуванням буде використано базове ім’я джерела.

Розташування джерела додається до нового сховища .hg/hgrc файл за замовчуванням
для використання в майбутньому.

Тільки місцеві шляхи і ssh:// URL-адреси підтримуються як цільові. Для ssh:// місця призначення,
немає робочого каталогу або .hg/hgrc буде створено на віддаленій стороні.

Якщо у вихідному сховищі встановлена ​​закладка під назвою «@», ця редакція буде переглянута
в новому репозиторії за замовчуванням.

Щоб перевірити певну версію, використовуйте -u/--update або -U/--noupdate, щоб створити клон
без робочого каталогу.

Щоб отримати лише підмножину наборів змін, укажіть один або кілька ідентифікаторів ревізій
-r/--rev або гілки з -b/--гілкою. Отриманий клон міститиме лише вказане
набори змін та їхні предки. Ці параметри (або 'clone src#rev dest') означають --pull, навіть
для локальних сховищ джерел.

Примітка. Вказання тегу включатиме позначений набір змін, але не набір змін, що містить
тег.

Для ефективності жорсткі посилання використовуються для клонування, коли джерело та призначення увімкнені
та сама файлова система (зверніть увагу, що це стосується лише даних репозиторію, а не робочих
каталог). Деякі файлові системи, такі як AFS, реалізують жорстке посилання некоректно, але цього не роблять
повідомляти про помилки. У цих випадках використовуйте параметр --pull, щоб уникнути жорсткого зв’язування.

У деяких випадках ви можете клонувати репозиторії та робочий каталог, використовуючи повні жорсткі посилання
з

$ cp -al РЕПОКЛОН РЕПО

Це найшвидший спосіб клонування, але він не завжди безпечний. Операція не є атомарною
(переконатися, що РЕПО не змінено під час операції, вирішувати вам), і ви повинні зробити
переконайтеся, що ваш редактор порушує жорсткі посилання (Emacs і більшість інструментів ядра Linux роблять це). Крім того, це
несумісний з певними розширеннями, які розміщують свої метадані в каталозі .hg,
наприклад mq.

Mercurial оновить робочий каталог до першої відповідної версії з цього
список:

а. null, якщо -U або вихідне сховище не має наборів змін

б. якщо -u . а вихідне сховище є локальним, першим батьківським сховищем вихідного коду
робочий каталог

c. набір змін, зазначений за допомогою -u (якщо назва гілки, це означає останню заголовок цього
відділення)

d. набір змін, зазначений за допомогою -r

e. крайня головка, зазначена через -b

f. найголовніша головка, зазначена за допомогою синтаксису джерела url#branch

g. редакція, позначена закладкою «@», якщо є

ч. найголовніша голова гілки за замовчуванням

я порада

Під час клонування із серверів, які його підтримують, Mercurial може отримати попередньо згенеровані дані з a
URL-адреса, рекламована сервером. Коли це буде зроблено, зачіпки, що працюють на вхідних наборах змін і
changegroups можуть запускатися двічі, один раз для пакета, отриманого з URL-адреси, і інший для будь-якого
додаткові дані не отримано з цієї URL-адреси. Крім того, якщо виникає помилка, репозиторій
можна відкотити до часткового клону. Ця поведінка може змінитися в майбутніх випусках. Подивитися hg
допомога -e пучки клонів для більш.

Приклади:

· клонувати віддалений репозиторій до нового каталогу з іменем hg/:

клон hg http://selenic.com/hg

· створити легкий локальний клон:

hg clone project/ project-feature/

· клонування з абсолютного шляху на сервері ssh (зверніть увагу на подвійну косу риску):

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

· зробити високошвидкісне клонування через локальну мережу під час перевірки вказаної версії:

hg clone --нестиснутий http://server/repo -u 1.5

· створити репозиторій без наборів змін після певної редакції:

hg clone -r 04e544 експериментальний/ добре/

· клонувати (і відстежувати) певну іменовану гілку:

клон hg http://selenic.com/hg#стабільний

Читати hg допомога URL-адреси для отримання детальної інформації щодо визначення URL-адрес.

У разі успіху повертає 0.

варіанти:

-У, --noupdate
клон включатиме порожній робочий каталог (тільки репозиторій)

-у,--updaterev
редакція, тег або гілка для перевірки

-р,--rev
включити вказаний набір змін

-б,-філія
клонувати лише вказану гілку

--тягнути використовуйте протокол pull для копіювання метаданих

--нестиснутий
використовувати нестиснену передачу (швидко через локальну мережу)

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

commit
зафіксувати вказані файли або всі невиконані зміни:

hg commit [ОПЦІЯ]... [ФАЙЛ]...

Зафіксуйте зміни до даних файлів у сховищі. На відміну від централізованого SCM, це
Операція є локальною операцією. Подивитися hg штовхати для способу активного поширення ваших змін.

Якщо список файлів пропущено, усі зміни повідомляється hg статус буде здійснено.

Якщо ви фіксуєте результат злиття, не вказуйте жодних імен файлів або -I/-X
фільтри

Якщо повідомлення про фіксацію не вказано, Mercurial запускає ваш налаштований редактор, де ви можете
введіть повідомлення. У разі невдачі вашої фіксації ви знайдете резервну копію свого повідомлення
.hg/last-message.txt.

Прапор --close-branch можна використовувати для позначення поточної головки гілки закритою. Коли всі голови
філії закриті, філія вважатиметься закритою і більше не входить до списку.

Прапор --amend можна використовувати, щоб змінити батьківський каталог робочого каталогу за допомогою нового
фіксація, яка містить зміни в батьківському елементі на додаток до тих, про які зараз повідомляє
hg статус, якщо такі є. Старий коміт зберігається в резервному пакеті в
.hg/strip-backup (Див. hg допомога пакет та hg допомога роз’єднати про те, як його відновити).

Повідомлення, користувач і дата беруться зі зміненого коміту, якщо не вказано. Коли повідомлення
не вказано в командному рядку, редактор відкриється з повідомленням про зміни
вчинити.

Неможливо змінювати загальнодоступні набори змін (див hg допомога фаз) або набори змін, які мають
дітей.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Повертає 0 у разі успіху, 1, якщо нічого не змінилося.

Приклади:

· зафіксувати всі файли, які закінчуються на .py:

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

· зафіксувати всі небінарні файли:

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

· внести зміни до поточного коміту та встановити дату зараз:

hg commit --amend --date зараз

варіанти:

-A, --addremove
перед фіксацією позначте нові/відсутні файли як додані/видалені

--ближне відділення
позначте головку гілки як закриту

--виправити
внести зміни до батьківського каталогу робочого каталогу

-так, -- секрет
використовуйте секретну фазу для фіксації

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-я, --інтерактивні
використовувати інтерактивний режим

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

псевдоніми: ci

конфиг
показати комбіновані налаштування конфігурації з усіх файлів hgrc:

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

Без аргументів друкуйте імена та значення всіх елементів конфігурації.

За допомогою одного аргументу форми section.name надрукуйте лише значення цього елемента конфігурації.

З кількома аргументами друкуйте імена та значення всіх елементів конфігурації з відповідним розділом
імена.

За допомогою --edit запустіть редактор у файлі конфігурації на рівні користувача. За допомогою --global відредагуйте файл
загальносистемний конфігураційний файл. За допомогою --local відредагуйте файл конфігурації на рівні репозитарію.

За допомогою --debug джерело (назва файлу та номер рядка) друкується для кожного елемента конфігурації.

Читати hg допомога конфиг для отримання додаткової інформації про файли конфігурації.

Повертає 0 у разі успіху, 1, якщо NAME не існує.

варіанти:

-у, --ненадійний
показати ненадійні параметри конфігурації

-е, --редагувати
редагувати конфігурацію користувача

-л, --місцевий
редагувати конфігурацію репозиторію

-g, --глобальний
редагувати глобальну конфігурацію

псевдоніми: showconfig debugconfig

скопіювати
позначити файли як скопійовані для наступного коміту:

hg copy [OPTION]... [ДЖЕРЕЛО]... ЦІЛЬ

Позначте dest як копії вихідних файлів. Якщо dest є каталогом, копії поміщаються в нього
каталог. Якщо dest є файлом, джерелом має бути один файл.

За замовчуванням ця команда копіює вміст файлів у тому вигляді, в якому вони існують у робочому
каталог. Якщо викликати за допомогою -A/--after, операція записується, але копіювання не відбувається
виконується.

Ця команда набуває чинності з наступним комітом. Щоб скасувати копію перед цим, див hg повернути.

Повертає 0 в разі успіху, 1, якщо зустрічаються помилки.

варіанти:

-A, --після
записати копію, яка вже відбулася

-f, --сила
примусово скопіювати наявний керований файл

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

Позначений [+] параметр можна вказати кілька разів

псевдоніми: cp

різниця
репозиторій diff (або вибрані файли):

hg diff [ПАРАМЕТР]... ([-c REV] | [-r REV1 [-r REV2]]) [ФАЙЛ]...

Показати відмінності між версіями для вказаних файлів.

Відмінності між файлами відображаються за допомогою уніфікованого формату diff.

примітки hg різниця може генерувати несподівані результати для злиття, оскільки за замовчуванням буде порівнюватися
проти першого батьківського набору змін робочого каталогу, якщо немає ревізій
вказано.

Якщо вказано два аргументи редакції, то зміни відображаються між цими редакціями. Якщо
вказана лише одна редакція, тоді ця редакція порівнюється з робочим каталогом,
і, якщо ревізії не вказані, файли робочого каталогу порівнюються з його
перший батько.

Крім того, ви можете вказати -c/--change з редакцією, щоб побачити зміни в цьому
набір змін відносно його першого батька.

Без параметра -a/--text, diff уникає створення відмінностей файлів, які він виявляє
двійковий. За допомогою -a diff все одно створить diff, ймовірно, з небажаними результатами.

Використовуйте параметр -g/--git, щоб генерувати відмінності у розширеному форматі diff git. Для більш
інформацію, читайте hg допомога відрізняється.

Приклади:

· порівняти файл у поточному робочому каталозі з його батьківським:

hg diff foo.c

· порівняти дві історичні версії каталогу з інформацією про перейменування:

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

· отримати статистику змін щодо останньої зміни на певну дату:

hg diff --stat -r "дата ('2 травня')"

· розрізняти всі щойно додані файли, які містять ключове слово:

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

· порівняти ревізію та її батьків:

hg diff -c 9353 # порівняти з першим батьком
hg diff -r 9353^:9353 # те саме з використанням синтаксису revset
hg diff -r 9353^2:9353 # порівняти з другим батьком

У разі успіху повертає 0.

варіанти:

-р,--rev
перегляд

-c,--зміна
зміна, внесена шляхом перегляду

-а, --текст
розглядати всі файли як текст

-g, --git
використовуйте розширений формат git diff

-- вузли
пропускати дати із заголовків diff

--непрефікс
опустити префікси a/ і b/ з імен файлів

-p, --показувати функцію
показати, до якої функції відноситься кожна зміна

--зворотний
створити diff, який скасовує зміни

-w, --ігнорувати-все-пробіл
ігноруйте пробіл під час порівняння рядків

-б, --ignore-space-change
ігнорувати зміни в кількості пробілів

-Б, --ignore-blank-lines
ігнорувати зміни, усі рядки яких порожні

-У,--уніфікований
кількість рядків контексту для відображення

--стат вивести підсумок змін у стилі diffstat

--корінь
створювати відмінності щодо підкаталогу

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

експорт
дамп заголовка та відмінностей для одного або кількох наборів змін:

hg експорт [ОПЦІЯ]... [-o OUTFILESPEC] [-r] [REV]...

Роздрукуйте заголовок набору змін і відмінності для однієї чи кількох ревізій. Якщо перегляд не надано,
використовується батьківський каталог робочого каталогу.

Інформація, яка відображається в заголовку набору змін: автор, дата, назва філії (якщо
не за замовчуванням), хеш набору змін, батьківський(и) коментар(и) та коментар.

примітки hg експорт може генерувати неочікуваний вихід diff для об’єднаних наборів змін, як і буде
порівняти лише набір змін об’єднання з його першим батьківським.

Вихід може бути у файлі, у цьому випадку ім’я файлу задається за допомогою формату
рядок. Правила форматування такі:

%%

буквальний символ "%".

%H

хеш змін (40 шістнадцяткових цифр)

%N

кількість створюваних патчів

%R

номер редакції набору змін

%b

базове ім'я експортованого репозиторію

%h

короткий хеш набору змін (12 шістнадцяткових цифр)

%m

перший рядок повідомлення про фіксацію (лише буквено-цифрові символи)

%n

порядковий номер із нульовим доповненням, починаючи з 1

%r

номер редакції набору змін із нульовим доповненням

Без параметра -a/--text експорт дозволить уникнути генерування відмінностей файлів, які він виявляє
двійковий. За допомогою -a експорт у будь-якому випадку створить відмінність, ймовірно, з небажаними результатами.

Використовуйте параметр -g/--git, щоб створити відмінності у розширеному форматі diff git. Подивитися hg допомога
відрізняється для отримання додаткової інформації.

З опцією --switch-parent різниця буде протистояти другому батьківському. Це може бути
корисно переглянути злиття.

Приклади:

· використовуйте експорт та імпорт, щоб пересадити виправлення помилки в поточну гілку:

hg експорт -r 9353 | імпорт hg -

· експортувати всі набори змін між двома версіями до файлу з інформацією про перейменування:

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

· розділити вихідні зміни на серію патчів з описовими іменами:

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

У разі успіху повертає 0.

варіанти:

-о,- вихід
роздрукувати вихід у файл із відформатованим ім'ям

--перемикач-батька
відмінність від другого батька

-р,--rev
редакції для експорту

-а, --текст
розглядати всі файли як текст

-g, --git
використовуйте розширений формат git diff

-- вузли
пропускати дати із заголовків diff

Позначений [+] параметр можна вказати кілька разів

файли
список відстежуваних файлів:

файли hg [ВАРІАНТ]... [ШАБЛОН]...

Роздрукуйте файли під керуванням Mercurial у робочому каталозі або вказаній версії якої
імена відповідають заданим шаблонам (за винятком видалених файлів).

Якщо шаблони не збігаються, ця команда друкує назви всіх файлів
Меркурійний контроль у робочому довіднику.

Приклади:

· перелік усіх файлів у поточному каталозі:

hg файли.

· показує розміри та позначки для поточної версії:

hg файли -vr .

· перелік усіх файлів з іменем README:

файли hg -I "**/README"

· перелік усіх бінарних файлів:

hg файли "set:binary()"

· знайти файли, що містять регулярний вираз:

файли hg "set:grep('bob')"

· пошук вмісту відстежуваного файлу за допомогою xargs і grep:

файли hg -0 | xargs -0 grep foo

Читати hg допомога моделі та hg допомога набори файлів для отримання додаткової інформації щодо визначення файлу
моделі.

Повертає 0, якщо збіг знайдено, 1 — інакше.

варіанти:

-р,--rev
пошук у сховищі, як він є в REV

-0, --друк0
кінцеві імена файлів з NUL, для використання з xargs

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

забувати
забудьте вказані файли під час наступного коміту:

hg забути [ПАРАЦІЯ]... ФАЙЛ...

Позначте вказані файли, щоб вони більше не відстежувалися після наступного коміту.

Це видаляє файли лише з поточної гілки, а не з усієї історії проекту
він не видаляє їх із робочого каталогу.

Щоб видалити файл із робочого каталогу, див hg видаляти.

Щоб скасувати забуття перед наступним комітом, див hg додавати.

Приклади:

· забудьте щойно додані двійкові файли:

hg забудьте "set:added() і binary()"

· забудьте файли, які були б виключені .hgignore:

hg забути "set:hgignore()"

У разі успіху повертає 0.

варіанти:

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

трансплантат
копіювати зміни з інших гілок до поточної гілки:

hg трансплантат [ВАРИАНТ]... [-r REV]... REV...

Ця команда використовує логіку злиття Mercurial для копіювання окремих змін з інших гілок
без злиття гілок в графі історії. Це іноді називають «бекпортуванням» або
«збір вишні». За замовчуванням graft копіює користувача, дату та опис з джерела
набори змін.

Набори змін, які є предками поточної редакції, які вже були щеплені, або
які є злиттями, буде пропущено.

Якщо вказано --log, до повідомлень журналу буде додано коментар у формі:

(щеплено з CHANGESETHASH)

Якщо вказано --force, ревізії будуть прищеплені, навіть якщо вони вже є предками
або були прищеплені до місця призначення. Це корисно, коли переглянуті зміни
було відсторонено.

Якщо злиття прищеплень призводить до конфліктів, процес трансплантації переривається так, що
поточне злиття можна вирішити вручну. Після того, як усі конфлікти будуть вирішені, підкуп
процес можна продовжити за допомогою параметра -c/--continue.

Примітка. Опція -c/--continue не застосовує повторно попередні параметри, за винятком --force.

Приклади:

· скопіюйте одну зміну в стабільну гілку та відредагуйте її опис:

стабільне оновлення hg
hg трансплантат --редагувати 9393

· прищепити діапазон наборів змін за одним винятком, оновлюючи дати:

hg graft -D "2085::2093, а не 2091"

· продовжувати прищеплення після вирішення конфліктів:

hg трансплантат -c

· показати джерело прищепленого набору змін:

hg log --debug -r .

· показати редакції, відсортовані за датою:

hg log -r 'сортувати (усі(), дата)'

Читати hg допомога перегляди та hg допомога ревсець для отримання додаткової інформації про внесення змін.

Повертає 0 після успішного завершення.

варіанти:

-р,--rev
ревізії до щеплення

-c, --продовжити
відновити перервану трансплантацію

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-- журнал додати інформацію про щеплення до повідомлення журналу

-f, --сила
силовий трансплантат

-Д, --Поточна дата
записати поточну дату як дату фіксації

-У, --поточний користувач
записати поточного користувача як комітера

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

-t,--інструмент
вказати інструмент об’єднання

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

Позначений [+] параметр можна вказати кілька разів

GREP
шукайте шаблон у визначених файлах і редакціях:

hg grep [ПАРАЦІЯ]... ШАБЛОН [ФАЙЛ]...

Пошук регулярних виразів у версіях файлів.

Ця команда веде себе інакше, ніж Unix grep. Він приймає лише регулярні вирази Python/Perl. Це
шукає історію сховища, а не робочий каталог. Він завжди друкує редакцію
номер, у якому збігається.

За замовчуванням grep друкує лише вихідні дані для першої версії файлу, в якому він знаходить a
матч. Щоб змусити його друкувати кожну версію, яка містить зміну статусу відповідності ("-" для a
відповідність, яка стає невідповідною, або «+» для невідповідності, яка стає збігом), використовуйте
--усі прапор.

Повертає 0, якщо збіг знайдено, 1 — інакше.

варіанти:

-0, --друк0
кінцеві поля з NUL

--все надрукувати всі відповідні редакції

-а, --текст
розглядати всі файли як текст

-f, -- слідувати
слідкуйте за історією набору змін або історією файлів між копіями та перейменуваннями

-я, --ігнорувати регістр
ігнорувати регістр при збігу

-л, --файли-зі збігами
друкувати лише відповідні назви файлів і редакції

-n, --номер рядка
надрукувати відповідні номери рядків

-р,--rev
лише файли пошуку змінено в межах діапазону редакцій

-у, --користувач
вказати автора (довго з -v)

-d, --дата
перелік дати (коротко з -q)

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

голови
показати голови гілок:

hg heads [-ct] [-r ПОЧАТКІВ] [РЕВ]...

Без аргументів показати всі відкриті заголовки гілок у сховищі. Головки гілок є
набори змін, які не мають нащадків у тій самій гілці. Вони там, де розвиток
зазвичай має місце і є звичайними цілями для операцій оновлення та злиття.

Якщо надано один або кілька REV, відкривайте лише головки гілок на гілках, пов’язаних з
відображаються вказані набори змін. Це означає, що ви можете використовувати hg голови . щоб побачити голови
філію, яку зараз виписують.

Якщо вказано -c/--closed, також показувати головки гілок, позначені як закриті (див hg commit
--ближне відділення).

Якщо вказано STARTREV, будуть лише ті голови, які є нащадками STARTREV
відображається.

Якщо вказано -t/--topo, іменована механіка гілок буде проігнорована і буде лише топологічна
відображатимуться заголовки (набори змін без дітей).

Повертає 0, якщо відповідні заголовки знайдено, 1, якщо ні.

варіанти:

-р,--rev
показувати лише голови, які є нащадками STARTREV

-t, --топо
показувати лише топологічні головки

-а, --активний
показати лише активні філії (ЗАСТАРЕЛО)

-c, --зачинено
показують нормальні та закриті головки гілок

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

допомога
показати довідку для певної теми або огляд довідки:

hg help [-ecks] [ТЕМА]

Без аргументів роздрукуйте список команд з короткими довідковими повідомленнями.

Враховуючи назву теми, розширення або команди, надрукуйте довідку для цієї теми.

У разі успіху повертає 0.

варіанти:

-е, --розширення
показувати лише довідку щодо розширень

-c, -- команда
показувати лише довідку для команд

-к, --ключове слово
показати теми, що відповідають ключовому слову

-так,--система
показати довідку для певних платформ

Позначений [+] параметр можна вказати кілька разів

ідентифікувати
визначити робочий каталог або вказану редакцію:

hg identify [-nibtB] [-r REV] [ДЖЕРЕЛО]

Надрукуйте підсумок, що ідентифікує стан сховища в REV, використовуючи один або два батьківських хеш
ідентифікатори, за якими слід «+», якщо робочий каталог має незафіксовані зміни, the
ім'я гілки (якщо не за замовчуванням), список тегів і список закладок.

Якщо REV не вказано, надрукуйте підсумок поточного стану сховища.

Якщо вказати шлях до кореня репозиторію або пакета Mercurial, буде працювати пошук
цей репозиторій/пакет.

Приклади:

· згенерувати ідентифікатор збірки для робочого каталогу:

hg id --id > build-id.dat

· знайти ревізію, що відповідає тегу:

hg id -n -r 1.3

· перевірити останню версію віддаленого сховища:

hg id -r підказка http://selenic.com/hg/

Читати hg журнал для отримання додаткової інформації про конкретні редакції, включаючи повний хеш
ідентифікатори.

У разі успіху повертає 0.

варіанти:

-р,--rev
визначити вказану редакцію

-n, --кількість
показати місцевий номер версії

-я, --id
показати глобальний ідентифікатор редакції

-б, -філія
показати відділення

-t, -теги
показати теги

-Б, -- закладки
показати закладки

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

псевдоніми: id

імпорт
імпортувати впорядкований набір патчів:

імпорт hg [ПАРАЦІЯ]... ВИПЛАННЯ...

Імпортуйте список виправлень і зафіксуйте їх окремо (якщо не вказано --no-commit).

Щоб прочитати патч зі стандартного введення, використовуйте «-» як назву патча. Якщо вказано URL-адресу,
патч буде завантажено звідти.

Імпорт спочатку застосовує зміни до робочого каталогу (якщо не вказано --bypass),
імпорт буде припинено, якщо є нездійснені зміни.

Використовуйте --bypass, щоб застосувати та зафіксувати виправлення безпосередньо до сховища, не впливаючи на
робочий каталог. Без --exact патчі будуть застосовані поверх робочого
батьківська версія каталогу.

Ви можете імпортувати виправлення прямо з поштового повідомлення. Навіть патчі як вкладення працюють (до
використовуйте частину тіла, вона повинна мати тип text/plain або text/x-patch). Заголовки «Від» і «Тема».
повідомлення електронної пошти використовуються як комітер за замовчуванням і повідомлення фіксації. Весь текст/звичайний текст
частини перед першим diff додаються до повідомлення фіксації.

Якщо імпортований патч був згенерований за допомогою hg експорт, користувач і опис із заміни виправлення
значення із заголовків і тіла повідомлення. Значення, наведені в командному рядку за допомогою -m/--повідомлення та
-u/--користувач замінює ці.

Якщо вказано --exact, імпорт встановить робочий каталог як батьківський для кожного виправлення
перед його застосуванням, і буде скасовано, якщо результуючий набір змін має інший ідентифікатор
один, записаний у патчі. Це може статися через проблеми з набором символів або інші
недоліки у форматі текстового патча.

Використовуйте --partial, щоб переконатися, що набір змін буде створений із виправлення, навіть якщо деякі шматочки не вдасться
подавати заяву. Ханки, які не подали заявку, будуть записані до a .rej файл. Конфлікти
потім можна вирішити вручну раніше hg commit --виправити запускається для оновлення створеного
набір змін. Цей прапорець існує, щоб дозволити людям імпортувати патчі, які частково застосовуються без них
втрата пов’язаних метаданих (автор, дата, опис, ...).

Примітка. Якщо жодних шматків не наноситься чисто, hg імпорт --частковий створить порожній набір змін,
імпортування лише метаданих виправлення.

За допомогою -s/--подібності hg намагатиметься знайти перейменування та копії у патчі в
так само, як hg видалення адреси.

Для виконання виправлення можна використовувати зовнішні програми виправлення, встановивши параметр ui.patch
варіант конфігурації. Для внутрішнього інструменту за замовчуванням fuzz також можна налаштувати за допомогою
patch.fuzz, Побачити hg допомога конфиг для отримання додаткової інформації про файли конфігурації та як це зробити
скористайтеся цими параметрами.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Приклади:

· імпортувати традиційний патч із веб-сайту та виявляти перейменування:

hg імпорт -s 80 http://example.com/bugfix.patch

· імпортувати набір змін із сервера hgweb:

імпорт hg http://www.selenic.com/hg/rev/5ca8c111e9aa

· імпортувати всі патчі в mbox у стилі Unix:

hg імпорту incoming-patches.mbox

· спроба точно відновити експортований набір змін (не завжди можливо):

hg import --exact offers-fix.patch

· використовувати зовнішній інструмент, щоб застосувати патч, який є занадто нечітким для внутрішнього інструменту за замовчуванням.

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

· змінити фаззінг за замовчуванням з 2 на менш суворий 7

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

Повертає 0 при успіху, 1 при частковому успіху (див. --partial).

варіанти:

-p,--смужка
параметр смуги каталогів для виправлення. Це має те саме значення, що й відповідне
параметр виправлення (за замовчуванням: 1)

-б,--база
базовий шлях (НЕ РЕКОМЕНДУЄТЬСЯ)

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-f, --сила
пропустити перевірку на наявність незавершених змін (ЗАСТАРЕЛО)

--без фіксації
не фіксуйте, просто оновіть робочий каталог

--обхід
застосувати патч, не торкаючись робочого каталогу

--частковий
здійснюйте, навіть якщо деякі шматки зазнають невдачі

--точні
застосувати виправлення до вузлів, з яких він був створений

--префікс
застосувати патч до підкаталогу

--імпорт-філія
використовувати будь-яку інформацію про гілки в патчі (на увазі --exact)

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

-так,-подібність
вгадати перейменовані файли за схожістю (0<=s<=100)

псевдоніми: патч

що входить
показати нові набори змін, знайдені в джерелі:

hg вхідний [-p] [-n] [-M] [-f] [-r REV]... [--bundle НАЗВА ФАЙЛУ] [ДЖЕРЕЛО]

Показати нові набори змін, знайдені у вказаному шляху/URL-адресі або в розташуванні за замовчуванням. Ці
– це набори змін, які було б витягнуто, якби витягнення було здійснено в той час, коли ви це видали
команда

Див. pull для отримання інформації про дійсний вихідний формат.

За допомогою -B/--закладок, результат порівняння закладок між локальними та віддаленими
відображається репозиторії. За допомогою -v/--verbose статус також відображається для кожної закладки
як нижче:

BM1 01234567890a додано
BM2 1234567890ab Advanced
BM3 234567890abc розійшовся
BM4 34567890abcd змінено

Дія, що виконується локально під час витягування, залежить від статусу кожної закладки:

доданий

pull створить його

просунутий

pull оновить його

розходяться

pull створить розбіжну закладку

змінилися

результат залежить від віддалених наборів змін

З точки зору тягової поведінки, закладка існує тільки в пульті
репозиторій розглядаються як доданий, навіть якщо він фактично видалено локально.

Для віддаленого сховища використання --bundle дозволяє уникнути подвійного завантаження наборів змін
вхідне супроводжується витягуванням.

Приклади:

· показати вхідні зміни з виправленнями та повним описом:

hg вхідний -vp

· показувати вхідні зміни, за винятком злиття, зберігати пакет:

hg в -vpM --bundle incoming.hg
hg потягнути вхідний.hg

· короткий список змін всередині пакета:

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

Повертає 0, якщо є вхідні зміни, 1 – інакше.

варіанти:

-f, --сила
запускати, навіть якщо віддалений репозиторій не пов’язаний

-n, --найновіший-перший
спочатку показати найновіший запис

-- пучок
файл для зберігання пакетів

-р,--rev
віддалений набір змін, який планується додати

-Б, -- закладки
порівняти закладки

-б,-філія
конкретну гілку, яку ви хотіли б потягнути

-p, --патч
показати патч

-g, --git
використовуйте розширений формат git diff

-л,--ліміт
обмежити кількість відображених змін

-М, --без злиття
не показувати злиття

--стат вивести підсумок змін у стилі diffstat

-G, --граф
показати ревізію DAG

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

псевдоніми: в

ініціалізації
створити нове сховище у вказаному каталозі:

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

Ініціалізуйте нове сховище у вказаному каталозі. Якщо вказаний каталог не існує,
воно буде створено.

Якщо каталог не вказано, використовується поточний каталог.

Можна вказати ssh:// URL як цільовий. Подивитися hg допомога URL-адреси більше
інформація.

У разі успіху повертає 0.

варіанти:

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

розмістити
знайти файли, які відповідають певним шаблонам (ЗАСТАРІЛО):

hg знайти [ПАРАЦІЯ]... [ШАБЛОН]...

Роздрукуйте файли під керуванням Mercurial у робочому каталозі, імена яких відповідають заданому
моделі.

За замовчуванням ця команда шукає всі каталоги в робочому каталозі. Щоб просто шукати
поточного каталогу та його підкаталогів, використовуйте "--include .".

Якщо шаблони не збігаються, ця команда друкує назви всіх файлів
Меркурійний контроль у робочому довіднику.

Якщо ви хочете передати результат цієї команди в команду "xargs", використовуйте параметр -0
як для цієї команди, так і для "xargs". Це дозволить уникнути проблеми "xargs" лікування одиночних
імена файлів, які містять пробіли як кілька імен файлів.

Читати hg допомога файли для більш універсальної команди.

Повертає 0, якщо збіг знайдено, 1 — інакше.

варіанти:

-р,--rev
пошук у сховищі, як він є в REV

-0, --друк0
кінцеві імена файлів з NUL, для використання з xargs

-f, --повний шлях
друкувати повні шляхи з кореня файлової системи

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

журнал
показати історію переглядів усього сховища або файлів:

журнал hg [ОПЦІЯ]... [ФАЙЛ]

Роздрукуйте історію переглядів вказаних файлів або всього проекту.

Якщо діапазон ревізій не вказано, значення за замовчуванням підказка: 0 якщо не встановлено параметр --follow, у якому
якщо батьківський робочий каталог використовується як початкова версія.

Історія файлів відображається без перейменування чи копіювання історії файлів. Використовуйте -f/--follow
з іменем файлу, щоб стежити за історією перейменування та копій. --follow без імені файлу
показуватиме лише предків або нащадків початкової редакції.

За замовчуванням ця команда друкує номер версії та ідентифікатор набору змін, теги, нетривіальні
батьки, користувач, дата і час, а також підсумок для кожного коміта. Коли перемикач -v/--verbose
використовується, відображається список змінених файлів і повне повідомлення про фіксацію.

За допомогою --graph редакції відображаються як DAG ASCII з найновішими змінами
Топ. «o» — це набір змін, «@» — робочий батьківський каталог, «x» застарів, а «+»
представляє розгалуження, де набір змін із рядків нижче є батьківським елементом злиття 'o'
та сама лінія.

примітки hg журнал --патч може генерувати неочікуваний вихід diff для об’єднаних наборів змін, як і буде
лише порівняти набір змін злиття з його першим батьківським. Крім того, тільки файли
відмінні від ОБІХ батьків з'являться у файлах:.

Примітка. З міркувань продуктивності hg журнал Фото може пропускати повторювані зміни, внесені до філій
і не відображатиме видалення чи зміни режиму. Щоб побачити всі такі зміни, скористайтеся
--вилучений перемикач.

Приклади:

· набори змін з повними описами та списками файлів:

hg log -v

· набори змін, які передують робочому каталогу:

hg log -f

· останні 10 комітів на поточній гілці:

hg log -l 10 -b .

· набори змін, що показують усі модифікації файлу, включаючи видалення:

hg log --видалений файл.c

· усі набори змін, які торкаються каталогу, з відмінностями, за винятком об'єднань:

hg log -Mp lib/

· всі номери ревізій, які відповідають ключовому слову:

hg log -k помилка --template "{rev}\n"

· повний хеш-ідентифікатор батьківського робочого каталогу:

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

· перелік доступних шаблонів журналів:

hg log -T список

· перевірте, чи включено даний набір змін у випуск із тегами:

hg log -r "a21ccf і предок (1.9)"

· знайти всі набори змін певним користувачем у діапазоні дат:

hg log -k alice -d "з травня 2008 року по липень 2008 року"

· підсумок усіх змін після останнього тегу:

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

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Читати hg допомога перегляди та hg допомога ревсець для отримання додаткової інформації про уточнення та замовлення
ревізії.

Читати hg допомога Шаблони для отримання додаткової інформації про попередньо запаковані стилі та визначення користувацьких шаблонів.

У разі успіху повертає 0.

варіанти:

-f, -- слідувати
слідкуйте за історією набору змін або історією файлів між копіями та перейменуваннями

-- слідувати першим
слідувати лише за першим батьком наборів змін для злиття (ЗАСТАРЕЛО)

-d,--дата
показати редакції, що відповідають даті спец

-C, -- копії
показати скопійовані файли

-к,--ключове слово
здійснювати пошук заданого тексту без урахування регістру

-р,--rev
показати вказану редакцію або скидання

-- видалено
включити редакції, де файли були видалені

-м, --лише-злиття
показувати лише злиття (ЗАСТАРЕЛО)

-у,--користувач
редакції, внесені користувачем

--тільки-філія
показувати лише набори змін у межах даної іменованої гілки (ЗАСТАРЕЛО)

-б,-філія
показати набори змін у вказаній гілці

-П,-- чорнослив
не відображати редакцію або будь-кого з його предків

-p, --патч
показати патч

-g, --git
використовуйте розширений формат git diff

-л,--ліміт
обмежити кількість відображених змін

-М, --без злиття
не показувати злиття

--стат вивести підсумок змін у стилі diffstat

-G, --граф
показати ревізію DAG

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

псевдоніми: історія

проявляється
вивести поточну або задану редакцію маніфесту проекту:

маніфест hg [-r REV]

Надрукуйте список файлів, які контролюються версіями для даної версії. Якщо перегляд не надано,
використовується перший батьківський каталог робочого каталогу або нульова версія, якщо ревізії немає
перевірено.

За допомогою -v дозволи друку файлів, символьне посилання та виконувані біти. За допомогою --debug роздрукуйте файл
хеші редакції.

Якщо вказано параметр --all, надрукується список усіх файлів з усіх версій. Це
включає видалені та перейменовані файли.

У разі успіху повертає 0.

варіанти:

-р,--rev
редакція для відображення

--все список файлів з усіх версій

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

злиття
об'єднати іншу ревізію в робочий каталог:

hg злиття [-P] [[-r] REV]

Поточний робочий каталог оновлюється з усіма змінами, внесеними в запитувану редакцію
з моменту останнього загального попередника.

Файли, які змінилися між одним із батьків, позначаються як змінені для наступного коміту та a
фіксація має бути виконана до того, як будуть дозволені будь-які подальші оновлення репозиторію. The
наступний комміт матиме двох батьків.

--інструмент можна використовувати для визначення інструмента злиття, який використовується для злиття файлів. Він перевизначає
Змінна середовища HGMERGE та ваші файли конфігурації. Подивитися hg допомога інструменти злиття та цінності
Варіанти.

Якщо ревізія не вказана, батьківська версія робочого каталогу є головною версією, а файл
поточна гілка містить рівно одну іншу головку, інша заголовок об’єднана з нею за замовчуванням.
В іншому випадку необхідно надати явну редакцію, з якою потрібно об’єднатися.

Читати hg допомога рішення для отримання інформації про обробку конфліктів файлів.

Щоб скасувати незафіксоване злиття, використовуйте hg оновлення --чистий . який перевірить чисту копію
вихідний батьківський елемент злиття, втративши всі зміни.

Повертає 0 у разі успіху, 1, якщо є нерозв’язані файли.

варіанти:

-f, --сила
примусово об’єднати, включаючи невиконані зміни (ЗАСТАРЕЛО)

-р,--rev
редакція для злиття

-П, -- попередній перегляд
переглянути редакції для злиття (злиття не виконується)

-t,--інструмент
вказати інструмент об’єднання

вихідний
показати набори змін, не знайдені в місці призначення:

hg вихідний [-M] [-p] [-n] [-f] [-r REV]... [ЦІЛЬ]

Показати набори змін, не знайдені у зазначеному цільовому сховищі або натисканні за замовчуванням
Місцезнаходження. Це набори змін, які будуть передані, якби було запитано натискання.

Докладнішу інформацію про дійсні формати призначення див.

За допомогою -B/--закладок, результат порівняння закладок між локальними та віддаленими
відображається репозиторії. За допомогою -v/--verbose статус також відображається для кожної закладки
як нижче:

BM1 01234567890a додано
BM2 видалено
BM3 234567890abc Advanced
BM4 34567890abcd розійшовся
BM5 4567890abcde змінено

Дія, що виконується під час натискання, залежить від статусу кожної закладки:

доданий

штовхати з -B створить його

видалено

штовхати з -B видалить його

просунутий

push оновить його

розходяться

штовхати з -B оновить його

змінилися

штовхати з -B оновить його

З точки зору поведінки натискання, закладки існують тільки в пульті
репозиторій розглядаються як видалено, навіть якщо він фактично додається віддалено.

Повертає 0, якщо є вихідні зміни, 1 – інакше.

варіанти:

-f, --сила
виконувати, навіть якщо призначення не пов’язане

-р,--rev
набір змін, призначений для включення в пункт призначення

-n, --найновіший-перший
спочатку показати найновіший запис

-Б, -- закладки
порівняти закладки

-б,-філія
конкретну гілку, яку ви хочете натиснути

-p, --патч
показати патч

-g, --git
використовуйте розширений формат git diff

-л,--ліміт
обмежити кількість відображених змін

-М, --без злиття
не показувати злиття

--стат вивести підсумок змін у стилі diffstat

-G, --граф
показати ревізію DAG

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

псевдоніми: out

батьки
показати батьків робочого каталогу або версії (ЗАСТАРЕЛО):

hg батьки [-r REV] [ФАЙЛ]

Надрукуйте батьківські версії робочого каталогу. Якщо редакція надається через -r/--rev, то
батьківська версія цієї редакції буде надрукована. Якщо вказано аргумент файлу, редакція в
який файл було змінено востаннє (перед редакцією робочого каталогу або аргументом до
--rev, якщо вказано) друкується.

Ця команда еквівалентна:

hg log -r "p1()+p2()" або
hg log -r "p1(REV)+p2(REV)" або
hg log -r "max(::p1() and file(FILE))+max(::p2() and file(FILE))" або
hg log -r "max(::p1(REV) і файл(FILE))+max(::p2(REV) and file(FILE))"

Читати hg резюме та hg допомога ревсець для пов'язаної інформації.

У разі успіху повертає 0.

варіанти:

-р,--rev
показати батькам зазначеної редакції

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

стежки
показати псевдоніми для віддалених сховищ:

hg шляхи [NAME]

Показати визначення символічного імені шляху NAME. Якщо назви не вказано, покажіть визначення всіх
доступні імена.

Параметр -q/--quiet пригнічує весь вихід під час пошуку NAME і показує лише шлях
назви при переліку всіх визначень.

Назви шляхів визначаються в розділі [paths] вашого конфігураційного файлу та в
/etc/mercurial/hgrc. Якщо запустити всередині сховища, .hg/hgrc також використовується.

Назви шляхів дефолт та за замовчуванням натиснути мають особливе значення. При виконанні поштовху або
витягування, вони використовуються як запасні, якщо не вказано розташування на
командний рядок. Коли за замовчуванням натиснути встановлено, він буде використовуватися для push і дефолт буде використовуватися
для витягування; інакше дефолт використовується як запасний варіант для обох. Під час клонування сховища,
джерело клону записується як дефолт in .hg/hgrc.

примітки дефолт та за замовчуванням натиснути застосовувати до всіх вхідних (напр hg що входить) і вихідний
(напр hg вихідний, hg e-mail та hg пакет) операції.

Читати hg допомога URL-адреси для отримання додаткової інформації.

У разі успіху повертає 0.

варіанти:

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

фаза
встановити або показати назву поточної фази:

фаза ртутного тиску [-p|-d|-s] [-f] [-r] [REV...]

Без аргументу показати назву фази поточної(их) версії(ів).

За допомогою одного з -p/--public, -d/--draft або -s/--secret змініть значення фази
зазначені редакції.

Якщо не вказано -f/--force, hg фаза не переміщає набір змін з нижчої фази до an
вища фаза. Фази впорядковані таким чином:

публічний < чернетка < таємний

Повертає 0 в разі успіху, 1, якщо деякі фази не можна змінити.

(Додаткову інформацію про концепцію фаз див hg допомога фаз.)

варіанти:

-p, --публічний
встановити фазу набору змін на загальнодоступну

-d, --чернетка
встановити фазу набору змін на чернетку

-так, -- секрет
встановити фазу набору змін у секретну

-f, --сила
дозволяє перемістити кордон назад

-р,--rev
цільовий перегляд

Позначений [+] параметр можна вказати кілька разів

тягнути
витягувати зміни з зазначеного джерела:

hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [ДЖЕРЕЛО]

Витягувати зміни з віддаленого сховища в локальне.

Це знаходить усі зміни зі сховища за вказаним шляхом або URL і додає їх до a
локальний репозиторій (поточний, якщо не вказано -R). За замовчуванням це не так
оновити копію проекту в робочому каталозі.

Скористайтесь hg що входить якщо ви хочете побачити, що було б додано від витягування в той час, коли ви
видав цю команду. Якщо ви потім вирішите додати ці зміни до сховища, ви повинні
використання hg тягнути -r X де X це останній набір змін у списку hg що входить.

Якщо SOURCE опущено, буде використаний шлях «за замовчуванням». Подивитися hg допомога URL-адреси більше
інформація.

Повертає 0 у разі успіху, 1, якщо оновлення містило нерозв’язані файли.

варіанти:

-у, --оновити
оновити до нової головки гілки, якщо були вилучені набори змін

-f, --сила
запускати, навіть якщо віддалений репозиторій не пов’язаний

-р,--rev
віддалений набір змін, який планується додати

-Б,-- закладка
закладка, щоб витягнути

-б,-філія
конкретну гілку, яку ви хотіли б потягнути

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

штовхати
натиснути зміни до вказаного місця призначення:

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

Перенесіть набори змін з локального сховища до вказаного місця призначення.

Ця операція є симетричною для витягування: вона ідентична витягуванню в місці призначення
репозиторію з поточного.

За замовчуванням push не дозволить створювати нові заголовки в місці призначення, оскільки декілька
головок не буде зрозуміло, яку голову використовувати. У цій ситуації рекомендується
витягніть і злийте перед натисканням.

Використовуйте --new-branch, якщо ви хочете дозволити push створювати нову іменовану гілку, яка не є
присутні в місці призначення. Це дозволяє вам лише створити нову гілку без примусу
інші зміни.

Примітка. Необхідно бути особливо обережними з параметром -f/--force, який підштовхне все нове
голови на всіх гілках, дія, яка майже завжди викликає плутанину для
співробітники.

Якщо використовується -r/--rev, зазначена редакція та всі її предки будуть переміщені до
віддалений репозиторій.

Якщо використовується закладка -B/--закладка, зазначена версія з закладкою, її предки та
закладку буде переміщено до віддаленого сховища.

Див hg допомога URL-адреси для важливих подробиць про ssh:// URL-адреси. Якщо DESTINATION є
опущено, буде використовуватися шлях за замовчуванням.

Повертає 0, якщо натискання було успішним, 1, якщо нічого не натискати.

варіанти:

-f, --сила
силовий поштовх

-р,--rev
набір змін, призначений для включення в пункт призначення

-Б,-- закладка
закладка, щоб натиснути

-б,-філія
конкретну гілку, яку ви хочете натиснути

-- нове відділення
дозволити перемістити нову гілку

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

оговтуватися
відкат перерваної транзакції:

ртутний тиск відновлюється

Відновлення після перерваної фіксації або вилучення.

Ця команда намагається виправити стан сховища після перерваної операції. Це повинно бути
необхідна лише тоді, коли це пропонує Mercurial.

Повертає 0 у разі успіху, 1, якщо нічого не відновити чи перевірити.

видаляти
видаліть вказані файли під час наступного коміту:

hg видалити [ВАРІАНТ]... ФАЙЛ...

Заплануйте видалення вказаних файлів з поточної гілки.

Ця команда планує видалення файлів під час наступного коміту. Щоб скасувати видалення
перед цим див hg повернути. Щоб скасувати додані файли, див hg забувати.

-A/--after можна використовувати для видалення лише файлів, які вже були видалені, -f/--force можна
використовуватися для примусового видалення, а -Af можна використовувати для видалення файлів з наступної версії
не видаляючи їх із робочого каталогу.

У наступній таблиці детально описано поведінку видалення для різних станів файлів (стовпців) і
комбінації варіантів (рядки). Стан файлу: Додано [A], Очистити [C], Змінено [M] та
Відсутній [!] (за повідомленням hg статус). Дії: Попередити, Видалити (з гілки) та
Видалити (з диска):

┌──────────┬───┬────┬────┬────┐
│опція/стан │ A │ C │ M │ ! │
├───────────┼───┼────┼────┼───┤
│немає │ W │ RD │ W │ R │
├───────────┼───┼────┼────┼───┤
│-f │ R │ RD │ RD │ R │
├───────────┼───┼────┼────┼───┤
│-A │ W │ W │ W │ R │
├───────────┼───┼────┼────┼───┤
│-Af │ R │ R │ R │ R │
└───────────┴───┴────┴────┴───┘

примітки hg видаляти ніколи не видаляє файли в стані Added [A] з робочого каталогу, ні
навіть якщо --сила вказано.

Повертає 0 у разі успіху, 1, якщо зустрічаються якісь попередження.

варіанти:

-A, --після
видалення запису для відсутніх файлів

-f, --сила
видалити (і видалити) файл, навіть якщо він доданий або змінений

-S, --підтримка
повертатися в підрепозиторії

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

псевдоніми: rm

перейменувати
перейменувати файли; еквівалент копіювати + видалити:

hg перейменувати [ВАРІАНТ]... ДЖЕРЕЛО... ЦІЛЬ

Позначте dest як копії джерел; позначити джерела для видалення. Якщо dest — це каталог, копії
розміщені в цьому каталозі. Якщо dest є файлом, джерело може бути лише одне.

За замовчуванням ця команда копіює вміст файлів у тому вигляді, в якому вони існують у робочому
каталог. Якщо викликати за допомогою -A/--after, операція записується, але копіювання не відбувається
виконується.

Ця команда набуває чинності при наступному коміті. Щоб скасувати перейменування перед цим, див hg повернути.

Повертає 0 в разі успіху, 1, якщо зустрічаються помилки.

варіанти:

-A, --після
записати перейменування, яке вже відбулося

-f, --сила
примусово скопіювати наявний керований файл

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

Позначений [+] параметр можна вказати кілька разів

псевдоніми: move mv

рішення
повторити злиття або встановити/переглянути статус злиття файлів:

hg вирішити [ПАРАЦІЯ]... [ФАЙЛ]...

Злиття з невирішеними конфліктами часто є результатом неінтерактивного злиття з використанням
внутрішній: злиття налаштування конфігурації або інструмент злиття командного рядка, наприклад diff3. Рішучість
Команда використовується для керування файлами, які беруть участь у злитті після hg злиття було запущено, і
перед тим hg commit запущено (тобто робочий каталог повинен мати двох батьків). Подивитися hg допомога
інструменти злиття для отримання інформації про налаштування інструментів злиття.

Команду resolve можна використовувати наступними способами:

· hg рішення [--інструмент ІНСТРУМЕНТ] ФАЙЛ...: спроба повторно об'єднати вказані файли, відкидаючи
будь-які попередні спроби злиття. Повторне об’єднання не виконується для файлів, уже позначених як
вирішено. Використовуйте --усі/-a щоб вибрати всі нерозв’язані файли. --інструмент можна використовувати для вказівки
інструмент об’єднання, який використовується для даних файлів. Він замінює змінну середовища HGMERGE і
ваші файли конфігурації. Вміст попереднього файлу зберігається за допомогою a .orig суфікс.

· hg рішення -m [ФАЙЛ]: позначити файл як вирішений (наприклад, після вручну
виправив файли). За замовчуванням позначаються всі нерозв’язані файли.

· hg рішення -u [ФАЙЛ] ...: позначити файл як невирішений. За замовчуванням позначається все як вирішене
файли.

· hg рішення -l: список файлів, які мали чи все ще мають конфлікти. У друкованому списку, U =
невирішені і R = вирішено.

Примітка. Mercurial не дозволить вам зафіксувати файли з невирішеними конфліктами злиття. Ти повинен
використання hg рішення -m ... перед тим, як ви зможете здійснити фіксацію після конфліктного злиття.

Повертає 0 у разі успіху, 1, якщо спроба розв’язати файли не вдається.

варіанти:

-а, --все
виберіть усі нерозв’язані файли

-л, -- список
список стану файлів, які потребують злиття

-м, --позначка
позначити файли як вирішені

-у, -- зніміть позначку
позначити файли як невирішені

-n, --без статусу
приховати префікс статусу

-t,--інструмент
вказати інструмент об’єднання

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

Позначений [+] параметр можна вказати кілька разів

повернути
відновити файли до стану отримання:

hg revert [ПАРАМЕТР]... [-r REV] [ІМ'Я]...

Примітка. Щоб перевірити попередні версії, скористайтеся hg оновлення REV. Щоб скасувати ан
незафіксоване злиття (і втрата змін), використання hg оновлення --чистий ..

Якщо редакція не вказана, поверніть зазначені файли або каталоги до вмісту, який вони
було в батьківському робочому каталозі. Це відновлює вміст файлів до файлу
unmodified state та unschedules додає, видаляє, копіює та перейменовує. Якщо робочий
каталог має двох батьків, ви повинні явно вказати ревізію.

Використовуючи параметри -r/--rev або -d/--date, поверніть дані файли або каталоги до їх
станом на конкретну редакцію. Оскільки revert не змінює робочий каталог
батьки, це призведе до того, що ці файли виглядатимуть зміненими. Це може бути корисно для «відступу»
деякі або всі попередні зміни. Подивитися hg Повернись назад для спорідненого методу.

Перед поверненням змінені файли зберігаються із суфіксом .orig. Щоб вимкнути ці резервні копії,
використовувати --no-backup.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Читати hg допомога Повернись назад для способу скасувати дію попереднього набору змін.

У разі успіху повертає 0.

варіанти:

-а, --все
скасувати всі зміни, якщо аргументи не наведені

-d,--дата
дата відповідності найбільшої редакції

-р,--rev
повернутися до вказаної редакції

-C, --без резервного копіювання
не зберігайте резервні копії файлів

-я, --інтерактивні
інтерактивно виберіть зміни (ЕКСПЕРИМЕНТАЛЬНО)

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

Позначений [+] параметр можна вказати кілька разів

відміна
відкат останньої транзакції (НЕБЕЗПЕЧНО) (ЗАСТАРІЛО):

hg відкат

Будь ласка, використовуйте hg commit --виправити замість відкату для виправлення помилок в останньому коміті.

Цю команду слід використовувати обережно. Є тільки один рівень відкату, і є
неможливо скасувати відкат. Це також відновить dirstate на момент останнього
трансакцію, втративши будь-які зміни, що змінилися з того часу. Ця команда не змінює
робочий каталог.

Транзакції використовуються для інкапсуляції ефектів усіх команд, які створюють нові
набори змін або розповсюджувати наявні набори змін у сховище.

Наприклад, наведені нижче команди є транзакційними, і їх ефекти можна згорнути
назад:

· здійснити

· імпорт

· тягнути

· push (з цим репозиторієм як призначенням)

· роз’єднати

Щоб уникнути втрати даних назавжди, відкат відмовиться відкатувати транзакцію фіксації
не перевірено. Використовуйте --force, щоб скасувати цей захист.

Ця команда не призначена для використання у загальнодоступних сховищах. Після того, як зміни стануть видимими для
залучення інших користувачів, локальний відкат транзакції неефективний (хтось інший може
вже внесли зміни). Крім того, можлива гонка з читачами
сховище; наприклад, поточне витягування зі сховища може завершитися невдачею, якщо відбувається відкат
виконується.

Повертає 0 у разі успіху, 1, якщо дані відкату недоступні.

варіанти:

-n, --сушить
не виконувати дії, просто друкувати вихідні дані

-f, --сила
ігнорувати заходи безпеки

корінь
надрукувати корінь (верхню) поточного робочого каталогу:

ртутний корінь

Роздрукуйте кореневий каталог поточного сховища.

У разі успіху повертає 0.

служити
запустити автономний веб-сервер:

hg serve [ВАРІАНТ]...

Запустіть браузер локального репозиторію HTTP і витягніть сервер. Ви можете використовувати це для випадкового обміну
і перегляд сховищ. Рекомендується використовувати справжній веб-сервер для обслуговування a
репозиторій на тривалі періоди часу.

Зверніть увагу, що сервер не реалізує контроль доступу. Це означає, що шляхом
за замовчуванням будь-хто може читати з сервера, і ніхто не може писати на нього за замовчуванням. Встановіть
web.allow_push варіант до * дозволити всім натиснути на сервер. Ви повинні використовувати справжній
веб-сервер, якщо вам потрібно аутентифікувати користувачів.

За замовчуванням сервер реєструє доступ до stdout і помилки до stderr. Використовувати
Параметри -A/--accesslog і -E/--errorlog для входу до файлів.

Щоб сервер вибрав вільний номер порту для прослуховування, вкажіть номер порту 0; в
у цьому випадку сервер надрукує номер порту, який він використовує.

У разі успіху повертає 0.

варіанти:

-A,--журнал доступу
ім'я файлу журналу доступу для запису

-d, --демон
запустити сервер у фоновому режимі

--daemon-pipefds
використовується внутрішньо режимом демона

-Е,--errorlog
ім'я файлу журналу помилок для запису

-p,--порт
порт для прослуховування (за замовчуванням: 8000)

-а,--адреса
адреса для прослуховування (за замовчуванням: усі інтерфейси)

--префікс
префікс шлях для обслуговування (за замовчуванням: корінь сервера)

-n,--ім'я
ім'я для відображення на веб-сторінках (за замовчуванням: робочий каталог)

--web-conf
ім'я файлу конфігурації hgweb (див. "hg help hgweb")

--webdir-conf
ім'я файлу конфігурації hgweb (ЗАСТАРЕЛО)

--pid-файл
ім'я файлу для запису ідентифікатора процесу

--stdio
для віддалених клієнтів

--cmdserver
для віддалених клієнтів

-t,--шаблони
веб-шаблони для використання

-- стиль
стиль шаблону для використання

-6, --ipv6
використовувати IPv6 на додаток до IPv4

--сертифікат
Файл сертифіката SSL

статус
показати змінені файли в робочому каталозі:

статус hg [ОПЦІЯ]... [ФАЙЛ]...

Показати статус файлів у сховищі. Якщо вказано імена, то будуть лише відповідні файли
показано. Чисті чи ігноровані файли чи джерело операції копіювання/переміщення – ні
у списку, якщо не вказано -c/--clean, -i/--ігнорований, -C/--copies або -A/--все. Хіба що варіанти
описані з "показати тільки ...", використовуються параметри -mardu.

Опція -q/--quiet приховує файли, які не відстежуються (невідомі та ігноруються), якщо цього не вимагається явно
з -u/--невідомо або -i/--ігнорується.

примітки hg статус може здатися, що він не погоджується з diff, якщо дозволи були змінені або злиття
відбулося. Стандартний формат diff не повідомляє про зміни дозволів і diff
повідомляє лише про зміни щодо одного батьківського об’єднання.

Якщо вказана одна редакція, вона використовується як базова версія. Якщо надано дві редакції,
показані відмінності між ними. Параметр --change також можна використовувати як ярлик
щоб перерахувати змінені файли ревізії від її першого батьківського.

Для відображення статусу файлів використовуються такі коди:

M = змінений
А = додано
R = видалено
C = чистий
! = відсутня (видалено командою без hg, але все ще відстежується)
? = не відстежується
Я = проігноровано
= походження попереднього файлу (з --copies)

Приклади:

· показати зміни в робочому каталозі відносно набору змін:

статус hg --rev 9353

· показати зміни в робочому каталозі відносно поточного каталогу (див hg допомога
моделі для отримання додаткової інформації):

статус hg re:

· показати всі зміни, включаючи копії в існуючому наборі змін:

статус hg --копії --змінити 9353

· отримати розділений NUL список доданих файлів, придатних для xargs:

статус hg -an0

У разі успіху повертає 0.

варіанти:

-A, --все
показати статус усіх файлів

-м, --змінено
показувати лише змінені файли

-а, --додано
показувати лише додані файли

-р, -- видалено
показувати лише видалені файли

-d, --видалено
показувати лише видалені (але відстежені) файли

-c, --чистий
показувати лише файли без змін

-у, --невідомо
показувати лише невідомі (не відстежені) файли

-я, -- проігноровано
показувати лише ігноровані файли

-n, --без статусу
приховати префікс статусу

-C, -- копії
показати джерело скопійованих файлів

-0, --друк0
кінцеві імена файлів з NUL, для використання з xargs

--rev
показати відмінність від перегляду

--зміна
список змінених файлів ревізії

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-S, --підтримка
повертатися в підрепозиторії

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

Позначений [+] параметр можна вказати кілька разів

псевдоніми: вул

резюме
підсумуйте стан робочого каталогу:

hg резюме [--remote]

Це генерує короткий підсумок стану робочого каталогу, включаючи батьків, філію,
статус, етап і доступні оновлення.

За допомогою параметра --remote це перевірить шляхи за замовчуванням для вхідних та вихідних
зміни. Це може зайняти багато часу.

У разі успіху повертає 0.

варіанти:

-дистанційне
перевірити, чи не штовхають і тягнуть

псевдоніми: сум

тег
додати один або кілька тегів для поточної або даної редакції:

тег hg [-f] [-l] [-m ТЕКСТ] [-d ДАТА] [-u КОРИСТУВАЧ] [-r REV] НАЗВА...

Назвіть конкретну редакцію за допомогою .

Теги використовуються для назви окремих версій сховища і дуже корисні
порівнювати різні версії, щоб повернутися до значущих попередніх версій або позначити галузь
точки як випуски тощо. Зміна існуючого тегу зазвичай заборонена; використовувати -f/--force
перевизначити.

Якщо редакція не вказана, використовується батьківський каталог робочого каталогу.

Щоб полегшити контроль версій, розповсюдження та об’єднання тегів, вони зберігаються як a
файл під назвою ".hgtags", який керується аналогічно іншим файлам проекту і може бути
при необхідності відредагований вручну. Це також означає, що тегування створює новий коміт. Файл
".hg/localtags" використовується для локальних тегів (не спільно з сховищами).

Коміти тегів зазвичай робляться на голові філії. Якщо батьківський робочий
каталог не є керівником філії, hg тег переривання; використовуйте -f/--force, щоб змусити тег зафіксувати
бути заснованим на неголовному наборі змін.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Оскільки імена тегів мають пріоритет над іменами гілок під час пошуку ревізій, використовуючи наявний
Ім'я гілки як ім'я тегу не рекомендується.

У разі успіху повертає 0.

варіанти:

-f, --сила
тег сили

-л, --місцевий
зробити тег локальним

-р,--rev
редакція тегу

-видалити
видалити тег

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

теги
список тегів сховища:

hg теги

Тут перелічено як звичайні, так і локальні теги. Коли використовується перемикач -v/--verbose, третій
стовпець "local" друкується для локальних тегів. Коли використовується перемикач -q/--quiet, тільки
надруковано назву тега.

У разі успіху повертає 0.

варіанти:

-Т,--шаблон
дисплей із шаблоном (ЕКСПЕРИМЕНТАЛЬНИЙ)

чайові
показати редакцію підказки (ЗАСТАРЕЛО):

hg підказка [-p] [-g]

Версія підказки (зазвичай її називають просто підказкою) — це останній набір змін, доданий до
репозиторій (і, отже, останній змінений керівник).

Якщо ви щойно зробили фіксацію, ця фіксація буде підказкою. Якщо ви тільки що потягнули
змінюється з іншого репозиторію, кінчик цього сховища стає поточним. The
Тег "tip" є особливим і не може бути перейменований або призначений для іншого набору змін.

Ця команда не підтримується, будь ласка, використовуйте hg голови замість цього.

У разі успіху повертає 0.

варіанти:

-p, --патч
показати патч

-g, --git
використовуйте розширений формат git diff

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

роз’єднати
застосувати один або кілька файлів Changegroup:

hg unbundle [-u] ФАЙЛ...

Застосуйте один або кілька стиснутих файлів Changegroup, згенерованих командою bundle.

Повертає 0 у разі успіху, 1, якщо оновлення містить нерозв’язані файли.

варіанти:

-у, --оновити
оновлення до нової головки гілки, якщо набори змін були розгруповані

оновлення
оновити робочий каталог (або змінити версії):

оновлення hg [-c] [-C] [-d ДАТА] [[-r] REV]

Оновіть робочий каталог сховища до вказаного набору змін. Якщо немає набору змін
вказано, оновіть до кінця поточної названої гілки та перемістіть активну закладку (див
hg допомога закладки).

Оновлення встановлює батьківську версію робочого каталогу на вказаний набір змін (див hg
допомога батьки).

Якщо набір змін не є нащадком або предком батьківського робочого каталогу, файл
оновлення скасовано. За допомогою параметра -c/--check перевіряється робочий каталог
незастосовані зміни; якщо жодного не знайдено, робочий каталог оновлюється до вказаного
набір змін.

Якщо робочий каталог містить незафіксовані зміни, застосовуються такі правила:

1. Якщо не вказано ні -c/--check, ні -C/--clean, і якщо запитуваний набір змін є
предком або нащадком батьківського робочого каталогу є незафіксовані зміни
об’єднано у запитаний набір змін, а результат об’єднання залишається незафіксованим. Якщо
запитуваний набір змін не є предком або нащадком (тобто він знаходиться на іншому
відділення), оновлення припиняється, а незастосовані зміни зберігаються.

2. За допомогою параметра -c/--check оновлення скасовується, а незастосовані зміни
збереглися.

3. За допомогою параметра -C/--clean незастосовані зміни відкидаються, а робочий каталог
оновлено до запитуваного набору змін.

Щоб скасувати незафіксоване злиття (і втратити зміни), використовуйте hg оновлення --чистий ..

Використовуйте null як набір змін, щоб видалити робочий каталог (наприклад hg клон -U).

Якщо ви хочете повернути лише один файл до старішої версії, використовуйте hg повернути [-р REV] ІМ'Я.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Повертає 0 у разі успіху, 1, якщо є нерозв’язані файли.

варіанти:

-C, --чистий
відхилити незастосовані зміни (без резервної копії)

-c, --перевірте
оновлювати між гілками, якщо немає незафіксованих змін

-d,--дата
дата відповідності найбільшої редакції

-р,--rev
перегляд

-t,--інструмент
вказати інструмент об’єднання

псевдоніми: up checkout co

перевірити
перевірити цілісність сховища:

hg перевірити

Перевірте цілісність поточного сховища.

Це виконає розширену перевірку цілісності репозиторію, перевіряючи хеші
і контрольні суми кожного запису в журналі змін, маніфесті та файлах, що відстежуються, а також файли
цілісність їх зшивок та індексів.

Будь ласка, перегляньте https://mercurial-scm.org/wiki/RepositoryCorruption для отримання додаткової інформації про
відновлення після пошкодження репозиторію.

Повертає 0 в разі успіху, 1, якщо зустрічаються помилки.

версія
вихідна версія та інформація про авторські права:

версія hg

вихідна версія та інформація про авторські права

ДАТА ПРОВЕДЕННЯ ФОРМАТИ

Деякі команди дозволяють користувачеві вказати дату, наприклад:

· backout, commit, import, tag: Вкажіть дату фіксації.

· журнал, повернення, оновлення: Виберіть ревізію(и) за датою.

Багато форматів дати дійсні. Ось кілька прикладів:

· Wed грудня 6 13:18:29 2006 (припускається місцевий часовий пояс)

· грудня 6 13:18 -0600 (припускається рік, надано зсув часу)

· грудня 6 13:18 UTC (UTC і GMT – це псевдоніми +0000)

· грудня 6 (північ)

· 13:18 (припускається сьогодні)

· 3:39 (припускається 3:39 ранку)

· 3: 39pm (15: 39)

· 2006-12-06 13:18:29 (формат ISO 8601)

· 2006-12-6 13:18

· 2006-12-6

· 12-6

· 12/6

· 12/6/6 (6 грудня 2006 р.)

· сьогодні (північ)

· вчора (північ)

· зараз - прямо зараз

Нарешті, є внутрішній формат Mercurial:

· 1165411109 0 (Ср, 6 грудня, 13:18:29 2006 UTC)

Це внутрішній формат представлення дат. Перше число - це число
секунд з епохи (1970-01-01 00:00 UTC). Другий — залік місцевого
часовий пояс, у секундах на захід від UTC (від’ємний, якщо часовий пояс розташований на схід від UTC).

Команда log також приймає діапазони дат:

· <ДАТА - до певної дати/часу або раніше

· >ДАТА - на або після певної дати/часу

· ДАТА ПРОВЕДЕННЯ до ДАТА ПРОВЕДЕННЯ - діапазон дат включно

· -ДНІ - протягом певної кількості днів від сьогодні

РІЗНИЦЯ ФОРМАТИ

Типовий формат Mercurial для відображення змін між двома версіями файлу
сумісний з уніфікованим форматом GNU diff, який може використовуватися патчем GNU та багатьма
інші стандартні інструменти.

Хоча цього стандартного формату часто достатньо, він не кодує таку інформацію:

· статус виконуваного файлу та інші біти дозволу

· копіювати або перейменовувати інформацію

· зміни в бінарних файлах

· створення або видалення порожніх файлів

Mercurial також підтримує розширений формат diff з git VCS, який відповідає цим
обмеження. Формат git diff не створюється за замовчуванням, оскільки є кілька широко поширених інструментів
досі не розумію цього формату.

Це означає, що під час генерації відмінностей із репозиторію Mercurial (наприклад, with hg експорт),
вам слід бути обережними з такими речами, як копії файлів і перейменування або інші згадані речі
вище, тому що при застосуванні стандартного diff до іншого сховища цей додатковий
інформація втрачена. Внутрішні операції Mercurial (наприклад, натискання та витягування) не зачіпаються
цим, оскільки вони використовують внутрішній двійковий формат для передачі змін.

Щоб змусити Mercurial створювати розширений формат git diff, використовуйте параметр --git, доступний для
багато команд або встановіть 'git = True' в розділі [diff] вашого файлу конфігурації. ти
не потрібно встановлювати цю опцію під час імпорту відмінностей у цьому форматі або використання їх у mq
розширення.

НАВКОЛИШНЄ СЕРЕДОВИЩЕ ЗМІННІ

HG Шлях до виконуваного файлу 'hg', автоматично передається під час запуску хуків, розширень або
зовнішні інструменти. Якщо не встановлено або порожнє, це ім’я виконуваного файлу hg, якщо він заморожений,
або виконуваний файл з назвою 'hg' (з %PATHEXT% [за замовчуванням COM/EXE/BAT/CMD]
розширення в Windows) виконується пошук.

HGEDITOR
Це ім’я редактора, який запускається під час фіксації. Дивіться РЕДАКТОР.

(не підтримується, використовуйте файл конфігурації)

HGENCODING
Це замінює налаштування мови за замовчуванням, виявлене Mercurial. Це налаштування
використовується для перетворення даних, включаючи імена користувачів, описи наборів змін, імена тегів і
гілки. Цей параметр можна змінити за допомогою параметра командного рядка --encoding.

РЕЖИМ HGENCODING
Це встановлює поведінку Mercurial для обробки невідомих символів під час перекодування
введення користувача. За замовчуванням є "строгий", що змушує Mercurial переривати роботу, якщо не може
відобразити символ. Інші налаштування включають "замінити", яка замінює невідомі
символів і "ігнорувати", що скидає їх. Цей параметр можна змінити за допомогою
--encodingmode параметр командного рядка.

HGENCING НЕОДНОЗНАЧНИЙ
Це встановлює поведінку Mercurial для обробки символів із «неоднозначною» шириною, наприклад
акцентовані латинські символи зі східноазіатськими шрифтами. За замовчуванням припускає Mercurial
неоднозначні символи є вузькими, установіть для цієї змінної значення "wide", якщо такі символи
викликати проблеми з форматуванням.

HGMERGE
Виконуваний файл для вирішення конфліктів злиття. Програма буде виконана
з трьома аргументами: локальний файл, віддалений файл, файл-предок.

(не підтримується, використовуйте файл конфігурації)

HGRCPATH
Список файлів або каталогів для пошуку файлів конфігурації. Роздільник предметів є
":" в Unix, ";" на Windows. Якщо HGRCPATH не встановлено, шлях пошуку платформи за замовчуванням
використовується. Якщо порожній, зчитується лише файл .hg/hgrc з поточного сховища.

Для кожного елемента в HGRCPATH:

· якщо це каталог, додаються всі файли, що закінчуються на .rc

· інакше буде додано сам файл

HGPLAIN
Якщо встановлено, це вимикає будь-які налаштування конфігурації, які можуть змінити Mercurial
вихід за замовчуванням. Це включає кодування, параметри за замовчуванням, докладний режим, режим налагодження, тихий режим
режим, відстеження та локалізація. Це може бути корисно під час написання сценаріїв проти
Mercurial в умовах існуючої конфігурації користувача.

Еквівалентні параметри, встановлені за допомогою прапорів командного рядка або змінних середовища, не є
перевизначено.

HGPLAINE, КРІМ
Це розділений комами список функцій, які потрібно зберегти, коли ввімкнено HGPLAIN.
Наразі підтримуються такі значення:

псевдонім

Не видаляйте псевдоніми.

i18n

Зберегти інтернаціоналізацію.

revsetalias

Не видаляйте псевдоніми відновлення.

Якщо встановити HGPLAINEXCEPT будь-що (навіть порожній рядок), буде увімкнено звичайний режим.

HGUSER Це рядок, який використовується як автор коміту. Якщо не встановлено, доступні значення
розглядатимуться в такому порядку:

· HGUSER (не підтримується)

· файли конфігурації з HGRCPATH

· ЕЛЕКТРОННА ПОШТА

· інтерактивна підказка

· LOGNAME (з @ім'я хоста додається)

(не підтримується, використовуйте файл конфігурації)

ЕЛ. АДРЕСА Може використовуватися як автор коміту; див. HGUSER.

LOGNAME
Може використовуватися як автор коміту; див. HGUSER.

VISUAL Це ім’я редактора, яке використовується під час фіксації. Дивіться РЕДАКТОР.

РЕДАКТОР Іноді Mercurial потрібно відкрити текстовий файл у редакторі, щоб користувач міг змінити,
наприклад, під час написання повідомлень про фіксацію. Редактор, який він використовує, визначається
дивлячись на змінні середовища HGEDITOR, VISUAL та Editor у такому порядку.
Вибирається перший непорожній. Якщо всі вони порожні, редактор за замовчуванням
'sense-editor'.

ПІТОНПАТ
Це використовується Python для пошуку імпортованих модулів і може знадобитися встановити
відповідним чином, якщо цей Mercurial не встановлено в системі.

ВИКОРИСТАННЯ ДОДАТКОВИЙ ОСОБЛИВОСТІ

Mercurial має можливість додавати нові функції за допомогою розширень. Розширення
може додавати нові команди, додавати параметри до існуючих команд, змінювати поведінку за замовчуванням
команди або реалізувати гачки.

Щоб увімкнути розширення "foo", яке постачається разом із Mercurial або в шляху пошуку Python,
створіть для нього запис у вашому конфігураційному файлі, наприклад:

[розширення]
фу =

Ви також можете вказати повний шлях до розширення:

[розширення]
моя особливість = ~/.hgext/myfeature.py

Читати hg допомога конфиг для отримання додаткової інформації про конфігураційні файли.

Розширення не завантажуються за замовчуванням з різних причин: вони можуть збільшити запуск
накладні витрати; вони можуть бути призначені лише для розширеного використання; вони можуть надати потенційно
небезпечні здібності (наприклад, що дозволяють знищувати або змінювати історію); їх може і не бути
готовий до прайм-тайму; або вони можуть змінити деякі звичайні поведінки акції Mercurial. це є
таким чином, користувач може активувати розширення за потреби.

Щоб явно вимкнути розширення, увімкнене у файлі конфігурації ширшого обсягу,
передувати свій шлях за допомогою !:

[розширення]
# вимкнення панелі розширення, що знаходиться в /path/to/extension/bar.py
bar = !/path/to/extension/bar.py
# так само, але шлях для розширення baz не вказано
база = !

вимкнені розширення:

ACL хуки для контролю доступу до сховища

Чорна скринька
реєструвати події репозиторію в чорний ящик для налагодження

баггілла
гачки для інтеграції з баг-трекером Bugzilla

цензор стерти вміст файлу під час даної редакції

збивати команда для відображення статистики історії репозиторію

пучки клонів
рекламувати попередньо згенеровані пакети для початкових клонів

color розфарбувати вихідні дані деяких команд

конвертувати
імпортувати редакції з іноземних репозиторіїв VCS в Mercurial

еол автоматично керувати новими рядками у файлах репозиторію

extdiff
команда, щоб дозволити зовнішнім програмам порівнювати версії

фактотум
http аутентифікація за допомогою factotum

gpg команди для підписання та перевірки наборів змін

hgcia хуки для інтеграції зі службою сповіщень CIA.vc

hgk переглядати репозиторій у графічному вигляді

виділити
підсвічування синтаксису для hgweb (потрібні Pygments)

histedit
інтерактивне редагування історії

ключове слово
розгорнути ключові слова у відстежуваних файлах

великі файли
відстежувати великі двійкові файли

mq керувати стеком патчів

повідомляти гачки для відправки push-повідомлень електронною поштою

пейджер перегляд команди за допомогою зовнішнього пейджера

патчбомба
команду для надсилання наборів змін у вигляді (серії) електронних листів із виправленням

чистка команда для видалення невідстежуваних файлів з робочого каталогу

ребаза команда для переміщення наборів ревізій до іншого предка

запис команди для інтерактивного вибору змін для commit/qrefresh

повторне зв’язок відтворює жорсткі зв'язки між клонами репозиторію

схеми
розширити схеми з ярликами на рої репозиторіїв

частка спільна історія між кількома робочими каталогами

полиці зберегти та відновити зміни в робочому каталозі

роздягнутися видалити набори змін та їх нащадків з історії

пересадка
команда для пересадки наборів змін з іншої гілки

win32mbcs
дозволяють використовувати шляхи MBCS з проблемним кодуванням

нульовий конф
виявляти та рекламувати репозиторії в локальній мережі

УКАЗАННЯ Фото НАБОРИ

Mercurial підтримує функціональну мову для вибору набору файлів.

Як і інші шаблони файлів, цей тип шаблону позначається префіксом «set:». Мову
підтримує ряд предикатів, які об'єднуються інфіксними операторами. Дужки можуть бути
використовується для групування.

Ідентифікатори, такі як назви файлів або шаблони, повинні братися в одинарні або подвійні лапки, якщо
вони містять символи за межами [.*{}[]?/\_a-zA-Z0-9\x80-\xff] або якщо вони відповідають одному з
заздалегідь визначені предикати. Зазвичай це стосується шаблонів файлів, відмінних від глобусів і
аргументи для предикатів.

Спеціальні символи можна використовувати в ідентифікаторах у лапках, екрануючи їх, наприклад, \n is
інтерпретується як новий рядок. Щоб запобігти їх інтерпретації, рядки можуть мати префікс
з r, напр г'...'.

Існує єдиний оператор-префікс:

НЕ x

Файли не в x. Коротка форма є ! x.

Це підтримувані інфіксні оператори:

x та y

Перетин файлів у x і y. Коротка форма є x & y.

x or y

Об'єднання файлів у x і y. Є дві альтернативні короткі форми: x | y та x +
y.

x - y

Файли в x, але не в y.

Підтримуються такі предикати:

додано()

Файл, який додається відповідно до hg статус.

двійковий()

Файл, який виглядає двійковим (містить NUL-байти).

чистий()

Файл, чистий відповідно до hg статус.

скопійовано()

Файл, який записується як копійований.

видалено()

Псевдонім для відсутній().

кодування (ім'я)

Файл може бути успішно декодований із заданим кодуванням символів. Може не бути
корисно для кодування, відмінного від ASCII та UTF-8.

eol (стиль)

Файл містить нові рядки заданого стилю (dos, unix, mac). Бінарні файли є
виключено, файли зі змішаними закінченнями рядків відповідають кільком стилям.

exec ()

Файл, позначений як виконуваний.

grep (регулярний вираз)

Файл містить заданий регулярний вираз.

hgignore()

Файл, який відповідає активному шаблону .hgignore.

ігнорується()

Файл, який ігнорується відповідно до hg статус. Ці файли розглядатимуться лише в тому випадку, якщо
вживається цей присудок.

відсутній()

Відсутній файл відповідно до hg статус.

змінений()

Файл, який змінено відповідно до hg статус.

портативний()

Файл із переносимою назвою. (Це не включає назви файлів із регістром
зіткнення.)

видалено()

Файл, видалений відповідно до hg статус.

вирішено()

Файл, позначений як вирішений відповідно до hg рішення -l.

розмір (вираз)

Розмір файлу відповідає заданому виразу. Приклади:

· 1k (файли від 1024 до 2047 байт)

· < 20k (файли менше 20480 байт)

· >= .5 МБ (файли розміром не менше 524288 байт)

· 4k - 1MB (файли від 4096 байт до 1048576 байт)

subrepo([шаблон])

Підсховища, шляхи яких відповідають заданому шаблону.

символічне посилання()

Файл, позначений як символьне посилання.

невідомо()

Файл, який невідомий згідно з hg статус. Ці файли розглядатимуться лише в тому випадку, якщо
вживається цей присудок.

невирішений()

Файл, позначений як невирішений відповідно до hg рішення -l.

Деякі зразки запитів:

· Показати статус файлів, які здаються двійковими в робочому каталозі:

статус hg -A "set:binary()"

· Забудьте файли, які знаходяться в .hgignore, але вже відстежуються:

hg забути "set:hgignore() і не ігнорується()"

· Знайти текстові файли, які містять рядок:

hg файли "set:GREP(магія), а не двійковий()"

· Знайдіть файли C у нестандартному кодуванні:

hg файли "set:**.c і не кодують ('UTF-8')"

· Повернути копії великих двійкових файлів:

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

· Видаліть файли, перераховані в foo.lst, які містять літеру a або b:

hg видалити "set: 'listfile:foo.lst' і (**a* або **b*)"

Дивіться також hg допомога моделі.

ГЛОСАРІЙ

Предка
Будь-який набір змін, який може бути досягнутий безперервним ланцюгом батьківських наборів змін з a
даний набір змін. Точніше, предків набору змін можна визначити двома
властивості: батьківський набір змін є предком, а батьком предка є
предок. Дивіться також: «Нащадок».

закладка
Закладки — це вказівники на певні коміти, які переміщуються під час фіксації. Вони є
схожий на теги тим, що можна використовувати імена закладок у всіх місцях, де
Mercurial очікує ідентифікатор набору змін, наприклад, with hg оновлення. На відміну від тегів, закладки переміщуються
разом, коли ви робите фіксацію.

Закладки можна перейменовувати, копіювати та видаляти. Закладки локальні, якщо вони не є
явно переміщено або витягнуто між сховищами. Натискання та витягування закладок
дозволяють вам співпрацювати з іншими у гілці без створення іменованої гілки.

Філія (Іменник) Дочірній набір змін, який був створений з батька, який не є головою.
Вони відомі як топологічні гілки, див. «Гілку, топологічні». Якщо
топологічна гілка іменована, вона стає іменованою гілкою. Якщо топологічна гілка
не названий, він стає анонімною гілкою. Див. розділи «Анонімне відділення» та «Відділення,
названий'.

Відгалуження можуть створюватися, коли зміни витягуються з пульта дистанційного керування або пересилаються на нього
репозиторій, оскільки за допомогою цих операцій можуть бути створені нові заголовки. Зверніть увагу, що термін
гілка також може використовуватися неформально для опису процесу розробки, в якому
певний розвиток здійснюється незалежно від іншого розвитку. Це іноді буває
виконується явно з іменованою гілкою, але це також можна зробити локально, використовуючи
закладки або клони та анонімні гілки.

Приклад: «Експериментальна гілка».

(Дієслово) Дія створення дочірнього набору змін, що призводить до того, що його батько має
більше однієї дитини.

Приклад: «Я збираюся відділитися в X».

Філія, анонімний
Щоразу новий дочірній набір змін створюється з батьківського елемента, який не є головою і
назва гілки не змінюється, створюється нова анонімна гілка.

Філія, закрито
Іменована філія, усі головки філій якої закриті.

Філія, дефолт
Гілка, призначена для набору змін, якщо раніше не було призначено жодного імені.

Філія голова
Див. «Голова, гілка».

Філія, неактивний
Якщо названа гілка не має топологічних головок, вона вважається неактивною. Як
наприклад, гілка функції стає неактивною, коли вона об’єднана зі стандартною
відділення. The hg гілки команда показує неактивні гілки за замовчуванням, хоча вони можуть
бути прихованим з hg гілки --активний.

ПРИМІТКА: ця концепція не підтримується, оскільки вона занадто неявна. Відділення повинні зараз
бути явно закритим за допомогою hg commit --ближне відділення коли вони вже не потрібні.

Філія, названий
Колекція наборів змін, які мають однакову назву гілки. За замовчуванням діти
набір змін у іменованій гілці належить до тієї ж іменованої гілки. Дитина може бути
явно віднесено до іншої гілки. Подивитися hg допомога філія, hg допомога гілки та
hg commit --ближне відділення для отримання додаткової інформації про управління відділеннями.

Іменовані гілки можна розглядати як свого роду простір імен, що розділяє колекцію
набори змін, які містять репозиторій у набір непересічних підмножин. А
названа гілка не обов'язково є топологічною гілкою. Якщо є нова іменована гілка
створений із заголовка іншої гілки з назвою або гілки за замовчуванням, але ні
подальші набори змін додаються до попередньої гілки, а потім до попередньої гілки
буде філією лише за назвою.

Філія чайові
Дивіться «Порада, відділення».

Філія, топологічний
Кожен раз, коли новий дочірній набір змін створюється з батьківського, який не є головою, новий
створюється топологічна гілка. Якщо топологічна гілка названа, вона стає іменованою
відділення. Якщо топологічна гілка не названа, вона стає анонімною гілкою
поточна, можливо, за замовчуванням, гілка.

змін
Запис наборів змін у тому порядку, в якому вони були додані до сховища.
Це включає такі деталі, як ідентифікатор набору змін, автор, повідомлення про фіксацію, дата та список
змінених файлів.

Набір змін
Знімок стану репозиторію, який використовується для запису змін.

Набір змін, дитина
Зворотне для батьківського набору змін: якщо P є батьківським для C, то C є дочірнім для P.
Кількість дітей, які може мати набір змін, не обмежена.

Набір змін id
Хеш SHA-1, який однозначно ідентифікує набір змін. Він може бути представлений як
«довгий» рядок із 40 шістнадцяткових цифр або «короткий» рядок із 12 шістнадцяткових цифр.

Набір змін, злиття
Набір змін з двома батьками. Це відбувається, коли фіксується злиття.

Набір змін, батько
Версія, на якій базується дочірній набір змін. Зокрема, батьківський набір змін
набору змін C — це набір змін, вузол якого безпосередньо передує C у DAG.
Набори змін мають не більше двох батьків.

Введіть дані:
(Іменник) Робочий каталог оновлюється до певної версії. Це використання повинно
мабуть, уникати, де це можливо, оскільки набір змін є набагато більш доречним, ніж
оформлення замовлення в цьому контексті.

Приклад: "Я використовую Checkout X."

(Дієслово) Оновлення робочого каталогу до певного набору змін. Подивитися hg допомога оновлення.

Приклад: "Я збираюся перевірити набір змін X."

Дитина ревізія
Див. «Набір змін, дитина».

близько ревізія
Див. «Голова, закрите відділення».

Закрито філія
Див. «Відділення, закрите».

Клон (Іменник) Повна або часткова копія сховища. Частковий клон повинен бути в
форма ревізії та її предки.

Приклад: "Чи оновлений ваш клон?"

(Дієслово) Процес створення клону, використовуючи hg клон.

Приклад: «Я збираюся клонувати сховище».

Закрито філія голова
Див. «Голова, закрите відділення».

здійснити (Іменник) Синонім набору змін.

Приклад: "Чи виправлено помилку у вашому нещодавньому коміті?"

(Дієслово) Акт запису змінюється на сховище. Коли файли фіксуються в a
робочого каталогу, Mercurial знаходить відмінності між зафіксованими файлами і
їхній батьківський набір змін, створюючи новий набір змін у сховищі.

Приклад: «Ви повинні зафіксувати ці зміни зараз».

Cset Звичайна абревіатура терміна Changeset.

DAG Репозиторій наборів змін розподіленої системи контролю версій (DVCS) може бути
описується як орієнтований ациклічний граф (DAG), що складається з вузлів і ребер, де
вузли відповідають наборам змін, а ребра мають на увазі батьківське -> дочірнє відношення. Це
графік можна візуалізувати за допомогою таких графічних інструментів, як hg журнал --граф. У Mercurial,
DAG обмежена вимогою, щоб діти мали не більше двох батьків.

Застаріле
Функція вилучена з документації, але не запланована на видалення.

дефолт філія
Див. «Відгалуження, за замовчуванням».

Нащадок
Будь-який набір змін, який може бути досягнутий ланцюгом дочірніх наборів змін із заданого
набір змін. Точніше, нащадків набору змін можна визначити двома
властивості: дочірній набір змін є нащадком, а дочірній — нащадком
є нащадком. Дивіться також: «Предок».

Різниця (Іменник) Різниця між вмістом та атрибутами файлів у двох
набори змін або набір змін і поточний робочий каталог. Різниця в тому
зазвичай представлений у стандартній формі, яка називається «розрізнення» або «патч». "git diff"
формат використовується, коли зміни включають копії, перейменування або зміни файлу
атрибути, жоден з яких не може бути представлений/оброблено класичними "diff" і "patch".

Приклад: "Чи бачили ви моє виправлення в різниці?"

(Дієслово) Розміщення двох наборів змін – це дія створення відмінності або виправлення.

Приклад: "Якщо ви відрізняєтеся від набору змін X, ви зрозумієте, що я маю на увазі."

Каталог, робочий
Робочий каталог представляє стан файлів, які відстежує Mercurial, тобто
буде записано в наступному коміті. Робочий каталог спочатку відповідає
знімок наявного набору змін, відомий як батьківський робочий
каталог. Див. «Батьківський, робочий каталог». Стан може бути змінений змінами до
файли, введені вручну або шляхом злиття. Метадані репозиторію існують у
.hg всередині робочого каталогу.

Проект Набори змін на етапі чернетки не були надані сховищам публікування та
таким чином, можна безпечно змінювати розширення, що змінюють історію. Подивитися hg допомога фаз.

Експериментальна
Функція, яка може бути змінена або вилучена пізніше.

Графік Див. DAG і hg журнал --граф.

Керівник Термін "голова" може використовуватися для позначення як головки гілки, так і голови сховища,
залежно від контексту. Додаткові відомості див. у розділах «Керівник, гілка» та «Керівник, сховище».
визначення.

Голови – це місце, де зазвичай відбувається розвиток, і вони є звичайними цілями
операції оновлення та злиття.

Голова, філія
Набір змін без нащадків у гілці з тим самим ім'ям.

Голова, закрито філія
Набір змін, який позначає голову як більше нецікаву. Закритої головки немає
довше в списку за hg голови. Відділення вважається закритим, якщо всі його головки є
закрито і, отже, не входить до списку hg гілки.

Закриті головки можна повторно відкрити, зафіксувавши новий набір змін як дочірній
набір змін, який позначає голову як закриту.

Голова, Сховище
Топологічна голівка, яка не була закрита.

Голова, топологічний
Набір змін без дітей у сховищі.

Історія, непорушний
Після фіксації набори змін не можуть бути змінені. Розширення, які, здається, змінюються
Історія фактично створює нові набори змін, які замінюють існуючі, а потім знищують
старі набори змін. Це може призвести до старих наборів змін
знову вводиться до сховища.

Історія, перезапису
Набори змін у сховищі є незмінними. Однак розширення для Mercurial можуть
використовуватися для зміни сховища, як правило, таким чином, щоб зберегти набір змін
зміст.

Незмінний історія
Див. «Історія, незмінна».

Злиття ревізія
Див. «Набір змін, об’єднання».

Маніфест
Кожен набір змін має маніфест, який є списком файлів, які відстежуються
набір змін.

Злиття Використовується для об’єднання різних галузей роботи. Коли ви оновлюєтеся до набору змін
а потім об’єднайте інший набір змін, ви перенесете історію останнього набору змін
у ваш робочий каталог. Після того, як конфлікти вирішені (і позначені), це злиття
може бути зафіксовано як набір змін злиття, що об’єднує дві гілки в DAG.

Названий філія
Див. «Відгалуження, назване».

Null ревізія
Порожній набір змін. Це батьківський стан нещодавно ініціалізованих сховищ і
репозиторії без перевіреної редакції. Таким чином, він є батьком кореневих наборів змін
і ефективний предок при об'єднанні непов'язаних наборів змін. Можна вказати за
псевдонім "null" або ідентифікатор набору змін "000000000000".

Parent Див. «Набір змін, батьківський».

Parent ревізія
Див. «Набір змін, батьківський».

Батько, робочий каталог
Батьківський робочий каталог відображає віртуальну версію, яка є дочірньою версією
набір змін (або два набори змін із незафіксованим злиттям), показаний за допомогою hg батьки, це
змінюється з hg оновлення. Інші команди для перегляду батьківського робочого каталогу є
hg резюме та hg id. Можна вказати псевдонімом ".".

пластир (Іменник) Продукт операції diff.

Приклад: «Я надіслав вам свій патч».

(Дієслово) Процес використання файлу виправлення для перетворення одного набору змін в інший.

Приклад: «Вам потрібно буде виправити цю редакцію».

Фаза Стан для кожного набору змін, що відстежує, як набір змін був або має бути надано спільно. Подивитися
hg допомога фаз.

громадськості Набори змін на загальнодоступній фазі були надані спільно з репозиторіями публікації та
тому вважаються незмінними. Подивитися hg допомога фаз.

Потягнути Операція, під час якої набори змін у віддаленому сховищі, які не знаходяться в локальному
репозиторій переносяться в локальне сховище. Зверніть увагу, що ця операція без
спеціальні аргументи лише оновлюють репозиторій, але не оновлюють файли в
робочий каталог. Подивитися hg допомога тягнути.

Штовхати Операція, під час якої набори змін у локальному сховищі, які не знаходяться у віддаленому
репозиторій надсилаються у віддалений репозиторій. Зауважте, що ця операція лише додає
набори змін, які були зафіксовані локально у віддаленому сховищі. Незроблені
зміни не надсилаються. Подивитися hg допомога штовхати.

Сховище
Метадані, що описують усі записані стани колекції файлів. Кожен записаний
стан представлений набором змін. Зазвичай (але не завжди) можна знайти репозиторій
в .hg підкаталог робочого каталогу. Будь-який записаний стан можна відтворити
шляхом «оновлення» робочого каталогу до певного набору змін.

Сховище голова
Див. «Голова, сховище».

Revision
Стан сховища в певний момент часу. Попередні версії можуть бути оновлені
до за допомогою hg оновлення. Див. також «Номер версії»; Дивіться також «Набір змін».

Revision номер
Це ціле число унікально ідентифікує набір змін у певному сховищі. Це
представляє порядок, у якому набори змін були додані до сховища, починаючи з
номер версії 0. Зверніть увагу, що номер версії може відрізнятися в кожному клоні
сховище. Щоб однозначно ідентифікувати набори змін між різними клонами, див
"Ідентифікатор набору змін".

Revlog Механізм зберігання історії, використовуваний Mercurial. Це форма дельта-кодування, с
періодична повна ревізія даних з подальшою дельтою кожного наступного перегляду. Це
містить дані та індекс, що вказує на дані.

Переписування історія
Див. «Історія, переписування».

Корінь Набір змін, який має лише нульовий набір змін як батьківський. У більшості сховищ є
лише один кореневий набір змін.

секрет Набори змін на секретній фазі не можуть надаватися за допомогою push, pull або клонування. Подивитися hg
допомога фаз.

Тег Альтернативна назва набору змін. Теги можна використовувати у всіх місцях
Mercurial очікує ідентифікатор набору змін, наприклад, with hg оновлення. Створення тегу є
зберігається в історії і, таким чином, буде автоматично переданий іншим за допомогою push
і тягнути.

Чайові Набір змін з найвищим номером версії. Це останній набір змін
додано в репозиторій.

Порада, філія
Керівник даної філії з найвищим номером ревізії. Коли назва філії
використовується як ідентифікатор ревізії, він відноситься до наконечника гілки. Дивіться також «Відділення,
керівник'. Зауважте, що оскільки номери ревізій можуть відрізнятися в різних репозиторіях
клонів, кінчик гілки може відрізнятися в різних клонованих сховищах.

Оновити (Іменник) Ще один синонім набору змін.

Приклад: "Я оновив".

(Дієслово) Цей термін зазвичай використовується для опису оновлення стану робочого
до каталогу певного набору змін. Подивитися hg допомога оновлення.

Приклад: «Ви повинні оновити».

Робочий каталог
Див. «Довідник, робочий».

Робочий каталог батько
Див. «Батьківський, робочий каталог».

СИНТАКС ДЛЯ РТУТНИЙ ІГНОРУВАТИ ФАЙЛИ

конспект
Система Mercurial використовує файл під назвою .hgignore у кореневому каталозі репозиторію до
керувати своєю поведінкою, коли він шукає файли, які наразі не відстежує.

Опис
Робочий каталог репозиторію Mercurial часто містить файли, які не повинні
відстежувати Mercurial. Сюди входять файли резервних копій, створені редакторами, і продукти збірки
створені компіляторами. Ці файли можна ігнорувати, перерахувавши їх у a .hgignore файл у
корінь робочого каталогу. The .hgignore файл потрібно створити вручну. це є
зазвичай ставиться під контроль версій, щоб налаштування поширювалися на інші
репозиторії за допомогою push and pull.

Невідстежуваний файл ігнорується, якщо його шлях відносно кореневого каталогу сховища або будь-який інший
префікс шлях цього шляху, зіставляється з будь-яким шаблоном в .hgignore.

Наприклад, припустимо, що у нас є файл, який не відстежується, файл.c, в a/b/file.c всередині нашого репозитарію.
Mercurial проігнорує файл.c якщо є шаблон .hgignore сірники a/b/file.c, / Б or a.

Крім того, файл конфігурації Mercurial може посилатися на набір для кожного користувача або глобальний
ігнорувати файли. Див ігнорувати ключ конфігурації на [ui] розділ hg допомога конфиг та цінності
докладні відомості про те, як налаштувати ці файли.

Щоб контролювати обробку Mercurial файлів, якими він керує, багато команд підтримують -I та
-X варіанти; подивитися hg допомога та hg допомога моделі for details.

.hgignore не впливає на файли, які вже відстежуються, навіть якщо вони з’являються
.hgignore. Невідстежуваний файл X можна явно додати hg додавати X, навіть якщо X буде
виключено шаблоном у .hgignore.

синтаксис
Файл ігнорування — це звичайний текстовий файл, що складається зі списку шаблонів, з одним шаблоном для кожного
лінія. Порожні рядки пропускаються. The # символ розглядається як символ коментаря, а символ
\ символ розглядається як escape-символ.

Mercurial підтримує кілька синтаксисів шаблонів. За замовчуванням використовується синтаксис у стилі Python/Perl
регулярні вирази.

Щоб змінити використовуваний синтаксис, використовуйте рядок наступної форми:

синтаксис: NAME

де ІМ'Я є одним із наступних:

RegExp

Регулярний вираз, синтаксис Python/Perl.

куля

Глоб у стилі раковини.

Вибраний синтаксис залишається в силі під час аналізу всіх наступних шаблонів до іншого
вибрано синтаксис.

Шаблони glob і regexp не вкорінені. Шаблон глобального синтаксису форми *.c волі
відповідати файлу, що закінчується на .c у будь-якому каталозі та шаблон регулярного виразу у формі \.c$ зроблю
так само. Щоб укоренити шаблон регулярного виразу, почніть його з ^.

Підкаталоги можуть мати власні налаштування .hgignore шляхом додавання
subinclude:path/to/subdir/.hgignore до кореня .hgignore, Побачити hg допомога моделі та цінності
деталі на підключати: та включати:.

Примітка Шаблони, зазначені в іншому, ніж .hgignore завжди вкорінені. Будь ласка, дивіться hg допомога
моделі for details.

Приклад
Ось приклад файлу ігнорування.

# використовувати синтаксис glob.
синтаксис: glob

*.elc
*.pyc
*~

# перейти до синтаксису регулярного виразу.
синтаксис: регулярний вираз
^\.pc/

НАСТРОЮВАННЯ HGWEB

Внутрішній веб-сервер Mercurial, hgweb, може обслуговувати або одне сховище, або дерево
сховища. У другому випадку шляхи до сховища та глобальні параметри можна визначити за допомогою
спеціальний файл конфігурації, загальний для hg служити, hgweb.wsgi, hgweb.cgi та hgweb.fcgi.

Цей файл використовує той самий синтаксис, що й інші файли конфігурації Mercurial, але лише розпізнає
наступні розділи:

· веб

· доріжки

· колекції

Команда Web опції докладно описані в hg допомога конфиг.

Команда стежки розділ зіставляє шляхи URL до шляхів сховищ у файловій системі. hgweb буде
не відкривати файлову систему безпосередньо - можна публікувати тільки репозиторії Mercurial
відповідно до конфігурації.

Ліва сторона – це шлях в URL-адресі. Зауважте, що hgweb резервує підшляхи, наприклад об or
файл, спробуйте використовувати різні назви вкладених сховищ, щоб уникнути незрозумілих ефектів.

Права сторона — це шлях у файловій системі. Якщо вказаний шлях закінчується на * or **
файлова система буде рекурсивно шукати репозиторії нижче цієї точки. З * it
не буде повертатися до знайдених сховищ (за винятком .hg/patches). З ** це буде
також шукайте всередині робочих каталогів репозиторіїв і, можливо, знайдіть підрепозиторії.

У цьому прикладі:

[шляхи]
/projects/a = /srv/tmprepos/a
/projects/b = c:/repos/b
/ = /srv/repos/*
/user/bob = /home/bob/repos/**

· Перші два записи змушують два сховища в різних каталогах з'являтися під
той самий каталог у веб-інтерфейсі

· У третьому записі буде опубліковано всі знайдені репозиторії Mercurial /srv/repos/, Для
примірник репозиторію /srv/repos/quux/ відображатиметься як http://server/quux/

· Четвертий запис публікує обидва http://server/user/bob/quux/ та
http://server/user/bob/quux/testsubrepo/

Команда Колекції розділ не підтримується і був замінений на стежки.

URL-адреси та загальний Аргументи
URL-адреси під кожним сховищем мають вигляд /{команда}[/{аргументи}] де {команда}
представляє ім'я команди або обробника і {аргументи} представляє будь-яку кількість
додаткові параметри URL до цієї команди.

Веб-сервер має стандартний стиль, пов’язаний із ним. Стилі відображаються в колекцію named
шаблони. Кожен шаблон використовується для відтворення певної частини даних, наприклад набору змін
або розн.

Стиль поточного запиту можна перезаписати двома способами. По-перше, якщо {команда}
містить дефіс (-), текст перед дефісом визначає стиль. Наприклад,
/atom-log надасть журнал обробник команд з атом стиль. Другий спосіб установки
стиль з стиль аргумент рядка запиту. Наприклад, /log?style=atom,
Переважний параметр URL-адреси через дефіс.

Не всі шаблони доступні для всіх стилів. Спроба використати стиль, який цього не робить
Визначення всіх шаблонів може призвести до помилки відтворення сторінки.

Багато команд приймають a {версія} Параметр URL-адреси. Це визначає набір змін для роботи.
Зазвичай це вказується як коротка 12-значна шістнадцяткова абревіатура для повних 40
унікальний ідентифікатор ревізії символу. Однак будь-яке значення, описане за допомогою hg допомога перегляди
зазвичай працює.

Команди та URL-адреси
Доступні такі веб-команди та їх URL-адреси:

/аннотувати/{версія}/{шлях}
Показати інформацію про набір змін для кожного рядка у файлі.

Команда файл анотації відображається шаблон.

/archive/{revision}.{format}[/{path}]
Отримайте архів вмісту репозитарію.

Вміст і тип архіву визначаються параметром шляху URL. формат є
розширення файлу типу архіву, який потрібно створити. наприклад ZIP or tar.bz2. Не всі архіви
типи можуть бути дозволені конфігурацією вашого сервера.

The optional шлях Параметр URL-адреси керує вмістом для включення в архів. Якщо пропущено,
кожен файл у вказаній редакції присутній в архіві. Якщо включено, тільки
зазначений файл або вміст зазначеного каталогу буде включено до архіву.

Для цього обробника не використовується шаблон. Генерується необроблений двійковий вміст.

/закладки
Показати інформацію про закладки.

Жодні аргументи не приймаються.

Команда закладки відображається шаблон.

/філії
Показати інформацію про філії.

Усі відомі гілки містяться у виводі, навіть закриті гілки.

Жодні аргументи не приймаються.

Команда гілки відображається шаблон.

/журнал змін[/{версія}]
Показати інформацію про декілька наборів змін.

Якщо необов’язковий перегляд Аргумент URL відсутній, інформація про всі набори змін починається
at чайові буде надано. Якщо перегляд аргумент присутній, буде показано набори змін
починаючи з зазначеної редакції.

If перегляд відсутня, в об може бути визначений аргумент рядка запиту. Це буде виконувати а
пошук наборів змін.

Аргумент за об може бути окремою редакцією, набором версій або буквальним ключовим словом для
пошук у даних набору змін (еквівалентно hg журнал -k).

Команда оборотів Аргумент рядка запиту визначає максимальну кількість наборів змін для відтворення.

Для не-пошуку, змін шаблон буде відтворений.

/changeset[/{версія}]
Показати інформацію про один набір змін.

Аргумент шляху URL – це ідентифікатор набору змін, який потрібно відобразити. Подивитися hg допомога перегляди та цінності
можливі значення. Якщо не визначено, то чайові буде показано набір змін.

Команда ревізія відображається шаблон. Зміст Changesettag, змінити закладку,
Посилання на вузол файлу, filenolink, і всі шаблони, пов’язані з diffs, можуть використовуватися
виробляти вихід.

/порівняння/{версія}/{шлях}
Показати порівняння між старою та новою версіями файлу зі змінами, внесеними на a
особливий перегляд.

Це схоже на різниця обробник. Однак ця форма має розкол або поруч
diff, а не уніфікований diff.

Команда контекст Аргумент рядка запиту можна використовувати для керування рядками контексту в diff.

Команда порівняння файлів відображається шаблон.

/diff/{версія}/{шлях}
Покажіть, як файл змінився під час певного коміту.

Команда filediff відображається шаблон.

Цей обробник зареєстровано під обома /розн та /filediff стежки. /розн використовується в
сучасний код.

/файл/{версія}[/{шлях}]
Показати інформацію про каталог або файл у сховищі.

Інформація про шлях буде відображено як параметр URL-адреси.

If шлях це каталог, буде відображатися інформація про записи в цьому каталозі.
Ця форма еквівалентна проявляється обробник.

If шлях є файлом, інформація про цей файл буде показана за допомогою перегляд файлу
шаблон

If шлях не визначено, буде відображатися інформація про кореневий каталог.

/diff/{версія}/{шлях}
Покажіть, як файл змінився під час певного коміту.

Команда filediff відображається шаблон.

Цей обробник зареєстровано під обома /розн та /filediff стежки. /розн використовується в
сучасний код.

/filelog/{версія}/{шлях}
Показати інформацію про історію файлу в репозиторії.

Команда оборотів Аргумент рядка запиту можна визначити для контролю максимальної кількості записів
показувати.

Команда журнал файлів шаблон буде відтворений.

/граф[/{версія}]
Показати інформацію про графічну топологію репозиторію.

Інформацію, надану цим обробником, можна використовувати для створення візуальних уявлень
топологія сховища.

Команда перегляд Параметр URL керує початковим набором змін.

Команда оборотів Аргумент рядка запиту може визначати кількість наборів змін для відображення інформації
для.

Цей обробник відтворить графік шаблон

/довідка[/{тема}]
Надайте довідкову документацію.

Ця веб-команда приблизно еквівалентна hg допомога. Якщо тема визначено, що тема допомоги
буде надано. Якщо ні, буде відображено покажчик доступних тем довідки.

Команда допомога шаблон буде відображатися під час запиту на допомогу з теми. теми довідки буде
надано для покажчика довідкових тем.

/log[/{версія}[/{шлях}]]
Показати сховище або історію файлів.

Для URL-адрес форми /log/{версія}, список наборів змін, починаючи з вказаного
відображається ідентифікатор набору змін. Якщо {версія} не визначено, за замовчуванням є чайові. Ця форма
еквівалентно змін обробник.

Для URL-адрес форми /log/{версія}/{файл}, історія для певного файлу буде
показано. Ця форма еквівалентна журнал файлів обробник.

/маніфест[/{revision}[/{path}]]
Показати інформацію про каталог.

Якщо аргументи шляху URL-адреси опущені, інформація про кореневий каталог для чайові
буде показано набір змін.

Оскільки цей обробник може показувати інформацію лише для каталогів, його рекомендується використовувати
файл натомість обробник, оскільки він може обробляти як каталоги, так і файли.

Команда проявляється шаблон буде відтворений для цього обробника.

/changeset[/{версія}]
Показати інформацію про один набір змін.

Аргумент шляху URL – це ідентифікатор набору змін, який потрібно відобразити. Подивитися hg допомога перегляди та цінності
можливі значення. Якщо не визначено, то чайові буде показано набір змін.

Команда ревізія відображається шаблон. Зміст Changesettag, змінити закладку,
Посилання на вузол файлу, filenolink, і всі шаблони, пов’язані з diffs, можуть використовуватися
виробляти вихід.

/короткий журнал
Показати основну інформацію про набір змін.

Це приймає ті самі параметри, що й змін обробник. Єдина відмінність полягає в тому
короткий журнал замість шаблону буде відображатися шаблон змін шаблон

/резюме
Показати підсумок стану сховища.

При цьому фіксується інформація про останні набори змін, закладки, теги та гілки
обробник.

Команда резюме відображається шаблон.

/теги
Показати інформацію про теги.

Жодні аргументи не приймаються.

Команда теги відображається шаблон.

ТЕХНІЧНІ IMPLEMENTATION ТЕМИ

пучки
контейнер для обміну даними репозитарію

змінні групи
представлення даних revlog

ревлоги
механізм зберігання ревізій

ВЕЛИКИЙ ЗАСОБИ

Для об’єднання файлів Mercurial використовує інструменти злиття.

Інструмент об’єднання об’єднує дві різні версії файлу в об’єднаний файл. Інструменти злиття є
враховуючи два файли та найбільшого спільного предка двох версій файлів, то вони можуть
визначити зміни, внесені в обох гілках.

Інструменти об’єднання використовуються для обох hg рішення, hg злиття, hg оновлення, hg Повернись назад і в кількох
розширення.

Зазвичай інструмент злиття намагається автоматично узгодити файли, об’єднавши всі
неперекриваються зміни, які відбувалися окремо в двох різних еволюціях
той самий початковий базовий файл. Крім того, деякі інтерактивні програми злиття полегшують це
розв’язувати конфліктні злиття вручну графічним способом або вставляючи деякі
маркери конфлікту. Mercurial не включає інтерактивні програми злиття, але покладається на них
зовнішні інструменти для цього.

наявний злиття інструменти
Зовнішні інструменти злиття та їх властивості налаштовуються в конфігурації інструментів злиття
розділ - див hgrc(5) - але часто їх можна просто назвати виконуваним файлом.

Інструмент злиття зазвичай можна використовувати, якщо його виконуваний файл можна знайти в системі та якщо він
може обробляти злиття. Виконуваний файл знайдено, якщо він є абсолютним або відносним виконуваним файлом
шлях або ім'я програми в шляху пошуку виконуваного файлу. Передбачається, що інструмент
мати можливість обробляти злиття, якщо він може обробляти символічні посилання, якщо файл є символічним посиланням, якщо він може
обробляти двійкові файли, якщо файл двійковий, і якщо графічний інтерфейс доступний, якщо цього вимагає інструмент
графічний інтерфейс.

Існують деякі інструменти внутрішнього злиття, які можна використовувати. Інструменти внутрішнього злиття:

:звалити

Створює три версії файлів для об’єднання, що містять вміст локального,
інше та база. Ці файли потім можна використовувати для виконання об’єднання вручну. Якщо
названо файл, який потрібно об’єднати a.txt, ці файли будуть відповідно названі
a.txt.local, a.txt.other та a.txt.base і вони будуть розміщені в тому самому
каталог як a.txt.

: невдача

Замість того, щоб намагатися об’єднати файли, які були змінені в обох гілках, він позначає
їх як невирішені. Для вирішення цих конфліктів необхідно використовувати команду resolve.

: місцевий

Використовує локальну версію файлів як об’єднану версію.

: об'єднати

Використовує внутрішній неінтерактивний простий алгоритм злиття для об’єднання файлів. Це буде
не вдається, якщо є конфлікти, і залишати маркери у частково об’єднаному файлі.
Маркери будуть мати дві секції, по одному для кожної сторони злиття.

:merge-локальний

Як :merge, але вирішуйте всі конфлікти неінтерактивно на користь локального
зміни.

: merge-other

Як :merge, але вирішуйте всі конфлікти неінтерактивно на користь іншого
зміни.

:merge3

Використовує внутрішній неінтерактивний простий алгоритм злиття для об’єднання файлів. Це буде
не вдається, якщо є конфлікти, і залишати маркери у частково об’єднаному файлі.
Маркер матиме три секції, по одному з кожної сторони злиття, а один для
базовий зміст.

:інший

Використовує іншу версію файлів як об’єднану версію.

:підказка

Запитує користувача, яку з локальної чи іншої версії зберегти як об’єднану
версія.

:tagmerge

Використовує внутрішній алгоритм злиття тегів (експериментальний).

:союз

Використовує внутрішній неінтерактивний простий алгоритм злиття для об’єднання файлів. Це буде
використовувати як ліву, так і праву сторону для конфліктних регіонів. Ніяких маркерів не вставлено.

Внутрішні інструменти завжди доступні і не вимагають графічного інтерфейсу, але за замовчуванням не будуть
обробляти символічні посилання або двійкові файли.

Вибір a злиття інструмент
Mercurial використовує ці правила, вирішуючи, який інструмент об’єднання використовувати:

1. Якщо інструмент було вказано з параметром --tool для об'єднання або розв'язання, він використовується.
Якщо це назва інструмента в конфігурації інструментів злиття, його конфігурація є
використаний. Інакше вказаний інструмент повинен виконуватися оболонкою.

2. Якщо HGMERGE змінна середовища присутня, її значення використовується і має бути
виконується оболонкою.

3. Якщо ім’я файлу, який потрібно об’єднати, відповідає будь-якому із шаблонів у файлі
розділ конфігурації шаблонів злиття, перший інструмент злиття, який можна використовувати, відповідний a
використовується відповідний шаблон. Тут двійкові можливості інструменту злиття відсутні
розглянуто.

4. Якщо встановлено ui.merge, він буде розглядатися наступним. Якщо значення не є ім’ям a
налаштований інструмент, використовується вказане значення, яке має виконуватися оболонкою.
В іншому випадку використовується названий інструмент, якщо його можна використовувати.

5. Якщо в розділі конфігурації інструментів злиття є якісь корисні інструменти злиття, то один
з найвищим пріоритетом використовується.

6. Якщо програма імен hgmerge можна знайти в системі, вона використовується - але це буде
за замовчуванням не використовуватися для символічних посилань і бінарних файлів.

7. Якщо файл, який потрібно об'єднати, не є двійковим і не є символічним посиланням, то внутрішній : об'єднати is
використаний

8. Злиття файлу не вдається, і його потрібно вирішити перед фіксацією.

Примітка. Після вибору програми об’єднання Mercurial за замовчуванням намагатиметься об’єднати
файли спочатку за допомогою простого алгоритму злиття. Тільки якщо це не вдасться через
конфліктні зміни Mercurial фактично виконає програму злиття. Чи потрібно
Використовуйте простий алгоритм злиття, спочатку можна керувати налаштуванням попереднього об’єднання
інструмент злиття. Premerge увімкнено за замовчуванням, якщо файл не є двійковим або a
символічне посилання.

Перегляньте розділи інструментів злиття та інтерфейсу користувача hgrc(5) для детальної інформації про конфігурацію злиття
інструментів.

УКАЗАННЯ БАГАТО РЕВІЗІЇ

Якщо Mercurial приймає більше однієї редакції, їх можна вказати окремо або
надається як топологічно безперервний діапазон, розділений символом ":".

Синтаксис нотації діапазону: [BEGIN]:[END], де BEGIN і END – це редакція
ідентифікатори. І BEGIN, і END є необов’язковими. Якщо BEGIN не вказано, він за замовчуванням
номер редакції 0. Якщо END не вказано, за замовчуванням буде підказка. Діапазон ":" таким чином
означає "усі редакції".

Якщо BEGIN більше за END, редакції обробляються у зворотному порядку.

Діапазон діє як закритий інтервал. Це означає, що діапазон 3:5 дає 3, 4 і 5.
Аналогічно, діапазон 9:6 дає 9, 8, 7 і 6.

Фото ІМ'Я ПАРТНЕРИ

Mercurial приймає кілька позначень для ідентифікації одного або кількох файлів одночасно.

За замовчуванням Mercurial розглядає імена файлів як розширені шаблони glob у стилі оболонки.

Альтернативні позначення шаблону повинні бути вказано явно.

Примітка Шаблони, зазначені в .hgignore не вкорінені. Будь ласка, дивіться hg допомога hgnore та цінності
подробиці

Щоб використовувати звичайне ім’я шляху без відповідності шаблону, почніть його з шлях:. Ці шляхи
імена повинні повністю збігатися, починаючи з кореня поточного сховища.

Щоб використовувати розширений глобус, почніть ім’я з глобус:. Глоби кореняться в поточному
довідник; глобус, наприклад *.c буде відповідати лише файлам у поточному каталозі, які закінчуються на
.c.

Підтримувані розширення синтаксису glob ** щоб відповідати будь-якому рядку між роздільниками шляхів і
{a,b} означати «а чи б».

Щоб використовувати регулярний вираз Perl/Python, почніть ім’я з повторно:. Відповідність шаблону регулярного виразу
прив’язується до кореня сховища.

Щоб прочитати шаблони імен із файлу, використовуйте файл списку: or файл списку0:. Останній розраховує на нуль
розмежовані шаблони, тоді як перший очікує переведення рядків. Кожен рядок, прочитаний з файлу
сам розглядається як шаблон файлу.

Щоб прочитати набір шаблонів з файлу, використовуйте включати: or підключати:. включати: використовуватиму всі
шаблони з заданого файлу та обробляти їх так, ніби вони були передані вручну.
підключати: застосовуватиме шаблони лише до файлів, які знаходяться під підпорядкованим включенням
каталог файлу. Подивитися hg допомога hgnore щоб дізнатися більше про формат цих файлів.

Усі візерунки, крім глобус: вказано в командному рядку (не для -I or -X варіанти), може
відповідати також каталогам: файли у відповідних каталогах розглядаються як відповідні.

Прості приклади:

path:foo/bar рядок імен у каталозі з іменем foo у корені
репозиторію
path:path:назва файлу або каталогу під назвою "path:name"

Приклади Glob:

glob:*.c будь-яке ім'я, що закінчується на ".c" у поточному каталозі
*.c будь-яке ім'я, яке закінчується на ".c" у поточному каталозі
**.c будь-яке ім'я, що закінчується на ".c" у будь-якому підкаталозі
поточний каталог, включаючи самого себе.
foo/*.c будь-яке ім'я, що закінчується на ".c" у каталозі foo
foo/**.c будь-яке ім'я, що закінчується на ".c" у будь-якому підкаталозі foo
включаючи себе.

Приклади регулярного виразу:

re:.*\.c$ будь-яке ім'я, яке закінчується на ".c", будь-де в сховищі

Приклади файлів:

listfile:list.txt читати список із list.txt з одним шаблоном файлу на рядок
listfile0:list.txt читання списку з list.txt з нульовими роздільниками байтів

Дивіться також hg допомога набори файлів.

Включіть приклади:

include:path/to/mypatternfile зчитує шаблони, які застосовуються до всіх шляхів
subinclude:path/to/subignorefile читає шаблони спеціально для шляхів у файлі
підкаталог

РОБОЧА З ФАЗИ

Що він має фази?
Фази — це система відстеження того, які набори змін були або мають бути спільними. Це
допомагає запобігти поширеним помилкам при зміні історії (наприклад, за допомогою mq або rebase
розширення).

Кожен набір змін у сховищі проходить одну з наступних фаз:

· public : набір змін видно на загальнодоступному сервері

· чернетка : набір змін ще не опубліковано

· секрет: набір змін не повинен бути переміщений, витягнутий або клонований

Ці фази впорядковані (public < draft < secret), і жодний набір змін не може бути в нижчому
фазі, ніж її предки. Наприклад, якщо набір змін є загальнодоступним, усі його предки є загальнодоступними
також публічні. Нарешті, фази набору змін слід змінювати лише на публічну фазу.

Як він має фаз керував?
Здебільшого фази повинні працювати прозоро. За замовчуванням набір змін створюється в
фазу чернетки і переміщається в публічну фазу, коли її переміщують до іншої
сховище

Як тільки набори змін стануть загальнодоступними, такі розширення, як mq і rebase, відмовляться працювати
щоб запобігти створенню повторюваних наборів змін. Фазами також можна керувати вручну
з hg фаза команда, якщо потрібно. Подивитися hg допомога -v фаза для прикладів.

Щоб зробити ваші коміти секретними за замовчуванням, помістіть це у свій конфігураційний файл:

[фази]
new-commit = секрет

Етапи та сервери
Як правило, всі сервери є видавнича за замовчуванням. Це означає:

- усі чернеткові набори змін, які витягуються або клонуються, відображаються в фазі
публічно на клієнті

- усі переміщені чернеткові набори змін відображаються як загальнодоступні на обох
клієнт і сервер

- секретні набори змін не передаються, не витягуються або клонуються

Примітка. Вилучення чернетки набору змін із сервера публікації не позначає його як загальнодоступного
на стороні сервера через природу pull тільки для читання.

Іноді може виявитися бажаним натиснути та витягнути набори змін у фазі чернетки для спільного використання
незавершена робота. Це можна зробити, налаштувавши репозиторій, щоб вимкнути публікацію в його
файл конфігурації:

[фази]
опублікувати = Неправда

Читати hg допомога конфиг для отримання додаткової інформації про конфігураційні файли.

Примітка. Сервери, на яких працюють старіші версії Mercurial, розглядаються як публікації.

Примітка. Набори змін у секретній фазі не обмінюються із сервером. Це стосується їх
вміст: імена файлів, вміст файлів і метадані набору змін. З технічних причин,
ідентифікатор (наприклад, d825e4025e39) секретного набору змін може передаватися
сервера.

прикладів
· перелік наборів змін у чернетці або секретній фазі:

hg log -r "не публічний()"

· змінити всі секретні набори змін на чернетки:

фаза hg --draft "secret()"

· примусово перемістити поточний набір змін і нащадків з загальнодоступного в чернетку:

фаза ртутного тиску --сила --тяга .

· показати список ревізій та фаз набору змін:

hg log --template "{rev} {phase}\n"

· повторно синхронізувати чернеткові набори змін щодо віддаленого сховища:

фаза hg -fd "вихідна (URL)"

Читати hg допомога фаза для отримання додаткової інформації про ручне маніпулювання фазами.

УКАЗАННЯ SINGLE РЕВІЗІЇ

Mercurial підтримує кілька способів вказувати окремі редакції.

Просте ціле число розглядається як номер редакції. Цілі від’ємні числа розглядаються як
послідовні зміщення від вершини, причому -1 позначає наконечник, -2 позначає попередню редакцію
до кінчика і так далі.

40-значний шістнадцятковий рядок розглядається як унікальний ідентифікатор редакції.

Шістнадцятковий рядок довжиною менше 40 символів розглядається як унікальна версія
ідентифікатор і згадується як ідентифікатор короткої форми. Це лише короткий ідентифікатор
дійсний, якщо він є префіксом рівно одного повнорозмірного ідентифікатора.

Будь-який інший рядок розглядається як закладка, тег або ім’я гілки. Закладка є рухомою
вказівник на ревізію. Тег – це постійна назва, пов’язана з версією. Назва філії
позначає саму відкриту головку гілки цієї гілки - або якщо всі вони закриті, то
найзакрита головка гілки. Назви закладок, тегів і гілок не повинні містити
символ ":".

Зарезервована назва "tip" завжди ідентифікує останню редакцію.

Зарезервована назва "null" вказує на нульову версію. Це перегляд порожнього
репозиторій, і батьківська версія версії 0.

Зарезервована назва "." вказує батьківський робочий каталог. Якщо робочого каталогу немає
перевірено, це еквівалентно null. Якщо виконується незафіксоване злиття, "." є
перегляд першого з батьків.

УКАЗАННЯ ПЕРЕГЛЯД НАБОРИ

Mercurial підтримує функціональну мову для вибору набору ревізій.

Мова підтримує ряд предикатів, які об’єднуються за допомогою інфіксних операторів.
Для групування можна використовувати круглі дужки.

Ідентифікатори, такі як назви гілок, можуть потребувати лапок з одинарними або подвійними лапками, якщо вони є
містять такі символи, як - або якщо вони збігаються з одним із попередньо визначених предикатів.

Спеціальні символи можна використовувати в ідентифікаторах у лапках, екрануючи їх, наприклад, \n is
інтерпретується як новий рядок. Щоб запобігти їх інтерпретації, рядки можуть мати префікс
з r, напр г'...'.

Існує єдиний оператор-префікс:

НЕ x

Набори змін не в x. Коротка форма є ! x.

Це підтримувані інфіксні оператори:

x::y

Діапазон DAG, що означає всі набори змін, які є нащадками x і предками y,
включаючи самі x і y. Якщо першу кінцеву точку опустити, це еквівалентно
до предки (у), якщо другий не вказано, це еквівалентно нащадки (x).

Альтернативний синтаксис х..у.

x:y

Усі набори змін з номерами ревізій між x і y, обидва включно. Або
кінцеву точку можна не використовувати, вони за замовчуванням мають значення 0 і tip.

x та y

Перетин наборів змін у x і y. Коротка форма є x & y.

x or y

Об'єднання наборів змін у x і y. Є дві альтернативні короткі форми: x | y
та x + y.

x - y

Набори змін у x, але не в y.

x^n

n-й батько x, n == 0, 1 або 2. Для n == 0, x; для n == 1, перший батько
кожного набору змін у x; для n == 2, другий батьківський набір змін у x.

x~n

n-й перший предок x; х~0 є х; х~3 is x^^^.

Існує один постфіксний оператор:

x^

Дорівнює х^1, перший батько кожного набору змін у x.

Підтримуються такі предикати:

додає (шаблон)

Набори змін, які додають шаблон відповідності файлу.

Шаблон без явного типу, як глобус: Очікується, що буде відносно
поточного каталогу та відповідність файлу чи каталогу.

всі ()

Усі набори змін, такі ж як 0:порада.

предок (*набір змін)

Найбільший загальний предок наборів змін.

Приймає 0 або більше наборів змін. Поверне порожній список, якщо не передані аргументи.
Найбільшим загальним предком окремого набору змін є цей набір змін.

предки (набір)

Набори змін, які є предками набору змін у наборі.

автор (рядок)

Псевдонім для користувач (рядок).

бісекта (рядок)

Набори змін, позначені у вказаному статусі бісекти:

· добре, поганий, пропускати: Csets явно позначено як добре/погано/пропустити

· товари, погано : набори топологічно добре/погано

· діапазон : ксети, які беруть участь у діленні навпіл

· обрізаний : набори, які є товарами, поганими або пропущеними

· неперевірені : csets, доля яких поки невідома

· ігноруються : Csets ігнорується через топологію DAG

· ток : Cset, який зараз ділиться навпіл

закладка ([ім'я])

Названа закладка або всі закладки.

If ім'я починається з повторно:, решта назви розглядається як звичайна
вираз. Щоб відповідати закладці, яка насправді починається з повторно:, використовуйте префікс
буквальне:.

гілка (рядок or встановити)

Усі набори змін, що належать до даної гілки або гілок даної
набори змін.

If рядок починається з повторно:, решта назви розглядається як звичайна
вираз. Щоб відповідати гілці, яка насправді починається з повторно:, використовуйте префікс
буквальне:.

точка розгалуження()

Набори змін для кількох дітей.

зіткнувся()

Змінювані набори змін, позначені як наступники загальнодоступних наборів змін.

Можуть бути лише непублічні та не застарілі набори змін зіткнувся.

bundle()

Набори змін у комплекті.

Bundle має бути визначений параметром -R.

діти (комплект)

Дочірні набори змін у наборі.

зачинено()

Набір змін закритий.

містить (шаблон)

Маніфест редакції містить шаблон відповідності файлу (але може не змінювати його).
Читати hg допомога моделі для отримання інформації про шаблони файлів.

Шаблон без явного типу, як глобус: Очікується, що буде відносно
поточного каталогу та точно відповідати файлу для ефективності.

конвертований([ідентифікатор])

Набори змін, перетворені з заданого ідентифікатора в старому сховищі, якщо є, або
всі перетворені набори змін, якщо не вказано ідентифікатор.

дата (інтервал)

Набори змін у межах інтервалу, див hg допомога дати.

desc(рядок)

Шукати повідомлення про фіксацію для рядка. Збіг не чутливий до регістру.

нащадки (множина)

Набори змін, які є нащадками наборів змін у наборі.

призначення ([набір])

Набори змін, створені шляхом трансплантації, пересадки або перебазування, за допомогою
дані редакції, зазначені як джерело. Пропустити необов'язковий набір - те саме, що
передаючи все().

дивергентний()

Остаточні наступники наборів змін з альтернативним набором кінцевих наступників.

чернетка()

Набір змін у фазі чернетки.

вимерлий()

Лише застарілі набори змін із застарілими нащадками.

додатково (етикетка, [значення])

Набори змін із заданою міткою в додаткових метаданих із заданим необов’язковим
value.

If значення починається з повторно:, залишок значення розглядається як звичайний
вираз. Щоб відповідати значенню, яке насправді починається з повторно:, використовуйте префікс
буквальне:.

файл (шаблон)

Набори змін, що впливають на файли, відповідні шаблону.

Щоб отримати швидший, але менш точний результат, розгляньте можливість використання filelog() замість цього.

Цей предикат використовує глобус: як тип шаблону за замовчуванням.

журнал файлів (шаблон)

Набори змін підключені до вказаного журналу файлів.

З міркувань продуктивності відвідує лише версії, зазначені в журналі файлів на рівні файлу,
а не фільтрувати всі набори змін (набагато швидше, але не включає
видаляє або повторює зміни). Для більш повільного та більш точного результату використовуйте файл().

Шаблон без явного типу, як глобус: Очікується, що буде відносно
поточного каталогу та точно відповідати файлу для ефективності.

Якщо якийсь linkrev вказує на редакції, відфільтровані за поточним переглядом, ми спрацюємо
навколо нього, щоб повернути невідфільтроване значення.

перший (набір, [n])

Псевдонім для limit().

слідувати ([шаблон])

Псевдонім для ::. (предки першого батька робочого каталогу). Якщо візерунок
вказано, відслідковуються історії файлів, що відповідають заданому шаблону, в т.ч
копії.

grep (регулярний вираз)

Люблю ключове слово (рядок) але приймає регулярний вираз. Використовуйте grep(r'...') для забезпечення спеціальної втечі
символи обробляються правильно. На відміну від ключове слово (рядок), збіг є
з урахуванням регістру.

керівник()

Набір змін — це названа голова гілки.

головки (набір)

Члени набору без дітей у наборі.

прихований()

Приховані набори змін.

id (рядок)

Редакція неоднозначно визначена за допомогою даного префікса шістнадцяткового рядка.

ключове слово (рядок)

Знайдіть рядок у повідомленнях фіксації, імені користувача та іменах змінених файлів. Матч
нечутливий до регістру.

останній(набір, [n])

Останні n членів набору, за замовчуванням 1.

ліміт(set[, n[, зміщення]])

Перші n членів набору, за замовчуванням 1, починаючи зі зміщення.

відповідність (перегляд [, поле])

Набори змін, у яких заданий набір полів відповідає набору полів у вибраному
доопрацювання або набір.

Щоб знайти відповідність більш ніж одному полю, передайте список полів для відповідності, розділених пробілами
(напр автор description).

Дійсними полями є більшість звичайних полів редакції та деякі спеціальні поля.

Поля звичайного перегляду є description, автор, філія, дата, файли, фаза,
батьки, підстан, користувач та різниця. Зверніть увагу на це автор та користувач є синонімами. різниця
посилається на зміст ревізії. Дві редакції, що відповідають їхнім різниця буде також
відповідати їхнім файли.

Спеціальні поля є резюме та метадані: резюме відповідає першому рядку
опису метадані є еквівалентним відповідності description користувач дата (тобто це
відповідає основним полям метаданих).

метадані це поле за замовчуванням, яке використовується, коли поля не вказано. Ти можеш
відповідати більше ніж одному полю одночасно.

максимум (набір)

Набір змін із найвищим номером версії в наборі.

merge ()

Набір змін – це об’єднаний набір змін.

хв (набір)

Набір змін із найменшим номером версії в наборі.

модифікує (шаблон)

Набори змін, що змінюють файли, відповідні шаблону.

Шаблон без явного типу, як глобус: Очікується, що буде відносно
поточного каталогу та відповідність файлу чи каталогу.

названий (простір імен)

Набори змін у заданому просторі імен.

If простору імен починається з повторно:, залишок рядка розглядається як звичайний
вираз. Щоб відповідати простору імен, який насправді починається з повторно:, використовуйте префікс
буквальне:.

застарілий()

Змінюваний набір змін у новішій версії.

тільки (встановити, [набір])

Набори змін, які є предками першого набору, які не є предками жодного іншого
голова в репо. Якщо вказано другий набір, результатом є предки
перший набір, який не є предками другого набору (тобто :: - :: ).

походження ([набір])

Набори змін, які були вказані як джерело для трансплантатів, пересадок або повторних баз
які створили дані редакції. Пропуск необов'язкового набору те саме, що і передача
все(). Якщо набір змін, створений цими операціями, сам вказано як джерело
для однієї з цих операцій є лише вихідний набір змін для першої операції
Вибраний

вихідний([шлях])

Набори змін не знайдені у зазначеному цільовому сховищі або натисканні за замовчуванням
Місцезнаходження.

p1([набір])

Перший батьківський пакет змін у наборі або робочому каталозі.

p2([набір])

Другий батьківський пакет змін у наборі або робочому каталозі.

батьки ([набір])

Набір усіх батьків для всіх наборів змін у наборі або робочому каталозі.

подарунок (набір)

Порожній набір, якщо жодна редакція в наборі не знайдена; в іншому випадку всі редакції в наборі.

Якщо жодної із зазначених ревізій немає в локальному сховищі, запит є
зазвичай переривається. Але цей предикат дозволяє продовжити запит навіть у такому
випадків.

публічний()

Набір змін у публічній фазі.

дистанційно ([id [,шлях]])

Локальна версія, яка відповідає заданому ідентифікатору у віддаленому сховищі, якщо
присутній. Тут '.' ідентифікатор є синонімом поточної локальної гілки.

видаляє (шаблон)

Набори змін, які видаляють файли, що відповідають шаблону.

Шаблон без явного типу, як глобус: Очікується, що буде відносно
поточного каталогу та відповідність файлу чи каталогу.

оберт (число)

Версія з заданим числовим ідентифікатором.

зворотний (набір)

Зворотний порядок набору.

коріння (набір)

Набори змін у наборі без батьківського набору змін у наборі.

секрет()

Набір змін у секретній фазі.

сортувати(набір[, [-]клавіша...])

Сортування налаштовано за ключами. Порядок сортування за замовчуванням — зростання, вкажіть ключ як -кілька до
сортувати в порядку спадання.

Ключі можуть бути:

· об для номера ревізії,

· філія для назви філії,

· за спаданням для повідомлення про фіксацію (опис),

· користувач для імені користувача (автор можна використовувати як псевдонім),

· дата на дату фіксації

subrepo([шаблон])

Набори змін, які додають, змінюють або видаляють заданий підпункт. Якщо немає шаблону subbrepo
іменований, повертаються будь-які зміни підпорядкувань.

тег ([ім'я])

Зазначений тег за іменем або всі позначені версії, якщо ім’я не вказано.

If ім'я починається з повторно:, решта назви розглядається як звичайна
вираз. Щоб відповідати тегу, який насправді починається з повторно:, використовуйте префікс буквальне:.

нестабільний()

Незастарілі набори змін із застарілими предками.

користувач (рядок)

Ім'я користувача містить рядок. Збіг не чутливий до регістру.

If рядок починається з повторно:, залишок рядка розглядається як звичайний
вираз. Щоб зіставити користувача, який насправді містить повторно:, використовуйте префікс буквальне:.

Нові предикати (відомі як "псевдоніми") можна визначити, використовуючи будь-яку комбінацію існуючих
предикати або інші псевдоніми. Визначення псевдоніма виглядає так:

=

в revsetalias розділ файлу конфігурації Mercurial. Аргументи форми $1,
$2, тощо. замінюються з псевдоніма у визначення.

Наприклад,

[revsetalias]
h = голови()
d($1) = сортування ($1, дата)
rs($1, $2) = зворотний (сортувати ($1, $2))

визначає три псевдоніми, h, d та rs. rs(0:підказка, автор) точно еквівалентно
зворотний(сортувати(0:підказка, автор)).

Інфіксний оператор ## може об’єднувати рядки та ідентифікатори в один рядок. Наприклад:

[revsetalias]
issue($1) = grep(r'\bissue[ :]?' ## $1 ## r'\b|\bbug\(' ## $1 ## r'\)')

питання(1234) еквівалентна grep(r'\bissue[ :]?1234\b|\bbbug\(1234\)') в цьому випадку. Це
відповідає всім "issue 1234", "issue:1234", "issue1234" і "помилка(1234) ".

Усі інші префіксні, інфіксні та постфіксні оператори мають нижчий пріоритет, ніж ##, Наприклад, $1
## $ 2 ~ 2 еквівалентна ($ 1 ## $2)~2.

Еквіваленти командного рядка для hg журнал:

-f -> ::.
-dx -> дата(x)
-kx -> ключове слово(x)
-m -> об'єднати()
-ux -> користувач (x)
-bx -> гілка (x)
-P x -> !::x
-lx -> межа (вираз, x)

Деякі зразки запитів:

· Набори змін у гілці за замовчуванням:

hg log -r "гілка (за замовчуванням)"

· Набори змін у гілці за замовчуванням, починаючи з тегу 1.5 (за винятком злиття):

hg log -r "гілка (за замовчуванням) і 1.5:: і не merge()"

· Відкриті голови:

hg log -r "голова() і не закрита()"

· Набори змін між тегами 1.3 та 1.5 із згадкою про "помилку", яка впливає hgext/*:

hg log -r "1.3::1.5 і ключове слово(помилка) і файл('hgext/*')"

· Набори змін, внесені в травні 2008 року, відсортовані за користувачем:

hg log -r "сортувати (дата ('травень 2008'), користувач)"

· Набори змін, у яких згадується "помилка" або "проблема", які не містяться в позначеному випуску:

hg log -r "(ключове слово(помилка) або ключове слово(проблема)), а не предки(тег())"

ВИКОРИСТАННЯ РТУТНИЙ З СЦЕНАРІЇ І АВТОМАТИКА

Зазвичай машини (на відміну від людей) споживають Mercurial. Ця тема довідки
описує деякі міркування щодо взаємодії машин із Mercurial.

Вибір an інтерфейс
Машини мають вибір із кількох методів взаємодії з Mercurial. До них належать:

· Виконання hg процес

· Запити до HTTP-сервера

· Виклик до командного сервера

Виконання hg процеси дуже схожі на те, як люди взаємодіють з Mercurial в оболонці.
Вам це вже має бути знайоме.

hg служити можна використовувати для запуску сервера. За замовчуванням це запускає HTTP-сервер "hgweb".
Цей HTTP-сервер підтримує машиночитаний вихід, наприклад JSON. Детальніше див hg
допомога hgweb.

hg служити також можна запустити "командний сервер". Клієнти можуть підключатися до цього сервера і видавати
Mercurial командує за спеціальним протоколом. Щоб дізнатися більше про командний сервер,
включаючи посилання на клієнтські бібліотеки, див. https://mercurial.selenic.com/wiki/CommandServer.

hg служити інтерфейси на основі (hgweb і командні сервери) мають перевагу перед простими
hg викликів процесів, оскільки вони, ймовірно, більш ефективні. Це тому, що є
значні накладні витрати на створення нових процесів Python.

Порада Якщо вам потрібно викликати кілька hg процеси в короткі терміни та/або продуктивність є
Важливо для вас використання інтерфейсу на основі сервера.

Навколишнє середовище Змінні
Як задокументовано в hg допомога навколишнє середовище, різні змінні середовища впливають на
робота Mercurial. Наступне особливо актуально для машин, що споживають
Меркуріал:

HGPLAIN
Якщо не встановлено, на вихід Mercurial можуть впливати налаштування конфігурації, які
впливати на його кодування, докладний режим, локалізацію тощо.

Машинам настійно рекомендується встановлювати цю змінну під час виклику hg
процесів.

HGENCODING
Якщо не встановлено, локаль, яку використовує Mercurial, буде виявлена ​​з середовища. Якщо
визначена локаль не підтримує відображення певних символів, Mercurial може
відображати ці послідовності символів неправильно (часто використовуючи «?» як заповнювач
для недійсних символів у поточній мові).

Явне встановлення цієї змінної середовища є гарною практикою, яку можна гарантувати
послідовні результати. "utf-8" є хорошим вибором для UNIX-подібних середовищ.

HGRCPATH
Якщо не встановлено, Mercurial успадкує параметри конфігурації з файлів конфігурації за допомогою
процес, описаний в hg допомога конфиг. Це включає в себе успадкування користувацького або загальносистемного
файли конфігурації.

Коли потрібний максимальний контроль над конфігурацією Mercurial, значення
HGRCPATH можна встановити як явний файл із відомими хорошими конфігураціями. У рідкісних випадках в
значення можна встановити на порожній файл або нульовий пристрій (часто / dev / null) обійти
завантаження будь-яких файлів конфігурації користувача або системи. Зауважте, що ці підходи можуть мати
непередбачувані наслідки, оскільки файли конфігурації користувача та системи часто визначають речі
наприклад ім’я користувача та розширення, які можуть знадобитися для взаємодії з a
сховище

споживає Command Вихід
Зазвичай машинам потрібно аналізувати вихідні дані команд Mercurial на відповідність
дані. У цьому розділі описано різні методики для цього.

Parsing Сировина Command Вихід
Ймовірно, найпростішим і найефективнішим рішенням для використання виводу команди є просто
викликати hg команди так само, як і користувач, і проаналізуйте їхній результат.

Вихід багатьох команд можна легко проаналізувати за допомогою таких інструментів, як GREP, sed та awk.

Потенційним недоліком виводу команд аналізу є те, що вихід команд може змінюватися
коли Mercurial буде оновлено. У той час як Mercurial, як правило, прагне до сильної назад
сумісність, вихід команди іноді змінюється. Проведення тестів для вашого автоматизованого
взаємодії з hg команд, як правило, рекомендується, але ще важливіше, коли
задіяний синтаксичний аналіз вихідних даних команд.

використання шаблони до Контроль Вихід
Багато hg команди підтримують шаблонизований вихід через -T/--шаблон аргумент. Детальніше див
hg допомога Шаблони.

Шаблони корисні для явного керування виводом, щоб отримати саме дані
ви хочете відформатувати, як ви хочете. Наприклад, журнал -T {вузол}\n можна використовувати для друку а
Список вузлів набору змін із роздільниками нового рядка замість персоналізованого виведення, що містить
автори, дати, описи тощо.

Порада Якщо розбір вихідних даних команди надто складний, подумайте про використання шаблонів для створення
твоє життя легше.

Команда -T/--шаблон аргумент дозволяє вказати попередньо визначені стилі. Кораблі Mercurial з
машиночитані стилі json та XML, які забезпечують вихід JSON і XML відповідно.
Вони корисні для створення результатів, які машиночитані як є.

Важливий
Команда json та XML стилі вважаються експериментальними. Хоча вони можуть бути привабливими
щоб використовувати для легкого отримання машиночитаного результату, їх поведінка може змінитися
наступні версії.

Ці стилі також можуть дати несподівані результати при роботі з певними
кодування. Mercurial розглядає такі речі, як імена файлів, як ряд байтів і
нормалізації певних послідовностей байтів до JSON або XML з певними параметрами кодування
може призвести до несподіванок.

Command сервер Вихід
Якщо ви використовуєте командний сервер для взаємодії з Mercurial, ви, ймовірно, використовуєте існуючий
бібліотека/API, яка абстрагує деталі реалізації командного сервера. Якщо так, то це
рівень інтерфейсу може виконувати синтаксичний аналіз за вас, заощаджуючи вам роботу по його реалізації
самі

Вихід Багатослівність
Команди часто мають різну детальність виводу, навіть коли використовуються машиночитані стилі
використовуваний (напр -T json). Додавання -v/--дослівно та --відлагоджувати до аргументів команди можна
збільшити обсяг даних, які розкриває Mercurial.

Альтернативний спосіб отримати потрібні дані — це явно вказати шаблон.

Інше теми
ревсець
Набори ревізій — це функціональна мова запитів для вибору набору ревізій.
Думайте про це як про SQL для репозиторіїв Mercurial. Revsets корисні для запитів
репозиторії для конкретних даних.

Читати hg допомога ревсець для більш.

частка розширення
Команда частка розширення надає функціональні можливості для спільного використання даних репозитарію
кілька робочих примірників. Він навіть може автоматично "об'єднати" сховище для логіки
пов’язані репозиторії під час клонування.

Налаштування частка розширення може призвести до значного використання ресурсів
зменшення, особливо навколо дискового простору та мережі. Це особливо вірно
для середовищ безперервної інтеграції (CI).

Читати hg допомога -e частка для більш.

СУБРЕПОЗИТОРІЇ

Підсховища дозволяють вкладати зовнішні репозиторії або проекти в батьківський Mercurial
репозиторію, і змусити команди працювати з ними як групою.

Наразі Mercurial підтримує підрепозиторії Mercurial, Git і Subversion.

Субрепозиторії складаються з трьох компонентів:

1. Вкладені перевірки сховища. Вони можуть з'являтися в будь-якому місці в батьківському робочому каталозі.

2. Вкладені посилання на репозиторій. Вони визначені в .hgsub, який слід помістити в
корінь робочого каталогу та вкажіть, звідки беруться перевірки субрепозиторію.
На субрепозиторії Mercurial посилаються як:

path/to/nested = https://example.com/nested/repo/path

Також підтримуються підпорядкування Git і Subversion:

path/to/nested = [git]git://example.com/nested/repo/path
шлях/до/вкладений = [svn]https://example.com/nested/trunk/path

де шлях/до/вкладений є місцем оформлення покупки відносно батьківського кореня Mercurial,
та https://example.com/nested/repo/path це вихідний шлях до репозитарію. Джерело може
також посилання на шлях файлової системи.

Зверніть увагу, що .hgsub не існує за замовчуванням у сховищах Mercurial, ви повинні
створіть та додайте його до батьківського сховища перед використанням підрепозиторіїв.

3. Вкладені стани сховища. Вони визначені в .hgsubstate, який розміщується в корені
робочого каталогу та фіксуйте всю інформацію, необхідну для відновлення
підрепозиторії до стану, в якому вони були внесені в набір змін батьківського сховища.
Mercurial автоматично записує стани вкладених сховищ під час фіксації в
батьківський репозиторій.

примітки
Команда .hgsubstate файл не слід редагувати вручну.

Додавання a Підрепозитарій
If .hgsub не існує, створіть його та додайте до батьківського сховища. Клонування або оформлення замовлення
зовнішні проекти, де ви хочете, щоб він існував у батьківському репозиторії. Редагувати .hgsub та
додайте запис підрепозиторію, як описано вище. У цей момент підрепозиторій є
відстежується, і наступний коміт запише його стан .hgsubstate і прив’язати його до
здійснений набір змін.

Синхронізація a Підрепозитарій
Subrepos не відстежує автоматично останні зміни своїх джерел. Натомість вони
оновлюються до набору змін, який відповідає набору змін, отриманому в
набір змін верхнього рівня. Завдяки цьому розробники завжди отримують узгоджений набір сумісного коду
і бібліотеки, коли вони оновлюються.

Таким чином, оновлення subrepos є ручним процесом. Просто перевірте цільове підпорядкування на сторінці
бажану редакцію, перевірте в сховищі верхнього рівня, а потім зафіксуйте в батьківському репозиторії
запишіть нову комбінацію.

видалення a Підрепозитарій
Щоб видалити підрепозиторій із батьківського сховища, видаліть його посилання .hgsub,
потім видаліть його файли.

Взаємодія з ртутний Команди
додавати add не повторюється в підпорядкуванні, якщо не вказано -S/--subrepos. Однак, якщо
Ви вказуєте повний шлях до файлу в підпорядкуванні, він буде доданий навіть без нього
-S/--вказані підпункти. Subversion subrepositories наразі мовчазний
ігнорується.

видалення адреси
addremove не повертається до підпорядкувань, якщо не вказано -S/--subrepos.
Однак, якщо ви вкажете повний шлях до каталогу в підпорядкуванні, addremove буде
виконуватися на ньому навіть без вказівки -S/--subrepos. Git і Subversion
субрепозиторії надрукують попередження та продовжать.

архів
архів не повторюється в підрепозиторіях, якщо не вказано -S/--subrepos.

як cat наразі обробляє лише точні збіги файлів у підрахунках. Підривна діяльність
підрепозиторії наразі ігноруються.

commit commit створює послідовний знімок стану всього проекту та його
підрепозиторії. Якщо якісь підрепозиторії були змінені, Mercurial припинить роботу.
Замість цього можна зробити так, щоб Mercurial фіксував усі модифіковані підрепозиторії, вказавши
-S/--subrepos, або встановлення "ui.commitsubrepos=True" у файлі конфігурації (див. hg
допомога конфиг). Після того, як модифікованих субрепозиторіїв більше немає, він записує
їх стан і, нарешті, фіксує його в батьківському репозиторії. --addremove
параметр також шанує параметр -S/--subrepos. Однак Git і Subversion
підрепозиторії надрукують попередження та перервуться.

різниця diff не повторюється в підпорядкуванні, якщо не вказано -S/--subrepos. Зміни є
відображаються, як зазвичай, на елементах підрепозиторіїв. Subversion subrepositories є
наразі мовчки ігноруються.

файли файли не повертаються в підпорядкування, якщо не вказано -S/--subrepos. однак,
якщо ви вкажете повний шлях до файлу або каталогу в підпорядкуванні, він буде
відображається навіть без вказівки -S/--subbrepos. Git і Subversion
субрепозиторії наразі мовчки ігноруються.

забувати наразі забути обробляє лише точні збіги файлів у підрядках. Git і Subversion
субрепозиторії наразі мовчки ігноруються.

що входить
вхідне не повторюється в підпорядкуванні, якщо не вказано -S/--subrepos. Git і
Підрепозиторії Subversion наразі мовчки ігноруються.

вихідний
вихідне не повторюється в підрядках, якщо не вказано -S/--підряд. Git і
Підрепозиторії Subversion наразі мовчки ігноруються.

тягнути pull не є рекурсивним, оскільки незрозуміло, що витягнути перед запуском hg оновлення
. Перелік і отримання всіх змін підрепозиторіїв, на які посилається батьківський
Витягнутий з репозиторію набори змін у кращому випадку дорогий, а в Subversion неможливо
справа

штовхати Mercurial автоматично натисне всі підрепозиторії першими, коли батьківський
репозиторій переміщається. Це забезпечує доступність нових змін у субрепозиторії
коли на нього посилаються сховища верхнього рівня. Push не можна використовувати для Subversion
підрепозиторії.

статус статус не повертається в підрепозиторії, якщо не вказано -S/--subrepos.
Зміни підрепозитарію відображаються як регулярні зміни Mercurial на
елементи субрепозиторію. Підрепозиторії Subversion наразі мовчки ігноруються.

видаляти remove не повертається в підрепозиторії, якщо не вказано -S/--subrepos.
Однак, якщо ви вкажете шлях до файлу або каталогу в підпорядкуванні, він буде видалено
навіть без -S/--subrepos. Наразі є підрепозиторії Git і Subversion
мовчки ігнорують.

оновлення update відновлює підпорядковані позиції в стані, в якому вони спочатку були зафіксовані в цільовому місці
набір змін. Якщо записаний набір змін недоступний у поточному підрепозиторії,
Mercurial спочатку затягне його перед оновленням. Це означає, що оновлення може
вимагати доступу до мережі під час використання підрепозиторіїв.

Переоформлення Підрепозиторії Джерела
Розташування джерела субрепозиторію може змінюватися протягом життя проекту, що робить посилання недійсними
зберігається в історії батьківського сховища. Щоб виправити це, можна визначити правила перепису в
батьківський репозиторій hgrc файл або в конфігурації Mercurial. Див [підшляхи] розділ в
hgrc(5) для більш детальної інформації.

ШАБЛОН ВИКОРИСТАННЯ

Mercurial дозволяє налаштувати вихід команд за допомогою шаблонів. Ви можете або
передайте шаблон або виберіть існуючий стиль шаблону з командного рядка за допомогою
--параметр шаблону.

Ви можете налаштувати вихід для будь-якої команди, схожої на журнал: log, outgoing, incoming, tip,
батьки та керівники.

Деякі вбудовані стилі комплектуються Mercurial. Їх можна перерахувати з hg журнал
--шаблон список. Приклад використання:

$ hg log -r1.0::1.1 --журнал змін шаблону

Шаблон — це фрагмент тексту з розміткою для виклику розширення змінної:

$ hg log -r1 --template "{вузол}\n"
b56ce7b07c52de7d5fd79fb89701ea538af65746

Рядки в фігурних дужках називаються ключовими словами. Доступність ключових слів залежить від
точний контекст шаблонника. Ці ключові слова зазвичай доступні для створення шаблонів a
команда, схожа на журнал:

активна закладка
рядок. Активна закладка, якщо вона пов’язана з набором змін

автор рядок. Незмінений автор набору змін.

бісект рядок. Статус поділу набору змін.

закладки
Список рядків. Будь-які закладки, пов’язані з набором змін. Також встановлює "активний",
ім'я активної закладки.

філія рядок. Назва гілки, на якій було здійснено набір змін.

зміни з самого початку
Ціле число. Усі предки не в останньому тегу.

діти
Список рядків. Діти набору змін.

дата Інформація про дату. Дата фіксації набору змін.

за спаданням рядок. Текст опису набору змін.

diffstat
рядок. Статистика змін у такому форматі: «змінені файли:
+додані/-видалені рядки"

екстракт Список dicts із ключовими, значеннями поля 'extras' цього набору змін.

файл_додає
Список рядків. Файли, додані цим набором змін.

копії файлу
Список рядків. Файли, скопійовані в цей набір змін, з їхніми джерелами.

file_copies_switch
Список рядків. Як і "file_copies", але відображається, лише якщо перемикач --copied встановлено
встановлений.

file_dels
Список рядків. Файли, видалені цим набором змін.

file_mods
Список рядків. Файли, змінені цим набором змін.

файли Список рядків. Усі файли, змінені, додані або видалені цим набором змін.

графвузол
рядок. Символ, що представляє вузол набору змін у графі ревізій ASCII

останній тег
Список рядків. Глобальні теги останнього предка з глобальними тегами
цей набір змін.

остання tagdistance
Ціле число. Найдовший шлях до останнього тегу.

просторів імен
Дикт про списки. Імена, додані до цього набору змін для кожного простору імен.

вузол рядок. Ідентифікаційний хеш набору змін у вигляді рядка з 40 шістнадцяткових цифр.

p1 вузол рядок. Ідентифікаційний хеш першого батька набору змін у вигляді 40 цифр
шістнадцятковий рядок. Якщо набір змін не має батьків, усі цифри дорівнюють 0.

p1rev Ціле число. Номер локальної версії репозиторію першого батьківського набору змін, або
-1, якщо набір змін не має батьків.

p2 вузол рядок. Ідентифікаційний хеш другого батька набору змін у вигляді 40 цифр
шістнадцятковий рядок. Якщо набір змін не має другого батька, усі цифри дорівнюють 0.

p2rev Ціле число. Номер локальної версії репозиторію другого батьківського набору змін, або
-1, якщо набір змін не має другого батька.

батьки
Список рядків. Батьки набору змін у форматі "rev:node". Якщо
набір змін має тільки одного "природного" батьківського (попередня версія) нічого не є
показано

фаза рядок. Назва фази набору змін.

phaseidx
Ціле число. Індекс фази набору змін.

об Ціле число. Номер версії локального набору змін репозиторію.

підрепо
Список рядків. Оновлені підрепозиторії в наборі змін.

теги Список рядків. Будь-які теги, пов’язані з набором змін.

Ключове слово "date" не дає читаний людиною вихід. Якщо ви хочете використовувати дату в
ваш результат, ви можете використовувати фільтр для його обробки. Фільтри – це функції, які повертають a
рядок на основі вхідної змінної. Обов’язково спочатку скористайтеся фільтром stringify
застосування фільтра введення рядків до вхідної змінної, схожої на список. Ви також можете використовувати ланцюжок
фільтри, щоб отримати бажаний результат:

$ hg tip --template "{date|isodate}\n"
2008-08-21 18:22 +0000

Список фільтрів:

addbreaks
Будь-який текст. Додати XHTML " " перед кінцем кожного рядка, крім останнього.

вік Дата. Повертає зрозумілу різницю дати/часу між заданою датою/часом і
поточну дату/час.

базове ім'я
Будь-який текст. Обробляє текст як шлях і повертає останній компонент шляху
після розбиття за допомогою роздільника шляху (ігноруючи кінцеві роздільники). Наприклад,
"foo/bar/baz" стає "baz", а "foo/bar//" стає "bar".

вважати Список або текст. Повертає довжину у вигляді цілого числа.

домен Будь-який текст. Знаходить перший рядок, схожий на адресу електронної пошти, і витягує
лише компонент домену. приклад: користувач <[захищено електронною поштою]> стає example.com.

e-mail Будь-який текст. Витягує перший рядок, схожий на адресу електронної пошти. приклад: користувач
<[захищено електронною поштою]> стає [захищено електронною поштою].

користувач електронної пошти
Будь-який текст. Повертає частину електронної адреси користувача.

бігти Будь-який текст. Замінює спеціальні символи XML/XHTML "&", "<" і ">" на XML
сутності та відфільтровує символи NUL.

заповнити 68 Будь-який текст. Обгортає текст, щоб поміститися в 68 стовпців.

заповнити 76 Будь-який текст. Обгортає текст, щоб поміститися в 76 стовпців.

перша лінія
Будь-який текст. Повертає перший рядок тексту.

гекса Будь-який текст. Перетворіть двійковий ідентифікатор вузла Mercurial в довгий шістнадцятковий
представництво.

hgdate Дата. Повертає дату у вигляді пари чисел: "1157407993 25200" (помітка часу Unix,
зміщення часового поясу).

ізодат
Дата. Повертає дату у форматі ISO 8601: «2009-08-18 13:00 +0200».

ізодатсек
Дата. Повертає дату у форматі ISO 8601, включаючи секунди: "2009-08-18 13:00:13
+0200". Дивіться також фільтр rfc3339date.

знизити Будь-який текст. Перетворює текст у нижній регістр.

непорожній
Будь-який текст. Повертає '(none)', якщо рядок порожній.

примхнути
Будь-який текст. Повертає введений текст, представлений як послідовність об’єктів XML.

людина Будь-який текст. Повертає ім’я перед адресою електронної пошти, інтерпретуючи його відповідно до RFC
5322.

revescape
Будь-який текст. Екранує всі "спеціальні" символи, крім @. Косі риски екрануються
двічі, щоб веб-сервери передчасно не вийшли з них. Наприклад, "@foo
bar/baz" стає "@foo%20bar%252Fbaz".

rfc3339date
Дата. Повертає дату, використовуючи формат дати в Інтернеті, зазначений у RFC 3339:
"2009-08-18T13:00:13+02:00".

rfc822date
Дата. Повертає дату, використовуючи той самий формат, що використовується в заголовках електронних листів: «Вт, 18 серпня 2009 р.
13:00:13 +0200».

коротка Хеш набору змін. Повертає коротку форму хеша набору змін, тобто 12 шістнадцяткових
рядок цифр.

короткий бісект
Будь-який текст. Пригощає текст як статус розділення навпіл і повертає один символ
представляє статус (G: добре, B: погано, S: пропущено, U: не перевірено, I: проігноровано).
Повертає одиничний пробіл if текст не є дійсним статусом бісекції.

короткий термін
Дата. Повертає дату типу "2006-09-18".

сплітлінії
Будь-який текст. Розбити текст на список рядків.

строфіфікувати
Будь-який тип. Перетворює значення в текст, перетворюючи значення в текст і
об'єднання їх.

stripdir
Розглядайте текст як шлях і, якщо можливо, відокремте рівень каталогу. Наприклад, "foo"
і "foo/bar" стає "foo".

табіндент
Будь-який текст. Повертає текст із кожним непорожнім рядком, крім першого, що починається
із символом табуляції.

верхній Будь-який текст. Перетворює текст у верхній регістр.

urlescape
Будь-який текст. Екранує всі "спеціальні" символи. Наприклад, "foo bar" стає
"foo%20bar".

користувач Будь-який текст. Повертає коротке представлення імені користувача або адреси електронної пошти.

Зауважте, що фільтр – це не що інше, як виклик функції, тобто expr|фільтр є еквівалентним
до фільтр (вираз).

Крім фільтрів, є деякі основні вбудовані функції:

дата(дата[, fmt])
Відформатуйте дату. Подивитися hg допомога дати для форматування рядків. За замовчуванням є дата Unix
формат, включаючи часовий пояс: "Пн, 04 вересня 15:13:13 2006 0700:XNUMX".

diff([includepattern [, шаблон виключення]])
Показати відмінність, за бажанням вказавши файли для включення чи виключення.

заповнити (текст[, ширина[, початковий ідентифікатор[, підвіска]]])
Заповніть багато абзаців необов’язковим відступом. Дивіться фільтр «заповнення».

отримати (dict, ключ)
Отримати атрибут/ключ від об’єкта. Деякі ключові слова є складними. Ця функція
дозволяє отримати значення атрибута для цих типів.

якщо (вираз, потім[, інше])
Умовно виконувати на основі результату виразу.

ifcontains(пошук, річ, потім[, інше])
Умовно виконувати залежно від того, чи є елемент "пошук" у "речі".

ifeq(вираз1, вираз 2, потім[, інше])
Умовно виконувати на основі того, чи є 2 елементи еквівалентними.

відступ (текст, indentchars[, перша лінія])
Зробить відступ у всіх непорожніх рядках символами, заданими в рядку indentchars. An
необов’язковий третій параметр замінить відступ для першого рядка лише якщо
присутній

приєднатися (список, вересень)
Об’єднайте елементи в список за допомогою роздільника.

етикетка (етикетка, вираз)
Застосуйте мітку до створеного вмісту. Вміст із нанесеною міткою може призвести до
додаткова постобробка, наприклад автоматична розфарбовування.

останній тег([шаблон])
Глобальні теги, що відповідають заданому шаблону на останніх глобальних тегах
предком цього набору змін.

локальна дата(дата[, ц])
Перетворює дату на вказаний часовий пояс. За замовчуванням є локальна дата.

блокнот (текст, ширина[, fillchar=' '[, правильно=Невірно]])
Текст заливки із символом заливки.

revset(запит[, formatargs...])
Виконайте запит на набір ревізій. Подивитися hg допомога reset.

rstdoc(текст, стиль)
Формат ReStructuredText.

найкоротший (вузол, minlength=4)
Отримайте найкоротше уявлення вузла.

починається з(шаблон, текст)
Повертає значення з аргументу "текст", якщо воно починається з вмісту з
аргумент «шаблон».

смуга (текст[, символи])
Вилучати символи з рядка. За замовчуванням знімає всі провідні та кінцеві
пробіл.

під(шаблон, заміна, вираз)
Виконайте заміну тексту за допомогою регулярних виразів.

слово (число, текст[, роздільник])
Повернути n-е слово з рядка.

Крім того, для будь-якого виразу, який повертає список, існує оператор списку:

expr % "{template}"

Як видно з наведеного вище прикладу, {шаблон} інтерпретується як шаблон. Щоб запобігти цьому
будучи інтерпретованим, ви можете використовувати escape-символ \{ або необроблений префікс рядка, г'...'.

Деякі зразки шаблонів командного рядка:

· Форматувати списки, наприклад файли:

$ hg log -r 0 --template "файли:\n{файли % ' {файл}\n'}"

· Приєднатися до списку файлів за допомогою ", ":

$ hg log -r 0 --template "файли: {join(files, ', ')}\n"

· Змініть кожен рядок опису коміту:

$ hg log --template "{splitlines(desc) % '**** {line}\n'}"

· Формат дати:

$ hg log -r 0 --template "{date(date, '%Y')}\n"

· Відображення дати в UTC:

$ hg log -r 0 --template "{localdate(date, 'UTC')|date}\n"

· Виведіть опис, встановлений на ширину заповнення 30:

$ hg log -r 0 --template "{fill(desc, 30)}"

· Використовуйте умовний для перевірки гілки за замовчуванням:

$ hg log -r 0 --template "{ifeq(гілка, 'за замовчуванням', 'на головній гілці',
'на гілці {гілки}')}\n"

· Додайте новий рядок, якщо він не порожній:

$ hg tip --template "{if(author, '{author}\n')}"

· Позначте вихідні дані для використання з розширенням кольору:

$ hg log -r 0 --template "{label('changeset.{phase}', node|short)}\n"

· Інвертуйте фільтр першого рядка, тобто все, крім першого рядка:

$ hg log -r 0 --template "{sub(r'^.*\n?\n?', '', desc)}\n"

· Відобразити вміст «додаткового» поля, по одному на рядок:

$ hg log -r 0 --template "{join(extras, '\n')}\n"

· Позначте активну закладку '*':

$ hg log --template "{bookmarks % '{bookmark}{ifeq(bookmark, active, '*')} '}\n"

· Знайдіть попередній тег-кандидат на випуск, відстань та зміни після тегу:

$hg log -r . --template "{latesttag('re:^.*-rc$') % '{tag}, {changes}, {distance}'}\n"

· Позначте батьківську робочу копію '@':

$ hg log --template "{ifcontains(rev, revset('.'), '@')}\n"

· Показати деталі батьківських версій:

$ hg log --template "{revset('parents(%d)', rev) % '{desc|firstline}\n'}"

· Показувати лише описи комітів, які починаються з "шаблон":

$ hg log --template "{startswith('template', firstline(desc))}\n"

· Надрукувати перше слово кожного рядка повідомлення про фіксацію:

$ hg log --template "{word(0, desc)}\n"

URL Шляхи

Дійсні URL-адреси мають вигляд:

локальний/файлова система/шлях[#revision]
file://local/filesystem/path[#revision]
http://[user[:pass]@]host[:port]/[path][#revision]
https://[user[:pass]@]host[:port]/[path][#revision]
ssh://[user@]host[:port]/[path][#revision]

Шляхи в локальній файловій системі можуть вказувати на репозиторії Mercurial або на пакет
файли (як створені hg пакет or hg що входить -- пучок) Дивись також hg допомога стежки.

Необов’язковий ідентифікатор після # вказує на конкретну гілку, тег або набір змін для використання
з віддаленого сховища. Дивитися також hg допомога перегляди.

Деякі функції, як-от натискання на URL-адреси http:// і https://, можливі лише за умови
функція явно ввімкнена на віддаленому сервері Mercurial.

Зауважте, що безпека URL-адрес HTTPS залежить від правильної конфігурації web.cacerts.

Деякі примітки щодо використання SSH з Mercurial:

· SSH вимагає доступного облікового запису оболонки на кінцевій машині та копії hg in
віддалений шлях або вказано як remotecmd.

· шлях за замовчуванням відноситься до домашнього каталогу віддаленого користувача. Використовуйте додаткову косу риску at
початок шляху для визначення абсолютного шляху:

ssh://example.com//tmp/repository

· Mercurial не використовує власне стиснення через SSH; правильне, що потрібно зробити, це налаштувати
це у вашому ~ / .ssh / config, наприклад:

Хост *.mylocalnetwork.example.com
Компресія №
Ведучий *
Компресія так

Або вкажіть "ssh -C" як команду ssh у файлі конфігурації або з
параметр командного рядка --ssh.

Усі ці URL-адреси можуть бути збережені у вашому файлі конфігурації з псевдонімами шляхів під файлом
розділ [шляхи] так:

[шляхи]
псевдонім1 = URL1
псевдонім2 = URL2
...

Потім ви можете використовувати псевдонім для будь-якої команди, яка використовує URL-адресу (наприклад hg тягнути alias1
буде розглядатися як hg тягнути URL1).

Два псевдоніма шляху є особливими, оскільки вони використовуються за замовчуванням, коли ви не надаєте
URL-адреса команди:

за замовчуванням:
Коли ви створюєте репозиторій за допомогою hg clone, команда clone зберігає розташування
вихідне сховище як шлях «за замовчуванням» нового сховища. Це потім використовується
коли ви пропускаєте шлях із команд, подібних до натискання та витягування (включаючи вхідні та
вихідний).

за замовчуванням натиснути:
Команда push шукатиме шлях під назвою 'default-push' і віддасть перевагу йому
"за замовчуванням", якщо обидва визначені.

Розширення

Цей розділ містить довідку щодо розширень, які поширюються разом із Mercurial.
Довідка щодо інших розширень доступна в довідковій системі.

ACL
хуки для контролю доступу до сховища

Цей хук дозволяє дозволяти або забороняти доступ на запис до заданих гілок і шляхів a
репозиторій при отриманні вхідних наборів змін через pretxnchangegroup і pretxncommit.

Авторизація збігається на основі імені локального користувача в системі, де гачок
запускається, а не комітер вихідного набору змін (оскільки останній є просто
інформативний).

Хук acl найкраще використовувати разом із обмеженою оболонкою, як-от hgsh, запобігаючи
аутентифікація користувачів від будь-яких інших дій, окрім натискання або витягування. Гачка немає
безпечно використовувати, якщо користувачі мають інтерактивний доступ до оболонки, оскільки вони можуть відключити хук. Ні
чи безпечно, якщо віддалені користувачі ділиться обліковим записом, тому що тоді неможливо відрізнити
Ними.

Порядок виконання перевірок доступу такий:

1. Список заборон для філій (розд acl.deny.branches)

2. Список дозволів для філій (розділ acl.allow.branches)

3. Список заборон для шляхів (розділ acl.deny)

4. Дозволити список шляхів (розділ acl.allow)

Розділи дозволу та заборони беруть пари ключ-значення.

На базі філій доступу Контроль
Використовувати acl.deny.branches та acl.allow.branches розділи, щоб мати доступ на основі гілок
контроль. Ключі в цих розділах можуть бути такими:

· назва філії, або

· зірочка, відповідати будь-якій гілці;

Відповідні значення можуть бути такими:

· розділений комами список, що містить користувачів і групи, або

· зірочка, відповідати будь-кому;

Ви можете додати "!" префікс до імені користувача або групи, щоб інвертувати сенс відповідності.

На основі шляху доступу Контроль
Використовувати acl.deny та acl.allow розділи, щоб мати контроль доступу на основі шляхів. Ключі в них
розділи приймають шаблон піддерева (за замовчуванням із синтаксисом glob). Відповідний
значення мають той самий синтаксис, що й інші розділи вище.

груп
Назви груп повинні мати префікс @ символ. Визначення назви групи має той самий ефект
як визначення всіх користувачів у цій групі.

Ви можете визначити учасників групи в акл.групи розділ. Якщо назва групи не визначена
там, а Mercurial працює під Unix-подібною системою, буде взятий список користувачів
з ОС. В іншому випадку буде створено виняток.

Приклад конфігурація
[гачки]

# Використовуйте це, якщо ви хочете перевірити обмеження доступу під час фіксації
pretxncommit.acl = python:hgext.acl.hook

# Використовуйте це, якщо ви хочете перевірити обмеження доступу для pull, push,
# зв’язати та подати.
pretxnchangegroup.acl = python:hgext.acl.hook

[acl]
# Дозволити або заборонити доступ для вхідних змін, лише якщо їх джерело є
# перелічені тут, нехай вони пройдуть інакше. Джерело «служить» для всіх
# віддалений доступ (http або ssh), "push", "pull" або "bundle", коли
# пов’язані команди виконуються локально.
# За замовчуванням: подавати
джерела = служити

[acl.deny.branches]

# Усім відмовлено в замороженій гілці:
заморожена гілка = *

# Поганий користувач заборонений на всіх гілках:
* = поганий користувач

[acl.allow.branches]

# Кілька користувачів дозволені на гілки-a:
гілка-а = користувач-1, користувач-2, користувач-3

# До гілки-b дозволено лише одного користувача:
гілка-b = користувач-1

# Суперкористувачу дозволено працювати в будь-якій гілці:
* = суперкористувач

# Усі бажаючі мають право на тестування:
гілка для тестів = *

[acl.deny]
# Цей список перевіряється першим. Якщо збіг знайдено, acl.allow ні
# перевірено. Усім користувачам надається доступ, якщо acl.deny відсутній.
# Формат для обох списків: glob pattern = user, ..., @group, ...

# Щоб відповідати всім, використовуйте зірочку для користувача:
# my/glob/pattern = *

# user6 не матиме доступу на запис до жодного файлу:
** = користувач6

# Група "hg-denied" не матиме доступу на запис до жодного файлу:
** = @hg-відмовлено

# Ніхто не зможе змінити "DONT-TOUCH-THIS.txt", незважаючи на це
# кожен може змінити всі інші файли. Дивіться нижче.
src/main/resources/DONT-TOUCH-THIS.txt = *

[acl.allow]
# якщо acl.allow відсутній, усі користувачі дозволені за замовчуванням
# пустий acl.allow = жодних користувачів не дозволено

# Користувач "doc_writer" має доступ на запис до будь-якого файлу в "docs"
# папка:
docs/** = doc_writer

# Користувач "jack" і група "дизайнерів" мають доступ на запис до будь-якого файлу
# у папці "images":
images/** = jack, @designers

# Усі (крім "user6" і "@hg-denied" - див. acl.deny вище)
# матиме доступ на запис до будь-якого файлу в папці "ресурси".
# (крім 1 файлу. Див. acl.deny):
src/main/resources/** = *

.hgtags = release_engineer

прикладів використання ! префікс
Припустимо, що є гілка, до якої має бути здатний натиснути лише певний користувач (або група), і
ви не хочете обмежувати доступ до будь-якої іншої гілки, яка може бути створена.

"!" префікс дозволяє заборонити комусь, окрім певного користувача або групи, натискати
набори змін у даній гілці або шляху.

У наведених нижче прикладах ми: 1) заборонимо доступ до гілки "кільця" будь-кому, крім користувача
"gollum" 2) Заборонити доступ до гілки "озеро" будь-кому, крім членів групи "хоббіт" 3)
Заборонити доступ до файлу будь-кому, крім користувача "gollum"

[acl.allow.branches]
# Порожній

[acl.deny.branches]

# 1) тільки 'gollum' може зробити фіксацію для розгалуження 'ring';
# 'gollum' та будь-хто ще може приєднатися до будь-якої іншої гілки.
кільце = !gollum

# 2) тільки члени групи 'хоббіт' можуть приєднатися до філії 'озеро';
# Члени 'hobbit' та будь-хто ще можуть приєднатися до будь-якої іншої гілки.
озеро = !@хоббіт

# Ви також можете заборонити доступ на основі шляхів до файлів:

[acl.allow]
# Порожній

[acl.deny]
# 3) тільки 'gollum' може змінити файл нижче;
# 'gollum' та будь-хто ще може змінити будь-який інший файл.
/misty/mountains/cave/ring = !gollum

Чорна скринька
реєструвати події репозиторію в чорний ящик для налагодження

Записує інформацію про події в .hg/blackbox.log, щоб допомогти налагодити та діагностувати проблеми. The
Події, які реєструються, можна налаштувати за допомогою ключа конфігурації blackbox.track. Приклади:

[Чорна скринька]
трек = *

[Чорна скринька]
track = команда, commandfinish, commandexception, exthook, pythonhook

[Чорна скринька]
трек = вхідний

[Чорна скринька]
# обмежити розмір файлу журналу
максимальний розмір = 1.5 МБ
# обертати до N файлів журналу, коли поточний стає занадто великим
максимальні файли = 3

Команди
Чорна скринька
переглянути останні події сховища:

hg blackbox [ВАРІАНТ]...

переглянути останні події сховища

варіанти:

-л,--ліміт
кількість подій для відображення (за замовчуванням: 10)

баггілла
гачки для інтеграції з баг-трекером Bugzilla

Це розширення гачок додає коментарі до помилок у Bugzilla, коли набори змін, які посилаються на помилки
від Bugzilla ID бачать. Коментар відформатовано за допомогою механізму шаблону Mercurial.

Посилання на помилку можуть додатково включати оновлення для Bugzilla про витрачені години
працює над помилкою. Помилки також можна позначити як виправлені.

Надаються три основних режими доступу до Bugzilla:

1. Доступ через інтерфейс Bugzilla XMLRPC. Потрібна Bugzilla 3.4 або новіша версія.

2. Перевірте дані через інтерфейс Bugzilla XMLRPC та надішліть зміну помилки електронною поштою
Інтерфейс електронної пошти Bugzilla. Потрібна Bugzilla 3.4 або новіша версія.

3. Запис безпосередньо в базу даних Bugzilla. Це лише інсталяції Bugzilla з використанням MySQL
підтримується. Потрібен Python MySQLdb.

Запис безпосередньо в базу даних сприйнятливий до змін схеми і покладається на a
Скрипт Bugzilla contrib для надсилання електронних листів зі сповіщеннями про зміну помилок. Цей скрипт працює як
користувач, який використовує Mercurial, має бути запущений на хості з інсталяцією Bugzilla, і
потрібен дозвіл на читання деталей конфігурації Bugzilla та необхідного користувача MySQL
та пароль, щоб мати повні права доступу до бази даних Bugzilla. З цих причин це
Режим доступу тепер вважається застарілим і не буде оновлюватися для нової Bugzilla
версії вперед. У цьому режимі доступу підтримується лише додавання коментарів.

Для доступу через XMLRPC потрібно вказати ім’я користувача та пароль Bugzilla
конфігурації. Коментарі додаються під цим іменем користувача. Оскільки конфігурація повинна бути
доступний для читання всіма користувачами Mercurial, рекомендується, щоб права цього користувача були
обмежено в Bugzilla до мінімуму, необхідного для додавання коментарів. Виправлено помилки маркування
вимагає Bugzilla 4.0 і новіших версій.

Доступ через XMLRPC/email використовує XMLRPC для запиту Bugzilla, але надсилає електронну пошту до Bugzilla
електронний інтерфейс для надсилання коментарів до помилок. Для адреси From: в електронному листі встановлено значення
адреса електронної пошти користувача Mercurial, тому коментар, схоже, надійшов від Mercurial
користувач. У випадку, якщо електронна адреса користувача Mercurial не розпізнається Bugzilla як a
Користувач Bugzilla, електронна адреса, пов’язана з іменем користувача Bugzilla, що використовується для входу в Bugzilla
замість цього використовується як джерело коментаря. Позначення виправлених помилок працює на всіх підтримуваних
Версії Bugzilla.

Елементи конфігурації, загальні для всіх режимів доступу:

bugzilla.version
Тип доступу для використання. Визнаються цінності:

XMLRPC

Інтерфейс Bugzilla XMLRPC.

xmlrpc+електронна пошта

Bugzilla XMLRPC та інтерфейси електронної пошти.

3.0

Доступ до MySQL, Bugzilla 3.0 і новіших версій.

2.18

Доступ до MySQL, Bugzilla 2.18 і вище, але не включаючи 3.0.

2.16

Доступ до MySQL, Bugzilla 2.16 і вище, але не включаючи 2.18.

bugzilla.regexp
Регулярний вираз для збігу ідентифікаторів помилок для оновлення в повідомленні про фіксацію набору змін. Це
має містити одну групу з назвою "()". містить ідентифікатори помилок, розділені символами
нецифрові символи. Він також може містити названу групу з
число з плаваючою комою, що вказує кількість годин, відпрацьованих над помилкою. Якщо немає названих груп
При цьому передбачається, що перша група "()" містить ідентифікатори помилок, а час роботи дорівнює
не оновлено. Вираз за замовчуванням відповідає Помилка 1234, Помилка немає. 1234, Помилка номер
1234, Помилки 1234,5678, Помилка 1234 та 5678 та їх варіації, за якими слідує an
номер годин із префіксом h or годин, напр годин 1.5. Відповідність не чутлива до регістру.

bugzilla.fixregexp
Регулярний вираз для збігу ідентифікаторів помилок для позначення виправлених у повідомленні про фіксацію набору змін.
Це має містити групу з іменем "()". ` що містить помилка Ідентифікатори відокремлений by
нецифровий символів. It може Також містити a названий група `` з
число з плаваючою комою, що вказує кількість годин, відпрацьованих над помилкою. Якщо немає названих груп
При цьому передбачається, що перша група "()" містить ідентифікатори помилок, а час роботи дорівнює
не оновлено. Вираз за замовчуванням відповідає Виправлення 1234, Виправлення помилка 1234, Виправлення помилки
1234,5678, Виправлення 1234 та 5678 та їх варіанти, за якими слідує номер годин
з префіксом h or годин, напр годин 1.5. Відповідність не чутлива до регістру.

bugzilla.fixstatus
Статус для встановлення помилки під час позначення виправленої. За замовчуванням РЕШЕНО.

bugzilla.fixresolution
Роздільна здатність для встановлення помилки під час позначення виправленої. За замовчуванням ФІКСОВАНО.

bugzilla.style
Файл стилю для форматування коментарів.

bugzilla.template
Шаблон для форматування коментарів. Перевизначає стиль, якщо вказано. На додачу
до звичайних ключових слів Mercurial, розширення вказує:

{помилка}

Ідентифікатор помилки Bugzilla.

{корінь}

Повний шлях до репозиторію Mercurial.

{webroot}

Вилучено ім’я шляху до репозиторію Mercurial.

{hgweb}

Базовий URL для перегляду сховищ Mercurial.

дефолт ревізія {вузол|короткий} in репо {корінь} відноситься до помилка
{помилка}.\nдеталі:\n\t{desc|tabindent}

bugzilla.strip
Кількість символів-роздільників шляхів, які знімаються з передньої панелі Mercurial
шлях до сховища ({корінь} у шаблонах) для виготовлення {webroot}. Наприклад, a
сховище с {корінь} /var/local/my-project зі смугою 2 дає значення для
{webroot} of мій проект. За замовчуванням 0.

web.baseurl
Базовий URL для перегляду сховищ Mercurial. Посилається із шаблонів як {hgweb}.

Елементи конфігурації, загальні для режимів доступу XMLRPC+email і MySQL:

bugzilla.usermap
Шлях до файлу, що містить повідомлення електронної пошти Mercurial committer до зіставлення електронної пошти користувача Bugzilla.
Якщо вказано, файл повинен містити одне зіставлення на рядок:

committer = користувач Bugzilla

Див. Також [карта користувача] .

Команда [карта користувача] Розділ використовується для визначення зіставлення електронної пошти Mercurial committer до Bugzilla
електронна пошта користувача. Дивитися також bugzilla.usermap. Містить записи форми комітер = Bugzilla
користувач.

Конфігурація режиму доступу XMLRPC:

bugzilla.bzurl
Базовий URL для встановлення Bugzilla. За замовчуванням http://localhost/bugzilla.

bugzilla.user
Ім’я користувача для входу в Bugzilla через XMLRPC. За замовчуванням помилки.

bugzilla.password
Пароль для входу в Bugzilla.

Режим доступу XMLRPC+email використовує елементи конфігурації режиму доступу XMLRPC, а також:

bugzilla.bzemail
Адреса електронної пошти Bugzilla.

Крім того, потрібно налаштувати параметри електронної пошти Mercurial. Дивіться документацію в
hgrc(5), розділи [електронна пошта] та [smtp].

Конфігурація режиму доступу до MySQL:

bugzilla.host
Ім'я хоста сервера MySQL, що містить базу даних Bugzilla. За замовчуванням локальний.

bugzilla.db
Назва бази даних Bugzilla в MySQL. За замовчуванням помилки.

bugzilla.user
Ім'я користувача для доступу до сервера MySQL. За замовчуванням помилки.

bugzilla.password
Пароль для доступу до сервера MySQL.

bugzilla.timeout
Час очікування підключення до бази даних (секунди). За замовчуванням 5.

bugzilla.bzuser
Резервне ім’я користувача Bugzilla для запису коментарів, якщо комітер набору змін не може
бути знайденим як користувач Bugzilla.

bugzilla.bzdir
Каталог встановлення Bugzilla. Використовується за замовчуванням Notify. За замовчуванням /var/www/html/bugzilla.

bugzilla.notify
Команда для запуску, щоб змусити Bugzilla надсилати електронні листи зі сповіщеннями про зміну помилок.
Замінники з карти з 3 ключами, bzdir, id (ідентифікатор помилки) і користувач (коммітер bugzilla
електронна пошта). За замовчуванням залежить від версії; з версії 2.18 це "cd %(bzdir)s && perl -T
contrib/sendbugmail.pl %(id)s %(user)s".

Активація розширення:

[розширення]
багзіла =

[гачки]
# запускайте гачок bugzilla на кожній зміні, яка витягується або вноситься тут
incoming.bugzilla = python:hgext.bugzilla.hook

Приклади конфігурацій:

Приклад конфігурації XMLRPC. Для цього використовується Bugzilla at http://my-project.org/bugzilla,
увійти як користувач [захищено електронною поштою] з паролем вилка. Він використовується з a
колекція сховищ Mercurial в /var/local/hg/repos/, з веб-інтерфейсом за адресою
http://my-project.org/hg.

[bugzilla]
bzurl=http://my-project.org/bugzilla
користувач=[захищено електронною поштою]
пароль=pugh
версія=xmlrpc
template=Набір змін {вузол|короткий} у {root|basename}.
{hgweb}/{webroot}/rev/{вузол|короткий}\n
{desc}\n
смуга = 5

[веб]
baseurl=http://my-project.org/hg

Приклад конфігурації XMLRPC+email. Для цього використовується Bugzilla at
http://my-project.org/bugzilla, увійти як користувач [захищено електронною поштою] з паролем
вилка. Він використовується з колекцією сховищ Mercurial в /var/local/hg/repos/,
з веб-інтерфейсом на http://my-project.org/hg. Коментарі про помилки надсилаються до Bugzilla
адресу електронної пошти [захищено електронною поштою].

[bugzilla]
bzurl=http://my-project.org/bugzilla
користувач=[захищено електронною поштою]
пароль=pugh
версія=xmlrpc+email
bzemail=[захищено електронною поштою]
template=Набір змін {вузол|короткий} у {root|basename}.
{hgweb}/{webroot}/rev/{вузол|короткий}\n
{desc}\n
смуга = 5

[веб]
baseurl=http://my-project.org/hg

[карта користувача]
[захищено електронною поштою]=[захищено електронною поштою]

Приклад конфігурації MySQL. Це локальна установка Bugzilla 3.2
/opt/bugzilla-3.2. База даних MySQL увімкнена локальний, назва бази даних Bugzilla помилки
а доступ до MySQL здійснюється за допомогою імені користувача MySQL помилки пароль XYZZY. Він використовується з a
колекція сховищ Mercurial в /var/local/hg/repos/, з веб-інтерфейсом за адресою
http://my-project.org/hg.

[bugzilla]
хост=локальний хост
пароль=XYZZY
версія=3.0
bzuser=[захищено електронною поштою]
bzdir=/opt/bugzilla-3.2
template=Набір змін {вузол|короткий} у {root|basename}.
{hgweb}/{webroot}/rev/{вузол|короткий}\n
{desc}\n
смуга = 5

[веб]
baseurl=http://my-project.org/hg

[карта користувача]
[захищено електронною поштою]=[захищено електронною поштою]

Усе вищезазначене додає коментар до запису помилок Bugzilla у формі:

Набір змін 3b16791d6642 в імені-сховище.
http://my-project.org/hg/repository-name/rev/3b16791d6642

Коментар фіксації набору змін. Помилка 1234.

цензор
стерти вміст файлу під час даної редакції

Команда цензора наказує Mercurial стерти весь вміст файлу під час даної редакції
без оновлення ревізія хеш. Це дозволяє існуючій історії залишатися дійсною доки
запобігання майбутнім клонам/витягам від отримання видалених даних.

Типове використання цензора обумовлено вимогами безпеки або юридичними вимогами, зокрема:

* Паролі, закриті ключі, криптографічні матеріали
* Ліцензійні дані/код/бібліотеки, для яких закінчився термін дії ліцензії
* Особиста інформація або інші приватні дані

Вузли, піддані цензурі, можуть переривати типову роботу Mercurial щоразу, коли потрібні вирізані дані
матеріалізуватися. Деякі команди, наприклад hg як/hg повернути, просто не вдається, коли про це просять
створювати цензуровані дані. Інші, як hg перевірити та hg оновлення, має бути здатним терпіти
цензуровані дані, щоб і надалі функціонувати значущим чином. Такі команди тільки терплять
цензуровані редакції файлів, якщо вони дозволені параметром конфігурації "censor.policy=ignore".

Команди
цензор
hg censor -r REV [-t ТЕКСТ] [ФАЙЛ]

варіанти:

-р,--rev
файл цензор із зазначеної редакції

-t,-- надгробна плита
дані про заміну надгробку

chgserver
розширення командного сервера для cHg (ЕКСПЕРИМЕНТАЛЬНО)

'S' канал (читати писати)
поширити запит ui.system() до клієнта

'аттачіо' команда
приєднати клієнтський stdio, переданий sendmsg()

'chdir' команда
змінити поточний каталог

'getpager' команда
перевіряє, чи увімкнено пейджер і який пейджер слід запустити

'setenv' команда
повністю замінити os.environ

'SIGHUP' сигналізувати
перезавантажити файли конфігурації

діти
команда для відображення дочірніх наборів змін (ЗАСТАРЕЛО)

Це розширення не підтримується. Ви повинні використовувати hg журнал -r "діти (REV)" замість цього.

Команди
діти
показати дочірні елементи даної або робочої версії каталогу:

hg діти [-r REV] [ФАЙЛ]

Друк дочірніх версій робочого каталогу. Якщо редакція надається через
-r/--rev, дочірні елементи цієї ревізії будуть надруковані. Якщо вказано аргумент файлу,
ревізії, в якій востаннє змінено файл (після редакції робочого каталогу або версії
аргумент для --rev, якщо вказано).

Будь ласка, використовуйте hg журнал натомість:

hg children => hg log -r 'children()'
hg children -r REV => hg log -r 'діти (REV)'

Читати hg допомога журнал та hg допомога revsets.children.

варіанти:

-р,--rev
показати дітей зазначеної редакції

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

збивати
команда для відображення статистики історії репозиторію

Команди
збивати
гістограма змін до сховища:

hg churn [-d ДАТА] [-r REV] [--псевдонім ФАЙЛ] [ФАЙЛ]

Ця команда відобразить гістограму, що відображає кількість змінених рядків або
редакції, згруповані за заданим шаблоном. Шаблон за замовчуванням буде групуватися
зміни за автором. Для групування результатів за датою можна використовувати параметр --dateformat
замість цього.

Статистика базується на кількості змінених рядків або, як варіант, кількості
відповідні редакції, якщо вказано параметр --changesets.

Приклади:

# відображення кількості змінених рядків для кожного комітера
hg churn -t "{автор|електронна пошта}"

# відображення графіка щоденної активності
hg churn -f "%H" -s -c

# відображення активності розробників за місяцями
hg churn -f "%Y-%m" -s -c

# відображення кількості рядків, змінених за кожен рік
hg churn -f "%Y" -s

Можна зіставити альтернативні адреси електронної пошти з основною, надавши файл
використовуючи такий формат:

=

Такий файл можна вказати за допомогою параметра --aliases, інакше буде файл .hgchurn
шукав у кореневому робочому каталозі. Псевдоніми будуть розділені від крайнього правого "=".

варіанти:

-р,--rev
швидкість підрахунку для вказаної редакції або скидання

-d,--дата
коефіцієнт підрахунку редакцій, які відповідають даті спец

-t,--старий шаблон
шаблон для групових наборів змін (ЗАСТАРЕЛО)

-Т,--шаблон
шаблон для групування наборів змін (за замовчуванням: {author|email})

-f,--формат дати
strftime-сумісний формат для групування за датою

-c, --набори змін
швидкість підрахунку за кількістю наборів змін

-так, --сортувати
сортувати за ключем (за замовчуванням: сортувати за кількістю)

--diffstat
відображати додані/видалені рядки окремо

--псевдоніми
файл з псевдонімами електронної пошти

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

пучки клонів
рекламувати попередньо згенеровані пакети для початкових клонів

"clonebundles" - це розширення на стороні сервера, яке використовується для реклами існування
попередньо згенеровані файли пакетів, розміщені на зовнішньому сервері, клієнтам, які клонують для цього клонування
може бути швидшим, надійнішим і вимагає менше ресурсів на сервері.

Клонування може бути інтенсивним процесом та операцією вводу-виводу на серверах. Традиційно сервер, в
відповідь на запит клієнта на клонування, динамічно створює пакет, що містить файл
весь вміст репозитарію та надсилає його клієнту. На сервері немає кешування
і сервер повинен буде генерувати той самий вихідний пакет у відповідь на
кожен запит на клон. Для серверів з великими сховищами або з великим об’ємом клонів, файл
навантаження від клонів може зробити масштабування сервера складним і дорогим.

Це розширення надає операторам серверів можливість розвантажувати потенційно дорого
клонувати завантаження до зовнішньої служби. Ось як це працює.

1. Оператор сервера встановлює механізм надання пакетних файлів доступним на a
послуга хостингу, де клієнти Mercurial можуть отримати їх.

2. До файлу маніфесту додано доступні URL-адреси пакетів і деякі додаткові метадані
репозиторій Mercurial на сервері.

3. Клієнт ініціює клонування на сервері, що підтверджує пакети клонів.

4. Клієнт бачить, що сервер рекламує пакети клонів, і отримує маніфест
список доступних пакетів.

5. Клієнт фільтрує та сортує доступні пакети на основі того, що він підтримує та
віддає перевагу.

6. Клієнт завантажує та застосовує доступний пакет із зазначеної сервером URL-адреси.

7. Клієнт повторно підключається до вихідного сервера і виконує еквівалент hg тягнути до
отримати всі дані репозиторію, які не входять у пакет. (Репозиторій можна було оновити
між моментом створення пакета та моментом, коли клієнт запустив клон.)

Замість того, щоб сервер генерував повні пакети репозиторію для кожного запиту на клонування, він
генерує повні пакети один раз, і вони згодом повторно використовуються для завантаження нових клонів. The
сервер все ще може передавати дані під час клонування. Однак це лише дані, які були
додано/змінено з моменту створення пакета. Для великих встановлених сховищ це може
зменшити навантаження на сервер для клонів до менш ніж 1% від оригіналу.

Для роботи цього розширення потрібні наступні оператори сервера:

· Створення пакетних файлів вмісту репозитарію (зазвичай періодично, наприклад, один раз на
день).

· Файловий сервер, до якого клієнти мають доступ до мережі і з яким Python знає, як спілкуватися
через свій звичайний засіб обробки URL-адрес (зазвичай HTTP-сервер).

· Процес синхронізації маніфесту пакетів із доступними файлами пакетів.

Строго кажучи, використання статичного сервера для розміщення файлів не потрібно: оператор сервера
може використовувати динамічну службу для отримання пакетних даних. Однак статичний файлообмінник
послуги прості та масштабовані, їх повинно бути достатньо для більшості потреб.

Пакетні файли можна створювати за допомогою hg пакет команда. Як правило hg пакет --все is
використовується для створення пакета всього сховища.

hg debugcreatestreamclonebundle можна використовувати для виготовлення спец потоковий клон пакет.
Це пакетні файли, які надзвичайно ефективно створювати та споживати (читати: швидко).
Однак вони більші, ніж традиційні формати пакетів, і вимагають підтримки клієнтами
точний набір форматів зберігання даних репозиторію, які використовуються репозиторієм, який їх створив.
Як правило, новіший сервер може обслуговувати дані, сумісні зі старими клієнтами. однак,
потоковий клон пучки не мають цієї гарантії. сервер Оператори необхідність до be знати Що
новіший версії of ртутний може виробляти потоковий клон пучки несумісні з старший
ртутний версій.

Оператор сервера відповідає за створення a .hg/clonebundles.manifest файл, що містить
список доступних пакетних файлів, придатних для завантаження клонів. Якщо цього файлу немає
існує, репозиторій не рекламуватиме існування пакетів клонів, коли клієнти
підключити.

Файл маніфесту містить список записів із роздільниками нового рядка ( ).

Кожен рядок у цьому файлі визначає доступний пакет. Рядки мають такий формат:

[ = [ = ]]

Тобто URL-адреса, за якою слідує необов’язковий, розділений пробілами список пар ключ=значення, що описують
додаткові властивості цього пучка. І ключі, і значення мають кодування URI.

Клавіші у ВЕРСІМ РЕГІСТРІ зарезервовані для використання Mercurial і визначені нижче. всі
ключі, які не є великими регістрами, можуть використовуватися в установках сайту. Приклад використання користувацьких властивостей
це використовувати центр обробки даних атрибут, щоб визначити, в якому центрі обробки даних розміщується файл.
Тоді клієнти можуть віддати перевагу серверу в найближчому до них центрі обробки даних.

Наразі визначено такі зарезервовані ключі:

BUNDLESPEC
Рядок "специфікації пакета", який описує тип пакета.

Це рядкові значення, які приймаються аргументом "--type". hg пакет.

Значення аналізуються в строгому режимі, що означає, що вони повинні бути з
" - " форма. Детальніше див. mercurial.exchange.parsebundlespec().
подробиці

hg налагоджувальний пакет --спец можна використовувати для друку рядка специфікації пакета для a
пакетний файл. Вихід цієї команди можна використовувати дослівно для значення
BUNDLESPEC (це вже втекло).

Клієнти автоматично відфільтрують невідомі специфікації або
не підтримується, тому вони не намагатимуться завантажити те, що, ймовірно, не підійде.

Фактичне значення не впливає на поведінку клієнта, крім фільтрації: клієнти впливають
все ще шукайте тип пакета із заголовка завантажених файлів.

Скористайтесь of це ключ is дуже рекомендований, оскільки це дозволяє клієнтам легко пропускати
непідтримувані пакети. Якщо цей ключ не визначено, старий клієнт може спробувати застосувати
пакет, який він не в змозі прочитати.

ПОТРІБНО
Чи потрібна вказівка ​​імені сервера (SNI) для підключення до URL-адреси. SNI дозволяє
сервери, щоб використовувати кілька сертифікатів на одному IP. Це дещо поширене в CDN
та інших хостинг-провайдерів. Старіші версії Python не підтримують SNI. Визначення
цей атрибут дозволяє клієнтам зі старішими версіями Python фільтрувати цей запис
без непрозорого збою SSL під час підключення.

Якщо це визначено, важливо рекламувати резервну URL-адресу або клієнтів, що не є SNI
запущені старі випуски Python можуть бути не в змозі клонувати за допомогою Clonebundles
центр.

Значення має бути "true".

Маніфести можуть містити кілька записів. Припускаючи, що метадані визначені, клієнти фільтруватимуть
записи з маніфесту, які вони не підтримують. Решта записів необов’язкова
відсортовано за уподобаннями клієнта (експериментальний.clonebundleprefers параметр конфігурації). Клієнт
потім намагається отримати пакет за першою URL-адресою в списку, що залишився.

помилки коли Завантаження a пакет волі невдача весь клон операція: клієнтів do НЕ
автоматично падати назад до a традиційний клон. Причина цього в тому, що якщо сервер є
використовуючи пакети клонів, це, ймовірно, робить це, тому що функція необхідна для цього
масштаб. Іншими словами, існує припущення, що навантаження клону буде передано іншому
служби і що сервер Mercurial не несе відповідальності за обслуговування цього клонованого навантаження. Якщо
що інші служби відчувають проблеми і клієнти починають масово повертатися до оригіналу
Mercurial server, додане навантаження клону може перевантажити сервер через несподіване навантаження
і ефективно перевести його в автономний режим. Відсутність клієнтів автоматично повертається до клонування
з оригінального сервера пом’якшує цей сценарій.

Тому що немає автоматичного резерву сервера Mercurial у разі збою пакетного хостингу
послуги, операторам серверів важливо розглядати пакет послуг хостингу як
розширення сервера Mercurial щодо доступності та угоди про рівень обслуговування:
якщо пакет послуги хостингу не працює, зменшується і можливість клонування клієнтів. Примітка:
клієнти побачать повідомлення, що інформує їх, як обійти пакети клонування, коли a
відбувається збій. Тому оператори серверів повинні підготуватися до того, що деякі люди будуть дотримуватися цих правил
інструкції при виникненні збою, тим самим посилюючи навантаження на оригінальний Mercurial
сервера, коли пакет послуги хостингу не працює.

color
розфарбувати вихідні дані деяких команд

Розширення кольору розфарбовує вихідні дані кількох команд Mercurial. Наприклад,
Команда diff показує додавання зеленим кольором, а видалення червоним, а команда status показує
змінені файли у пурпурному кольорі. Багато інших команд мають аналогічні кольори. Це можливо
налаштувати ці кольори.

Ефекти
Крім кольору, також доступні інші ефекти, наприклад жирний і підкреслений текст. За
за замовчуванням база даних terminfo використовується для пошуку термінальних кодів, які використовуються для зміни кольору і
ефект. Якщо terminfo недоступний, то ефекти відображаються за допомогою ECMA-48 SGR
керуюча функція (він же escape-коди ANSI).

Доступні ефекти в режимі terminfo: «блимання», «жирний», «затуманений», «зворотний», «невидимий»,
«курсив», «виділяється» та «підкресли»; у режимі ECMA-48 параметри: «жирний», «інверсний»,
«курсив» і «підкреслення». Спосіб відображення кожного залежить від емулятора терміналу. Деякі
може бути недоступним для даного типу терміналу, і буде ігноруватися мовчки.

етикетки
Текст отримує колірні ефекти залежно від міток, які він має. Багато за замовчуванням Mercurial
команди видають мічений текст. Ви також можете визначити власні мітки в шаблонах за допомогою
функція етикетки, див hg допомога Шаблони. Одна частина тексту може мати більше одного
етикетці. У цьому випадку ефекти, надані останній мітці, замінять будь-які інші ефекти. Це
включає спеціальний ефект "none", який зводить нанівець інші ефекти.

Мітки зазвичай невидимі. Щоб побачити ці мітки та їх положення в
тексту, використовуйте глобальний параметр --color=debug. З ним може бути пов’язаний той самий текст прив’язки
кілька міток, напр

[log.changeset changeset.secret|changeset: 22611:6f0a53c8f587]

Нижче наведено ефекти за замовчуванням для деяких міток за замовчуванням. Ефекти за замовчуванням можуть бути
замінено з вашого конфігураційного файлу:

[колір]
status.modified = синій напівжирний підкреслений червоний_фон
status.added = зелений жирний
status.removed = червоний жирний синій_фон
status.deleted = блакитний жирне підкреслення
status.unknown = пурпуровий жирне підкреслення
status.ignored = чорний жирний

# 'none' вимикає всі ефекти
status.clean = немає
status.copied = немає

qseries.applied = синє напівжирне підкреслення
qseries.unapplied = чорний жирний
qseries.missing = червоний жирний

diff.diffline = жирний
diff.extended = блакитний жирний
diff.file_a = червоний жирний
diff.file_b = зелений жирний
diff.hunk = пурпурний
diff.deleted = червоний
diff.inserted = зелений
diff.changed = білий
diff.tab =
diff.trailingwhitespace = жирний червоний_фон

# Порожній, щоб він успадкував стиль навколишньої етикетки
Changeset.public =
changeset.draft =
changeset.secret =

resolve.unresolved = червоний жирний
resolve.resolved = зелений жирний

закладки.активний = зелений

branches.active = немає
гілки.закриті = чорний жирний
гілки.ток = зелений
branches.inactive = немає

теги.нормальний = зелений
tags.local = чорний жирний

rebase.rebased = синій
rebase.remaining = червоний жирний

shelve.age = блакитний
shelve.newest = зелений жирний
shelve.name = синій жирний

histedit.remaining = червоний жирний

виготовлений на замовлення квітів
Оскільки стандартних кольорів всього вісім, цей модуль дозволяє визначати назви кольорів
для інших кольорових слотів, які можуть бути доступні для вашого типу терміналу, припускаючи terminfo
режим. Наприклад:

колір.яскраво-блакитний = 12
колір.рожевий = 207
колір.помаранчевий = 202

щоб встановити «яскраво-блакитний» на колірний слот 12 (корисно для 16 кольорових терміналів, які мають яскравіше
кольори, визначені у верхніх вісімках) і, «рожевий» та «помаранчевий» до кольорів у 256-кольорових xterm
колірний куб за замовчуванням. Ці визначені кольори потім можна використовувати як будь-який із попередньо визначених
вісім, включаючи додавання "_background", щоб встановити фон на цей колір.

Режими
За замовчуванням розширення кольору використовуватиме режим ANSI (або режим win32 у Windows), якщо він
виявляє термінал. Щоб скасувати автоматичний режим (наприклад, увімкнути режим terminfo), встановіть параметр
наступний варіант конфігурації:

[колір]
режим = термінфо

Будь-яке значення, крім 'ansi', 'win32', 'terminfo' або 'auto', вимкне колір.

Зауважте, що в деяких системах режим terminfo може викликати проблеми під час використання кольору з
розширення пейджера і менше -R. менше з опцією -R відображатиме лише колір ECMA-48
коди, а режим terminfo іноді може видавати коди, які менші не розуміють. Ти можеш
обійти це, використовуючи режим ansi (або автоматичний режим), або використовуючи less -r (що буде
пропускати всі коди керування терміналами, а не лише коди керування кольором).

У деяких системах (наприклад, MSYS у Windows) термінал може підтримувати інший колірний режим
ніж пейджер (активується через розширення "пейджер"). Можна визначити окремі
режими залежно від того, чи активний пейджер:

[колір]
режим = авто
режим пейджера = ansi

If режим пейджера не визначено, режим буде використовуватися.

Команди
конвертувати
імпортувати редакції з іноземних репозиторіїв VCS в Mercurial

Команди
конвертувати
конвертувати іноземний репозиторій SCM в Mercurial.:

hg convert [OPTION]... ДЖЕРЕЛО [ЦІЛЬ [REVMAP]]

Прийняті вихідні формати [ідентифікатори]:

· ртутний [hg]

· CVS [cvs]

· Даркс [даркс]

· git [git]

· Subversion [svn]

· монотонний [mtn]

· GNU Arch [gnuarch]

· базар [bzr]

· Сила [p4]

Прийняті формати призначення [ідентифікатори]:

· ртутний [hg]

· Subversion [svn] (історія на гілках не збережена)

Якщо редакція не вказана, усі редакції будуть перетворені. В іншому випадку конвертація буде лише
імпортувати до названої версії (наданої у форматі, зрозумілому для джерела).

Якщо ім’я каталогу призначення не вказано, за замовчуванням буде використано базове ім’я джерела
з -рт.ст додається. Якщо цільового сховища не існує, воно буде створено.

За замовчуванням усі джерела, крім Mercurial, використовуватимуть --branchsort. Використання ртуті
--sourcesort для збереження початкового порядку номерів ревізій. Режими сортування мають наступне
ефекти:

--сортування філій
конвертувати від батьківської до дочірньої редакції, коли це можливо, що означає, що гілки є
зазвичай перетворюються один за одним. Він створює більш компактні сховища.

--сортувати дати
сортувати редакції за датою. Перетворені репозиторії мають гарні журнали змін, але є
часто на порядок більше, ніж ті самі, що генеруються --branchsort.

--sourcesort
намагайтеся зберегти порядок редагування джерела, який підтримується лише джерелами Mercurial.

-- близький сорт
намагайтеся перемістити закриті редакції якомога ближче до батьківських гілок
підтримується джерелами Mercurial.

If REVMAP не надано, він буде розміщено за замовчуванням (/.hg/shamap by
за замовчуванням). The REVMAP є простим текстовим файлом, який співставляє кожен ідентифікатор фіксації джерела з файлом
Ідентифікатор призначення для цієї версії, наприклад:



Якщо файл не існує, він створюється автоматично. Він оновлюється під час кожного скопійованого коміту,
so hg конвертувати можна переривати і запускати багаторазово, щоб скопіювати нові коміти.

Authormap — це простий текстовий файл, який зіставляє кожного автора джерела фіксації до місця призначення
фіксувати автора. Це зручно для вихідних SCM, які використовують логіни Unix для ідентифікації авторів (наприклад:
CVS). Один рядок на відображення автора та формат рядка:

вихідний автор = автор призначення

Порожні рядки та рядки, які починаються з a # ігноруються.

Файлова карта — це файл, який дозволяє фільтрувати та перепризначати файли та каталоги. Кожен
рядок може містити одну з таких директив:

включити шлях/до/файл-або каталог

виключити шлях/до/файл-або каталог

перейменувати шлях/до/шлях джерела/до/пункт призначення

Рядки коментарів починаються з #. Вказаний шлях відповідає, якщо він дорівнює повному відносному імені
файлу або одного з його батьківських каталогів. The включати or виключати директива з
застосовується найдовший відповідний шлях, тому порядок рядків не має значення.

Команда включати Директива призводить до того, що файл або всі файли в каталозі будуть включені до
цільовий репозиторій. За замовчуванням, якщо їх немає включати заяви включати
все. Якщо такі є включати заяви, більше нічого не включено. The виключати
Директива спричиняє пропуск файлів або каталогів. The перейменувати Директива перейменовує файл
або каталог, якщо він конвертований. Щоб перейменувати підкаталог у корінь файлу
сховище, корист . як шлях для перейменування.

--повний переконається, що перетворені набори змін містять саме потрібні файли з
правильний вміст. Це зробить повне перетворення всіх файлів, а не лише тих, які є
змінився. Файли, які вже є правильними, не змінюватимуться. Це можна використовувати для застосування
файли змінюються при поступовому конвертуванні. Наразі це підтримується лише для
Mercurial і Subversion.

splicemap — це файл, який дозволяє вставляти синтетичну історію, що дозволяє вам вказати
батьки перегляду. Це корисно, якщо ви хочете, наприклад, надати Subversion злиття двох
батьків, або прищепити дві незв’язані серії історії разом. Кожен запис містить ключ,
за яким слідує пробіл, а потім одне або два значення, розділені комами:

ключ parent1, parent2

Ключем є ідентифікатор версії в системі контролю версії джерела, батьки якого повинні бути
змінено (той же формат, що й ключ у .hg/shamap). Значення є ідентифікаторами ревізій (в будь-якому з них
вихідна або цільова система контролю переглядів), які слід використовувати як нові батьківські
для цього вузла. Наприклад, якщо ви об’єднали «release-1.0» у «trunk», то ви повинні
вкажіть ревізію на "trunk" як на першому батьківському та на "release-1.0"
відділення як друге.

Карта гілок — це файл, який дозволяє перейменувати гілку під час її введення
з будь-якого зовнішнього сховища. При використанні в поєднанні з картою з’єднання це дозволяє
для потужної комбінації, яка допоможе виправити навіть найбільш погано керовані репозиторії та
перетворити їх на добре структуровані репозиторії Mercurial. Карта гілок містить рядки
форма:

оригінальна_назва_гілки нова_назва_гілки

де «original_branch_name» — це назва гілки у вихідному сховищі, і
"new_branch_name" - це ім'я гілки, яка є репозиторієм призначення. Без пробілів
дозволено в назвах гілок. Це можна використовувати для (наприклад) переміщення коду в один
репозиторій із «за замовчуванням» до іменованої гілки.

ртутний Source
Джерело Mercurial розпізнає такі параметри конфігурації, які ви можете налаштувати
командний рядок с --config:

convert.hg.ignoreerrors
ігнорувати помилки цілісності під час читання. Використовуйте його для виправлення сховищ Mercurial
відсутні ревлоги, шляхом перетворення з і на Mercurial. Типовим значенням є False.

convert.hg.saverev
зберігати вихідний ідентифікатор версії в наборі змін (примусово змінювати цільові ідентифікатори). Це займає a
логічний аргумент і за умовчанням має значення False.

convert.hg.startrev
вкажіть початкову версію Mercurial. За замовчуванням 0.

convert.hg.revs
revset вказує вихідні версії для перетворення.

CVS Source
Джерело CVS використовуватиме пісочницю (тобто вилучену копію) з CVS, щоб вказати початок
пункт того, що буде перетворено. Прямий доступ до файлів сховища не потрібен,
якщо, звичайно, сховище не є :місцевий:. Перетворення використовує каталог верхнього рівня в
пісочниці, щоб знайти репозиторій CVS, а потім використовує команди CVS rlog, щоб знайти файли для
конвертувати. Це означає, що якщо не вказано карту файлів, усі файли в початковому каталозі
буде перетворено, а будь-яка реорганізація каталогу в пісочниці CVS ігнорується.

Наступні параметри можна використовувати з --config:

convert.cvsps.cache
Установіть значення False, щоб вимкнути кешування віддаленого журналу з метою тестування та налагодження.
Типовим значенням є True.

convert.cvsps.fuzz
Укажіть максимальний час (у секундах), який дозволено між комітами за допомогою
ідентичний користувач і повідомлення журналу в одному наборі змін. Коли дуже великі файли були
зареєстровано як частину набору змін, тоді значення за замовчуванням може бути недостатньо довгим. The
за замовчуванням - 60.

convert.cvsps.mergeto
Укажіть регулярний вираз, якому відповідають повідомлення журналу фіксації. Якщо збіг
відбувається, тоді процес перетворення вставить фіктивну версію, що об’єднує гілку
на якому виникає це повідомлення журналу до гілки, зазначеної в регулярному виразі. За замовчуванням
{{mergetobranch ([-\w]+)}}

convert.cvsps.mergefrom
Укажіть регулярний вираз, якому відповідають повідомлення журналу фіксації. Якщо збіг
відбувається, тоді процес перетворення додасть останню версію до гілки
вказано в регулярному виразі як другий батько набору змін. За замовчуванням
{{mergefrombranch ([-\w]+)}}

convert.localtimezone
використовувати місцевий час (як визначено змінною середовища TZ) для набору змін
дата/час. За замовчуванням значення False (використовуйте UTC).

hooks.cvslog
Укажіть функцію Python, яка буде викликана в кінці збору журналу CVS. The
функції передається список із записами журналу та може змінювати записи
на місці, додайте чи видаліть їх.

hooks.cvschangesets
Укажіть функцію Python, яка буде викликана після обчислення наборів змін із
Журнал CVS. Функції передається список із записами набору змін і може змінюватися
набори змін на місці, додайте чи видаліть їх.

Додаткова команда Mercurial "debugcvsps" дозволяє об'єднувати код вбудованого набору змін
запускати без перетворення. Його параметри та вихідні дані подібні до параметрів cvsps
2.1. Будь ласка, перегляньте довідку щодо команд, щоб дізнатися більше.

Підривна діяльність Source
Джерело Subversion виявляє класичні макети стовбура/гілок/тегів. За замовчуванням надається
svn://repo/шлях/ вихідна URL-адреса перетворюється як одна гілка. Якщо svn://repo/path/trunk
існує, він замінює стандартну гілку. Якщо svn://repo/path/branches існує, його
підкаталоги вказані як можливі гілки. Якщо svn://repo/path/tags існує, воно є
шукав теги, що посилаються на перетворені гілки. За замовчуванням ствол, гілки та теги величини
можна замінити наступними параметрами. Установіть для них шляхи відносно вихідної URL-адреси або
залиште їх порожніми, щоб вимкнути автоматичне визначення.

Наступні параметри можна встановити за допомогою --config:

convert.svn.branches
вказати каталог, що містить гілки. За замовчуванням гілки.

convert.svn.tags
вкажіть каталог, що містить теги. За замовчуванням теги.

convert.svn.trunk
вказати назву магістральної гілки. За замовчуванням ствол.

convert.localtimezone
використовувати місцевий час (як визначено змінною середовища TZ) для набору змін
дата/час. За замовчуванням значення False (використовуйте UTC).

Історію джерела можна отримати, починаючи з певної версії, замість того, щоб бути
повністю перетворений. Підтримуються лише перетворення однієї гілки.

convert.svn.startrev
вкажіть початковий номер редакції Subversion. За замовчуванням 0.

Git Source
Імпортер Git перетворює коміти з усіх доступних гілок (посилання у посиланнях/заголовках) і
пульти дистанційного керування (посилання в посиланнях/пульти дистанційного керування) до Mercurial. Гілки перетворюються на закладки за допомогою
те саме ім’я, з видаленими першими «refs/heads». Підмодулі Git перетворюються на Git
subrepos в Mercurial.

Наступні параметри можна встановити за допомогою --config:

convert.git.similarity
вкажіть, наскільки подібні файли, змінені в коміті, мають бути імпортовані як перейменовані або
копій, у відсотках між 0 (вимкнено) і 100 (файли мають бути ідентичними). для
наприклад, 90 означає, що пара видалення/додавання буде імпортована як перейменування, якщо більше ніж
90% файлу не змінилося. За замовчуванням 50.

convert.git.findcopiesharder
під час виявлення копій переглядайте всі файли в робочій копії, а не просто
змінених. Це дуже дорого для великих проектів і ефективне лише тоді, коли
convert.git.similarity більше за 0. За замовчуванням значення False.

convert.git.remoteprefix
віддалені посилання перетворюються на закладки за допомогою convert.git.remoteprefix як префікс
слідом за a /. За умовчанням встановлено "віддалений".

convert.git.skipsubmodules
не перетворює файли кореневого рівня .gitmodules або файли із зазначенням режиму 160000
підмодуль. Типовим значенням є False.

Перфорс Source
Імпортеру Perforce (P4) можна надати шлях депо p4 або специфікацію клієнта
джерело. Він перетворить усі файли в джерелі до плоского сховища Mercurial, ігноруючи
мітки, гілки та інтеграції. Зауважте, що коли вам надається шлях до депо, зазвичай
має вказати цільовий каталог, оскільки інакше ціль може бути названо ...-рт.ст.

Наступні параметри можна встановити за допомогою --config:

convert.p4.encoding
вкажіть кодування для використання під час декодування стандартного виводу команди Perforce
інструмент лінії. Стандартним є системне кодування.

convert.p4.startrev
укажіть початкову версію Perforce (номер списку змін Perforce).

ртутний призначення
Пункт призначення Mercurial розпізнає підрепозитарії Mercurial у місці призначення
і автоматично оновіть файл .hgsubstate, якщо місце призначення
підсховища містять / /.hg/shamap файл. Перетворення репозиторію з
підрепозиторії потребують конвертації одного сховища за раз, знизу вгору.

Приклад, який показує, як конвертувати репозиторій із підрепозиторіями:

# тому convert знає тип, коли бачить непорожнє місце призначення
$ hg init перетворено

$ hg конвертувати orig/sub1 конвертовано/sub1
$ hg конвертувати orig/sub2 конвертовано/sub2
$ hg конвертувати вихідний конвертований

Підтримуються такі параметри:

convert.hg.clonebranches
відправляти вихідні гілки в окремих клонах. За замовчуванням значення False.

convert.hg.tagsbranch
назва гілки для ревізій тегу, за замовчуванням дефолт.

convert.hg.usebranchnames
зберегти назви гілок. Типовим значенням є True.

convert.hg.sourcename
записує вказаний рядок як додаткове значення 'convert_source' для кожного зробленого коміту
цільове сховище. За замовчуванням встановлено значення «Немає».

ВСІ напрями
Усі типи призначення приймають такі параметри:

convert.skiptags
не перетворює теги з вихідного репо у цільове репо. За замовчуванням
Помилковий.

варіанти:

--автори
Ім'я файлу зіставлення імені користувача (ЗАСТАРЕЛО) (замість цього використовуйте --authormap)

-так,-- тип джерела
вихідний тип сховища

-d,--dest-тип
тип сховища призначення

-р,--rev
імпорт до вихідної версії REV

-A,--авторська карта
перепризначити імена користувачів за допомогою цього файлу

--filemap
перепризначати імена файлів, використовуючи вміст файлу

--повний застосувати зміни карти файлів, конвертувавши всі файли знову

--splicemap
з’єднати синтезовану історію на місце

-Branchmap
змінити назви гілок під час конвертації

--сортування філій
спробуйте відсортувати набори змін за гілками

--сортувати дати
спробуйте відсортувати набори змін за датою

--sourcesort
зберегти вихідний порядок наборів змін

-- близький сорт
спробуйте змінити порядок закритих версій

Позначений [+] параметр можна вказати кілька разів

еол
автоматично керувати новими рядками у файлах репозиторію

Це розширення дозволяє вам керувати типом закінчення рядків (CRLF або LF), які використовуються в
у сховищі та в локальному робочому каталозі. Таким чином ви можете отримати закінчення рядків CRLF
на Windows і LF на Unix/Mac, таким чином дозволяючи кожному використовувати рідні закінчення рядків ОС.

Розширення читає свою конфігурацію з версії .hgeol файл конфігурації знайдено в
корінь робочого каталогу. The .hgeol файл використовує той самий синтаксис, що й усі інші
Конфігураційні файли Mercurial. Він використовує два розділи, [візерунки] та [сховище].

Команда [візерунки] у розділі вказується, як закінчення рядків повинні перетворюватися між робочими
каталог і репозиторій. Формат визначається шаблоном файлу. Перший матч
використовується, тому спочатку розмістіть більш конкретні шаблони. Доступні закінчення рядків LF, CRLF та
BIN.

Файли із заявленим форматом CRLF or LF завжди перевіряються та зберігаються в
репозиторій у цьому форматі та файли, оголошені як бінарні (BIN) залишаються без змін.
Крім того, рідний це псевдонім для перевірки в кінці рядка платформи за замовчуванням:
LF на Unix (включаючи Mac OS X) і CRLF на Windows. Зауважте, що BIN (нічого не робити для лінії
закінчення) є типовою поведінкою Mercurial; це потрібно, лише якщо вам потрібно перевизначити a
пізніше, більш загальна закономірність.

The optional [сховище] розділ визначає закінчення рядків для файлів, що зберігаються в
сховище. Він має єдине налаштування, рідний, що визначає закінчення рядків зберігання
для файлів, оголошених як рідний в [візерунки] розділ. Його можна встановити на LF or CRLF,
за замовчуванням LF. Наприклад, це означає, що в Windows файли, налаштовані як рідний (CRLF
за замовчуванням) буде перетворено на LF при зберіганні в репозиторії. Файли, оголошені як LF,
CRLFабо BIN в [візерунки] завжди зберігаються в сховищі як є.

Приклад версії .hgeol Файл:

[візерунки]
**.py = нативний
**.vcproj = CRLF
**.txt = нативний
Makefile = LF
**.jpg = BIN

[сховище]
рідний = LF

Примітка Правила спочатку застосовуються, коли торкаються файлів у робочому каталозі, наприклад by
оновлення до нуля та повернення до підказки, щоб торкнутися всіх файлів.

Розширення використовує опціональний параметр [eol] розділ читається як із звичайного Mercurial
файли конфігурації та .hgeol файл, причому останній перекриває попередній. Ти можеш
використовуйте цей розділ для керування загальною поведінкою. Є три налаштування:

· еол.рідний (за замовчуванням ос.лінесеп) можна встановити на LF or CRLF щоб змінити значення за замовчуванням
інтерпретація рідний для виписки. Це можна використовувати з hg архів на Unix, скажімо, до
створити архів, де файли мають закінчення рядків для Windows.

· еол.тільки-послідовний (за замовчуванням True) можна встановити значення False, щоб конвертувати розширення
файли з неузгодженими EOL. Непослідовність означає, що є і те, і інше CRLF та LF представити
у файлі. Такі файли зазвичай не торкаються, припускаючи, що вони мають
змішані EOL навмисно.

· eol.fix-trailing-newline (за замовчуванням False) можна встановити значення True, щоб забезпечити перетворення
файли закінчуються символом EOL (або \n or \ Г \ п відповідно до налаштованих шаблонів).

Розширення забезпечує cleverencode: та cleverdecode: фільтри, як застарілі
розширення win32text робить. Це означає, що ви можете вимкнути win32text і ввімкнути eol і
ваші фільтри працюватимуть. Ці фільтри потрібно лише використовувати, доки ви не підготуєте a
.hgeol файлу.

Команда win32text.forbid* хуки, надані розширенням win32text, були об’єднані в a
один гачок ім eol.checkheadshook. Хук шукатиме очікувані закінчення рядків
.hgeol файл, що означає, що ви повинні перейти до a .hgeol файл перед використанням
гачок. eol.checkheadshook перевіряє лише заголовки, проміжні недійсні версії будуть надіслані.
Щоб повністю заборонити їх, використовуйте eol.checkallhook гачок. Ці гачки найкраще використовувати як
pretxnchangegroup гачки.

Читати hg допомога моделі для отримання додаткової інформації про використані шаблони glob.

extdiff
команда, щоб дозволити зовнішнім програмам порівнювати версії

Розширення extdiff Mercurial дозволяє використовувати зовнішні програми для порівняння версій,
або редакція з робочим каталогом. Зовнішні програми розрізнення викликаються за допомогою a
конфігурований набір параметрів і два аргументи, що не є параметрами: шляхи до каталогів, що містять
знімки файлів для порівняння.

Розширення extdiff також дозволяє вам налаштовувати нові команди diff, тому вам не потрібно
друкувати hg extdiff -p kdiff3 завжди

[extdiff]
# додати нову команду, яка запускає GNU різниця(1) у режимі «відмінності контексту».
cdiff = gdiff -Nprc5
## або по-старому:
#cmd.cdiff = gdiff
#opts.cdiff = -Nprc5

# додати нову команду під назвою meld, запускає meld (не потрібно називати двічі). Якщо
# виконуваний файл meld недоступний, інструмент meld у [merge-tools]
# буде використано, якщо доступно
meld =

# додайте нову команду під назвою vimdiff, запускає gvimdiff із плагіном DirDiff
# (побачити http://www.vim.org/scripts/script.php?script_id=102) Ні
# Користувач англійською мовою, обов’язково вставте «let g:DirDiffDynamicDiffText = 1» у
# ваш .vimrc
vimdiff = gvim -f "+наступний" \
"+виконати 'DirDiff' fnameescape(argv(0)) fnameescape(argv(1))"

Аргументи інструменту можуть містити змінні, які розгортаються під час виконання:

$parent1, $plabel1 - назва файлу, описова мітка першого батька
$child, $clabel - назва файлу, описова мітка дочірньої версії
$parent2, $plabel2 - ім'я файлу, описова мітка другого батька
$root - корінь сховища
$parent — це псевдонім для $parent1.

Розширення extdiff шукатиме у ваших розділах [diff-tools] та [merge-tools] diff
аргументи інструменту, якщо в [extdiff] жоден не вказаний.

[extdiff]
kdiff3 =

[інструменти розрізнення]
kdiff3.diffargs=--L1 '$plabel1' --L2 '$clabel' $parent $child

Ви можете використовувати -I/-X і список імен файлів або каталогів, як зазвичай hg різниця командування. The
Розширення extdiff робить знімки лише необхідних файлів, тому запуск зовнішнього diff
програма насправді буде досить швидкою (принаймні швидше, ніж порівнювати всю
дерево).

Команди
extdiff
використовувати зовнішню програму для розрізнення сховища (або вибраних файлів):

hg extdiff [OPT]... [ФАЙЛ]...

Показати відмінності між версіями для вказаних файлів за допомогою зовнішньої програми. The
Типовою програмою є diff із типовими параметрами "-Npru".

Щоб вибрати іншу програму, скористайтеся параметром -p/--program. Програма пройде
назви двох каталогів для порівняння. Щоб передати додаткові параметри програмі, використовуйте
-o/--варіант. Вони будуть передані перед назвами каталогів для порівняння.

Якщо вказано два аргументи редакції, то зміни відображаються між цими редакціями. Якщо
вказана лише одна редакція, тоді ця редакція порівнюється з робочим каталогом,
і, якщо ревізії не вказані, файли робочого каталогу порівнюються з його
батько.

варіанти:

-p,--програма
програма порівняння для запуску

-о,--варіант
передайте опцію програмі порівняння

-р,--rev
перегляд

-c,--зміна
зміна, внесена шляхом перегляду

--патч
порівняти патчі для двох ревізій

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

фактотум
http аутентифікація за допомогою factotum

Це розширення дозволяє фактотум(4) об’єкт на плані 9 від платформ Bell Labs до
надати інформацію автентифікації для доступу HTTP. Записи конфігурації, указані в
розділ auth, а також інформацію про автентифікацію, надану в URL-адресі сховища
повністю підтримується. Якщо префікс не вказано, буде прийнято значення "*".

За замовчуванням ключі вказуються як:

proto=pass service=hg префікс= користувач= !пароль=

Якщо розширення factotum не може прочитати потрібний ключ, його буде запропоновано
інтерактивно.

Розділ конфігурації доступний для налаштування поведінки під час виконання. За замовчуванням ці
записи:

[фактотум]
виконуваний файл = /bin/auth/factotum
точка монтування = /mnt/factotum
обслуговування = hg

Виконуваний запис визначає повний шлях до двійкового файла factotum. Запис точки монтування
визначає шлях до файлової служби factotum. Нарешті, вхід служби контролює
назва служби, що використовується під час читання ключів.

отримувати
витягувати, оновлювати та об’єднувати в одній команді (ЗАСТАРЕЛО)

Команди
отримувати
отримати зміни з віддаленого сховища, об’єднати нові зміни, якщо потрібно.:

hg fetch [ДЖЕРЕЛО]

Це знаходить усі зміни зі сховища за вказаним шляхом або URL-адресою та додає їх
локальне сховище.

Якщо витягнуті зміни додають нову голову гілки, вона автоматично об’єднується, а
результат злиття фіксується. В іншому випадку робочий каталог оновлюється, щоб включити
нові зміни.

Коли потрібне злиття, робочий каталог спочатку оновлюється до щойно отриманого
зміни. Потім локальні зміни об’єднуються в отримані зміни. Щоб змінити порядок злиття,
використовуйте --switch-parent.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

У разі успіху повертає 0.

варіанти:

-р,--rev
конкретну версію, яку ви хотіли б витягти

-е, --редагувати
викликати редактор для повідомлень про фіксацію

--force-редактор
редагувати повідомлення коміту (ЗАСТАРЕЛО)

--перемикач-батька
поміняти батьків при злитті

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

gpg
команди для підписання та перевірки наборів змін

Команди
sigcheck
перевірте всі підписи, які можуть бути для конкретної редакції:

hg sigcheck REV

перевірити всі підписи, які можуть бути для певної редакції

підпис
додати підпис для поточної або даної версії:

знак hg [ОПЦІЯ]... [ПОВЕР.]...

Якщо ревізії не вказано, використовується батьківський каталог робочого каталогу або підказка, якщо ні
редакція перевірена.

Команда gpg.cmd Налаштування config можна використовувати для вказівки команди для виконання. Типовим ключем може бути
зазначено с gpg.key.

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

варіанти:

-л, --місцевий
зробити підпис локальним

-f, --сила
знак, навіть якщо sigfile змінено

--без фіксації
не фіксуйте sigfile після підписання

-к,--ключ
ідентифікатор ключа для підпису

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

сиги
список підписаних змін:

hg sigs

список підписаних наборів змін

graphlog
команда для перегляду графіків версій з оболонки (ЗАСТАРЕЛО)

Функціональність цього розширення включено в ядро ​​Mercurial з версії 2.3.
Будь ласка, використовуйте hg журнал -G ... замість цього.

Це розширення додає опцію --graph до вхідних, вихідних і журнальних команд. Коли це
наведено параметри, а також показано ASCII-представлення графіка версій.

Команди
глід
показати історію редакцій разом із графіком редакцій ASCII:

hg glog [ВАРІАНТ]... [ФАЙЛ]

Надрукуйте історію версій разом із графіком версій, намальованим символами ASCII.

Вузли, надруковані як символ @, є батьками робочого каталогу.

Це псевдонім для hg журнал -G.

варіанти:

-f, -- слідувати
слідкуйте за історією набору змін або історією файлів між копіями та перейменуваннями

-- слідувати першим
слідувати лише за першим батьком наборів змін для злиття (ЗАСТАРЕЛО)

-d,--дата
показати редакції, що відповідають даті спец

-C, -- копії
показати скопійовані файли

-к,--ключове слово
здійснювати пошук заданого тексту без урахування регістру

-р,--rev
показати вказану редакцію або скидання

-- видалено
включити редакції, де файли були видалені

-м, --лише-злиття
показувати лише злиття (ЗАСТАРЕЛО)

-у,--користувач
редакції, внесені користувачем

--тільки-філія
показувати лише набори змін у межах даної іменованої гілки (ЗАСТАРЕЛО)

-б,-філія
показати набори змін у вказаній гілці

-П,-- чорнослив
не відображати редакцію або будь-кого з його предків

-p, --патч
показати патч

-g, --git
використовуйте розширений формат git diff

-л,--ліміт
обмежити кількість відображених змін

-М, --без злиття
не показувати злиття

--стат вивести підсумок змін у стилі diffstat

-G, --граф
показати ревізію DAG

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

hgcia
хуки для інтеграції зі службою сповіщень CIA.vc

Це призначено для запуску як група змін або вхідний хук. Щоб налаштувати його, встановіть
такі параметри у вашому hgrc:

[cia]
# ваше зареєстроване ім'я користувача CIA
користувач = foo
# назва проекту в CIA
проект = foo
# модуль (підпроект) (необов'язково)
#module = foo
# Додайте diffstat до повідомлення журналу (необов'язково)
#diffstat = False
# Шаблон для повідомлень журналу (необов'язково)
#template = {desc}\n{baseurl}{webroot}/rev/{node}-- {diffstat}
# Стиль для використання (необов'язково)
#стиль = foo
# URL-адреса служби сповіщень ЦРУ (необов'язково)
# Ви можете використовувати mailto: URL-адреси для надсилання електронною поштою, наприклад
# MAILTO:[захищено електронною поштою]
# Обов’язково встановіть email.from, якщо ви це зробите.
#url = http://cia.vc/
# друкувати повідомлення замість надсилання (необов'язково)
#test = False
# кількість скісних рисок, які потрібно видалити для URL-шляхів
#strip = 0

[гачки]
# один з цих:
changegroup.cia = python:hgcia.hook
#incoming.cia = python:hgcia.hook

[веб]
# Якщо вам потрібні гіперпосилання (необов’язково)
baseurl = http://server/path/to/repo

hgk
переглядати репозиторій у графічному вигляді

Розширення hgk дозволяє переглядати історію сховища в графічному вигляді. Це
вимагає Tcl/Tk версії 8.4 або новішої. (Tcl/Tk не поширюється з Mercurial.)

hgk складається з двох частин: сценарію Tcl, який виконує відображення та запити
інформації, а також розширення Mercurial під назвою hgk.py, яке забезпечує підключення для hgk до
отримати інформацію. hgk можна знайти в каталозі contrib, і розширення постачається
у сховищі hgext, і його потрібно ввімкнути.

Команда hg вид команда запустить сценарій hgk Tcl. Щоб ця команда працювала, hgk має бути
на вашому шляху пошуку. Крім того, ви можете вказати шлях до hgk у своїй конфігурації
Файл:

[hgk]
шлях = /location/of/hgk

hgk може використовувати розширення extdiff для візуалізації версій. Припускаючи, що ви мали
уже налаштована команда extdiff vdiff, просто додайте:

[hgk]
vdiff=vdiff

Контекстне меню версій тепер відображатиме додаткові записи для запуску vdiff при наведенні та
вибрані версії.

Команди
вид
запустити інтерактивний переглядач історії:

hg view [-l LIMIT] [REVRANGE]

запустити інтерактивний засіб перегляду історії

варіанти:

-л,--ліміт
обмежити кількість відображених змін

виділити
підсвічування синтаксису для hgweb (потрібні Pygments)

Це залежить від бібліотеки підсвічування синтаксису Pygments: http://pygments.org/

Існують наступні параметри конфігурації:

[веб]
pygments_style = (default: colorful)
highlightfiles = (за замовчуванням: size('<5M'))
highlightonlymatchfilename = (за замовчуванням False)

highlightonlymatchfilename виділить лише файли, якщо можна визначити їх тип
їх ім'я файлу. Якщо це не ввімкнено (за замовчуванням), Pygments дуже старатиметься
визначте тип файлу за вмістом і будь-яким збігом (навіть за збігами з низькою достовірністю
оцінка).

histedit
інтерактивне редагування історії

Після встановлення цього розширення Mercurial отримує одну нову команду: histedit. Використання як
слідує, припускаючи таку історію:

@ 3[підказка] 7c2fd3b9020c 2009-04-27 18:04 -0500 durin42
| Додати дельту
|
o 2 030b686bedc4 2009-04-27 18:04 -0500 durin42
| Додайте гамму
|
o 1 c561b4e977df 2009-04-27 18:04 -0500 durin42
| Додати бета-версію
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 durin42
Додати альфа

Якби ти бігав hg histedit c561b4e977df, ви побачите відкритий наступний файл у вашому
редактор:

вибрати c561b4e977df Додати бета-версію
вибрати 030b686bedc4 Додати гамму
вибрати 7c2fd3b9020c Додати дельту

# Історія редагування між c561b4e977df та 7c2fd3b9020c
#
# Коміти перераховані від найменшого до останнього
#
# Команди:
# p, pick = використовувати commit
# e, редагувати = використовувати фіксацію, але зупинитися для внесення змін
# f, fold = використовуйте commit, але поєднайте його з тим, що наведено вище
# r, roll = як fold, але відкинути опис цього коміту
# d, drop = видалити фіксацію з історії
# m, mess = редагувати повідомлення коміту без зміни вмісту коміту
#

У цьому файлі рядки, що починаються з # ігноруються. Ви повинні вказати правило для кожного
перегляд вашої історії. Наприклад, якщо ви мали на увазі додати гамму перед бета-версією, а потім
хотів додати дельту в тій самій версії, що й бета-версію, ви б реорганізували файл, щоб виглядати
подобається це:

вибрати 030b686bedc4 Додати гамму
вибрати c561b4e977df Додати бета-версію
складіть 7c2fd3b9020c Додайте дельту

# Історія редагування між c561b4e977df та 7c2fd3b9020c
#
# Коміти перераховані від найменшого до останнього
#
# Команди:
# p, pick = використовувати commit
# e, редагувати = використовувати фіксацію, але зупинитися для внесення змін
# f, fold = використовуйте commit, але поєднайте його з тим, що наведено вище
# r, roll = як fold, але відкинути опис цього коміту
# d, drop = видалити фіксацію з історії
# m, mess = редагувати повідомлення коміту без зміни вмісту коміту
#

У цей момент ви закриваєте редактор і histedit починає працювати. Коли ви вказуєте a скласти
операція, histedit відкриє редактор, коли він складе ці редакції разом, пропонуючи
у вас є можливість очистити повідомлення коміту:

Додати бета-версію
***
Додати дельту

Відредагуйте повідомлення коміту на свій смак, а потім закрийте редактор. Для цього прикладу давайте
припустимо, що повідомлення про фіксацію було змінено на додавати бета та дельта. Після запуску histedit
і мав шанс видалити будь-які старі або тимчасові версії, які йому потрібні, виглядає історія
подобається це:

@ 2[підказка] 989b4d060121 2009-04-27 18:04 -0500 durin42
| Додайте бета та дельта.
|
o 1 081603921c3f 2009-04-27 18:04 -0500 durin42
| Додайте гамму
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 durin42
Додати альфа

Зверніть увагу, що histedit робить НЕ видалити будь-які редакції (навіть власні тимчасові) до останнього
він завершив усі операції редагування, тому він, ймовірно, виконає кілька смуг
операції, коли це зроблено. У наведеному вище прикладі смугу потрібно було виконати двічі. Смужка може бути
повільно, залежно від низки факторів, тому вам, можливо, доведеться трохи терпіти. Ти можеш
виберіть зберегти вихідні версії, передавши -- тримати прапор

Команда редагувати операція поверне вас до командного рядка, де ви зможете редагувати файли
вільно або навіть використовувати hg запис щоб зафіксувати деякі зміни окремим комітом. Коли ти
зроблено, будь-які незафіксовані зміни також будуть зафіксовані. Коли закінчите, біжіть hg
histedit --продовжити щоб завершити цей крок. Вам буде запропоновано нове повідомлення про фіксацію, але
типовим повідомленням фіксації буде вихідне повідомлення для редагувати вид ред.

Команда повідомлення операція дасть вам можливість переглянути повідомлення коміту без змін
вміст. Це ярлик для виконання редагувати одразу за ним hg histedit
--продовжити`.

If histedit стикається з конфліктом під час переміщення ревізії (під час обробки вибирати or скласти),
це зупиниться подібним чином до редагувати з тією різницею, що він не запитуватиме a
зафіксувати повідомлення після завершення. Якщо на цьому етапі ви вирішите, що вам не подобається, скільки це працює
буде переставити історію, або те, що ви зробили помилку, ви можете використовувати hg histedit --перервати
щоб відмовитися від нових змін, які ви внесли, і повернутися до стану, до якого ви намагалися це зробити
редагувати історію.

Якщо ми клонуємо наведений вище приклад histeded-ed і додамо ще чотири зміни, наприклад
маємо таку історію:

@ 6[підказка] 038383181893 2009-04-27 18:04 -0500 стефан
| Додайте тету
|
o 5 140988835471 2009-04-27 18:04 -0500 стефан
| Додайте ета
|
o 4 122930637314 2009-04-27 18:04 -0500 стефан
| Додайте дзету
|
o 3 836302820282 2009-04-27 18:04 -0500 стефан
| Додайте епсилон
|
o 2 989b4d060121 2009-04-27 18:04 -0500 durin42
| Додайте бета та дельта.
|
o 1 081603921c3f 2009-04-27 18:04 -0500 durin42
| Додайте гамму
|
o 0 d8d2fcd0e319 2009-04-27 18:04 -0500 durin42
Додати альфа

Якщо ти біжиш hg histedit -- вихідний на клоні, то це те саме, що запущено hg histedit
836302820282. Якщо вам потрібно запланувати надсилання до сховища, яке Mercurial не виявляє
бути пов’язаним із вихідним репо, ви можете додати a --сила варіант.

конфиг
За замовчуванням рядки правила Histedit скорочуються до 80 символів. Ви можете налаштувати це
поведінку, встановивши іншу довжину у файлі конфігурації:

[histedit]
linelen = 120 # скоротити рядки правила на 120 символів

hg histedit намагається автоматично вибрати відповідну базову версію для використання. до
змінити базову версію, яка використовується, визначте revset у вашому файлі конфігурації:

[histedit]
defaultrev = only(.) & draft()

За замовчуванням кожна редагована версія має бути присутня в командах histedit. Видалити
редакція, яку потрібно використовувати падіння операція. Ви можете налаштувати відкидання неявним для
відсутні коміти, додавши:

[histedit]
dropmissing = Правда

Команди
histedit
інтерактивно редагувати історію набору змін:

hg histedit [ПАРАМЕТИ] ([ПРЕДОК] | --outgoing [URL])

Ця команда дозволяє редагувати лінійний ряд наборів змін (до робочого
каталог, який повинен бути чистим). Ти можеш:

· вибирати щоб [пере]впорядкувати набір змін

· падіння щоб пропустити набір змін

· безлад щоб переформулювати повідомлення коміту набору змін

· скласти щоб поєднати його з попереднім набором змін

· котити like fold, але відкидаючи опис цього коміту

· редагувати щоб редагувати цей набір змін

Є кілька способів вибрати кореневий набір змін:

· Вкажіть безпосередньо ANCESTOR

· Використовуйте --outgoing -- це буде перший лінійний набір змін, не включений до призначення.
(Див. hg допомога config.default-push)

· В іншому випадку значення з параметра конфігурації "histedit.defaultrev" використовується як revset для
виберіть базову версію, якщо ANCESTOR не вказано. Першу редакцію повернув
використовується revset. За замовчуванням вибирається редагована історія, унікальна для
походження робочого каталогу.

Якщо ви використовуєте --outgoing, ця команда буде перервана, якщо є неоднозначні вихідні версії.
Наприклад, якщо є кілька гілок, що містять вихідні версії.

Використовуйте "min(outgoing() and ::.)" або подібну специфікацію revset замість --outgoing to
вкажіть редагувати цільову версію саме в такій неоднозначній ситуації. Побачити hg допомога ревсець та цінності
докладно про вибір версій.

Приклади:

· Внесено низку змін. Редакція 3 більше не потрібна.

Почати редагування історії з версії 3:

hg histedit -r 3

Відкриється редактор, який містить список версій із зазначеними конкретними діями:

вибрати 5339bf82f0ca 3 Зворгл foobar
pick 8ef592ce7cc4 4 Засліпіть зерлог
pick 0a9639fcda9d 5 Morgify кромулант

Додаткова інформація про можливі дії з’являється під списком
ревізії.

Щоб видалити ревізію 3 з історії, її дію (на початку відповідної
line) змінюється на 'drop':

drop 5339bf82f0ca 3 Zworgle the foobar
pick 8ef592ce7cc4 4 Засліпіть зерлог
pick 0a9639fcda9d 5 Morgify кромулант

· Внесено низку змін. Ревізії 2 і 4 потрібно поміняти місцями.

Почати редагування історії з версії 2:

hg histedit -r 2

Відкриється редактор, який містить список версій із зазначеними конкретними діями:

вибрати 252a1af424ad 2 Blorb a morgwazzle
вибрати 5339bf82f0ca 3 Зворгл foobar
pick 8ef592ce7cc4 4 Засліпіть зерлог

Щоб поміняти місцями версії 2 і 4, її рядки міняються місцями в редакторі:

pick 8ef592ce7cc4 4 Засліпіть зерлог
вибрати 5339bf82f0ca 3 Зворгл foobar
вибрати 252a1af424ad 2 Blorb a morgwazzle

Повертає 0 у разі успіху, 1, якщо потрібне втручання користувача (не лише для навмисного "редагування"
команди, а також для вирішення неочікуваних конфліктів).

варіанти:

-- команди
читати історію змін із зазначеного файлу

-c, --продовжити
продовжити редагування, яке вже триває

--edit-plan
редагувати список дій, що залишилися

-к, -- тримати
не видаляйте старі вузли після завершення редагування

--перервати
припинити поточне редагування

-о, -- вихідний
наборів змін не знайдено в місці призначення

-f, --сила
примусово надсилати навіть для непов’язаних сховищ

-р,--rev
перша версія для редагування

Позначений [+] параметр можна вказати кілька разів

ключове слово
розгорнути ключові слова у відстежуваних файлах

Це розширення розширює RCS/CVS-подібні або самостійно налаштовані $Keywords$ у відстежених текстових файлах
вибрані відповідно до вашої конфігурації.

Ключові слова розгортаються лише в локальних сховищах і не зберігаються в історії змін. The
механізм можна розглядати як зручність для поточного користувача або для архіву
розподіл.

Ключові слова розширюються до даних набору змін, що стосуються останніх змін щодо
робочий каталог, батьківський для кожного файлу.

Конфігурація виконується в розділах [keyword], [keywordset] і [keywordmaps] hgrc
файли.

приклад:

[ключове слово]
# розгорнути ключові слова в кожному файлі python, крім тих, що відповідають "x*"
**.py =
x* = ігнорувати

[набір ключових слів]
# віддайте перевагу svn-, ніж cvs-подібним типовим картам ключових слів
svn = Правда

Примітка. Чим точніше ви використовуєте шаблони назв файлів, тим менше ви втрачаєте швидкість у великій кількості
сховища.

Для [keywordmaps] зіставлення шаблону та розширення демонстрації та керування hg kwdemo.
Читати hg допомога Шаблони щоб переглянути список доступних шаблонів і фільтрів.

Надаються три додаткові фільтри шаблону дати:

utcdate

"2006/09/18 15:13:13"

svnutcdate

"2006-09-18 15:13:13Z"

svnisodate

"2006-09-18 08:13:13 -700 (пн, 18 вересня 2006 р.)"

Зіставлення шаблонів за замовчуванням (перегляд за допомогою hg kwdemo -d) можна замінити на налаштований
ключові слова та шаблони. Знову біжи hg kwdemo щоб контролювати результати вашої конфігурації
зміни.

Перед зміною/вимкненням активних ключових слів необхідно запустити hg kwsshrink щоб уникнути зберігання
розширені ключові слова в історії змін.

Щоб примусово розширити після його ввімкнення або зміни конфігурації, запустіть hg kwexpand.

Розширення, що охоплюють більше ніж один рядок, і поступове розширення, як $Log$ CVS, є
Не підтримується. Карта шаблону ключового слова "Log = {desc}" розгортається до першого рядка
опис набору змін.

Команди
kwdemo
print [keywordmaps] конфігурація та приклад розширення:

hg kwdemo [-d] [-f RC-ФАЙЛ] [КАРА ШАБЛОНУ]...

Показати поточні, користувальницькі або стандартні карти шаблонів ключових слів та їх розширення.

Розширте поточну конфігурацію, вказавши карти як аргументи та використовуючи -f/--rcfile
джерело зовнішній файл hgrc.

Використовуйте -d/--default, щоб вимкнути поточну конфігурацію.

Читати hg допомога Шаблони для отримання інформації про шаблони та фільтри.

варіанти:

-d, --за замовчуванням
показати стандартні карти шаблонів ключових слів

-f,--rcfile
читати карти з rcfile

kwexpand
розширити ключові слова в робочому каталозі:

hg kwexpand [ПАРАМЕТР]... [ФАЙЛ]...

Запустити після (повторного) увімкнення розширення ключових слів.

kwexpand відмовляється запускатися, якщо дані файли містять локальні зміни.

варіанти:

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

файли kw
показати файли, налаштовані для розширення ключових слів:

hg kwfiles [ПАРАМЕТР]... [ФАЙЛ]...

Перелічіть, які файли в робочому каталозі відповідають конфігурації [ключове слово].
моделі.

Корисно для запобігання ненавмисному розширенню ключових слів і для прискорення виконання шляхом включення
лише ті файли, які дійсно є кандидатами на розширення.

Читати hg допомога ключове слово про те, як побудувати шаблони як для включення, так і для виключення
файли.

З -A/--all і -v/--verbose коди, які використовуються для відображення стану файлів:

K = кандидат на розширення ключового слова
k = кандидат на розширення ключового слова (не відстежується)
Я = проігноровано
i = ігнорується (не відстежується)

варіанти:

-A, --все
показати позначки статусу ключових слів усіх файлів

-я, --ігнорувати
показати файли, виключені з розширення

-у, --невідомо
показувати лише невідомі (не відстежувані) файли

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

kwsshrink
повернути розширені ключові слова в робочому каталозі:

hg kwshrink [ПАРАМЕТР]... [ФАЙЛ]...

Необхідно запустити перед зміною/вимкненням активних ключових слів.

kwshrink відмовляється запускатися, якщо дані файли містять локальні зміни.

варіанти:

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

великі файли
відстежувати великі двійкові файли

Великі двійкові файли, як правило, не дуже стискаються, не дуже розрізняються, а то й взагалі
зливаються. Такі файли не обробляються ефективно у форматі зберігання Mercurial (revlog),
яка базується на стислих двійкових дельтах; зберігання великих бінарних файлів як звичайних
Файли Mercurial витрачають пропускну спроможність і дисковий простір і збільшують використання пам’яті Mercurial.
Розширення largefiles вирішує ці проблеми, додаючи централізований клієнт-сервер
шар поверх Mercurial: великі файли знаходяться в a центральний зберігати в мережі
десь, і ви отримуєте лише ті редакції, які вам потрібні, коли вони вам потрібні.

largefiles працює, зберігаючи "standin файл" у .hglf/ для кожного largefile. The
standins невеликі (41 байт: хеш SHA-1 плюс новий рядок) і відстежуються Mercurial.
Версії великого файлу ідентифікуються хешем SHA-1 їх вмісту, який записується
до стоячи. largefiles використовує цей ідентифікатор версії для отримання/переміщення версій великих файлів з/до
центральний магазин. Це економить дисковий простір і пропускну здатність, оскільки вам цього не потрібно
отримати всі історичні версії великих файлів під час клонування або вилучення.

Щоб створити нове сховище або додати нові великі двійкові файли, просто додайте --large до вашого hg додавати
команду. Наприклад:

$ dd if=/dev/urandom of=randomdata count=2000
$ hg add --великі випадкові дані
$ hg commit -m 'додати випадкові дані як великий файл'

Коли ви надсилаєте набір змін, який додає/змінює великі файли до віддаленого сховища, його
версії великих файлів будуть завантажені разом з ним. Зауважте, що дистанційний Mercurial повинен
також увімкніть розширення largefiles, щоб це працювало.

Коли ви отримуєте набір змін, який впливає на великі файли, із віддаленого сховища, великі файли
оскільки набір змін за замовчуванням не буде витягнуто. Однак, коли ви оновлюєте до такого
версії, будь-які великі файли, необхідні для цієї версії, завантажуються та кешуються (якщо вони є
ніколи раніше не завантажувався). Таким чином, одним із способів отримання великих файлів є використання
--update, який оновить вашу робочу копію до останньої вилученої версії (і таким чином
завантаження будь-яких нових великих файлів).

Якщо ви хочете отримати великі файли, які вам ще не потрібні для оновлення, ви можете використовувати pull with
--lfrev опція або hg lfpull команда

Якщо ви знаєте, що ви завантажуєте з місця, яке не є стандартним, і хочете завантажити всі
великі файли, які одночасно відповідають новим наборам змін, тоді ви можете використовувати їх
--lfrev "витягнув()".

Якщо ви просто хочете переконатися, що у вас будуть великі файли, необхідні для об’єднання або перебазування
з новими головами, які ви тягнете, тоді ви можете тягнути --lfrev "голова(витяг())" прапор
щоб завчасно завантажити будь-які великі файли, які є новими в головах, які ви витягуєте.

Майте на увазі, що доступ до мережі тепер може знадобитися для оновлення до наявних наборів змін
раніше не оновлено до. Природа розширення largefiles означає, що оновлення є
більше не гарантується, що це буде лише локальна операція.

Якщо у вас уже є великі файли, які відстежуються Mercurial без розширення largefiles, ви
потрібно буде конвертувати ваше сховище, щоб отримати вигоду від великих файлів. Це зроблено
з hg lfconvert команда:

$ hg lfconvert --size 10 старе сховище нове сховище

У сховищах, які вже містять великі файли, будь-який новий файл розміром понад 10 МБ буде
автоматично додається як великий файл. Щоб змінити цей поріг, встановіть largefiles.minsize in
ваш конфігураційний файл Mercurial до мінімального розміру в мегабайтах для відстеження як великого файлу, або
використовуйте опцію --lfsize для команди add (також у мегабайтах):

[великі файли]
мінімальний розмір = 2

$ hg add --lfsize 2

Команда largefiles.patterns Параметр config дозволяє вказати список шаблонів імен файлів
(Див. hg допомога моделі), які слід завжди відстежувати як великі файли:

[великі файли]
візерунки =
* .jpg
re:.*\.(png|bmp)$
бібліотека.zip
контент/аудіо/*

Файли, які відповідають одному з цих шаблонів, будуть додані як великі файли незалежно від їхнього
розмір.

Команда largefiles.minsize та largefiles.patterns параметри конфігурації ігноруватимуться
сховища, які ще не містять великий файл. Щоб додати перший великий файл до a
репозиторію, ви повинні зробити це явно за допомогою прапора --large, переданого до hg додавати команда

Команди
lfconvert
перетворити звичайне сховище на сховище великих файлів:

hg lfconvert SOURCE DEST [ФАЙЛ ...]

Перетворіть репозиторій SOURCE на новий репозиторій DEST, ідентичний SOURCE, за винятком того, що
певні файли буде перетворено як великі файли: зокрема, будь-який файл, який відповідає будь-якому
ПАТЕРН or розмір якого перевищує мінімальне порогове значення, перетворюється на великий файл. The
розмір, який використовується для визначення того, чи відстежувати файл, оскільки великий файл — це розмір файлу
перша версія файлу. Мінімальний розмір можна вказати за допомогою --size або in
конфігурація як largefiles.size.

Після виконання цієї команди вам потрібно буде переконатися, що largefiles увімкнено будь-де
ви маєте намір розмістити нове сховище.

Використовуйте --to-normal, щоб конвертувати великі файли назад у звичайні; після цього DEST
репозиторій можна використовувати взагалі без великих файлів.

варіанти:

-так,--розмір
мінімальний розмір (Мб) для файлів, які потрібно перетворити на великі файли

--до норми
конвертувати зі сховища великих файлів на звичайне сховище

lfpull
отримати великі файли для вказаних версій із вказаного джерела:

hg lfpull -r REV... [-e CMD] [--remotecmd CMD] [ДЖЕРЕЛО]

Витягувати великі файли, на які посилаються локальні набори змін, але відсутні локально, витягувати
з віддаленого сховища в локальний кеш.

Якщо SOURCE опущено, буде використаний шлях «за замовчуванням». Подивитися hg допомога URL-адреси більше
інформація.

Приклади:

· отримати великі файли для всіх заголовків гілок:

hg lfpull -r "head() і не закрито()"

· витягти великі файли на гілку за замовчуванням:

hg lfpull -r "гілка (за замовчуванням)"

варіанти:

-р,--rev
отримати великі файли для цих версій

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

mq
керувати стеком патчів

Це розширення дозволяє працювати зі стеком виправлень у сховищі Mercurial. Це вдається
два стеки патчів - усі відомі патчі та застосовані патчі (підмножина відомих патчів).

Відомі латки представлені у вигляді файлів латок у каталозі .hg/patches. Накладені патчі
є файлами виправлень і наборами змін.

Загальні завдання (використання hg допомога команда для більш детальної інформації):

створити новий патч qnew
імпортувати існуючий патч qimport

серія патчів друку qseries
надрукувати застосовані патчі qapplied

додати відомий патч до застосованого стеку qpush
видалити патч із застосованого стека qpop
оновити вміст верхнього застосованого патча qrefresh

За замовчуванням mq автоматично використовуватиме патчі git, коли буде потрібно, щоб уникнути втрати файлового режиму
зміни, копіювання записів, створення чи видалення двійкових файлів або порожніх файлів. Ця поведінка
можна налаштувати за допомогою:

[mq]
git = auto/keep/yes/no

Якщо встановлено значення «keep», mq підпорядковуватиметься конфігурації розділу [diff], зберігаючи існуючу
патчі git після qrefresh. Якщо встановлено «так» або «ні», mq замінить розділ [diff].
і завжди генеруйте git або звичайні патчі, у другому випадку можлива втрата даних.

Може бути бажаним, щоб набори змін mq зберігалися в секретній фазі (див hg допомога фаз),
який можна ввімкнути за допомогою таких налаштувань:

[mq]
секрет = Правда

За умовчанням ви керуватимете чергою виправлень під назвою "патчі". Ви можете створити інші,
незалежні черги виправлення з hg qqueue команда

Якщо робочий каталог містить незакріплені файли, qpush, qpop і qgoto переривають
негайно. Якщо використовується -f/--force, зміни скасовуються. налаштування:

[mq]
keepchanges = Правда

змусити їх поводитися так, ніби було передано --keep-changes, і неконфліктні локальні зміни будуть
терпіти і зберігати. Якщо є несумісні параметри, такі як -f/--force або --exact
пройдено, це налаштування ігнорується.

Це розширення використовувалося для надання команди strip. Ця команда тепер живе в смузі
розширення.

Команди
qзастосовано
роздрукувати вже застосовані патчі:

hg qapplied [-1] [-s] [ПАТЧ]

У разі успіху повертає 0.

варіанти:

-1, --останнє
показати лише попередній застосований патч

-так, -- резюме
надрукувати перший рядок заголовка латки

qclone
клонувати основний і репозиторій виправлень одночасно:

hg qclone [ПАРАМЕТР]... ДЖЕРЕЛО [ЦІЛЬ]

Якщо джерело є локальним, до місця призначення не буде застосовано латок. Якщо джерело віддалене, це
Команда не може перевірити, чи латки застосовано у джерелі, тому не може гарантувати, що латки
не застосовуються в пункті призначення. Якщо ви клонуєте віддалений репозиторій, переконайтеся, що він є
патчі не застосовуються.

Вихідне сховище виправлень шукається в /.hg/patches за замовчуванням. Використовуйте -p до
змінити.

Каталог виправлень має бути вкладеним репозиторієм Mercurial, який би створив hg ініціалізації
--mq.

У разі успіху повертайте 0.

варіанти:

--тягнути використовуйте протокол pull для копіювання метаданих

-У, --noupdate
не оновлювати нові робочі каталоги

--нестиснутий
використовувати нестиснену передачу (швидко через локальну мережу)

-p,--патчі
розташування вихідного сховища виправлень

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

qcommit
зафіксувати зміни в репозиторії черги (ЗАСТАРЕЛО):

hg qcommit [ПАРАМЕТР]... [ФАЙЛ]...

Ця команда застаріла; використовувати hg commit --mq замість цього.

варіанти:

-A, --addremove
перед фіксацією позначте нові/відсутні файли як додані/видалені

--ближне відділення
позначте головку гілки як закриту

--виправити
внести зміни до батьківського каталогу робочого каталогу

-так, -- секрет
використовуйте секретну фазу для фіксації

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-я, --інтерактивні
використовувати інтерактивний режим

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

-S, --підтримка
повертатися в підрепозиторії

Позначений [+] параметр можна вказати кілька разів

псевдоніми: qci

qdelete
видалити патчі з черги:

hg qdelete [-k] [ПАТЧ]...

Пластирі не можна накладати, потрібен хоча б один патч. Точний патч
необхідно надати ідентифікатори. За допомогою -k/--keep файли виправлення зберігаються в патчі
каталог.

Щоб припинити керування виправленням і перемістити його до постійної історії, скористайтеся hg qfinish команда

варіанти:

-к, -- тримати
зберегти файл виправлення

-р,--rev
припинити керування версією (ЗАСТАРЕЛО)

Позначений [+] параметр можна вказати кілька разів

псевдоніми: qremove qrm

qdiff
diff поточного патча та наступних змін:

hg qdiff [ПАРАМЕТР]... [ФАЙЛ]...

Показує різницю, яка включає поточний патч, а також будь-які внесені зміни
у робочому каталозі з моменту останнього оновлення (таким чином показуючи, що буде робити поточний патч
стати після qrefresh).

Скористайтесь hg різниця якщо ви хочете лише переглянути зміни, внесені після останнього qrefresh, або hg експорт
qtip якщо ви бажаєте переглянути зміни, внесені поточним патчем, не включаючи внесені зміни
після qrefresh.

У разі успіху повертає 0.

варіанти:

-а, --текст
розглядати всі файли як текст

-g, --git
використовуйте розширений формат git diff

-- вузли
пропускати дати із заголовків diff

--непрефікс
опустити префікси a/ і b/ з імен файлів

-p, --показувати функцію
показати, до якої функції відноситься кожна зміна

--зворотний
створити diff, який скасовує зміни

-w, --ігнорувати-все-пробіл
ігноруйте пробіл під час порівняння рядків

-б, --ignore-space-change
ігнорувати зміни в кількості пробілів

-Б, --ignore-blank-lines
ігнорувати зміни, усі рядки яких порожні

-У,--уніфікований
кількість рядків контексту для відображення

--стат вивести підсумок змін у стилі diffstat

--корінь
створювати відмінності щодо підкаталогу

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

qfinish
перемістити застосовані латки в історію сховища:

hg qfinish [-a] [REV]...

Завершує вказані версії (що відповідають застосованим латкам), переміщуючи їх із
mq control у звичайну історію сховища.

Приймає діапазон версії або опцію -a/--applied. Якщо вказано --applied, усі
застосовані версії mq видаляються з керування mq. В іншому випадку дані зміни повинні бути
в основі стопки нанесених латок.

Це може бути особливо корисним, якщо ваші зміни було застосовано до попереднього сховища,
або якщо ви збираєтеся перенести свої зміни до попередньої версії.

У разі успіху повертає 0.

варіанти:

-а, -- прикладний
завершити всі застосовані набори змін

qfold
складіть названі патчі в поточний патч:

hg qfold [-e] [-k] [-m ТЕКСТ] [-l ФАЙЛ] ПАТЧ...

Патчі ще не повинні застосовуватися. Кожен патч буде послідовно застосований до поточного
патч у вказаному порядку. Якщо всі патчі успішно застосовано, буде використано поточний патч
оновлено за допомогою нового накопичувального патча, а складені патчі буде видалено. с
-k/--keep, згорнуті файли латок не будуть видалені згодом.

Заголовок кожного згорнутого патча буде об’єднано з поточним заголовком патча,
розділених лінією * * *.

У разі успіху повертає 0.

варіанти:

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-к, -- тримати
зберігайте файли виправлень у складеному вигляді

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

qgoto
штовхати або висувати патчі, доки названий патч не опиниться у верхній частині стека:

hg qgoto [ВАРІАНТ]... ПАТЧ

У разі успіху повертає 0.

варіанти:

--keep-changes
терпіти неконфліктні локальні зміни

-f, --сила
перезаписати будь-які локальні зміни

--без резервного копіювання
не зберігайте резервні копії файлів

qguard
встановити або надрукувати щитки для латки:

hg qguard [-l] [-n] [ПАТЧ] [-- [+GUARD]... [-GUARD]...]

Охоронці контролюють, чи можна проштовхнути латку. Латка без охоронців завжди штовхається. А
патч із позитивним захистом ("+foo") натискається, лише якщо hg qселект команда має
активував його. Патч із негативним захистом ("-foo") ніколи не натискається, якщо hg qселект
команда активувала його.

Без аргументів вивести поточні активні охоронці. З аргументами, поставити варту для
названий патч.

Примітка. Вказівка ​​негативних захисників тепер вимагає '--'.

Щоб встановити охоронців на інший патч:

hg qguard other.patch -- +2.6.17 - стабільний

У разі успіху повертає 0.

варіанти:

-л, -- список
перерахувати всі нашивки та щитки

-n, -- жодного
скинути всіх охоронців

qheader
надрукувати заголовок самого верхнього або вказаного патча:

hg qheader [ПАТЧ]

У разі успіху повертає 0.

qimport
імпортувати патч або існуючий набір змін:

hg qimport [-e] [-n НАЗВА] [-f] [-g] [-P] [-r REV]... [ФАЙЛ]...

Патч вставляється в серію після останнього застосованого патча. Якщо немає патчів
застосовано, qimport додає патч до серії.

Патч матиме ту саму назву, що й вихідний файл, якщо ви не присвоїте йому нове
-n/--ім'я.

Ви можете зареєструвати існуючий патч у каталозі патчів за допомогою прапорця -e/--existing.

За допомогою -f/--force існуючий патч із такою ж назвою буде перезаписано.

Існуючий набір змін можна помістити під контроль mq за допомогою -r/--rev (наприклад, qimport --rev.
-n patch помістить поточну версію під контроль mq). З -g/--git, патчі
імпортований за допомогою --rev використовуватиме формат git diff. Перегляньте розділ довідки щодо відмінностей, щоб отримати інформацію
чому це важливо для збереження інформації про перейменування/копіювання та змін дозволів.
Скористайтесь hg qfinish щоб видалити набори змін з елемента керування mq.

Щоб імпортувати латку зі стандартного вводу, передайте - як файл латки. При імпорті з
стандартний ввід, назву патча потрібно вказати за допомогою прапорця --name.

Щоб імпортувати наявний патч із перейменуванням:

hg qimport -e існуючий патч -n нова назва

Повертає 0, якщо імпортування вдалось.

варіанти:

-е, --існуючий
імпортувати файл у каталог виправлень

-n,--ім'я
ім'я файлу виправлення

-f, --сила
перезаписати наявні файли

-р,--rev
поставити існуючі редакції під контроль mq

-g, --git
використовуйте розширений формат git diff

-П, -- натиснути
qpush після імпорту

Позначений [+] параметр можна вказати кілька разів

qinit
ініціювати нове сховище черги (ЗАСТАРЕЛО):

hg qinit [-c]

Репозиторій черги за замовчуванням не має версій. Якщо вказано -c/--create-repo, qinit
створить окреме вкладене сховище для патчів (qinit -c також можна запустити пізніше, щоб
перетворити неверсійне сховище виправлень у версійне). Ви можете використовувати qcommit для
внести зміни до цього сховища черги.

Ця команда застаріла. Без -c це передбачається іншими відповідними командами. З -c,
використання hg ініціалізації --mq замість цього.

варіанти:

-c, --create-repo
створити репозиторій черги

qnew
створити новий патч:

hg qnew [-e] [-m ТЕКСТ] [-l ФАЙЛ] ПАТЧ [ФАЙЛ]...

qnew створює новий патч поверх поточного застосованого патча (якщо є). Латка буде
ініціалізовано з будь-якими незавершеними змінами в робочому каталозі. Ви також можете використовувати
-I/--include, -X/--exclude та/або список файлів після назви виправлення, щоб додати лише
змінює відповідні файли до нового патча, залишаючи решту незафіксованими змінами.

-u/--user і -d/--date можна використовувати для встановлення (даного) користувача та дати відповідно.
-U/--currentuser і -D/--currentdate встановлюють користувача поточним користувачем і дату поточною датою.

-e/--edit, -m/--message або -l/--logfile встановлює заголовок виправлення, а також фіксацію
повідомлення. Якщо нічого не вказано, заголовок порожній, а повідомлення про фіксацію — «[mq]:
ПАТЧ'.

Використовуйте параметр -g/--git, щоб зберегти патч у розширеному форматі git diff. Прочитайте відмінності
розділ довідки, щоб дізнатися більше про те, чому це важливо для збереження змін дозволу
і копіювати/перейменовувати інформацію.

Повертає 0 у разі успішного створення нового патча.

варіанти:

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-f, --сила
імпорт незафіксованих змін (ЗАСТАРЕЛО)

-g, --git
використовуйте розширений формат git diff

-У, --поточний користувач
додати "Від: " латати

-у,--користувач
додати "Від: " латати

-Д, --Поточна дата
додати "Дата: " латати

-d,--дата
додати "Дата: " латати

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

Позначений [+] параметр можна вказати кілька разів

Qnext
надрукуйте назву наступного патча, який можна натиснути:

hg qнаступний [-s]

У разі успіху повертає 0.

варіанти:

-так, -- резюме
надрукувати перший рядок заголовка латки

qpop
вилучити поточний патч зі стеку:

hg qpop [-a] [-f] [ПАТЧ | ІНДЕКС]

Без аргументів вискакує з верхньої частини стека латок. Якщо дається ім’я латки, зберігається
знімати патчі, поки названий патч не опиниться у верхній частині стека.

За замовчуванням перервати, якщо робочий каталог містить незафіксовані зміни. с
--keep-changes, перервати, лише якщо незафіксовані файли накладаються на виправлені файли. с
-f/--примусово створювати резервні копії та скасовувати зміни, внесені до таких файлів.

У разі успіху повертайте 0.

варіанти:

-а, --все
витягнути всі патчі

-n,--ім'я
назва черги для показу (ЗАСТАРЕЛО)

--keep-changes
терпіти неконфліктні локальні зміни

-f, --сила
забути будь-які локальні зміни в виправлених файлах

--без резервного копіювання
не зберігайте резервні копії файлів

qprev
надрукуйте назву попереднього застосованого патча:

hg qprev [-s]

У разі успіху повертає 0.

варіанти:

-так, -- резюме
надрукувати перший рядок заголовка латки

qpush
помістіть наступний патч у стек:

hg qpush [-f] [-l] [-a] [--move] [ПАТЧ | ІНДЕКС]

За замовчуванням перервати, якщо робочий каталог містить незафіксовані зміни. с
--keep-changes, перервати, лише якщо незафіксовані файли накладаються на виправлені файли. с
-f/--примусове, резервне копіювання та виправлення незафіксованих змін.

У разі успіху повертайте 0.

варіанти:

--keep-changes
терпіти неконфліктні локальні зміни

-f, --сила
застосувати поверх локальних змін

-е, --точні
застосувати цільовий патч до його записаного батька

-л, -- список
назва патча списку в тексті коміту

-а, --все
застосувати всі патчі

-м, -- об'єднати
об'єднати з іншої черги (ЗАСТАРЕЛО)

-n,--ім'я
назва черги злиття (ЗАСТАРЕЛО)

-- рухатися змінити порядок серії патчів і застосувати лише патч

--без резервного копіювання
не зберігайте резервні копії файлів

qqueue
керувати кількома чергами виправлень:

hg qqueue [ПАРАМЕТР] [ЧЕРГА]

Підтримується перемикання між різними чергами виправлень, а також створення нових черг виправлень
і видалення існуючих.

Якщо пропустити назву черги або вказати -l/--list, ви побачите зареєстровані черги - за
за умовчанням зареєстровано "звичайну" чергу виправлень. Буде поточна активна черга
позначено «(активний)». Якщо вказати --active, буде надруковано лише назву активної черги.

Щоб створити нову чергу, використовуйте -c/--create. Черга автоматично стає активною, за винятком в
випадок, коли є застосовані латки з поточної активної черги в
сховище. Тоді черга буде тільки створена і перемикання не вдасться.

Щоб видалити наявну чергу, використовуйте --delete. Ви не можете видалити поточну активну чергу.

У разі успіху повертає 0.

варіанти:

-л, -- список
перерахувати всі доступні черги

--активний
вивести назву активної черги

-c, --творити
створити нову чергу

--перейменувати
перейменувати активну чергу

--видалити
видалити посилання на чергу

-- очищення
видалити чергу та видалити патч

qrefresh
оновити поточний патч:

hg qrefresh [-I] [-X] [-e] [-m ТЕКСТ] [-l ФАЙЛ] [-s] [ФАЙЛ]...

Якщо надано шаблони файлів, оновлений патч міститиме лише зміни
які відповідають цим шаблонам; інші зміни залишаться в роботі
каталог.

Якщо вказано -s/--short, файли, які наразі включені до виправлення, будуть просто оновлені
подобаються відповідні файли та залишаються в патчі.

Якщо вказано -e/--edit, Mercurial запустить ваш налаштований редактор, щоб ви могли ввести a
повідомлення. У разі помилки qrefresh ви знайдете резервну копію свого повідомлення
.hg/last-message.txt.

hg add/remove/copy/rename працюють як зазвичай, хоча ви можете використовувати патчі у стилі git
(-g/--git або [diff] git=1) для відстеження копій і перейменувань. Щоб дізнатися більше, перегляньте розділ довідки про відмінності
інформація про формат git diff.

У разі успіху повертає 0.

варіанти:

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-g, --git
використовуйте розширений формат git diff

-так, --короткі
оновлювати лише файли, які вже є в патчі, і вказані файли

-У, --поточний користувач
додати/оновити поле автора в патчі з поточним користувачем

-у,--користувач
додати/оновити поле автора в патчі з даним користувачем

-Д, --Поточна дата
додати/оновити поле дати в патчі поточною датою

-d,--дата
додати/оновити поле дати в патчі з вказаною датою

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

Позначений [+] параметр можна вказати кілька разів

qrename
перейменувати патч:

hg qrename PATCH1 [PATCH2]

З одним аргументом змінює назву поточного патча на PATCH1. З двома аргументами перейменовує
PATCH1 до PATCH2.

У разі успіху повертає 0.

псевдоніми: qmv

qrestore
відновити стан черги, збережений версією (ЗАСТАРЕЛО):

hg qrestore [-d] [-u] REV

Ця команда застаріла, використовуйте hg ребаза замість цього.

варіанти:

-d, --видалити
видалити зберегти запис

-у, --оновити
оновити робочий каталог черги

qsave
зберегти поточний стан черги (ЗАСТАРЕЛО):

hg qsave [-m ТЕКСТ] [-l ФАЙЛ] [-c] [-n НАЗВА] [-e] [-f]

Ця команда застаріла, використовуйте hg ребаза замість цього.

варіанти:

-c, --копія
копіювати каталог патчів

-n,--ім'я
копіювати назву каталогу

-е, --порожній
очистити файл стану черги

-f, --сила
примусове копіювання

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

qселект
встановити або надрукувати захищені патчі для проштовхування:

hg qвиберіть [ОПЦІЯ]... [ОХОРОНА]...

Використовувати hg qguard команду для встановлення або друку захисників на патчі, а потім скористайтеся qselect, щоб повідомити mq
які охоронці використовувати. Патч буде виштовхнуто, якщо на ньому немає охоронців або будь-які позитивні охоронці
збігається з поточним вибраним охоронцем, але не буде натиснуто, якщо збігаються будь-які негативні охоронці
нинішній охоронець. Наприклад:

qguard foo.patch -- -stable (негативний захист)
qguard bar.patch +stable (позитивний захист)
qselect stable

Це активує охорону «стайні». mq пропустить foo.patch (оскільки він має негативний
збіг), але натисніть bar.patch (оскільки він має позитивний збіг).

Без аргументів друкує поточні активні захисники. З одним аргументом встановлює активний
вартовий.

Використовуйте -n/--none, щоб вимкнути захисники (інші аргументи не потрібні). Коли немає охорони
активні, патчі з позитивними охоронами пропускаються, а патчі з негативними охоронами –
штовхнув.

qselect може змінювати захисники застосованих патчів. Він не вискакує захищені патчі
за замовчуванням. Використовуйте --pop, щоб повернутися до останнього застосованого патча, який не захищено. використання
--reapply (що передбачає --pop), щоб потім повернутися до поточного патча, але пропустити
охороняються патчі.

Використовуйте -s/--series, щоб надрукувати список усіх охоронців у файлі серії (без інших аргументів
потрібно). Використовуйте -v для отримання додаткової інформації.

У разі успіху повертає 0.

варіанти:

-n, -- жодного
вимкнути всі охоронці

-так, --серія
список усіх охоронців у файлі серії

--поп відкрити перед першим захищеним застосованим патчем

--подати заявку повторно
вискочити, потім повторно застосувати патчі

qseries
надрукувати весь файл серії:

hg qseries [-ms]

У разі успіху повертає 0.

варіанти:

-м, -- відсутній
друкувати патчі не в серії

-так, -- резюме
надрукувати перший рядок заголовка латки

qtop
надрукувати назву поточного патча:

hg qtop [-s]

У разі успіху повертає 0.

варіанти:

-так, -- резюме
надрукувати перший рядок заголовка латки

qнезастосовуваний
роздрукувати ще не застосовані патчі:

hg qunapplied [-1] [-s] [ПАТЧ]

У разі успіху повертає 0.

варіанти:

-1, --спочатку
показати лише перший патч

-так, -- резюме
надрукувати перший рядок заголовка латки

повідомляти
гачки для відправки push-повідомлень електронною поштою

Це розширення реалізує хуки для надсилання сповіщень електронною поштою, коли надсилаються набори змін
або отримані локальним сховищем.

Спочатку ввімкніть розширення, як описано в hg допомога Розширення, і зареєструйте хук ви
хочеться бігти. що входить та змінити групу хуки запускаються, коли отримані набори змін, while
вихідний хуки призначені для наборів змін, надісланих до іншого сховища:

[гачки]
# один електронний лист для кожного вхідного набору змін
incoming.notify = python:hgext.notify.hook
# один електронний лист для всіх вхідних наборів змін
changegroup.notify = python:hgext.notify.hook

# один електронний лист для всіх вихідних наборів змін
outgoing.notify = python:hgext.notify.hook

Це реєструє гачки. Щоб увімкнути сповіщення, потрібно призначити абонентів
сховища. The [usersubs] розділ відображає кілька сховищ для певного одержувача. The
[reposubs] розділ відображає кількох одержувачів в одному сховищі:

[usersubs]
# ключ — електронна адреса підписника, значення — список шаблонів репо, розділених комами
користувач@хост = шаблон

[reposubs]
# ключ — шаблон репо, значення — список електронних листів підписників, розділених комами
шаблон = користувач@хост

A модель це куля зіставлення абсолютного шляху до сховища, необов’язково в поєднанні з a
вираз revset. Вираз revset, якщо він присутній, відокремлюється від глобуса хешем.
приклад:

[reposubs]
*/widgets#branch(release) = [захищено електронною поштою]

Це надсилає до [захищено електронною поштою] щоразу, коли набір змін на звільнити тригери гілок a
сповіщення в будь-якому репозиторії, що закінчується на віджети.

Щоб передати їх під пряме керування користувачами, [usersubs] та [reposubs] розділам
можна помістити в окремий hgrc файл і включено за посиланням:

[повідомити]
config = /path/to/subscriptionsfile

Сповіщення не надсилатимуться до notify.test значення встановлено на Помилковий; Дивись нижче.

Вміст сповіщень можна налаштувати за допомогою таких записів конфігурації:

notify.test
If Правда, друкувати повідомлення на stdout замість їх надсилання. Типове значення: True.

notify.sources
Список джерел змін, розділений пробілами. Сповіщення активуються лише тоді, коли a
Джерело набору змін знаходиться в цьому списку. Джерелами можуть бути:

служити

набори змін, отримані через http або ssh

тягнути

наборів змін, отриманих через hg тягнути

роз’єднати

наборів змін, отриманих через hg роз’єднати

штовхати

набори змін, надіслані або отримані через hg штовхати

пакет

набори змін, надіслані через hg роз’єднати

За замовчуванням: служити.

notify.strip
Кількість початкових скісних риск, які потрібно видалити з URL-шляхів. За замовчуванням сповіщення
репозиторії посилань із їхнім абсолютним шляхом. notify.strip дозволяє повертати їх
у відносні шляхи. Наприклад, notify.strip=3 зміниться /long/path/repository
в Сховище. Типове значення: 0.

notify.domain
Домен електронної пошти за умовчанням для відправника або одержувачів без явного домену.

notify.style
Файл стилю для використання під час форматування електронних листів.

notify.template
Шаблон для форматування електронних листів.

сповістити.вхідний
Шаблон для використання під час запуску як вхідний хук, заміна notify.template.

сповістити.вихідний
Шаблон для використання під час запуску як вихідний хук, заміна notify.template.

notify.changegroup
Шаблон для використання під час роботи як хук групи змін, перевизначення notify.template.

notify.maxdiff
Максимальна кількість рядків відмінностей для включення в електронний лист сповіщення. Встановіть 0, щоб вимкнути
diff або -1, щоб включити все це. Типове значення: 300.

notify.maxsubject
Максимальна кількість символів у темі листа. Типове значення: 67.

notify.diffstat
Установіть значення True, щоб включити параметр diffstat перед вмістом diff. Типове значення: True.

notify.merge
Якщо True, надсилати сповіщення про об’єднані набори змін. Типове значення: True.

notify.mbox
Якщо встановлено, додавати листи до цього файлу mbox замість надсилання. За замовчуванням: немає.

notify.fromauthor
Якщо встановлено, використовувати коміттера першого набору змін у групі змін для "Від"
поле поштового повідомлення. Якщо не встановлено, забрати користувача з резервного репо.
За замовчуванням: False.

Якщо встановлено, такі записи також використовуватимуться для налаштування сповіщень:

email.fr
Електронна адреса Від адреса для використання, якщо її не можна знайти у згенерованому вмісті електронної пошти.

web.baseurl
URL-адреса кореневого сховища для поєднання зі шляхами до сховища під час створення посилань. Побачити
Також notify.strip.

пейджер
перегляд команди за допомогою зовнішнього пейджера

Щоб установити пейджер, який слід використовувати, встановіть змінну програми:

[пейджер]
пейджер = менше -FRX

Якщо пейджер не встановлено, розширення пейджера використовують змінну середовища $PAGER. Якщо ні
pager.pager, $PAGER не встановлено, пейджер не використовується.

Ви можете вимкнути пейджер для певних команд, додавши їх до списку pager.ignore:

[пейджер]
ігнорувати = версія, довідка, оновлення

Ви також можете ввімкнути пейджер лише для певних команд за допомогою pager.attend. Нижче наведено
типовий список команд для перегляду:

[пейджер]
відвідувати = анотувати, cat, diff, export, glog, log, qdiff

Якщо встановити порожнє значення для pager.attend, усі команди будуть виведені на сторінки.

Якщо pager.attend присутній, pager.ignore буде проігноровано.

Нарешті, ви можете ввімкнути та вимкнути сторінку для окремих команд за допомогою
відвідувати- варіант. Цей параметр має перевагу над наявним відвідуванням та ігноруванням
параметри та значення за замовчуванням:

[пейджер]
attend-cat = false

Ігнорувати глобальні команди, наприклад hg версія or hg допомога, ви повинні вказати їх у своєму
файл конфігурації користувача.

Щоб контролювати, чи пейджер взагалі використовується для окремої команди, ви можете використовувати
--pager= :

- використовуйте за потреби: `auto`.
- вимагати пейджер: `yes` або `on`.
- придушити пейджер: `no` або `off` (будь-яке нерозпізнане значення
теж буде працювати).

патчбомба
команду для надсилання наборів змін у вигляді (серії) електронних листів із виправленням

Серія починається зі вступу «[PATCH 0 of N]», який описує серію
в цілому.

Кожен електронний лист із виправленнями має рядок теми «[PATCH M of N] ...», використовуючи перший рядок
опис набору змін як текст теми. Повідомлення містить дві або три частини тіла:

· Опис набору змін.

· [Необов’язково] Результат запуску diffstat у патчі.

· Сам патч, створений hg експорт.

Кожне повідомлення посилається на перше в серії за допомогою In-Reply-To та References
заголовки, тож вони відображатимуться як послідовність у потоковій пошті та програмах читання новин, а також у пошті
архіви.

Щоб налаштувати інші параметри за замовчуванням, додайте такий розділ до файлу конфігурації:

[електронна пошта]
від = моє ім'я
кому = одержувач1, одержувач2, ...
cc = cc1, cc2, ...
bcc = bcc1, bcc2, ...
відповідь на = адреса1, адреса2, ...

Скористайтесь [патчбомба] як назву розділу конфігурації, якщо вам потрібно змінити глобальний [електронна пошта]
налаштування адреси.

Тоді ви можете використовувати hg e-mail команда, щоб надіслати ряд наборів змін як патчбомбу.

Ви також можете налаштувати параметр методу в розділі електронної пошти як sendmail
сумісний поштовий додаток або заповніть розділ [smtp], щоб розширення patchbomb могло
автоматично надсилати патчбомби безпосередньо з командного рядка. Перегляньте [email] і [smtp]
розділи в hgrc(5) для деталей.

За замовчуванням hg e-mail запропонує a До or CC заголовок, якщо ви не надаєте його через
конфігурації або командного рядка. Ви можете перевизначити це, щоб ніколи не запитувати, налаштувавши
пусте значення:

[електронна пошта]
cc =

Ви можете керувати стандартним включенням вступного повідомлення за допомогою patchbomb.intro
параметр конфігурації. Конфігурація завжди перезаписується прапорцями командного рядка, наприклад
--intro та --desc:

[патчбомба]
intro=auto # включає вступне повідомлення, якщо більше ніж 1 патч (за замовчуванням)
intro=never # ніколи не включати вступне повідомлення
intro=always # завжди включати вступне повідомлення

Ви можете налаштувати patchbomb так, щоб він завжди запитував підтвердження за допомогою налаштування patchbomb.confirm до істини.

Команди
e-mail
надсилати набори змін електронною поштою:

hg email [ОПЦІЯ]... [ЦІЛ.]...

За замовчуванням відмінності надсилаються у форматі, створеному hg експорт, по одному на повідомлення. The
серія починається зі вступу «[PATCH 0 of N]», який описує серію в цілому.

Кожен електронний лист із виправленнями має рядок теми «[PATCH M of N] ...», використовуючи перший рядок
опис набору змін як текст теми. Повідомлення складається з двох або трьох частин.
По-перше, опис набору змін.

З параметром -d/--diffstat, якщо встановлено програму diffstat, результат запуску
diffstat на патчі вставлено.

Нарешті, сам патч, створений hg експорт.

За допомогою опцій -d/--diffstat або --confirm вам буде запропоновано остаточний підсумок
усі повідомлення та попросив підтвердження перед надсиланням повідомлень.

За замовчуванням виправлення включено як текст у тіло електронної пошти для легкого перегляду. Використовуючи
Натомість параметр -a/--attach створить вкладення для патча. З -i/--inline an
буде створено вбудований вкладений файл. Ви можете включити виправлення як текст у тіло електронної пошти
і як звичайне або вбудоване вкладення, поєднавши -a/--attach або -i/--inline з
опція --body.

За допомогою -o/--outgoing електронні листи генеруватимуться для патчів, яких немає в пункті призначення
репозиторій (або лише ті, які є предками вказаних версій, якщо такі є
надано)

За допомогою -b/--bundle набори змін вибираються так само, як і для --outgoing, але одна електронна пошта містить
буде надіслано двійковий пакет Mercurial як вкладення. Використовувати patchbomb.bundletype
параметр конфігурації для керування типом комплекту, як у hg пакет --тип.

За допомогою -m/--mbox замість попереднього перегляду кожного повідомлення patchbomb у пейджері або надсилання
повідомлення безпосередньо, він створить файл поштової скриньки UNIX з електронними листами виправлень. Ця поштова скринька
файл можна попередньо переглянути за допомогою будь-якого поштового агента користувача, який підтримує файли UNIX mbox.

За допомогою -n/--test усі кроки виконуватимуться, але пошта не надсилатиметься. Вам буде запропоновано
адресу одержувача електронної пошти, тему та вступне повідомлення з описом патчів
вашої патчбомби. Потім, коли все буде зроблено, відобразяться повідомлення patchbomb. Якщо ПЕЙДЖЕР
встановлено змінну середовища, ваш пейджер запускатиметься один раз для кожного повідомлення patchbomb,
щоб ви могли переконатися, що все в порядку.

Якщо надсилання електронної пошти не вдасться, ви знайдете резервну копію вступного повідомлення серії
.hg/last-email.txt.

Стандартну поведінку цієї команди можна налаштувати за допомогою конфігурації. (Побачити hg допомога
патчбомба для деталей)

Приклади:

hg email -r 3000 # надсилати лише патч 3000
hg email -r 3000 -r 3001 # надіслати патчі 3000 і 3001
hg email -r 3000:3005 # надсилати патчі від 3000 до 3005
hg email 3000 # надіслати виправлення 3000 (застаріле)

hg email -o # надсилати всі латки, які не встановлені за замовчуванням
hg email -o DEST # надсилати всі патчі не в DEST
hg email -o -r 3000 # надсилати всі предки 3000 не за замовчуванням
hg email -o -r 3000 DEST # надіслати всіх предків 3000 не в DEST

hg email -b # надіслати пакет усіх патчів, які не встановлені за замовчуванням
hg email -b DEST # надіслати пакет усіх патчів не в DEST
hg email -b -r 3000 # пакет усіх предків 3000 не за замовчуванням
hg email -b -r 3000 DEST # група всіх предків 3000 не в DEST

hg email -o -m mbox && # створити файл mbox...
mutt -R -f mbox # ... і переглянути його за допомогою mutt
hg email -o -m mbox && # створити файл mbox ...
formail -s sendmail \ # ... і використовуйте formail для надсилання з mbox
-bm -t < mbox # ... за допомогою sendmail

Перш ніж використовувати цю команду, вам потрібно буде ввімкнути електронну пошту у вашому hgrc. Перегляньте [електронну адресу]
розділ в hgrc(5) для деталей.

варіанти:

-g, --git
використовуйте розширений формат git diff

-- звичайний
опустити заголовок патча hg

-о, -- вихідний
надіслати зміни, не знайдені в цільовому сховищі

-б, -- пучок
надсилати зміни, які не є цільовими, як двійковий пакет

--назва пакета
ім'я файлу вкладення комплекту (за замовчуванням: пакет)

-р,--rev
перегляд для надсилання

--сила
запускати, навіть якщо віддалений репозиторій не пов’язаний (з -b/--bundle)

--база
базовий набір змін для визначення замість призначення (з -b/--bundle)

-- вступ
надіслати вступний електронний лист для одного патча

-- тіло надсилати патчі як вбудований текст повідомлення (за замовчуванням)

-а, --прикріпити
надсилайте патчі як вкладення

-я, --в лінію
надсилати патчі як вкладені файли

--прихована копія
адреси електронної пошти одержувачів сліпих копій

-c,--cc
електронні адреси одержувачів копії

--підтвердити
просити підтвердження перед відправкою

-d, --diffstat
додати вихід diffstat до повідомлень

--дата
використовуйте вказану дату як дату надсилання

--дез
використовуйте наведений файл як опис серії

-f,--від
адреса електронної пошти відправника

-n, --тест
надрукувати повідомлення, які будуть надіслані

-м,--mbox
писати повідомлення у файл mbox замість того, щоб надсилати їх

--відповідати на
адреси електронної пошти, на які слід надсилати відповіді

-так,--предмет
тема першого повідомлення (вступ або один патч)

--у-відповідь-на
ідентифікатор повідомлення, на яке потрібно відповісти

-- прапор
прапорці для додавання в префікси теми

-t,--до
електронні адреси одержувачів

-е,--ssh
вкажіть команду ssh для використання

--remotecmd
вкажіть команду hg для запуску на віддаленому боці

--небезпечно
не перевіряти сертифікат сервера (ігноруючи конфігурацію web.cacerts)

Позначений [+] параметр можна вказати кілька разів

чистка
команда для видалення невідстежуваних файлів з робочого каталогу

Команди
чистка
видаляє файли, які не відстежуються Mercurial:

hg purge [ОПЦІЯ]... [DIR]...

Видалити файли, невідомі Mercurial. Це корисно для тестування локальних і незафіксованих змін
в іншому чистому дереві вихідних кодів.

Це означає, що очищення за замовчуванням видалить наступне:

· Невідомі файли: файли, позначені "?" за hg статус

· Порожні каталоги: фактично Mercurial ігнорує каталоги, якщо вони не містять файлів під
управління джерельним контролем

Але це залишиться недоторканим:

· Модифіковані та немодифіковані відстежувані файли

· Ігноровані файли (якщо не вказано --all)

· Нові файли, додані до сховища (з hg додавати)

Параметри --files і --dirs можна використовувати для спрямування очищення лише на видалення файлів
каталогів або обох. Якщо не вказано жоден варіант, обидва будуть видалені.

Якщо каталоги вказані в командному рядку, доступні лише файли в цих каталогах
розглянуто.

Будьте обережні з очищенням, оскільки ви можете безповоротно видалити деякі файли, які забули додати
сховище. Якщо ви бажаєте лише надрукувати список файлів, які ця програма зробить
видалити, скористайтеся опцією --print.

варіанти:

-а, --abort-on-err
перервати, якщо сталася помилка

--все також очистити ігноровані файли

--реж очистити порожні каталоги

--файли
очистити файли

-p, --друк
друкувати назви файлів замість їх видалення

-0, --друк0
завершуйте імена файлів NUL, для використання з xargs (передбачається -p/--print)

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

псевдоніми: чистий

ребаза
команда для переміщення наборів ревізій до іншого предка

Це розширення дозволяє перебазувати набори змін у наявному сховищі Mercurial.

Для отримання додаткової інформації: https://mercurial-scm.org/wiki/RebaseExtension

Команди
ребаза
перемістити набір змін (і нащадків) до іншої гілки:

hg rebase [-s REV | -b REV] [-d REV] [ПАРАМЕТР]

Rebase використовує повторне злиття для пересадки наборів змін з однієї частини історії (джерело)
на інший (пункт призначення). Це може бути корисним для лінеаризації місцевий зміни віднос
до основного дерева розробки.

Опубліковані коміти не можна перебазувати (див hg допомога фаз). Щоб скопіювати коміти, див hg допомога
трансплантат.

Якщо ви не вкажете цільовий набір змін (-d/--дест), rebase використовує поточну гілку
чайові як пункт призначення. (Цільовий набір змін не змінюється шляхом перебазування, а створюється новий
набори змін додаються як його нащадки.)

Ось способи вибору наборів змін:

1. Виділіть їх явно за допомогою --rev.

2. використання --джерело щоб вибрати кореневий набір змін і включити всіх його нащадків.

3. використання --база вибрати набір змін; rebase знайде предків та їхніх нащадків
які також не є предками пункту призначення.

4. Якщо не вказано жодного з --rev, джерелоабо --база, використовуватиме rebase --база . as
вище.

Rebase знищить оригінальні набори змін, якщо ви не використовуєте -- тримати. Це також зворушить вас
закладки (навіть якщо є).

Деякі набори змін можуть бути видалені, якщо вони не вносять зміни (наприклад, злиття з
відділення призначення).

на відміну від злиття, rebase нічого не робитиме, якщо ви перебуваєте на кінчику гілки з назвою гілки з
дві голови. Вам потрібно буде чітко вказати джерело та/або призначення.

Якщо перебазування переривається для вирішення конфлікту вручну, його можна продовжити
--continue/-c або перервано за допомогою --abort/-a.

Приклади:

· перемістити «локальні зміни» (поточний фікс назад до точки розгалуження) до поточної підказки гілки
після тяги:

hg rebase

· перемістити один набір змін до стабільної гілки:

hg rebase -r 5f493448 -d стабільний

· з’єднання коміту та всіх його нащадків в іншу частину історії:

hg rebase --source c0c3 --dest 4cf9

· перебазувати все на гілці, позначеній закладкою, на гілку за замовчуванням:

hg rebase --base myfeature --dest за замовчуванням

· згорнути послідовність змін в один коміт:

hg rebase --collapse -r 1520:1525 -d .

· перемістити гілку з назвою, зберігаючи її назву:

hg rebase -r "branch(featureX)" -d 1.3 --keepbranches

Повертає 0 у разі успіху, 1, якщо нічого не потрібно перебазувати або є невирішені конфлікти.

варіанти:

-так,--джерело
перебазувати вказаний набір змін і нащадків

-б,--база
перебазувати все з точки розгалуження зазначеного набору змін

-р,--rev
перебазувати ці редакції

-d,--прим
перебазувати на вказаний набір змін

--згорнути
згорнути перебазовані набори змін

-м,--повідомлення
використовувати текст як повідомлення згортання фіксації

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-л,--файл журналу
читати повідомлення згортання фіксації з файлу

-к, -- тримати
зберегти оригінальні набори змін

--зберігати гілки
зберегти оригінальні назви гілок

-Д, --від’єднати
(НЕПРЕДПОВІДАЄТЬСЯ)

-я, --інтерактивні
(НЕПРЕДПОВІДАЄТЬСЯ)

-t,--інструмент
вказати інструмент об’єднання

-c, --продовжити
продовжити перерване перебазування

-а, --перервати
перервати перерване перебазування

-- стиль
відображати за допомогою файлу карти шаблону (ЗАСТАРЕЛО)

-Т,--шаблон
дисплей із шаблоном

Позначений [+] параметр можна вказати кілька разів

запис
команди для інтерактивного вибору змін для commit/qrefresh

Команди
qrecord
інтерактивно записати новий патч:

hg qrecord [ПАРАМЕТР]... ПАТЧ [ФАЙЛ]...

Читати hg допомога qnew & hg допомога запис для отримання додаткової інформації та використання.

запис
інтерактивно вибрати зміни для внесення:

hg запис [ПАРАМЕТР]... [ФАЙЛ]...

Якщо список файлів пропущено, усі зміни повідомляється hg статус будуть кандидатами на
запис

Читати hg допомога дати для списку форматів, дійсних для -d/--date.

Вам буде запропоновано вказати, чи записувати зміни до кожного зміненого файлу та для файлів
з кількома змінами, для використання кожної зміни. Для кожного запиту наведені відповіді
можливо:

у - записати цю зміну
n - пропустити цю зміну
e - редагувати цю зміну вручну

s - пропустити решту змін у цьому файлі
f - запис решти змін у цей файл

d - готово, пропустити решту змін і файлів
a - записати всі зміни до всіх файлів, що залишилися
q - вихід, запис без змін

? - відображення довідки

Ця команда недоступна під час здійснення злиття.

варіанти:

-A, --addremove
перед фіксацією позначте нові/відсутні файли як додані/видалені

--ближне відділення
позначте головку гілки як закриту

--виправити
внести зміни до батьківського каталогу робочого каталогу

-так, -- секрет
використовуйте секретну фазу для фіксації

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

-м,--повідомлення
використовувати текст як повідомлення про фіксацію

-л,--файл журналу
прочитати повідомлення про фіксацію з файлу

-d,--дата
записати вказану дату як дату фіксації

-у,--користувач
записати вказаного користувача як комітера

-S, --підтримка
повертатися в підрепозиторії

-w, --ігнорувати-все-пробіл
ігноруйте пробіл під час порівняння рядків

-б, --ignore-space-change
ігнорувати зміни в кількості пробілів

-Б, --ignore-blank-lines
ігнорувати зміни, усі рядки яких порожні

Позначений [+] параметр можна вказати кілька разів

повторне зв’язок
відтворює жорсткі зв'язки між клонами репозиторію

Команди
повторне зв’язок
відтворити жорсткі посилання між двома сховищами:

hg relink [ПОХОДЖЕННЯ]

Коли репозиторії клонуються локально, їх файли даних будуть жорстко пов’язані, щоб вони
використовувати лише простір одного сховища.

На жаль, подальше залучення до будь-якого репозиторію порушить жорсткі посилання для будь-яких файлів
торкнулися нові набори змін, навіть якщо обидва репозиторії в кінцевому підсумку витягають ті самі зміни.

Подібним чином, передаючи --rev до "hg clone" не вдасться використовувати жорсткі посилання, повертаючись до
повна копія вихідного сховища.

Ця команда дозволяє відтворити ці жорсткі посилання та відновити цей втрачений простір.

Це сховище буде повторно зв’язано, щоб спільно використовувати простір із ORIGIN, який має бути на тому самому місці
локальний диск. Якщо ORIGIN опущено, шукається «default-relink», а потім «default» у [шляхи].

Не намагайтеся виконувати операції читання в цьому сховищі під час виконання команди. (Обидва
репозиторії будуть заблоковані від запису.)

схеми
розширити схеми з ярликами на рої репозиторіїв

Це розширення дозволяє вказувати ярлики для батьківських URL-адрес із великою кількістю сховищ
діяти як схема, наприклад:

[схеми]
py = http://code.python.org/hg/

Після цього ви можете використовувати його як:

hg клон py://trunk/

Крім того, є підтримка деяких більш складних схем, наприклад, які використовує Google
код:

[схеми]
gcode = http://{1}.googlecode.com/hg/

Синтаксис взято з шаблонів Mercurial, і ви маєте необмежену кількість змінних,
починаючи з 1 {} і продовжуючи с 2 {}, 3 {} і так далі. Ці змінні отримають
частини наданої URL-адреси, розділені на /. Усе, що не зазначено як {part} буде просто додано
до URL-адреси.

Для зручності розширення додає такі схеми за замовчуванням:

[схеми]
py = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://[захищено електронною поштою]/
gcode = https://{1}.googlecode.com/hg/
піч = https://{1}.kilnhg.com/Repo/

Ви можете замінити попередньо визначену схему, визначивши нову схему з такою ж назвою.

частка
спільна історія між кількома робочими каталогами

автоматичний Об'єднаний зберігання та цінності клони
Коли це розширення активне, hg клон можна налаштувати на автоматичний спільний доступ/пул
зберігання в кількох клонах. Цей режим ефективно перетворює hg клон до hg клон + hg
частка. Перевагою використання цього режиму є автоматичне керування шляхами зберігання та
інтелектуальне об'єднання пов'язаних сховищ.

Наступні акції. параметри конфігурації впливають на цю функцію:

share.pool

Шлях файлової системи, де зберігатимуться дані спільного сховища. Коли визначено, hg клон
автоматично використовуватиме сховище спільного сховища замість створення внутрішнього сховища
кожен клон.

share.poolnaming

Як імена каталогів у share.pool побудовані.

"ідентичність" означає, що ім'я походить від першого набору змін у сховищі. в
у цьому режимі різні віддалені пристрої спільно використовують пам’ять, якщо їхній кореневий/початковий набір змін є таким
однакові. У цьому режимі локальне спільне сховище є сукупністю всіх
виявлені віддалені сховища.

«віддалений» означає, що ім’я походить від шляху або URL-адреси вихідного сховища. в
у цьому режимі сховище надається спільно, лише якщо шлях або URL-адреса, запитані в hg клон
команда точно відповідає репозиторію, який був клонований раніше.

Типовим режимом іменування є «ідентифікація».

Команди
частка
створити нове спільне сховище:

hg частка [-U] [-B] ДЖЕРЕЛО [ЦІЛЬ]

Ініціалізуйте нове сховище та робочий каталог, який ділиться своєю історією (і за бажанням
закладки) з іншим репозиторієм.

Зауважте, що використання відкату або розширень, які знищують/змінюють історію (mq, rebase тощо), може
викликають значну плутанину зі спільними клонами. Зокрема, якщо ділилися двоє
обидва клони оновлюються до одного набору змін, і один з них знищує його
набір змін із відкатом, інший клон раптово перестане працювати: усі операції
не вийде з "перервати: робочий каталог має невідомий батьків". Єдиний відомий
обхідним шляхом є використання debugsetparents для зламаного клону, щоб скинути його до набору змін
що все ще існує.

варіанти:

-У, --noupdate
не створювати робочий каталог

-Б, -- закладки
також поділитися закладками

скасувати спільний доступ
перетворити спільне сховище на звичайне:

hg скасувати спільний доступ

Скопіюйте дані магазину в репо та видаліть дані спільного шляху.

полиці
зберегти та відновити зміни в робочому каталозі

Команда "hg shelve" зберігає зміни, зроблені в робочому каталозі, і скасовує їх
зміни, скидання робочого каталогу до чистого стану.

Пізніше команда «hg unshelve» відновлює зміни, збережені «hg shelve». Зміни можуть
можна відновити навіть після оновлення до іншого батьківського елемента, у такому випадку відбувається злиття Mercurial
техніка за потреби вирішить будь-які конфлікти.

Одночасно можна мати більше ніж одну відкладену зміну; кожна відкладена зміна має a
чітке ім'я. Щоб отримати докладнішу інформацію, перегляньте довідку для "hg shelve".

Команди
полиці
зберегти та відкласти зміни з робочого каталогу:

hg полиця [ВАРІАНТ]... [ФАЙЛ]...

Shelving приймає файли, які "hg status" повідомляє як нечисті, зберігає зміни в a
bundle (відкладена зміна) і повертає файли таким чином, щоб їхній стан був робочим
каталог стає чистим.

Щоб відновити ці зміни в робочому каталозі, використовуючи "hg unshelve"; це спрацює
навіть якщо ви перемкнетеся на інший комміт.

Якщо файли не вказано, «hg shelve» зберігає всі нечисті файли. Якщо конкретні файли або
каталоги мають назви, лише зміни в цих файлах залишаються на полиці.

Кожна відкладена зміна має назву, яка полегшує її пошук пізніше. Назва стелажа
змінити значення за замовчуванням на основі активної закладки або, якщо активної закладки немає,
поточна названа гілка. Щоб вказати інше ім'я, використовуйте --ім'я.

Щоб переглянути список наявних відкладених змін, скористайтеся -- список варіант. Для кожної відкладеної зміни,
буде надруковано його ім'я, вік і опис; використовувати --патч or --стат для більш докладної інформації.

Щоб видалити певні відкладені зміни, використовуйте --видалити. Щоб видалити всі відкладені зміни, використовуйте
--прибирати.

варіанти:

-A, --addremove
позначати нові/відсутні файли як додані/видалені перед розміщенням на полиці

-у, --невідомо
зберігати невідомі файли на полиці

--прибирати
видалити всі відкладені зміни

--дата
полиця із зазначеною датою фіксації

-d, --видалити
видалити названі відкладені зміни

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-л, -- список
список поточних полиць

-м,--повідомлення
використовувати текст як повідомлення на полиці

-n,--ім'я
використовуйте дане ім'я для відкладеного коміту

-p, --патч
показати патч

-я, --інтерактивні
інтерактивний режим, працює лише під час створення полиці

--стат вивести підсумок змін у стилі diffstat

-я,--включати
включити назви, що відповідають заданим шаблонам

-X,--виключити
виключити імена, що відповідають заданим шаблонам

Позначений [+] параметр можна вказати кілька разів

розкладати
відновити відкладену зміну до робочого каталогу:

hg unshelve [ПОЛИЦЯ]

Ця команда приймає необов’язкову назву відкладеної зміни для відновлення. Якщо нічого не надано,
використовується остання відкладена зміна.

Якщо відкладену зміну застосовано успішно, пакет, який містить відкладену зміну, змінюється
переміщується до розташування резервної копії (.hg/shelve-backup).

Оскільки ви можете відновити відкладену зміну поверх довільного коміту, це можливо
видалення з полиці призведе до конфлікту між вашими змінами та вашими комітами
розкладання на. Якщо це станеться, ви повинні вирішити конфлікт, а потім використовувати --продовжити до
завершити операцію видалення з полиці. (Пакет не буде переміщено, доки ви не встигнете
завершити розкладання.)

(Альтернативно, ви можете використовувати --перервати відмовитися від неподалік, що спричиняє конфлікт. Це
повертає незахищені зміни та залишає пакет на місці.)

Після успішного видалення з полиці відкладені зміни зберігаються в каталозі резервного копіювання. Тільки
зберігаються N останніх резервних копій. N за умовчанням дорівнює 10, але його можна змінити за допомогою
shelve.maxbackups варіант налаштування.

Мітка часу в секундах використовується для визначення порядку резервного копіювання. Більш ніж maxbackups резервні копії є
зберігається, якщо та сама мітка часу заважає визначити їх точний порядок, для безпеки.

варіанти:

-а, --перервати
перервати незавершену операцію видалення з полиці

-c, --продовжити
продовжити незавершену операцію розкладки

-к, -- тримати
зберігати полицю після розкладання

-t,--інструмент
вказати інструмент об’єднання

--дата
встановити дату для тимчасових комітів (ЗАСТАРЕЛО)

роздягнутися
видалити набори змін та їх нащадків з історії

Це розширення дозволяє видаляти набори змін і всі їхні нащадки з
сховище. Додаткову інформацію дивіться в довідці команд.

Команди
роздягнутися
видалити набори змін і всіх їхніх нащадків зі сховища:

hg strip [-k] [-f] [-B закладка] [-r] REV...

Команда strip видаляє вказані набори змін і всіх їхніх нащадків. Якщо
у робочому каталозі є незафіксовані зміни, операцію буде перервано, якщо не буде використано --force
надається прапорець, у цьому випадку зміни буде відхилено.

Якщо батьківський каталог робочого каталогу буде видалено, робочий каталог буде видалено
автоматично оновлюється до останнього доступного предка видаленого батька
після завершення операції.

Будь-які видалені набори змін зберігаються в .hg/strip-backup як пучок (див hg допомога пакет та
hg допомога роз’єднати). Їх можна відновити бігом hg роз’єднати .hg/strip-backup/BUNDLE,
де BUNDLE — файл пакету, створений смугою. Зверніть увагу, що номери локальних версій
загалом буде іншим після відновлення.

Використовуйте параметр --no-backup, щоб скасувати пакет резервного копіювання після завершення операції.

Strip не є операцією перезапису історії, і її можна використовувати для загальнодоступних наборів змін
фаза. Але якщо вилучені набори змін було передано до віддаленого сховища, ви це зробите
ймовірно, витягніть їх знову.

У разі успіху повертайте 0.

варіанти:

-р,--rev
видалити вказану версію (необов'язково, можна вказати версії без цієї опції)

-f, --сила
примусове видалення наборів змін, відхилення незафіксованих змін (без резервного копіювання)

--без резервного копіювання
немає резервних копій

--без резервного копіювання
немає резервних копій (ЗАСТАРЕЛО)

-n ігнорується (ЗАСТАРЕЛО)

-к, -- тримати
не змінюйте робочий каталог під час видалення

-Б,-- закладка
видалити обороти, доступні лише з даної закладки

Позначений [+] параметр можна вказати кілька разів

пересадка
команда для пересадки наборів змін з іншої гілки

Це розширення дозволяє вам переносити зміни до іншої батьківської версії, можливо, у
інший репозиторій. Пересадка виконується за допомогою патчів «різниці».

Трансплантовані патчі записуються в .hg/transplant/transplants як карта з набору змін
хеш до свого хешу у вихідному сховищі.

Команди
пересадка
пересадити набори змін з іншої гілки:

hg пересадка [-s РЕПО] [-b ГІЛКА [-a]] [-p REV] [-m REV] [REV]...

Вибрані набори змін буде застосовано поверх поточного робочого каталогу з журналом
вихідного набору змін. Набори змін копіюються і, таким чином, з’являться двічі в
історії з різними ідентичністями.

Розгляньте можливість використання команди graft, якщо все знаходиться в одному сховищі – вона використовуватиме
зливається і зазвичай дає кращий результат. Використовуйте розширення rebase, якщо набори змін
не опубліковані, і ви хочете їх перемістити, а не копіювати.

Якщо вказано --log, до повідомлень журналу буде додано коментар у формі:

(пересаджено з CHANGESETHASH)

Ви можете переписати повідомлення журналу змін за допомогою параметра --filter. Його аргументація буде
викликається з поточним повідомленням журналу змін як $1 і патчем як $2.

--source/-s вказує інше сховище для вибору наборів змін, як ніби це
тимчасово було вилучено. Якщо вказано --branch/-b, ці версії використовуватимуться як
голови, вирішуючи, які набори змін трансплантувати, так само, якби мали лише ці редакції
витягнуто. Якщо вказано --all/-a, усі версії до заголовків, указаних у
--гілка буде пересаджена.

приклад:

· перенести всі зміни до REV поверх поточної версії:

hg пересадка --розгалуження REV --все

За бажанням ви можете позначити вибрані трансплантовані набори змін як об’єднані набори змін. Ви не будете
буде запропоновано пересадити будь-яких предків об’єднаного пересадження, і ви зможете злити
замість того, щоб пересаджувати їх.

Об’єднані набори змін можна трансплантувати безпосередньо, вказавши відповідний батьківський набір змін
покликання hg пересадка --батька.

Якщо злиття або перегляди не надаються, hg пересадка запустить інтерактивний набір змін
браузера.

Якщо програма з набором змін виходить з ладу, ви можете виправити злиття вручну, а потім продовжити з того місця, де ви
припинив виклик hg пересадка --продовжити/-c.

варіанти:

-так,--джерело
трансплантувати набори змін із REPO

-б,-філія
використовувати цей вихідний набір змін як заголовок

-а, --все
витягнути всі набори змін до версії --branch

-p,-- чорнослив
пропустити REV

-м,-- об'єднати
злиття на REV

--батька
батьків вибрати при пересадці злиття

-е, --редагувати
викликати редактор для повідомлень про фіксацію

-- журнал додати інформацію про трансплантацію до повідомлення журналу

-c, --продовжити
продовжити останній сеанс трансплантації після усунення конфліктів

--фільтр
фільтрувати набори змін за допомогою команди

Позначений [+] параметр можна вказати кілька разів

win32mbcs
дозволяють використовувати шляхи MBCS з проблемним кодуванням

Деякі кодування MBCS не підходять для деяких операцій шляху (наприклад, розділення шляху, case
перетворення тощо) із закодованими байтами. Ми називаємо таке кодування (тобто shift_jis і
big5) як "проблемне кодування". Це розширення можна використовувати для вирішення проблеми з ними
кодування шляхом обгортання деяких функцій для перетворення в рядок Unicode перед операцією шляху.

Це розширення корисне для:

· Японські користувачі Windows, які використовують кодування shift_jis.

· Китайські користувачі Windows, які використовують кодування big5.

· Усі користувачі, які використовують репозиторій з одним із проблемних кодувань без урахування регістру
файлова система.

Це розширення не потрібне для:

· Будь-який користувач, який використовує лише символи ASCII у шляху.

· Будь-який користувач, який не використовує жодне з проблемних кодувань.

Зауважте, що є деякі обмеження щодо використання цього розширення:

· Ви повинні використовувати єдине кодування в одному репозиторії.

· Якщо шлях до сховища закінчується на 0x5c, .hg/hgrc неможливо прочитати.

· win32mbcs не сумісний із розширенням fixutf8.

За замовчуванням win32mbcs використовує encoding.encoding, визначений Mercurial. Ви можете вказати
кодування за параметром конфігурації:

[win32mbc]
кодування = sjis

Це корисно для користувачів, які хочуть зафіксувати повідомлення журналу UTF-8.

win32text
виконувати автоматичне перетворення нового рядка (ЗАСТАРЕЛО)

Застаріле: розширення win32text вимагає, щоб кожен користувач налаштував розширення
знову і знову для кожного клону, оскільки конфігурація не копіюється під час клонування.

Тому ми зробили еол як альтернатива. The еол використовує контрольовану версію
файл для його конфігурації, тому кожен клон використовуватиме правильні налаштування з
початок.

Щоб виконати автоматичне перетворення нового рядка, використовуйте:

[розширення]
win32text =
[кодувати]
** = cleverencode:
# або ** = macencode:

[розшифрувати]
** = cleverdecode:
# або ** = macdecode:

Якщо ви не виконуєте перетворення, щоб переконатися, що ви випадково не зафіксували CRLF/CR:

[гачки]
pretxncommit.crlf = python:hgext.win32text.forbidcrlf
# або pretxncommit.cr = python:hgext.win32text.forbidcr

Щоб зробити таку ж перевірку на сервері, щоб запобігти надсиланню або витягуванню CRLF/CR:

[гачки]
pretxnchangegroup.crlf = python:hgext.win32text.forbidcrlf
# або pretxnchangegroup.cr = python:hgext.win32text.forbidcr

нульовий конф
виявляти та рекламувати репозиторії в локальній мережі

Розширення zeroconf буде рекламувати hg служити екземпляри через DNS-SD, щоб вони могли бути
виявлено за допомогою hg стежки команду, не знаючи адреси сервера.

Щоб дозволити іншим людям відкривати ваше сховище за допомогою run hg служити у вашому сховищі:

$ cd тест
$ hg служити

Ви можете знайти репозиторії з підтримкою Zeroconf, запустивши hg стежки:

Шляхи $ hg
zc-тест = http://example.com:8000/тест

Використовуйте hg онлайн за допомогою сервісів onworks.net