Библиотека знаний - hg_init

Hg Init: Переобучение для пользователей Subversion. Часть 1.

Anonymous (anonymous@undisclosed.example.com) — 2016-02-16T14:09:41+00:00

Hg Init: Переобучение для пользователей Subversion. Часть 1.

    <h5>Hg Init: Учебное пособие по Mercurial.</h5><br>

<img src="http://habrastorage.org/storage/eebea7f1/5482efc4/01467053/55589e0f.png" align="left">Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (<a href="http://www.joelonsoftware.com/">Joel Spolsky</a>) рассказывает о ключевых принципах Mercurial. Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто <a href="http://habrahabr.ru/blogs/development_tools/108658/">пропустить эту часть</a>. <h4>Часть 1. Переобучение для пользователей Subversion</h4> В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial! <img src="http://habrastorage.org/storage/33c920fc/5fefe056/7d9c727b/7761db50.png" align="left">Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с <a href="http://ru.wikipedia.org/wiki/%D0%A1%D0%B0%D0%B9%D0%BB%D0%BE%D0%BD%D1%8B">Сайлонами</a>, Штурмовиками и прелестными <a href="http://en.wikipedia.org/wiki/Labradoodle">лабрадудлами</a> или что там требует ваш IT-отдел. <a name="habracut"></a> «Проблема с распределенными системами контроля версий в том, что они позволяют слишком легко делать ветки (branch)», — сказал я. «А ветки всегда приносят проблемы». Получается, что тут я тоже был неправ. Волна такая пошла. Ветки несут проблемы при работе с Subversion, потому что Subversion не хранит достаточно информации для того, чтобы слияние (merge) нормально работало. В Mercurial слияние безболезненно и легко, а потому ветвление распространено и безвредно. Потом я сказал: «Хорошо, я буду использовать эту систему, но не ждите, что я смогу в ней разобраться». И я попросил Джейкоба сделать для меня шпаргалку, в которой будет все, что я обычно делал в Subversion, с указанием аналогов в Mercurial. Я могу показать вам эту шпаргалку, но не буду, потому что она несколько месяцев мешала моим мозгам перестроиться. Получается что, если вы использовали Subversion, то ваша голова немного… Э-э-э, как бы помягче сказать? Вы ранены во всю голову! Нет, не получилось. Вам нужно переобучение. Я ходил таким раненным полгода и думал, что Mercurial более сложен, чем Subversion. Но это потому, что я не понимал, как новая система на самом деле работала. Как только я понял, как она работает, оказалось — опа! да это достаточно просто. Вот я и написал для вас это пособие, в котором очень старался не объяснять все в терминах Subversion, потому что хватит уже раненных во всю голову. Их и так достаточно. Вместо этого, для тех, кто переходит на Mercurial с Subversion, я написал эту часть в начале пособия, которая постарается аннулировать как можно больше вреда, чтобы вы могли изучить Mercurial с чистого листа. Если вы никогда не использовали Subversion, то можете перейти к следующей статье (<a href="http://habrahabr.ru/blogs/development_tools/108658/">«Основы Mercurial»</a>) и ничего не упустите. Готовы? Хорошо, начнем с короткого опроса. <blockquote>Вопрос первый: Вы всегда с первого раза пишите идеальный код?</blockquote> Если вы ответили «Да» на первый вопрос, то вы врун и жулик. Получите «банан» и приходите на пересдачу. Новый код глючен. Требуется время, чтобы он начал прилично работать. А пока этот код может повредить остальным разработчикам в команде. И вот, как работает Subversion: <ul> <li>Когда вы вносите новый код в репозиторий, его получают все.</li> </ul> Так как весь новый код, который вы пишите, содержит баги, то у вас есть выбор. <ul> <li>Вы можете вносить глючный код и сводить людей с ума, или</li> <li>Вы можете придерживать новый код до тех пор, пока полностью его не отладите.</li> </ul> Subversion постоянно ставит вас перед этим ужасным выбором. Или репозиторий полон глючного кода, потому что содержит новый код, который только что написан, или новый код, что только что написан, не добавлен в репозиторий. Как пользователи Subversion, мы настолько привыкли к этой дилемме, что трудно представить себе систему, где эта дилемма не существует. Команда, использующая Subversion, часто днями или неделями ничего не добавляет в репозиторий. В таких командах новички боятся залить что-то в репозиторий из-за опасения поломать билд, или разозлить Майка, ведущего разработчика, или по сходным причинам. Майк однажды так рассердился из-за изменений, которые поломали билд, что ворвался к практиканту, смахнул все с его стола и проорал: «Это твой последний день!». Этот день не был последним, но бедный практикант практически намочил штаны. Все эти страхи и опасения означают, что люди пишут код неделя за неделей не используя преимуществ системы контроля версий, а затем ищут кого-нибудь опытного, чтобы внести код в репозиторий. И для чего репозиторий, если им нельзя пользоваться? Вот простая иллюстрация жизни с Subversion: <img src="http://habrastorage.org/storage/d15885f7/9ebf875d/5d83d6f4/f6ea14f3.png" align="center"> При работе с Mercurial у каждого разработчика свой собственный репозиторий, живущий у них на компьютере: <img src="http://habrastorage.org/storage/df9ce736/7f3b9699/aa8bb2bb/b5180086.png" align="center"> Так что вы можете вносить изменения в свой репозиторий и пользоваться всеми благами системы контроля версий, когда захотите. Каждый раз, чуть улучшив код, вы можете вносить его в репозиторий. Когда код надежен, и вы хотите дать другим его использовать, вы проталкиваете (push) ваши изменения из своего репозитория в центральный репозиторий. Из центрального репозитория каждый вытягивает (pull) общие изменения и рано или поздно все получат ваш новый код. Когда он готов. Mercurial разделяет момент внесения кода в репозиторий и момент получения этого кода всеми остальными. И это означает, что вы можете коммитить (

hg com

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

hg push

) их в главный репозиторий. <h5>Еще одно большое концептуальное отличие</h5> Вы знаете, что у каждой улицы есть название? <img src="http://habrastorage.org/storage/0a94d9a4/417a4639/b4495b24/db298b24.png" align="right">Ну, оказывается что в Японии это не совсем так. Японцы обычно просто <a href="http://sivers.org/jadr">нумеруют кварталы</a> между улицами и только очень, очень важные улицы имеют названия. У Subversion и Mercurial есть сходное различие. В Subversion мыслят ревизиями. Ревизия — это то, как выглядит вся файловая система в определенный момент времени. В Mercurial вы мыслите наборами изменений (changesets). Набор изменений — это четкий список изменений между двумя соседними ревизиями. Шесть того или полдюжины этого — в чем разница? Вот в чем разница. Представьте, что вы и я вместе работаем над каким-то кодом. И мы сделали ветки этого кода, и каждый пошел на свое место и сделал много-много независимых изменений в коде, так что ветки достаточно сильно разошлись в разные стороны. Когда нам нужно сделать слияние, Subversion смотрит на обе ревизии — мой измененный код и ваш измененный код — и пытается угадать, как слепить их вместе в один большой страшный бардак. Обычно Subversion это не удается, и получаются длинные списки конфликтов («merge conflicts»), которые на самом деле не конфликты, а просто места, в которых система не смогла разобраться в наших изменениях. Для сравнения, если мы независимо работали в Mercurial, то система сохраняла серии изменений. Таким образом, когда мы хотим сделать слияние кода, у Mercurial на самом деле гораздо больше информации: система знает, что каждый из нас изменил, и может заново применить эти изменения вместо того, чтобы смотреть на конечный вариант и пытаться угадать, как все это собрать воедино. Если, для примера, я немного изменил какую-то функцию и перенес ее куда-то, то Subversion на самом деле не помнит этого. Так что когда дело дойдет до слияния, она просто может решить, что в коде из ниоткуда появилась новая функция. В то же время, Mercurial запомнит: функция изменилась, функция переместилась. Это значит, что если вы тоже поменяли эту функцию, то вероятность того, что Mercurial успешно проведет слияние наших изменений, гораздо больше. Так как Mercurial мыслит в терминах наборов изменений, вы можете делать интересные вещи с этими наборами изменений. Вы можете дать попробовать эти изменения другу вместо того, чтобы вносить эти изменения в центральный репозиторий и вынуждать всех ими пользоваться. Если все это кажется вам немного запутанным — не переживайте. По мере чтения этого пособия все обретет ясный смысл. В данный момент самое главное, что вам нужно знать: из-за того, что Mercurial оперирует наборами изменений, а не ревизиями, слияние кода в Mercurial работает гораздо лучше, чем в Subversion. И это значит, что вы можете свободно делать ветки, потому что слияние не будет кошмаром. Хотите узнать кое-что забавное? Почти у каждой команды, использующей Subversion, с членами которой я разговаривал, есть некий вариант одной и той же истории. История настолько часто встречается, что я просто назову ее «Главной историей про Subversion». Вот эта история: в определенный момент они попробовали сделать ветку в развитии кода. Обычно для того, чтобы версия, которую отдали клиентами, была отделена от версии, с которой возятся разработчики. И все рассказывали мне, что когда они попробовали сделать это, то все было отлично до момента, когда им нужно было сделать слияние. И слияние было кошмаром. То, что должно было быть пятиминутным процессом, превратилось в шесть программистов вокруг одного компьютера, работавших две недели, пытаясь вручную внести каждый багфикс из стабильной ветки в ветку разработчиков. И почти в каждой команде мне сказали, что они поклялись «больше никогда» и отказались от веток. И теперь они делают так: каждая новая фича в большом

