программирование

Распределенная
система
контроля
версий Bazaar

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

От централизованных
систем к распределенным
Рассмотрим, что сейчас происходит
в области систем контроля версий с от-
крытым исходным кодом. Пока это мо-
жет быть не так очевидно, но просмат-
ривается постепенный рост количест-
ва распределенных систем и идет яв-
ное движение в эту сторону. Например,
из централизованных систем боль-
шинство могут назвать следующие:
n CVS (http://www.nongnu.org/cvs) –
постепенно исчезающая, но все
еще популярная система, разрабо-
танная поверх формата RCS фай-
лов;
n S ubve rsion (ht tp: //subversion.
tigris.org) – на данный момент на-
иболее популярная централизо-
ванная система контроля вер-
сий, изначально разработанная
как «лучший CVS» и в итоге испра-
вившая многие ошибки в дизайне
CVS;

70
 программмирование
А что же распределенные системы? трального хранилища версий – репози- каждого изменения, чтобы избежать
Вот наиболее популярные и активно тория. В случае распределенных сис- конфликтов и ошибок. Для распреде-
развивающиеся системы: тем набор версий может быть полно- ленных систем контроля версий вет-
n Git (http://git-scm.com) – распре- стью или частично распределен между ки разработки являются одной из ос-
деленная система контроля вер- различными хранилищами, в том чис- новополагающих концепций – в боль-
сий, разработанная Линусом Тор- ле и удаленными. шинстве случаев каждая копия хра-
вальдсом. Изначально Git пред- Такая модель отлично вписывает- нилища версий является веткой раз-
назначалась для использования ся в работу распределенных команд, работки.
в процессе разработки ядра Linux, например, распределенной по все- Таким образом, механизм объеди-
но позже стала использоваться му миру команды разработчиков, ра- нения изменений с одной ветки на дру-
и во многих других проектах – та- ботающих над одним проектом с от- гую в случае распределенных систем
ких, как, например, X.org и Ruby on крытым исходным кодом. Разработ- является одним из основных, что поз-
Rails. На данный момент Git явля- чик такой команды может скачать се- воляет пользователям прикладывать
ется самой быстрой распределен- бе всю информацию по версиям и пос- меньше усилий при пользовании сис-
ной системой, использующей са- ле этого работать только на локаль- темой.
мое компактное хранилище реви- ной машине.
зий. Но в то же время для пользо- Как только будет достигнут резуль- Основные концепции
вателей, переходящих, например, тат одного из этапов работы, измене- Bazaar
с Subversion интерфейс Git может ния могут быть залиты в один из цен- Итак, начнем ближе рассматривать
показаться сложным; тральных репозиториев или опублико- Bazaar. На момент написания этой ста-
n Mercurial (http://www.selenic.com/ ваны для просмотра на сайте разра- тьи последняя версия Bazaar 1.6.
mercurial) – распределенная сис- ботчика или в почтовой рассылке. Но прежде чем рассматривать ра-
тема, написанная на языке Python Другие участники проекта, в свою боту с этой системой контроля версий,
с несколькими расширениями очередь, смогут обновить свою копию сначала обратим внимание на основ-
на C. Из использующих Mercurial хранилища версий новыми изменени- ные концепции, лежащие в ее основе.
проектов можно назвать такие, ями или попробовать опубликованные Если эти термины уже знакомы вам
как Mozilla и MoinMoin. изменения на отдельной, тестовой вет- по централизованным системам, они
n Bazaar (http://bazaar-vcs.org) – сис- ке разработки. могут иметь немного другое значение
тема, разработка которой поддер- К сожалению, без хорошей орга- в приложении к распределенной сис-
живается компанией Canonical – низации проекта отсутствие одного теме Bazaar, и их понимание важно
известной своими дистрибутивом центрального хранилища может быть для дальнейшего рассмотрения.
Ubuntu и сайтом https://launchpad.net. минусом распределенных систем. Ес- n Ревизия – это сохраненное состоя-
Система в основном написана ли в случае централизованных сис- ние файлов и директорий, включая
на языке Python и используется тем всегда есть один общий репози- их содержимое и иерархию в задан-
такими проектами, как, например, торий, откуда можно получить послед- ный момент времени. С ревизией
MySQL и Drupal. нюю версию проекта, то в случае рас- также связана мета-информация,
пределенных систем нужно организа- например:
Рассмотрим одну из наиболее гиб- ционно решить, какая из веток проек-  автор изменения;
ких, на мой взгляд, распределенных та будет основной.  дата изменения;
систем контроля версий – Bazaar. Почему распределенная система  комментарий, связанный с из-
Одним из примеров гибкости Bazaar контроля версий может быть интерес- менением;
может служить возможность использо- на кому-то, кто уже использует цен-  родительские ревизии, от кото-
вания как централизованной модели, трализованную систему – такую как рых произведена данная реви-
так и распределенной и даже смешива- Subversion? зия.
ние этих моделей контроля версий. Любая работа подразумевает при-
Даже если вы не согласны со мной нятие решений, и в большинстве слу- После создания, ревизии не ме-
по вопросу выбора конкретной сис- чаев необходимо пробовать различ- няются и могут быть идентифици-
темы, эта статья поможет вам понять ные варианты: при работе с система- рованы глобально уникальным но-
общие принципы работы распреде- ми контроля версий для рассмотрения мером ревизии (revision-id), напри-
ленных систем и затем остановить различных вариантов и работы над мер таким: «pqm@pqm.ubuntu.com-
свой выбор на одной из перечислен- большими изменениями служат вет- 20071129184101-u9506rihe4zbzyyz».
ных выше. ки разработки. Идентификаторы ревизий созда-
И хотя это естественная концепция, ются в момент фиксации (commit) из-
Зачем нужны пользоваться ею в Subversion непрос- менений или в момент импорта реви-
распределенные то. Тем более все усложняется в слу- зий из других систем. Идентификато-
системы? чае множественных последовательных ры ревизий необходимы для функцио-
Как следует из названия, одна из ос- объединений с одной ветки на другую – нирования системы, но вряд ли кто-
новных идей распределенных систем – в этом случае нужно безошибочно ука- то сможет использовать идентифика-
это отсутствие четко выделенного цен- зывать начальные и конечные версии тор такого типа в разговоре. Специ-

№9, сентябрь 2008 71

 программирование
ально для упрощения идентификации Такое разделение концепций позво- bzr version
ревизий разработаны специфичные ляет более гибко использовать Bazaar,
для ветки номера ревизий. в том числе и как централизованную В ответ будет выведена текущая
Номера ревизий генерируются систему. версия Bazaar, пути используемых сис-
«на лету» в момент исполнения команд Рассмотрим набор сценариев, в ос- темой файлов и директорий, а также
и представляют собой последователь- нове которых лежат описанные выше лицензионная информация (Bazaar ис-
но увеличивающийся номер. Таким об- концепции: пользует GPL2). Для получения спис-
разом первая ревизия имеет номер 1, n Ра з д е л я е м ы е р е п о з и т о р и и ка основных команд можно использо-
следующая за ней, более поздняя, ре- (Shared repositories) – в этом слу- вать команду help:
визия – номер 2 и так далее. При объ- чае рабочее дерево и ветка нахо-
единении изменений с других веток дятся в одной директории, но ре- bzr help
номер ревизии представляется тремя позиторий находится на одну ди-
числами, разделенными точками (на- ректорию выше, что позволяет После команды help можно указы-
пример: 3112.1.5): хранить информацию о ревизиях вать любую другую команду, по кото-
1. Номер ревизии для данной ветки, только в одном месте. Такой сце- рой нужно получить подробную инфор-
от которой были произведены объ- нарий позволяет не тратить мес- мацию, например:
единенные изменения. то на полные копии ревизий, если
2. Порядковый номер (счетчик) объ- ветки, находящиеся под репози- bzr help version
единенной ветки. Так как объеди- торием, отличаются незначитель-
нение может затрагивать сразу не- но, например, относятся к одному Или можно вывести все коман-
сколько веток, этот номер служит проекту. ды Bazaar, в том числе и определен-
их счетчиком. n Легковесные рабочие копии ные подключаемыми модулями, ко-
3. Порядковый номер ревизии с мо- (Lightweight checkouts) – ветка мандой:
мента создания объединяемой и рабочее дерево находятся в раз-
ветки. ных местах. Этот сценарий похож bzr help commands
на использование централизован-
n Рабочее дерево – это директо- ной системы контроля версий, ког- Первое, что нужно сделать перед
рия под контролем версий, содер- да удаленный репозиторий хра- началом работы  Bazaar, это указать
жащая файлы, которые может ре- нит всю информацию о ревизиях, свое имя и e-mail, которыми будут под-
дактировать пользователь. Рабо- а рабочая копия представляет со- писываться все ревизии. Это делается
чее дерево ассоциировано с веткой. бой только рабочие файлы и ди- командой whoami, например:
Многие из команд Bazaar использу- ректории.
ют рабочее дерево для своей рабо- bzr whoami "John Doe <john@nowhere>"
ты. Например, команда commit (за- Мы рассмотрели все основные кон-
фиксировать изменения) создает цепции, лежащие в основе Bazaar, и те- Эта же команда без параметров
новую ревизию на основе текуще- перь можно приступать к изучению ин- выводит текущее установленное имя:
го состояния рабочего дерева. терфейса командной строки.
n Ветка – в простейшем случае это bzr whoami
упорядоченная серия ревизий, Начинаем работать John Doe <john@nowhere>
где последняя ревизия называ- с Bazaar
ется верхушкой. Ветки могут раз- Во многих UNIX-совместимых опера- Если вы хотите использовать раз-
деляться на несколько веток и за- ционных системах Bazaar может быть ные имена для разных веток, то мож-
тем, позже, объединяться обратно, установлен штатными средствами сис- но воспользоваться опцией --branch
формируя граф ревизий. При этом темы. Для Windows и других ОС, в ко- для установки имени только для теку-
в рамках ветки может быть основ- торых Bazaar недоступен для установ- щей ветки:
ная линия разработки, ревизии ки штатными средствами, его можно
в которой помечаются обычны- скачать с официального сайта: http:// bzr whoami --branch ↵
"John Doe <john@nowhere>"
ми номерами ревизий. Также вет- bazaar-vcs.org/Download.
ка может иметь другие линии раз- Хотя для Bazaar есть графичес- Конфигурационные файлы Bazaar
работки, помечаемые номерами кие интерфейсы, которые также мо- хранятся в директории $HOME/.bazaar
ревизий через точку, как описано гут быть установлены, и вместе с ос- для UNIX-подобных операционных сис-
выше. новной программой мы будем рассмат- тем и в директории C:\Documents and
n Репозиторий – это хранилище ре- ривать только интерфейс командной Settings\<username>\Application Data\
визий. Обычно ветка имеет свой строки, являющийся основным интер- Bazaar\2.0 для Windows. В этой дирек-
собственный репозиторий, но так- фейсом работы с Bazaar. тории хранятся три основных файла
же несколько веток могут раз- Интерфейс командной строки конфигурации:
делять один репозиторий, чтобы представлен командой bzr, и первое, n bazaar.conf – описывает конфигу-
уменьшить используемое ветками что можно сделать, это проверить ус- рационные параметры по умолча-
место на диске. тановку следующей командой: нию;

72
 программмирование
n locations.conf – описывает конфигурационные пара- ки. Если требуется зафиксировать только отдельную ди-
метры для отдельных веток; ректорию или набор файлов, их можно указать вслед за ко-
n authentication.conf – описывает идентификационную мандой, как здесь:
информацию для доступа к удаленным серверам.
bzr commit -m "Изменения" README.txt src
Каждая ветка также может содержать файл конфигу-
рации, в этом случае он находится в каталоге .bzr/branch/ Если при создании нового проекта планируется созда-
branch.conf внутри ветки. вать несколько локальных веток, то можно воспользовать-
После того, как мы настроили свое имя и e‑mail командой ся описанным выше разделяемым репозиторием для эко-
whoami, эта информация записывается в файл bazaar.conf, номии места:
и в простейшем случае он будет выглядеть так:
$ bzr init-repo repo
$ cd repo
[DEFAULT] $ bzr init trunk
emai = John Doe <john@nowhere> $ cd trunk
Создание файлов
Работаем самостоятельно $ bzr add
Даже если вы работаете в команде, в какой-то момент $ bzr commit -m "Испортирование проекта"
времени все равно приходится работать одному, и с точки
зрения многих команд Bazaar в этом случае мало что ме- Первая команда init-repo создает в директории repo раз-
няется. деляемый репозиторий, и под директорией repo могут хра-
Если у вас уже есть готовый проект и его надо поста- нится различные ветки проекта. Основную ветку мы созда-
вить под контроль версий, нужно начать со следующей це- ем следующей командой init, которая уже была описана вы-
почки команд: ше. В случае создания разделяемого репозитория в дирек-
тории repo/.bzr хранится репозиторий и в директории repo/
$ cd project-directory trunk/.bzr ветка.
$ bzr init
$ bzr add Если при добавлении мы хотим игнорировать какие-
$ bzr commit -m "Импортирование проекта" либо объекты, можно воспользоваться командой ignore,
ее синтаксис:
Здесь первая команда init создает в рабочей директо-
рии project-directory служебную директорию .bzr, в которой bzr ignore имена объектов
хранятся репозиторий и ветка проекта.
Следующая команда, add, рекурсивно добавляет все Эта команда создаст в корневой директории ветки файл
файлы и директории в рабочем каталоге под контроль вер- .bzrignore, в котором будут записаны имена или шаблоны
сий. Если нет необходимости в рекурсивном добавлении, для игнорирования. Если удобно, то данный файл также
то можно использовать опцию --no-recurse или перечис- можно редактировать в текстовом редакторе.
лить необходимые для добавления объекты сразу вслед Глобальные правила игнорирования можно задать в кон-
за командной. фигурационном файле ignore в каталоге с конфигурацией,
Bazaar может контролировать и, соответственно, добав- ~/.bazaar/ignore для UNIX-подобных систем.
лять командой add, файлы, директории и символические Кроме задания полных имен и шаблонов, используемых
ссылки (для ссылок хранится значение ссылки, а не объ- командной оболочкой, таких как *.py[co], *.o, можно исполь-
ект, на который она ссылается). зовать регулярные выражения:
Если в процессе работы над проектом создаются новые
файлы и директории, которые нужно хранить под контро- bzr ignore "RE:lib/.*\.o"
лем версий, они также должны быть добавлены командой
add или внесены в список игнорируемых файлов, описан-
ной ниже, командой ignore. Если этого не сделать, файлы Просмотр изменений
будут показываться Bazaar как неизвестные. Когда закончен очередной этап изменений, хорошей прак-
И последняя команда, commit, фиксирует изменения тикой, прежде чем фиксировать эти изменения в системе
на ветке и в репозитории, создавая новую ревизию. Опция контроля версий, может быть их просмотр.
-m позволяет указать комментарий к ревизии прямо из ко- Команда status показывает изменения в рабочем дере-
мандной строки. Без этой опции для создания коммента- ве с момента последней ревизии:
рия будет вызван текстовый редактор.
На данный момент в Bazaar нет жесткого ограниче- $ bzr status
ния на размер комментария (единственное ограничение – modified:
это достаточно большой, максимальный размер строки README.txt
unknown:
в Python), но рекомендуется делать их разумной длины, до- db.tmp
статочной для описания сделанных изменений.
По умолчанию команда commit фиксирует все измене- Команда diff показывает изменения в текстовых фай-
ния на ветке, даже если запущена из-под директории вет- лах в стандартной унифицированной форме:

№9, сентябрь 2008 73

 программирование
$ bzr diff Выпуск проекта
После некоторого количества ревизий наступает долго-
=== added file 'README.txt'
--- README.txt 1970-01-01 00:00:00 +0000 жданный момент выпустить очередную версию проекта.
+++ README.txt 2008-01-20 14:23:29 +0000 Для упаковки новой версии можно воспользоваться ко-
@@ -0,0 +1,1 @@ мандой export, которая упаковывает проект в зависимос-
+Файл README
ти от заданного расширения файла. Например, следующая
команда создаст ZIP-архив проекта:
Просматривать изменения между заданными ревизия-
ми можно с использованием опции -r: bzr export ../releases/project-1.0.zip

bzr diff -r 100..
bzr diff -r 100..120
Первая команда показывает все изменения, начиная
с ревизии 100, а вторая – между ревизией 100 и 120.
Для просмотра истории ревизий используется коман-
да log. Bazaar использует иерархическую историю, где объ-
единенные с данной веткой ревизии показываются с от-
ступами в виде дерева. В этом случае визуально проще
отделить объединенные изменения от изменений на ос-
новной ветке:
$ bzr log
При выпуске каждой версии имеет смысл помечать ее,
чтобы в будущем можно было использовать более простые
символические имена для работы с этой ревизией. Это мож-
но сделать командой tag:
bzr tag version-1.0
После этого созданную метку можно использовать в дру-
гих командах следующим образом:
bzr diff -r tag:version-1.0

------------------------------------------------------------
revno: 100 Исправление ошибок
committer: John Doe <john@nowhere>
branch nick: trunk
К сожалению, ошибок невозможно избежать, они случают-
timestamp: Tue 2008-08-19 16:25:36 +0100 ся, и это надо принимать и быть к этому готовым. Bazaar
message: разработан таким образом, что большинство ошибок мож-
Объединены изменения с работы
но исправлять, в том числе и с использованием отдель-
------------------------------------------------------------
revno: 100.1.1 ных команд. Рассмотрим различные ситуации и их раз-
committer: John Doe <john@nowhere> решение.
branch nick: work
timestamp: Tue 2008-08-19 09:54:08 -0500 Если вы случайно поставили под контроль версий
message: не то рабочее дерево, то можно удалить служебный ката-
Добавлен файл README.txt лог .bzr, хотя стоит быть внимательным, чтобы не удалить
что-то нужное.
С командой log так же, как и с командой diff, можно ис- Если случайно под контроль версий был поставлен
пользовать опцию -r для указания необходимых ревизий файл, который нет необходимости хранить под контролем
для просмотра. версий, то его можно удалить командной remove, но без ис-
Для просмотра краткой истории изменений, не включа- пользования опций команда не будет удалять изменен-
ющей описание ревизий с объединенных веток, можно вос- ный файл:
пользоваться опцией --short:
bzr add file.txt
bzr remove file.txt
$ bzr log --short
bzr: ERROR: Can't safely remove modified or unknown files:
100 John Doe 2008-08-19 [merge]
Объединены изменения с работы
added:
file.txt
Use --keep to not delete them, or --force to delete them
Кроме того, историю ревизий можно просматривать regardless.
для отдельного файла или директории, добавив его имя
после команды: Соответственно, можно использовать опцию --keep, что-
бы оставить файл на диске, но удалить его регистрацию
bzr log README.txt или опцию --force, чтобы удалить и регистрацию, и файл.
Надо заметить, что если вы удалите файл, не используя
Команда cat выводит содержимое файла для ревизии Bazaar, то Bazaar будет считать, что необходимо удалить
заданной опцией -r: и регистрацию файла.
Команда revert возвращает все файлы и директории
$ bzr cat -r 100 README.txt в состояние на момент последней фиксации, но при этом
Файл README сохраняет измененные файлы под другими именами. Она
действует рекурсивно, и если нужно вернуть только не-
После просмотра изменений их можно зафиксировать сколько файлов, то надо быть внимательным и указывать
командой commit, которая была описана выше. в командной строке только их:

74
 программмирование
bzr revert ветку в каталоге remote, и в итоге создаем еще одну копию,
копируя локальную ветку в каталог local:
Если вы случайно сделали фиксацию, то можно исполь-
зовать команду uncommit, чтобы убрать последнюю ревизию $ cd projects
$ bzr init-repo project
и вернуть рабочее дерево в состояние до момента фикса- $ cd project
ции. Эта команда позволяет также исправлять и коммен- $ bzr branch bzr+ssh://some.host/some/project remote
тарии к ревизии: Branched 10 revision(s).

bzr commit -m "Исправлен файл README" $ bzr branch remote local

bzr uncommit
bzr commit -m "Исправлен файл README.txt" Branched 10 revision(s).

Кроме того, команда uncommit позволяет отменить не- Если теперь в каталоге remote мы посмотрим инфор-
сколько последних ревизий, например, три последние: мацию о ветке командной info, то увидим ассоциирован-
ную родительскую ветку:
bzr uncommit -r -3
$ cd remote
$ bzr info
Если нет необходимости удалять ревизии, а нужно толь-
Standalone tree (format: pack-0.92)
ко вернуть рабочее дерево в прежнее состояние, то можно
Location:
использовать команду revert с опцией -r: branch root: .

bzr revert -r -3 Related branches:

parent branch: bzr+ssh://some.host/some/project

Исправить неправильно поставленные метки можно Хотя возможно большое количество сценариев работы,
с помощью команды tag, например, перенести метку на дру- в нашем примере все локальные изменения будут делать-
гую ревизию можно с помощью опции --force, а удалить с по- ся на ветке в каталоге local, а ветка в каталоге remote будет
мощью опции --delete: отслеживать все изменения, сделанные на удаленной вет-
ке. Но в простейшем случае можно использовать и только
bzr tag --delete version-1.0 одну локальную ветку.
bzr tag --force version-2.0
Итак, представим, что мы проделали некоторую рабо-
ту и создали несколько ревизий на ветке local. Теперь мы
Работаем в команде обновим копию удаленной ветки изменениями, сделанны-
После того как мы рассмотрели работу с Bazaar в одино- ми другими разработчиками, и потом объединим наши из-
честве, рассмотрим распределенные возможности при ра- менения. Для обновления ветки нужно выполнить коман-
боте в команде (или по такому же сценарию вы можете ра- ду pull в каталоге remote, при этом будут скачаны и добав-
ботать из нескольких мест, например, c работы и из дома). лены все ревизии, которые были сделаны на родительской
В простейшем случае, если вы работаете в команде, кто- ветке после момента последнего обновления:
то из разработчиков уже мог создать центральную ветку
Bazaar, или при работе в паре это может быть одна из ло- bzr pull
кальных веток другого разработчика, которую вам необхо-
димо скопировать к себе. Кроме работы с файловой сис- Так как изменения на ветке local происходили парал-
темой, Bazaar может работать со следующими протокола- лельно с изменениями на удаленной ветке, то мы не мо-
ми: FTP, HTTP, HTTPS, SFTP и собственным оптимизиро- жем просто сделать pull, а должны объединить изменения
ванным протоколом bzr. Одним из простейших способов с помощью команды merge в каталоге remote:
открыть к ветке доступ для чтения может быть использо-
вание HTTP/HTTPS. В этом случае достаточно в конфигу- bzr merge ../local
рации веб-сервера открыть, с учетом необходимых огра-
ничений, директорию с веткой на доступ, как и любую дру- Если путь не указан, то merge как и pull будет использо-
гую директорию. Для доступа на запись рекомендуется ис- вать путь к родительской ветке. При объединении изменя-
пользовать соединение через SSH, которое можно устано- ется только рабочее дерево, чтобы сохранить объединен-
вить, используя схему bzr+ssh://. В этом случае автомати- ные изменения, нужно сделать фиксацию командой commit.
чески будет использоваться собственный протокол Bazaar Bazaar использует качественный алгоритм объединения,
через SSH туннель. К сожалению, на данный момент собст- учитывающий возможные прошлые объединения, и во мно-
венный протокол сам по себе не имеет никаких ограниче- гих случаях не надо заботиться о таких тонкостях, как на-
ний на доступ. чальная и конечная ревизии для объединения.
Для копирования ветки используется команда branch, В случае если в параллельных ветках было изменено
которая по умолчанию копирует все ревизии из указанно- одно и то же место в файле, автоматическое объединение
го места в локальный каталог, создавая новую ветку. В при- может не сработать, и требуется устранить конфликты вруч-
мере ниже мы создаем разделяемый репозиторий для эко- ную. При объединении бинарных файлов по умолчанию лю-
номии места и затем копируем удаленную ветку, создавая бые параллельные изменения всегда будут конфликтовать,

№9, сентябрь 2008 75

 программирование
но есть возможность подключения модулей, поддержива-
ющих объединение конкретных бинарных форматов. Фай-
лы, в которых не удалось сделать автоматическое объеди-
нение, можно посмотреть по команде status, или conflicts.
При обнаружении конфликта Bazaar создаст дополнитель-
но 3 файла для каждого файла с конфилктами:
n имя.BASE – файл с содержимым из предыдущей
или последней ревизии текущей ветки;
n имя.THIS – файл с содержимым из последней ревизии
или рабочая копия из текущей ветки;
n имя.OTHER – файл с содержимым из другой ветки.
После того, как конфликт был исправлен вручную, нуж-
но использовать команду resolve, чтобы сказать Bazaar
об этом, при этом ей можно указать только имена исправ-
ленных файлов:
bzr resolve
Также часто бывает полезно определить, кто поменял
конкретные строчки в файле, для этого в Bazaar можно ис-
пользовать команду annotate:
bzr annotate
После того как все изменения сделаны на ветке remote,
нужно их перенести на удаленную ветку, для этого исполь-
зуется команда push, которая переносит все недостающие
ревизии на родительскую ветку. Если родительская ветка
также была изменена, то Bazaar скажет о расхождении ве-
ток и нужно будет сначала сделать их объединение и толь-
ко затем push:
bzr push
Иногда нужно просто передать изменения для про-
смотра, не обновляя родительскую ветку. В каком-то слу-
чае можно опубликовать свою ветку с изменениями через
один из протоколов, поддерживаемых Bazaar, или можно
послать изменения по e-mail. Для этого в Bazaar есть ко-
манды send и bundle. Команда bundle может быть исполь-
зована для создания пакета с изменениями, который мож-
но приложить к e‑mail-сообщению. Команда send позволя-
ет послать сообщение с изменениями прямо из команд-
ной строки.
Работа в централизованном стиле
Кроме всего прочего Bazaar позволяет работать в центра-
лизованном стиле, когда все изменения в момент фикса-
ции сразу идут и на одну центральную ветку. Рекоменду-
ется все центральные ветки располагать в разделяемом
репозитории, что может соответствовать корню репозито-
рия в Subversion. Так как в центральном репозитории есть
смысл хранить только историю изменений, его можно соз-
дать без рабочего дерева. Рассмотрим процесс создания
основной центральной ветки, копирование ее на локаль-
ную ветку и добавление файлов:
$ bzr init-repo --no-trees sftp://central.host/bzr/repo
76
$ bzr init sftp://central.host/bzr/repo/trunk
$ bzr checkout sftp://central.host/bzr/repo/trunk
$ cd trunk
$ cp -ar ../some-files/ .
$ bzr add
$ bzr commit -m "Импорт проекта"
Здесь мы использовали команду checkout, чтобы ско-
пировать и связать удаленную ветку с локальной. Кроме
использования этой команды можно связать любые ветки
с помощью команды bind. В этом случае в момент фикса-
ции все изменения сразу пойдут и на связанную ветку. Ес-
ли до момента фиксации на связанной ветке произошли
изменения, то команда commit скажет о них и нужно будет
прежде выполнить описанную ниже команду update:
bzr bind sftp://central.host/bzr/repo/trunk
Также в любой момент можно отвязать локальную вет-
ку командой unbind, чтобы вернуться к режиму «локальные
фиксации и публикация»:
bzr unbind
Надо заметить, что команда checkout копирует всю ис-
торию локально. Если в этом нет необходимости, то мож-
но использовать ее с ключом --lightweight:
bzr checkout --lightweight sftp://central.host/bzr/repo/trunk
После того как мы сделали checkout обновления из цент-
ральной ветки, можно получать командой update как и в цен-
трализованных системах:
bzr update
Если при использовании центральной ветки вам в какой-
то момент необходимо сделать фиксацию локальной ветки,
можно использовать опцию --local команды commit:
bzr commit --local
Что дальше?
К сожалению, не удалось включить в эту статью другие
возможности или принципы работы Bazaar, о которых хо-
телось бы рассказать. За кадром остались, например, та-
кие темы:
n подключаемые модули, позволяющие расширять воз-
можности Bazaar;
n как создавать псевдонимы для команд;
n примеры использования Bazaar в различных ситуациях;
n импорт и экспорт ревизий из других систем контроля
версий;
n организация веток в виде стека.
Таким образом, эти темы остаются для самостоятель-
ного изучения или могут быть темой одной из будущих ста-
тей. В любом случае я уверен, что изучение одной из рас-
пределенных систем контроля версий поможет вам увели-
чить продуктивность вашей работы.