Привет, Вы узнаете о том , что такое mercurial , Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое mercurial , сис контроля версий работы , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

Без Mercurial вы могли бы попытаться сохранить предыдущие версии, просто создавая много копий каталога с кодом:



Это муторно, требует много места на диске и создает путаницу. Лучше использовать систему контроля версий.

Большинство людей работают с Mercurial через интерфейс командной строки. Так можно работать в Windows, Unix, и Mac. Команда для Mercurial — это hg:



Если выполнить hg без параметров, то вы получите список наиболее часто используемых команд. Вы можете также попробовать выполнить hg help для получения полного списка команд.

Для того чтобы воспользоваться преимуществами контроля версий, вам нужен репозиторий. Репозиторий хранит все предыдущие версии всех ваших файлов. На самом деле, для экономии места на диске, все предыдущие версии не будут храниться — будет храниться только компактный список изменений.

В старые времена заиметь репозиторий было большим делом. Вам было необходимо иметь центральный сервер и нужно было установить на него программное обеспечение. Mercurial — распределенная система, так что вы можете использовать ее без модного центрального сервера. Вы можете пользоваться Mercurial, используя один только свой компьютер. А заполучить репозиторий супер просто: вы просто идете в каталог с вашим кодом…



… и выполняете команду hg init:

hg init
создает репозиторий.

Минуточку, а разве что-то произошло? Выглядит так, словно ничего не поменялось. Нет, если вы присмотритесь получше, то увидите, что появился новый каталог .hg:



Это и есть репозиторий! Это каталог со всем, что нужно Mercurial для работы. Настройки, предыдущие версии файлов, теги, лишняя пара носков на случай дождя, и прочее. Не лазьте туда. Вам почти всегда не стоит возиться с этим каталогом самостоятельно.

Ну хорошо, раз у нас теперь есть свежеиспеченный репозиторий, то мы захотим добавить в него все исходные файлы. Это тоже просто: нужно лишь выполнить hg add.

hg add
помечает файлы как запланированные для добавления в репозиторий. Файлы на самом деле не будут добавлены до тех пор, пока вы не зафиксируете изменения.

Остался еще один шаг… вам нужно зафиксировать ваши изменения. Какие изменения? Факт добавления всех этих файлов.

Почему вы вынуждены фиксировать изменения? При работе с Mercurial фиксирование изменений означает: «Эй, вот как файлы сейчас выглядят, так их и запомни, пожалуйста». Это как создание копии всего каталога… каждый раз, когда у вас есть что-то измененное, и оно вам типа нравится, то вы фиксируете изменения.

hg commit
сохраняет текущее состояние всех файлов в репозиторий.

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



После сохранения и выхода из редактора ваши изменения будут зафиксированы.

Вы можете выполнить hg log для просмотра истории изменений. Это как блог для вашего репозитория:

hg log
отображает историю изменений, зафиксированных в репозитории.

Давайте изменим файл и посмотрим, что получится.



Так как мы сделали изменение, то можем его зафиксировать при помощи hg commit:



Обратите внимание, что Mercurial догадался, что только один файл, a.txt, изменен:



А теперь, после того как я закоммитил (зафиксировал изменения), давайте посмотрим на историю:



Как любой нынешний блоггер, Mercurial помещает самое новое в начало.

Я собираюсь сделать еще одно изменение, просто чтобы потешить себя.



Коммичу (фиксирую изменения):



Мое сообщение к коммиту:



А что у нас теперь в истории?



Хорошо, это было весело. Я сделал несколько изменений и каждый раз, сделав значимое изменение, я фиксировал его в репозитории.

Я знаю, вы сейчас думаете: «ДЖОЭЛЬ, ВСЕ ЭТО ВЫГЛЯДИТ ПУСТОЙ ТРАТОЙ ВРЕМЕНИ». К чему вся эта катавасия с коммитами?

Терпение, мой юный друг. Ты вот-вот узнаешь, как извлечь выгоду из всего этого.

Для начала: скажем, вы сделали большую ошибку в процессе редактирования.



А затем, боже ж мой, в дополнение ко всему вы удалили пару очень важных файлов.



Во времена, когда не было Mercurial, это все могло бы стать неплохим поводом для похода к системному администратору. Там, со слезами на глазах, вы бы задали ему пронзительно грустный вопрос: «Почему система резервного копирования „временно“ не работает все последние восемь месяцев».