#ifdef

блоке. Так они могут работать всегда в стволе репозитория, а клиенты никогда не получают новый код пока он не отлажен, и, откровенно говоря, это нелепо. Отделять стабильный и разрабатываемый код — это именно то, что система контроля версий должна позволять вам делать. С переходом на Mercurial, вы можете даже не осознать этого, но ветвление снова станет возможным и вам не нужно будет ничего опасаться. Это означает, что у вас могут быть командные репозитории, где небольшая команда программистов работает над новой фичей, и, когда все готово, сливает свои изменения в главный репозиторий. И это работает! Это означает, что у вас могут быть репозитории для службы тестирования, где команда тестеров пробует новый код. Если он работает, то служба тестирования вносит изменения в центральный репозиторий, что, в свою очередь, означает, что в центральном репозитории всегда надежный протестированный код. И это работает! Это означает, что вы можете проводить эксперименты в отдельных репозиториях, и, если эксперименты удачны, сливать изменения в главный репозиторий, а если неудачны, то просто выбрасывать их. И это работает! <h5>И последнее большое концептуальное отличие</h5> Последнее важное концептуальное отличие между Subversion и Mercurial не такое уж и важное, но оно может поставить вас в неудобное положение, если вы не будете про него знать. Вот оно: Subversion, по сути, система контроля изменений для файлов, а в Mercurial контроль изменений применяется ко всему каталогу, включая все подкаталоги. Главным образом, это проявляется так: в Subversion, если вы находитесь в подкаталоге и вносите свои изменения в репозиторий, то вносятся только изменения из этого подкаталога и всех его подкаталогов. Это может привести к тому, что вы забудете внести изменения из другого подкаталога. А в Mercurial все команды всегда применяются ко всему дереву каталогов. Если ваш код находится в c:\code, то когда вы выполняете

hg commit

, то можете находиться в c:\code или в любом подкаталоге — результат будет одним и тем же. Это не так уж важно, но если вы привыкли иметь один гигантский репозиторий на всю компанию, в котором некоторые люди работают только с определенными подкаталогами, которые их касаются, то знайте, что это не самый лучший метод при работе с Mercurial. Вам лучше иметь много меньших по размеру репозиториев на каждый проект. <h5>И напоследок…</h5> Теперь часть, где вы просто должны поверить мне на слово. Mercurial лучше, чем Subversion. Лучше, если работать над кодом в команде. Лучше, если работать над кодом в одиночку. Просто лучше. И, попомните мои слова, если вы поймете как работает Mercurial, и будете работать так, как работает Mercurial, и не будете бороться с этой системой, и не будете пытаться делать с Mercurial все так же, как делали в Subversion, а вместо этого научитесь работать так, как от вас ожидает Mercurial, то будете счастливы, успешны, упитаны и всегда сможете найти пульт от телевизора. И поначалу вас будет искушать мысль — я знаю, будет, — бросить Mercurial и вернуться к Subversion. Потому что будет странно, словно вы живете в чужой стране, и вас будет тянуть на родину, и вы будете придумывать всевозможные оправдания вроде того, что будете заявлять, что в Mercurial рабочие копии занимают слишком много места, что есть туфта, так как на самом деле они занимают меньше места, чем в Subversion. Это правда! И затем вы вернетесь к Subversion, потому что вы пробовали делать ветки так же, как в Subversion, и запутались, и получилось не очень, потому что вы на самом деле должны были делать ветки как в Mercurial, клонируя репозитории, не пытаться делать так, как работало в Subversion, а научиться принятому в Mercurial способу, который, поверьте мне, работает. И после этого вы попросите Джейкоба, или кто там у вас эквивалент Джейкоба в вашем офисе, дать вам шпаргалку «От Subversion к Mercurial», и вы потратите три месяца, думая, что

hg fetch

это как

svn up

, не понимая, на самом деле, что делает

hg fetch

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

hg merge

и скажете себе «О, боже, это круто, это просто сработало.» И Майк расслабится и поделится косячком с практикантами, и наступит весна, и молодежь из соседнего колледжа сменит пуховики на коротенькие надорванные футболки, и жизнь будет хороша. </html>

Продолжение здесь: Hg Init: Часть 2. Основы Mercurial

Основы Mercurial. Часть 2.

Anonymous (anonymous@undisclosed.example.com) — 2016-02-16T15:01:10+00:00

scm, mercurial, hg

Основы Mercurial. Часть 2.

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть Hg Init: Переобучение для пользователей Subversion. Часть 1..

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

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

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

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

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

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

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

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

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

de0f8775.pn

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, вы: Делаете изменения Оцениваете, подходят ли они Если подходят, то выполняете commit Если не подходят, то выполняете revert 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 без дополнительных параметров приводит рабочий каталог к состоянию как у самой свежей ревизии.

Проверь себя

Отлично! Эта часть закончена. Вот все, что вы должны уметь делать на данный момент: Создать репозиторий Добавить или удалить файлы из репозитория После внесения изменений просмотреть, что было сделано, а затем … зафиксировать изменения, если они вам нравятся … или откатить изменения, если не нравятся Просмотреть предыдущие версии файлов или привести рабочий каталог к состоянию как у некоторой ревизии.

Продолжение здесь: Hg Init: Часть 3. Привыкаем работать в команде

Hg Init: Часть 3. Привыкаем работать в команде

Anonymous (anonymous@undisclosed.example.com) — 2011-10-10T15:13:46+00:00

Hg Init: Часть 3. Привыкаем работать в команде

    <img src="http://habrastorage.org/storage/eebea7f1/5482efc4/01467053/55589e0f.png" align="left">Это третья часть из серии <b>Hg Init: Учебное пособие по Mercurial</b> от Джоэля Спольски (<a href="http://www.joelonsoftware.com/">Joel Spolsky</a>). Предыдущие части:<br>

hg init

и открыть к нему доступ при помощи

hg serve

. По умолчанию репозиторий будет доступен на 8000-ом порту. <img src="http://habrastorage.org/storage/1918f1bf/d865dae0/d4966f24/12e8fe35.png"> <blockquote>

hg serve

