Базарный день

Inside .bzr: что внутри служебного каталога .bzr: Часть 2: shared repository

2011-08-14T19:40:00.000+01:00

В первой части мы рассмотрели как внутри выглядит ветка и отметили, что у самостоятельных веток (standalone branch) репозиторий свой. Посмотрим, что изменится при работе с shared repository.
(Далее)

Копия ветки без использования shared repository

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

C:\work\bzr-day\Inside>bzr branch branch copy
Branched 1 revision(s).

Заходим в копию нашей первой ветки и смотрим вывод bzr info -v:

C:\work\bzr-day\Inside\copy>bzr info -v
Standalone tree (format: 2a)
Location:
branch root: .

Related branches:
parent branch: C:/work/bzr-day/Inside/branch

Format:
control: Meta directory format 1
working tree: Working tree format 6
branch: Branch format 7
repository: Repository format 2a - rich roots, group compression and chk inventories
...

Интересными для нас являются следующие секции: Related branches и Format.

Секция Related branches показывает нам путь к родительской ветке (т.е. к нашей первой ветке). Как уже отмечалось ранее в 1й части, эти данные хранятся в конфигурационном файле .bzr/branch/branch.conf в чем легко можно убедиться:

parent_location = ../branch/

(Путь сохранен в относительном виде, относительно корневого каталога ветки-копии).

Секция Format показывает, что у текущей ветки есть свой репозиторий. В этом также легко убедиться, заглянув в /bzr/repository. Имя пакетированного файла в клонированном репозитории скорее всего будет отличаться от первого репозитория, поскольку bzr осуществил не просто копирование репозитория, а еще и выполнил перепаковку данных.

Кстати говоря, если мы просто скопируем каталог с оригинальной веткой как новый каталог, то получим вполне рабочую новую ветку, но очевидно, что при этом значение parent_location в branch.conf останется старым.

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

Поэтому для оптимизации времени создания новой ветки и для уменьшения требуемого дискового пространства для копий веток, рекомендуется использовать разделяемый/общий репозиторий (shared repository). Как следует из названия он служит общим хранилищем для нескольких веток (располагающихся внутри).

Анатомия shared repository

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

C:\work\bzr-day\Inside>bzr init-repo shared-repo

Shared repository with trees (format: 2a)

Location:

shared repository: shared-repo

Мы создали общий репозиторий, в котором по умолчанию для веток будут создаваться рабочее дерево (Shared repository with trees). Для работы с ветками на локальном компьютере это ожидаемая конфигурация.

Заглянем внутрь .bzr:

branch-lock/

repository/

branch-format

readme

Как мы видим в отличие от ветки, в общем репозитории присутствует только компонент .bzr/repository, другие служебные файлы и каталоги на своих местах. Что нам покажет bzr info -v:

C:\work\bzr-day\Inside\shared-repo\.bzr>bzr info -v

Shared repository with trees (format: 2a)

Location:

shared repository: C:/work/bzr-day/Inside/shared-repo

Format:

control: Meta directory format 1

repository: Repository format 2a - rich roots, group compression and chk inventories

Create working tree for new branches inside the repository.

Repository:

0 revisions

Хотя этот общий репозиторий пока пустой (0 revisions), однако внутри каталога .bzr/repository есть на что посмотреть:

indices/

lock/

obsolete_packs/

packs/

upload/

format

pack-names

shared-storage

Очень похоже на содержимое .bzr/repository для обычной ветки, но добавился файл shared-storage (нулевой длины). Этот файл является маркером общего репозитория. Если его удалить, то наш объект перестанет быть shared repository.

Ветки внутри общего репозитория

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

C:\work\bzr-day\Inside\shared-repo>bzr branch ../branch a_branch

Branched 1 revision(s).

Посмотрим внутрь служебного каталога новой копии a_branch:

branch/

branch-lock/

checkout/

branch-format

readme

Как мы видим компонент .bzr/repository отсутствует. Что нам покажет bzr info -v:

C:\work\bzr-day\Inside\shared-repo\a_branch>bzr info -v

Repository tree (format: 2a)

Location:

shared repository: C:/work/bzr-day/Inside/shared-repo

repository branch: .

Related branches:

parent branch: C:/work/bzr-day/Inside/branch

Format:

control: Meta directory format 1

working tree: Working tree format 6

branch: Branch format 7

repository: Repository format 2a - rich roots, group compression and chk inventories
...

Тем не менее, мы видим, что в секции форматов компонент repository присутствует. А в секции Location появилось упоминание shared repository. Наша новая ветка автоматически использует общий репозиторий вместо создания своего собственного. Если мы посмотрим внутрь .bzr/repository общего репозитория, то увидим, что туда добавлен новый пакетированный файл для нашей ветки.

Если мы посмотрим на branch.conf нашей новой ветки, то не увидим там никаких упоминаний общего репозитория и его расположения. И вообще нигде нет таких упоминаний. В том числе в структурах самого общего репозитория нет никаких указаний на расположение нашей ветки.

Bazaar осуществляет поиск общего репозитория для ветки просто просматривая все родительские каталоги вверх по дереву файловой системы пока не найдет один.

Из этого следует два вывода:

Вы можете как угодно перемещать ветки внутри общего репозитория, внутрь подкаталогов, между подкаталогами, просто переименовывать ветки/каталоги -- и всё будет работать.
Если вы просто скопируете или перенесете ветку из общего репозитория наружу, в другой каталог, то работа с такой веткой станет невозможна, поскольку bzr не сможет найти требуемый общий репозиторий. Вместо этого вам нужно использовать команду bzr branch, которая позаботится о том, чтобы восстановить репозиторий для ветки, если нужно.

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

C:\work\bzr-day\Inside\shared-repo>bzr branch a_branch a_copy

Branched 1 revision(s).

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

Дополнительные сведения про общие репозитории

1. Общий репозиторий ничего не знает про ветки внутри него

Общий репозиторий является максимально общим хранилищем для ревизий. Настолько, что он ничего не знает о содержащихся внутри ветках. Их там даже может и не быть. С другой стороны вы можете иметь внутри репозитория ветки не имеющие ни одной общей ревизии, не имеющие общей истории, и все будет работать, поскольку каждая ревизия имеет внутри себя указатель на последнюю зафиксированную ревизию (файл last-revision).

2. Общий репозиторий на сервере

Если у вас есть центральный сервер, на котором вы храните свои ветки, то в большинстве случаев имеет смысл заводить общий репозиторий и на сервере, для получения тех же преимуществ: экономия места и ускорение клонирования веток. Однако чаще всего на сервере вашим веткам не нужно иметь рабочее дерево (компонент .bzr/checkout). Поэтому на сервере общий репозиторий имеет смысл создавать с опцией --no-trees:

C:\work\bzr-day\Inside>bzr init-repo --no-trees shared-no-trees
Shared repository (format: 2a)
Location:
shared repository: shared-no-trees

C:\work\bzr-day\Inside\shared-no-trees>bzr info -v
Shared repository (format: 2a)
Location:
shared repository: .

Format:
control: Meta directory format 1
repository: Repository format 2a - rich roots, group compression and chk inventories

Repository:
0 revisions

При данной опции внутри каталога .bzr/repository создается дополнительный файл-флаг нулевой длины no-working-trees. Этот флаг влияет только на создание новых веток. В существующих ветках вы всегда можете создать или удалить рабочее дерево при помощи команд bzr checkout и bzr remove-tree.

В существующем общем репозитории можно переключаться между режимами --no-trees и --trees при помощи команд:

bzr reconfigure --with-no-trees

bzr reconfigure --with-trees

3. Переход от самостоятельной ветки к использованию общего репозитория и обратно

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

bzr reconfigure --use-shared

Это полезная команда еще и в тех случаях, когда у нас была просто самостоятельная ветка или две, а потом мы решили, что неплохо было бы, чтобы эта ветка или две были внутри общего репозитория. Тогда мы просто создаем в родительском каталоге общий репозиторий, и для всех веток запускаем команду bzr reconfigure --use-shared.

Существует и обратное преобразование: ветку, использующую общий репозиторий мы можем превратить в ветку со своим собственным репозиторием командой

bzr reconfigure --standalone

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

bzr branch URL a_copy

bzr reconfigure --stadalone a_copy

целесообразно использовать одну команду:

bzr branch --standalone URL a_copy

Особенно, если формат ветки и общего репозитория не совпадают.

4. Замечание касательно форматов репозиториев

Лучше всего если все ваши ветки используют один и тот же формат. Тем более, что формат в bzr не менялся уже 2 года.

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

Поэтому я настоятельно рекомендую вам держать все свои рабочие ветки в одинаковом формате.

Inside .bzr: что внутри служебного каталога .bzr. Часть 1: просто ветка

2011-08-08T10:14:00.001+01:00

В своей книге Version Control by Example Эрик Синк (Eric Sink) пишет:

Version control tools are more like cars than clocks.

Clock users have no need to know how a clock works behind the dials. We just want to know what time it is. Those who understand the inner workings of a clock can’t tell time any more skillfully than the rest of us.

Version control tools are more like cars. Lots of people, including me, use cars without knowing much about how they work. However, people who really understand cars tend to get better performance out of them.

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

В документации к bzr вопросам внутреннего устройства системы уделяется меньше внимания, чем могло быть. Отчасти потому что разработчики bzr исходили из посылки, что для успешного использования bzr знания о внутреннем устройстве необязательны (в отличие от git, где без знания как устроен репозиторий вы не имеете права использовать его).

Предлагаю рассмотреть внутреннее устройство служебного каталога .bzr, и что там живет внутри, это даст вам понимание о разнице между веткой, разделяемом репозитории (shared repository) и различным типам checkouts.
(Далее)

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

Обычная ветка

Начнем с объекта, создаваемого по умолчанию командой bzr init -- это обычная ветка.

C:\work\bzr-day\Inside>bzr init branch
Created a standalone tree (format: 2a)

C:\work\bzr-day\Inside>cd branch
C:\work\bzr-day\Inside\branch>

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

C:\work\bzr-day\Inside\branch>bzr mkdir spam
added spam

C:\work\bzr-day\Inside\branch>echo > eggs

C:\work\bzr-day\Inside\branch>bzr add
adding eggs

C:\work\bzr-day\Inside\branch>bzr st
added:
eggs
spam/

C:\work\bzr-day\Inside\branch>bzr ci -m "initial revision"
Committing to: C:/work/bzr-day/Inside/branch/
added eggs
added spam
Committed revision 1.

Заходим внутрь каталога .bzr и что мы там видим:

branch/
branch-lock/
checkout/
repository/
branch-format
README

Четыре каталога и 2 файла.

Посмотрим, что нам предлагает прочитать в нем файл README:

This is a Bazaar control directory.
Do not change any files in this directory.
See http://bazaar.canonical.com/ for more information about Bazaar.

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

Посмотрим второй файл branch-format:

Bazaar-NG meta directory, format 1

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

Из 4х каталогов branch, branch-lock, checkout, repository интересными для нас будут только branch, checkout и repository, каталог branch-lock предназначен для блокировок совместного доступа и в мирное время он пуст.

Историческое отступление

Файл branch-format и каталог branch-lock имеют такое название с доисторических времен, когда Bazaar только зарождалась. Для обратной совместимости с древними форматами они оставлены без изменений.

В остальных каталогах файл-маркер формата называется просто format, а каталог для блокировок -- lock.

Файлы-маркеры форматов (format) нужны bzr для того, чтобы знать как правильно работать с соответствующим объектом. На вопрос "зачем базару сто тысяч миллионов форматов" я отвечу в другой статье.

Продолжаем.

Каталоги branch, checkout, repository соответствуют 3м базовым объектам в bzr: ветке, рабочей копии и репозиторию. Собственно каталог .bzr, содержащий их, является контейнером и называется control directory. Все эти 4 объекта и их форматы отображаются в выводе команды bzr info -v:

C:\work\bzr-day\Inside\branch\.bzr>bzr info -v

Standalone tree (format: 2a)

Location:

branch root: C:/work/bzr-day/Inside/branch

Format:

control: Meta directory format 1

working tree: Working tree format 6

branch: Branch format 7

repository: Repository format 2a - rich roots, group compression and chk inventories

...

Секция, озаглавленная Format, показывает нам форматы для всех 4х объектов. Эти форматы, как я уже сказал, идентифицируются файлами format в соответствующих подкаталогах.

Компонент (каталог) branch

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

Посмотрим внутрь .bzr/branch:

lock/
branch.conf
format
last-revision
tags

Каталог lock неинтересен -- он для блокировок.

Файл format содержит маркер формата компонента:

Bazaar Branch Format 7 (needs bzr 1.6)

(В выводе команды bzr info мы видели строку Branch format 7 -- совпадает).

Файл last-revision -- это тоже маркер. Собственно это -- указатель на последнюю ревизию в данной ветке (так называемый tip). Содержимое файла -- это пара revno revid:

1 ru_bzr@googlegroups.com-20110806154658-b9b3oat6e8tzsibe

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

C:\work\bzr-day\Inside\branch\.bzr\branch>bzr log --show-ids -r-1

------------------------------------------------------------

revno: 1

revision-id: ru_bzr@googlegroups.com-20110806154658-b9b3oat6e8tzsibe

committer: Базарный день

branch nick: branch

timestamp: Sat 2011-08-06 18:46:58 +0300

message:

initial revision

Самой ревизии в .bzr/branch мы не видим -- ревизии хранятся в .bzr/repository.

Файл tags -- это хранилище для тегов ветки. Пока мы не создали ни одного тега этот файл пустой. При добавлении тегов командой bzr tag в этот файл будут добавляться данные о тегах, в виде словаря где ключ -- это имя тега, а значение -- это идентификатор ревизии, на которую указывает тег. Сам словарь кодируется при помощи Bencode.

Файл branch.conf наиболее интересен с точки зрения пользователя. Это файл конфигурации для текущей ветки. В нем могут храниться любые настройки и параметры, которые нужны для ветки. В частности, там хранятся пути/URL к связанным веткам: parent_location (для pull/missing/merge), push_location (для push), submit_location (для merge/send). Кроме того, плагин QBzr использует branch.conf для сохранения данных о коммитах, или кодировке файлов (qdiff/qannotate/qcat/qviewer). Этот файл должен иметь кодировку UTF-8, и в принципе если вам нужно, то его можно редактировать вручную, или менять параметры в нем с помощью команды bzr config.

Наиболее важно то, что для простых веток содержимое этого файла некритично для работы. А вот в случае bound branch / heavyweight checkout или stacked branch в файле branch.conf содержится важная информация, поэтому порча этого файла может нарушить нормальную работу. Подробнее об этом мы поговорим позднее.

Компонент (каталог) checkout

Компонент checkout хранит служебную информацию, необходимую для работы с рабочим деревом (working tree). Если ветка не имеет рабочего дерева (например, на сервере), то компонент будет отсутствовать.

Посмотрим внутрь .bzr/checkout:

lock/
shelf/
conflicts
dirstate
format
views

Назначение каталога lock и файла format -- аналогичное рассмотренным ранее.

Каталог shelf предназначен для работы функциональности shelve / unshelve -- именно там хранятся те правки, которые вы отобрали в команде shelve.

Файл dirstate хранит информацию о файлах и каталогах в вашем рабочем дереве: о последней зафиксированной ревизии каждого элемента, об изменениях и т.д. Этот файл достаточно важен для нормальной работы, при его порче единственное, что можно сделать -- это создать рабочее дерева заново и скопировать туда последние незафиксированные изменения (если нужно).

Файл conflicts как следует из его названия хранит информацию о текущих конфликтах требующих решения.

Файл views хранит информацию о настроенных видах (см. команду bzr view).

Кроме этих файлов и каталогов в .bzr/checkout еще могут быть созданы следующие файлы и каталоги:

файл merge-hashes создается в результате merge и служит для отслеживания факта модификаций файлов после merge, используется командой revert для определения того, безопасно ли делать revert конкретному файлу или там могут находиться пользовательские изменения.

два каталога limbo и pending-deletions -- это коротко живущие каталоги, создаваемые во время выполнения команд pull, push, merge. Эти каталоги не должны существовать после нормального завершения команд. Однако при сбоях в работе указанных команд эти каталоги остаются на диске и мешают дальнейшей работе. Единственный способ исправить сложившуюся ситуацию -- это нужно просто их удалить, особенно если они пустые.

Компонент (каталог) repository

Компонент repository -- это собственно хранилище истории: ревизий, текстов файлов в каждой ревизии, состояния рабочего дерева для каждой ревизии, а также подписей к ревизиям. Самостоятельные ветки имеют собственный репозиторий, ветки же создаваемые внутри shared repository используют репозиторий общего хранилища. Об этой особенности мы говорили ранее.

Начиная с bzr версии 1.0 основным форматом репозитория стал так-называемый pack-based формат. Краткое техническое описание формата можно прочитать в документации для разработчиков bzr: http://doc.bazaar.canonical.com/bzr.2.3/developers/packrepo.html#technical-notes. Также начиная с bzr 2.0 основным форматом репозитория стала улучшенная версия описанного формата 2a (CHKGroupCompress, CHK = Content Hash Key), которая улучшила сжатие данных в репозитории и позволила ускорить операции по сохранению и извлечению данных. В документации разработчиков есть только некоторые мысли касательно дизайна нового формата: http://doc.bazaar.canonical.com/bzr.2.3/developers/groupcompress-design.html, для нас же главное, что в формате 2a добавился еще один индекс. См. далее.

Посмотрим внутрь .bzr/repository:

indices/
lock/
obsolete_packs/
packs/
upload/
format
pack-names

Назначение каталога lock и файла format -- аналогичное рассмотренным ранее.

Файл pack-names содержит список пакетированных (pack) файлов. Этот список содержит базовые имена файлов в каталогах packs и indices. Если посмотреть этот файл в текстовом редакторе, то можно увидеть, что он закодирован (сжат для экономии места). Для просмотра его в читаемом виде можно применить скрытую команду bzr dump-btree:

C:\work\bzr-day\Inside\branch\.bzr\repository>bzr dump-btree pack-names
(('42d1a7283aac1a3d35f93593af36b836',), '162 161 238 72 183', None)

Показанные данные все равно имеют свои особенности, как мы видим, для нас же главное -- это первый элемент: 42d1a7283aac1a3d35f93593af36b836. Это имя пакетированного файла и индексов к нему.

Посмотрим внутрь каталога packs: там находится единственный файл 42d1a7283aac1a3d35f93593af36b836.pack и как мы можем видеть его имя файла соответствует информации из pack-names + расширение.

Отличительная деталь: имена пакетированных файлов совпадают с md5 суммой для их содержимого. Этот факт рекомендуется использовать для проверки целостности пакетированных файлов.

C:\work\bzr-day\Inside\branch\.bzr\repository\packs>md5sum 42d1a7283aac1a3d35f93593af36b836.pack
42d1a7283aac1a3d35f93593af36b836 *42d1a7283aac1a3d35f93593af36b836.pack

Сами пакетированные файлы содержат много блоков различной информации в сжатом виде (zlib + CHKGroupCompress) и для извлечения конкретной информации bzr использует индексы для определения того, где именно в файле лежат нужные данные.

Индексы хранятся в каталоге indices. Посмотрим:

42d1a7283aac1a3d35f93593af36b836.cix
42d1a7283aac1a3d35f93593af36b836.iix
42d1a7283aac1a3d35f93593af36b836.rix
42d1a7283aac1a3d35f93593af36b836.six
42d1a7283aac1a3d35f93593af36b836.tix

Опять же имена файлов-индексов соответствуют имени пакетированного файла. Расширения файлов-индексов соответствуют различной информации, которую bzr собирается извлекать.

cix -- индексы для восстановления данных, закодированных по алгоритму CHKGroupCompress.
tix -- индексы для извлечения содержимого файлов в рабочем дереве.
rix -- индексы для извлечения данных о ревизиях.
iix -- индексы для извлечения инвентаря ревизий (списка файлов и каталогов в конкретной ревизии + указание на содержимое файлов). Это аналог файлов dirstate из компонента checkout.
six -- индексы для извлечения gpg-подписей к ревизиям (если таковые имеются).

Индексы также закодированы, для их просмотра в раскодированном виде нужно использовать команду bzr dump-btree.

Каталоги upload и obsolete_packs имеют вспомогательный характер.

В каталоге upload создаются новые пакетированные файлы с временным именем, после чего переименовываются согласно их md5 и переносятся в каталог packs. После успешного окончания операций каталог upload должен быть пуст. Если в результате сбоя там остаются какие-то файлы, то их нужно удалять.

Каталог obsolete_packs служит в качестве мусорки. Туда переносятся ненужные более пакетированные файлы и их индексы после перепаковки мелких пакетированных файлов в более крупные.

Bazaar при каждой новой ревизии создает один новый пакетированный файл. Каждый пакетированный файл записывается только один раз и туда больше ничего не дописывается. Это сделано чтобы гарантировать целостность данных. Однако, при таком подходе количество пакетированных файлов будет очень большим, что плохо скажется как на скорости работы, так и на используемом дисковом пространстве. Поэтому каждые 10/100/1000/10000/.... (10 в n-й степени) ревизий bzr автоматически осуществляет переупаковку мелких файлов в более крупные. По окончанию операции старые файлы не удаляются сразу, а сначала переносятся в каталог obsolete_packs, на случай если их нужно будет восстановить.

Переупаковку репозитория можно делать и вручную, запустив команду bzr pack. Это имеет смысл периодически делать для репозиториев на центральном сервере, чтобы все работало максимально оптимально.