Системный администратор, которого все зовут Тако, слишком скромен и не обедает с остальной командой. В тех редких случаях, когда он не сидит в своем кресле на колесиках, можно увидеть треугольное пятно цвета сальсытам, где падали, пролетев между ног, капли от его мексиканских закусок. Эти капли гарантируют, что никто не возьмет его кресло, хотя это одно из превосходных кресел от Herman Miller, купленных учредителями компании для себя любимых, а не обычное бюджетное офисное нечто, из-за которого у всех болят спины.

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

Благодаря Mercurial, если вам не нравится то, что вы сделали, вы можете выполнить удобную команду hg revert, которая немедленно вернет ваш каталог к виду, в котором он был в момент последнего коммита.

hg revert
возвращает измененные файлы к зафиксированному в репозитории виду.

Я использовал аргумент --all, потому что хотел вернуть все файлы к прежнему состоянию.

Таким образом, когда вы работаете над исходным кодом, используя Mercurial, вы:

1. Делаете изменения
2. Оцениваете, подходят ли они
3. Если подходят, то выполняете commit
4. Если не подходят, то выполняете revert
5. GOTO 1

(Я знаю. Пользуюсь командной строкой, в Windows, да еще и оператором GOTO — я самый стремный программер из всех, когда-либо живших.)

Со временем вы можете забыть, на чем остановились и что поменяли с момента прошлого коммита. Mercurial отслеживает все это для вас. Все что вам нужно, это выполнить hg status и Mercurial даст вам список измененных файлов.

hg status
отображает список измененных файлов.

Предположим, я создал один файл, отредактировал другой и удалил третий.



hg status отображает список измененных файлов, добавляя значок в начале каждой строки. Этот значок сообщает о том, что же произошло. «M» означаете «Modified» — файл был изменен. "!" означает отсутствие — файл должен быть здесь, но куда-то делся. "?" означает что, состояние не определено — Mercurial ничего не знает про этот файл. Пока не знает.

Давайте разбираться с изменениями поочередно. Вот что поменялось в файле a.txt? Вы ведь можете забыть, что изменили. Черт, да я едва помню что я обычно ем на завтрак. А особенно внушает опасения то, что это всегда хрустящие колечки CHEERIOS. В любом случае, a.txt изменен. Что поменялось?

А есть команда для этого: hg diff сообщит вам в точности, что произошло с файлом с прошлого коммита.

hg diff
показывает, что изменилось в файле.

Формат результата немного непонятный, но самое важное, что вы можете видеть строки, начинающиеся с минуса (это то, что было удалено), и строки, начинающиеся с плюса (это то, что добавлено). Таким образом, вы можете видеть, что «Normal people» было заменено на «Civilians».

Теперь про тот пропавший файл favicon.ico. Как уже было сказано, если вы на самом деле не планировали его удалять, то можете выполнить команду hg revert для восстановления. Но, предположим, что вы на самом деле хотели его удалить. При каждом удалении (или добавлении) файла вы обязаны сообщить об этом событии Mercurial.

hg remove
помечает файлы как запланированные для удаления из репозитория. Файлы на диске не будут удалены до тех пор, пока вы не зафиксируете изменения.

«R» означает «Removed», то есть, помечен для удаления. Во время следующего коммита Mercurial удалит этот файл. (История для этого файла сохранится в репозитории, так что, конечно, мы всегда сможем получить его назад.) И, наконец, нужно добавить этот новый файл b.txt:



«A» означает «Added», то есть, помечен для добавления. Заметили, что я разленился писать hg status каждый раз? Для Mercurial достаточно минимального набора букв, однозначно определяющего команду, а на stначинается только одна команда.

Разобравшись с вопросиками и восклицательными знаками, я могу продолжить и внести изменения:



На что еще стоит обратить внимание в выводе hg log: строка changeset отображает номер каждого коммита. На самом деле даже два номера: короткий удобный вроде «0» для первой ревизии и длинный непонятный шестнадцатеричный, на который вы можете пока не обращать внимания.

Запомните, что Mercurial хранит в репозитории достаточно информации для воссоздания любой версии любого файла.

Прежде всего, при помощи простой команды hg cat вы можете вывести содержимое любой версии любого файла в консоль. К примеру, вот как увидеть, что сейчас находится в файле a.txt:

hg cat
отображает содержимое любого файла для любой ревизии.

Для того чтобы увидеть как файл выглядел раньше, я могу просто указать нужный номер набора изменений (changeset из лога) при помощи аргумента -r («revision», то есть ревизия):