запускает веб-сервер и делает текущий репозиторий доступным в сети Интернет. </blockquote> Так как сервер запущен на компьютере joel.example.com, то я могу просто открыть joel.example.com:8000 в браузере и увидеть, что сервер работает, правда репозиторий абсолютно пуст. <img src="http://habrastorage.org/storage/0140b8e0/896882e3/4baa6617/d1a267f3.png"> Имея запущенный центральный веб-сервер, я могу склонировать центральный репозиторий с сервера на мой компьютер для личного пользования. Репозиторий в данный момент пуст, значит, я получу еще один пустой репозиторий в результате клонирования. <img src="http://habrastorage.org/storage/2c740a45/4fabec98/c98fcb7a/92f422c6.png"> <blockquote>

hg clone

делает полную копию всего репозитория. </blockquote> Теперь я создам файл guac, в котором запишу мой знаменитый рецепт <a href="http://ru.wikipedia.org/wiki/%D0%93%D1%83%D0%B0%D0%BA%D0%B0%D0%BC%D0%BE%D0%BB%D0%B5">гуакамоле</a>. <img src="http://habrastorage.org/storage/4aff84ff/486ba60c/9057e021/c0035b15.png"> Я добавлю и закоммичу этот файл в репозиторий. Это будет первая официальная версия: <img src="http://habrastorage.org/storage/44d3a55b/e0d4e124/e42c1cf7/cf3b7c31.png"> Напишу комментарий к коммиту: <img src="http://habrastorage.org/storage/89a503a1/b5c6d82d/6c6b4193/13248894.png"> Я быстренько отредактирую файл, сделав одно небольшое изменение, для того, чтобы у нас было хоть немного истории изменений в репозитории. <img src="http://habrastorage.org/storage/deaba090/1260460f/410b04a4/5167fd72.png"> И зафиксирую изменения: <img src="http://habrastorage.org/storage/233f2aa8/8318239c/90025c61/b72bd994.png"> Обратите внимание, что когда я коммитил в этот раз, то использовал аргумент

-m

, чего раньше не делал. Это просто для того, чтобы указать комментарий к коммиту в командной строке и не использовать редактор. Хорошо, что у нас есть? К настоящему времени у меня есть центральный репозиторий и мой персональный клон этого репозитория. Я сделал два изменения и зафиксировал их, но эти изменения хранятся в моем клоне. В центральном репозитории их пока нет. Так что все выглядит так: <img src="http://habrastorage.org/storage/24badfd6/f67bd275/c3ddb80b/26b09b8b.png"> А сейчас я воспользуюсь командой

hg push

, которая протолкнет мои изменения из локального в центральный репозиторий: <blockquote>

hg push

проталкивает свежие изменения из текущего репозитория в центральный. </blockquote> <img src="http://habrastorage.org/storage/5a06d34f/2bc320d7/b153b069/e629a0db.png"> Ну, отлично. Ясно видно, что так не сработает. Не хочу думать о безопасности и последствиях запуска какого-то веб-сервера с разрешением всем и каждому проталкивать в него свои тупые изменения. Потерпите немного, я собираюсь настроить сервер так, чтобы он разрешал делать всем что угодно. Нужно отредактировать файл .hg\hgrc на сервере: <img src="http://habrastorage.org/storage/36e5b657/454f8d10/28fb9c5f/d8f05740.png"> Не стоит и говорить, что это небезопасно. Но если вы в защищенной локальной сети на работе, и у вас есть хороший файрвол, и вы доверяете всем в своей сети, то так вполне можно сделать. В противном случае вам стоит почитать о настройках безопасности. Хорошо, пора вновь запустить сервер: <img src="http://habrastorage.org/storage/105523b5/59e1b4bf/6342c521/267d945e.png"> Теперь у меня должно получиться протолкнуть изменения: <img src="http://habrastorage.org/storage/a2b9811f/4badc381/b95e5697/f5eb54c8.png"> Ага! Теперь все выглядит так: <img src="http://habrastorage.org/storage/4dbad5c0/8258e140/798f5ae3/e02b095c.png"> Я знаю, о чем вы думаете. Вы думаете: «Господи, Джоэль, это все странно. Почему в репозиториях лежат изменения, а не файлы? Где тот файлик guac?». Ну да, странно. Но так уж работает распределенный контроль версий. Репозитории просто хранят большие стопки изменений. Представьте, что одно изменение — это как лист частично прозрачного материала. Если у вас есть пачка таких листов, и вы сложите их друг на дружку так, чтобы самое последнее изменение было сверху, а потом посмотрите на эту пачку сверху вниз, то — та-да-да-дам! — увидите текущую версию файла. Если по одному убирать листы с верха стопки, то вы будете видеть все более и более ранние версии файла. Воспользуемся браузером и снова заглянем в центральный репозиторий: <img src="http://habrastorage.org/storage/3c857027/d3fe2213/746c3e1a/bd26eb0f.png"> Там именно то, что ожидалось. Теперь я позову Розу помочь мне в работе над рецептом. Роза из команды тестеров. Любой подтвердит, что она напоминает одну из тех бабулек, что можно увидеть в Вегасе, часами сидящих с отвисшей челюстью перед «одноруким бандитом» и бросающих монетку за монеткой в заветную щелку. Все отличие в том, что Роза программы тестирует. Вы можете подкинуть ей новую версию программы, и она проверит ее на 23 дистрибутивах Linux. Проверит по очереди на каждом. Не выказывая никаких эмоций, не делая лишних движений. Останавливаясь только для того, чтобы сообщить вам, что пропущена точка над i в турецкой версии Ubuntu Linux. Роза отлично тестирует, но, клянусь, иногда ведет себя как зомби. <img src="http://habrastorage.org/storage/371530e4/00fbd7ce/85609735/4208ce7b.png"> Роза воспользовалась командой

hg clone

для создания своей собственной полной копии репозитория.

hg clone

принимает два аргумента: URL репозитория и имя каталога, в который вы хотите склонировать. У Розы свой каталог recipes. <img src="http://habrastorage.org/storage/3750c07a/f5b90d1b/06d55bb2/ecd4d3a6.png"> Обратите внимание, что при выполнении

hg log

она видит всю историю. То есть Роза скачала весь репозиторий с полной историей всего, что уже произошло. Сейчас Роза сделает изменение и внесет его в репозиторий: <img src="http://habrastorage.org/storage/625ee93f/4abace04/4fa31409/85261f2d.png"> Вот, коммитит. Обратите внимание, что она может работать даже если сервер не работает: коммит полностью выполняется на ее машине. <img src="http://habrastorage.org/storage/2326821c/0aa0eb4e/1b0ff6ad/985efcd6.png"> Пока Роза делала свои изменения, я тоже кое-что сделал. <img src="http://habrastorage.org/storage/5e8ea447/72ead90e/263bba3f/8721f9eb.png"> После того, как я зафиксирую свои изменения, станет видно, что в моем логе под номером два указано не то же, что у Розы. <img src="http://habrastorage.org/storage/2dba88e3/6da5d0aa/a3bb4bd9/7b38c1e1.png"> Истории в наших репозиториях начали отличаться. <img src="http://habrastorage.org/storage/a9c1352a/9d5dc961/99774de2/5ae54129.png"> Не переживайте, скоро увидим, как свести все эти изменения воедино для получения отменной вкусняшки с чипсами и <a href="http://ru.wikipedia.org/wiki/%D0%A5%D0%B0%D0%B1%D0%B0%D0%BD%D0%B5%D1%80%D0%BE">перчиком хабанеро</a>. Роза может продолжать работать без подключения к серверу, делая сколько угодно изменений. Она может фиксировать или откатывать изменения в своем репозитории. Однако настанет момент, когда она решит поделиться своими изменениями с остальными. Она может выполнить команду

hg outgoing

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

hg push

. <img src="http://habrastorage.org/storage/db449ef2/d6b61d93/156b0919/f19dd056.png"> <blockquote>

hg outgoing

отображает список изменений ждущих отправки в текущем репозитории. </blockquote>

hg outgoing

