Введение в Mercurial. Часть 2. Основы работы

Продолжаю писать и постить цикл статей про распределенную систему контроля версий Mercurial. Первая часть находится здесь. В этой части рассказа о распределенной системе контроля версий Mercurial речь пойдёт об основных командах, используемых при работе с репозиториями. Статья покрывает начальный уровень взаимодействия с Mercurial, и подразумевает, что у читающего есть некоторые навыки взаимодействия с централизованными системами контроля версий, например, Subversion. Все примеры в статье относятся к работе с Mercurial в unix-подобных системах, при этом для работы в Windows потребуется лишь минимальная адаптация.

Основные сведения о ревизиях в Mercurial

Как и в большистве существующих систем контроля версий, центральным понятием Mercurial являетя ревизия, которая здесь называется changeset. В связи со спецификой распределенных систем контроля версий невозможно выдать каждой ревизии её номер, поскольку не получится гарантировать его уникальность среди всех существующих репозиториев. Однако  каждая ревизия все таки имеет уникальный идентификатор, в случае Mercurial это 40-значный sha1-хеш, который учитывает все параметры ревизии. Таким образом, у каждой новой ревизии в любом удаленном репозитории будет свой уникальный идентификатор. Использование подобной нумерации ревизий немного пугает начинающих пользователей, особенно переходящих на Mercurial с svn, однако ничего страшного в них нет, и использование тех или иных идентификаторов это просто дело привычки.

Начало работы

Вся работа с системой котроля версий Mercurial происходит с помощью команды hg, и во всех постах посвященных работе непосредственно с Mercurial, я буду приводить именно консольные команды, и консольные способы работы. Безусловно есть и вполне нормальные GUI-клиенты, однако освоение лучше начинать именно с консоли, чтобы лучше понять как именно все работает, и каковы логические и алгоритмические основы взаимодействия с этой системой контроля версий.

Работа с этой системой контроля версий, как, впрочем, и со всеми остальными, начинается с создания репозитория в пустом каталоге файловой системы. Для этого перейдём в выбранный каталог, пусть это будет ~/repos/hgproject, и скажем:

> hg init

По команде «hg init» Mercurial создает репозиторий в текущем каталоге. Если посмотреть на результат работы — мы увидим  каталог «.hg», в которой собственно и хранится вся история работы над проектом.

В принципе, рабочую копию можно хранить в той же папке, где был создан репозиторий, но поскольку мы собираемся знакомится с системой контроля версий, причем с распределенной, то будет лучше создать некое подобие обычной структуры работы над проектом. Для этого создадим каталог, в котором будет располагаться наш проект и перейдем в него, пусть это будет ~/projects.

Теперь нужно получить данные для начала работы над проектом. В общем случае это будет все содержимое некоторого репозитория расположенного где-то на сервере. Для этого перейдем в ~/projects и скомандуем:

> hg clone ~/repos/hgproject

По команде «hg clone» Mercurial «клонирует» репозиторий расположенный по указанному адресу в текущий каталог. При этом к вам попадает именно репозиторий, то есть хранилище, содержащее всю существующую историю изменений, что сильно отличает операцию клонирования от того же checkout в Subversion. Таким образом, у нас уже имеется два репозитория — то есть мы локально получили именно распределенную систему контроля версий. Взаимодействие может происходить с любым имеющимся репозиторием, так как они все равноценны, однако мы назовем репозиторий в каталоге ~/repos/hgproject "центральным", то есть введем конвенцию на взаимодействие с системой. Практически в любом случае работы в команде без подобных конвенций не обойтись.

Работа с локальным репозиторием

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

>hg status
? readme.txt
Mercurial ответил, что он видит файл readme.txt, при этом этот файл пока не находится в системе контроля версий (символ «?» слева от имени файла). По команде status Mercurial выводит состояние рабочей копии в сравнении с состоянием локального репозитория. Для того, чтобы сказать Mercurial, что его необходимо версионировать скажем:

> hg add
adding readme.txt

И ещё раз:

> hg status
A readme.txt

Видим, что слева от имени файла появился символ «А», который означает что файл readme.txt будет добавлен в систему контроля версий при следующем коммите, который мы сейчас и сделаем:

>hg commit

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

>hg log
changeset:   0:8fae369766e9
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 08:58:01 2009 +0300
summary:     Файл readme.txt добавлен в репозиторий