После успешной перепаковки файлы из каталога obsolete_packs можно удалить. Команда bzr pack имеет ключ --clean-obsolete-packs однако его использование предваряется предупреждением, что в случае сбоя диска во время выполнения этой операции могут быть потеряны файлы. Более безопасным способом на Linux будет сделать что-то вроде sync && sync и затем удалить файлы вручную.

Следует отметить, что bzr сам удалит файлы из obsolete_packs при следующей перепаковке (автоматической или ручной). Поэтому если дискового пространства у вас достаточно, то можно этим не заморачиваться.

Однако для целей сравнения размеров репозиториев (с другими DVCS например) имеет смысл вручную перепаковаться и удалить файлы из obsolete_packs. Так результат будет более оптимальный.

Автоматическая перепаковка иногда может быть нежелательной, в новых версиях bzr работают над тем, чтобы сделать ее настраиваемой.

Заключение

Мы рассмотрели внутреннее устройство служебного каталога .bzr для базового объекта -- ветки. В последующих частях мы рассмотрим внутренее устройство других объектов -- shared repository, bound branch, stacked branch, lightweight checkout и увидим, что все они строятся из рассмотренных блоков в нужных комбинациях.

Bazaar уверенно удерживает третье место

2011-08-05T16:43:00.001+01:00

Ни для кого ни секрет, что bzr не является самой-пресамой популярной DVCS по состоянию на 2011 год. По моим личным наблюдениям первое место уверенно держит git, я думаю не в последнюю очередь благодаря GitHub.

На блогах Microsoft опубликованы результаты опроса (через Twitter) предпочтений разработчиков Open Source проектов. Насколько эта выборка репрезентативна -- вопрос спорный. Однако она достаточно хорошо на качественном уровне показывает тенденции: git > hg > bzr.

Выбрав цифры только для тройки git/hg/bzr и беспощадно усредняя их можно прийти к такой средней температуре по больнице:

git ~77%
hg ~18%
bzr < 5%

Почему все еще имеет смысл использовать bzr? может спросить кто-то.

С моей точки зрения причины к этому могут быть следующие:

вы и ваша команда более чем удовлетворены работой bzr и у вас нет причин менять проверенного коня. (По моему личному мнению каждая система из тройки имеет свои недостатки, с которыми придется мириться)
Вы предпочитаете работать в централизованном стиле не теряя плюсов DVCS
вам нравится GUI интерфейс к bzr -- QBzr и/или Bazaar Explorer, и вы не хотите их потерять при переходе на другую систему. Я не раз и не два получал отзывы от различных людей, даже от (увы) бывших пользователей bzr о том, что QBzr очень хорош. И я с этим согласен
вам нравится использовать Launchpad для хостинга своих открытых проектов.
вы используете bzr для работы с svn через bzr-svn. Плюшки в виде QBzr/Explorer прилагаются и здесь.

Собственно других веских причин я затрудняюсь назвать. Я строго убежден, что лучшая DVCS еще не написана, и что у hg просто нет шансов подняться до более-менее паритета с git. Хотя на Windows платформе у hg много преимуществ, учитывая, что git на Windows -- это весьма тяжкое испытание.

Использование bzr-externals или компонентный подход

2010-04-06T20:05:00.035+01:00

При работе над крупными проектами часто возникает потребность выделить часть проекта в отдельный подпроект, как самостоятельную сущность. Такой подпроект может представлять собой некоторую библиотеку, которая используется в разных проектах. Для работы с составными проектами, которые включают в себя дополнительные библиотеки, в bzr задумана функция под названием nested trees (в git для этого есть submodules, а в hg — subrepos). К сожалению разработка функции nested trees пока не завершена, поэтому вместо нее можно использовать плагины bzr-externals или bzr-scmproj. Я попросил автора плагина bzr-externals Евгения Тарасенко рассказать про работу с плагином. В данной статье описывается работа с плагином версии 1.3.

Автор: Евгений Тарасенко

Если ваш проект использует общие библиотеки или компоненты, то самым правильным решением будет подключить их как вложенные подпроекты (или компоненты), а не тупо копировать внутрь проекта.

В Bazaar работа с общими компонентами пока еще не доведена до ума, поэтому пришлось написать небольшой плагин bzr-externals. Надо отметить, что существует еще один похожий плагин bzr-scmproj, но в отличие от первого, в нем для работы с компонентами используются отдельные команды, а это означает, что работа возможна только из консоли и такие инструменты как Bazaar Explorer, QBzr и TortoizeBzr остаются не у дел.

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

Итак, нам понадобится плагин bzr-externals, который можно скачать с http://launchpad.net/bzr-externals или взять прямо из репозитория lp:bzr-externals, о том как это сделать можно узнать из этой статьи.

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

bzr externals-add URL  DIRECTORY [--revision REVISIONSPEC]

Здесь URL может быть относительным, так же как и в svn:externals. Например, следующие команды делают почти одно и тоже, но разными способами, не считая использования конкретной ревизии в первом варианте (eadd — встроенный псевдоним команды):

bzr eadd bzr://example.com/repos/common/foo  common/foo -r revno:100

Если доступ к хранилищу возможен по разным протоколам (например, http или bzr+http), то для компонента имя протокола можно опустить, будет использоваться тот же протокол, по которому вы получите главный проект

bzr eadd //example.com/repos/common/foo  common/foo

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

bzr eadd /repos/common/foo  common/foo

И наконец возможен доступ относительно каталога главного проекта в репозитории

bzr eadd ../../common/foo  common/foo

Каталог, в котором должен размещаться компонент, DIRECTORY указывается относительно корня проекта. Если такого компонента еще нет в рабочей папке проекта, то будет выполнен branch/checkout, в зависимости от типа главного проекта, иначе pull/update.

REVISIONSPEC — необязательный параметр, и должен использоваться, только если вам нужна конкретная версия компонента.

В результате выполнения команды externals-add будет добавлен компонент в рабочую директорию, а также в корне проекта появятся конфигурационные файлы:

.bzrmeta/externals
.bzrmeta/externals-snapshot

Первый файл используется для хранения параметров всех компонентов и может быть отредактирован пользователем; например, чтобы привязать компонент к конкретной версии или просто удалить компонент из проекта. Второй файл создается автоматически при каждом commit в проекте и предназначен для создания "снимка" используемых ревизий компонентов, чтобы впоследствии, при откате на какую-либо ревизию, можно было точно восстановить все дерево проекта (чего, кстати, не умеет делать subversion).

Формат обоих конфигурационных файлов одинаков и незатейлив:

URL DIRECTORY REVISIONSPEC

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

branch [--revision]
checkout [--revision]
commit
pull
push
update.

Однако, если вам все же не хватает этих команд, то есть два пути: первый — просто зайти в директорию с компонентом и делать с ним что угодно, так как по сути это обыкновенная ветка Bazaar. И второй путь — использовать вторую дополнительную команду externals-cmd или кратко ecmd, чтобы выполнить любую команду Bazaar для всех компонентов проекта и для самого проекта тоже. Например, посмотреть последнюю ревизию для всех:

bzr ecmd -- log -r -1

Работа с Bazaar может быть организована различными способами, в том числе с использованием feature branch, когда сначала делается локальная копия удаленного репозитория, а уже от нее делается ветка для конкретной фичи, плагин поддерживает и такой режим работы.

Рассмотрение плагина подошло к концу, дополнительную информацию можно получить с помощью:

bzr help externals

Командная строка и bzr: "ленивые" опции

2010-03-24T12:53:00.002Z

Следующий совет может оказаться полезным для тех, кто использует bzr из командной строки на постоянной основе или даже время от времени. Как вы помните, многие команды bzr имеют встроенные псевдонимы, а также пользователь может задавать свои собственные пользовательские псевдонимы при помощи команды alias. Так вместо status можно использовать st, а вместо commit — ci. Однако эти самые команды зачастую имеют обширный набор опций для тонкого управления поведением каждой команды. Все эти опции имеют основную форму вида --имяопции, и могут иметь короткую форму вида -X где X — это одна буква латинского алфавита. Для того, чтобы узнать какая короткая форма у определенной опции, просматривайте информацию об использовании команды. Например, опция --revision имеет короткую форму -r (о чем вы наверняка знаете).

Однако это еще не всё. Движок, используемый для обработки опций и аргументов команд bzr позволяет использовать сокращенную запись для основной формы. Сокращать допускается до того состояния пока bzr сможет однозначно понять, что вы имеете ввиду, обычно достаточно оставить 2-3 первых буквы. Например, опцию --revision можно сокращать до --rev, а опцию --force до --fo. Тогда pull --remember можно вызывать как pull --rem, а push --overwrite как push --over, и т.д. И поскольку не все опции имеют короткую форму из одной буквы, то часто бывает полезно знать эту возможность.

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

C:\work\bzr-day\options-for-lazy>bzr pull --re lp:foo

bzr: ERROR: ambiguous option: --re (--remember, --revision?)

В данном случае bzr не смог понять какую именно опцию вы имели ввиду: --remember или --revision.

Механизм поддержки сокращений для опций работает для всех опций самой команды, но не работает для глобальных опций самого bzr, таких как --no-plugins, --no-aliases и т.п. Полный список глобальных опций можно увидеть запустив команду bzr help global-options.

Использование внешнего редактора для команды bzr shelve

2010-03-21T11:47:00.004Z

Одной из очень полезных функций в bzr является пара команд shelve/unshelve. Эти команды позволяют временно удалить из рабочих файлов часть изменений, чтобы зафиксировать остальные изменения без них. Часто это бывает нужно для логического разделения разных правок. Например, вы начали реализовывать новую функцию в своей программе и попутно обнаружили и исправили старый баг. Имеет смысл зафиксировать исправление ошибки отдельно и затем продолжить работу над новой функцией. В этом случае помогает shelve/unshelve.

Подобная функциональность присутствует в других системах контроля версий. Так, в git для этого используется команда stash, а в hg для этого используется расширение shelve.

Подробный рассказ об использовании shelve/unshelve заслуживает отдельной статьи. Вкратце процесс отбора изменений для удаления их "на полочку" выглядит следующим образом:

вы запускаете команду shelve, опционально указывая список файлов, в которых нужно отобрать изменения.
для каждого файла с изменениями bzr вам показывает отдельные блоки изменений (diff hunks), аналогично тому как блоками показывает изменения команда diff.
для каждого блока вы указываете: хотите ли вы убрать это изменение "на полочку" либо оставить в рабочей копии.
после того, как вы ответите на вопрос по каждому блоку каждого файла с изменениями, отобранные изменения удаляются из рабочей копии и сохраняются в специальном хранилище ("на полочке").

Подробнее об использовании shelve смотрите справку по этой команде.

Одним из неудобств при использовании shelve является гранулярность отбора изменений. Вы не можете так просто удалить одну строку с изменениями из целого блока (hunks). Вам приходится или убирать весь блок или оставлять весь блок. Что было не очень удобно.

Однако, к нашей радости, в bzr 2.1.0 у shelve появилась новая функция: теперь можно использовать внешний редактор для правки и отбора изменений. В качестве редактора имеет смысл использовать программу для просмотра и редактирования изменений в 2х файлах. Например, vimdiff, WinMerge и проч.

Для того, чтобы использовать внешний редактор в команде shelve его следует предварительно задать в файле конфигурации bazaar.conf. Для этого в секции [DEFAULT] добавьте строку вида:

change_editor = vimdiff -fo @new_path @old_path

Здесь: @new_path @old_path — это специальные параметры, вместо которых в реальности bzr будет подставлять полный путь к редактируемому файлу (@new_path) и полный путь к файлу с последним зафиксированным состоянием (@old_path).

Так, например, я для использования WinMerge указал следующую строку в bazaar.conf:

change_editor = '"C:/Program Files/WinMerge/WinMergeU.exe" @old_path @new_path'

После того, как вы настроите change_editor, при вызовах shelve в строке выбора для каждого блока изменений вам будет доступен дополнительный выбор ("e"). По нажатию на клавишу "e" (editor) будет запущена указанная вами программа для редактирования текущего файла. Ваша задача: отредактировать @new_path до состояния, в котором вы хотите, чтобы он был на диске. Команда shelve сама определит какие изменения нужно убрать из текущей рабочей копии конкретного файла, чтобы в итоге получилось то, что вы хотите.

Приятной работы!

Использование плагина bzr-pipeline для "вечных" локальных правок

2010-02-18T09:01:00.004Z

Иван Сагалаев описал один из вариантов работы с плагином bzr-pipeline. Иван пишет:

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

Читать целиком: http://softwaremaniacs.org/blog/2010/02/18/local-patches-in-bzr-pipeline

Новая стабильная версия Bazaar 2.1.0

2010-02-17T13:53:00.004Z

Спустя полгода после выпуска стабильного релиза bzr 2.0.0 разработчики Bazaar представляют новую стабильную версию Bazaar 2.1.0 (февраль 2010 года).

Новая версия содержит в себе много разных улучшений и исправлений дефектов, однако ничего революционного (вроде нового формата репозитория) не несёт. Список отдельных улучшений просто огромен (более 200 пунктов), поэтому рассмотрим только ключевые и заметные для пользователей моменты.

Значительно уменьшено потребление памяти для выполнения операций (уменьшение почти в два раза). Это значит, что с ветками с большой историей работать будет быстрее и комфортнее.
Добавлен новый хук для объединения файлов. Теперь становится возможным для файлов разных типов определять различные алгоритмы объединения изменений. Для использования этой возможности необходимо будет написать соответствущий плагин.

В качестве примера такого плагина вместе с bzr поставляется плагин news_merge, который должен облегчить процесс объединения изменений в файле NEWS в исходном коде самого bzr. (Файл NEWS в bzr редактируется очень часто, поэтому конфликты возникают очень часто).
В файле .bzrignore теперь можно задавать шаблоны для отключения игнорирования специфичных файлов. Для этого используйте восклицательный знак (!) в начале шаблона.
Например, игнорируем все файлы кроме *.py:
```
* 
!*.py
```
Функция shelve: теперь имеется возможность использовать внешний редактор для редактирования изменений, которые должны быть отложены "на полочку". Для этого нужно указать редактор в файле конфигурации как опцию change_editor, например:
```
change_editor = vimdiff -fo @new_path @old_path
```
здесь @new_path и @old_path специальные макросы для подстановки пути к текущей версии файла и зафиксированной его версии.
Новая опция unshelve --preview для просмотра отложенных изменений
Для checkout теперь можно сделать switch --revision, update --revision
При указании ревизии опцией --revision (-r) теперь можно использовать более простой синтаксис в стиле "делай то, что я имею в виду" (DWIM). Т.е. вместо -r tag:foo можно использовать просто -r foo, а вместо -r date:today просто -r today. Префиксы по прежнему можно использовать, и они могут понадобиться в случаях, когда bzr не сможет угадать правильный вариант (например тег 1.1.1 может совпадать с номером ревизии 1.1.1).
На Windows в командной строке поддерживаются маски для имен файлов, как на Linux. Раньше такая поддержка существовала в специфичном виде только для команды bzr add, теперь же она реализована в общем виде для всех команд. Поэтому теперь для добавления маски *.obj в файл .bzrignore командой bzr ignore вам нужно позаботиться о том, чтобы аргумент *.obj был взят в кавычки.
Поддержка знака тильды (~) как домашнего каталога пользователя в URL вида bzr+ssh://host/~
Появился новый раздел в документации: Bazaar System Administrator’s Guide
Значительно переработана документация по плагинам. Кроме основных сведений также содержит автоматически сгенерированную документацию по всем публичным плагинам.

Кроме изменений в самом bzr множество изменений в сопутствующих инструментах и плагинах. Так GUI для bzr Bazaar Explorer меньше чем за 9 месяцев доросло до версии 1.0, с чем мы и поздравляем его автора Йена Клэтворси (Ian Clatworthy).

Разработчики bzr объявили, что предыдущая стабильная версия bzr 2.0 (текущий релиз по состоянию на февраль 2010 — это 2.0.4) будет поддерживаться и далее, но настоятельно рекомендуют переходить на 2.1. Серия 2.1 будет поддерживаться в течение года (как минимум), она же будет включена в дистрибутив Ubuntu Lucid.

Сморите также:

Уникальные идентификаторы файлов в bzr

2010-02-07T05:49:00.001Z

Как я уже упоминал в статье "одна ветка = один каталог" bzr унаследовал из baz такую особенность как уникальные идентификаторы файлов. В этой статье рассмотрим идентификаторы подробнее.

В примерах использовался bzr версии 2.1.

Для чего нужны идентификаторы файлов

Для каждого файла, каталога или симлинка Bazaar использует внутри некий уникальный идентификатор, аналогично уникальным идентификаторам ревизий. Присвоение каждому версионированному объекту идентификатора упрощает отслеживание переименований/перемещений файлов и каталогов. Таким образом операция получения журнала ревизий для одного файла, а также операция объединения изменений в разных ветках, — эти операции работаю гораздо эффективнее поскольку им не требуется отслеживать все прошлые переименования. Чтобы получить копию файла из прошлой ревизии через команду

bzr cat -rN file

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

Уникальные идентификаторы назначаются в момент добавления файлов/каталогов под контроль версий командой add и затем в течении жизни файлов/каталогов уже не меняются.

Уникальные идентификаторы файлов можно посмотреть с помощью команды bzr ls --show-ids:

$ bzr ls --show-ids
bar.txt    bar.txt-20100207052407-e0zzku5zxmzfsso8-1
foo/       foo-20100207052337-rv090vn2o3x0m720-1

Проблемы с идентификаторами файлов

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

Текущая реализация идентификаторов файлов в bzr страдает следующими недостатками:

Один и тот же файл добавленный в разных ветках одного и того же проекта будет иметь разный идентификатор. Что при последующем объединении веток приведет к проблеме: bzr будет считать эти два файла абсолютно разными. В результате вы получите конфликт объединения и вам придется выбрать какой файл оставить, а какой удалить (и соответственно потерять историю изменений). Изменения между версиями из разных веток придется объединять вручную.
Если вы отмените контроль версий для файла командой bzr remove file а затем передумаете и снова добавите его командой bzr add file, то команда add назначит файлу новый уникальный идентификатор, соответственно история файла прервется и начнется с нуля.
Текущая реализация уникальных идентификаторов в bzr препятствует реализации функции создания копий файлов (аналогично svn copy или hg copy).

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

В теории эти недостатки можно преодолеть, и главные разработчики bzr даже имеют определенные планы на этот счёт. Но по состоянию на версию bzr 2.1 эти планы еще не реализованы и сложно сказать когда они все-таки будут реализованы.

Проблемы 1 и 2 из списка выше возможно решить в текущей версии bzr с помощью определенных техник.

Использование bzr add --file-ids-from

Поскольку bzr назначает уникальный идентификатор во время выполнения команды bzr add, то для частичного преодоления проблемы номер 1 из списка выше (один и тот же файл добавленный в разных ветках будет иметь разные идентификаторы) можно воспользоваться опцией --file-ids-from команды add. Эта опция в качестве своего аргумента принимает путь к другой ветке и для всех новых файлов, имена которых совпадают с именами файлов в той другой ветке, используются уникальные идентификаторы из другой ветки. Таким образом можно избежать расхождения идентификаторов.

Пример:

C:\work\bzr-day\file-ids>bzr init a

C:\work\bzr-day\file-ids>bzr mkdir a/foo
added a/foo

C:\work\bzr-day\file-ids>bzr commit -m1 a
Committing to: C:/work/bzr-day/file-ids/a/
added foo
Committed revision 1.

C:\work\bzr-day\file-ids>echo > a/bar.txt

C:\work\bzr-day\file-ids>bzr add a
adding bar.txt

C:\work\bzr-day\file-ids>bzr ls a --show-ids
a/bar.txt    bar.txt-20100207052407-e0zzku5zxmzfsso8-1
a/foo/       foo-20100207052337-rv090vn2o3x0m720-1

Теперь создадим копию ветки а для ревизии 1 и также попробуем добавить файл bar.txt:

C:\work\bzr-day\file-ids>bzr branch a b
Branched 1 revision(s).

C:\work\bzr-day\file-ids>echo > b/bar.txt

C:\work\bzr-day\file-ids>bzr add b
adding bar.txt

C:\work\bzr-day\file-ids>bzr ls b --show-ids
b/bar.txt    bar.txt-20100207052932-m88m6b14qvdroa2s-1
b/foo/       foo-20100207052337-rv090vn2o3x0m720-1

Как мы видим уникальные идентификаторы для файла bar.txt в разных ветках различаются.

Повторим те же действия, но файл будем добавлять с опцией --file-ids-from:

C:\work\bzr-day\file-ids>bzr branch a c
Branched 1 revision(s).

C:\work\bzr-day\file-ids>echo > c/bar.txt

C:\work\bzr-day\file-ids>bzr add c --file-ids-from a
adding bar.txt w/ file id from bar.txt

C:\work\bzr-day\file-ids>bzr ls c --show-ids
c/bar.txt    bar.txt-20100207052407-e0zzku5zxmzfsso8-1
c/foo/       foo-20100207052337-rv090vn2o3x0m720-1

Теперь файл bar.txt добавлен с тем же самым уникальным идентификатором.

Восстановление контроля версий для файла после команды bzr remove