это просто список всех таких изменений в текущем репозитории, которых нет в центральном репозитории. Хорошо, вот Роза проталкивает свои изменения в центральный репозиторий. <img src="http://habrastorage.org/storage/7fce8e5d/56405199/c27ae4af/25722734.png"> И теперь все выглядит так: <img src="http://habrastorage.org/storage/28086fde/fee793f7/af840235/a9751709.png"> После того, как я сходил выпить четвертую чашку <a href="http://ru.wikipedia.org/wiki/%D0%9B%D0%B0%D1%82%D1%82%D0%B5">латте</a> за сегодняшний день, я тоже готов протолкнуть мое изменение про картофельные чипсы. <img src="http://habrastorage.org/storage/66211440/3bef48f3/e7d8fa43/4a17dfb5.png"> ААААА!!! Ошибка! Да, кстати, видите сообщение? То, в котором написано используйте ключ -f для принудительного проталкивания (use push -f to force)? Это ужасный совет. Никогда и ни за что не используйте ключ -f. Вы пожалеете о том, что использовали его. Просто поверьте мне в данный момент. Причина, по которой у Розы получилось протолкнуть изменения, а у меня нет в том, что картофельный чипсы и гуакамоле плохо сочетаются. Шучу, шучу! Просто хотел удостовериться, что вы еще не уснули там. Команда завершилась с ошибкой потому, что каждый из нас сделал изменения, а значит, их нужно слить вместе, и Mercurial знает об этом. Первым делом я заберу все изменения из центрального репозитория, которых у меня еще нет, чтобы произвести слияние (merge). <img src="http://habrastorage.org/storage/cc14316f/6d00f829/c045eaff/b28a5dff.png"> Тут какая-то тарабарщина про +1 голову (+1 heads). Это потому, что мой репозиторий, в котором раньше были аккуратно уложены три изменения, стал двухголовым монстром. На вершине репозитория опасно расположены два разных изменения. Вот как это выглядит: <img src="http://habrastorage.org/storage/d20fe311/841ec62a/25136b20/a75b2b3b.png"> У меня в репозитории теперь обе версии. Вот моя: <img src="http://habrastorage.org/storage/7727aca4/0638daad/bddcb9a2/1cb4c06e.png"> А вот версия Розы: <img src="http://habrastorage.org/storage/ccca055a/4385a92c/1b996f55/8e9755c9.png"> И я должен слить эти версии воедино. К счастью, это просто: <img src="http://habrastorage.org/storage/94ed4e43/6c8c1c1c/f34767ff/9825f25a.png"> Глядите-ка! Команда

hg merge

взяла и объединила обе мои «головы» (изменения на вершине репозитория) в одну. Так как в данном случае мы с Розой изменили разные части файла, то конфликтов при слиянии не было и все прошло без сучка без задоринки. <blockquote>

hg merge

производит слияние (объединение) двух «голов». </blockquote> Мне по-прежнему надо сделать коммит. Это важно. Если бы слияние не удалось, то я всегда мог бы откатиться и попробовать снова. Но, так как слияние было успешным, то я сделаю коммит. После этого я смогу протолкнуть мои изменения в центральный репозиторий. <img src="http://habrastorage.org/storage/2372798e/f0a49c6a/2f49a1ee/75085756.png"> Теперь в центральном репозитории то же, что в моем: <img src="http://habrastorage.org/storage/3301ab87/9868c9ff/9bb6c7ea/acb0e87e.png"> Хорошо, у меня есть изменения Розы и мои собственные изменения, но у Розы пока нет моих изменений. Есть еще один момент, связанный с Розой, о котором я забыл рассказать. Она — доктор. Ага, доктор, который врач. Ну не чудно? Она была главным педиатром в больнице <a href="http://www.mountsinai.org/">Mt. Sinai</a> и получала, наверное, «раз в пять больше, чем этот поганый укурок платит своим тестерам». Никто наверняка не знает, почему она оставила медицину. Остальные тестеры думают, что случилось что-то трагичное. Еще у нее семья была: на ее столе картинка милого десятилетнего ребенка. Но теперь она живет одна, и мы не хотим лезть ей в душу. Розе нужно вытянуть (pull) свежие входящие изменения из репозитория, чтобы получить мои изменения. <img src="http://habrastorage.org/storage/19f31f66/0a623177/f258cc66/5667615b.png"> Готово. Теперь, — вам может показаться это странным, — несмотря на то, что Роза втянула новые изменения в свой репозиторий, эти изменения не находятся в ее рабочем каталоге. <img src="http://habrastorage.org/storage/c8bc0274/0d8008f0/40c44b5b/b92c3101.png"> Видите, Она по-прежнему работает с <a href="http://en.wikipedia.org/wiki/Tortilla_chip">кукурузными чипсами</a>. С кукурузными чипсами! У нее есть мои последние изменения где-то в репозитории… <img src="http://habrastorage.org/storage/37e67e82/67a3e142/e9022010/4fd8cfde.png"> Просто мои изменения не в ее рабочем каталоге. Это потому, что она до сих пор изменяет второй набор изменений. Это можно увидеть, выполнив команду

hg parent

: <img src="http://habrastorage.org/storage/248c9d9e/b3027e43/dee45f23/6063a7e3.png"> <blockquote>

hg parent

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

hg up

без аргументов приведет рабочий каталог к «макушке» (tip), то есть применит все изменения до самого верхнего набора изменений. В данном случае, это четвертый набор изменений: <img src="http://habrastorage.org/storage/06bd58a7/84eba403/73124798/54b38879.png"> Теперь Роза видит самую свежую версию с изменениями от обоих нас. Когда вы работаете в команде, то рабочий процесс будет выглядеть во многом так: <ol> <li>Забрать свежую версию, с которой все работают, если вы давненько этого не делали, выполнив: <ul> <li>hg pull</li> <li>hg up</li> </ul> </li> <li>Внести изменения</li> <li>Зафиксировать изменения (локально)</li> <li>Повторить пункты 2-3 до тех пор, пока у вас не получится хороший код, который вы хотите вывалить на всех остальных</li> <li>Когда вы готовы поделиться, выполнить: <ul> <li>hg pull для получения чужих изменений (если есть)</li> <li>hg merge для слияния этих изменений со своими</li> <li>тестирование! для того, чтобы удостовериться, что при слиянии ничего не попортилось</li> <li>hg commit (для фиксации результата слияния)</li> <li>hg push</li> </ul> </li> </ol> <h5>Проверь себя</h5> Вот все, что вы должны уметь делать на данный момент: <ol> <li>Настроить центральный репозиторий и дать членам команды возможность делать его клоны</li> <li>Проталкивать изменения в центральный репозиторий</li> <li>Вытягивать изменения из центрального репозитория</li> <li>Делать слияние изменений от разных авторов</li> </ol> </html>

Продолжение здесь: Часть 4. Исправляем ошибки

Hg Init: Привыкаем работать в команде. Часть 3.

Anonymous (anonymous@undisclosed.example.com) — 2016-02-16T14:06:35+00:00

scm, mercurial, hg

Hg Init: Привыкаем работать в команде. Часть 3.

    <img src="http://habrastorage.org/storage/eebea7f1/5482efc4/01467053/55589e0f.png" align="left">Это третья часть из серии <b>Hg Init: Учебное пособие по Mercurial</b> от Джоэля Спольски (<a href="http://www.joelonsoftware.com/">Joel Spolsky</a>). Предыдущие части:<br>

hg init

и открыть к нему доступ при помощи

hg serve

hg serve

hg clone

-m

hg push

, которая протолкнет мои изменения из локального в центральный репозиторий: <blockquote>

hg push

hg clone

для создания своей собственной полной копии репозитория.

hg clone

hg log

hg outgoing

hg push

. <img src="http://habrastorage.org/storage/db449ef2/d6b61d93/156b0919/f19dd056.png"> <blockquote>

hg outgoing

отображает список изменений ждущих отправки в текущем репозитории. </blockquote>

hg outgoing

hg merge

hg merge

hg parent

: <img src="http://habrastorage.org/storage/248c9d9e/b3027e43/dee45f23/6063a7e3.png"> <blockquote>

hg parent

hg up

Продолжение здесь: Hg Init: Часть 4. Исправляем ошибки

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

Anonymous (anonymous@undisclosed.example.com) — 2016-02-16T14:07:10+00:00