Если у файла сложное содержимое или большая длина, а изменился он лишь немного, то я могу использовать команду hg diff с аргументом r для вывода разницы между двумя ревизиями. К примеру, вот как посмотреть разницу между ревизиями 0 и 1:



И наконец,- надеюсь, что вы еще не свалились от усталости,- прежде чем закончить эту часть, я хочу показать вам еще одну маленькую фишку: при помощи команды hg update вы можете перемещаться вперед и назад ко времени создания любой ревизии. Ну, по сути в будущее вы перемещаться не сможете, хотя это было бы супер круто, да. Вы, имея всего четыре ревизии, смогли бы выполнить hg update -r 103994 и получить реально крутую версию ваших исходников. С гравицапой и прочими футуристическими штучками. Но, конечно, это невозможно.

Что на самом деле возможно, так это вернуться к любой ревизии. Следите за руками:

hg update
приводит рабочий каталог к состоянию, как у заданной ревизии.

Фактически, для перемещении вперед и назад между ревизиями hg update вносит в файлы запомненные изменения. Если файл был добавлен или удален, то эта команда добавляет или удаляет его на диске. Выполнение hg update без дополнительных параметров приводит рабочий каталог к состоянию как у самой свежей ревизии.

Проверь себя

Отлично! Эта часть закончена. Вот все, что вы должны уметь делать на данный момент:

1. Создать репозиторий
2. Добавить или удалить файлы из репозитория
3. После внесения изменений просмотреть, что было сделано, а затем
4. … зафиксировать изменения, если они вам нравятся
5. … или откатить изменения, если не нравятся
6. Просмотреть предыдущие версии файлов или привести рабочий каталог к состоянию как у некоторой ревизии.

Привыкаем работать в команде

При командной работе с Mercurial общепринято настраивать центральный репозиторий в дополнение к личным репозиториям, расположенным на компьютерах членов команды. Центральный репозиторий можно рассматривать как своего рода блошиный рынок, то есть, как место где встречаются и обмениваются сделанным.





Проще всего создать центральный репозиторий при помощи встроенного в Mercurial веб-сервера. Вам нужно лишь создать репозиторий при помощи hg init и открыть к нему доступ при помощи hg serve. По умолчанию репозиторий будет доступен на 8000-ом порту.

hg serve
запускает веб-сервер и делает текущий репозиторий доступным в сети Интернет.

Так как сервер запущен на компьютере joel.example.com, то я могу просто открыть joel.example.com:8000в браузере и увидеть, что сервер работает, правда репозиторий абсолютно пуст.



Имея запущенный центральный веб-сервер, я могу склонировать центральный репозиторий с сервера на мой компьютер для личного пользования. Репозиторий в данный момент пуст, значит, я получу еще один пустой репозиторий в результате клонирования.

hg clone
делает полную копию всего репозитория.

Теперь я создам файл guac, в котором запишу мой знаменитый рецепт гуакамоле.



Я добавлю и закоммичу этот файл в репозиторий. Об этом говорит сайт https://intellect.icu . Это будет первая официальная версия:



Напишу комментарий к коммиту:



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



И зафиксирую изменения:



Обратите внимание, что когда я коммитил в этот раз, то использовал аргумент -m, чего раньше не делал. Это просто для того, чтобы указать комментарий к коммиту в командной строке и не использовать редактор.

Хорошо, что у нас есть? К настоящему времени у меня есть центральный репозиторий и мой персональный клон этого репозитория. Я сделал два изменения и зафиксировал их, но эти изменения хранятся в моем клоне. В центральном репозитории их пока нет. Так что все выглядит так:



А сейчас я воспользуюсь командой hg push, которая протолкнет мои изменения из локального в центральный репозиторий:

hg push
проталкивает свежие изменения из текущего репозитория в центральный.

Ну, отлично. Ясно видно, что так не сработает. Не хочу думать о безопасности и последствиях запуска какого-то веб-сервера с разрешением всем и каждому проталкивать в него свои тупые изменения. Потерпите немного, я собираюсь настроить сервер так, чтобы он разрешал делать всем что угодно. Нужно отредактировать файл .hg\hgrc на сервере:



Не стоит и говорить, что это небезопасно. Но если вы в защищенной локальной сети на работе, и у вас есть хороший файрвол, и вы доверяете всем в своей сети, то так вполне можно сделать. В противном случае вам стоит почитать о настройках безопасности.