Выше указывалось, что вторым недостатком уникальных идентификаторов является то, что файл удаленный из-под контроля версий командой bzr remove при последующем добавлении командой bzr add получит новый уникальный идентификатор. Как следствие для такого файла прервется история. Если вы не хотите терять историю, то вместо использования bzr add для восстановления файла вам необходимо использовать команду bzr revert. В этом случае файл будет восстановлен в последнем зафиксированном состоянии с правильным уникальным идентификатором.

Даже если вы удалили файл несколько ревизий назад, то используйте команду bzr revert -rN file, где N — это номер ревизии, предшествующей удалению файла.

Работа с bzr в централизованном стиле

2010-01-15T15:48:00.001Z

Наш читатель и автор плагина bzr-externals Евгений Тарасенко рассказывает о работе с Bazaar в централизованном стиле (а-ля svn). Передаю ему слово.

Централизованный стиль

В данной статье я хотел бы обратить внимание на еще один вариант организации работы с системой контроля версий Bazaar, о котором часто забывают в пылу погони за ветками и DVCS. Я говорю о централизованном стиле работы, который используется в Subversion, но в отличии от последнего Bazaar предоставляет намного более гибкий и главное понятный инструмент разработчику. Так в нашем распоряжении оказываются: понятная история ветвлений (попробуйте bzr qlog), локальные фиксации, откат и много других приятных мелочей. Также не стоит забывать что Bazaar расширяемая система и если вам там чего-то не хватает, то можно попробовать написать это самому!

Итак, чем хорош централизованный стиль:

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

во-вторых, если вы используете С++ компилятор то количество дополнительных файлов просто съест ваше время и место на жестком диске при каждом новом построении, а при работе с ветками неизбежно придется компилировать и отлаживать сначала ветку, а после слияния и trunk

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

Про TortoiseBzr

Для начала, я хотел бы обратить внимание на тот факт, что при установке Bazaar под Windows по умолчанию отключен модуль TortoiseBzr, скорее всего это связано с его некоторой задумчивостью при обновлении статуса иконок файлов, частенько бывает нужно пару раз F5 нажать, чтобы он сообразил что к чему. Поэтому если вы любитель работы из проводника проверьте, что он у вас установлен.

Базовый набор команд

Поскольку Bazaar поддерживает различные псевдонимы (алиасы) для команд, то вы можете выбрать для себя наиболее удобный вариант использования:

checkout, co, qgetnew — извлечь рабочую копию
commit, ci, qcommit, qci — фиксировать изменения
update, up, qupdate, qup — обновить рабочую копию

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

Извлечение проекта из хранилища

Команда:
bzr checkout bzr://server/project/trunk project
или из контекстного меню проводника: 'Bazaar Checkout/Branch…'

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

Внесение изменений

После внесения локальных изменений (непосредственно программирования) у нас есть два пути.

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

bzr update

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

И фиксируем наши изменения в хранилище:

bzr qcommit

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

bzr qcommit --local

либо через контекстное меню 'Bazaar Commit…' и выбором пункта 'Локальная фиксация'

Команда выполняется столько раз, сколько требует логика разработчика, обычно стараются делать одно функциональное изменение = одна фиксация, но это уже из области best practice.

После окончания разработки и последней локальной фиксации, действуем по схеме 1:

bzr update

И вот тут происходит самое интересное, запустите:

bzr qlog

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

Тестируем наши объединенные изменения и если все нормально фиксируем в хранилище:

bzr qcommit

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

Как отменить merge сделанное в результате bzr update

Хочу предупредить, если после update у вас что-то пошло не так или вы просто передумали объединять ваши изменения, то не спешите использовать команду revert. Эта команда отменит неоконченное объединение и ваши изменения. Ваши локальные ревизии никуда не исчезнут, они останутся в хранилище истории локального дерева файлов. Но вы не вернетесь к своей локальной истории, а напротив останетесь с историей из основной ветки.

Для возвращения к локальной истории вам необходимо узнать идентификатор последней ревизии в вашей локальной истории. Проще всего это сделать при помощи GUI команды qlog, но можно и воспользоваться командой heads из плагина bzrtools.

В случае использования qlog выделите ревизию, помеченую ярлыком Pending Merge и затем в нижнем левом окне в первой строке с версией найдите подстроку вида revid:xxxx, в нашем примере это revid:_-20100111130959-gd9bfn7z2mxxixx3. Выделите ее мышкой и скопируйте в буфер обмена.

Затем закройте qlog и выполните следующие команды:

bzr revert
bzr unbind 
bzr pull . --overwrite -r revid:_-20100111130959-gd9bfn7z2mxxixx3
bzr bind

Команде pull вы должны передать идентификатор ревизии локальной истории, тот самый, который мы скопировали из окна qlog.

Идентификатор ревизии локальной истории можно также получить при помощи команды heads из плагина bzrtools. Для этого запустите следующую команду:

bzr heads --dead-only

В ответ она выведет информацию следующего вида:

C:\work\bzr-day\Centralised\trunk>bzr heads --dead
HEAD: revision-id: _-20100111130959-gd9bfn7z2mxxixx3 (dead)
  committer: Базарный день
  branch nick: trunk
  timestamp: Mon 2010-01-11 15:09:59 +0200
  message:
    локальная фиксация №2

В строке "HEAD: revision-id:" показан нужный нам идентификатор. Опять же копируем его и запускаем те же действия:

bzr revert
bzr unbind 
bzr pull . --overwrite -r revid:_-20100111130959-gd9bfn7z2mxxixx3
bzr bind

Даже если вы сделали revert до того, как посмотрели идентификатор локальной ревизии через qlog — не паникуйте, а используйте второй способ с командой heads.

Замечание редакции: если вы используете локальные фиксации, то перед выполнением команды bzr update убедитесь, что все ваши изменения зафиксированы командой commit, либо отложены "на полочку" командой shelve. Иначе вы их легко потеряете при выполнении команды revert. Однако, вместо локальных фиксацией всё-таки более безопасно использовать либо отдельную ветку либо отдельную рабочую копию.

Заключение

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

Модель "одна ветка = один каталог" в bzr

2009-12-13T15:01:00.005Z

Немного истории

Современная система контроля версий Bazaar имеет свои корни в другой распределенной системе: GNU Arch. У системы Arch было несколько форков (разновидностей), одни из которых также назывался Bazaar (baz). Arch критиковали за излишнюю сложность интерфейса и трудность в освоении. Собственно современный Bazaar (bzr) появился как замена старому baz, и главной целью разработки нового bzr было именно упростить интерфейс пользователя системы, сделать систему удобной и лёгкой в использовании.

По большей части новый bzr добился своей цели (удобства использования). Однако при этом некоторые особенности модели системы Arch перекочевали в том или ином виде в новый Bazaar (bzr). И это накладывает свой отпечаток на работу самой системы и на работу пользователей с системой.

Следует заметить, что старый baz и новый bzr — обе эти системы разрабатывались и разрабатываются в основном за счет финансовой помощи компании Canonical Ltd, широко известной благодаря своему дистрибутиву Linux: Ubuntu.

Также следует отметить, что разработка нового bzr была задумана в ноябре 2004 года и официально началась в февраля 2005 года, на несколько месяцев ранее начала работ над git и hg. До первой половины 2006 года bzr развивался совершенно самостоятельно, как продолжатель baz. После стали очевидны успехи новых систем git и hg, особенно в плане показателей скорости, в результате чего внутренние алгоритмы bzr и форматы хранения данных в репозитории стали постепенно оптимизировать и улучшать в плане скорости работы. Однако несколько фундаментальных особенностей, унаследованных из baz/Arch, остались и до сегодняшнего дня. Понимание этих особенностей поможет вам более эффективно использовать bzr.

Унаследованные особенности

Основные особенности, унаследованные из Arch:

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

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

Каждая ветка живет в отдельном каталоге

Основная модель работы с ветками в bzr — это размещение каждой ветки в отдельном каталоге. У такого метода есть ряд плюсов и ряд минусов.

К плюсам можно отнести следующее. Каждая ветка однозначно присутствует как объект файловой системы, поэтому с ней можно оперировать средствами самой файловой системы, т.е. переименовывать, перемещать или удалять. Каждая ветка однозначно идентифицируется своим расположением, поэтому для доступа к ней достаточно использовать простой путь (для локального доступа) либо URL (для удаленного доступа), т.е. нет необходимости указывать URL + собственно имя ветки. Присутствие одной ветки в одном месте позволяет эффективно реализовать идею mainline. Каждая ветка хранит полную копию истории и полный набор рабочих файлов, что позволяет легко сравнивать и одновременно работать с несколькими ветками, которые содержат незафиксированные изменения.

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

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

Рассмотрим внимательно минусы. Они известны давно и для их нивелирования существует ряд методик эффективного использования bzr. Все указанные проблемы (каждая ветка занимает много места, долгое создание новой ветки, разделение одной рабочей копии) эффективно решаются при использовании разделяемого (или общего) репозитория (shared repository). Таким образом указанные минусы нивелируются использованием shared repository и остается лишь маленький недостаток: по умолчанию разделяемый репозиторий не создается сам по себе, его нужно создавать явно, командой init-repository.

Будем предельно честными: bzr позволяет эффективно работать с ветками, но по умолчанию создает обычные ветки. Это недостаток, который особенно сильно влияет на восприятие системы новичками, пришедших в bzr из других систем (git/hg), в которых всегда ветки живут в едином каталоге и представляют собой лишь виртуальные имена для разных линий истории проекта.

Из-за непонимания этого факта bzr много и не всегда оправданно критикуют.

Эффективное использование bzr: разделяемые репозитории

Что такое разделяемый репозиторий (shared repository)?

Для того, чтобы понять, что такое shared repository (разделяемый или общий репозиторий), сначала рассмотрим внутреннее устройство bzr-ветки. Каждая ветка содержит указатель на последнюю зафиксированную ревизию, что однозначно определяет всю историю ветки, поскольку история имеет вид направленного графа. Каждая ветка должна иметь репозиторий, в котором хранятся зафиксированные ревизии и состояние всех файлов ветки для каждой ревизии. Также ветка может иметь рабочую копию (а может и не иметь).

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

Поэтому такой репозиторий (shared repository) является общим для нескольких веток, либо можно сказать, что несколько веток разделяют (совместно используют) один и тот же репозиторий.

Следует запомнить фундаментальную разницу между ветками и репозиториями в bzr и репозиториями в git/hg. В bzr под репозиторием в большинстве случае понимают именно разделяемый репозиторий, каждая ветка внутри него — это отдельный каталог. В git/hg в одном каталоге живет и репозиторий, и ветки, и присутствует рабочая копия.

Локальная работа с ветками в репозитории

Для локальной работы рекомендуется создавать разделяемый репозиторий командой:

bzr init-repo PATH

После чего создавать копию главной ветки с сервера внутри репозитория:

cd PATH
bzr branch bzr://server/project/trunk

А уже для конкретной работы над новыми функциями создавать новую ветку на основе локальной копии trunk:

bzr branch trunk new-feature
cd new-feature

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

Использование репозитория на сервере

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

bzr init-repo --no-trees URL

Опция командой строки --no-trees указывает, что по умолчанию рабочая копия для веток создаваться не будет.

Остальные операции с ветками можно производить как обычно.

Разделение одной рабочей копии между несколькими ветками

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

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

Для этого нужно создать отдельный репозиторий с указанием флага --no-trees, чтобы локальные ветки в этом репозитории не создавали ненужные рабочие копии. А затем нужно создать отдельную легковесную рабочую копию (lightweight checkout), не содержащую истории. Такая легковесная рабочая копия может быть создана даже за пределами репозитория.

bzr init-repo --no-trees PROJECT
bzr init PROJECT/trunk
bzr checkout --lightweight PROJECT/trunk work

В результате выполнения этой последовательности команд bzr создаст репозиторий в каталоге PROJECT, внутри репозитория создаст ветку trunk, и затем создаст рабочую копию в каталоге work.

Для создания новой ветки и одновременного переключения рабочей копии на нее можно использовать команду:

bzr branch --switch trunk new-feature

Переключение рабочей копии между ветками осуществляется командой switch:

bzr switch trunk

При переключении можно указать опцию --create-branch (-b), чтобы автоматически создать новую ветку:

bzr switch -b bugfix-123

Для получения списка веток в репозитории используйте команду:

bzr branches PROJECT

из плагина bzrtools.

Более подробный рассказ о нюансах работы с bzr в git-стиле будет дан в виде отдельной статьи.

Заключение

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

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

Недостатком можно назвать лишь то, что по умолчанию bzr работает в не самом оптимальном режиме, поэтому для достижения эффективности требуется сделать несколько больше телодвижений. Следует ли это считать смертельным недостатком? Уверен, что нет.

Впрочем, каждому решать самому. Помните лишь, что каждая из современных распределенных систем (git/hg/bzr) имеет как достоинства, так и недостатки. Однако очень часто значимость как плюсов, так и минусов, не абсолютна, а относительна, и зависит от конкретного проекта и предпочитаемого стиля работы. И часто одни недостатки компенсируются другими достоинствами.

Уборка мусора: команда bzr clean-tree

2009-12-11T12:22:00.004Z

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

И вот когда приходит время удалять это барахло, что вы делаете? Удаляете вручную?

Есть более удобный способ: использовать команду clean-tree (начиная с версии bzr 1.13 эта команда доступна в самом bzr, ранее эта команда жила в плагине bzrtools). Эта команда показывает вам список неизвестных (неверсионированных) файлов и предлагает их удалить. Просто и без затей.

Также эта команда имеет удобный ключ командной строки: --ignored. С этим ключом clean-tree будет удалять только игнорируемые файлы. Такая функция тоже бывает полезной, особенно если у вас нет make clean.

Приятной уборки!

Управление кодировкой файла при работе с QBzr (GUI для bzr)

2009-12-08T07:36:00.001Z

QBzr — это кросс-платформенный GUI плагин для bzr, использующий библиотеку Qt4/PyQt4. Мы рассмотрим вопрос управления кодировкой файлов для их корректного отображения в окнах QBzr.

QBzr и кодировки

Поскольку [Py]Qt4 ориентирована на использование unicode для отображения текстовых данных, то возникает небольшая проблема с файлами, содержащими неанглийские тексты (например, русский или японский). Для корректного отображения таких текстов QBzr необходимо знать кодировку, в которой был сохранен текст.

По умолчанию, QBzr предполагает, что текст имеет кодировку UTF-8 (с автоматическим переключением на Latin-1, если текст невозможно отобразить как UTF-8). Кодировка UTF-8 довольно популярна и используется на многих современных дистрибутивах Linux и Mac. Однако на Windows часто используется кодировка ANSI (например, cp1251 для русского текста), а на старых платформах — исторически сложившиеся кодировки (например, koi8-r для русского текста). Поэтому некоторым пользователям приходится указывать кодировку вручную одним из 3х способов:

указать кодировку в командной строке
указать кодировку в конфигурационном файле
указать кодировку непосредственно в диалоговом окне с отображаемым текстом

Рассмотрим эти методы подробнее.

Опция командной строки

Большинство команд, непосредственно отображающих содержимое файлов, таких как qdiff, qannotate, qcat и qviewer, имеют опцию командной строки --encoding. Эта опция позволяет напрямую задать кодировку файла из набора поддерживаемых библиотеками Python (полный список). Часто используемые кодировки для русского языка:

cp1251 (Windows ANSI)
cp866 (DOS/OEM)
koi8-r (Unix)

Для украинского языка аналогично: cp1251, cp866, koi8-u.

Настройки в конфигурационном файле

Кодировка, указанная опцией --encoding, либо выбранная непосредственно (см. ниже), сохраняется в конфигурационном файле текущей ветки (файл .bzr/branch/branch.conf) как опция:

encodng = xxx

Сохраненная кодировка будет использоваться по умолчанию при следующем запуске соответствующей команды QBzr.

Если вы постоянно работаете с одной и той же кодировкой (например, cp1251), то ее можно указать как кодировку по умолчанию для всех веток, прописав в главном конфигурационном файле bazaar.conf:

[DEFAULT]
email = Vasya Pupkin <vasya@pupkin.ru>
encoding = cp1251

Более тонкой настройки можно добиться при использовании конфигурационного файла locations.conf.

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

Непосредственное управление

Благодаря Наоки Инада (Naoki INADA) в QBzr 0.17 появилась возможность управлять кодировкой файла прямо из соответствующих диалоговых окон. В окнах для отображения diff, annotate, cat появился элемент (выпадающий список), позволяющий выбрать нужную кодировку. Это очень полезное улучшение, особенно для пользователей TortoiseBzr и Bazaar Explorer, поскольку эти программы никак не передают данные о кодировках в диалоговые окна QBzr.

Diff:

Annotate:

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

Новая версия QBzr 0.17 с показанным элементом выбора кодировок будет выпущена в середине декабря 2009. Однако уже сейчас эти улучшения доступны в ветке trunk2a.

Строгий контроль со стороны bzr

2009-12-04T00:00:00.008Z

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

Ситуация

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

Собрав всю волю в кулак, вы находите подозрительные места, дорабатываете код, добавляете новый модуль, фиксируете изменения, запускаете, проверяете и ура? Нет, снова что-то не так... ах вот же она опечатка. Последние изменения, всё работает. И вы запускаете команду bzr push и передаете свою работу на сервер.

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

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

Ошибка №1: забыли добавить новые модули под контроль версий

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

В большинстве случаев подобного рода ошибки можно поймать внимательным просмотром вывода команд bzr status (до и/или после фиксации) и bzr diff. Но в пылу сражения может случиться всякое, особенно если вы фиксируете только часть изменений.

commit --strict

В таких ситуациях bzr может помочь если вы будете использовать опцию --strict для команды commit. Данная опция делает невозможным успешную фиксацию, если в рабочем каталоге присутствуют неизвестные файлы, которые не помещены под контроль версий командой add, и не соответствуют маскам игнорируемых файлов.

C:\work\bzr-day\strict>bzr ci --strict -m foo
Committing to: C:/work/bzr-day/strict/
aborting commit write group: StrictCommitFailed()
bzr: ERROR: Commit refused because there are unknown files in the working tree.

При использовании пользовательских псевдонимов вы можете включить эту опцию по умолчанию:

bzr alias commit="commit --strict"
bzr alias ci="commit --strict"

Ошибка №2: последние изменения не зафиксированы, push передает на сервер неокончательный код

С этой ситуацией более-менее понятно. Push работает на уровне зафиксированной истории ветки, поэтому состояние рабочих файлов для него проверять не обязательно.

Опять же внимательный просмотр вывода команды bzr status поможет поймать такого рода ошибки.

push --strict

К счастью, начиная с версии bzr 1.17 команда push автоматически проверяет рабочее дерево файлов на наличие незафиксированных изменений, включая неоконченное объединение. И отказывается работать, если таковые обнаружатся:

C:\work\bzr-day\strict>bzr push ../foo
bzr: ERROR: Working tree "C:/work/bzr-day/strict/" has uncommitted changes (See bzr status). Use --no-strict to force the push.

Как видно, эту проверку можно отключать, указывая опцию --no-strict.

push --no-strict

Если подобная проверка вам почему-то не по душе, то не спешите заводить новый пользовательский псевдоним для команды push, а используйте опцию push_strict в файле конфигурации bazaar.conf или branch.conf. Например:

push_strict = False

Заключение

Мы рассмотрели две встроенные функции bzr для контроля и предотвращения некоторых распространенных ошибок при выполнении операций commit и push. Как указывалось, такие ошибки можно отловить при внимательном анализе вывода команды status. Но в том-то и дело, что подобные ошибки случаются когда смотрят не внимательно или не смотрят вообще.

Дополнительные проверки, специфичные для конкретного проекта, можно осуществлять через функции-хуки, например хуки для событий pre_commit или pre_change_branch_tip. В качестве примера pre_commt хука см. плагин checkeol, который может осуществлять проверку концовок строк в фиксируемых файлах.

Статьи про bzr в блоге Kash Farooq

2009-12-02T22:20:00.000Z

Kash Farooq (Каш Фарук), .NET разработчик из Великобритании, опубликовал в своем блоге ряд статей про bzr.

Затрагиваемые темы: работа с Subversion при помощи плагина bzr-svn, описания настроек внешних GUI утилит для объединения изменений и решения конфликтов, операции объединения и переименования в bzr.

__________________

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

Если вы знаете такие блоги или сами регулярно публикуете материалы на эту тему, то оставляйте ссылки в комментариях либо присылайте электропочтой.

Пользовательские псевдонимы команд bzr (aliases)

2009-11-30T00:00:00.007Z

Bazaar имеет весьма интересную и полезную функцию тонкого тюнинга: поддержку для определяемых пользователем псевдонимов для команд (aliases). Псевдонимы позволяют определять команды с нужными опциями и параметрами по умолчанию, и даже переопределять встроенные команды. При умелом использовании псевдонимы могут значительно упростить повседневное использование bzr из командной строки.

Отличие пользовательских псевдонимов от встроенных псевдонимов команд

Большинство стандартных команд bzr и даже команд, добавляемых плагинами, имеют заранее предопределенный набор альтернативных имен (псевдонимов) для вызова этих команд. Так, команда commit имеет псевдонимы ci и checkin, а status — st и stat, и т.п. Эти псевдонимы выводятся при запросе справки на конкретную команду (bzr xxx --help или bzr xxx --usage).

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

Как работают пользовательские псевдонимы

Пользователь может определить псевдоним, как некоторое имя, и связать с этим именем существующую команду bzr и дополнительно какие-то опции и параметры. Тогда при вызове команды как:

bzr имя_псевдонима [опции аргументы]

вместо имени псевдонима будет подставляться значение псевдонима: определенная ранее реальная команда bzr + дополнительные параметры.

При этом опции псевдонима могут переопределяться в конкретной командной строке: просто укажите новое значение и bzr будет использовать последнее определенное значение опции при запуске команды. Для отмены действия булевой опции используйте префикс no, например: --short => --no-short.

У псевдонимов есть еще одно интересное свойство: вы можете в качестве имени псевдонима использовать имя существующей команды bzr. Это особенно полезно в тех случаях, когда вы хотите "навсегда" поменять поведение какой-то команды по умолчанию. Например, чтобы вывод команды status имел компактный вид применяется опция --short или -S. Если вы предпочитаете всегда использовать такую форму вывода информации, то можете определить псевдоним

status = status --short

Следует однако помнить, что все встроенные альтернативные имена команд (о которых упоминалось ранее) автоматически не переопределяются при переопределении команды. Поэтому если вы определили псевдоним для status как описано выше, то запуск bzr st будет производиться обычным (не переопределенным) способом.

Как определить свой псевдоним

Определения пользовательских псевдонимов хранятся в файле bazaar.conf (~/.bazaar/bazaar.conf на Linux и C:\Documents and Settings\USERNAME\Application Data\bazaar\2.0\bazaar.conf на Windows) внутри секции [ALIASES]. Определения псевдонимов имеют простую форму:

имя_псевдонима = имя_команды [опции]

Для определения новых псевдонимов или редактирования старых вы можете как напрямую редактировать файл bazaar.conf, так и использовать встроенную команду alias, либо воспользоваться GUI диалогами из плагинов QBzr (команда qconfig) или bzr-gtk (команда gpreferences).

Использование команды bzr alias

Запуск команды bzr alias без параметров выведет список уже определенных вами псевдонимов.

Для определения нового псевдонима используйте синтаксис:

bzr alias имя_псевдонима="значение"

(Не забывайте использовать кавычки если значение псевдонима состоит из имени команды bzr и набора опций по умолчанию).

Например:

bzr alias st="status --short"

Для удаления ранее определенного псевдонима используйте опцию --remove:

bzr alias st --remove

Примеры псевдонимов

Кроме уже упомянутого ранее псевдонима для status --short рассмотрим еще несколько примеров полезных псевдонимов.

Получать вывод команды missing в формате в максимально сжатом виде (1 ревизия на строку):

miss = missing --line

Получить список десяти последних ревизий в компактном виде:

last = log -l10 --short

Вывод максимальной информации в аннотации файла:

ann = annotate --long

Всегда удалять файлы из-под контроля bzr без удаления их с диска:

forget = remove --keep

Матерые пользователи darcs могут захотеть определить псевдоним:

whatsnew = diff

Примечание: примеры выше даны в нотации, подходящей для помещения в конфигурационный файл bazaar.conf. Для установки их в командной строке через команду bzr alias используйте форму имя="команда опции".

Вредные советы

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

ci = revert --no-backup

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

Временное отключение пользовательских псевдонимов

Иногда может оказаться полезным отключить псевдонимы. Например, когда возникают непонятные ошибки.

Глобальная опция --no-aliases, заданная до имени команды, поможет вам в этом:

bzr --no-aliases xxx

Совет: опции --no-plugins и --no-aliases целесообразно использовать при замерах скорости работы bzr.

Заключение

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

Встроенная справочная служба bzr: получение списка аргументов и опций для команды

2009-11-27T00:00:00.000Z

У встроенной справки bzr на команды есть один маленький недостаток: при попытке получить справку для нетривиальной команды как правило на терминал выводится огромное описание возможностей команды и вариантов ее использования. При этом собственно информация о списке аргументов и опций команды выводится в самом начале текста справки, и чтобы увидеть этот список приходится пользоваться программами-пейджерами типа more или less.

К счастью в bzr версии 1.14 появилось очень удобное дополнение: при запуске команды с опцией --usage на экран выводится краткая справка по команде, которая содержит только назначение команды (1 строка) и список аргументов и опций командной строки. Очень удобно, когда запамятовал как называется (правильно пишется) нужная опция.

Сравните вывод bzr add --help и bzr add --usage:

C:\>bzr add --usage
Purpose: Add specified files or directories.
Usage:   bzr add [FILE...]

Options:
  --dry-run            Show what would be done, but don't actually do
                       anything.
  -v, --verbose        Display more information.
  --file-ids-from=ARG  Lookup file ids from this tree.
  --no-recurse         Don't recursively add the contents of directories.
  -q, --quiet          Only display errors and warnings.
  --usage              Show usage message and options.
  -h, --help           Show help message.

See bzr help add for more details and examples.

See also: ignore, remove

Подробнее о встроенной справочной службе можно прочитать в статье "bzr help: встроенная справочная служба класса "люкс" (Часть 1, Часть 2)"

Список статей блога bzr-day

2009-11-26T21:38:00.009Z

Список статей теперь находится на странице http://bzr-day.blogspot.com/p/bzr-day.html

Общие сведения

Концепции

Mainline: главная линия разработки и номера ревизий (Часть 1, Часть 2, Часть 3)

Настройки

Справка по bzr

bzr help: встроенная справочная служба класса "люкс" (Часть 1, Часть 2)
Встроенная справочная служба bzr: получение списка аргументов и опций для команды

Работа с bzr

Исправление ошибок при работе с Bazaar
Начинаем работу с bzr: базовый набор команд (Часть 1, Часть 2)
Работа с ветками: push, pull, merge (Часть 1, Часть 2, Часть 3)
Работа в централизованном стиле

Рецепты

Дополнительно

Использование WebDAV для доступа к Bazaar-серверу

Плагины

bzr-svn

QBzr

Управление кодировкой файла при работе с QBzr (GUI для bzr)

Блоги

Статьи про bzr в блоге Kash Farooq

Список обновлен: 2010/01/15

Как добавить каталог без содержащихся в нём файлов?

2009-11-25T00:00:00.000Z

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

Как же быть, когда нужно добавить каталог, не добавляя все файлы (или подкаталоги) содержащиеся в нём?

Используйте опцию --no-recurse. Эта опция отключает обычное рекурсивное поведение и при её использовании будут добавлены только те каталоги (или файлы), которые явно указаны в командной строке.

Сравните обычное рекурсивное поведение:

C:\work\bzr-day\add>bzr st
unknown:
  foo/

C:\work\bzr-day\add>dir /b foo
eggs
spam

C:\work\bzr-day\add>bzr add foo
adding foo
adding foo/eggs
adding foo/spam

И поведение при использовании опции --no-recurse

C:\work\bzr-day\add>bzr st
unknown:
  foo/

C:\work\bzr-day\add>bzr add foo --no-recurse
adding foo

C:\work\bzr-day\add>bzr st
added:
  foo/
unknown:
  foo/eggs
  foo/spam

Mainline: главная линия разработки и номера ревизий (Часть 3)

2009-11-22T18:07:00.002Z

Это заключительная статья с рассказом о концепции mainline в Bazaar (предыдущие части первая и вторая). Я должен признать, что несмотря на то, что сама концепция mainline достаточно проста, но рассказать про нее просто и понятно у меня получается не так хорошо, как хотелось бы. Поэтому в начале этой части я снова повторю некоторые ключевые особенности концепции mainline и затем расскажу как она влияет на работу с Bazaar.

Концепция mainline

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

Благодаря тому, что в Bazaar используется модель "одна ветка в одном каталоге", то концепция mainline становится возможной и в некотором смысле логичной.

Наибольшее значение концепция mainline приобретает для главной ветки проекта (trunk), в которой должен находится только проверенный и рабочий код. При максимальном использовании mainline ни одна новая функция или багфикс не фиксируются напрямую в trunk, а всегда присоединяются (командой merge). При этом история в trunk представляет собой четкий список новых функций и улучшений.

Наиболее полно этот принцип используется самими разработчиками Bazaar. Если посмотреть на журнал ревизий ветки с кодом bzr, то мы увидим историю в виде списка улучшений и добавлений:

C:\work\Bazaar\bzr-2a\bzr.dev>bzr log -l10 --short
 4819 Canonical.com Patch Queue Manager 2009-11-20 [merge]
      (jam) Fix bug #485771,
        only change slashes on arguments that are being globbed.

 4818 Canonical.com Patch Queue Manager 2009-11-20 [merge]
      (jam) Add a developer doc describing dependencies for win32 builds

 4817 Canonical.com Patch Queue Manager 2009-11-20 [merge]
      (igc) Trivial formatting fix to merge help

 4816 Canonical.com Patch Queue Manager 2009-11-20 [merge]
      (igc) Explain that .bzrignore is implicitly added (Patrick Regan,
        #59608)

 4815 Canonical.com Patch Queue Manager 2009-11-19 [merge]
      (jam) Fix CommitBuilder.inv_sha1 when using record_iter_changes.

 4814 Canonical.com Patch Queue Manager 2009-11-19 [merge]
      (jam) Release the gil during some of the core groupcompress code
        paths.

 4813 Canonical.com Patch Queue Manager 2009-11-19 [merge]
      (jam) Remove a @needs_read_lock decorator from something that doesn't
        really need it.

 4812 Canonical.com Patch Queue Manager 2009-11-19 [merge]
      (Alexander Sack) Add --commit-time option to 'bzr commit'. (#459276)

 4811 Canonical.com Patch Queue Manager 2009-11-19 [merge]
      (Andrew Bennetts) Add 'Bazaar Contribution in Five Minutes'
        introduction to developer docs.

 4810 Canonical.com Patch Queue Manager 2009-11-18 [merge]
      (jam) Last few tweaks to get the win32 test suite to pass.

Use --include-merges or -n0 to see merged revisions.

Разделение ревизий на 2 группы

Как отмечено выше концепция mainline делит все ревизии в ветке на две неравные группы:

ревизии, непосредственно зафиксированные в конкретной ветке
ревизии, присоединенные из других веток командой merge

Последовательность ревизий из 1й группы образует "основную" историю ветки, или mainline. Иногда еще эту последовательность называют "left-hand history", поскольку при выводе журнала ревизий основная группа отображается начиная с крайней левой колонки, в то время как присоединенные ревизии выводятся в журнале с отступом.

Второе неравенство между группами ревизий заключается в том, что для "основной" истории ревизии нумеруются целыми числами, начиная с 1 для первой ревизии. Присоединенные ревизии нумеруются по сложной "точечной" схеме M.B.N, где

M — это основная ревизия, от которой отпочковалась ветка,
B — это условный порядковый номер ветки (чтобы различать несколько веток отпочковавшихся из одной и той же основной ревизии)
N — это номер ревизии в ветке, после отпочкования

Собственно номера ревизий — это одно из наиболее заметных проявлений концепции mainline. Рассмотрим теперь как mainline влияет на различные команды bzr.

Журнал ревизий

Как уже отмечалось, журнал ревизий выводит основные и присоединенные ревизии немного по-разному. Прежде всего присоединенные ревизии выводятся с отступом. А в последних версиях bzr присоединенные ревизии по умолчанию не отображаются (это сделано из соображений производительности). Для того, чтобы увидеть присоединенные ревизии необходимо использовать опцию командной строки --include-merges или -n0:

C:\work\Bazaar\bzr-2a\bzr.dev>bzr log -r-1 --short -n0
 4819 Canonical.com Patch Queue Manager 2009-11-20 [merge]
      (jam) Fix bug #485771,
        only change slashes on arguments that are being globbed.

       4818.1.1 John Arbash Meinel      2009-11-20
                Fix bug #485771. Only change '/' to '/' when expanding globs.

                The code we had would replace '/' even if it was in a quoted section,
                or if it was part of a simple argument that didn't have a glob.

При просмотре ревизий в GUI окне команды qlog присоединенные ревизии скрыты и помечены значком +:

Щелчком мышки по значку + (либо нажатие стрелки вправо при использовании клавиатуры) раскрывает присоединенные ревизии:

Объединение двух веток

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

Рассмотрим несколько типовых случаев. Приведенные ниже примеры и рекомендации имеют смысл только если ваша команда разработчиков договорилась использовать парадигму mainline.

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

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

При длительной работе над новой функцией в отдельной (функциональной) ветке зачастую приходится делать merge новых изменений из других веток (либо из главной ветки). Это может требоваться для того, чтобы задействовать новую функциональность, необходимую для вашей работы. Либо для того, что решить возможные конфликты из-за радикальных изменений (например рефакторинга) в основной ветке.

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

Объединение главной ветки и нового кода из функциональной ветки

Когда работа над новой функциональностью закончена и вы готовы объединить свой новый код с главной веткой, то необходимо помнить, что основная история в главной ветке должна оставаться неизменной. Поэтому вы должны присоединить свою ветку в главную ветку. Часто эту операцию называют land или landing (посадка, приземление).

Для выполнения объединения-приземления удобно использовать локальную копию главной ветки. Перед объединением вы обновляете локальную копию главной ветки (командой pull). Затем из каталога с копией главной ветки запускаете команду merge:

bzr merge ../my-work

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

Такой порядок действия хорошо работает в небольших командах, где каждый может делать push в главную ветку. В тех командах, где присоединением новых веток в главную занимается специальный человек (gatekeeper) или объединение производится специальной программой (так например в проекте Bazaar объединением с основной веткой занимается PQM — программа-работ, получающая инструкции через электронную почту), в этом случае целесообразно сделать merge из главной ветки в свою функциональную ветку перед подачей заявки на объединение с главной веткой. Это merge позволит вам исправить все возможные конфликты и следовательно упростит процедуру включения ваших изменений.

Когда объединение делать необязательно?

Продолжая тему объединения новой функциональности с главной веткой рассмотрим вопрос: всегда ли нужно использовать merge для этого?

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

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

Если все ваши изменения уместились в одну ревизию, то в этом случае выбор за вами: делать merge или push. Операция merge может оказаться полезной тем, что вы сможете написать другой комментарий к вашим изменениям, более уместный в контексте главной ветки.

Push/pull и основная история

Следует знать и всегда помнить о том, что операции push и pull могут поменять основную историю ветки. В некотором смысле даже без вашего желания. Это происходит в тех случаях, когда одна ветка была объединена с другой.

Pull

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

Push

Наиболее частая ошибка при объединении функциональной ветки с главной веткой, это когда merge делается в функциональную ветку (вместо копии главной ветки). В этом случае push из функциональной ветки в главную ветку становится возможным. Но делать такой push — очень плохая идея, потому что при этом изменяется нумерация ревизий в главной ветке: push при этом меняет mainline главной ветки на mainline функциональной ветки. Так делать не следует. Как было описано выше правильно делать merge в локальную копию главной ветки и делать push оттуда.

Хотя подобный push не является фатальным сам по себе, его следует избегать. Потому что если кто-то другой зафиксирует новую ревизию после того, как основная история была изменена, это превратится в проблему.

append_revisions_only

В bzr существует способ запретить изменение основной истории ветки.

Если при создании ветки указать опцию --append-revisions-only, то для такой ветки устанавливается флаг, запрещающий изменение основной истории за исключением добавления новых ревизий. Т.е. запрещаются операции uncommit и pull/push, если в результате pull/push существующие mainline ревизии могут быть заменены другими с одинаковыми номерами.

Флаг append_revisions_only можно установить и позднее, после того как ветка создана. Для этого необходимо добавить следующую строку в файл конфигурации branch.conf (он находится в .bzr/branch/branch.conf):

append_revisions_only = True

Установка такого флага возможна и для веток на Launchpad.net, хотя и не совсем тривиальным способом: вам понадобится использовать утилиту hitchhicker.

Заключение

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

Еще раз хочу отметить, что идея mainline уникальна для bzr и отсутствует в других распределенных системах контроля версий (git, hg). У идеи mainline есть свои достоинства и недостатки, и правильное использование mainline требует определенной внимательности и соглашений в команде разработчиков.

Использование Bazaar для работы с Subversion-репозиториями

2009-10-16T07:19:00.000+01:00

Продолжаем тему работы с bzr-svn.

John Szakmeister написал подробную статью Bazaar as Subversion "super client".

Ian Clatworthy (Йен Клатворси), который занимается документацией в проекте Bazaar, создал (полу) оффициальный документ Using Bazaar on Subversion projects. Документ описывает детали работы с Subversion-репозиторием при помощи Bazaar и bzr-svn.

В документе подробно описываются проблемы объединения svn-trunk с вашими bzr-ветками, применение rebase.

Читать: http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html

Работа с svn из bzr

2009-10-11T20:22:00.001+01:00

Иван Сагалаев делится опытом использования Bazaar и плагина bzr-svn для работы с SVN репозиторием:

Юра Юревич подбил меня недавно на пост про то, как я пользуюсь Subversion из Bazaar. Недавно Bazaar поменял мажорную версию на 2.0, и я решил, что пора.

Предыстория такова. В Яндексе много кода (бо́льшая часть наверное) хранится под управлением svn. Подозреваю, что мы не одни такие :-). Какое-то время назад меня стало точить настойчивое желание попользоваться или даже совсем переехать на какую-нибудь распределённую VCS. Волею случая выбор пал на bzr, я его попробовал, и вроде понравилось. Но на работе большую часть времени сидел всё равно под svn, чтобы работать с существующим кодом. Однако совсем недавно я вдруг сложил в голове несколько очевидных вещей, и теперь -- тадам! -- общаюсь со всем svn-кодом из bzr, используя все прелести последнего.

Теперь делюсь опытом.

Читать полностью: http://softwaremaniacs.org/blog/2009/10/11/svn-from-bzr/

Bazaar 2.0 и новый формат репозитория по умолчанию

2009-09-25T11:53:00.003+01:00

Сегодня 25 сентября и со дня на день всё прогрессивное человечество ожидает выхода новой версии bzr 2.0. Как видно из названия, эта версия не просто очередная версия bzr, одна из тех, что выходят почти каждый месяц. Это версия 2.0 (три восклицательных знака).

Одно из ключевых изменений в версии 2.0 — это новый формат репозитория, используемый по умолчанию, который называется 2a. Именно это изменение может стать серьезным камнем преткновения для некоторых пользователей, как оно почти стало для меня.

Проблема

Bazaar имеет заслуженную репутацию системы, в которой существует зоопарк форматов репозиториев. В настоящий момент число форматов превышает 10. История появления каждого формата отмечает этапы развития системы и путь, который bzr прошел ради достижения скорости работы, сравнимой с такими лидерами как Mercurial и Git.

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

Речь идет о различии между обычными форматами и так называемыми rich-root форматами. По историческим причинам rich-root формат появился для поддержки одной долгожданной функции bzr, которая впрочем до сих пор не реализована. Отличие между простыми форматами и rich-root заключается в наличии дополнительных метаданных о ветках. Форматы rich-root никогда не были рекомендуемыми, и не являлись форматом по умолчанию. Более того, поскольку дополнительная информация rich-root формата не может быть сохранена в простом формате, то вы не можете перейти от rich-root к простому формату. Вообще. Переход от простых форматов к rich-root возможен всегда. Причем, вы не сможете даже сделать pull или merge из rich-root в обычную ветку. Собственно это и составляет проблему: односторонний переход из одной группы форматов в другую.

Ящик пандоры открыл популярный плагин bzr-svn, который первым стал активно использовать формат rich-root при конверсии svn репозитория в bzr. Причины такого решения целиком логичные, однако имели далеко идущие последствия. Каждый новый формат в серии bzr 1.x всегда имел пару реализаций: простую и rich-root. Много раз подымался вопрос об их объединении в единый формат, однако по ряду причин это сделано только в новом формате 2a.

Новый формат bzr 2a поддерживает только rich-root, поэтому новые пользователи будут избавлены от имеющейся дихотомии.

Однако, все существующие репозитории и ветки должны быть либо обновлены до 2a или хотя бы до rich-root, чтобы избежать проблемы несовместимости форматов.

Пример несовместимости

Создадим ветку в формате pack-0.92 (основной формате в серии bzr 1.x, обычный не rich-root).

C:\work\bzr-day\Formats>bzr init 0.92 --format=pack-0.92 Created a standalone tree (format: pack-0.92) C:\work\bzr-day\Formats\0.92>bzr ci --unchanged -m 1 Committing to: C:/work/bzr-day/Formats/0.92/ Committed revision 1.

Сделаем копию этой ветки и сконвертируем ее в формат 2a.

C:\work\bzr-day\Formats>bzr branch 0.92 2a Branched 1 revision(s). C:\work\bzr-day\Formats\2a>bzr upgrade --format=2a starting upgrade of file:///C:/work/bzr-day/Formats/2a/ making backup of file:///C:/work/bzr-day/Formats/2a/.bzr to file:///C:/work/bzr-day/Formats/2a/backup.bzr starting repository conversion repository converted finished C:\work\bzr-day\Formats\2a>bzr info Standalone tree (format: 2a) Location: branch root: . Related branches: parent branch: C:/work/bzr-day/Formats/0.92 C:\work\bzr-day\Formats\2a>bzr ci --unchanged -m 2a Committing to: C:/work/bzr-day/Formats/2a/ Committed revision 2.
Зафиксируем еще одну ревизию в первой ветке:

C:\work\bzr-day\Formats\0.92>bzr commit --unchanged -m 2-0.92 Committing to: C:/work/bzr-day/Formats/0.92/ Committed revision 2.
И попробуем сделать объединение. Объединение из обычного формата в 2a работает без проблем:

C:\work\bzr-day\Formats\2a>bzr merge ../0.92 All changes applied successfully.
А вот в обратную сторону не работает вовсе:

C:\work\bzr-day\Formats\0.92>bzr merge ../2a bzr: ERROR: KnitPackRepository('file:///C:/work/bzr-day/Formats/0.92/.bzr/repository/') is not compatible with CHKInventoryRepository('file:///C:/work/bzr-day/Formats/2a/.bzr/repository/') different rich-root support

В последней строке явно виден корень проблемы: different rich-root support.

Проблема усугубляется тем, что конвертация из простого формата в rich-root может произойти неявно и без вашего ведома. Например, когда вы делаете копию не-rich-root ветки в разделяемый репозиторий (shared repository) в rich-root формате:

C:\work\bzr-day\Formats>bzr init-repo --2a shared-repo Shared repository with trees (format: 2a) Location: shared repository: shared-repo C:\work\bzr-day\Formats\shared-repo>bzr branch ../0.92 trunk Branched 2 revision(s). C:\work\bzr-day\Formats\0.92>bzr merge ../shared-repo/trunk bzr: ERROR: KnitPackRepository('file:///C:/work/bzr-day/Formats/0.92/.bzr/repository/') is not compatible with CHKInventoryRepository('file:///C:/work/bzr-day/Formats/shared-repo/.bzr/repository/') different rich-root support

Как узнать текущий формат ветки/репозитория

Команда bzr info -v отображает различную информацию о ветке/репозитории и в том числе формат репозитория.

C:\work\bzr-day\Formats\0.92>bzr info -v Standalone tree (format: pack-0.92) Location: branch root: . Related branches: submit branch: C:/work/bzr-day/Formats/2a Format: control: Meta directory format 1 working tree: Working tree format 4 branch: Branch format 6 repository: Packs containing knits without subtree support ...
В строке repository описан детальный формат. Если там написано without subtree support — это обычный не-rich-root формат.

C:\work\bzr-day\Formats\2a>bzr info -v Standalone tree (format: 2a) Location: branch root: . Related branches: parent branch: C:/work/bzr-day/Formats/0.92 submit branch: C:/work/bzr-day/Formats/0.92 Format: control: Meta directory format 1 working tree: Working tree format 6 branch: Branch format 7 repository: Repository format 2a - rich roots, group compression and chk inventories ...

Заметьте, что для 2a в описании формата присутствует упоминание rich roots.

Что делать

С первым вопросом русской интеллигенции мы разобрались выше, теперь перейдем ко второму вопросу. Ответ на него имеет несколько вариантов в зависимости от конкретной ситуации.

1. Конвертировать все свои ветки и репозитории в формат 2a

В долгосрочной перспективе наиболее правильное решение — это конвертация всех ваших репозиториев в формат, поддерживающий rich-root. В первую очередь в формат 2a.
Формат 2a поддерживается в bzr, начиная с версии 1.16. Поэтому если на всех компьютерах в вашей организации установлена достаточная свежая версия bzr вы можете пойти этим путём.

Рекомендуется сделать тестовое обновление на локальной машине. Перед обновлением целесообразно запустить команду bzr reconcile для исправления возможных нестыковок внутри репозитория. Затем кто-то один из вашей команды должен сделать обновление веток на центральном сервере, а затем остальные сделают новую копию главной ветки на свои компьютеры, или обновят все свои ветки в формат 2a.

Подробная инструкция по обновлению.
2. Конвертировать свои ветки в формат rich-root

Если по ряду причин в вашем ведении находятся компьютеры со старой версией bzr, либо вы используете сторонние продукты, которые зависят от старых версий bzr, то вы можете рассмотреть вариант обновления до формата rich-root-pack, который совместим с 2a. Рекомендации по последовательности обновления те же самые.

3. Не использовать bzr 2.0 и выше

Если по ряду причин вы не можете обновить часть компьютеров и не считаете целесообразным обновлять все ветки и репозитории в rich-root формат, то, возможно, вам стоит принять волевое решение не обновлять ни на одном подведомственном вам компьютере bzr до версии 2.0. Последняя стабильная версия из серии bzr 1.x — это bzr 1.18.

Однако рано или поздно перейти придётся. Хотя бы потому, что в новых версиях чинят старые баги.

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

Я написал маленький плагин format1, который устанавливает старый не-rich-root формат pack-0.92 в качестве формата по умолчанию для bzr. После установки этого плагина при каждом запуске bzr форматом по умолчанию будет устанавливаться pack-0.92. Поэтому все создаваемые с нуля новые ветки и разделяемые репозитории (что самое важное!) будут иметь формат pack-0.92. При этом пользователь может принудительно выбрать другой формат через опции командной строки.

Ветка плагина располагается на Launchpad: https://code.launchpad.net/~bialix/+junk/format1

Установка плагина: как обычно, поместите копию ветки в ваш каталог plugins.

ПРЕДУПРЕЖДЕНИЕ ОБ ОТКАЗЕ ОТ ОТВЕТСТВЕННОСТИ: написанный мною плагин должен работать корректно, однако 100% гарантию я давать не буду. Поэтому используйте его на свой страх и риск, либо не используйте вовсе, а рассмотрите предыдущие озвученные варианты решения проблемы.

Выводы

Переход на использование нового bzr 2.0 влечёт за собой и переход на новый формат 2a. Будьте внимательны и донесите до сведения каждого участника вашей команды все последствия такого перехода и скоординируйте обновление всех ваших веток.

Mainline: главная линия разработки и номера ревизий (Часть 2)

2009-09-14T21:54:00.004+01:00

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

Откуда есмь пошло понятие mainline

В английском языке mainline означает основную дорогу, магистраль, основную колею участка железной дороги.

Понятие mainline пришло в Bazaar из его предшественника Arch. В Arch это понятие использовалось, чтобы разделить ревизии, зафиксированные в этой конкретной ветке, от ревизий, присоединенных (merged) из других веток. В таком же контексте mainline используется и в Bazaar.

Синонимом понятия mainline (главная линия или главная ветка) в распределенных системах можно считать ствол (trunk) в централизованных системах (svn). Однако при этом промежуточные стадии разработки производятся в отдельных ветках, а в главную ветку (trunk) попадает уже готовый отлаженный результат работы. В этом случае trunk теоретически всегда находится в работоспособном состоянии: программа заведомо компилируется и работает. Подробное изложение такого метода разработки можно найти в документе Ultimate Quality Development System (UQDS).

Реально, mainline в Bazaar — это фактически закрепленная на уровне системы контроля версий модель разработки с основной (центральной) веткой, в которая содержит законченные результаты работы, и множества рабочих веток (features branches — ветки для разработки новых функций), которые собственно используются разработчиками.

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

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

Как mainline влияет на вывод журнала ревизий

Дополнительное (негативное) влияние парадигма mainline косвенно оказывает на быстродействие некоторых операций, в которых участвуют составные "точечные" номера ревизий (dotted revno), например, ревизия 2.1.1. Для однозначного вычисления "точечного" номера ревизии Bazaar должен проанализировать полный граф ревизий на достаточную глубину, чтобы найти ревизию, после которой ветки разошлись.

В связи с этим разработчики Bazaar, начиная с версии bzr 1.14, пошли на небольшую хитрость: по умолчанию "точечные" ревизии в журнале не отображаются, что позволяет избежать затрат на вычисление их номеров. При этом у пользователя остается возможность принудительно включить их вывод при помощи соответствующей опции командной строки.

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

bzr log --long — формат вывода журнала по умолчанию; отображается детальная информация о ревизии в несколько строк: условный номер ревизии, теги, автор(ы), короткое имя ветки (branch nick), дата, полный текст комментария к ревизии. Пример (из знакомой нам ветки Test):

C:\work\bzr-day\Basic-commands\Test>bzr log -r-1 ------------------------------------------------------------ revno: 4 [merge] committer: Базарный день <ru_bzr@googlegroups.com> branch nick: Test timestamp: Tue 2009-09-08 23:50:01 +0300 message: Объединение с веткой Experimental ------------------------------------------------------------ Use --include-merges or -n0 to see merged revisions.

bzr log --short — "краткий" формат вывода: в одну строку выводится условный номер ревизии, автор, дата; ниже выводится полный комментарий к ревизии. Пример:

C:\work\bzr-day\Basic-commands\Test>bzr log -r-1 --short 4 Базарный день 2009-09-08 [merge] Объединение с веткой Experimental Use --include-merges or -n0 to see merged revisions.

bzr log --line — наиболее компактный формат вывода: в одну строку выводится условный номер ревизии, автор, дата и начало комментария к ревизии. Пример:

C:\work\bzr-day\Basic-commands\Test>bzr log -r-1 --line 4: Базарный день 2009-09-08 [merge] Объединение с веткой Experimental

До версии bzr 1.14 log --long всегда отображал присоединенные ревизии, а log --short и log --line не умели этого. Теперь все форматы умеют отображать присоединенные ревизии при запуске команды log с опцией -n0 или --include-merges. Например:

C:\work\bzr-day\Basic-commands\Test>bzr log --line -n0 4: Базарный день 2009-09-08 [merge] Объединение с веткой Experimental 2.1.1: Базарный день 2009-09-08 Скорректирован файл goodbye.txt в ветке Experimental 3: Базарный день 2009-09-08 Скорректирован файл foo.txt в ветке Test 2: Базарный день 2009-09-08 Внесены изменения для иллюстрации команд status и diff 1: Базарный день 2009-09-08 Начальное состояние файлов
Итак, мы можем видеть, что сегодня журнал по умолчанию отображает только ревизии, соответствующие mainline. Поэтому, если ваш проект не следует этой парадигме, вы всегда должны запускать команду log с включенной опцией отображения присоединенных ревизий. (Этого можно достичь при помощи aliases). Аналогичная картина и с GUI командой qlog (из плагина QBzr): после запуска этой команды пользователь видит только mainline-ревизии, а присоединенные ревизии свернуты. Для разворачивания/отображения этих ревизий пользователь должен щелкнуть мышкой по значку + в круглом узле на графе ревизий (либо использовать стрелки влево-вправо на клавиатуре), см. снимок с экрана ниже.

Рисунок 1. Отображение графа ревизий после запуска: только mainline ревизии

Рисунок 2. Развернутый узел с присоединенными ревизиями

В следующей части этой статьи мы рассмотрим как mainline влияет на команды merge, commit и push. Также мы попытаемся сформулировать ряд советов по правильному использованию парадигмы главной линии разработки (mainline).

Mainline: главная линия разработки и номера ревизий (Часть 1)

2009-09-08T22:37:00.004+01:00

Сегодня речь пойдет об одной специфичной особенности bzr, которую вы не найдете ни в одной другой распределенной системе контроля версий. Мы рассмотрим понятие mainline (главная линия разработки), его связь с номерами ревизий, и каким образом mainline влияет на работу с несколькими ветками.

Номера ревизий в распределенной системе

Прежде всего необходимо четко понимать и помнить, что в распределенных системах контроля версий для однозначной идентификации любой ревизии необходимо применять некие уникальные идентификаторы. Простая нумерация ревизий 1,2,3,… для этого не подходит, поскольку идентификаторы должны быть уникальны в глобальном смысле, а простые номера уникальны только в пределах одной физической копии репозитория (что вполне подходит для централизованных систем типа svn).

Поэтому все современные распределенные системы применяют уникальные идентификаторы. Так Monotone, Git и Mercurial используют в качестве уникального идентификатора ревизии SHA-1 хэш от данных самой ревизии. Bazaar тоже использует уникальные идентификаторы для ревизий, однако эти идентификаторы представляют произвольную строку и нет требования, чтобы идентификатор был основан на данных самой ревизии.

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

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

Принципы формирования номеров ревизий в Bazaar

Каждой ревизии, которую вы фиксируете в своей ветке присваивается свой порядковый номер (revno), начиная с 1. Эти номера неизменны для конкретной ветки.

Когда вы объединяете свою ветку с другой, то должны зафиксировать результат объединения в виде новой ревизии. Эта ревизия получит свой порядковый номер как и раньше. А вот ревизии, которые были добавлены в вашу ветку в результате объединения, получат специальные новые "номера", состоящие из 3х чисел, разделенных точками (так называемые dotted revno).

В качестве примера вернемся к нашей прошлой статье Начинаем работу с bzr: базовый набор команд (Часть 2). Я приведу кусочек вывода команды bzr log для ветки после объединения:

C:\work\bzr-day\Basic-commands\Test>bzr log -n0 
------------------------------------------------------------ 
revno: 4 [merge] 
committer: Базарный день <ru_bzr@googlegroups.com>
branch nick: Test 
timestamp: Tue 2009-09-08 23:50:01 +0300 
message: 
  Объединение с веткой Experimental     
------------------------------------------------------------ 
    revno: 2.1.1
    committer: Базарный день <ru_bzr@googlegroups.com>
    branch nick: Experimental 
    timestamp: Tue 2009-09-08 23:48:42 +0300 
    message: 
      Скорректирован файл goodbye.txt в ветке Experimental 
------------------------------------------------------------ 
revno: 3 
committer: Базарный день <ru_bzr@googlegroups.com>
branch nick: Test 
timestamp: Tue 2009-09-08 23:49:13 +0300 
message: 
  Скорректирован файл foo.txt в ветке Test 
------------------------------------------------------------

Обратите внимание на строки, начинающиеся с "revno:" — они показывают номер ревизии.

Можно видеть, что после ревизии номер 3 было произведено объединение, результат объединения зафиксирован в ревизии под номером 4. В результате объединения появилась ревизия из другой ветки, ей был присвоен номер 2.1.1.

Ревизии с целыми номерами (без точек) образуют главную линию разработки вашей ветки (mainline). Ревизии, присоединенные из других веток (merged revisions) являются частью полной истории ветки, но не входят в главную линию и имеют составной номер ревизии, разделенный точками (X.Y.Z).

Как узнать уникальные идентификаторы ревизий

Команда bzr log способна отображать настоящие глобально-уникальные идентификаторы ревизий при запуске с дополнительной опцией --show-ids:

C:\work\bzr-day\Basic-commands\Test>bzr log -n0 --show-ids -l3 
------------------------------------------------------------ 
revno: 4 [merge] 
revision-id: ru_bzr@googlegroups.com-20090908205001-h9q4wxqx76bi0j6u
parent: ru_bzr@googlegroups.com-20090908204913-43cyv2j60fva7w8g
parent: ru_bzr@googlegroups.com-20090908204842-5c0hseh1g4zyrzwx
committer: Базарный день <ru_bzr@googlegroups.com>
branch nick: Test 
timestamp: Tue 2009-09-08 23:50:01 +0300 
message: 
  Объединение с веткой Experimental     
------------------------------------------------------------ 
    revno: 2.1.1 
    revision-id: ru_bzr@googlegroups.com-20090908204842-5c0hseh1g4zyrzwx
    parent: ru_bzr@googlegroups.com-20090908204210-qegq6pfotpffqda6
    committer: Базарный день <ru_bzr@googlegroups.com>
    branch nick: Experimental 
    timestamp: Tue 2009-09-08 23:48:42 +0300 
    message: 
      Скорректирован файл goodbye.txt в ветке Experimental 
------------------------------------------------------------ 
revno: 3 
revision-id: ru_bzr@googlegroups.com-20090908204913-43cyv2j60fva7w8g
parent: ru_bzr@googlegroups.com-20090908204210-qegq6pfotpffqda6
committer: Базарный день <ru_bzr@googlegroups.com>
branch nick: Test 
timestamp: Tue 2009-09-08 23:49:13 +0300 
message: 
  Скорректирован файл foo.txt в ветке Test 
------------------------------------------------------------

Строки, начинающиеся на "revision-id:" собственно отображают идентификаторы ревизий. Так, ревизии номер 4 в этой ветке соответствует уникальный идентификатор "ru_bzr@googlegroups.com-20090908205001-h9q4wxqx76bi0j6u".

Можно заметить, что Bazaar использует данные об авторе ревизии и дате фиксации плюс некоторые случайные данные для формирования уникального идентификатора. Однако, как я упоминал ранее, формат и содержание идентификатора — произвольные.

Что означают цифры в номере присоединенной ревизии

Правило образования номеров для присоединенных ревизий следующее:

первая цифра означает номер ревизии в главной ветке, от которой отпочковалась побочная ветка
вторая цифра означает порядковый номер побочной ветки (начиная с 1)
третья цифра означает порядковый номер ревизии в побочной ветке, после того, как история разошлась.

Взглянем на граф ревизий, визуализированный при помощи команды qlog из плагина QBzr:

Ревизия 2.1.1 отпочковалась от ревизии 2 в основной ветке, имеем всего одну побочную ветку (Experimental), и одну ревизию в побочной ветке. Если бы в побочной ветке Experimental были бы еще ревизии, то они были бы пронумерованы как 2.1.2, 2.1.3 и т.д.

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

Примеры к статье можно найти на Launchpad.net: ветка Test, ветка Experimental.

Разработка плагинов для bzr

2009-05-10T19:33:00.001+01:00

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

Для успешной разработки плагина нужно знать и понимать следующие вопросы: как плагины загружаются при запуске bzr, как плагины взаимодействуют с кодом bzr, как плагин может расширять существующую функциональность bzr, как организовать код плагина. Есть также ряд менее важных сопутствующих вопросов: как распространять/устанавливать плагины, как писать тесты для плагинов.

Язык программирования

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

Документация и примеры

При разработке плагинов вам поможет следующая документация:

Прежде всего полезно ознакомиться с кратким учебником по разработке плагинов: http://bazaar-vcs.org/WritingPlugins
Чтобы узнать о методах использования библиотеки bzrlib для выполнения типичных операций, используйте документ http://bazaar-vcs.org/Integrating_with_Bazaar
Подробнее узнать о поддерживаемом API плагинов можно из документа http://doc.bazaar-vcs.org/bzr.dev/developers/plugin-api.html
Хуки и их сигнатуры приведены в документе http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#hooks
В качестве справочника по bzrlib API можно использовать автоматически сгенерированную API-документацию: http://starship.python.net/crew/mwh/bzrlibapi/

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

Как bzr загружает плагин

Код загрузки плагинов содержится в модуле bzrlib/plugin.py

При старте bzr производит поиск питон-модулей и питон-пакетов в предопределенных каталогах (~/.bazaar/plugin, site-packages/bzrlib/plugin и т.п., подробнее см. статью "Плагины bzr: основные сведения" раздел "Как подключить плагин").

Для всех найденных модулей и пакетов делается попытка импорта (в терминах Python). При импорте Python исполняет импортируемый код, поэтому вся инициализация плагина и регистрация новых команд/функций/форматов/хуков должна производиться в момент импорта. Сам bzr в момент загрузки плагина не вызывает никаких функций из импортируемого модуля.

В случае успешного импорта плагин регистрируется для последующего использования.

Взаимодействие плагина с bzrlib

Плагины должны регистрировать новые команды и функции императивным способом: путем вызова соответствующих функций из bzrlib. Т.е. код плагина импортирует соответствующие модули/функции из bzrlib и затем вызывает их с необходимыми аргументами.

Практически для всех точек расширения в bzrlib используются реестры объектов. API объектов-реестров находится в модуле bzrlib/registry.py. Однако, часто регистрация расширений производится и при помощи специальных функций. Так, например, функция регистрации новых команд register_command находится в модуле bzrlib/commands.py. API для регистрации хуков определено в модуле bzrlib/hooks.py, однако сами хуки регистрируются для классов Branch (bzrlib/branch.py), BzrDir (bzrlib/bzrdir.py) и проч.

Данная статья не ставит перед собой целью дать исчерпывающее описание всех точек расширения в bzrlib. Мы постараемся осветить эти вопросы в других статьях на живых примерах. Однако помните о том, что для bzr написано множество плагинов, которые можно использовать в качестве наглядного примера использования точек расширения.

Советы по организации кода плагина

Плагин может быть одиночным модулем или питон-пакетом. Удобнее оформлять плагин как питон-пакет. В этом случае каталог с кодом плагина можно легко превратить в bzr-ветку и использовать эту ветку для ведения разработки. Также кроме собственно кода плагина в такой ветке можно спокойно разместить тесты, дополнительные документы (такие как README), скрипт установки setup.py и любые дополнительные ресурсы. Дополнительным удобством такой организации является то, что любой желающий может просто поместить локальную копию ветки с вашим плагином в каталог ~/.bazaar/plugins и тем самым не только подключить плагин, но и иметь возможность легко обновлять код плагина командой bzr pull.

Совместимость с автономной версией bzr.exe для Windows

При использовании автономной версии bzr.exe, которая создается при помощи утилиты py2exe, следует помнить об одной важной детали. Автономная версия bzr.exe содержит интерпретатор Python и большую часть (но не всю!) стандартной библиотеки Python внутри. В дополнение к стандартной библиотеке внутри bzr.exe содержатся библиотеки, необходимые для полноценной работы bzr, такие как paramiko, pyCrypto и т.п. Однако, если для работы вашего плагина потребуется какая-то экзотическая библиотека, то возможности "доустановить" ее у пользователя bzr.exe не будет. В таком случае следует предусмотреть возможность импорта дополнительных библиотек из подкаталога внутри вашего плагина. В качестве примера см. плагин QBzr.

Советы по отладке плагина

Проблемы с загрузкой плагина

В случае проблем с загрузкой кода плагина (ошибки при импорте плагина) вы увидите сообщение на экране:

Unable to load plugin 'foo' from '...'

Полный traceback для ошибки записывается в лог-файл .bzr.log. Точное расположение лог-файла можно узнать из вывода команды bzr version (см. строку Bazaar log file).

Отладочная печать

При отладке нетривиальных алгоритмов вам поможет отладочная печать. Вы конечно можете воспользоваться оператором print, но для конечных пользователей это будет создавать ненужный шум и мусор на экране. Поэтому целесообразнее производить отладочную печать в лог-файл .bzr.log. Для этого используйте функцию mutter из модуля bzrlib/trace.py:

import trace trace.mutter('My debug print')

Для логирования bzr использует стандартную библиотеку logging.

Пошаговая отладка

В особо трудных случаях вы можете захотеть использовать отладчик. Для этого можно использовать любой отладчик для Python, как с графическим, так и с консольным интерфейсом. Очень простым вариантом создания "точки останова" в нужном месте с последующим вызовом стандартного отладчика pdb является использование следующего кода:

import pdb; pdb.set_trace()

Публикация плагинов

Чаще всего плагины разрабатывают в отдельных ветках и публикуют их как обычные bzr-ветки. Для публикации bzr-плагинов удобно использовать сайт Launchpad.net. При регистрации нового проекта для bzr-плагина рекомендуется использовать приставку "bzr-", например bzr-email, bzr-svn. Краткое описание вашего плагина и ссылку на страницу с кодом плагина желательно добавить на соответствующую страничку wiki: http://bazaar-vcs.org/BzrPlugins.

Плагины bzr: основые сведения

2009-04-21T10:19:00.002+01:00

Базар имеет множество команд для выполнения своих основых функций: для просмотра изменений, для фиксирования состояния файлов и каталогов в определенные моменты времени и для работы с историей изменений. И для большей части пользователей этого достаточно. Однако существуют ситуации, когда требуются дополнительные возможности от системы контроля версий, не предоставляемые стандартной поставкой. В этом случае на сцене появляются модули расширения или плагины (plugins) для bzr.

Плагины позволяют расширить возможности bzr за счет новых команд, либо за счет модификации поведения старых. Плагины могут регистрировать специальные обработчики событий (хуки/hooks), которые будут вызываться перед или после некоторых операций, например, commit, pull/push и т.д. Плагины могут добавлять новые алгоритмы обработки данных либо позволять работать с другими форматами репозиториев, например, предоставлять доступ к репозиториям других систем контроля версий. Наиболее знаменитым плагином в этом отношении является bzr-svn, который позволяет напрямую работать с svn.

Список плагинов

Список имеющихся плагинов для bzr приведен на странице BzrPlugins.

Для каждого плагина указано его краткое описание, информация об авторе (авторах) плагина, информация о совместимости с основными операционными системами (Linux/Windows/Mac). Также указан URL на страничку плагина либо bzr-ветку с его кодом.

Что представляют собой плагины

Плагины представляют собой модули или пакеты, написанные на языке программирования Python. Плагины должны писаться на Python, поскольку сама система bzr написана на Python, а плагины взаимодействуют напрямую с внутренним API bzr.

Как подключить плагин

При каждом запуске bzr ищет установленные плагины в следующих каталогах:

Если установлена переменная окружения BZR_PLUGIN_PATH, то проводится поиск в списке каталогов из этой переменной
Иначе проводится поиск плагинов в каталоге настроек приложения для текущего пользователя (на Linux/Mac это ~/.bazaar/plugins; на Windows это C:\Documents and Settings\USERNAME\Application Data\bazaar\2.0\plugins).
Дополнительно проводится поиск в подкаталоге, где установлен bzr:

например на Linux это может быть /usr/lib/python2.5/site-packages/bzrlib/plugins

на Windows:

для случая установки standalone installer это будет C:\Program Files\Bazaar\plugins (если сам bzr установлен в каталоге C:\Program Files\Bazaar)

для случая установки как python-программы — аналогично Linux в каталоге site-packages/bzrlib/plugins

Если плагин находится в указанных каталогах, то он будет загружен. Никаких специальных настроек для разрешения или запрещения плагина не требуется. Для того чтобы отключить плагин достаточно удалить плагин из соответствующего каталога.

Установка плагинов

Многие популярные плагины имеют специальные пакеты для установки на Linux. Они могут быть установлены/удалены обычным образом при помощи менеджера пакетов.

Рассмотрим установку плагина из исходного кода.

Большинство плагинов работают прямо из исходного кода и не требуют специальных действий для установки. Достаточно просто поместить каталог (или ветку) с кодом плагина в каталог plugins. Однако все-таки стоит изучить имеющийся файл README или INSTALL на предмет дополнительных инструкций по установке.

Следует также помнить о том, что часто код плагинов размещается на сайте Launchpad.net, который предоставляет бесплатный хостинг для проектов и/или bzr-веток. В этом случае страница bzr-плагина зачастую имеет приставку "bzr-" в имени плагина (чтобы подчеркнуть свою принадлежность). При установке плагина эту приставку нужно опустить, плюс все дефисы в названии поменять на знак подчеркивания. Так, например, плагин bzr-gtk должен устанавливаться в каталог gtk, а плагин bzr-x-bit в каталог x_bit. Каталог, в котором должен помещаться код плагина, часто жестко предопределен и при его изменении плагин в большинстве случаев оказывается неработоспособным.

Рассмотрим установку на примере плагина merge-into:

перейти в каталог plugins: cd ~/.bazaar/plugins
получить копию ветки с launchpad.net:
bzr branch lp:bzr-merge-into merge_into

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

Чтобы убедиться в том, что плагин установлен корректно, запустите команду bzr plugins. Ваш плагин должен присутствовать в списке, который выдает эта команда:

C:\>bzr plugins bzrtools 1.13 Various useful commands for working with bzr. launchpad Launchpad.net integration plugin for Bazaar. merge_into Provide the 'merge-into' command.
Многие плагины содержат набор тестов, которые можно использовать для проверки работоспособности плагина на вашей платформе или для проверки совместимости с используемой версией bzr. Для запуска тестов конкретного плагина используйте команду selftest:

C:\>bzr selftest -s bp.merge_into testing: C:/Program Files/Bazaar/bzr.EXE C:\Program Files\Bazaar\lib\library.zip\bzrlib (1.13.1 python2.5.4) [5/5 in 4s] bzrlib.plugins.merge_into.test_bb_merge_into.TestMergeInto.test_smoke ---------------------------------------------------------------------- Ran 5 tests in 5.125s OK tests passed

Справочная информация о плагине

Для получения справки о плагине посмотрите файл README, поставляемый с кодом плагина, либо используйте команду help:

C:\>bzr help merge_into Provide the 'merge-into' command. This command allows you to merge other branches into subdirectories, rather than always merging into root, and then needing to be moved around.
Некоторые плагины добавляют большое количество команд, не все из которых описаны в скудной справке к плагину. Отыскать все команды нам поможет команда bzr help commands и утилита grep. Например, найдем все команды, предоставляемые популярным плагином bzrtools:

C:\>bzr help commands | grep bzrtools branch-history Display the development history of a branch. [bzrtools] branches Scan a location for branches [bzrtools] cbranch Create a new checkout, associated with a new repository branch. [bzrtools] cdiff A color version of bzr's diff [bzrtools] clean-tree Remove unwanted files from working tree. [bzrtools] fetch-ghosts Attempt to retrieve ghosts from another branch. [bzrtools] graph-ancestry Produce ancestry graphs using dot. [bzrtools] heads Show all revisions in a repository not having descendants. [bzrtools] import Import sources from a directory, tarball or zip file [bzrtools] link-tree Hardlink matching files to another tree. [bzrtools] multi-pull Pull all the branches under a location, e.g. a repository. [bzrtools] patch Apply a named patch to the current tree. [bzrtools] rspush Upload this branch to another location using rsync. [bzrtools] shelf1 Perform various operations on your shelved patches. See also shelve1. [bzrtools] shell Begin an interactive shell tailored for bzr. [bzrtools] shelve1 Temporarily set aside some changes from the current tree. [bzrtools] trees Scan a location for trees [bzrtools] unshelve1 Restore shelved changes. [bzrtools] zap Remove a lightweight checkout, if it can be done safely. [bzrtools]

Примечание: пользователям Windows необходимо установить утилиту grep самостоятельно.

Временное отключение плагинов

В некоторых (редких) случаях может потребоваться запустить команду bzr без плагинов. В этом случае вы можете использовать глобальную опцию командной строки --no-plugins. Глобальные опции должны указываться после имени программы (bzr) и перед собственно командой. Так, например, следующая команда выведет список только встроенных команд:

bzr --no-plugins help commands

Имеется еще одна глобальная опция, воздействующая на плагины: --builtin. При использовании этой опции плагины загружаются как обычно, но при этом плагинам запрещается декорирование команд. Т.е. плагины не смогут зарегистрировать новую команду с именем, которое совпадает с именем встроенной команды. Эта опция полезна прежде всего для целей отладки.

Автоматический whoami при работе через SSH

2009-04-05T22:23:00.002+01:00

В статье рассматривается простой пример использования (документированных) возможностей как sshd, так и bzr, для автоматической установки идентификатора пользователя при работе на удаленной машине.

Сценарий

Имеется общий компьютер, на котором могут работать несколько человек под одной учетной записью. Этот компьютер может использоваться как тестовый полигон, либо как машина для компиляции окончательной версии программы, или для сборки инсталляционных пакетов. Либо же это тестовый/боевой сервер, на котором запущен веб-сайт или другое приложение. Разработчики используют SSH для работы на этом общем компьютере.

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

Проблема

При такой совместной работе остро стоит вопрос адекватной идентификации разработчиков, которые фиксировали свои изменения. По умолчанию bzr использует автоматический идентификатор, состоящий из имени учетной записи и имени компьютера, например: root@server. А поскольку под одной учетной записью могут работать несколько человек, то нельзя установить глобальный идентификатор через команду bzr whoami.

Способы идентификации

Базар позволяет идентифицировать автора ревизии несколькими способами: глобальная идентификация, идентификация на уровне ветки, или через использование переменных окружения.

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

Остается вариант с использованием переменных окружения. Базар использует значение переменной окружения BZR_EMAIL или EMAIL в качестве идентификатора пользователя. Если одна из этих переменных определена, то она имеет приоритет как над глобальным идентификатором, так и над идентификацией на уровне ветки.

Вариант с использованием переменных окружения тоже имеет свой недостаток: в начале каждой новой SSH-сессии разработчик должен установить переменную окружения BZR_EMAIL. О необходимости установки этой переменной легко забыть. К счастью имеется возможность автоматизировать этот скучный процесс при использовании аутентификации пользователей при помощи SSH-ключей.

Использование файла authorized_keys

При аутентификации при помощи SSH-ключей используется файл ~/.ssh/authorized_keys (или ~/.ssh/authorized_keys2). В этом файле сохраняется список публичных SSH-ключей, которым разрешена аутентификация. Однако кроме самих ключей, дополнительно могут быть указаны различные параметры соединения, либо ограничения доступа, либо директивы запуска некоторой программы при аутентификации конкретным ключом. Либо директива установки переменной окружения при аутентификации конкретным ключем. Именно эта директива нам и нужна.

Директива установки переменной окружения при логине указывается в виде:

environment="ИМЯ=значение"

Подробнее о формате и параметрах в файле authorized_keys читайте в man sshd.

Таким образом для настройки автоматической идентификации пользователей необходимо применить вход на общий компьютер через SSH-ключи, и для каждого пользователя (перед его публичным ключем) указать свою директиву environment, например:

--------------------Файл: authorized_keys------------------------------------- environment="BZR_EMAIL=Vasya Pupkin <pupkin@mail.ru>" ssh-dss AAAAB3NzaC1kc3MAAACAcdSwa... ------------------------------------------------------------------------------

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

Работа с ветками: push, pull, merge (Часть 3)

2009-04-03T03:16:00.001+01:00

Рассмотрим еще один пример работы с ветками: совместная работа над проектом в небольшом коллективе. Для определенности будем рассматривать коллектив из 2х человек, поскольку приводимый сценарий легко масштабируется и на большее количество участников.

Сценарий №2

Над созданием программы под кодовым названием MegaApp работают Иван и Сергей. У них есть общее хранилище для веток проекта на центральном сервере. Там находится главная ветка проекта под названием trunk. Каждый из участников проекта, Иван и Сергей, имеет локальную копию главной ветки на своем компьютере и периодически синхронизирует ее с оригиналом на сервере.

Для реализации новой функции Иван создает новую копию ветки trunk для локальной работы. Иван пишет новую функциональность, фиксирует изменения, тестирует свой код в локальной рабочей ветке. Когда работа над новой функцией завершена Иван объединяет свои изменения с копией главной ветки, фиксирует результат объединения и отправляет новые ревизии в главную ветку на сервере.

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

Главная ветка проекта

С технической точки зрения для Базара все ветки равны. Однако в любом проекте должна быть главная ветка, которая используется всеми участниками проекта для синхронизации, в которую попадают новые изменения, багфиксы, из которой в конечном счете формируются окончательные версии (релизы) вашего продукта. Такая ветка является центральным связующим звеном для проекта.

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

Имя trunk пришло из svn. По английски "trunk" означает "ствол" (ствол дерева), как противоположность просто веткам (branch), которые ответвляются от ствола.

Центральное хранилище

Для хранения эталонной главной ветки, с которой все участники проекта будут периодически синхронизироваться, нужно какое-либо центральное хранилище, или центральный сервер. Базар поддерживает различные типы серверов для хранения веток: SFTP, FTP, специализированный bzr-сервер, можно даже задействовать какой-то общий каталог на одной из машин (в сети Windows) или на SAMBA-сервере. Выбор того или иного варианта зависит от конкретной ситуации.

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

bzr serve --allow-writes --directory C:/work/bzr-day/server

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

Будьте внимательны: bzr-сервер не осуществляет никакую авторизацию пользователей, и с опцией --allow-writes разрешает любому клиенту операции как чтения так и записи. bzr-сервер использует порт 4155 для работы.

Создание главной ветки на сервере

Иван использует команду init (или push), чтобы создать ветку trunk на сервере:

C:\work\bzr-day\ivan>bzr init bzr://localhost/trunk Created a standalone branch (format: unnamed)

Создание локальной копии главной ветки

Для работы над проектом Ивану необходима локальная копия главной ветки. Для получения главной ветки с сервера Иван использует команду branch:

C:\work\bzr-day\ivan>bzr branch bzr://localhost/trunk Branched 0 revision(s).

Ветка совсем пустая (0 revisions), поэтому Иван решает сделать первую фиксацию прямо в ней и обновить ветку на сервере:

C:\work\bzr-day\ivan\trunk>bzr commit -m initial --unchanged Committing to: C:/work/bzr-day/ivan/trunk/ Committed revision 1. C:\work\bzr-day\ivan\trunk>bzr push bzr://localhost/trunk Pushed up to revision 1.

Иван работает над новой функцией

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

C:\work\bzr-day\ivan\trunk>bzr pull Using saved parent location: bzr://localhost/trunk/ No revisions to pull. C:\work\bzr-day\ivan\trunk>cd .. C:\work\bzr-day\ivan>bzr branch trunk feature Branched 1 revision(s). C:\work\bzr-day\ivan>cd feature
Иван пишет новый код, фиксирует каждый логически законченный этап, тестирует его...

C:\work\bzr-day\ivan\feature>bzr st ... C:\work\bzr-day\ivan\feature>bzr diff ... C:\work\bzr-day\ivan\feature>bzr commit ... ... C:\work\bzr-day\ivan\feature>bzr log ...
Наконец, работа над новой функцией закончена и Иван объединяет главную ветку со своей работой:

C:\work\bzr-day\ivan\feature>cd ../trunk C:\work\bzr-day\ivan\trunk> C:\work\bzr-day\ivan\trunk>bzr merge ../feature +N foo.c All changes applied successfully. C:\work\bzr-day\ivan\trunk>bzr status added: foo.c pending merge tips: (use -v to see all merge revisions) Базарный день 2009-03-31 Реализована и протестирована новая функция foo C:\work\bzr-day\ivan\trunk>bzr status -v added: foo.c pending merges: Базарный день 2009-03-31 Реализована и протестирована новая функция foo Базарный день 2009-03-31 Исправлена ошибка в функции foo Базарный день 2009-03-31 Реализован базовый алгоритм функции foo C:\work\bzr-day\ivan\trunk>bzr commit -m "Реализована функция foo" Committing to: C:/work/bzr-day/ivan/trunk/ added foo.c Committed revision 2.
После чего можно отправлять новые ревизии на сервер командой push:

C:\work\bzr-day\ivan\trunk>bzr push bzr://localhost/trunk Pushed up to revision 2.
Подобным образом работают все участники проекта.

Сергей работает над исправлением найденного дефекта

Работа над исправлением дефекта для Сергея мало отличается от написания новой функции программы. Сергей точно также использует отдельную ветку для работы и в конце объединяет главную ветку со своими изменениями:

обновить локальную копию главной ветки (bzr pull)
создать отдельную ветку для работы (bzr branch trunk bugfix)
проделать работу в отдельной ветке (status, diff, commit, log)
объединить локальную копию главной ветки со своими изменениями (bzr merge ../bugfix)
передать новые ревизии в главную ветку на центральном сервере (bzr push)

Регулярная синхронизация с главной веткой

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

Рассмотрим следующий пример. Иван работает над новой сложной функцией программы не первый день. В это время Сергей исправляет найденный дефект в коде одного из модулей, и свои исправления публикует в ветке trunk. Исправления Сергея затрагивают код, над которым работает Иван. Иван время от времени обновляет копию главной ветки и просматривает новые ревизии. Когда он замечает, что появились изменения, влияющие на его работу, то Иван объединяет новые ревизии из trunk со своей веткой, исправляет возможные несоответствия в своем коде и продолжает работу в своей ветке.

Вот как этот пример выглядит в командах bzr:

Иван работает в своей ветке bigfeature над новой сложной функцией:

bzr branch trunk bigfeature cd bigfeature hack-hack-hack bzr diff bzr commit
Иван периодически обновляет свою копию trunk, просматривает новые ревизии и обнаруживает появление багфикса от Сергея:

cd ../trunk bzr pull bzr log
Для того, чтобы увидеть только новые ревизии в главной ветке, которые отсутствуют в ветке bigfeature Иван может воспользоваться командой missing:

cd ../bigfeature bzr missing --theirs-only ../trunk

Флаг --theirs-only указывает команде missing, что пользователя интересует только информация о новых ревизиях в ветке trunk.

Иван решает, что ему нужно объединить новые правки из trunk с его собственной работой и делает merge:

cd ../bigfeature bzr merge ../trunk bzr diff bzr commit -m "merge trunk"
Теперь Иван может продолжать свою работу, имея в своей ветке все последние необходимые ему изменения и багфиксы.

Резюме

Итак, мы рассмотрели основные моменты совместной работы над проектом. Данный сценарий характерен для работы с распределенными системами контроля версий, но может и варьироваться в зависимости от нужд коллектива разработчиков. В больших командах может практиковаться ревью нового кода другими (опытными) разработчиками, в этом случае по окончании работы новая функциональная ветка публикуется на центральном сервере, чтобы те, кто будет делать ревью, имели к ней свободный доступ. После ревью объединение нового кода с главной веткой может делать или автоматическая система объединения, либо специально назначенный человек. Выбирайте необходимый вам вариант работы.

Использование WebDAV для доступа к Bazaar-серверу

2009-03-30T13:52:00.027+01:00

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

Варианты доступа к удаленному серверу

bzr:// — "умный" (smart) протокол Bazaar. Это наиболее функциональный и производительный протокол удаленного доступа, использующий встроенный в Bazaar сервер. К сожалению, на данный момент, не имеет возможности аутентифицировать пользователей и управлять доступом. По этим причинам не рекомендуется использовать его самостоятельно, а только в связке с SSH или HTTP/HTTPS:

bzr+ssh:// — использует bzr:// протокол через SSH-туннель. Совмещает функциональность и производительность протокола bzr:// с безопасностью протокола SSH. Наиболее часто используемый в среде Unix/Linux и наиболее часто рекомендуемый протокол удаленного доступа.
bzr+http:// — использует bzr:// протокол совместно с web-сервером Apache и модулем FastCGI или mod_python. Для авторизации пользователей используются механизмы, встроенные в Apache.

sftp:// — для доступа используется протокол SFTP, поддерживаемый большинством SSH серверов. Может быть хорошей альтернативой bzr+ssh://, например, в случае отсутствия на сервере Bazaar.
ftp://, aftp:// — доступ с использованием пассивного (и соотв. активного) режимов FTP. Позволяет давать доступ на запись, но имеет проблемы с безопасностью.
http://, https:// — доступ только для чтения с использованием протоколов HTTP и HTTPS. Хороший вариант если нужен только доступ на чтение.

Из всех рассмотренных выше протоколов только bzr:// (bzr+ssh:// bzr+http://) поддерживают работу с подключаемыми модулями или плагинами (plugins) Bazaar на сервере, т.к. используют встроенный в Bazaar сервер. Остальные же протоколы только предоставляют доступ локальному клиенту Bazaar к данным на удаленном сервере.

Зачем нужен доступ по протоколу WebDAV?

Достаточно часто встречается ситуация, когда для обеспечения политики безопасности, или по другим причинам, нет возможности использовать ни один из перечисленных выше протоколов. Такая ситуация может возникать в случае если нужен удаленный доступ на запись, но нельзя использовать SSH/SFTP, потому что необходимо создавать системные учетные записи. При этом FTP тоже отпадает, поскольку он считается недостаточно безопасным.

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

WebDAV — это набор расширений для протокола HTTP, позволяющий пользователям совместное редактирование и управление файлами на удаленных WEB-серверах. Таким образом, он, как и HTTP/HTTPS, обеспечивает для Bazaar доступ к данным на удаленном сервере, но предоставляет при этом также и возможность их изменения. Одно из основных преимуществ использования WebDAV — это возможность использования стандартных средств HTTP-сервера для управления аутентификацией и доступом пользователей.

Для работы через WebDAV нам понадобится установить плагин на стороне клиента (на локальной машине) и настроить HTTP сервер (в нашем примере Apache) для работы с WebDAV.

Установка плагина WebDAV

Плагин WebDAV для Bazaar можно найти на сайте Launchpad: https://launchpad.net/bzr.webdav. Для получения плагина сделаем копию ветки с Launchpad и затем установим плагин.

Установка только для текущего пользователя

Наиболее просто установить плагин для текущего пользователя. На Unix/Linux системах плагины устанавливаются в каталог ~/.bazaar/plugins/ (на Windows используется каталог C:\Documents and Settings\USERNAME\Application Data\2.0\bazaar\plugins). Перейдите в каталог plugins и выполните команду branch:

$ cd ~/.bazaar/plugins/ $ bzr branch lp:bzr.webdav webdav Плагин будет установлен в подкаталог webdav.

Установка для всех пользователей

В данном случае модуль устанавливается в системной директории для поиска модулей bzrlib/plugins (на Unix системах это может быть /usr/lib/python2.5/site-packages/bzrlib/plugins/).

$ bzr branch lp:bzr.webdav $ cd bzr.webdav/ $ sudo python setup.py install

Проверка наличия плагина WebDAV

Для проверки наличия плагина необходимо использовать команду plugins. Эта команда выведет список всех установленных плагинов, их версий, и краткое описание каждого плагина. В этом списке должен присутствовать плагин webdav:

$ bzr plugins
...
webdav 1.12
  An http transport, using webdav to allow pushing.
...

Настройка сервера Apache

Теперь рассмотрим настройки HTTP сервера Apache. Прежде всего для Apache должен быть установлен модуль mod_dav. Конфигурация для этого модуля будет выглядеть приблизительно следующим образом:

<IfModule mod_dav.c>

  Alias /bzr /var/www/bzr

  <Directory /var/www/bzr>
    Dav On
    DirectorySlash Off
    DavDepthInfinity On

    AuthType Basic
    AuthName "Bazaar server"
    AuthUserFile /etc/apache2/dav.users
    Require valid-user
  </Directory>
</IfModule>

Рассмотрим настройки подробнее:

директива Alias устанавливает связь между путем в URL (/bzr) и каталогом /var/www/bzr, где будут хранится ветки;
опция Dav On включает WebDAV для /var/www/bzr;
опция DirectorySlash Off выключает перенаправление в случае если в конце URL для каталогов не указан '/'. (Такие перенаправления не очень хорошо работают с Bazaar);
опция DavDepthInfinity On включает обработку PROPFIND запросов с заголовком Depth: Infinity;
оставшиеся опции настраивают простую HTTP авторизацию;

Работа с сервером

После перезагрузки Apache вы сможете работать с удаленными ветками с помощью протокола http+webdav:// следующим образом: $ bzr branch http+webdav://user@a.site/bzr/branch Кроме использования HTTP можно настроить работу WebDAV и по протоколу HTTPS.

Сохранение пароля

Если вы используете на сервере авторизацию и не хотите каждый раз набирать пароль, то можно воспользоваться клиентским файлом конфигурации authentication.conf. Этот файл должен находится в каталоге с файлами конфигурации Bazaar (по умолчанию на Unix - ~/.bazaar). В файле для WebDAV должна быть следующая информация:

 [myprojects]
scheme = http
host = host.com
user = ivan
password = secret

Обратите внимание, что значение параметра scheme должно быть http для http+webdav:// и https для https+webdav://.

Один из минусов использования файла authentication.conf в том, что (на данный момент) пароли хранятся в виде простого текста.

Резюме

Подытоживая, можно сказать, что WebDAV может быть хорошей альтернативой для bzr+ssh://, в случае если вы не хотите создавать системные учетные записи для каждого пользователя и в то же время предоставлять более безопасный доступ (при использовании HTTPS) чем ftp://.

Работа с ветками: push, pull, merge (Часть 2)

2009-03-26T11:07:00.002Z

Продолжаем начатую тему работы с ветками. Рассмотрим практическое применение команд push, pull, merge на двух примерах: синхронизация веток между несколькими компьютерами (одиночная работа), совместная работа над одним проектом в небольшом коллективе.

Сценарий №1

Петр работает над своим проектом FuzzyCoding на нескольких компьютерах (например, на домашнем и на рабочем). Перед тем как уйти с одного рабочего места на другое Петр фиксирует сделанные изменения, чтобы можно было продолжить работу на другом компьютере. Петр использует синхронизацию своих веток на разных компьютерах при помощи USB-flash диска. Когда он заканчивает работу, то копирует новые ревизии из локальной ветки на флеш-диск командой bzr push. Придя на другое рабочее место синхронизирует локальную ветку, копируя новые ревизии с флеш-диска командой bzr pull.

Рассмотрим этот сценарий более детально.

Подготовка USB-flash диска

Петр уже создал новую ветку на своем компьютере и работает в ней некоторое время. Для переноса своей ветки на другой компьютер он решил использовать USB-диск. Петр может просто использовать команду bzr push в своей рабочей ветке, чтобы передать ревизии и рабочие файлы на USB-диск. Базар полностью поддерживает такую работу.

Однако, имеет смысл сделать некоторые подготовительные действия на USB-диске. Дело в том, что команда push не только копирует новые ревизии в другую ветку, но еще и обновляет рабочие файлы в другой ветке в том случае, если ветка локальная. Поскольку подключенный USB-диск практически всегда является локальным диском, то bzr будет стараться создать и обновить ваши рабочие файлы. В то же время для синхронизации веток вам совсем не требуется переносить и рабочие файлы (поскольку они присутствуют в истории и могут быть легко восстановлены). Поэтому с практической точки зрения необходимо исключить рабочие файлы с USB-диска и синхронизировать только историю.

Для одной ветки это можно сделать так: создать новую ветку и удалить дерево рабочих файлов.

E:\USB_sync>bzr init Created a standalone tree (format: pack-0.92) E:\USB_sync>bzr remove-tree

Здесь мы создали новую ветку командой init в каталоге E:\USB_sync (E: это наш USB-диск при использовании Windows, на Linux флеш-диски монтируются в /mnt/flash или другое место). А затем удалили рабочее дерево командой remove-tree.

Другим вариантом является создание общего репозитория для веток на USB-диске, новые ветки в котором автоматически будут создаваться без рабочих файлов:

E:\>bzr init-repo --no-trees USB_repo Shared repository (format: pack-0.92) Location: shared repository: USB_repo

Опция командной строки --no-trees указывает, что по умолчанию для всех веток в этом репозитории рабочие файлы создаваться не будут.

Копирование новых ревизий на USB-диск

Для отправки новых ревизий на USB-диск Петр использует команду push:

C:\work\bzr-day\FuzzyCode>bzr push E:\USB_sync Pushed up to revision 3.
Создание копии ветки на другом компьютере

Придя на другое рабочее место со своим USB-диском Петр создает копию ветки для работы:

C:\work\bzr-day>bzr branch E:\USB_sync FuzzyCode Branched 3 revision(s).
Теперь он может продолжать работу со своей веткой FuzzyCode. По окончании работы Петр снова отправляет новые ревизии на USB-диск командой push.

Синхронизация рабочей ветки с USB-диском

Для получения новых ревизий с USB-диска в свою рабочую ветку Петр использует команду pull:

C:\work\bzr-day\FuzzyCode>bzr pull E:\USB_sync All changes applied successfully. Now on revision 4.
Рабочая ветка успешно обновлена, можно продолжать работу.

Иногда ветки могут разойтись

Если же Петр забыл синхронизировать рабочую ветку с USB-диском и зафиксировал новые изменения, то при попытке сделать push или pull он получит сообщение, что ветки "разошлись". В этом случае Петр должен объединить ветки командой merge:

C:\work\bzr-day\FuzzyCode>bzr merge E:\USB_sync +N dir/ +N foo.txt All changes applied successfully. C:\work\bzr-day\FuzzyCode>bzr commit -m "Объединение рабочей ветки с копией ветки на USB-диске" Committing to: C:/work/bzr-day/FuzzyCode/ added dir added foo.txt Committed revision 5.
После этого команда push позволит синхронизировать копию на USB-диске с рабочей веткой.

Мы рассмотрели простой пример синхронизации веток между несколькими компьютерами. В качестве промежуточной ветки также можно использовать и некоторый общедоступный сервер, например SFTP/FTP.

В следующей части мы рассмотрим сценарий совместной работы над проектом в небольшом коллективе.

Работа с ветками: push, pull, merge (Часть 1)

2009-03-23T07:14:00.002Z

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

Команды

`branch`	Ветка	Создать новую ветку
`merge`	Объединить	Объединить изменения из разных веток
`pull`	Тянуть, втягивать (направление движения: на себя)	Получить (загрузить) изменения из другой ветки в рабочую ветку
`push`	Толкать, выталкивать (направление движения: от себя)	Передать (отправить) изменения из рабочей ветки в другую ветку
`missing`	Недостающий, отсутствующий	Просмотр набора ревизий, различающихся между двумя ветками

Графы ревизий

Рассматриваемые команды в первую очередь работают с историей изменений. История хранится в bzr в виде DAG, поэтому в описании работы будем использовать соответствующие графы, помечая знаком "O" отдельные (ключевые) ревизии. Считаем что ревизии растут снизу вверх, т.е. вверху более новые. Рассматривая две родственные ветки, мы можем иметь 4 возможных типа графов:

`O` Рабочая ветка, другая ветка`\| O`	Ветки содержат одинаковый набор ревизий
`O` Рабочая ветка `\| O` Другая ветка `\| / O \| O`	Ветки содержат различный набор ревизий, история "разошлась"
`O` Рабочая ветка `\| O`Другая ветка `\| O`	Рабочая ветка является продолжением другой ветки; рабочая ветка имеет новые ревизии (относительно истории другой ветки)
`O` Другая ветка`\| O`Рабочая ветка`\| O`	Другая ветка является продолжением рабочей ветки; в рабочей ветке отсутствуют новые ревизии (относительно истории другой ветки)

Команда branch

Команда branch создает копию существующей ветки. После выполнения этой команды обе ветки содержат одинаковый набор ревизий, что соответствует графу 1.

Команда merge

Команда merge используется в случаях, когда две ветки "разошлись", т.е. имеют различный набор ревизий, что соответствует графу 2. Эта команда объединяет ревизии рабочей ветки с другой веткой. После фиксации объединения граф ревизий будет содержать все ревизии из другой ветки. Другая ветка при этом не изменяется.

Граф ревизий после объединения:

O Рабочая ветка
|\
O \ | OДругая ветка
| / O | O

Такой граф уже ближе к графу номер 3, когда рабочая ветка является продолжением другой ветки.

В случаях, когда история еще не разошлась, имеется возможность использовать команды push и pull для синхронизации веток.

Команда push

Команда push используется для синхронизации другой ветки с рабочей веткой. В случае, когда рабочая ветка содержит новые ревизии, которые отсутствуют в другой ветке (как показано на графе 3), пользователь может отправить новые ревизии в другую ветку командой push. После выполнения команды push обе ветки будут синхронизированы (см. граф 1).

C:\work\bzr-day\a>bzr push ../other All changes applied successfully. Pushed up to revision 3.
Если обе ветки уже синхронизированы, то команда push сообщит об этом::

C:\work\bzr-day\a>bzr push ../other No new revisions to push.
В случае, когда история двух веток разошлась, команда выдаст ошибку и предложит сделать merge:

C:\work\bzr-day\b>bzr push ../a bzr: ERROR: These branches have diverged. Try using "merge" and then "push".

Команда push чаще всего используется для публикации рабочих веток на общем сервере, чтобы другие участники проекта могли получить к ней доступ. Если ветка еще не существует, то она будет автоматически создана.

Команда pull

Команда pull является полной противоположностью команде push: она предназначена для синхронизации рабочей ветки с другой веткой. В случае, когда другая ветка содержит новые ревизии, которые отсутствуют в рабочей ветке (как показано на графе 4), пользователь может загрузить новые ревизии из другой ветки командой pull. После выполнения команды pull обе ветки будут синхронизированы (см. граф 1).

C:\work\bzr-day\other>bzr pull ../a All changes applied successfully. Now on revision 3.
Если обе ветки уже синхронизированы, то команда pull сообщит об этом::

C:\work\bzr-day\other>bzr pull ../a No revisions to pull.
В случае, когда история двух веток разошлась, команда выдаст ошибку и предложит сделать merge:

C:\work\bzr-day\b>bzr pull ../a bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.

Команда pull часто используется для обновления локальной копии ветки, которая находится на общем сервере.

Команда missing

Команда missing — это информационная команда. Она позволяет сравнить наборы ревизий в двух ветках и увидеть какие ревизии содержатся в одной ветке и отсутствуют в другой. Команду missing удобно использовать перед запуском команд push, pull или merge, чтобы яснее представлять себе общий граф ревизий двух веток.

Вывод команды missing разделен на 2 части: сначала выводится список ревизий в рабочей ветке, которые отсутствуют в другой ветке; затем список ревизий из другой ветки, которые отсутствуют в рабочей ветке. Вывод списка ревизий аналогичен выводу команды log.

C:\work\bzr-day\b>bzr missing ../a You have 1 extra revision(s): ------------------------------------------------------------ revno: 3 committer: Базарный день <ru_bzr@googlegroups.com> branch nick: b timestamp: Mon 2009-03-23 08:47:47 +0200 message: Новая ревизия в ветке b You are missing 1 revision(s): ------------------------------------------------------------ revno: 3 committer: Базарный день <ru_bzr@googlegroups.com> branch nick: a timestamp: Mon 2009-03-23 08:47:39 +0200 message: Новая ревизия в ветке a

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

Если история веток еще не разошлась (см. графы 3 и 4), то команда missing покажет только новые/недостающие ревизии:

C:\work\bzr-day\a>bzr missing ../other You have 1 extra revision(s): ------------------------------------------------------------ revno: 3 committer: Базарный день <ru_bzr@googlegroups.com> branch nick: a timestamp: Mon 2009-03-23 08:47:39 +0200 message: Новая ревизия в ветке a

C:\work\bzr-day\other>bzr missing ../a You are missing 1 revision(s): ------------------------------------------------------------ revno: 3 committer: Базарный день <ru_bzr@googlegroups.com> branch nick: a timestamp: Mon 2009-03-23 08:47:39 +0200 message: Новая ревизия в ветке aОбе ветки синхронизированы:

C:\work\bzr-day\a>bzr missing ../a Branches are up to date.

Итак, в первой части статьи было показано как работают команды push, pull, missing. В второй части этой статьи рассмотрим сценарий работы с использованием этих команд.

Начинаем работу с bzr: базовый набор команд (Часть 2)

2009-03-15T08:33:00.008Z

В первой части мы рассмотрели работу с одной веткой. Рассмотрим теперь работу с несколькими ветками.

Сценарий работы

Создадим копию ветки для параллельной работы. Изменим некоторые файлы в старой и новой ветках и зафиксируем новое состояние. Объединим изменения в двух ветках.

Для чего нужны дополнительные ветки?

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

Часто ветки используются, чтобы разделить разработку нового функционала программного продукта и поддержку выпущенных версий. В этом случае выпущенные версии (release — релизы) живут в своих собственных ветках. Как правило в релизных ветках только исправляются найденные ошибки, например, исправления ошибок из основной ветки переносятся (портируются) в релизную ветку. Другой тип веток — функциональные ветки (feature branches). Функциональные ветки используются для работы над одной конкретной задачей: реализации одной новой функции, исправления одного найденного дефекта и т.п.. Функциональные ветки удобно использовать для работы над экспериментальными вещами, про которые заранее неизвестно: выйдет что-либо полезное или нет. Независимо от стиля работы (централизованный или распределенный) или от того, работаете вы в одиночку или группой, использование функциональных веток позволяет более эффективно работать над проектами. Функциональные ветки помогают сфокусировать усилия при работе над конкретными задачами. Когда работа над конкретной задачей закончена, функциональная ветка объединяется с основной веткой проекта. (О пользе функциональных веток подробно излагается в статье Ultimate Quality Development System).

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

Далее в статье мы рассмотрим работу с ветками именно с позиции функциональных веток.

Создать копию ветки

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

C:\Temp> bzr branch Test Experimental
Branched 2 revision(s).

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

Будем считать Test — основной веткой, а Experimental — функциональной (или экспериментальной) веткой.

Работа в другой ветке

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

------Файл goodbye.txt--------
До свидания
------------------------------

C:\Temp\Experimental>bzr commit -m "Скорректирован файл goodbye.txt в ветке Experimental"
Committing to: C:/Temp/Experimental/
modified goodbye.txt
Committed revision 3.

Вернемся в первую ветку Test и изменим там другой файл:

--------Файл foo.txt----------
bar
------------------------------

C:\Temp\Test>bzr commit -m "Скорректирован файл foo.txt в ветке Test"
Committing to: C:/Temp/Test/
modified foo.txt
Committed revision 3.

Обе ветки теперь содержат по 3 ревизии, но с различными изменениями. История "разошлась".

История веток в bzr представляется в виде ориентированного ациклического графа (DAG), совместный граф для этих двух веток будет выглядеть следующим образом:

Работа в обеих ветках может продолжаться независимо. Как только пользователь посчитает, что работа над функциональной веткой Experimental закончена, можно объединить основную и функциональные ветки.

Объединение веток

Операция объединения веток выполняется командой merge. При этом bzr будет объединять историю и изменения из другой ветки с текущей веткой.

C:\Temp\Test>bzr merge ../Experimental
M goodbye.txt
All changes applied successfully.

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

После объединения команда status будет отображать ревизии, которые мы объединили, но еще не зафиксировали:

C:\Temp\Test>bzr status -v
modified:
goodbye.txt
pending merges:
Alexander Belchenko 2009-03-13 Скорректирован файл goodbye.txt в ветке Experimental

Как видно ревизии из ветки Experimental помечены как pending merges (незаконченное объединение). Чтобы закончить процесс объединения мы должны зафиксировать изменения командой commit.

Результаты объединения желательно просмотреть визуально, проанализировав содержимое изменившихся файлов либо просмотреть различия командой diff:

C:\Temp\Test>bzr diff
=== modified file 'goodbye.txt'
--- goodbye.txt 2009-03-10 09:06:24 +0000
+++ goodbye.txt 2009-03-15 07:59:47 +0000
@@ -1,1 +1,1 @@
-Пока
+До свидания

Если пользователь согласен с внесенными изменениями, то их нужно зафиксировать как обычно:

C:\Temp\Test>bzr commit -m "Объединение с веткой Experimental"
Committing to: C:/Temp/Test/
modified goodbye.txt
Committed revision 4.

Если мы просмотрим журнал изменений для ветки Test, то мы увидим объединенные ревизии в истории основной ветки:

C:\Temp\Test>bzr log
------------------------------------------------------------
revno: 4
committer: Alexander Belchenko <alexander.belchenko @ gmail.com>
branch nick: Test
timestamp: Sun 2009-03-15 10:11:30 +0200
message:
  Объединение с веткой Experimental
    ------------------------------------------------------------
    revno: 2.1.1
    committer: Alexander Belchenko <alexander.belchenko @ gmail.com>
    branch nick: Experimental
    timestamp: Fri 2009-03-13 20:04:12 +0200
    message:
      Скорректирован файл goodbye.txt в ветке Experimental
------------------------------------------------------------
revno: 3
committer: Alexander Belchenko <alexander.belchenko @ gmail.com>
branch nick: Test
timestamp: Fri 2009-03-13 20:07:10 +0200
message:
  Скорректирован файл foo.txt в ветке Test
------------------------------------------------------------
revno: 2
committer: Alexander Belchenko <alexander.belchenko @ gmail.com>
branch nick: Test
timestamp: Tue 2009-03-10 15:38:19 +0200
message:
  Внесены изменения для иллюстрации команд status и diff
------------------------------------------------------------
revno: 1
committer: Alexander Belchenko <alexander.belchenko @ gmail.com>
branch nick: Test
timestamp: Tue 2009-03-10 11:06:24 +0200
message:
  Начальное состояние файлов

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

После объединения вся история ветки Experimental содержится в ветке Test. Мы видим ревизию из этой ветки под номером 2.1.1 в ветке Test. Если работа с веткой Experimental закончена, то ее можно смело удалить. Если ветка Experimental понадобится вновь, ее можно восстановить командой branch, указав номер ревизии при помощи опции --revision (-r):

C:\Temp>bzr branch Test Experimental -r 2.1.1
Branched 3 revision(s).

Итак, мы рассмотрели работу с несколькими ветками и научились объединять ветки. В следующих статьях мы рассмотрим другие команды для работы с ветками, а также научимся справляться с конфликтами объединения.

Начинаем работу с bzr: базовый набор команд (Часть 1)

2009-03-11T07:51:00.005Z

Как вы помните, bzr является распределенной системой контроля версий и не требует никакого специального сервера для своей работы. Поэтому начать работу с ней очень просто: вы можете создать новый репозиторий и новую ветку в любом удобном локальном каталоге на вашем компьютере. Далее мы рассмотрим 8 базовых команд bzr, которые понадобятся для локальной одиночной работы.

Сценарий работы

Инициализируем в локальном каталоге новую ветку для работы. В этом каталоге создадим несколько рабочих файлов. Добавим эти файлы под контроль версий. Зафиксируем начальное состояние файлов. Изменим некоторые из файлов. Просмотрим изменения в файлах. Зафиксируем новое состояние файлов. Просмотрим историю изменений. Создадим копию ветки для параллельной работы. Изменим некоторые файлы в старой и новой ветках и зафиксируем новое состояние. Объединим изменения в двух ветках.

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

Команды

В вышеприведенном сценарии работы выделены действия, производимые при помощи bzr. Команды bzr используют английские термины, соответствующие выполняемым действиям:

`init`	Инициализация	Инициализация новой ветки
`add`	Добавить	Добавить файлы под контроль версий
`commit`	Зафиксировать	Зафиксировать состояние файлов
`status`	Состояние	Показать состояние файлов, отобразить имена измененных файлов
`diff`	Разница	Показать изменения в файлах
`log`	Журнал	Просмотр журнала изменений, истории изменений
`branch`	Ветка	Создать новую ветку
`merge`	Объединить	Объединить изменения из разных веток

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

Инициализировать новую ветку

Инициализировать новую ветку в текущем каталоге:
C:\Temp\Test>bzr init Created a standalone tree (format: pack-0.92)

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

При инициализации создается служебный каталог с именем .bzr, в котором хранятся служебные файлы и история изменений.
Новая ветка инициализирована — можно добавлять файлы.

Добавить новые файлы

Для примера создадим два текстовых файла в рабочем каталоге:

-------Файл hello.txt---------

Привет
 ------------------------------

------Файл goodbye.txt--------Пока------------------------------Добавим файлы под контроль версий:

C:\Temp\Test>bzr add adding goodbye.txt adding hello.txt

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

Файлы добавлены — можно фиксировать их состояние.

Зафиксировать состояние файлов

Фиксация запоминает текущее состояние файлов. Пользователь должен дать комментарий к фиксируемым изменениям. Этот комментарий затем можно будет увидеть при просмотре журнала изменений. Хорошей практикой является описание цели и сути изменений в комментарии: конкретные изменения можно просмотреть при помощи команд bzr, а вот мотивы и цели изменений знает только автор изменений. Со временем это знание утрачивается, поэтому старайтесь писать четкие комментарии, которые будут понятны и через неделю/месяц/год.

C:\Temp\Test>bzr commit -m "Начальное состояние файлов" Committing to: C:/Temp/Test/ added goodbye.txt added hello.txt Committed revision 1.

Опция -m (--message) используется для указания комментария. Пользователь также может указать имя файла, из которого будет прочитан комментарий (используется опция --file, -F). Либо можно не указывать ничего, в этом случае будет запущен текстовый редактор, в котором вы сможете ввести свой комментарий.

Просмотр изменений

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

Изменим файл hello.txt и создадим новый файл foo.txt:

-------Файл hello.txt---------

Привет, мир!
 ------------------------------

--------Файл foo.txt----------Новый файл------------------------------

Для просмотра списка измененных файлов (состояние набора рабочих файлов) используется команда status:

C:\Temp\Test>bzr status modified: hello.txt unknown: foo.txt

bzr показал, что файл hello.txt был изменен, а также что появился неизвестный файл foo.txt. Неизвестными (unknown) считаются файлы, которые не находятся под контролем версий и не попадают в список игнорируемых (о списке игнорируемых файлов будет рассказано в других статьях). Поскольку команда commit фиксирует состояние только тех файлов, которые находятся под контролем версий, то нам необходимо добавить новый файл командой add:

C:\Temp\Test>bzr add adding foo.txt
Теперь status отрапортует о новом файле, как о добавленном:

C:\Temp\Test>bzr status added: foo.txt modified: hello.txt
Для того, чтобы увидеть не только имена изменных файлов, но и сами изменения в них, используется команда diff:

C:\Temp\Test>bzr diff === added file 'foo.txt' --- foo.txt 1970-01-01 00:00:00 +0000 +++ foo.txt 2009-03-10 13:13:56 +0000 @@ -0,0 +1,1 @@ +Новый файл === modified file 'hello.txt' --- hello.txt 2009-03-10 09:06:24 +0000 +++ hello.txt 2009-03-10 13:14:11 +0000 @@ -1,1 +1,1 @@ -Привет +Привет, мир!Команда diff отображает разницу между последним зафиксированным состоянием файла и текущим в формате unidiff (изменения показываются в виде групп, знак минус в начале строки индицирует старый удаленный текст, знак плюс в начале строки индицирует новый добавленный текст).

Примечание для пользователей Windows: обычно русский текст в файлах сохраняется в кодировке cp1251 (ANSI), в то время как кодировка консоли cp866 (DOS/OEM). Для того, чтобы увидеть русский текст в выводе команды diff нормально, а не ввиде иероглифов, переключите кодировку консоли командой:

chcp 1251

Обратное переключение осуществляется командой:

chcp 866

Если пользователя удовлетворяют эти изменения, то он может их зафиксировать:

C:\Temp\Test>bzr commit -m "Внесены изменения для иллюстрации команд status и diff" Committing to: C:/Temp/Test/ added foo.txt modified hello.txt Committed revision 2.
Просмотр истории

Для просмотра журнала изменений (зафиксированных ревизий) используется команда log:

C:\Temp\Test>bzr log
 ------------------------------------------------------------
 revno: 2
 committer: Alexander Belchenko <alexander.belchenko@gmail.com>
 branch nick: Test
 timestamp: Tue 2009-03-10 15:38:19 +0200
 message:
   Внесены изменения для иллюстрации команд status и diff
 ------------------------------------------------------------
 revno: 1
 committer: Alexander Belchenko <alexander.belchenko@gmail.com>
 branch nick: Test
 timestamp: Tue 2009-03-10 11:06:24 +0200
 message:
   Начальное состояние файлов

Для каждой ревизии выводится информация о номере, о том кто и когда зафиксировал изменения (поля committer и timestamp), название ветки (branch nick), а также комментарий (message). Журнал изменений — это важный инструмент для анализа прошлых изменений.

При запуске команды bzr log с опцией --verbose (-v) для каждой ревизии будет выведен список измененных файлов, аналогично команде status. Впрочем, вы можете использовать и команды status и diff для просмотра зафиксированных изменений. У этих команд есть опция --change (-c), которая позволяет просмотреть изменения зафиксированные в определенной ревизии:

C:\Temp\Test>bzr status -c 2 added: foo.txt modified: hello.txt

Также можно указать произвольный диапазон ревизий для просмотра внесенных изменений. Например, те же самые изменения во второй ревизии можно увидеть, если указать диапазон ревизий 1..2:

C:\Temp\Test>bzr status -r 1..2 added: foo.txt modified: hello.txt

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

Исправление ошибок при работе с Bazaar

2009-03-04T20:32:00.053Z

Errare humanum est (человеку свойственно ошибаться) — утверждение, с которым невозможно поспорить. Мудрый подход состоит не в том, чтобы пытаться избегать ошибок, а в том, чтобы научиться их исправлять. Собственно, одно из основных предназначений любой системы контроля версий — это возможность исправления ошибок. Используя систему контроля версий вы быстрее сможете понять почему перестала работать последняя ревизия вашего приложения, изучив изменения от предыдущей ревизии, или даже можете вернутся к старой, работающей, ревизии. Кроме этого, распределенные системы, в отличие от централизованных, отделяют момент фиксации изменений от момента их отправки (в обычном режиме работы), тем самым позволяя внимательнее рассмотреть изменения на предмет ошибок. Плюс ко всему этому, Bazaar предлагает свои подходы и команды для работы над ошибками, которые мы и рассмотрим ниже в приложении к типичным ситуациям. Если вы случайно ошиблись при создании ветки Bazaar из дерева исходного кода (с помощью команды bzr init) и превратили в ветку не то дерево, самое простое, что можно сделать - это удалить появившуюся служебную директорию .bzr. Конечно, здесь нужно быть внимательным чтобы не удалить нужную служебную директорию. Другая типичная ситуация - добавление под контроль версий (с помощью команды bzr add) не того файла. Часто в рабочей директории могут находится временные файлы, журналы тестовых запусков, или другие файлы, которые не нужно хранить под контролем версий. Но в случае выполнения команды bzr add без параметров, под контроль версий попадут все неизвестные файлы (исключая файлы указанные для игнорирования). Эту ситуацию можно исправить с помощью команды bzr remove. При этом команда remove без опций не будет удалять неизвестный, или измененный файл:

$ bzr add
$ bzr remove file.tmp
bzr: ERROR: Can't safely remove modified or unknown files:
added:
    file.tmp
Use --keep to not delete them, or --force to delete them regardless.

Здесь мы можем использовать опцию --keep что бы оставить файл как неизвестный и удалить его только из под контроля версий. Или можно использовать опцию --force для полного удаления файла. Но, если файл уже был зарегистрирован и не изменялся, то команда remove удалит его без необходимости указания дополнительных опций, т.к. файл может быть восстановлен на момент предыдущей ревизии с помощью команды revert, которую мы рассмотрим ниже:

$ bzr add TODO
$ bzr commit -m "Добавлен TODO"
$ bzr remove TODO

В случае, если не использовать команды Bazaar, а просто удалить файл с помощью команды операционной системы, то файл автоматически будет удален и из под контроля версий. Теперь представим, что мы решили попробовать какой-то новый вариант в проекте, изменили несколько файлов, но попытка не удалась и хочется просто вернуться к состоянию на момент последней фиксации изменений. В этом случае мы можем использовать команду revert:

$ bzr revert

Эта команда отменит все изменения в рабочей директории с момента последней фиксации (в том числе будут восстановлены удаленные файлы). В этом случае хорошей практикой является предварительное использование команд bzr status и bzr diff, что бы быть уверенным, что при отмене изменений не пропадет что-то нужное. Команда revert также позволяет указывать имена файлов для которых нужно отменить изменения:

$ bzr revert file.txt

При этом все остальные измененные файлы останутся нетронутыми. Еще одна уникальная для Bazaar функция (по крайней мере я не видел в других системах такого простого интерфейса) для работы надо ошибками — команда uncommit. С ее помощью можно отменить последнюю фиксацию и вернуть рабочее дерево в состояние на момент до выполнения фиксации. Незаменимая вещь на случай опечатки в сообщении о фиксации:

$ bzr commit -m "Очепятка"
$ bzr uncommit
$ bzr commit -m "Опечатка"

Кроме этого, с uncommit можно использовать опцию -r для отмены сразу нескольких ревизий:

$ bzr uncommit -r -3

При этом рабочее дерево останется в том же состоянии что и до выполнения отмененных фиксаций. С командой revert также можно использовать опцию -r для возврата рабочего дерева в состояние до указанной ревизии, но ревизии при этом не удаляются:

$ bzr commit -m "Исправления"
(выпуск релиза)
$ bzr revert -r -2
$ bzr commit -m "Отменено исправление"
(выпуск следующего релиза)

Также рассмотрим исправления, связанные с метками. Если вы поставили для ревизии метку с помощью команды bzr tag, но после этого обнаружили, что ее лучше перенести на более позднюю ревизию, то можно воспользоваться опцией --force:

$ bzr tag 1.0
(еще рано для первой версии, нужно сделать несколько изменений)
$ bzr tag 1.0 --force

Метка также может быть удалена с помощью опции --delete:

$ bzr tag 1.0
(еще рано для первой версии, нам пока не нужна метка)
$ bzr tag 1.0 --delete

bzr help: встроенная справочная служба класса "люкс" (Часть 2)

2009-03-01T21:11:00.002Z

Рассмотрим вывод справочной информации на примере команды branch, и посмотрим какую информацию мы там можем найти.

C:\>bzr help branch
Purpose: Create a new copy of a branch.
Usage:   bzr branch FROM_LOCATION [TO_LOCATION]

Options:
  --stacked             Create a stacked branch referring to the source
                        branch. The new branch will depend on the availability
                        of the source branch for all operations.
  -v, --verbose         Display more information.
  --standalone          Do not use a shared repository, even if available.
  -h, --help            Show help message.
  -q, --quiet           Only display errors and warnings.
  --hardlink            Hard-link working tree files where possible.
  -r ARG, --revision=ARG
                        See "help revisionspec" for details.

Description:
  If the TO_LOCATION is omitted, the last component of the FROM_LOCATION will
  be used.  In other words, "branch ../foo/bar" will attempt to create ./bar.
  If the FROM_LOCATION has no / or path separator embedded, the TO_LOCATION
  is derived from the FROM_LOCATION by stripping a leading scheme or drive
  identifier, if any. For example, "branch lp:foo-bar" will attempt to
  create ./foo-bar.

  To retrieve the branch as of a particular revision, supply the --revision
  parameter, as in "branch foo/bar -r 5".

Aliases:  get, clone
See also: checkout

Здесь:

Purpose — назначение команды
Usage — командная строка с указанием ожидаемых аргументов
Options — опции командной строки
Description — подробное описание команды и вариантов использования
Aliases — встроенные псевдонимы для команды
See also — ссылки на схожие по тематике разделы справки

Аргументы командной строки

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

Опции командной строки

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

Опции -v и -q отображаются для всех команд, однако для некоторых команд они не имеют эффекта.

Псевдонимы

Некоторые команды могут иметь псевдонимы. Это сделано для удобства и для имитации поведения других систем контроля версий, чтобы пользователям при переходе на Базар было легче осваиваться. Во многих случаях псевдонимы предлагают более короткую форму записи имени для часто используемых команд. Так например, команда status имеет псевдоним st, а команда diff имеет псевдоним di.

В дополнение к встроенным псевдонимам Базар поддерживает также псевдонимы определяемые пользователем. О них мы расскажем в следующих статьях.

See also (см. также)

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

Итак, теперь вы знаете об использовании справки достаточно, чтобы не растеряться в ответственный момент. Помните, что аргументы и опции можно записывать вперемешку, и что опция -h (--help) выводит справку по команде без запуска самой команды. Так что если вы начали писать команду и вдруг решили перечитать справку по ней, то можете просто дописать -h в конце и нажать Enter. А прочитав справку, вызовите предыдущую команду (в большинстве командных процессоров это делается просто нажатием стрелки вверх) и отредактируйте ее нужным образом.

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

bzr help: встроенная справочная служба класса "люкс" (Часть 1)

2009-02-25T20:56:00.003Z

Любому пользователю bzr (от новичка до профи) время от времени нужна справочная информация: всего не упомнишь, всех нюансов в голове не удержишь, тем более если речь идет о мало используемых или незнакомых командах и опциях. В таких ситуациях нужно помнить главное: справка у вас всегда под руками. И я говорю не про man bzr, а про встроенный механизм справки, вызываемый по команде bzr help. Команда bzr help, помимо очевидных вещей типа справки к командам и опциям, имеет также неплохой каталог дополнительной справочной информации о базовых концепциях, настройках и конфигурации bzr, и даже такой материал как объяснение типов конфликтов объединения и как с ними бороться. Должен сказать, что разработчики bzr уделяют справке внимание, что положительно сказывается на ее количестве и качестве. Многие пункты справки содержат информации на несколько экранов, так что для удобства чтения используйте программы типа more или less.

Полезный совет для пользователей Windows: скачайте и установите программу less, которая значительно превосходит по функциональности стандартную more. После установки добавьте папку с программой в список в переменную окружения PATH.

Итак, посмотрим, что же может предложить bzr help. Запускаем и видим краткую сводку по базовым командам:

C:\>bzr help
Bazaar -- a free distributed version-control tool
http://bazaar-vcs.org/

Basic commands:
bzr init           makes this directory a versioned branch
bzr branch         make a copy of another branch

bzr add            make files or directories versioned
bzr ignore         ignore a file or pattern
bzr mv             move or rename a versioned file

bzr status         summarize changes in working copy
bzr diff           show detailed diffs

bzr merge          pull in changes from another branch
bzr commit         save some or all changes
bzr send           send changes via email

bzr log            show history of changes
bzr check          validate storage

bzr help init      more help on e.g. init command
bzr help commands  list all commands
bzr help topics    list all help topics

Команды сгруппированы по назначению:

init, branch — создание новой ветки с нуля или путем клонирования существующей
add, ignore, mv — процесс добавления файлов под контроль версий, информирование об игнорируемых объектах, переименование через bzr
status, diff — просмотр изменений в файлах
merge, commit, send — фиксация изменений (commit), объединений изменений в двух ветках (merge), отправка патчей по электронной почте (send)
log — просмотр истории изменений

Ниже вы видите пример того, как получить справку по конкретной команде — например, вызывая bzr help init либо используя опцию -h или --help после имени команды: bzr init -h. Для того, чтобы получить список всех доступных команд, запустите bzr help commands; рекомендую использовать less для просмотра:

bzr help commands | less

Будет выведен список всех команд в алфавитном порядке с кратким описанием для каждой команды. Обратите внимание на команду bzr help topics.

Эта команда выводит оглавление всех доступных материалов встроенной справки в виде списка: слева названия статей, справа — краткое описание материала. Ниже приведены первые несколько строк из списка статей (для bzr 1.12):

C:\>bzr help topics
authentication       Information on configuring authentication
basic                Basic commands
branches             Information on what a branch is
bugs                 Bug tracker settings
checkouts            Information on what a checkout is
commands             Basic help for all commands
configuration        Details on the configuration settings available
conflicts            Types of conflicts and what to do about them

Используйте название статьи для доступа к ее тексту. Например, команда

bzr help configuration

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

Настройки bzr: whoami или как меня зовут

2009-02-24T00:51:00.001Z

После установки bzr сразу можно приступать к работе, однако стоит потратить пару минут на настройку некоторых важных параметров. Одним из таких параметров является ваша личная идентификация. Другими словами — ваше имя, ваш идентификатор для bzr. Это имя будет использоваться bzr для подписывания изменений, которые вы будете фиксировать. И поскольку история ваших фиксаций будет оставаться неизменной все время, то стоит позаботиться о том, чтобы ваше имя отображалось правильно. Чтобы узнать ваш текущий идентификатор используйте команду:

bzr whoami

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

vasya@home

Если подобный идентификатор вас устраивает, то можете ничего не менять. Иначе задайте свое настоящее имя при помощи этой же команды whoami, но с соответствующим аргументом:

bzr whoami "Василий Пупкин <vasya.pupkin@gmail.com>"

Здесь в кавычкаx задается имя и дополнительно может задаваться электронный почтовый адрес (в угловых скобках). Проверим установки:

$ bzr whoamiВасилий Пупкин <vasya.pupkin@gmail.com>

Настройка вашего идентификатора сохраняется в файле глобальных настроек bazaar.conf (в вашем домашнем каталоге). Этот идентификатор будет использоваться для фиксации всех веток. О том, как задать отличающийся идентификатор для некоторых веток будет рассказано в следующих статьях.

Установка bzr

2009-02-23T21:16:00.000Z

Для установки bzr в вашей системе нужно выбрать соответствующий пакет или дистрибутив из перечисленных на странице Download.
Кратко рассмотрим варианты установки для различных операционных систем.

Установка из исходных кодов

Система контроля версий Bazaar написана на языке программирования Python (Питон), что облегчает ее установку и использование: достаточно иметь установленный интерпретатор языка Python в вашей системе (версии 2.4–2.6, рекомендуется 2.5). Опытные пользователи Python могут использовать стандартное "заклинание": python setup.py install для установки. Более подробно об опциях установки можно прочитать в файле INSTALL.

Установка для ОС Linux

Для большинства популярных дистрибутивов Linux имеются готовые пакеты для установки bzr. Каждый конкретный дистрибутив имеет свои особенности, поэтому ознакомьтесь с детальными инструкциями на странице DistroDownloads.

Если вы используете Ubuntu Linux, то скорее всего bzr уже будет установлен в вашей системе. Однако вам имеет смысл ознакомиться с процессом обновления bzr, для того, чтобы регулярно устанавливать свежую версию. Разработка bzr идет достаточно интенсивно и примерно каждый месяц выпускается новая версия. Новые версии как правило работают быстрее и содержат значительное количество исправлений известных ошибок.

Установка для ОС Windows

Наиболее оптимальным и рекомендуем способом установки bzr в ОС Windows является использование инсталлятора автономной версии (Windows Standalone Installer). Автономная версия содержит скомпилированную программу bzr.exe для Windows, и поставляется с набором всех необходимых библиотек. Также инсталлятор автономной версии предлагает установить набор популярных плагинов для bzr, а также программу TortoiseBzr, которая предоставляет интеграцию bzr-команд в Explorer.

Альтернативным вариантом установки является использование инсталляторов питон-версии bzr (python installer). Для работы питон-версии вам потребуется установленный интерпретатор Python (версии 2.4–2.6, рекомендуется 2.5), а также набор дополнительных библиотек. См. http://bazaar-vcs.org/WindowsInstall для дополнительных инструкций.

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

Установка для ОС Mac OS X

Для компьютеров фирмы Apple также имеются готовые инсталляторы, а также специальные репозитории портированных программ: MacPorts и Fink. См. ссылки на подробные инструкции на странице Download.