scm, mercurial, hg

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

    <img src="http://habrastorage.org/storage/eebea7f1/5482efc4/01467053/55589e0f.png" align="left">Это четвертая часть из серии <b>Hg Init: Учебное пособие по Mercurial</b> от Джоэля Спольски (<a href="http://www.joelonsoftware.com/">Joel Spolsky</a>). Предыдущие части:<br>

hg revert

: <img src="http://habrastorage.org/storage/64abc0c1/6b548170/8fb06654/8d15fb91.png"> <blockquote>

hg revert

возвращает файлы к состоянию, зафиксированному в репозитории. </blockquote> Эта команда вернет файлы в именно то состояние, что было у них в момент последнего коммита. Mercurial не любит что-либо удалять, так что вместо того чтобы затереть рецепт на <a href="http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80%D0%BE%D1%81%D1%8F%D1%87%D1%8C%D1%8F_%D0%BB%D0%B0%D1%82%D1%8B%D0%BD%D1%8C">свинском латинском</a>, он переименовал файл: <img src="http://habrastorage.org/storage/6bd1f78e/ff44c2ff/2af58601/3d594470.png"> А что если все зашло слишком далеко и вы уже закоммитили? <img src="http://habrastorage.org/storage/9de936e9/28f4c3ef/539275c3/d981bd2d.png"> Есть команда

hg rollback

, которая спасет вашу шкуру, но только если вы еще не протолкнули (push) ошибочный коммит в другой репозиторий. Эта команда отменяет один коммит. <img src="http://habrastorage.org/storage/25fdbb00/217ac772/0e6e63d8/beaa92be.png"> <blockquote>

hg rollback

отменяет один коммит, при условии, что вы не протолкнули его в другой репозиторий. </blockquote> Представьте, что вы хотите поставить большой эксперимент в свободное время. Ваш босс нанял нового дизайнера, Джима. С тех пор дизайны, которые вы получаете, стали просто абсурдны. В них кислотный зеленый текст, ничего не выровнено (на это есть «художественные» причины, ага) и юзабилити хромает. Вы хотите прийти на работу в выходной и все переделать, но боитесь коммитить свои изменения, так как не уверены на 100%, что ваши идеи лучше, чем у этого рехнувшегося дизайнера. Джим курит траву практически все время с момента пробуждения до момента отхода ко сну. Вы не хотите использовать это против него, да и все думают, что эта привычка никого не касается до тех пор, пока дизайны в порядке. Но всему есть предел. Так ведь? И дизайны у Джима не в порядке, и вообще он дерзкий какой-то. При работе с Mercurial вы можете просто создать клон всего репозитория: <img src="http://habrastorage.org/storage/68c027bf/7ef55f11/c341dc59/60dc90f0.png"> Это не настолько расточительно, как может показаться. Так как в репозиториях recipes и recipes-experiment хранится одно и то же (пока), то Mercurial воспользуется "<a href="http://ru.wikipedia.org/wiki/%D0%96%D1%91%D1%81%D1%82%D0%BA%D0%B0%D1%8F_%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0">жёсткими ссылками</a>" (hard links). А значит, копия репозитория будет создана быстро и не займет много дополнительного места на диске. Теперь можно сделать ряд изменений в экспериментальной ветке: <img src="http://habrastorage.org/storage/96ad9731/6fd2c79f/d458d7b9/235b60bd.png"> Начинаем мой великий эксперимент над рецептом гуакамоле: <img src="http://habrastorage.org/storage/c49c10f0/cfdb23e3/4d84fb94/fa0ded5b.png"> В экспериментальный репозиторий можно коммитить без опасений: <img src="http://habrastorage.org/storage/71deac19/a844b427/b4ed24c9/e60a80d9.png"> Вы можете смело вносить изменения, фиксируя результат когда захотите. Это дает вам всю мощь контроля версий даже для вашего безумного эксперимента, причем никто не пострадает. Если вы решите, что эксперимент не удался, то можете просто удалить весь каталог с экспериментальным репозиторием. Нет репозитория — нет проблемы. Но если все получилось, то вам нужно лишь протолкнуть ваши новые правки: <img src="http://habrastorage.org/storage/01fcf609/6a0e9029/b4787faa/73f02234.png"> И куда же они протолкнулись? <img src="http://habrastorage.org/storage/5b52ac76/64573441/dfe23550/342d9ba9.png"> <blockquote>

hg paths

отображает список известных удаленных (remote) репозиториев. </blockquote> Строчка, начинающаяся с «default», содержит путь к репозиторию, в который

hg push

проталкивает изменения если вы явно не укажете другой репозиторий. Обычно в этой строчке указан путь к репозиторию, с которого вы делали клон. В данном случае это локальный каталог, но в качестве пути может быть и URL. <img src="http://habrastorage.org/storage/f6f677ed/a911d2d6/f822cef7/33993dea.png"> Не забывайте, что проталкивание изменений в этот репозиторий… <img src="http://habrastorage.org/storage/5b3e3e5b/cf6dbd5e/0f29418a/c0738e7e.png"> … не приводит к тому, что изменения появляются в рабочем каталоге. <img src="http://habrastorage.org/storage/742d905e/607cbf55/51688a01/bb5b1f96.png"> <blockquote>

hg parent

отображает набор изменений, находящийся в рабочем каталоге. </blockquote> Видите? Правки про «Queso» в пятом наборе изменений. Но в моем основном репозитории работа остановилась на четвертом наборе изменений. От того, что кто-то протолкнул изменения в репозиторий, рабочий каталог не обновился, и пятый набор изменений в нем не появился. Так что я по-прежнему работаю с четвертым набором изменений. <img src="http://habrastorage.org/storage/81287b1f/9096f4a3/eae68e64/5fe130a5.png"> Если я захочу узнать, что в пятом наборе изменений, то мне нужно будет использовать команду

hg update

: <img src="http://habrastorage.org/storage/023fc2aa/41243289/e94f5f67/35276977.png"> Видите, что произошло? Изменения были получены, но они были после той версии, с которой я работал. Команды

push

pull

просто пересылают изменения между репозиториями. Эти команды не влияют на то, с чем я работаю в данный момент. Сейчас репозитории выглядят так: <img src="http://habrastorage.org/storage/6ebe8da2/5fac7827/7dd53ab1/5a118ca1.png"> Mercurial гибок в вопросах пересылки изменений из репозитория в репозиторий. Можно протолкнуть изменения прямо из экспериментального в центральный репозиторий: <img src="http://habrastorage.org/storage/5b5c8de5/3a4fa941/a7e099f2/bc357932.png"> Так пятый набор изменений был отправлен из экспериментального прямиком в центральный репозиторий. Теперь, если я вернусь в свой основной репозиторий, то увижу, что в нем больше нечего проталкивать! <img src="http://habrastorage.org/storage/bbd0ef75/4601b945/c3774a27/4df5c17c.png"> Это потому, что Mercurial знает, что в центральном репозитории этот (пятый) набор изменений уже откуда-то есть. Это по-настоящему полезно, потому как иначе Mercurial мог бы попытаться применить изменения заново и серьезно запутаться. Дизайнер Джим, после того как ему предложили работу, пообещал приступить к делам сразу же. Однако он не появлялся на работе еще два месяца. Почти все уже забыли и о нем, и о том, что предлагали ему работу, так что когда он весь такой загорелый впервые появился в офисе, честно сказать, никто толком не мог понять, кто он и что вообще происходит. Это было достаточно забавно. Внешность у него типическая. В конце концов, во всем разобрались, но так как он был новеньким, все постеснялись спросить у него, что, черт побери, произошло. И про шрамы и синяки на лице тоже не спросили. Неважно. Просто мы ненавидим этого парня. Иногда случается, что спустя месяцы, вы обнаруживаете, что сделали ошибку. <img src="http://habrastorage.org/storage/deaea912/fe92dd6c/ec887aaa/889f199f.png"> Картофельные чипсы? Чё за..?! Mercurial может изъять старый набор изменений из истории. Mercurial смотрит на набор изменений, определяет обратные действия и изменяет текущий рабочий каталог. Давайте попробуем изъять ту старую ревизию номер 2. <img src="http://habrastorage.org/storage/4667451a/25bdb499/f632481c/2a066f45.png"> Матерь божья, что это было? <img src="http://habrastorage.org/storage/fd39bd64/6a0afc42/b16be42c/96ff7f13.png"> Вообще говоря, времени могло пройти много. Чипсы вообще могли исчезнуть из рецепта. Много всего жуткого могло произойти. А значит, иногда после изъятия ревизии объединить изменения невозможно. В таких случаях вы получите конфликты слияния (merge conflicts), которые вам нужно как-то разрешить. Вот об этом и поговорим в следующей части. <h5>Проверь себя</h5> Вот то, что вы должны уметь делать после прочтения данной части: <ol> <li>Откатить случайные изменения. До того, как они зафиксированы в репозитории, и после.</li> <li>Локально склонировать репозиторий для экспериментов.</li> <li>Проталкивать изменения в разные репозитории.</li> <li>Откатить старую ошибку, которая давным-давно была зафиксирована в репозитории.</li> </ol> </html>

