Mercurial система контроля версий

Mercurial
Тип	распределённая система управления версиями[d]
Разработчик	Matt Mackall
Написана на	Python , Си и Rust
Операционная система	кроссплатформенность
Первый выпуск	19 апреля2005[1]
Последняя версия	5.2 ( 5 ноября2019 ) [2]
Лицензия	GNU GPL 2
Сайт	mercurial-scm.org
Медиафайлы на Викискладе

Mercurial (с англ. — «ртутный, подвижный»), он же Hg (от обозначения химического элемента ртути) — кроссплатформенная распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода. В первую очередь она является консольной программой.

Mercurial появился в результате того же конфликта, что привёл к созданию Git. Автором новой системы стал Мэт Мэкол (Matt Mackall).

Содержание

Описание [ править | править код ]

Система Mercurial написана на Python, хотя чувствительные к производительности части (например, своя реализация diff) выполнены в качестве модулей-расширений на C [3] . Mercurial первоначально была написана для Linux, позже портирована под Windows, Mac OS X и большинство Unix-систем. Репозитории Mercurial управляются при помощи утилиты командной строки hg , но есть и GUI-интерфейсы.

Наряду с традиционными возможностями систем контроля версий, Mercurial поддерживает полностью децентрализованную работу (отсутствует понятие основного хранилища кода), ветвление (возможно вести несколько веток одного проекта и копировать изменения между ветками), слияние репозиториев (чем и достигается «распределённость» работы). Поддерживается обмен данными между репозиториями через HTTP/HTTPS, SSH и вручную при помощи упакованных наборов изменений.

Утилита hg обладает компактным интерфейсом, и Mercurial считается более простой в освоении системой, чем, например, git [4] .

Концепции [ править | править код ]

Рабочий процесс [ править | править код ]

Mercurial является распределённой (децентрализованной) системой контроля версий. Это означает, что рабочий процесс, как правило, выглядит следующим образом:

1. На личном компьютере создаётся новый репозиторий (путём клонирования существующего репозитория, создания нового и т. п.);
2. В рабочем каталоге данного репозитория изменяются/добавляются/удаляются файлы;
3. Выполняется фиксация (commit) изменений в данный репозиторий (то есть в локальный репозиторий на личном компьютере);
4. Шаги 2 и 3 повторяются столько раз, сколько необходимо;
5. При необходимости производится синхронизация изменений с другими репозиториями: забираются (pull) чужие наборы изменений и/или отдаются (push) собственные.

То есть вся повседневная работа происходит в локальном репозитории, а когда возникает необходимость, производится отправка результатов своей работы в один или несколько других репозиториев. Количество шагов при работе с отдалёнными репозиториями можно сократить, если настроить Mercurial на автоматическую отправку изменений в другие репозитории при выполнении фиксации [5] .

Консольная программа [ править | править код ]

Консольная программа реализована таким образом, что название любой команды можно сокращать до тех пор, пока её имя остаётся однозначным. Плюс некоторые команды имеют псевдонимы. Например, вместо hg commit можно написать hg commi , hg comm или hg com , но если написать hg c , то Mercurial откажется выполнять эту команду, сообщив, что «команда 'c' неоднозначна» и приведя список команд, которые попадают под это сокращение. Использовать hg co в качестве сокращения для hg commit нельзя, так как это псевдоним для команды hg update, однако доступно сокращение hg ci .

Логическая структура наборов изменений [ править | править код ]

При вызове команды hg commit выполняется фиксация изменений. При этом программа сохраняет в репозиторий набор изменений( changeset или ревизия). Физически происходят те же изменения, что и у вас, но сохраняются они в служебные файлы, а не в копии (подробнее в За кулисами).

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

Узнать идентификаторы родительских наборов изменений, с которыми связаны зафиксированные наборы изменений можно с помощью команды hg log —debug . У каждого набора изменений будет два родителя (благодаря чему возможно ветвление внутри репозитория, см. hg -v help branch ). Значение «-1:0000000000000000000000000000000000000000» означает отсутствие родителя. Например, у самого первого набора изменений в репозитории данное значение будет проставлено для обоих родителей, а у последующих данное значение будет проставлено для второго родителя (если для них в репозитории не использовалось ветвление), а для первого родителя будет проставлен идентификатор от предыдущего набора изменений.

Рабочий каталог также полезно представлять в виде такого же набора изменений (который пока не зафиксирован, но, возможно, вскоре также будет зафиксирован). Рабочий каталог также связан с одним или двумя родительскими наборами изменений, узнать о которых можно с помощью команды hg parents . После фиксации изменений данные родители станут родителями для нового (уже зафиксированного) набора изменений.

Идентификация наборов изменений [ править | править код ]

Ревизии распознают по следующим признакам [6] :