Разберем, что Mercurial выдал в этом сообщении. Changeset — это и есть номер ревизии, который состоит из двух частей: виртуального номера ревизии(записан до «:») и идентификатора (sha1-хеша). Виртуальный номер ревизии призван облегчить жизнь пользователям, и все-таки ввести в эту систему некоторую нумерацию ревизий. Но, как показывает практика использовать этот номер для однозначной идентификации нельзя, так как может привести к путанице в понимании происходящего в репозиториях. Обычно для однозначной идентификации версии достаточно 4-5 шестнадцатеричных цифр идентификатора. Следующей строкой идёт «tag: tip», вообще говоря tip — это обозначение последней ревизии, хотя выбирается это обозначение в различных случаях по различным принципам, в дальнейшем, когда будем рассматривать организацию ветвлений этот момент исследуем более подробно. Значение следующих строк очевидно, и нет необходимости их как-либо комментировать.

Обмен с удаленными репозиториями

А теперь вспомним, что у нас есть ещё некий «центральный» репозиторий, через который, по идее будет происходить взаимодействие с другими членами команды разработки. При этом выполненный коммит был локальным, то есть история изменений была сохранена только в вашем локальном репозитории. Для того, чтобы передать изменения в репозиторий расположенный в ~/repos/hgproject выполним:

> hg push
pushing to ~/repos/hgproject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

После выполнения этой команды все изменения зафиксированные в локальном репозитории были зафиксированы также и в удаленном. Теперь склонируем репозиторий ещё раз, и посмотрим как происходит обмен ревизиями в Mercurial. Создадим новый каталог ~/projects/hgproj_clone, и склонируем в него наш удаленный репозиторий:

>hg clone ~/repos/hgproject ~/projects/hgproj_clone
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

И уже во вновь склонированном репозитории создадим файл other.txt с помощью вашего любимого текстового редактора.  И снова повторим операции описанные выше:

> hg status
? other.txt
> hg add
adding other.txt
> hg commit
> hg log
changeset:   1:270e49e72f4b
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории


changeset:   0:8fae369766e9
user:        mike@mike-notebook
date:        Fri Nov 27 08:58:01 2009 +0300
summary:     Файл readme.txt добавлен в репозиторий

Видим, что в новом репозитории отражени как изменения сделанные локально, так и изменения сделанные в удаленном репозитории, которые мы ранее отправляли командой push. Теперь воспользуемся еще одной командой:

> hg outgoing
comparing with ~/repos/hgproject
searching for changes
changeset:   1:270e49e72f4b
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории

По команде hg outgoing Mercurial выводит список ревизий которые есть в вашем локальном репозитории, но которых нет в «центральном». Отправим появившиеся ревизии в «центральный» репозиторий известным нам способом:

> hg push
pushing to ~/repos/hgproject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

Итак, в «центральном репозитории две ревизии. Теперь научимся забирать обновления из центрального репозитория. Для этого перейдём в каталог с первым клоном, то есть в ~/projects/hgproject, и скажем:

> hg incoming
comparing with ~/repos/hgproject
searching for changes
changeset:   1:270e49e72f4b
tag:         tip
user:        mike@mike-notebook
date:        Fri Nov 27 10:39:35 2009 +0300
summary:     Записан файл other.txt в другом репозитории

Команда «hg incoming» выдает список ревизий, которые есть в удаленном репозитории, но отсутствуют в локальном. А затем получим эти ревизии, для чего скажем:

> hg pull
pulling from ~/repos/hgproject
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)

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

> hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Если посмотреть на состояние рабочей копии, то она соответствует состоянию рабочей копии в репозитории ~/projects/hgproj_clone, а состояние хранилища во всех трех репозиториях одинаково.

Ну и напоследок просто необходимо сказать о ещё одной команде. «hg help», как вы уже, наверное, догадались выводит некоторый набор подсказок по работе с утилитами Mercurial. А при использовании в виде «hg help [command]» выводит подсказку о приемах работы с указанной командой. Причем это именно краткая подсказка, если вам требуется подробное описание, то лучше всего обратиться к документации, которая имеется в абсолютно свободном доступе и вполне неплохого качества.

Итак мы познакомились с основными приемами и командами работы с распределенной системой контроля версий Mercurial. Главным отличием, проявившихся на данном этапе, от централизованных систем контроля версий является наличие полной копии всего репозитория у каждого пользователя, что приводит к двухступенчатой системе взаимодействия с хранилищами (commit-push/pull-update). Такая двухступенчатая система требует некоторого привыкания, однако она вполне понятна и логична, и, на самом деле, достаточно проста в использовании. На этом я заканчиваю этот раздел. В следующем разделе мы рассмотрим наиболее интересные аспекты взаимодействия с Mercurial, а именно ветвления (branching) и слияния (merging).

Документация Django в chm и pdf формате