Продолжение здесь: Часть 5. Процесс слияния

Hg. Процесс слияния. Часть 5.

Anonymous (anonymous@undisclosed.example.com) — 2016-02-16T14:07:45+00:00

scm, mercurial, hg

Hg. Процесс слияния. Часть 5.

    <img src="http://habrastorage.org/storage/eebea7f1/5482efc4/01467053/55589e0f.png" align="left">Это пятая часть из серии <b>Hg Init: Учебное пособие по Mercurial</b> от Джоэля Спольски (<a href="http://www.joelonsoftware.com/">Joel Spolsky</a>). Предыдущие части:<br>

<ul> <li><a href="http://docs.mirocow.com/doku.php?id=hg_init:%D1%87%D0%B0%D1%81%D1%82%D1%8C_1._%D0%BF%D0%B5%D1%80%D0%B5%D0%BE%D0%B1%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D0%B5_%D0%B4%D0%BB%D1%8F_%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9_subversion">«Переобучение для пользователей Subversion»</a></li> <li><a href="http://docs.mirocow.com/doku.php?id=hg_init:%D1%87%D0%B0%D1%81%D1%82%D1%8C_2._%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D1%8B_mercurial">«Основы Mercurial»</a></li> <li><a href="http://docs.mirocow.com/doku.php?id=hg_init:%D1%87%D0%B0%D1%81%D1%82%D1%8C_3._%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D1%8B_mercurial">«Привыкаем работать в команде»</a></li> <li><a href="http://docs.mirocow.com/doku.php?id=hg_init:%D1%87%D0%B0%D1%81%D1%82%D1%8C_4._%D0%B8%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D1%8F%D0%B5%D0%BC_%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B8">«Исправляем ошибки»</a></li> </ul> Иногда при слияниях возникают конфликты. Обычно их легко разрешить. В любом случае их надо разрешить, или у вас будет несколько «голов». А кому это нужно? <h4>Часть 5. Процесс слияния</h4> <img src="http://habrastorage.org/storage/640e555c/1cbdb7a6/1c1be8ce/273818dc.png" align="left"> Обеспечение слаженной работы нескольких людей над одним и тем же кодом — это важная функция системы контроля версий. Представьте что и Роза, и я хотим внести изменения в рецепт гуакамоле. Роза работает над качеством авокадо. Перед тем как начать, она обновляет свой рабочий каталог, вытягивая свежие изменения из центрального репозитория. <a name="habracut"></a> <img src="http://habrastorage.org/storage/49492ce5/6d5c159c/0fceb6e4/d1371e41.png"> Теперь небольшая правка: <img src="http://habrastorage.org/storage/1f1b5727/aa9ead27/1baec231/ea75e210.png"> Она фиксирует изменения и проталкивает их в центральный репозиторий: <img src="http://habrastorage.org/storage/eb48ca94/8b8d8084/faf52620/567fe487.png"> В это же время я делаю изменение в другой части файла: <img src="http://habrastorage.org/storage/47aa2eae/b082887d/8f4efdf9/82c8204a.png"> Я могу сделать коммит, но не могу протолкнуть изменения в центральный репозиторий. <img src="http://habrastorage.org/storage/06f7657f/f6e19411/72bbeee1/49613e14.png"> Это, пожалуй, наименее полезное сообщение об ошибке в Mercurial. Лучше было бы так: <img src="http://habrastorage.org/storage/2668f993/5096053c/ca4cc74c/0a1bc81d.png"> Так я и поступлю: <img src="http://habrastorage.org/storage/23989ae6/e098973a/29b71b73/28b63534.png"> Хотите узнать, что за изменения только что были получены? Для этого есть удобный способ — команда

hg log -P .

<img src="http://habrastorage.org/storage/f37baadc/ba0e4f1c/8bb30299/ba53f194.png"> Ну точно, это те изменения, что сделала Роза. И что там с моим репозиторием сейчас? <img src="http://habrastorage.org/storage/590062e4/7361c67f/c7495e4a/0dbc0c0a.png"> У моего репозитория «несколько голов». По сути, мой репозиторий выглядит так: <img src="http://habrastorage.org/storage/3bd32436/06550de1/6c75bfe2/0aae9522.png"> Видите две головы? Они появились, потому что Роза сделала свои изменения, работая с седьмым набором изменений, и я тоже сделал свои изменения, работая с тем же набором. Так что теперь требуется слияние (merge). [Редактор подсказывает, что нельзя использовать пассивный залог] Я должен сделать слияние. <img src="http://habrastorage.org/storage/5621d82f/5d6acbb8/5eb36af3/cff77626.png"> Команда слияния,

hg merge