• Номеру ревизии;
• Идентификатору набора изменений;
• Меткам (Тег);
• Имени ветки.

Номер ревизии [ править | править код ]

Номер ревизии представляет собой целое число, отражающее порядок, в котором наборы изменений были добавлены в хранилище. Номер ревизии начинается с нуля, присваивается набору изменений автоматически и может использоваться для идентификации наборов изменений. Номер ревизии для одного и того же набора изменений может различаться в каждом из клонов хранилища. В выводе команды hg log номер ревизии можно увидеть перед двоеточием (например, «4:e1be1898f374»).

Идентификатор набора изменений [ править | править код ]

Идентификатор набора изменений представляет собой SHA-1 хеш, состоящий из цифр и букв «a, b, c, d, e, f», например, «e1be1898f3747386c41c8a5c5776e87373f6d3d3». Идентификатор набора изменений присваивается каждому набору изменений автоматически, вычисляется на основе содержимого этого набора изменений, поэтому соответствует одному и тому же набору изменений во всех репозиториях. Вероятность коллизии, когда для двух разных наборов изменений будет сгенерирован один и тот же SHA-1 хеш, крайне мала.

Mercurial не требует ввода полной строки идентификатора при использовании его в командах, ему достаточно лишь той его начальной части, которая однозначно идентифицирует требуемый набор изменений (в противном случае, Mercurial сообщит о неоднозначности). В выводе команды hg log идентификатор набора изменений можно увидеть после двоеточия (например, «4:e1be1898f374»). Без параметра —debug команда hg log выводит не полный, а сокращённый (из 12 символов) идентификатор набора изменений.

Метки [ править | править код ]

В дополнение к номеру ревизии и идентификатору набора изменений, Mercurial предоставляет возможность присваивать каждому набору изменений одно или более произвольных символических имён, называемых метками (или тегами). Присваиваются метки с помощью команды hg tag , а посмотреть все добавленные метки можно с помощью команды hg tags . Имя метки не может содержать некоторые символы (например ": "), о чём, в случае необходимости, Mercurial сообщит при выполнении команды hg tag .

Везде, где в командах можно указать идентификатор набора изменений, можно подставить имя метки.

Название ветки [ править | править код ]

Каждая ветка имеет собственное название. Оно указывается при создании ветки и больше никогда не изменяется.

Неочевидные моменты [ править | править код ]

• Если в качестве идентификатора ревизии какой-либо команде передано число, то Mercurial будет считать, что ему передан номер ревизии и будет выполнять проверку на неоднозначность с сокращённым идентификатором наборов изменений только в том случае, если отсутствует набор изменений с указанным номером ревизии. Например, если в репозитории существует один набор изменений с номером ревизии «6» и другой набор изменений с идентификатором «647362ac74d76124267215af1a3f94aa9707dfdf» (начинается с цифры «6»), то команда hg log -r 6 выдаст информацию о первом наборе изменений, не сообщив о неоднозначности. Поэтому, если глобальный идентификатор начинается с цифры, полезно всегда сокращать его лишь до тех пор, пока в нём не встретится буква. Данное поведение наблюдалось в версии 2.2.1 под Mac OS X 10.7.4.
• Если создать метку с именем, например, «5», в то время как в репозитории существует (или появится в будущем) набор изменений с номеров ревизии «5», то Mercurial будет искать в первую очередь наборы изменений по номеру ревизии. Но если создать метку с именем, например, «e1be», в то время как в репозитории существует (или появится в будущем) набор изменений с идентификатором наборов изменений, начинающимся с «e1be», то Mercurial будет искать наборы изменений в первую очередь уже по меткам. Притом, в обоих случаях о неоднозначности сообщено не будет. По этой причине не рекомендуется создавать метки, состоящие только из цифр и/или букв «a, b, c, d, e, f». Данное поведение наблюдалось в версии 2.2.1 под Mac OS X 10.7.4.
• Нельзя добавить в репозиторий пустую папку (для решения этой проблемы можно положить в папку любой файл, например, readme.txt). Такое поведение связано с тем, что Mercurial не отслеживает папки, а только файлы [7] . Поведение реализовано осознанно для упрощения системы и пока что изменений не планируется [7] .

Отличительные особенности [ править | править код ]

В отличие от git Mercurial предполагает более строгую модель работы, наиболее заметными аспектами которой являются [8] [9] :

• «Честные ветки» — любая ветвь может быть отслежена с самого начала;
• Хранение изменений в виде revlog (в противовес blob у git);
• Возможно слияние лишь двух ветвей за один проход (git допускает множественное слияние);
• Невозможность отмены коммита — вместо этого следует послать исправляющий коммит, который наложится поверх неудачного;
• Более строгий контроль различий по умолчанию следует единому стандарту, исключающему конфликты различных версий и клиентов.

Дополнительные средства [ править | править код ]