Хорошо, пора вновь запустить сервер:



Теперь у меня должно получиться протолкнуть изменения:



Ага! Теперь все выглядит так:



Я знаю, о чем вы думаете. Вы думаете: «Господи, Джоэль, это все странно. Почему в репозиториях лежатизменения, а не файлы? Где тот файлик guac?».

Ну да, странно. Но так уж работает распределенный контроль версий. Репозитории просто хранят большие стопки изменений. Представьте, что одно изменение — это как лист частично прозрачного материала. Если у вас есть пачка таких листов, и вы сложите их друг на дружку так, чтобы самое последнее изменение было сверху, а потом посмотрите на эту пачку сверху вниз, то — та-да-да-дам! — увидите текущую версию файла. Если по одному убирать листы с верха стопки, то вы будете видеть все более и более ранние версии файла.

Воспользуемся браузером и снова заглянем в центральный репозиторий:



Там именно то, что ожидалось.

Теперь я позову Розу помочь мне в работе над рецептом. Роза из команды тестеров. Любой подтвердит, что она напоминает одну из тех бабулек, что можно увидеть в Вегасе, часами сидящих с отвисшей челюстью перед «одноруким бандитом» и бросающих монетку за монеткой в заветную щелку. Все отличие в том, что Роза программы тестирует. Вы можете подкинуть ей новую версию программы, и она проверит ее на 23 дистрибутивах Linux. Проверит по очереди на каждом. Не выказывая никаких эмоций, не делая лишних движений. Останавливаясь только для того, чтобы сообщить вам, что пропущена точка над i в турецкой версии Ubuntu Linux. Роза отлично тестирует, но, клянусь, иногда ведет себя как зомби.



Роза воспользовалась командой hg clone для создания своей собственной полной копии репозитория. hg cloneпринимает два аргумента: URL репозитория и имя каталога, в который вы хотите склонировать. У Розы свой каталог recipes.



Обратите внимание, что при выполнении hg log она видит всю историю. То есть Роза скачала весь репозиторий с полной историей всего, что уже произошло.

Сейчас Роза сделает изменение и внесет его в репозиторий:



Вот, коммитит. Обратите внимание, что она может работать даже если сервер не работает: коммит полностью выполняется на ее машине.



Пока Роза делала свои изменения, я тоже кое-что сделал.



После того, как я зафиксирую свои изменения, станет видно, что в моем логе под номером два указано не то же, что у Розы.



Истории в наших репозиториях начали отличаться.



Не переживайте, скоро увидим, как свести все эти изменения воедино для получения отменной вкусняшки с чипсами и перчиком хабанеро.

Роза может продолжать работать без подключения к серверу, делая сколько угодно изменений. Она может фиксировать или откатывать изменения в своем репозитории. Однако настанет момент, когда она решит поделиться своими изменениями с остальными. Она может выполнить команду hg outgoing и увидеть список изменений, ожидающих отправки в центральный репозиторий. Это те изменения, которые будут отправлены при выполнении hg push.

hg outgoing
отображает список изменений ждущих отправки в текущем репозитории.

hg outgoing это просто список всех таких изменений в текущем репозитории, которых нет в центральном репозитории.

Хорошо, вот Роза проталкивает свои изменения в центральный репозиторий.



И теперь все выглядит так:



После того, как я сходил выпить четвертую чашку латте за сегодняшний день, я тоже готов протолкнуть мое изменение про картофельные чипсы.



ААААА!!! Ошибка! Да, кстати, видите сообщение? То, в котором написано используйте ключ -f для принудительного проталкивания (use push -f to force)? Это ужасный совет. Никогда и ни за что не используйте ключ -f. Вы пожалеете о том, что использовали его. Просто поверьте мне в данный момент.

Причина, по которой у Розы получилось протолкнуть изменения, а у меня нет в том, что картофельный чипсы и гуакамоле плохо сочетаются. Шучу, шучу! Просто хотел удостовериться, что вы еще не уснули там.

Команда завершилась с ошибкой потому, что каждый из нас сделал изменения, а значит, их нужно слить вместе, и Mercurial знает об этом.

Первым делом я заберу все изменения из центрального репозитория, которых у меня еще нет, чтобы произвести слияние (merge).



Тут какая-то тарабарщина про +1 голову (+1 heads). Это потому, что мой репозиторий, в котором раньше были аккуратно уложены три изменения, стал двухголовым монстром. На вершине репозитория опасно расположены два разных изменения. Вот как это выглядит:



У меня в репозитории теперь обе версии. Вот моя:



А вот версия Розы:



И я должен слить эти версии воедино. К счастью, это просто:



Глядите-ка! Команда hg merge взяла и объединила обе мои «головы» (изменения на вершине репозитория) в одну. Так как в данном случае мы с Розой изменили разные части файла, то конфликтов при слиянии не было и все прошло без сучка без задоринки.

hg merge
производит слияние (объединение) двух «голов».

Мне по-прежнему надо сделать коммит. Это важно. Если бы слияние не удалось, то я всегда мог бы откатиться и попробовать снова. Но, так как слияние было успешным, то я сделаю коммит. После этого я смогу протолкнуть мои изменения в центральный репозиторий.



Теперь в центральном репозитории то же, что в моем:



Хорошо, у меня есть изменения Розы и мои собственные изменения, но у Розы пока нет моих изменений.

Есть еще один момент, связанный с Розой, о котором я забыл рассказать. Она — доктор. Ага, доктор, который врач. Ну не чудно? Она была главным педиатром в больнице Mt. Sinai и получала, наверное, «раз в пять больше, чем этот поганый укурок платит своим тестерам». Никто наверняка не знает, почему она оставила медицину. Остальные тестеры думают, что случилось что-то трагичное. Еще у нее семья была: на ее столе картинка милого десятилетнего ребенка. Но теперь она живет одна, и мы не хотим лезть ей в душу.

Розе нужно вытянуть (pull) свежие входящие изменения из репозитория, чтобы получить мои изменения.



Готово. Теперь, — вам может показаться это странным, — несмотря на то, что Роза втянула новые изменения в свой репозиторий, эти изменения не находятся в ее рабочем каталоге.



Видите, Она по-прежнему работает с кукурузными чипсами. С кукурузными чипсами!

У нее есть мои последние изменения где-то в репозитории…



Просто мои изменения не в ее рабочем каталоге. Это потому, что она до сих пор изменяет второй набор изменений. Это можно увидеть, выполнив команду hg parent:

hg parent
отображает набор изменений, находящийся в рабочем каталоге.

Mercurial добр к нам. Вытягивать изменения всегда безопасно. Все, что происходит — это получение свежих изменений, сделанных другими людьми. Мы можем начать работать с этими изменениями позже, когда нам удобно.

Запомните, что команда hg up без аргументов приведет рабочий каталог к «макушке» (tip), то есть применит все изменения до самого верхнего набора изменений. В данном случае, это четвертый набор изменений:



Теперь Роза видит самую свежую версию с изменениями от обоих нас.

Когда вы работаете в команде, то рабочий процесс будет выглядеть во многом так:

1. Забрать свежую версию, с которой все работают, если вы давненько этого не делали, выполнив:
   • hg pull
   • hg up
2. Внести изменения
3. Зафиксировать изменения (локально)
4. Повторить пункты 2-3 до тех пор, пока у вас не получится хороший код, который вы хотите вывалить на всех остальных
5. Когда вы готовы поделиться, выполнить:
   • hg pull для получения чужих изменений (если есть)
   • hg merge для слияния этих изменений со своими
   • тестирование! для того, чтобы удостовериться, что при слиянии ничего не попортилось
   • hg commit (для фиксации результата слияния)
   • hg push

Проверь себя

Вот все, что вы должны уметь делать на данный момент:

1. Настроить центральный репозиторий и дать членам команды возможность делать его клоны
2. Проталкивать изменения в центральный репозиторий
3. Вытягивать изменения из центрального репозитория
4. Делать слияние изменений от разных авторов

Исправляем ошибки

Одно из главных преимуществ Mercurial состоит в том, что вы можете использовать личные клоны репозитория для экспериментов и разработки новых возможностей. Если что-то пошло не так, можно все исправить за мгновение.

Часть 4. Исправляем ошибки

Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:





Emacs, как же я тебя люблю. Как бы то ни было, все можно исправить. Наиболее распространенным способом справиться с такими проблемами является использование команды hg revert:

hg revert
возвращает файлы к состоянию, зафиксированному в репозитории.

Эта команда вернет файлы в именно то состояние, что было у них в момент последнего коммита. Mercurial не

продолжение следует...

Продолжение:

Часть 1 Mercurial — система контроля версий. Основы работы
Часть 2 Часть 5. Процесс слияния - Mercurial — система контроля версий.