, взяла две головы и объединила их. После этого она поместила результат в мой рабочий каталог. Она не закоммитила его. Это дает мне шанс проверить, что результат слияния корректен: <img src="http://habrastorage.org/storage/26e1e355/a577e02b/0523977e/f9da5180.png"> Похоже на правду: авокадо сорта Хасс и <a href="http://ru.wikipedia.org/wiki/%D0%A5%D0%B0%D0%BB%D0%B0%D0%BF%D0%B5%D0%BD%D1%8C%D0%BE">перчики халапеньо</a>. Так что я сделаю коммит и протолкну изменения на сервер. <img src="http://habrastorage.org/storage/ae013a30/05787999/a42e347d/30c74efa.png"> Я проталкиваю два набора изменений: мои изменения про халапеньо и результат слияния, который тоже является набором изменений. Обратите внимание на то, что в наших изменениях не было конфликтов, потому что Роза и я работали над разными частями рецепта. Потому слияние было супер-пупер простым. Это наиболее частая ситуация, потому что в большинстве организаций разные программисты работают над разными частями кода. Иногда бывают странные организации, в которых никто не готов стукнуть кулаком по столу и все-таки разделить зоны ответственности. Это может спровоцировать неожиданное и часто необъяснимое чувство грусти среди программистов. Эту ситуацию непросто распознать. Но есть симптомы: программисты закрываются в туалетах, программисты закрываются в серверных, высокая текучесть кадров, звуки сдавленных рыданий в помещении, а также неожиданное повреждение барабанных перепонок из-за многократных выстрелов штурмовой винтовки. НО, даже в самых замечательных организациях с наилучшим руководством конфликты при слиянии иногда случаются, и Mercurial потребует от того, кто делает слияние, разрешить конфликт. Давайте посмотрим как это делается. Для начала… я хочу чтобы Роза была в курсе моих изменений про халапеньо: <img src="http://habrastorage.org/storage/7cdb3d62/986ee692/5d621d00/dee47636.png"> Сейчас мы увидим что случается когда у вас на-сто-я-щий конфликт: мы оба немного накосячим с ингредиентами. Я добавил банан: <img src="http://habrastorage.org/storage/4585d66a/853aff76/0d16a3ca/5cd2a054.png"> И первым зафиксировал изменения: <img src="http://habrastorage.org/storage/7fc22261/c85df119/fbc1b69a/4dc22812.png"> А Роза, господи прости, добавила МАНГО в ТОМ ЖЕ МЕСТЕ рецепта. <img src="http://habrastorage.org/storage/8ed8694b/d5f5a156/dfff95f9/d720b1fe.png"> «Зрелый молодой» манго, я не шучу. <img src="http://habrastorage.org/storage/9b359d09/549796d6/52bb2564/634c9a94.png"> В этот раз я первым зафиксировал изменения, так что теперь Розе придется заниматься слиянием. Ха-ха! <img src="http://habrastorage.org/storage/19d3e459/a1d10cb6/96edf235/f2a72de4.png"> И вдруг, обнаруживается конфликт и выскакивает окошко какой-то программы для разрешения конфликтов со столь страшным интерфейсом, что только матери этой программы он может нравиться. Но программа обычно достаточно неплохо делает то, для чего предназначена, надо только разобраться как она работает. Наиболее распространенной программой для разрешения конфликтов в наше время является KDiff3, так что Роза увидит следующее: <img src="http://habrastorage.org/storage/98500077/99d1eff2/a1de7c3f/c0eadf2d.png"> В программе KDiff3 у вас есть четыре панели. Верхняя левая — это оригинальный файл. Верхняя средняя показывает Розе ее версию файла. Верхняя правая показывает Розе мою версию. Нижняя панель — это редактор, в котором Роза собирает итоговый файл по мере разрешения конфликтов. Разрешать конфликты достаточно просто. Нужно пройтись по всем конфликтам и выбрать каким образом разрешить каждый из них. Роза сошла с ума и решила, что бананово-манговая гуакамоле не так уж плоха: <img src="http://habrastorage.org/storage/4293e69b/330834b3/9a5446e0/48dc158b.png"> Кстати, я говорил вам, что Роза, похоже, кое с кем встречается? Как-то раз ее видели уходящей с работы с парнем, который выглядел примерно как <a href="http://ru.wikipedia.org/wiki/%D0%A4%D1%80%D0%B0%D0%BD%D1%86,_%D0%94%D0%B5%D0%BD%D0%BD%D0%B8%D1%81">Деннис Франц</a>. В таком прекрасном настроении как тогда ее давненько не видели. Роза сохраняет изменения и закрывает KDiff3. <img src="http://habrastorage.org/storage/05f78199/f0a9e7f9/a8d54d4d/a5513301.png"> И конфликт разрешен. Вот что вам стоит запомнить: вы не обязаны проводить слияние, подстраиваясь под чье-либо расписание. Вы можете выполнять

hg pull

когда угодно и, если не хочется сразу же разрешать конфликты, то можете свободно продолжать работать и счастливо коммитить до тех пор, пока не найдете время заняться слиянием. <h5>Проверь себя</h5> Вот то, что вы должны уметь делать после прочтения данной части: <ol> <li>Работать с кодом совместно с другими людьми.</li> <li>Получать их изменения.</li> <li>Проталкивать свои изменения.</li> <li>Разрешать конфликты, которые время от времени случаются.</li> <li>Диагностировать некоторые виды программерской меланхолии.</li> </ol> </html>

Заключительная часть здесь: Часть 6. Архитектура репозиториев

Hg. Архитектура репозиториев. Часть 6.

Anonymous (anonymous@undisclosed.example.com) — 2016-02-16T14:08:50+00:00

scm, mercurial, hg

Hg. Архитектура репозиториев. Часть 6.

    <img src="http://habrastorage.org/storage/eebea7f1/5482efc4/01467053/55589e0f.png" align="left">Это шестая, заключительная часть из серии <b>Hg Init: Учебное пособие по Mercurial</b> от Джоэля Спольски (<a href="http://www.joelonsoftware.com/">Joel Spolsky</a>). Предыдущие части:<br>

<ul> <li><a href="http://habrahabr.ru/blogs/development_tools/108443/">«Переобучение для пользователей Subversion»</a></li> <li><a href="http://habrahabr.ru/blogs/development_tools/108658/">«Основы Mercurial»</a></li> <li><a href="http://habrahabr.ru/blogs/development_tools/108904/">«Привыкаем работать в команде»</a></li> <li><a href="http://habrahabr.ru/blogs/development_tools/109074/">«Исправляем ошибки»</a></li> <li><a href="http://habrahabr.ru/blogs/development_tools/109203/">«Процесс слияния»</a></li> </ul> <img src="http://habrastorage.org/storage/80a00e0e/f27de307/ccce4ca3/7532006e.png" align="left"> Mercurial позволяет очень гибко настроить репозитории. Плюс, так как слияния работают отлично и вы можете на них полагаться, можно иметь особые служебные репозитории в соответствии с требованиями процесса разработки в вашей команде. <h4>Часть 6. Архитектура репозиториев</h4> Наш рецепт становится все лучше: <a name="habracut"></a> <img src="http://habrastorage.org/storage/d68f2d22/b07c1108/357e69d3/6be4c263.png"> Давайте приглядимся к номеру набора изменений: <img src="http://habrastorage.org/storage/b80f7a57/03613f2d/fb95fcea/bb2f8430.png"> Первая часть номера, 13, короткая и удобная. Проблема в том, что… на нее нельзя полагаться! При независимой работе членов команды и осуществлении слияний эти короткие номера могу начать отличаться у разных членов команды: <img src="http://habrastorage.org/storage/a35d59b3/1ed965ee/64cf690c/4e903cb9.png"> Так что на практике я не могу сказать: «Хорошо, давайте выпускать версию, собранную из 13 набора изменений», потому что у сотрудников может быть разное представление о том, что является 13-тым набором. Вот почему есть еще и тот безумный шестнадцатеричный номер. <img src="http://habrastorage.org/storage/75357326/1bf027db/eb83d6fb/73144a39.png"> Этот шестнадцатеричный номер уникален во всех репозиториях и никогда не меняется. То есть я могу сказать людям: «Эй, сегодня релиз! 1b03ab783b17-ый набор изменений!». Согласитесь, было бы неплохо иметь возможность дать этому набору имя? Ну, у вас есть такая возможность. Такое имя называется тег (или таг, от англ. tag). <img src="http://habrastorage.org/storage/29f99fca/dad78d02/617c7ae2/e1015e41.png"> Давайте теперь взглянем на лог: <img src="http://habrastorage.org/storage/e3f5ceba/7ef7ce12/9230375b/fdac5b68.png"> Обратите внимание, что само добавление тега к набору изменений является набором изменений. Этот набор изменений автоматически фиксируется в репозитории (коммитится). Так что теперь каждый раз, когда я хочу сослаться на ту версию кода, что мы выпустили, я могу использовать Version-1.0 вместо 1b03ab783b17. Замдиректора спустился с 31-го этажа для того чтобы поучаствовать в офисной вечеринке по поводу выпуска новой версии и принес ящик достаточно дорогого на вид игристого вина. Стэн немного напился. Ну, не то, чтобы немного. Вообще-то, это было что-то невиданное. Стэн снял рубашку и, показывая всем свои мускулы и солидное пузо, пытался произвести впечатление на дам из отдела маркетинга. Он хвалился: «Я буду подтягиваться на лампах» (у нас в офисе используются длинные лампы дневного света). В общем, он подпрыгнул, схватился за светильник и, конечно же, оторвал его вместе с лампами и потолочной плиткой. Неудивительно, ведь светильник весом в примерно 4,5 килограмма висел на <a href="http://habrastorage.org/storage/6a621ba1/e19ec0a3/07f2e188/fee1837e.jpg">паре проволочек</a>, а вес Стэна как раз в том самом популярном диапазоне 130-135 килограммов. Повсюду было битое стекло и куски звукоизолирующей плитки. Стэн упал прямо на копчик и начал жаловаться, что засудит компанию за небезопасные условия труда. Остальные вернулись на рабочие места для работы над Guac 2.0. <img src="http://habrastorage.org/storage/c9f4e36c/0637f3bf/d472f6a8/c1d4fdea.png"> Коммит: <img src="http://habrastorage.org/storage/0031b86c/94b2ba74/1baa1291/493613a4.png"> Не стоит и говорить, что этот рецепт пока сомнителен. Его не тестировали, к примеру. И тут звонит клиент. «Слишком солёно получается!», скулит клиент. И нет, он не желает подождать выхода версии 2.0 с исправлением ошибки. К счастью, у нас есть тот тег. Я могу использовать