В комплекте с Mercurial поставляются CGI-сценарии для предоставления веб-интерфейса к репозиториям [10] .

Есть графическая оболочка TortoiseHg [11] , работающая как под Windows (с интеграцией в Explorer), так и под Linux (в виде отдельного приложения [12] или с интеграцией в Gnome/Nautilus [13] ). Существует разрабатываемый консольный клиент hgtui для Linux и Windows (с использованием cygwin).

Atlassian также продвигает свой клиент SourceTree, предоставляющий доступ как к hg, так и к svn и git.

Ряд сред разработки имеет возможности для работы с Mercurial, например Microsoft Visual Studio [14] [15] , IntelliJ >[16] [17] [18] , Eclipse [19] , Qt Creator (начиная с версии 2.0) [20] , P >[21] , NetBeans [22] . Возможна работа с Mercurial из Emacs c помощью входящего в Emacs универсального пакета VC.

Экспериментальная поддержка Mercurial есть в системе Trac [23] . Проект Redmine [24] также поддерживает репозитории Mercurial.

При помощи утилиты Tailor [25] или расширения convert [26] поддерживается конвертирование [27] репозиториев других систем контроля версий, включая CVS, Subversion, Git, Perforce, Darcs, GNU Arch, Bazaar.

Проекты, использующие Mercurial [ править | править код ]

Значительное количество проектов по разработке свободного программного обеспечения использует Mercurial в качестве основной системы контроля версий [28] . В их числе:

Поддерживаются Mercurial-зеркала основных репозиториев других проектов [33] , например, GCC, Vim, GNU Emacs и Linux.

Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface.

How you can benefit from Mercurial

1. It is fast and powerful

Mercurial efficiently handles projects of any size and kind . Every clone contains the whole project history, so most actions are local, fast and convenient. Mercurial supports a multitude of workflows and you can easily enhance its functionality with extensions.

You can follow our simple guide to learn how to revision your documents with Mercurial, or just use the quick start to get going instantly. A short overview of Mercurial’s decentralized model is also available.

And it just works

Mercurial strives to deliver on each of its promises. Most tasks simply work on the first try and without requiring arcane knowledge.

Есть три системы контроля версий (svn, mercurial, git).

Дмитрий Афанасьев о mercurial

Для меркуриала существует своя графическая среда — Tortoise HG (тортила).

При установке Tortoise HG (то есть достаточно установить тортилу) устанавливается и MercurialHg.

Создаем тестовые проект

Все манипуляции с репозитарием происходят при помощи программы hg .

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

— создать новый репозиторий в текущей папке (реп-й можно определить по наличии папки .hg ).

Hg Workbench и TortoiseHg

Hg Workbench — это запуск основной графической программы при работе с репозитарием.

TortoiseHg — отдельные команды для отдельных операций.

Добавить существующие файлы в репозиторий:

— просмотр статуса репозитария ( знак
? — говорит о том, что файлы репозиторию неизвестны;
M — modify);

— добавляем файлы в реп-й; или через тортилу: Tortoise HG — add files

Но данные файлы еще в репозитарий не добавились.

Добавляем файлы в репозитарий (выполняем commit / фиксация).

После нажатия на кнопку Commit (Фиксировать) выбранные файлы заносятся в репозитарий.

Commit в командной строке:

hg commit –m " " -u

( user name без кавычек и слитно с -u ).

Например, hg commit –m "commit hi"

Создадим новую ветку в проекте, где и будем реализовывать необходимый функционал:

Например, в ветке default будет вестись "текучка", а в новой ветке будет новый функционал.

Затем мы объединим ветку default с новой веткой (выполним merge ).

Работу над новым функционалом начинаем в ветке default и во время коммита создадим новую ветку.

Создаем новую ветку через интерфейс: нажимаем по кнопке branch: default (имя ветки) – open new branch (пишем название новой ветки) – create Branch .

Переключаем ветки (переходи обратно на ветку default ), но через командную строку*:

up (сокращенное от update ; при переключении веток с флагом -С все незакомиченные изменения будут утеряны!

*В командную строку через интерфейс TortoiseHG можно перейти следующим образом: хранилище (Repository) – терминал (terminal).

ПЕРЕКЛЮЧАЕМСЯ НА ДРУГУЮ ВЕТКУ (посредством графической оболочки):

Клик по ветке (последний кружок текущей ветки — правая кнопка мыши — update (обновить)). Этим мы переключимся на ветку new_branch . Таким образом мы переключаемся между ветками.

Замечание: Рекомендуется регулярно заливать главную ветку во второстепенную (то есть переключились на ветку new_branch и заливаем в нее default (основная ветка) ). Чем чаще это делать, тем меньше будет конфликтов.

То есть, например, заливаем данные из ветки default (главная ветка) во второстепенную ветку ( new_branch ), находясь на ветке new_branch (текущая):

Последний кружок ветки default — правая кнопка мыши — merge with local (слить с локальной копией)

Правило: ЛЮБАЯ ВЕТКА ПРИ ОБЪЕДИНЕНИИ (MERGE) БУДЕТ ЗАЛИВАТЬСЯ В ТЕКУЩУЮ ВЕТКУ.

Конфликт:

При конфликтах нажимаем по resolved (улажены). Выбираем опцию Tool Resolve (Уладить средством (правильнее инструментом)) — выбираем средство ( kdiff3noauto ) — трехсторонее сравнение неавтоматизированное.

Программа kdiff3noauto состоит из 3-х окон:

• 1 окно это базовые изменения;
• 2-е (центральное) окно это текущие изменения;
• 3-е эта ветка, которую мы хотим merge -ть с нашей текущей веткой.
• Нижнее окно — результат.

Выбор окон (а также нужных данных) делаем при помощи кнопок A, B, C. И в результирующем окне появляется те изменения, которые мы выбрали по нажатию на окна (A, B, C). По конфликтам перемещаемся при помощи стрелок (верх, низ).

Становится активной кнопка save . Чтобы появилась кнопка save должен быть выбор (A, B, C) по всем изменениям, по которым мы ходим стрелкой верх/низ. Сохранились и выходим.

Файлы с расширением .orig появляются во время конфликтов и как бы "про запас", на случай если вы затерли что-то важное.

.hgignore

добавляем исключения — то что будет определено в файле hgignore не будет отправлено при PUSH .

glob — означает, что далее будут описания файлов и папок с масками используемые в операционных системах (" * "," ? ").

regexp — далее будет описание файлов с регулярными выражениями.

syntax: glob

# игнорируем папку tmp
tmp
# игнорируем файл (все файлы, в которых содержится имя
# local)
config/*local*.ini

syntax: regexp

# папке htdocs/upload/ игнорируем все файлы кроме
# файлов с расширением jpg и png
htdocs/upload/.+?. (? ! (jpg|png)) . +

Работа над проектом в команде

remote server bitbucket.org

Создал репозитарий на сайте bitbucket.org. Использовать bitbucket.org гораздо удобнее, чем организовывать собственный сервер и открывать там репозиторий. Бесплатного доступа обычно хватает на небольшую группу программистов.

Итак, регистрируемся на bitbucket.org и создаем наш первый репозиторий.

Сделаем так, чтобы данные нашего проекта попали в репозиторий. То есть при push изменения должны будут отправляться на bitbucket.org (на созданный ранее репозиторий). Если у вас уже есть локальный проект, то выбираем ( I have an existing project ) и получаем инструкции, которые мы должны внести в наш проект, но, если настроить как по инструкции, то при каждом push будет требоваться пароль и т.д. Поэтому настроим (автоматизируем: чтобы при клике на push в Hg Workbench данные сразу отправлялись на удаленный репозиторий и т.д.) следующим образом:

Нам потребуется файл hgrc (папка .hg )

И файл (находится: пользователи – имя_пользователя – ) mercurial.ini .

В hgrc добавляем (Копируем адрес нашего реп-я):

[paths]
default = https://denzlll@bitbucket.org/denzlll/test_repo_mer

и вставляем его в hgrc + выше добавляем директиву [paths] .

В mercurial.ini добавляем:

[auth]
bb.prefix = https://denzlll@bitbucket.org/denzlll/test_repo_mer
bb.username = denzlll
bb.password = 10198211kost

• bb.prefix – путь к нашему репозиторию;
• bb.username — имя пользователя;
• bb.password – пароль.

Далее откроем Hg Workbench нашего проекта. Выше мы настроили автоматизацию для связи нашего репозитория с главным. Нажимаем PUSH , тем самым проталкиваем все на удаленный сервер.

Клонирование репозитория

Клонировать проект будем с удаленного сервера расположенного на bitbucket.org.

В bitbucket.org кликаем по кнопке clone . Копируем ссылку.

На папке (в которую клонируем проект) вызываем clone , затем в source (источник) указываем путь откуда клонируем; в destination (назначение) указываем путь куда клонируем. Все копия проекта создана.

При создании новой ветки и комита, а затем проталкивании в удаленные репозиторий произойдет ошибка (255) — ?. В любом случае, чтобы протолкнуть изменения созданные на новой ветке в репозиторий необходимо в терминале использовать команду:

Hg Commit — это так называемая фиксация, запоминаем изменения. (или добавляем новые файлы)

Hg Workbench — посмотреть все версии (ревизии)

Слить с локальной — merge

В любой момент можно откатиться на какую-либо ревизию: выбираем ревизию и обновить. Этим мы переходи в выбранную ревизию и выделяется отдельная ветка для вышестоящих ревизий.