Нарыл сегодня документацию для django, да и не только, для того чтобы использовать на ноуте. У меня часто нет интернета на ноуте, и я далеко не все помню из документации, что вполне естественно. А Django-book не совсем нравится, там не все есть, в документации которую рекомендуют использовать на сайте чёрт ногу сломит - всё таки 21 век, а там txt файлы. Вот, малец погуглив, накопал тут.

Введение в Mercurial. Часть 1. Распределенные системы контроля версий (DVCS).

Здравствуйте, уважаемые!

Решил написать развернутый цикл статей про Мерк, так как судя по общению с товарищами - как то не очень народ его принимает. Вот буду делиться своим опытом и познаниями. Будет несколько статей, в одну все естественно не влезет. Сегодня просто про распределенные системы контроля версий. Что это и с чем едят.

Думаю что с классическими централизованными системами контроля версий (Subversion, CVS) знакомы уже почти все - есть выделенное специальное хранилище называемое репозиторий, в котором хранятся исходники некоторого проекта, и вся история изменений. И вот к этому хранилищу обращаются попеременно все работающие над проектом.

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

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

И вот появилась немного более сложная концепция - распределенные системы. Давайте посмотрим на локальную копию svn'a. при выполнении чекаута - у нас в каждом каталоге находится .svn - каталог, в котором хранится копия из репозитория. То есть, в снятом чекаутом наборе каталогов и файлов приходит и точная копия внешнего репозитория. Именно этот принцип и эксплуатируется нещадным образом в распределенных системах - у каждого пользователя есть свой локальный репозиторий, причем вовсе необязательно один. При этом то, что в практике svn назвается коммитом и апдейтом выполняется в свой локальный репозиторий.

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

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

Смотря на такую структуру, возможность локальных коммитов, возможность синхронизации состояния репозитория с кем угодно создается ощущение, что исходники превратятся в кашу, и на определенном этапе, причем совсем недалеком от начала, уже невозможно будет как-то получить адекватное их состояние. На самом деле все не так страшно. Мощнейшей вещью распределенных систем контроля версий - является ветвление. При этом это не ветвление Subversion, это действительно настоящее, удобное и понятное ветвление и слияние. В DVCS, ну по крайней мере в Mercurial (хотя догадываюсь что и в Git и в Bazaar) ветвление это повседневная операция, это в принципе основа контроля версий в данном случае. И реализована она абсюлютно логично и понятно, и действительно проста в использовании.

Для меня решающим фактором при принятии решения о переходе на Mercurial стали именно локальные коммиты (у меня не всегда есть доступ к интернету, а иногда возникает необходимость что-то закоммитить) и настолько мощная поддержка ветвления. Но уже после перехода я был немало удивлен скоростью работы с репозиториями, эквивалент checkout работает очень быстро даже на сверхбольших репозиториях, commit и update - это моментальные операции, действительно моментальные.

Как работать со всем этим хозяйством я буду постепенно писать в следующих постах. Сегодня этакое начало. Следующий пост будет как раз про основы работы с Mercurial. Для тех кто знаком с Subversion не составит труда сделать первые несколько шагов в этом направлении.

Продолжение. Часть 2. Основы работы.

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

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

После часа гугленья нашлось одно решение, которое отвечало всем требованиям - использовать Apache в связке с Mercurial, при помощи hgwebdir.cgi из стандартного комплекта Mercurial. Итак, предположим что на сервере стоит Apache2 и Mercurial. Если этого нет, то нетрудно воспользоваться apt-get (у меня на серваке Debian), или пакетным менеджером своей системы. Отмечу только, что для выполнения всех требований нужна версия Mercurial не меньше 1.2.1, так как только в этой версии была исправлена ошибка, которая не позволяла разделять права на чтение различных репозиториев стандартными средствами.

Итак, основные задачи, которые предстоит решить:

1. Настроить Apache

2. Настроить hgwebdir.cgi

3. Создать и настроить репозиторий

 Поехали с начала. Я разместил корневую папку репозитория в папке /home/mike/www-data/hg/. Чтобы не путаться я на сервере все собственные данные размещаю у себя в домашней папке. В конфиг соответствующего виртуалхоста добавляем описание:

Alias /hg "/home/mike/www-data/hg"
  <Directory "/home/mike/www-data/hg/">
     Order allow,deny
     Allow from all
     AllowOverride All
     Options ExecCGI FollowSymLinks
     AddHandler cgi-script .cgi
  </Directory >

В данном случае предполагается, что все репозитории будут доступны по ссылкам вида http://[домен]/hg/[репозиторий]. AllowOverride необходим для возможности использования .htaccess файла, далее он потребуется. Создаем в каталоге /home/mike/www-data/hg/ файл .htaccess примерно такого содержания:

RewriteEngine On
RewriteBase /hg
RewriteRule ^$ hgwebdir.cgi  [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) hgwebdir.cgi/$1  [QSA,L]

AuthUserFile /home/mike/www-data/hg/htpasswd_hgstore
AuthGroupFile /dev/null
AuthName "HgRepo"
AuthType Basic
Require valid-user

Аутентификацию организуем срествами HTTP, логины и пароли будут храниться в файле /home/mike/www-data/hg/htpasswd_hgstore, как и написано в .htaccess. А в первой части указаны директивы для mod_rewrite (который естественно нужно подключить), которые позволяют получить красивые урлы вида http://[домен]/hg/[репозиторий], без указания hgwebdir.cgi. Правда описанный выше способ имеет свои недостатки - поле [репозиторий] в url не может совпадать с именем каталога на диске.

Идем дальше. В папку /home/mike/www-data/hg/ копируем файлик hgwebdir.cgi (в Debian он находится в /usr/share/doc/mercurial/examples/), и разрешаем ему выполняться:

chmod +x hgwebdir.cgi

Создаем в этом же каталоге файл hgweb.config, в котором прописываем следующее:

[paths]
test = repo_test

[web]
baseurl = /hg

Главное здесь - секция [paths]. В ней прописываются соответствия урлов и репозиториев на диске в виде URL = /path/to/repo, где /path/to/repo считается от текущего по отношению к hgweb.config каталога, а URL - от алиаса /hg/.

Нам потребуется ещё один файлик, а именно hgrc, который тоже создаем в каталоге с hgwebdir.cgi, и в этот самый hgrc вписываем:

[web]
#allow_push = *
#allow_read = *
push_ssl = false
contact = Mike Girkin
description = Get our elephants
allow_archive = bz2 gz zip
style = gitweb

Это заготовка для hgrc в каждом из репозиториев. Осталось дело за малым - создаем репозиторий, и копируем заготовку hgrc по месту:

mkdir repo_test
cd repo_test
hg init
cp ../hgrc repo_test/.hg/

Осталось только создать файлик с паролями htpasswd_hgstore с помощью утилиты htpasswd, и вбить в него нужное количество пользователей и паролей. Ограничить доступ на чтение/запись можно с помощью директив allow_read/allow_push в файлах hgrc лежащих в каждом из репозиториев, например:

allow_read = pupkin petrov sidorov
allow_push = petrov

Обращаю внимание, что в директивах allow_read/allow_push используются те логины, которые забиваются в htpasswd_hgstore, и используются для аутентификации клиентов. Для того, чтобы открыть доступ всем аутентифицировавшимся пользователям пишем allow_read = * или allow_push = *, соответственно.

И последнее, что нельзя забыть сделать, это поменять владельца для всей ~/www-data/hg/ (у меня Apache выполняется от имени www-data:www-data):

chown -R www-data:www-data ~/www-data/hg

На этом, для первого репозитория все настроено, и он должен быть доступен (в данном случае по ссылке http://[домен]/hg/test/, при этом он доступен как для утилиты hg и клиентов по этому url, так и через браузер, хотя необходимость последнего очень спорна.

Чтобы добавить новый репоиторий необходимо выполнить следующее:

1. Создать каталог (mkdir repo_new)

2. Прописать в hgweb.config в секцию [paths] соответсвие путей (new = repo_new)

3. Скопировать hgrc в repo_new/.hg/

4. Прописать во внутренний hgrc пользователей, которым разрешены операции над репозиторием

5. Изменить владельца на www-data (chown -R www-data:www-data repo_new)

На этом все. Спасибо за внимание ;)

Используем Backports в Debian Lenny

Backports - это проект по адаптации свежих версий софта для стабильных дистрибутивов Debian. Необходимость в таком переносе объясняется тем, что Debian отличается достаточно длительным релиз-циклом, и софт стабильной ветки сильно устаревает до момента релиза нового дистрибутива.

Давиче мне вот понадобился Mercurial с версией 1.2.1 или позднее, а в репозиториях Lenny только 1.0. Вот и решил написать небольшой пост про подключение и использование проекта backports к Debian Lenny.

1. Добавляем в /etc/apt/sources.list ссылку на репозиторий Backports:

deb http://www.backports.org/debian lenny-backports main contrib non-free

2. Обновляем информацию о пакетах:

apt-get update

3. Поскольку все пакеты из этого репозитория имеют минимальный приоритет, то для того, чтобы поставить пакет из backports, например тот же mercurial, нужно воспользоваться командой:

apt-get -t lenny-backports install mercurial

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

apt-get install debian-backports-keyring

Всё. Можем ставить требуемые компоненты с версией значительно более близкой к актуальной.