hg up

для перехода к любой версии в репозитории. <img src="http://habrastorage.org/storage/633fedc2/cc2c66c1/cb5d3c8f/42cbc002.png"> Теперь я могу исправить эту тупую проблему с солью: <img src="http://habrastorage.org/storage/6a67553e/093ccf44/d290f910/6956c6f1.png"> Затем: <img src="http://habrastorage.org/storage/efe56ec9/58727a58/94a0e492/e56d5553.png"> Mercurial напоминает мне, что мои действия создали новую голову. Теперь в репозитории две головы: версия 2.0, над которой я недавно работал, и версия, которую я только что закоммитил. <img src="http://habrastorage.org/storage/461735ea/624be09a/a8b26521/af885f2f.png"> В данный момент я могу отдать версию с последними изменениями клиенту, пометить ее как 1.1, и продолжить работать с версией 2.0. <img src="http://habrastorage.org/storage/71bc196d/41345306/1ef4d16e/9ab05419.png"> Но есть одна проблема… исправления про соль отсутствуют в версии 2.0. Как мне это исправить? <img src="http://habrastorage.org/storage/45277523/d4534deb/e6e778b4/f3665feb.png"> <img src="http://habrastorage.org/storage/72edbdf4/50bd8cdd/e08640a9/32196428.png"> Ну вот. Я должен сделать слияние тегов. Это известный баг в Mercurial. Проблема в том, что теги в Mercurial — это просто файл с именем .hgtags, для которого тоже ведется контроль версий. Поэтому время от времени вам нужно вручную делать слияние разных версий файла .hgtags. В такой ситуации ваши действия просты… нужно всегда сохранять ОБЕ версии каждой строки в файле. <img src="http://habrastorage.org/storage/1aa9272a/8bcae15c/b09cb4ec/5242aae8.png"> Описанный выше простой способ перейти к старой, помеченной версии годится, если вам нужно сделать лишь одно маленькое незапланированное изменение в выпущенном коде. Но правда в том, что в большинстве программных проектов такие ситуации возникают постоянно, а у Mercurial есть более надежный способ разобраться с ними. Так что я сейчас отменю все изменения, сделанные после 1.0, верну репозиторий в состояние, которое у него было в момент выпуска 1.0, и затем смогу показать вам модный надежный способ исправлять баги существующих клиентов и параллельно работать над новой версией. <img src="http://habrastorage.org/storage/920e88ad/36225520/5db9dd52/ddf8aa7a.png"> Идея в том, что вместо работы с одним репозиторием мы заведем два репозитория. Один репозиторий назовем stable, а второй — dev. В репозитории stable хранится последняя мажорная версия кода, отправленная клиентам. Каждый раз, когда вам нужно срочно исправить баг, вы делаете это в stable. В нашем примере, все патчи для версии 1.0 попадут в stable. Репозиторий dev — это то место, где ведется разработка следующей мажорной версии, то есть версии 2.0. Как только вышла версия 1.0, я клонирую stable в dev: <img src="http://habrastorage.org/storage/874eef22/a1545d93/a0232e75/95342a96.png"> Теперь у меня два идентичных репозитория: <img src="http://habrastorage.org/storage/6a6b8010/f84d4b0a/78f25f9a/49c5c0bc.png"> Так как история в обоих репозиториях одинакова до 14-го набора изменений включительно, то Mercurial воспользуется "<a href="http://ru.wikipedia.org/wiki/%D0%96%D1%91%D1%81%D1%82%D0%BA%D0%B0%D1%8F_%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B0">жёсткими ссылками</a>" вместо того, чтобы делать две копии на диске. Поэтому операция

hg clone

выполняется быстро и дешево, а значит, вы можете без колебаний делать много-много клонов репозитория. Теперь начнем работать над guac в репозитории dev: <img src="http://habrastorage.org/storage/905ffd18/8d990fe0/40ba5e86/0f957768.png"> И исправим ту проблему с солью в репозитории stable: <img src="http://habrastorage.org/storage/93b7491a/01cd83a3/2f852c5c/aea3d2a8.png"> Я помечу эту версию и выпущу ее как 1.1: <img src="http://habrastorage.org/storage/d5ca3f6d/5a1321e9/abf90da0/35c32879.png"> Теперь, время от времени, нам нужно втягивать изменения из stable в dev: <img src="http://habrastorage.org/storage/b8a8ffd4/dc5c701b/3b95d143/21255c0d.png"> Вот что мы только что сделали: <img src="http://habrastorage.org/storage/53bf82a1/b62b1a9f/ee8752b7/398d919f.png"> И если вы можете понять, что нарисовано на этой безумной картинке, то с пониманием Mercurial у вас больше проблем не будет. Суть в том, что в репозиторий stable попадают только исправления ошибок, а в репозитории dev хранится новый код и проводятся слияния с исправлениями ошибок. Есть и другие применения нескольким репозиториям. <ul> <li> Вы можете настроить командные репозитории, в которых несколько человек вместе работают над каким-то новым функционалом. Когда они закончат и все сделанное будет работать правильно, вы протолкнете изменения из командного репозитория в главный репозиторий, и все увидят эти изменения. </li> <li> Вы можете настроить репозиторий для тестеров. Вместо того чтобы сразу проталкивать изменения в главный репозиторий, вы будете проталкивать изменения в репозиторий тестеров. Тестеры проверят изменения и когда (и если) изменения будут одобрены, вы сможете протолкнуть изменения из репозитория тестеров в главный репозиторий. При таком подходе главный репозиторий всегда будет содержать протестированный код. </li> <li> Так как у каждого разработчика свой репозиторий, то вы можете вытягивать на пробу экспериментальные изменения из репозитория товарища, не влияя на работу остальной команды. </li> </ul> В больших сложно устроенных организациях вы можете комбинировать эти техники и настраивать цепочки репозиториев, вытягивающих изменения друг из друга. По мере того, как какой-то функционал проходит этапы тестирования и интеграции, он втягивается в репозитории по цепочке до тех пор, пока, наконец, не окажется в главном репозитории, хранящем код, который получают клиенты: <img src="http://habrastorage.org/storage/aa0f38ff/e5a593c6/0470c7bd/89c7c3d4.png"> <h5>Проверь себя</h5> Вот то, что вы должны уметь делать после прочтения данной части: <ol> <li>Помечать старые версии и возвращаться к ним.</li> <li>Организовывать работу команды с двумя репозиториями (stable и dev).</li> </ol> Что ж, так получилось, что мы дошли до конца пособия. Я даже близко не подобрался к тому, чтобы описать все возможности Mercurial, но есть достаточное число материалов для углубленного изучения. Есть <a href="http://hgbook.red-bean.com/">книга</a>, которая описывает все крайне подробно. И если у вас есть какие-либо вопросы, то я приглашаю вас на сайт <a href="http://kiln.stackexchange.com/">Kiln Knowledge Exchange</a> (это как <a href="http://stackoverflow.com/">StackOverflow</a>, только для Kiln, и вопросы про Mercurial более чем приветствуются на этом сайте). </html>

HG - Mercurial

Anonymous (anonymous@undisclosed.example.com) — 2011-10-10T15:05:34+00:00

HG - Mercurial

Основные команды

Clone a project and push changes

$ hg clone http://selenic.com/repo/hello
$ cd hello
$ (edit files)
$ hg add (new files)
$ hg commit -m 'My changes'
$ hg push

Create a project and commit

$ hg init (project-directory)
$ cd (project-directory)
$ (add some files)
$ hg add
$ hg commit -m 'Initial commit'