<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="ru">
<head>
<meta http-equiv="X-UA-Compatible" content="IE=Edge" />
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>1 Руководство пользователя Bazaar — Документация Bazaar 2.7.0</title>
<link rel="stylesheet" href="../_static/classic.css" type="text/css" />
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
<script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
<script type="text/javascript" src="../_static/jquery.js"></script>
<script type="text/javascript" src="../_static/underscore.js"></script>
<script type="text/javascript" src="../_static/doctools.js"></script>
<script type="text/javascript" src="../_static/language_data.js"></script>
<script type="text/javascript" src="../_static/translations.js"></script>
<link rel="shortcut icon" href="../_static/bzr.ico"/>
<link rel="search" title="Поиск" href="../search.html" />
</head><body>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Навигация</h3>
<ul>
<li><a href="http://bazaar.canonical.com/">
<img src="../_static/bzr icon 16.png" /> Главная</a> | </li>
<a href="http://doc.bazaar.canonical.com/ru/">Документация</a> | </li>
<li class="nav-item nav-item-0"><a href="../index.html">Содержание (2.7.0)</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<div class="section" id="bazaar">
<h1><a class="toc-backref" href="#id75">1 Руководство пользователя Bazaar</a><a class="headerlink" href="#bazaar" title="Ссылка на этот заголовок">¶</a></h1>
<div class="contents topic" id="id1">
<p class="topic-title first">Содержание</p>
<ul class="auto-toc simple">
<li><a class="reference internal" href="#bazaar" id="id75">1 Руководство пользователя Bazaar</a><ul class="auto-toc">
<li><a class="reference internal" href="#id2" id="id76">1.1 Введение</a></li>
<li><a class="reference internal" href="#id22" id="id77">1.2 Начинаем работать</a></li>
<li><a class="reference internal" href="#id30" id="id78">1.3 Личный контроль версий</a></li>
<li><a class="reference internal" href="#id34" id="id79">1.4 Делимся с другими</a></li>
<li><a class="reference internal" href="#id38" id="id80">1.5 Сотрудничество в команде, централизованный стиль</a></li>
<li><a class="reference internal" href="#id42" id="id81">1.6 Сотрудничество в команде, распределенный стиль</a></li>
<li><a class="reference internal" href="#id46" id="id82">1.7 Различные темы</a></li>
<li><a class="reference internal" href="#id55" id="id83">1.8 Краткое описание некоторых популярных плагинов</a></li>
<li><a class="reference internal" href="#id57" id="id84">1.9 Интегрируем Bazaar в нашу среду</a></li>
<li><a class="reference internal" href="#id59" id="id85">1.10 Приложения</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="id2">
<h2><a class="toc-backref" href="#id76">1.1 Введение</a><a class="headerlink" href="#id2" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="id3">
<h3>1.1.1 Представляем Bazaar<a class="headerlink" href="#id3" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id4">
<h4>1.1.1.1 Что такое Bazaar?<a class="headerlink" href="#id4" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar - это инструмент помогающий людям сотрудничать. Он отслеживает
изменения, которые вы и другие люди делают с группой файлов, (таких как
исходный код программы) для того что бы дать вам снимок каждого этапа их
эволюции. Используя эту информацию, Bazaar может без проблем объединить вашу
работу с работой других людей.</p>
<p>Такие инструменты как Bazaar называются системами контроля версий (Version
Control System (VCS)) и уже долгое время популярны среди разработчиков ПО.
Легкость использования, гибкость и простота настройки Bazaar делают его
идеальным не только для разработчиков ПО, но так же и для других групп,
работающих совместно с файлами и документами, таких как технические писатели,
Web-дизайнеры и переводчики.</p>
<p>Это руководство описывает установку и использование Bazaar вне зависимости от
того работает вы один, или в команде с другими людьми. Если вы уже знаете, что
такое распределенная система контроля версий и хотите перейти прямо к описанию
работы вы можете бегло просмотреть эту секцию и перейти прямо к
<a class="reference internal" href="#id8">Продолжаем изучение</a>.</p>
</div>
<div class="section" id="id5">
<h4>1.1.1.2 Краткая история систем контроля версий<a class="headerlink" href="#id5" title="Ссылка на этот заголовок">¶</a></h4>
<p>Инструменты для контроля версий на данный момент развиваются уже в течение
нескольких десятилетий. Простыми словами можно описать 4 поколения таких
инструментов:</p>
<blockquote>
<div><ol class="arabic simple">
<li>инструменты контроля версий файлов, например CSSC, RCS</li>
<li>инструменты контроля дерева файлов - централизованный стиль, например CVS</li>
<li>инструменты контроля дерева файлов - централизованный стиль, этап 2,
например Subversion</li>
<li>инструменты контроля дерева файлов - распределенный стиль, например Bazaar.</li>
</ol>
</div></blockquote>
<p>Дизайн и реализация Bazaar учитывает уроки полученные на каждом из этих этапов
развития подобных инструментов. В частности, Bazaar аккуратно поддерживает и
централизованную и распределенную модели контроля версий и таким образом вы
можете менять модель работы (когда это имеет смысл) без необходимости смены
инструмента.</p>
</div>
<div class="section" id="id6">
<h4>1.1.1.3 Централизованная модель против распределенной<a class="headerlink" href="#id6" title="Ссылка на этот заголовок">¶</a></h4>
<p>Многие традиционные инструменты контроля версий требуют наличия центрального
сервера, который хранит историю изменений (или <em>репозиторий</em>) для дерева
файлов. Что бы работать с файлами пользователю необходимо установить соединение
с сервером и получить <em>рабочую версию</em> файлов. Таким образом пользователь
получает <em>рабочее дерево</em> в котором он может работать. Для сохранения, или
<em>фиксации</em> изменений пользователю нужен доступ к центральному серверу и он
должен убедиться, что перед фиксацией он объединил свою работу с последней
версией сохраненной на сервере. Такой подход известен как централизованная
модель.</p>
<p>Централизованная модель проверена достаточно долгой практикой, но она имеет и
некоторые значительные недостатки. Во-первых, централизованная система требует
наличия соединения с сервером при выполнении большинства операций по контролю
версий. Во-вторых, централизованная модель жестко связывает момент <strong>фиксации</strong>
изменений с моментом их <strong>публикации</strong>. В каких-то ситуациях это может быть
нормально, но может сказываться негативно в других.</p>
<p>Распределенные системы контроля версий позволяют отдельным пользователям и
командам иметь несколько репозиториев, вместо одного центрального. В случае с
Bazaar история обычно хранится в том же месте, что и код который находится под
контролем версий. Это позволяет пользователю фиксировать свои изменения в любой
момент когда это нужно, даже при отсутствии сетевого соединения. Сетевое
соединение требуется только для публикации изменений, или когда нужен доступ к
изменениям в другом месте.</p>
<p>На самом деле для разработчиков использование распределенных систем контроля
версий может иметь другие преимущества, кроме очевидных, связанных с работой
при отсутствии сетевого соединения. Другие преимущества включают:</p>
<blockquote>
<div><ul class="simple">
<li>более легкое создание разработчиками экспериментальных веток</li>
<li>более легкое сотрудничество с другими разработчикам</li>
<li>меньше времени требуется для механических задач и больше для творчества</li>
<li>увеличение гибкости в управлении релизами через использование
фиксаций включающих набор изменений для конкретной функциональности</li>
<li>качество и стабильность основной ветки может быть выше, что делает
работу проще для каждого</li>
<li>для сообществ с открытым исходным кодом:<ul>
<li>более легкое создание и поддержка изменений для сторонних разработчиков</li>
<li>упрощение взаимодействия основных разработчиков со сторонними
разработчиками и более простая миграция сторонних разработчиков в основные</li>
</ul>
</li>
<li>для компаний - упрощение работы с распределенными и внешними командами.</li>
</ul>
</div></blockquote>
<p>Для более детального взгляда на преимущества распределенных систем контроля
версий по сравнению с централизованными смотрите <a class="reference external" href="http://wiki.bazaar.canonical.com/BzrWhy">http://wiki.bazaar.canonical.com/BzrWhy</a>.</p>
</div>
<div class="section" id="id7">
<h4>1.1.1.4 Ключевые особенности Bazaar<a class="headerlink" href="#id7" title="Ссылка на этот заголовок">¶</a></h4>
<p>Хотя Bazaar не единственная распределенная система контроля версий, она имеет
некоторые значимые преимущества, которые делают ее прекрасным выбором для
многих команд и сообществ. Описание этих особенностей и сравнение с другими
системами контроля версий может быть найдено на Wiki Bazaar -
<a class="reference external" href="http://wiki.bazaar.canonical.com">http://wiki.bazaar.canonical.com</a>.</p>
<p>Из большинства особенностей, одна требует особого упоминания: Bazaar - это
полностью свободное ПО написанное на языке Python. Это упрощает сотрудничество
для внесения улучшений. Если вы хотите помочь, обратите внимание на
<a class="reference external" href="http://wiki.bazaar.canonical.com/BzrSupport">http://wiki.bazaar.canonical.com/BzrSupport</a>.</p>
</div>
<div class="section" id="id8">
<h4>1.1.1.5 Продолжаем изучение<a class="headerlink" href="#id8" title="Ссылка на этот заголовок">¶</a></h4>
<p>Это руководство представляет из себя легкое для чтения введение в Bazaar и
описание его использования. Всем пользователям рекомендуется прочесть хотя бы
окончание этой главы, так как:</p>
<blockquote>
<div><ul class="simple">
<li>она описывает основные концепции, которые нужно знать пользователям</li>
<li>она описывает некоторые популярные пути использования Bazaar для
сотрудничества.</li>
</ul>
</div></blockquote>
<p>Главы 2-6 более детально описывают использование Bazaar для выполнения
различных задач. Большинству пользователей рекомендуется прочесть их одну за
другой сразу после начала использования Bazaar. Глава 7 и дальше содержат
дополнительную информацию, которая поможет получить максимум от Bazaar после
того как понятны основные функции. Этот материал может быть прочитан когда
потребуется и в любом порядке.</p>
<p>Если вы уже хорошо знакомы с другими системами контроля версий, вы возможно
захотите вникнуть скорее через чтение следующих документов:</p>
<blockquote>
<div><ul class="simple">
<li><a class="reference external" href="../mini-tutorial/index.html">Bazaar за пять минут</a> - небольшое введение</li>
<li><a class="reference external" href="../quick-reference/quick-start-summary.svg">Bazaar. Карточка быстрого старта</a> - наиболее часто используемые команды на
одной странице.</li>
</ul>
</div></blockquote>
<p>Плюс к этому справка на сайте и <a class="reference external" href="../../en/user-reference/bzr_man.html">Справка по Bazaar</a> предоставляют все детали
по доступным командам и опциям.</p>
<p>Мы надеемся, что вам понравится это руководство. Если у вас есть пожелания по
улучшению документации Bazaar вы можете написать в список рассылки
<a class="reference external" href="mailto:bazaar%40lists.canonical.com">bazaar<span>@</span>lists<span>.</span>canonical<span>.</span>com</a>.</p>
</div>
</div>
<div class="section" id="id12">
<h3>1.1.2 Основные концепции<a class="headerlink" href="#id12" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id13">
<h4>1.1.2.1 Простая модель для пользователя<a class="headerlink" href="#id13" title="Ссылка на этот заголовок">¶</a></h4>
<p>Для использования Bazaar нужно понимать четыре основные концепции:</p>
<ul class="simple">
<li><strong>Ревизия</strong> - снимок файлов с которыми вы работаете.</li>
<li><strong>Рабочее дерево</strong> - каталог содержащий файлы и каталоги под контролем версий</li>
<li><strong>Ветка</strong> - упорядоченный набор ревизий, описывающий историю набора файлов.</li>
<li><strong>Репозиторий</strong> - хранилище ревизий.</li>
</ul>
<p>Давайте рассмотрим каждую концепцию более детально.</p>
</div>
<div class="section" id="id14">
<h4>1.1.2.2 Ревизия<a class="headerlink" href="#id14" title="Ссылка на этот заголовок">¶</a></h4>
<p>Ревизия - это <em>снимок</em> состояния дерева файлов и каталогов включающий их
содержимое и форму. С ревизией так же связаны некоторые мета-данные, например:</p>
<ul class="simple">
<li>Кто зафиксировал ревизию</li>
<li>Когда ревизия была зафиксирована</li>
<li>Комментарий к ревизии</li>
<li>Родительские ревизии от которых была унаследована данная ревизия</li>
</ul>
<p>Ревизии не изменяются и могут быть глобально и уникально идентифицированы
<em>идентификатором ревизии</em>. Пример идентификатора:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">pqm</span><span class="nd">@pqm</span><span class="o">.</span><span class="n">ubuntu</span><span class="o">.</span><span class="n">com</span><span class="o">-</span><span class="mi">20071129184101</span><span class="o">-</span><span class="n">u9506rihe4zbzyyz</span>
</pre></div>
</div>
<p>Идентификаторы ревизий создаются во время фиксации, или, в случае импорта из
других систем, в момент импорта. Хотя идентификаторы ревизий необходимы для
внутреннего использования и интеграции с внешними инструментами, специфичные
для веток <em>номера ревизий</em> предпочтительны для людей.</p>
<p>Номера ревизий - это разделенные точками десятичные идентификаторы, такие как
1, 42 и 2977.1.59, которые отслеживают путь через граф номеров ревизий на
ветке. Номера ревизий обычно короче чем идентификаторы ревизий и, в пределах
одной ветки, могут сравниваться друг с другом для получения картины их
отношений. Например, ревизия 10 - это основная ревизия (см. ниже) следующая
непосредственно после ревизии 9. Номера ревизий создаются налету, при
выполнении каждой команды, т.к. они зависят от ревизии являющейся верхушкой
(т.е. самой последней ревизией) на ветке.</p>
<p>Смотрите <a class="reference internal" href="#id60">Определение ревизий</a> в приложениях для более детального описания
огромного количества методов задания ревизий и их диапазонов в Bazaar и
<a class="reference internal" href="#id26">Понимание номеров ревизий</a> для более детального описания нумерации ревизий.</p>
</div>
<div class="section" id="id15">
<h4>1.1.2.3 Рабочее дерево<a class="headerlink" href="#id15" title="Ссылка на этот заголовок">¶</a></h4>
<p>Рабочее дерево - это <em>каталог под контролем версий</em> содержащий файлы которые
может редактировать пользователь. Рабочее дерево связано с <em>веткой</em>.</p>
<p>Многие команды используют рабочее дерево как контекст, например <code class="docutils literal notranslate"><span class="pre">commit</span></code>
создает новую ревизию используя текущее содержимое файлов в рабочем дереве.</p>
</div>
<div class="section" id="id16">
<h4>1.1.2.4 Ветка<a class="headerlink" href="#id16" title="Ссылка на этот заголовок">¶</a></h4>
<p>В простейшем случае, ветка - это <em>упорядоченная серия ревизий</em>. Самая последняя
ревизия известна как <em>верхушка</em>.</p>
<p>Ветки могут быть разделены и <em>объединены</em> обратно, формируя <em>граф</em> ревизий.
Технически, граф показывает прямые отношения (между родительской и дочерними
ревизиями) и не имеет петель, и известен как <em>направленный ациклический граф</em>
(directed acyclic graph (DAG)).</p>
<p>Но не стоит бояться этого названия. Основные вещи которые нужно помнить:</p>
<ul class="simple">
<li>Основная линия разработки внутри графа называется <em>основная линия</em>,
или просто <em>левая сторона</em>.</li>
<li>Ветка может иметь другие линии разработки и в этом случае они начинаются
в одной точке и заканчиваются в другой.</li>
</ul>
</div>
<div class="section" id="id17">
<h4>1.1.2.5 Репозиторий<a class="headerlink" href="#id17" title="Ссылка на этот заголовок">¶</a></h4>
<p>Репозиторий - это просто <em>хранилище ревизий</em>. В простейшем случае, каждая ветка
имеет свой собственный репозиторий. В других случаях имеет смысл разделять
репозиторий между ветками для оптимизации дискового пространства.</p>
</div>
<div class="section" id="id18">
<h4>1.1.2.6 Складывая концепции вместе<a class="headerlink" href="#id18" title="Ссылка на этот заголовок">¶</a></h4>
<p>Как только вы поняли описанные выше концепции, различные пути использования
Bazaar станут более понятными. Простейший способ использования Bazaar - это
использовать <em>самостоятельное дерево</em>, совмещающее рабочее дерево, ветку и
репозиторий в одном месте. Другие часто используемые сценарии включают:</p>
<ul class="simple">
<li><a class="reference external" href="#a-reminder-about-shared-repositories">Разделяемые репозитории</a> -
рабочее дерево и ветка находятся вместе, но репозиторий находится в
каталоге выше.</li>
<li><a class="reference external" href="#using-stacked-branches">Стек веток</a> - ветка хранит только уникальные
для нее ревизии и использует родительский репозиторий для общих ревизий.</li>
<li><a class="reference external" href="#getting-a-lightweight-checkout">Легковесные рабочие копии</a> -
ветка хранится в другом месте по сравнению с рабочим деревом.</li>
</ul>
<p>Лучший путь для использования Bazaar конечно зависит от ваших потребностей.
Давайте дальше рассмотрим некоторые часто употребляемые способы использования.</p>
</div>
</div>
<div class="section" id="workflows">
<h3>1.1.3 Workflows<a class="headerlink" href="#workflows" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="bazaar-is-just-a-tool">
<h4>1.1.3.1 Bazaar is just a tool<a class="headerlink" href="#bazaar-is-just-a-tool" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar supports many different ways of working together.
This means that you can
start with one workflow and adapt it over time as circumstances
change. There is no «one true way» that always makes sense and
there never will be. This section provides a brief overview of
some popular workflows supported by Bazaar.</p>
<p>Keep in mind that these workflow are just <em>some</em> examples of how
Bazaar can be used. You may want to use a workflow not listed here,
perhaps building on the ideas below.</p>
</div>
<div class="section" id="solo">
<h4>1.1.3.2 Solo<a class="headerlink" href="#solo" title="Ссылка на этот заголовок">¶</a></h4>
<p>Whether developing software, editing documents or changing configuration files,
having an easy-to-use VCS tool can help. A single user can use this workflow
effectively for managing projects where they are the only contributor.</p>
<img alt="../_images/workflows_single.png" src="../_images/workflows_single.png" />
<p>Advantages of this workflow over not using version control at all include:</p>
<blockquote>
<div><ul class="simple">
<li>backup of old versions</li>
<li>rollback to an earlier state</li>
<li>tracking of history.</li>
</ul>
</div></blockquote>
<p>The key features of Bazaar appropriate for this workflow are low administration
(no server setup) and ease of use.</p>
</div>
<div class="section" id="partner">
<h4>1.1.3.3 Partner<a class="headerlink" href="#partner" title="Ссылка на этот заголовок">¶</a></h4>
<p>Sometimes two people need to work together sharing changes as they go. This
commonly starts off as a <em>Solo</em> workflow (see above) or a team-oriented
workflow (see below). At some point, the second person takes a branch (copy
including history) of what the first person has done. They can then work in
parallel exchanging changes by merging when appropriate.</p>
<img alt="../_images/workflows_peer.png" src="../_images/workflows_peer.png" />
<p>Advantages over <em>Solo</em> are:</p>
<blockquote>
<div><ul class="simple">
<li>easier sharing of changes</li>
<li>each line of each text file can be attributed to a particular change
including who changed it, when and why.</li>
</ul>
</div></blockquote>
<p>When implementing this workflow, Bazaar’s advantages over CVS and Subversion include:</p>
<blockquote>
<div><ul class="simple">
<li>no server to setup</li>
<li>intelligent merging means merging multiple times isn’t painful.</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="centralized">
<h4>1.1.3.4 Centralized<a class="headerlink" href="#centralized" title="Ссылка на этот заголовок">¶</a></h4>
<p>Also known as <em>lock-step</em>, this is essentially the same as the workflow
encouraged/enforced by CVS and Subversion. All developers work on the same
branch (or branches). They run <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">update</span></code> to get their checkout up-to-date,
then <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">commit</span></code> to publish their changes to the central location.</p>
<img alt="../_images/workflows_centralized.png" src="../_images/workflows_centralized.png" />
<p>Subversion and CVS are good choices for implementing this workflow because they
make it easy. Bazaar directly supports it as well while providing some
important advantages over CVS and Subversion:</p>
<blockquote>
<div><ul class="simple">
<li>better branching and merging</li>
<li>better renaming support.</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="centralized-with-local-commits">
<h4>1.1.3.5 Centralized with local commits<a class="headerlink" href="#centralized-with-local-commits" title="Ссылка на этот заголовок">¶</a></h4>
<p>This is essentially the same as the <em>Centralized</em> model, except that when
developers are making a series of changes, they do <code class="docutils literal notranslate"><span class="pre">commit</span> <span class="pre">--local</span></code> or unbind
their checkout. When it is complete, they commit their work to the shared
mainline.</p>
<img alt="../_images/workflows_localcommit.png" src="../_images/workflows_localcommit.png" />
<p>Advantages over <em>Centralized</em>:</p>
<blockquote>
<div><ul class="simple">
<li>Can work offline, e.g. when disconnected during travel</li>
<li>Less chance for a bad commit to interfere with everyone else’s work</li>
</ul>
</div></blockquote>
<p>Subversion and CVS do not support this model. Other distributed VCS tools can
support it but do so less directly than Bazaar does.</p>
</div>
<div class="section" id="decentralized-with-shared-mainline">
<h4>1.1.3.6 Decentralized with shared mainline<a class="headerlink" href="#decentralized-with-shared-mainline" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this workflow, each developer has their own branch or branches, plus commit
rights to the main branch. They do their work in their personal branch, then
merge it into the mainline when it is ready.</p>
<img alt="../_images/workflows_shared.png" src="../_images/workflows_shared.png" />
<p>Advantage over <em>Centralized with local commits</em>:</p>
<blockquote>
<div><ul class="simple">
<li>Easier organization of work - separate changes can be developed in their own branches</li>
<li>Developers can merge one another’s personal branches when working on something together.</li>
</ul>
</div></blockquote>
<p>Subversion and CVS do not support this model. Other distributed VCS
tools support it. Many features of Bazaar are good for this workflow
including ease of use, shared repositories, integrated merging and
rich metadata (including directory rename tracking).</p>
</div>
<div class="section" id="decentralized-with-human-gatekeeper">
<h4>1.1.3.7 Decentralized with human gatekeeper<a class="headerlink" href="#decentralized-with-human-gatekeeper" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this workflow, each developer has their own branch or branches, plus
read-only access to the main branch. One developer (the gatekeeper) has commit
rights to the main branch. When a developer wants their work merged, they ask
the gatekeeper to merge it. The gatekeeper does code review, and merges the
work into the main branch if it meets the necessary standards.</p>
<img alt="../_images/workflows_gatekeeper.png" src="../_images/workflows_gatekeeper.png" />
<p>Advantage over <em>Decentralized with shared mainline</em>:</p>
<blockquote>
<div><ul class="simple">
<li>Code is always reviewed before it enters the mainline</li>
<li>Tighter control over when changes get incorporated into the mainline.</li>
</ul>
</div></blockquote>
<p>A companion tool of Bazaar’s called Bundle Buggy can be very useful for
tracking what changes are up for review, their status and reviewer comments.</p>
</div>
<div class="section" id="decentralized-with-automatic-gatekeeper">
<h4>1.1.3.8 Decentralized with automatic gatekeeper<a class="headerlink" href="#decentralized-with-automatic-gatekeeper" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this workflow, each developer has their own branch or branches, plus
read-only access to the mainline. A software gatekeeper has commit rights to
the main branch. When a developer wants their work merged, they request another
person to review it. Once it has passed review, either the original author or
the reviewer asks the gatekeeper software to merge it, depending on team
policies. The gatekeeper software does a merge, a compile, and runs the test
suite. If and only if the code passes, it is merged into the mainline.</p>
<p>Note: As an alternative, the review step can be skipped and the author can
submit the change to the automatic gatekeeper without it. (This is particularly
appropriate when using practices such as Pair Programming that effectively
promote just-in-time reviews instead of reviewing code as a separate step.)</p>
<img alt="../_images/workflows_pqm.png" src="../_images/workflows_pqm.png" />
<p>Advantages over <em>Decentralized with human gatekeeper</em>:</p>
<blockquote>
<div><ul class="simple">
<li>Code is always tested before it enters the mainline (so the integrity of the
mainline is higher)</li>
<li>Scales better as teams grow.</li>
</ul>
</div></blockquote>
<p>A companion tool of Bazaar’s called Patch Queue Manager (PQM) can provide the
automated gatekeeper capability.</p>
</div>
<div class="section" id="implementing-a-workflow">
<h4>1.1.3.9 Implementing a workflow<a class="headerlink" href="#implementing-a-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>For an in-depth look at how to implement each of the workflows above,
see chapters 3 to 6 in this manual. First though, chapter 2
explains some important pre-requisites including installation, general
usage instructions and configuration tips.</p>
</div>
</div>
</div>
<div class="section" id="id22">
<h2><a class="toc-backref" href="#id77">1.2 Начинаем работать</a><a class="headerlink" href="#id22" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="installing-bazaar">
<h3>1.2.1 Installing Bazaar<a class="headerlink" href="#installing-bazaar" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="gnu-linux">
<h4>1.2.1.1 GNU/Linux<a class="headerlink" href="#gnu-linux" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar packages are available for most popular GNU/Linux distributions
including Ubuntu, Debian, Red Hat and Gentoo.
See <a class="reference external" href="http://wiki.bazaar.canonical.com/Download">http://wiki.bazaar.canonical.com/Download</a> for the latest instructions.</p>
</div>
<div class="section" id="windows">
<h4>1.2.1.2 Windows<a class="headerlink" href="#windows" title="Ссылка на этот заголовок">¶</a></h4>
<p>For Windows users, an installer is available that includes
the core Bazaar package together with necessary pre-requisites
and some useful plug-ins.
See <a class="reference external" href="http://wiki.bazaar.canonical.com/Download">http://wiki.bazaar.canonical.com/Download</a> for the latest instructions.</p>
<p>Note: If you are running Cygwin on Windows, a Bazaar for Cygwin package
is available and ought to be used instead of the Windows version.</p>
</div>
<div class="section" id="other-operating-systems">
<h4>1.2.1.3 Other operating systems<a class="headerlink" href="#other-operating-systems" title="Ссылка на этот заголовок">¶</a></h4>
<p>Beyond Linux and Windows, Bazaar packages are available for a large
range of other operating systems include Mac OS X, FreeBSD and Solaris.
See <a class="reference external" href="http://wiki.bazaar.canonical.com/Download">http://wiki.bazaar.canonical.com/Download</a> for the latest instructions.</p>
</div>
<div class="section" id="installing-from-scratch">
<h4>1.2.1.4 Installing from scratch<a class="headerlink" href="#installing-from-scratch" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you wish to install Bazaar from scratch rather than using a
pre-built package, the steps are:</p>
<blockquote>
<div><ol class="arabic simple">
<li>If it is not installed already, install Python 2.6 or later.</li>
<li>Download the <code class="docutils literal notranslate"><span class="pre">bazaar-xxx.tar.gz</span></code> file (where xxx is the version
number) from <a class="reference external" href="http://wiki.bazaar.canonical.com/Download">http://wiki.bazaar.canonical.com/Download</a> or from Launchpad
(<a class="reference external" href="https://launchpad.net/~bzr/">https://launchpad.net/~bzr/</a>).</li>
<li>Unpack the archive using tar, WinZip or equivalent.</li>
<li>Put the created directory on your PATH.</li>
</ol>
</div></blockquote>
<p>To test the installation, try running the <strong>bzr</strong> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">version</span>
</pre></div>
</div>
<p>This will display the version of Bazaar you have installed. If this
doesn’t work, please contact us via email or IRC so we can help you
get things working.</p>
<div class="section" id="installing-into-site-wide-locations">
<h5>1.2.1.4.1 Installing into site-wide locations<a class="headerlink" href="#installing-into-site-wide-locations" title="Ссылка на этот заголовок">¶</a></h5>
<p>Instead of adding the directory to your PATH, you can install bzr into the
system locations using:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">python</span> <span class="n">setup</span><span class="o">.</span><span class="n">py</span> <span class="n">install</span>
</pre></div>
</div>
<p>If you do not have a compiler, or do not have the python development tools
installed, bzr supplies a (slower) pure-python implementation of all
extensions. You can install without compiling extensions with:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">python</span> <span class="n">setup</span><span class="o">.</span><span class="n">py</span> <span class="n">install</span> <span class="n">build_ext</span> <span class="o">--</span><span class="n">allow</span><span class="o">-</span><span class="n">python</span><span class="o">-</span><span class="n">fallback</span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="running-the-development-version">
<h4>1.2.1.5 Running the development version<a class="headerlink" href="#running-the-development-version" title="Ссылка на этот заголовок">¶</a></h4>
<p>You may wish to always be using the very latest development version of
Bazaar. Note that this is not recommended for
the majority of users as there is an increased risk of bugs. On the other
hand, the development version is remarkably solid (thanks to the processes
we follow) and running it makes it easier for you to send us changes for
bugs and improvements. It also helps us by having more people testing
the latest software.</p>
<p>Here are the steps to follow:</p>
<blockquote>
<div><ol class="arabic">
<li><p class="first">Install Bazaar using one of the methods given above.</p>
</li>
<li><p class="first">Get a copy of the development version like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">lp</span><span class="p">:</span><span class="n">bzr</span>
</pre></div>
</div>
</li>
<li><p class="first">Put the created directory on your PATH.</p>
</li>
</ol>
</div></blockquote>
<p>Advanced users may also wish to build the optional C extensions for greater
speed. This can be done using <code class="docutils literal notranslate"><span class="pre">make</span></code> and requires <code class="docutils literal notranslate"><span class="pre">pyrex</span></code> and a C compiler.
Please contact us on email or IRC if you need assistance with this.</p>
</div>
<div class="section" id="running-multiple-versions">
<h4>1.2.1.6 Running multiple versions<a class="headerlink" href="#running-multiple-versions" title="Ссылка на этот заголовок">¶</a></h4>
<p>It’s easy to have multiple versions of Bazaar installed and to switch
between them. To do this,
simply provide the full pathname to the <strong>bzr</strong> command you wish to run.
The relevant libraries will be automatically detected and used. Of course,
if you do not provide a pathname, then the <strong>bzr</strong> used will be the one
found on your system path as normal.</p>
<p>Note that this capability is particularly useful if you wish to run
(or test) both the latest released version and the development version say.</p>
</div>
</div>
<div class="section" id="entering-commands">
<h3>1.2.2 Entering commands<a class="headerlink" href="#entering-commands" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="user-interfaces">
<h4>1.2.2.1 User interfaces<a class="headerlink" href="#user-interfaces" title="Ссылка на этот заголовок">¶</a></h4>
<p>There are numerous user interfaces available for Bazaar.
The core package provides a command line tool called <strong>bzr</strong> and
graphical user interfaces (GUIs) are available as plug-ins.</p>
</div>
<div class="section" id="using-bzr">
<h4>1.2.2.2 Using bzr<a class="headerlink" href="#using-bzr" title="Ссылка на этот заголовок">¶</a></h4>
<p>The syntax is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="p">[</span><span class="k">global</span><span class="o">-</span><span class="n">options</span><span class="p">]</span> <span class="n">command</span> <span class="p">[</span><span class="n">options</span> <span class="ow">and</span> <span class="n">arguments</span><span class="p">]</span>
</pre></div>
</div>
<p>Global options affect how Bazaar operates and can appear either
before or after <code class="docutils literal notranslate"><span class="pre">command</span></code>. Command specific options must appear
after the command but may be given either before, during or after any
command-specific arguments.</p>
</div>
<div class="section" id="common-options">
<h4>1.2.2.3 Common options<a class="headerlink" href="#common-options" title="Ссылка на этот заголовок">¶</a></h4>
<p>Some options are legal for all commands as shown below.</p>
<blockquote>
<div><table border="1" class="docutils">
<colgroup>
<col width="28%" />
<col width="25%" />
<col width="47%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Short form</th>
<th class="head">Long form</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>-h</td>
<td>–help</td>
<td>get help</td>
</tr>
<tr class="row-odd"><td>-v</td>
<td>–verbose</td>
<td>be more verbose</td>
</tr>
<tr class="row-even"><td>-q</td>
<td>–quiet</td>
<td>be more quiet</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>Quiet mode implies that only errors and warnings are displayed.
This can be useful in scripts.</p>
<p>Note: Most commands typically only support one level of verbosity though
that may change in the future. To ask for a higher level of verbosity,
simply specify the -v option multiple times.</p>
</div>
</div>
<div class="section" id="getting-help">
<h3>1.2.3 Getting help<a class="headerlink" href="#getting-help" title="Ссылка на этот заголовок">¶</a></h3>
<p>Bazaar comes with a built-in on-line help system, accessed through:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">help</span>
</pre></div>
</div>
<p>You can ask for help on a command, or on non-command topics. To see a
list of available help of each kind, use either:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">help</span> <span class="n">commands</span>
<span class="n">bzr</span> <span class="n">help</span> <span class="n">topics</span>
</pre></div>
</div>
<p>For help on a particular command, use either of these forms:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">help</span> <span class="n">status</span>
<span class="n">bzr</span> <span class="n">status</span> <span class="o">--</span><span class="n">help</span>
</pre></div>
</div>
<p>If you wish to search the help or read it as a larger document, the
information is also available in the Bazaar User Reference.</p>
</div>
<div class="section" id="configuring-bazaar">
<h3>1.2.4 Configuring Bazaar<a class="headerlink" href="#configuring-bazaar" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="telling-bazaar-about-yourself">
<h4>1.2.4.1 Telling Bazaar about yourself<a class="headerlink" href="#telling-bazaar-about-yourself" title="Ссылка на этот заголовок">¶</a></h4>
<p>One function of a version control system is to keep track of who changed
what. In a decentralized system, that requires an identifier for each
author that is globally unique. Most people already have one of these: an
email address. Bazaar is smart enough to automatically generate an email
address by looking up your username and hostname. If you don’t like the
guess that Bazaar makes, then use the <code class="docutils literal notranslate"><span class="pre">whoami</span></code> command to set the
identifier you want:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">whoami</span> <span class="s2">"Your Name <email@example.com>"</span>
</pre></div>
</div>
<p>If <code class="docutils literal notranslate"><span class="pre">whoami</span></code> is used without an argument, the current value is displayed.</p>
</div>
<div class="section" id="using-a-network-proxy">
<h4>1.2.4.2 Using a network proxy<a class="headerlink" href="#using-a-network-proxy" title="Ссылка на этот заголовок">¶</a></h4>
<p>If your network requires that you use an HTTP proxy for outbound
connections, you must set the <code class="docutils literal notranslate"><span class="pre">http_proxy</span></code> variable. If the proxy is
also required for https connections, you need to set <code class="docutils literal notranslate"><span class="pre">https_proxy</span></code> too.
If you need these and don’t have them set, you may find that connections
to Launchpad or other external servers fail or time out.</p>
<p>On Unix you typically want to set these in <code class="docutils literal notranslate"><span class="pre">/etc/environment</span></code> or
<code class="docutils literal notranslate"><span class="pre">~/.bash_profile</span></code> and on Windows in the user profile.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">http_proxy</span><span class="o">=</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">proxy</span><span class="o">.</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="p">:</span><span class="mi">3128</span><span class="o">/</span>
<span class="n">https_proxy</span><span class="o">=</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">proxy</span><span class="o">.</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="p">:</span><span class="mi">3128</span><span class="o">/</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">no_proxy</span></code> variable can be set to a comma-separated list of hosts
which shouldn’t be reached by the proxy. (See
<<a class="reference external" href="http://docs.python.org/library/urllib.html">http://docs.python.org/library/urllib.html</a>> for more details.)</p>
</div>
<div class="section" id="various-ways-to-configure">
<h4>1.2.4.3 Various ways to configure<a class="headerlink" href="#various-ways-to-configure" title="Ссылка на этот заголовок">¶</a></h4>
<p>As shown in the example above, there are various ways to
configure Bazaar, they all share some common properties though.
An option has:</p>
<ul class="simple">
<li>a name which is generally a valid python identifier,</li>
<li>a value which is a string. In some cases, Bazaar will be able
to recognize special values like „True“, „False“ to infer a
boolean type, but basically, as a user, you will always specify
a value as a string.</li>
</ul>
<p>Options are grouped in various contexts so the option name
uniquely identifies it in this context. When needed, options can
be made persistent by recording them in a configuration file.</p>
</div>
<div class="section" id="configuration-files">
<h4>1.2.4.4 Configuration files<a class="headerlink" href="#configuration-files" title="Ссылка на этот заголовок">¶</a></h4>
<p>Configuration files are located in <code class="docutils literal notranslate"><span class="pre">$HOME/.bazaar</span></code> on Unix and
<code class="docutils literal notranslate"><span class="pre">C:\Documents</span> <span class="pre">and</span> <span class="pre">Settings\<username>\Application</span> <span class="pre">Data\Bazaar\2.0</span></code> on
Windows. There are three primary configuration files in this location:</p>
<ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> describes default configuration options,</li>
<li><code class="docutils literal notranslate"><span class="pre">locations.conf</span></code> describes configuration information for
specific branch locations,</li>
<li><code class="docutils literal notranslate"><span class="pre">authentication.conf</span></code> describes credential information for
remote servers.</li>
</ul>
<p>Each branch can also contain a configuration file that sets values specific
to that branch. This file is found at <code class="docutils literal notranslate"><span class="pre">.bzr/branch/branch.conf</span></code> within the
branch. This file is visible to <strong>all users of a branch</strong>. If you wish to
override one of the values for a branch with a setting that is specific to you,
then you can do so in <code class="docutils literal notranslate"><span class="pre">locations.conf</span></code>.</p>
<p>Here is sample content of <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> after setting an email address using
the <code class="docutils literal notranslate"><span class="pre">whoami</span></code> command:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[</span><span class="n">DEFAULT</span><span class="p">]</span>
<span class="n">email</span> <span class="o">=</span> <span class="n">Your</span> <span class="n">Name</span> <span class="o"><</span><span class="n">email</span><span class="nd">@example</span><span class="o">.</span><span class="n">com</span><span class="o">></span>
</pre></div>
</div>
<p>For further details on the syntax and configuration settings supported, see
<a class="reference external" href="../user-reference/index.html#configuration-settings">Configuration Settings</a>
in the Bazaar User Reference.</p>
</div>
<div class="section" id="looking-at-the-active-configuration">
<h4>1.2.4.5 Looking at the active configuration<a class="headerlink" href="#looking-at-the-active-configuration" title="Ссылка на этот заголовок">¶</a></h4>
<p>To look at all the currently defined options, you can use the following
command:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">config</span>
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">bzr</span></code> implements some rules to decide where to get the value of a
configuration option.</p>
<p>The current policy is to examine the existing configurations files in a
given order for matching definitions.</p>
<blockquote>
<div><ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">locations.conf</span></code> is searched first for a section whose name matches the
location considered (working tree, branch or remote branch),</li>
<li>the current <code class="docutils literal notranslate"><span class="pre">branch.conf</span></code> is searched next,</li>
<li><code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> is searched next,</li>
<li>finally, some options can have default values generally defined in the
code itself and not displayed by <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">config</span></code> (see <a class="reference external" href="../user-reference/index.html#configuration-settings">Configuration
Settings</a>).</li>
</ul>
</div></blockquote>
<p>This is better understood by using <code class="docutils literal notranslate"><span class="pre">`bzr</span> <span class="pre">config</span></code> with no arguments, which
will display some output of the form:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">locations</span><span class="p">:</span>
<span class="n">post_commit_to</span> <span class="o">=</span> <span class="n">commits</span><span class="nd">@example</span><span class="o">.</span><span class="n">com</span>
<span class="n">news_merge_files</span> <span class="o">=</span> <span class="n">NEWS</span>
<span class="n">branch</span><span class="p">:</span>
<span class="n">parent_location</span> <span class="o">=</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">bazaar</span><span class="o">.</span><span class="n">launchpad</span><span class="o">.</span><span class="n">net</span><span class="o">/+</span><span class="n">branch</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span>
<span class="n">nickname</span> <span class="o">=</span> <span class="n">config</span><span class="o">-</span><span class="n">modify</span>
<span class="n">push_location</span> <span class="o">=</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">bazaar</span><span class="o">.</span><span class="n">launchpad</span><span class="o">.</span><span class="n">net</span><span class="o">/~</span><span class="n">vila</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">config</span><span class="o">-</span><span class="n">modify</span><span class="o">/</span>
<span class="n">bazaar</span><span class="p">:</span>
<span class="n">debug_flags</span> <span class="o">=</span> <span class="n">hpss</span><span class="p">,</span>
</pre></div>
</div>
<p>Each configuration file is associated with a given scope whose name is
displayed before each set of defined options.</p>
<p>If you need to look at a specific option, you can use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">config</span> <span class="o"><</span><span class="n">option</span><span class="o">></span>
</pre></div>
</div>
<p>This will display only the option value and is intended to be used in
scripts.</p>
</div>
<div class="section" id="modifying-the-active-configuration">
<h4>1.2.4.6 Modifying the active configuration<a class="headerlink" href="#modifying-the-active-configuration" title="Ссылка на этот заголовок">¶</a></h4>
<p>To set an option to a given value use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">config</span> <span class="n">opt</span><span class="o">=</span><span class="n">value</span>
</pre></div>
</div>
<p>An option value can reference another option by enclosing it in curly
braces:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">config</span> <span class="n">opt</span><span class="o">=</span><span class="p">{</span><span class="n">other_opt</span><span class="p">}</span><span class="o">/</span><span class="n">subdir</span>
</pre></div>
</div>
<p>If <code class="docutils literal notranslate"><span class="pre">other_opt</span></code> is set to <code class="docutils literal notranslate"><span class="pre">'root</span></code>, <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">config</span> <span class="pre">opt</span></code> will display:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">root</span><span class="o">/</span><span class="n">subdir</span>
</pre></div>
</div>
<p>Note that when <code class="docutils literal notranslate"><span class="pre">--all</span></code> is used, the references are left as-is to better
reflect the content of the config files and make it easier to organize them:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">config</span> <span class="o">--</span><span class="nb">all</span> <span class="o">.*</span><span class="n">opt</span>
<span class="n">bazaar</span><span class="p">:</span>
<span class="p">[</span><span class="n">DEFAULT</span><span class="p">]</span>
<span class="n">opt</span> <span class="o">=</span> <span class="p">{</span><span class="n">other_opt</span><span class="p">}</span><span class="o">/</span><span class="n">subdir</span>
<span class="n">other_opt</span> <span class="o">=</span> <span class="n">root</span>
</pre></div>
</div>
<p>To remove an option use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">config</span> <span class="o">--</span><span class="n">remove</span> <span class="n">opt</span>
</pre></div>
</div>
</div>
<div class="section" id="rule-based-preferences">
<h4>1.2.4.7 Rule-based preferences<a class="headerlink" href="#rule-based-preferences" title="Ссылка на этот заголовок">¶</a></h4>
<p>Some commands and plugins provide custom processing on files matching
certain patterns. Per-user rule-based preferences are defined in
<code class="docutils literal notranslate"><span class="pre">BZR_HOME/rules</span></code>.</p>
<p>For further information on how rules are searched and the detailed syntax of
the relevant files, see <a class="reference external" href="../user-reference/index.html#rules">Rules</a>
in the Bazaar User Reference.</p>
</div>
<div class="section" id="escaping-command-lines">
<h4>1.2.4.8 Escaping command lines<a class="headerlink" href="#escaping-command-lines" title="Ссылка на этот заголовок">¶</a></h4>
<p>When you give a program name or command line in configuration, you can quote
to include special characters or whitespace. The same rules are used across
all platforms.</p>
<p>The rules are: strings surrounded by double-quotes are interpreted as single
«words» even if they contain whitespace, and backslash may be used to quote
quotation marks. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">BZR_EDITOR</span><span class="o">=</span><span class="s2">"C:\Program Files\My Editor\myeditor.exe"</span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="using-aliases">
<h3>1.2.5 Using aliases<a class="headerlink" href="#using-aliases" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="what-are-aliases">
<h4>1.2.5.1 What are aliases?<a class="headerlink" href="#what-are-aliases" title="Ссылка на этот заголовок">¶</a></h4>
<p>Aliases are an easy way to create shortcuts for commonly-typed commands, or to set
defaults for commands.</p>
</div>
<div class="section" id="defining-aliases">
<h4>1.2.5.2 Defining aliases<a class="headerlink" href="#defining-aliases" title="Ссылка на этот заголовок">¶</a></h4>
<p>Command aliases can be defined in the <code class="docutils literal notranslate"><span class="pre">[ALIASES]</span></code> section of your
<code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> file. Aliases start with the alias name, then an
equal sign, then a command fragment. Here’s an example ALIASES section:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[</span><span class="n">ALIASES</span><span class="p">]</span>
<span class="n">recentlog</span><span class="o">=</span><span class="n">log</span> <span class="o">-</span><span class="n">r</span><span class="o">-</span><span class="mf">3.</span><span class="o">.-</span><span class="mi">1</span>
<span class="n">ll</span><span class="o">=</span><span class="n">log</span> <span class="o">--</span><span class="n">line</span> <span class="o">-</span><span class="n">r</span><span class="o">-</span><span class="mf">10.</span><span class="o">.-</span><span class="mi">1</span>
<span class="n">commit</span><span class="o">=</span><span class="n">commit</span> <span class="o">--</span><span class="n">strict</span>
<span class="n">diff</span><span class="o">=</span><span class="n">diff</span> <span class="o">--</span><span class="n">diff</span><span class="o">-</span><span class="n">options</span> <span class="o">-</span><span class="n">p</span>
</pre></div>
</div>
<p>Here are the explanations of the examples above:</p>
<blockquote>
<div><ul class="simple">
<li>The first alias makes a new <code class="docutils literal notranslate"><span class="pre">recentlog</span></code> command that shows the logs for the
last three revisions</li>
<li>The <code class="docutils literal notranslate"><span class="pre">ll</span></code> alias shows the last 10 log entries in line format.</li>
<li>the <code class="docutils literal notranslate"><span class="pre">commit</span></code> alias sets the default for commit to refuse to commit if new
files in the tree are not recognized.</li>
<li>the <code class="docutils literal notranslate"><span class="pre">diff</span></code> alias adds the coveted -p option to diff</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="using-the-aliases">
<h4>1.2.5.3 Using the aliases<a class="headerlink" href="#using-the-aliases" title="Ссылка на этот заголовок">¶</a></h4>
<p>The aliases defined above would be used like so:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">recentlog</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">ll</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">diff</span>
</pre></div>
</div>
</div>
<div class="section" id="rules-for-aliases">
<h4>1.2.5.4 Rules for aliases<a class="headerlink" href="#rules-for-aliases" title="Ссылка на этот заголовок">¶</a></h4>
<blockquote>
<div><ul class="simple">
<li>You can override a portion of the options given in an alias by
specifying the new part on the command-line. For example, if
you run <code class="docutils literal notranslate"><span class="pre">lastlog</span> <span class="pre">-r-5..</span></code>, you will only get five line-based log
entries instead of 10. Note that all boolean options have an
implicit inverse, so you can override the commit alias with
<code class="docutils literal notranslate"><span class="pre">commit</span> <span class="pre">--no-strict</span></code>.</li>
<li>Aliases can override the standard behaviour of existing commands by giving
an alias name that is the same as the original command. For example, default
commit is changed with <code class="docutils literal notranslate"><span class="pre">commit=commit</span> <span class="pre">--strict</span></code>.</li>
<li>Aliases cannot refer to other aliases. In other words making a
<code class="docutils literal notranslate"><span class="pre">lastlog</span></code> alias and referring to it with a <code class="docutils literal notranslate"><span class="pre">ll</span></code> alias will not work.
This includes aliases that override standard commands.</li>
<li>Giving the <code class="docutils literal notranslate"><span class="pre">--no-aliases</span></code> option to the bzr command will tell it to ignore aliases
for that run. For example, running <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">--no-aliases</span> <span class="pre">commit</span></code> will perform a
standard commit instead, not do a <code class="docutils literal notranslate"><span class="pre">commit</span> <span class="pre">--strict</span></code>.</li>
</ul>
</div></blockquote>
</div>
</div>
<div class="section" id="using-plugins">
<h3>1.2.6 Using plugins<a class="headerlink" href="#using-plugins" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="what-is-a-plugin">
<h4>1.2.6.1 What is a plugin?<a class="headerlink" href="#what-is-a-plugin" title="Ссылка на этот заголовок">¶</a></h4>
<p>A plugin is an external component for Bazaar that is typically made by
third parties. A plugin is capable of augmenting Bazaar by adding new
functionality. A plugin can also change current Bazaar behavior by
replacing current functionality. Sample applications of plugins are:</p>
<ul class="simple">
<li>overriding commands</li>
<li>adding new commands</li>
<li>providing additional network transports</li>
<li>customizing log output.</li>
</ul>
<p>The sky is the limit for the customization that can be done through plugins.
In fact, plugins often work as a way for developers to test new features for
Bazaar prior to inclusion in the official codebase. Plugins are helpful
at feature retirement time as well, e.g. deprecated file formats may one
day be removed from the Bazaar core and be made available as a plugin instead.</p>
<p>Plugins are good for users, good for external developers and good for
Bazaar itself.</p>
</div>
<div class="section" id="where-to-find-plugins">
<h4>1.2.6.2 Where to find plugins<a class="headerlink" href="#where-to-find-plugins" title="Ссылка на этот заголовок">¶</a></h4>
<p>We keep our list of plugins on the <a class="reference external" href="http://wiki.bazaar.canonical.com/BzrPlugins">http://wiki.bazaar.canonical.com/BzrPlugins</a> page.</p>
</div>
<div class="section" id="how-to-install-a-plugin">
<h4>1.2.6.3 How to install a plugin<a class="headerlink" href="#how-to-install-a-plugin" title="Ссылка на этот заголовок">¶</a></h4>
<p>Installing a plugin is very easy! If not already created, create a
<code class="docutils literal notranslate"><span class="pre">plugins</span></code> directory under your Bazaar configuration directory,
<code class="docutils literal notranslate"><span class="pre">~/.bazaar/</span></code> on Unix and
<code class="docutils literal notranslate"><span class="pre">C:\Documents</span> <span class="pre">and</span> <span class="pre">Settings\<username>\Application</span> <span class="pre">Data\Bazaar\2.0\</span></code>
on Windows. Within this directory (referred to as $BZR_HOME below),
each plugin is placed in its own subdirectory.</p>
<p>Plugins work particularly well with Bazaar branches. For example, to
install the bzrtools plugins for your main user account on GNU/Linux,
one can perform the following:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">panoramicfeedback</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">opensource</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">bzrtools</span>
<span class="o">~/.</span><span class="n">bazaar</span><span class="o">/</span><span class="n">plugins</span><span class="o">/</span><span class="n">bzrtools</span>
</pre></div>
</div>
<p>When installing plugins, the directories that you install them in must
be valid python identifiers. This means that they can only contain
certain characters, notably they cannot contain hyphens (<code class="docutils literal notranslate"><span class="pre">-</span></code>). Rather
than installing <code class="docutils literal notranslate"><span class="pre">bzr-gtk</span></code> to <code class="docutils literal notranslate"><span class="pre">$BZR_HOME/plugins/bzr-gtk</span></code>, install it
to <code class="docutils literal notranslate"><span class="pre">$BZR_HOME/plugins/gtk</span></code>.</p>
</div>
<div class="section" id="alternative-plugin-locations">
<h4>1.2.6.4 Alternative plugin locations<a class="headerlink" href="#alternative-plugin-locations" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have the necessary permissions, plugins can also be installed on a
system-wide basis. One can additionally override the personal plugins
location by setting the environment variable <code class="docutils literal notranslate"><span class="pre">BZR_PLUGIN_PATH</span></code> (see <a class="reference external" href="../user-reference/configuration-help.html#bzr-plugin-path">User
Reference</a>
for a detailed explanation).</p>
</div>
<div class="section" id="listing-the-installed-plugins">
<h4>1.2.6.5 Listing the installed plugins<a class="headerlink" href="#listing-the-installed-plugins" title="Ссылка на этот заголовок">¶</a></h4>
<p>To do this, use the plugins command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">plugins</span>
</pre></div>
</div>
<p>The name, location and version of each plugin installed will be displayed.</p>
<p>New commands added by plugins can be seen by running <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">help</span> <span class="pre">commands</span></code>.
The commands provided by a plugin are shown followed by the name of the
plugin in brackets.</p>
</div>
<div class="section" id="popular-plugins">
<h4>1.2.6.6 Popular plugins<a class="headerlink" href="#popular-plugins" title="Ссылка на этот заголовок">¶</a></h4>
<p>Here is a sample of some of the more popular plugins.</p>
<blockquote>
<div><table border="1" class="docutils">
<colgroup>
<col width="24%" />
<col width="25%" />
<col width="51%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Category</th>
<th class="head">Name</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>GUI</td>
<td>QBzr</td>
<td>Qt-based GUI tools</td>
</tr>
<tr class="row-odd"><td>GUI</td>
<td>bzr-gtk</td>
<td>GTK-based GUI tools</td>
</tr>
<tr class="row-even"><td>GUI</td>
<td>bzr-eclipse</td>
<td>Eclipse integration</td>
</tr>
<tr class="row-odd"><td>General</td>
<td>bzrtools</td>
<td>misc. enhancements including shelf</td>
</tr>
<tr class="row-even"><td>General</td>
<td>difftools</td>
<td>external diff tool helper</td>
</tr>
<tr class="row-odd"><td>General</td>
<td>extmerge</td>
<td>external merge tool helper</td>
</tr>
<tr class="row-even"><td>Integration</td>
<td>bzr-svn</td>
<td>use Subversion as a repository</td>
</tr>
<tr class="row-odd"><td>Migration</td>
<td>cvsps</td>
<td>migrate CVS patch-sets</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>If you wish to write your own plugins, it is not difficult to do.
See <a class="reference external" href="writingaplugin.html">Writing a plugin</a> in the appendices to get
started.</p>
</div>
</div>
<div class="section" id="id24">
<h3>1.2.7 Путь Bazaar<a class="headerlink" href="#id24" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id25">
<h4>1.2.7.1 Глубокое понимание Bazaar<a class="headerlink" href="#id25" title="Ссылка на этот заголовок">¶</a></h4>
<p>Хотя Bazaar во многом похож на другие инструменты контроля версий, есть
некоторые важные различия, которые не всегда очевидны на первый взгляд. Этот
раздел пытается объяснить некоторые вещи, который пользователь должен знать
чтобы разбираться в Bazaar, т.е. глубоко его понимать.</p>
<p>Заметьте: чтобы использовать Bazaar совсем необязательно полностью понимать
этот раздел. Вы можете просмотреть этот раздел сейчас и вернуться к нему позже.</p>
</div>
<div class="section" id="id26">
<h4>1.2.7.2 Понимание номеров ревизий<a class="headerlink" href="#id26" title="Ссылка на этот заголовок">¶</a></h4>
<p>All revisions in the mainline of a branch have a simple increasing
integer. (First commit gets 1, 10th commit gets 10, etc.) This makes them
fairly natural to use when you want to say «grab the 10th revision from my
branch», or «fixed in revision 3050».</p>
<p>For revisions which have been merged into a branch, a dotted notation is used
(e.g., 3112.1.5). Dotted revision numbers have three numbers <a class="footnote-reference" href="#id28" id="id27">[2]</a>. The first
number indicates what mainline revision change is derived from. The second
number is the branch counter. There can be many branches derived from the
same revision, so they all get a unique number. The third number is the
number of revisions since the branch started. For example, 3112.1.5 is the
first branch from revision 3112, the fifth revision on that branch.</p>
<table class="docutils footnote" frame="void" id="id28" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id27">[2]</a></td><td>Versions prior to bzr 1.2 used a slightly different algorithm.
Some nested branches would get extra numbers (such as 1.1.1.1.1)
rather than the simpler 3-number system.</td></tr>
</tbody>
</table>
</div>
<div class="section" id="hierarchical-history-is-good">
<h4>1.2.7.3 Hierarchical history is good<a class="headerlink" href="#hierarchical-history-is-good" title="Ссылка на этот заголовок">¶</a></h4>
<p>Imagine a project with multiple developers contributing changes where
many changes consist of a series of commits. To give a concrete example,
consider the case where:</p>
<blockquote>
<div><ul class="simple">
<li>The tip of the project’s trunk is revision 100.</li>
<li>Mary makes 3 changes to deliver feature X.</li>
<li>Bill makes 4 changes to deliver feature Y.</li>
</ul>
</div></blockquote>
<p>If the developers are working in parallel and using a traditional
centralized VCS approach, the project history will most likely be linear
with Mary’s changes and Bill’s changes interleaved. It might look like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">107</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">106</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">Y</span>
<span class="mi">105</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">X</span>
<span class="mi">104</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">103</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">102</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="ow">and</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Add</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>Many teams use this approach because their tools make branching and merging
difficult. As a consequence, developers update from and commit to the trunk
frequently, minimizing integration pain by spreading it over every commit.
If you wish, you can use Bazaar exactly like this. Bazaar does offer other
ways though that you ought to consider.</p>
<p>An alternative approach encouraged by distributed VCS tools is to create
feature branches and to integrate those when they are ready. In this case,
Mary’s feature branch would look like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">103</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">X</span>
<span class="mi">102</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="ow">and</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>And Bill’s would look like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">104</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">103</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">Y</span>
<span class="mi">102</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Add</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>If the features were independent and you wanted to keep linear history,
the changes could be pushed back into the trunk in batches. (Technically,
there are several ways of doing that but that’s beyond the scope of
this discussion.) The resulting history might look like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">107</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">X</span>
<span class="mi">106</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">105</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="ow">and</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">104</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">103</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">Y</span>
<span class="mi">102</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Add</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>While this takes a bit more effort to achieve, it has some advantages over
having revisions randomly intermixed. Better still though, branches can
be merged together forming a non-linear history. The result might look
like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">102</span><span class="p">:</span> <span class="n">Merge</span> <span class="n">feature</span> <span class="n">X</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">3</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">X</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">2</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">X</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">1</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="ow">and</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Merge</span> <span class="n">feature</span> <span class="n">Y</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">4</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">3</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">Y</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">2</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">1</span><span class="p">:</span> <span class="n">Add</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">Y</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>Or more likely this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">102</span><span class="p">:</span> <span class="n">Merge</span> <span class="n">feature</span> <span class="n">X</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">3</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">2</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">1</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="ow">and</span> <span class="n">tests</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Merge</span> <span class="n">feature</span> <span class="n">Y</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">4</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">3</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">2</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">1</span><span class="p">:</span> <span class="n">Add</span> <span class="n">tests</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>This is considered good for many reasons:</p>
<blockquote>
<div><ul class="simple">
<li>It makes it easier to understand the history of a project.
Related changes are clustered together and clearly partitioned.</li>
<li>You can easily collapse history to see just the commits on the mainline
of a branch. When viewing the trunk history like this, you only see
high level commits (instead of a large number of commits uninteresting
at this level).</li>
<li>If required, it makes backing out a feature much easier.</li>
<li>Continuous integration tools can be used to ensure that
all tests still pass before committing a merge to the mainline.
(In many cases, it isn’t appropriate to trigger CI tools after
every single commit as some tests will fail during development.
In fact, adding the tests first - TDD style - will guarantee it!)</li>
</ul>
</div></blockquote>
<p>In summary, the important points are:</p>
<blockquote>
<div><p><em>Organize your work using branches.</em></p>
<p><em>Integrate changes using merge.</em></p>
<p><em>Ordered revision numbers and hierarchy make history easier to follow.</em></p>
</div></blockquote>
</div>
<div class="section" id="each-branch-has-its-own-view-of-history">
<h4>1.2.7.4 Each branch has its own view of history<a class="headerlink" href="#each-branch-has-its-own-view-of-history" title="Ссылка на этот заголовок">¶</a></h4>
<p>As explained above, Bazaar makes the distinction between:</p>
<blockquote>
<div><ul class="simple">
<li>mainline revisions, i.e. ones you committed in your branch, and</li>
<li>merged revisions, i.e. ones added as ancestors by committing a merge.</li>
</ul>
</div></blockquote>
<p>Each branch effectively has its own view of history, i.e. different
branches can give the same revision a different «local» revision number.
Mainline revisions always get allocated single number revision numbers
while merged revisions always get allocated dotted revision numbers.</p>
<p>To extend the example above, here’s what the revision history of
Mary’s branch would look like had she decided to merge the project
trunk into her branch after completing her changes:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">104</span><span class="p">:</span> <span class="n">Merge</span> <span class="n">mainline</span>
<span class="mf">100.2</span><span class="o">.</span><span class="mi">1</span><span class="p">:</span> <span class="n">Merge</span> <span class="n">feature</span> <span class="n">Y</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">4</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">3</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">2</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span>
<span class="mf">100.1</span><span class="o">.</span><span class="mi">1</span><span class="p">:</span> <span class="n">Add</span> <span class="n">tests</span>
<span class="mi">103</span><span class="p">:</span> <span class="n">Fix</span> <span class="n">bug</span> <span class="n">found</span> <span class="ow">in</span> <span class="n">testing</span> <span class="n">X</span>
<span class="mi">102</span><span class="p">:</span> <span class="n">Add</span> <span class="n">documentation</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">101</span><span class="p">:</span> <span class="n">Add</span> <span class="n">code</span> <span class="ow">and</span> <span class="n">tests</span> <span class="k">for</span> <span class="n">X</span>
<span class="mi">100</span><span class="p">:</span> <span class="o">...</span>
</pre></div>
</div>
<p>Once again, it’s easy for Mary to look at just <em>her</em> top level of history
to see the steps she has taken to develop this change. In this context,
merging the trunk (and resolving any conflicts caused by doing that) is
just one step as far as the history of this branch is concerned.</p>
<p>It’s important to remember that Bazaar is not changing history here, nor
is it changing the global revision identifiers. You can always use the
latter if you really want to. In fact, you can use the branch specific
revision numbers when communicating <em>as long as</em> you provide the branch
URL as context. (In many Bazaar projects, developers imply the central
trunk branch if they exchange a revision number without a branch URL.)</p>
<p>Merges do not change revision numbers in a branch, though they do
allocate local revision numbers to newly merged revisions. The only time
Bazaar will change revision numbers in a branch is when you explicitly
ask it to mirror another branch.</p>
<p>Note: Revisions are numbered in a stable way: if two branches have
the same revision in their mainline, all revisions in the ancestry of that
revision will have the same revision numbers. For example, if Alice and Bob’s
branches agree on revision 10, they will agree on all revisions before
that.</p>
</div>
<div class="section" id="id29">
<h4>1.2.7.5 Резюме<a class="headerlink" href="#id29" title="Ссылка на этот заголовок">¶</a></h4>
<p>Обычно, если вы следовали ранее полученным советам - организовать вашу работу
в ветках и использовать объединение для сотрудничества - вы обнаружите что
чаще всего Bazaar делает то что вы ожидаете.</p>
<p>В следующих главах, мы проверим различный способы использования Bazaar, начиная
с самого простого: использование Bazaar для личных проектов.</p>
</div>
</div>
</div>
<div class="section" id="id30">
<h2><a class="toc-backref" href="#id78">1.3 Личный контроль версий</a><a class="headerlink" href="#id30" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="going-solo">
<h3>1.3.1 Going solo<a class="headerlink" href="#going-solo" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="a-personal-productivity-tool">
<h4>1.3.1.1 A personal productivity tool<a class="headerlink" href="#a-personal-productivity-tool" title="Ссылка на этот заголовок">¶</a></h4>
<p>Some tools are designed to make individuals productive (e.g. editors)
while other tools (e.g. back-end services) are focused on making teams
or whole companies more productive. Version control tools have
traditionally been in the latter camp.</p>
<p>One of the cool things about Bazaar is that it is so easy to setup
that version control can now be treated as a personal productivity tool.
If you wish to record changes to files for the purposes of checkpointing
good known states or tracking history, it is now easy to do so. This
chapter explains how.</p>
</div>
<div class="section" id="the-solo-workflow">
<h4>1.3.1.2 The solo workflow<a class="headerlink" href="#the-solo-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you are creating your own masterpiece, whether that be a software
project or a set of related documents, the typical workflow looks like this:</p>
<img alt="../_images/workflows_single.png" src="../_images/workflows_single.png" />
<p>Even if you will always be working as part of a team, the tasks covered
in this chapter will be the basis of what you’ll be doing so it’s a good
place to start.</p>
</div>
</div>
<div class="section" id="starting-a-project">
<h3>1.3.2 Starting a project<a class="headerlink" href="#starting-a-project" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="putting-an-existing-project-under-version-control">
<h4>1.3.2.1 Putting an existing project under version control<a class="headerlink" href="#putting-an-existing-project-under-version-control" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you already have a tree of source code (or directory of documents) you
wish to put under version control, here are the commands to use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">my</span><span class="o">-</span><span class="n">stuff</span>
<span class="n">bzr</span> <span class="n">init</span>
<span class="n">bzr</span> <span class="n">add</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Initial import"</span>
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">init</span></code> creates a <code class="docutils literal notranslate"><span class="pre">.bzr</span></code> directory in the top level directory
(<code class="docutils literal notranslate"><span class="pre">my-stuff</span></code> in the example above). Note that:</p>
<blockquote>
<div><ul class="simple">
<li>Bazaar has everything it needs in that directory - you do
<strong>not</strong> need to setup a database, web server or special service
to use it</li>
<li>Bazaar is polite enough to only create one <code class="docutils literal notranslate"><span class="pre">.bzr</span></code> in the
directory given, not one in every subdirectory thereof.</li>
</ul>
</div></blockquote>
<p><code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">add</span></code> then finds all the files and directories it thinks
ought to be version controlled and registers them internally.
<code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">commit</span></code> then records a snapshot of the content of these
and records that information, together with a commit message.</p>
<p>More information on <code class="docutils literal notranslate"><span class="pre">init</span></code>, <code class="docutils literal notranslate"><span class="pre">add</span></code> and <code class="docutils literal notranslate"><span class="pre">commit</span></code> will be provided
later. For now, the important thing to remember is the recipe above.</p>
</div>
<div class="section" id="starting-a-new-project">
<h4>1.3.2.2 Starting a new project<a class="headerlink" href="#starting-a-new-project" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you are starting a project from scratch, you can also use the recipe
above, after creating an empty directory first of course. For efficiency
reasons that will be explored more in later chapters though, it is a good
idea to create a repository for the project at the top level and to nest
a <em>main</em> branch within it like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">my</span><span class="o">.</span><span class="n">repo</span>
<span class="n">cd</span> <span class="n">my</span><span class="o">.</span><span class="n">repo</span>
<span class="n">bzr</span> <span class="n">init</span> <span class="n">my</span><span class="o">.</span><span class="n">main</span>
<span class="n">cd</span> <span class="n">my</span><span class="o">.</span><span class="n">main</span>
<span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span>
<span class="n">bzr</span> <span class="n">add</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Initial import"</span>
</pre></div>
</div>
<p>Some users prefer a name like <em>trunk</em> or <em>dev</em> to <em>main</em>. Choose
whichever name makes the most sense to you.</p>
<p>Note that the <code class="docutils literal notranslate"><span class="pre">init-repo</span></code> and <code class="docutils literal notranslate"><span class="pre">init</span></code> commands both take a path as an
argument and will create that path if it doesn’t already exist.</p>
</div>
</div>
<div class="section" id="controlling-file-registration">
<h3>1.3.3 Controlling file registration<a class="headerlink" href="#controlling-file-registration" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="what-does-bazaar-track">
<h4>1.3.3.1 What does Bazaar track?<a class="headerlink" href="#what-does-bazaar-track" title="Ссылка на этот заголовок">¶</a></h4>
<p>As explained earlier, <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">add</span></code> finds and registers all the things in
and under the current directory that Bazaar thinks ought to be
version controlled. These things may be:</p>
<blockquote>
<div><ul class="simple">
<li>files</li>
<li>directories</li>
<li>symbolic links.</li>
</ul>
</div></blockquote>
<p>Bazaar has default rules for deciding which files are
interesting and which ones are not. You can tune those rules as
explained in <a class="reference internal" href="#ignoring-files">Ignoring files</a> below.</p>
<p>Unlike many other VCS tools, Bazaar tracks directories as first class
items. As a consequence, empty directories are correctly supported -
you don’t need to create a dummy file inside a directory just to
ensure it gets tracked and included in project exports.</p>
<p>For symbolic links, the value of the symbolic link is tracked,
not the content of the thing the symbolic link is pointing to.</p>
<p>Note: Support for tracking projects-within-projects («nested trees»)
is currently under development. Please contact the Bazaar developers
if you are interested in helping develop or test this functionality.</p>
</div>
<div class="section" id="selective-registration">
<h4>1.3.3.2 Selective registration<a class="headerlink" href="#selective-registration" title="Ссылка на этот заголовок">¶</a></h4>
<p>In some cases, you may want or need to explicitly nominate the things
to register rather than leave it up to Bazaar to find things. To do this,
simply provide paths as arguments to the <code class="docutils literal notranslate"><span class="pre">add</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">add</span> <span class="n">fileX</span> <span class="n">dirY</span><span class="o">/</span>
</pre></div>
</div>
<p>Adding a directory implicitly adds all interesting things
underneath it.</p>
</div>
<div class="section" id="ignoring-files">
<h4>1.3.3.3 Ignoring files<a class="headerlink" href="#ignoring-files" title="Ссылка на этот заголовок">¶</a></h4>
<p>Many source trees contain some files that do not need to be versioned,
such as editor backups, object or bytecode files, and built programs. You
can simply not add them, but then they’ll always crop up as unknown files.
You can also tell Bazaar to ignore these files by adding them to a file
called <code class="docutils literal notranslate"><span class="pre">.bzrignore</span></code> at the top of the tree.</p>
<p>This file contains a list of file wildcards (or «globs»), one per line.
Typical contents are like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">*.</span><span class="n">o</span>
<span class="o">*~</span>
<span class="o">*.</span><span class="n">tmp</span>
<span class="o">*.</span><span class="n">py</span><span class="p">[</span><span class="n">co</span><span class="p">]</span>
</pre></div>
</div>
<p>If a glob contains a slash, it is matched against the whole path from the
top of the tree; otherwise it is matched against only the filename. So
the previous example ignores files with extension <code class="docutils literal notranslate"><span class="pre">.o</span></code> in all
subdirectories, but this example ignores only <code class="docutils literal notranslate"><span class="pre">config.h</span></code> at the top level
and HTML files in <code class="docutils literal notranslate"><span class="pre">doc/</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">./</span><span class="n">config</span><span class="o">.</span><span class="n">h</span>
<span class="n">doc</span><span class="o">/*.</span><span class="n">html</span>
</pre></div>
</div>
<p>To get a list of which files are ignored and what pattern they matched,
use <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">ignored</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">ignored</span>
<span class="n">config</span><span class="o">.</span><span class="n">h</span> <span class="o">./</span><span class="n">config</span><span class="o">.</span><span class="n">h</span>
<span class="n">configure</span><span class="o">.</span><span class="ow">in</span><span class="o">~</span> <span class="o">*~</span>
</pre></div>
</div>
<p>Note that ignore patterns are only matched against non-versioned files,
and control whether they are treated as «unknown» or «ignored». If a file
is explicitly added, it remains versioned regardless of whether it matches
an ignore pattern.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">.bzrignore</span></code> file should normally be versioned, so that new copies
of the branch see the same patterns:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">add</span> <span class="o">.</span><span class="n">bzrignore</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Add ignore patterns"</span>
</pre></div>
</div>
<p>The command <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">ignore</span> <span class="pre">PATTERN</span></code> can be used to easily add PATTERN to
the <code class="docutils literal notranslate"><span class="pre">.bzrignore</span> <span class="pre">file</span></code> (creating it if necessary and registering it to
be tracked by Bazaar). Removing and modifying patterns are done by
directly editing the <code class="docutils literal notranslate"><span class="pre">.bzrignore</span></code> file.</p>
</div>
<div class="section" id="global-ignores">
<h4>1.3.3.4 Global ignores<a class="headerlink" href="#global-ignores" title="Ссылка на этот заголовок">¶</a></h4>
<p>There are some ignored files which are not project specific, but more user
specific. Things like editor temporary files, or personal temporary files.
Rather than add these ignores to every project, bzr supports a global
ignore file in <code class="docutils literal notranslate"><span class="pre">~/.bazaar/ignore</span></code> <a class="footnote-reference" href="#id32" id="id31">[3]</a>. It has the same syntax as the
per-project ignore file.</p>
<table class="docutils footnote" frame="void" id="id32" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id31">[3]</a></td><td>On Windows, the users configuration files can be found in the
application data directory. So instead of <code class="docutils literal notranslate"><span class="pre">~/.bazaar/branch.conf</span></code>
the configuration file can be found as:
<code class="docutils literal notranslate"><span class="pre">C:\Documents</span> <span class="pre">and</span> <span class="pre">Settings\<username>\Application</span> <span class="pre">Data\Bazaar\2.0\branch.conf</span></code>.
The same is true for <code class="docutils literal notranslate"><span class="pre">locations.conf</span></code>, <code class="docutils literal notranslate"><span class="pre">ignore</span></code>, and the
<code class="docutils literal notranslate"><span class="pre">plugins</span></code> directory.</td></tr>
</tbody>
</table>
</div>
</div>
<div class="section" id="reviewing-changes">
<h3>1.3.4 Reviewing changes<a class="headerlink" href="#reviewing-changes" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="looking-before-you-leap">
<h4>1.3.4.1 Looking before you leap<a class="headerlink" href="#looking-before-you-leap" title="Ссылка на этот заголовок">¶</a></h4>
<p>Once you have completed some work, it’s a good idea to review your changes
prior to permanently recording it. This way, you can make sure you’ll be
committing what you intend to.</p>
<p>Two bzr commands are particularly useful here: <strong>status</strong> and <strong>diff</strong>.</p>
</div>
<div class="section" id="bzr-status">
<h4>1.3.4.2 bzr status<a class="headerlink" href="#bzr-status" title="Ссылка на этот заголовок">¶</a></h4>
<p>The <strong>status</strong> command tells you what changes have been made to the
working directory since the last revision:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">status</span>
<span class="n">modified</span><span class="p">:</span>
<span class="n">foo</span>
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">status</span></code> hides «boring» files that are either unchanged or ignored.
The status command can optionally be given the name of some files or
directories to check.</p>
</div>
<div class="section" id="bzr-diff">
<h4>1.3.4.3 bzr diff<a class="headerlink" href="#bzr-diff" title="Ссылка на этот заголовок">¶</a></h4>
<p>The <strong>diff</strong> command shows the full text of changes to all files as a
standard unified diff. This can be piped through many programs such as
„“patch“„, „“diffstat“„, „“filterdiff““ and „“colordiff“„:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">diff</span>
<span class="o">===</span> <span class="n">added</span> <span class="n">file</span> <span class="s1">'hello.txt'</span>
<span class="o">---</span> <span class="n">hello</span><span class="o">.</span><span class="n">txt</span> <span class="mi">1970</span><span class="o">-</span><span class="mi">01</span><span class="o">-</span><span class="mi">01</span> <span class="mi">00</span><span class="p">:</span><span class="mi">00</span><span class="p">:</span><span class="mi">00</span> <span class="o">+</span><span class="mi">0000</span>
<span class="o">+++</span> <span class="n">hello</span><span class="o">.</span><span class="n">txt</span> <span class="mi">2005</span><span class="o">-</span><span class="mi">10</span><span class="o">-</span><span class="mi">18</span> <span class="mi">14</span><span class="p">:</span><span class="mi">23</span><span class="p">:</span><span class="mi">29</span> <span class="o">+</span><span class="mi">0000</span>
<span class="o">@@</span> <span class="o">-</span><span class="mi">0</span><span class="p">,</span><span class="mi">0</span> <span class="o">+</span><span class="mi">1</span><span class="p">,</span><span class="mi">1</span> <span class="o">@@</span>
<span class="o">+</span><span class="n">hello</span> <span class="n">world</span>
</pre></div>
</div>
<p>With the <code class="docutils literal notranslate"><span class="pre">-r</span></code> option, the tree is compared to an earlier revision, or
the differences between two versions are shown:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">diff</span> <span class="o">-</span><span class="n">r</span> <span class="mf">1000.</span><span class="o">.</span> <span class="c1"># everything since r1000</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">diff</span> <span class="o">-</span><span class="n">r</span> <span class="mf">1000.</span><span class="o">.</span><span class="mi">1100</span> <span class="c1"># changes from 1000 to 1100</span>
</pre></div>
</div>
<p>To see the changes introduced by a single revision, you can use the <code class="docutils literal notranslate"><span class="pre">-c</span></code>
option to diff.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">diff</span> <span class="o">-</span><span class="n">c</span> <span class="mi">1000</span> <span class="c1"># changes from r1000</span>
<span class="c1"># identical to -r999..1000</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">--diff-options</span></code> option causes bzr to run the external diff program,
passing options. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">diff</span> <span class="o">--</span><span class="n">diff</span><span class="o">-</span><span class="n">options</span> <span class="o">--</span><span class="n">side</span><span class="o">-</span><span class="n">by</span><span class="o">-</span><span class="n">side</span> <span class="n">foo</span>
</pre></div>
</div>
<p>Some projects prefer patches to show a prefix at the start of the path
for old and new files. The <code class="docutils literal notranslate"><span class="pre">--prefix</span></code> option can be used to provide
such a prefix.
As a shortcut, <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">diff</span> <span class="pre">-p1</span></code> produces a form that works with the
command <code class="docutils literal notranslate"><span class="pre">patch</span> <span class="pre">-p1</span></code>.</p>
</div>
</div>
<div class="section" id="recording-changes">
<h3>1.3.5 Recording changes<a class="headerlink" href="#recording-changes" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="bzr-commit">
<h4>1.3.5.1 bzr commit<a class="headerlink" href="#bzr-commit" title="Ссылка на этот заголовок">¶</a></h4>
<p>When the working tree state is satisfactory, it can be <strong>committed</strong> to
the branch, creating a new revision holding a snapshot of that state.</p>
<p>The <strong>commit</strong> command takes a message describing the changes in the
revision. It also records your userid, the current time and timezone, and
the inventory and contents of the tree. The commit message is specified
by the <code class="docutils literal notranslate"><span class="pre">-m</span></code> or <code class="docutils literal notranslate"><span class="pre">--message</span></code> option. You can enter a multi-line commit
message; in most shells you can enter this just by leaving the quotes open
at the end of the line.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"added my first file"</span>
</pre></div>
</div>
<p>You can also use the <code class="docutils literal notranslate"><span class="pre">-F</span></code> option to take the message from a file. Some
people like to make notes for a commit message while they work, then
review the diff to make sure they did what they said they did. (This file
can also be useful when you pick up your work after a break.)</p>
</div>
<div class="section" id="message-from-an-editor">
<h4>1.3.5.2 Message from an editor<a class="headerlink" href="#message-from-an-editor" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you use neither the <code class="docutils literal notranslate"><span class="pre">-m</span></code> nor the <code class="docutils literal notranslate"><span class="pre">-F</span></code> option then bzr will open an
editor for you to enter a message. The editor to run is controlled by
your <code class="docutils literal notranslate"><span class="pre">$VISUAL</span></code> or <code class="docutils literal notranslate"><span class="pre">$EDITOR</span></code> environment variable, which can be overridden
by the <code class="docutils literal notranslate"><span class="pre">editor</span></code> setting in <code class="docutils literal notranslate"><span class="pre">~/.bazaar/bazaar.conf</span></code>; <code class="docutils literal notranslate"><span class="pre">$BZR_EDITOR</span></code> will
override either of the above mentioned editor options. If you quit the
editor without making any changes, the commit will be cancelled.</p>
<p>The file that is opened in the editor contains a horizontal line. The part
of the file below this line is included for information only, and will not
form part of the commit message. Below the separator is shown the list of
files that are changed in the commit. You should write your message above
the line, and then save the file and exit.</p>
<p>If you would like to see the diff that will be committed as you edit the
message you can use the <code class="docutils literal notranslate"><span class="pre">--show-diff</span></code> option to <code class="docutils literal notranslate"><span class="pre">commit</span></code>. This will include
the diff in the editor when it is opened, below the separator and the
information about the files that will be committed. This means that you can
read it as you write the message, but the diff itself wont be seen in the
commit message when you have finished. If you would like parts to be
included in the message you can copy and paste them above the separator.</p>
</div>
<div class="section" id="selective-commit">
<h4>1.3.5.3 Selective commit<a class="headerlink" href="#selective-commit" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you give file or directory names on the commit command line then only
the changes to those files will be committed. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"documentation fix"</span> <span class="n">commit</span><span class="o">.</span><span class="n">py</span>
</pre></div>
</div>
<p>By default bzr always commits all changes to the tree, even if run from a
subdirectory. To commit from only the current directory down, use:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="o">.</span>
</pre></div>
</div>
</div>
<div class="section" id="giving-credit-for-a-change">
<h4>1.3.5.4 Giving credit for a change<a class="headerlink" href="#giving-credit-for-a-change" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you didn’t actually write the changes that you are about to commit, for instance
if you are applying a patch from someone else, you can use the <code class="docutils literal notranslate"><span class="pre">--author</span></code> commit
option to give them credit for the change:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="o">--</span><span class="n">author</span> <span class="s2">"Jane Rey <jrey@example.com>"</span>
</pre></div>
</div>
<p>The person that you specify there will be recorded as the «author» of the revision,
and you will be recorded as the «committer» of the revision.</p>
<p>If more than one person works on the changes for a revision, for instance if you
are pair-programming, then you can record this by specifying <code class="docutils literal notranslate"><span class="pre">--author</span></code> multiple
times:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="o">--</span><span class="n">author</span> <span class="s2">"Jane Rey <jrey@example.com>"</span> \
<span class="o">--</span><span class="n">author</span> <span class="s2">"John Doe <jdoe@example.com>"</span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="browsing-history">
<h3>1.3.6 Browsing history<a class="headerlink" href="#browsing-history" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="bzr-log">
<h4>1.3.6.1 bzr log<a class="headerlink" href="#bzr-log" title="Ссылка на этот заголовок">¶</a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">log</span></code> command shows a list of previous revisions.</p>
<p>As with <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">diff</span></code>, <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">log</span></code> supports the <code class="docutils literal notranslate"><span class="pre">-r</span></code> argument:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">log</span> <span class="o">-</span><span class="n">r</span> <span class="mf">1000.</span><span class="o">.</span> <span class="c1"># Revision 1000 and everything after it</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">log</span> <span class="o">-</span><span class="n">r</span> <span class="o">..</span><span class="mi">1000</span> <span class="c1"># Everything up to and including r1000</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">log</span> <span class="o">-</span><span class="n">r</span> <span class="mf">1000.</span><span class="o">.</span><span class="mi">1100</span> <span class="c1"># changes from 1000 to 1100</span>
<span class="o">%</span> <span class="n">bzr</span> <span class="n">log</span> <span class="o">-</span><span class="n">r</span> <span class="mi">1000</span> <span class="c1"># The changes in only revision 1000</span>
</pre></div>
</div>
</div>
<div class="section" id="viewing-merged-revisions">
<h4>1.3.6.2 Viewing merged revisions<a class="headerlink" href="#viewing-merged-revisions" title="Ссылка на этот заголовок">¶</a></h4>
<p>As distributed VCS tools like Bazaar make merging much easier than
it is in central VCS tools, the history of a branch may often contain
lines of development splitting off the mainline and merging back
in at a later time. Technically, the relationship between the
numerous revision nodes is known as a Directed Acyclic Graph or
DAG for short.</p>
<p>In many cases, you typically want to see the mainline first and drill
down from there. The default behaviour of log is therefore to show
the mainline and indicate which revisions have nested merged revisions.
To explore the merged revisions for revision X, use the following command:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="o">-</span><span class="n">n0</span> <span class="o">-</span><span class="n">rX</span>
</pre></div>
</div>
<p>To see all revisions and all their merged revisions:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="o">-</span><span class="n">n0</span>
</pre></div>
</div>
<p>Note that the -n option is used to indicate the number of levels to display
where 0 means all. If that is too noisy, you can easily adjust the number
to only view down so far. For example, if your project is structured with
a top level gatekeeper merging changes from team gatekeepers, <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">log</span></code>
shows what the top level gatekeeper did while <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">log</span> <span class="pre">-n2</span></code> shows what
the team gatekeepers did. In the vast majority of cases though, <code class="docutils literal notranslate"><span class="pre">-n0</span></code>
is fine.</p>
</div>
<div class="section" id="tuning-the-output">
<h4>1.3.6.3 Tuning the output<a class="headerlink" href="#tuning-the-output" title="Ссылка на этот заголовок">¶</a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">log</span></code> command has several options that are useful for tuning
the output. These include:</p>
<blockquote>
<div><ul class="simple">
<li><code class="docutils literal notranslate"><span class="pre">--forward</span></code> presents the log in chronological order, i.e. the
most recent revisions are displayed last.</li>
<li>the <code class="docutils literal notranslate"><span class="pre">--limit</span></code> option controls the maximum number of revisions displayed.</li>
</ul>
</div></blockquote>
<p>See the online help for the log command or the User Reference for more
information on tuning the output.</p>
</div>
<div class="section" id="viewing-the-history-for-a-file">
<h4>1.3.6.4 Viewing the history for a file<a class="headerlink" href="#viewing-the-history-for-a-file" title="Ссылка на этот заголовок">¶</a></h4>
<p>It is often useful to filter the history so that it only
applies to a given file. To do this, provide the filename
to the <code class="docutils literal notranslate"><span class="pre">log</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">foo</span><span class="o">.</span><span class="n">py</span>
</pre></div>
</div>
</div>
<div class="section" id="viewing-an-old-version-of-a-file">
<h4>1.3.6.5 Viewing an old version of a file<a class="headerlink" href="#viewing-an-old-version-of-a-file" title="Ссылка на этот заголовок">¶</a></h4>
<p>To get the contents of a file at a given version, use the
<code class="docutils literal notranslate"><span class="pre">cat</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">cat</span> <span class="o">-</span><span class="n">r</span> <span class="n">X</span> <span class="n">file</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">X</span></code> is the revision identifier and <code class="docutils literal notranslate"><span class="pre">file</span></code> is
the filename. This will send output to the standard output
stream so you’ll typically want to pipe the output through
a viewing tool (like <code class="docutils literal notranslate"><span class="pre">less</span></code> or <code class="docutils literal notranslate"><span class="pre">more</span></code>) or redirect it
like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">cat</span> <span class="o">-</span><span class="n">r</span> <span class="o">-</span><span class="mi">2</span> <span class="n">foo</span><span class="o">.</span><span class="n">py</span> <span class="o">|</span> <span class="n">less</span>
<span class="n">bzr</span> <span class="n">cat</span> <span class="o">-</span><span class="n">r</span> <span class="mi">1</span> <span class="n">foo</span><span class="o">.</span><span class="n">py</span> <span class="o">></span> <span class="o">/</span><span class="n">tmp</span><span class="o">/</span><span class="n">foo</span><span class="o">-</span><span class="mi">1</span><span class="n">st</span><span class="o">-</span><span class="n">version</span><span class="o">.</span><span class="n">py</span>
</pre></div>
</div>
</div>
<div class="section" id="graphical-history-viewers">
<h4>1.3.6.6 Graphical history viewers<a class="headerlink" href="#graphical-history-viewers" title="Ссылка на этот заголовок">¶</a></h4>
<p>History browsing is one area where GUI tools really make life easier.
Bazaar has numerous plug-ins that provide this capability including
QBzr and bzr-gtk. See <a class="reference external" href="plugins.html">Using plugins</a> for details on how to install
these if they are not already installed.</p>
<p>To use the graphical viewer from QBzr:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">qlog</span>
</pre></div>
</div>
<p>To use the graphical viewer from bzr-gtk:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">viz</span>
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">viz</span></code> is actually a built-in alias for <code class="docutils literal notranslate"><span class="pre">visualize</span></code> so use the longer
command name if you prefer.</p>
</div>
</div>
<div class="section" id="releasing-a-project">
<h3>1.3.7 Releasing a project<a class="headerlink" href="#releasing-a-project" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="packaging-a-release">
<h4>1.3.7.1 Packaging a release<a class="headerlink" href="#packaging-a-release" title="Ссылка на этот заголовок">¶</a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">export</span></code> command is used to package a release, i.e. to
take a copy of the files and directories in a branch and
package them into a fresh directory or archive. For example,
this command will package the last committed version into
a <code class="docutils literal notranslate"><span class="pre">tar.gz</span></code> archive file:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">export</span> <span class="o">../</span><span class="n">releases</span><span class="o">/</span><span class="n">my</span><span class="o">-</span><span class="n">stuff</span><span class="o">-</span><span class="mf">1.5</span><span class="o">.</span><span class="n">tar</span><span class="o">.</span><span class="n">gz</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">export</span></code> command uses the suffix of the archive file
to work out the type of archive to create as shown below.</p>
<blockquote>
<div><table border="1" class="docutils">
<colgroup>
<col width="40%" />
<col width="60%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Supported formats</th>
<th class="head">Autodetected by extension</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>dir</td>
<td>(none)</td>
</tr>
<tr class="row-odd"><td>tar</td>
<td>.tar</td>
</tr>
<tr class="row-even"><td>tbz2</td>
<td>.tar.bz2, .tbz2</td>
</tr>
<tr class="row-odd"><td>tgz</td>
<td>.tar.gz, .tgz</td>
</tr>
<tr class="row-even"><td>zip</td>
<td>.zip</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>If you wish to package a revision other than the last one, use
the <code class="docutils literal notranslate"><span class="pre">-r</span></code> option. If you wish to tune the root directory inside
the archive, use the <code class="docutils literal notranslate"><span class="pre">--root</span></code> option. See the online help or
User Reference for further details on the options supported by
<code class="docutils literal notranslate"><span class="pre">export</span></code>.</p>
</div>
<div class="section" id="tagging-a-release">
<h4>1.3.7.2 Tagging a release<a class="headerlink" href="#tagging-a-release" title="Ссылка на этот заголовок">¶</a></h4>
<p>Rather than remembering which version was used to package a release,
it’s useful to define a symbolic name for a version using the <code class="docutils literal notranslate"><span class="pre">tag</span></code>
command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">tag</span> <span class="n">version</span><span class="o">-</span><span class="mi">1</span><span class="o">-</span><span class="mi">5</span>
</pre></div>
</div>
<p>That tag can be used later whenever a revision identifier is
required, e.g.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">diff</span> <span class="o">-</span><span class="n">r</span> <span class="n">tag</span><span class="p">:</span><span class="n">version</span><span class="o">-</span><span class="mi">1</span><span class="o">-</span><span class="mi">5</span>
</pre></div>
</div>
<p>To see the list of tags defined in a branch, use the <code class="docutils literal notranslate"><span class="pre">tags</span></code> command.</p>
</div>
</div>
<div class="section" id="undoing-mistakes">
<h3>1.3.8 Undoing mistakes<a class="headerlink" href="#undoing-mistakes" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="mistakes-happen">
<h4>1.3.8.1 Mistakes happen<a class="headerlink" href="#mistakes-happen" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar has been designed to make it easy to
recover from mistakes as explained below.</p>
</div>
<div class="section" id="dropping-the-revision-history-for-a-project">
<h4>1.3.8.2 Dropping the revision history for a project<a class="headerlink" href="#dropping-the-revision-history-for-a-project" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you accidentally put the wrong tree under version control, simply
delete the <code class="docutils literal notranslate"><span class="pre">.bzr</span></code> directory.</p>
</div>
<div class="section" id="deregistering-a-file-or-directory">
<h4>1.3.8.3 Deregistering a file or directory<a class="headerlink" href="#deregistering-a-file-or-directory" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you accidentally register a file using <code class="docutils literal notranslate"><span class="pre">add</span></code> that you
don’t want version controlled, you can use the <code class="docutils literal notranslate"><span class="pre">remove</span></code>
command to tell Bazaar to forget about it.</p>
<p><code class="docutils literal notranslate"><span class="pre">remove</span></code> has been designed to <em>Do the Safe Thing</em> in
that it will not delete a modified file. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">add</span> <span class="n">foo</span><span class="o">.</span><span class="n">html</span>
<span class="p">(</span><span class="n">oops</span> <span class="o">-</span> <span class="n">didn</span><span class="s1">'t mean that)</span>
<span class="n">bzr</span> <span class="n">remove</span> <span class="n">foo</span><span class="o">.</span><span class="n">html</span>
</pre></div>
</div>
<p>This will complain about the file being modified or unknown.
If you want to keep the file, use the <code class="docutils literal notranslate"><span class="pre">--keep</span></code> option.
Alternatively, if you want to delete the file, use the <code class="docutils literal notranslate"><span class="pre">--force</span></code> option.
For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">add</span> <span class="n">foo</span><span class="o">.</span><span class="n">html</span>
<span class="p">(</span><span class="n">oops</span> <span class="o">-</span> <span class="n">didn</span><span class="s1">'t mean that)</span>
<span class="n">bzr</span> <span class="n">remove</span> <span class="o">--</span><span class="n">keep</span> <span class="n">foo</span><span class="o">.</span><span class="n">html</span>
<span class="p">(</span><span class="n">foo</span><span class="o">.</span><span class="n">html</span> <span class="n">left</span> <span class="n">on</span> <span class="n">disk</span><span class="p">,</span> <span class="n">but</span> <span class="n">deregistered</span><span class="p">)</span>
</pre></div>
</div>
<p>On the other hand, the unchanged <code class="docutils literal notranslate"><span class="pre">TODO</span></code> file is deregistered and
removed from disk without complaint in this example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">add</span> <span class="n">TODO</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"added TODO"</span>
<span class="p">(</span><span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span> <span class="o">-</span> <span class="n">but</span> <span class="n">don</span><span class="s1">'t change TODO)</span>
<span class="n">bzr</span> <span class="n">remove</span> <span class="n">TODO</span>
<span class="p">(</span><span class="n">TODO</span> <span class="n">file</span> <span class="n">deleted</span><span class="p">)</span>
</pre></div>
</div>
<p>Note: If you delete a file using your file manager, IDE or via an operating
system command, the <code class="docutils literal notranslate"><span class="pre">commit</span></code> command will implicitly treat it as removed.</p>
</div>
<div class="section" id="undoing-changes-since-the-last-commit">
<h4>1.3.8.4 Undoing changes since the last commit<a class="headerlink" href="#undoing-changes-since-the-last-commit" title="Ссылка на этот заголовок">¶</a></h4>
<p>One of the reasons for using a version control tool is that it
lets you easily checkpoint good tree states while working. If you
decide that the changes you have made since the last <code class="docutils literal notranslate"><span class="pre">commit</span></code> ought
to be thrown away, the command to use is <code class="docutils literal notranslate"><span class="pre">revert</span></code> like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">revert</span>
</pre></div>
</div>
<p>As a precaution, it is good practice to use <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">status</span></code> and
<code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">diff</span></code> first to check that everything being thrown away
really ought to be.</p>
</div>
<div class="section" id="undoing-changes-to-a-file-since-the-last-commit">
<h4>1.3.8.5 Undoing changes to a file since the last commit<a class="headerlink" href="#undoing-changes-to-a-file-since-the-last-commit" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you want to undo changes to a particular file since the last commit but
keep all the other changes in the tree, pass the filename as an argument
to <code class="docutils literal notranslate"><span class="pre">revert</span></code> like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">revert</span> <span class="n">foo</span><span class="o">.</span><span class="n">py</span>
</pre></div>
</div>
</div>
<div class="section" id="undoing-the-last-commit">
<h4>1.3.8.6 Undoing the last commit<a class="headerlink" href="#undoing-the-last-commit" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you make a commit and really didn’t mean to, use the <code class="docutils literal notranslate"><span class="pre">uncommit</span></code> command
to undo it like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">uncommit</span>
</pre></div>
</div>
<p>Unlike <code class="docutils literal notranslate"><span class="pre">revert</span></code>, <code class="docutils literal notranslate"><span class="pre">uncommit</span></code> leaves the content of your working tree
exactly as it is. That’s really handy if you make a commit and accidently
provide the wrong error message. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Fix bug #11"</span>
<span class="p">(</span><span class="n">damn</span> <span class="o">-</span> <span class="n">wrong</span> <span class="n">bug</span> <span class="n">number</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">uncommit</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Fix bug #1"</span>
</pre></div>
</div>
<p>Another common reason for undoing a commit is because you forgot to add
one or more files. Some users like to alias <code class="docutils literal notranslate"><span class="pre">commit</span></code> to <code class="docutils literal notranslate"><span class="pre">commit</span> <span class="pre">--strict</span></code>
so that commits fail if unknown files are found in the tree.</p>
<p>Tags for uncommitted revisions are removed from the branch unless
<code class="docutils literal notranslate"><span class="pre">--keep-tags</span></code> was specified.</p>
<p>Note: While the <code class="docutils literal notranslate"><span class="pre">merge</span></code> command is not introduced until the next
chapter, it is worth noting now that <code class="docutils literal notranslate"><span class="pre">uncommit</span></code> restores any pending
merges. (Running <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">status</span></code> after <code class="docutils literal notranslate"><span class="pre">uncommit</span></code> will show these.)
<code class="docutils literal notranslate"><span class="pre">merge</span></code> can also be used to effectively undo just a selected commit
earlier in history. For more information on <code class="docutils literal notranslate"><span class="pre">merge</span></code>, see
<a class="reference external" href="merging_changes.html">Merging changes</a> in the next chapter and the
Bazaar User Reference.</p>
</div>
<div class="section" id="undoing-multiple-commits">
<h4>1.3.8.7 Undoing multiple commits<a class="headerlink" href="#undoing-multiple-commits" title="Ссылка на этот заголовок">¶</a></h4>
<p>You can use the -r option to undo several commits like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">uncommit</span> <span class="o">-</span><span class="n">r</span> <span class="o">-</span><span class="mi">3</span>
</pre></div>
</div>
<p>If your reason for doing this is that you really want to
back out several changes, then be sure to remember that <code class="docutils literal notranslate"><span class="pre">uncommit</span></code>
does not change your working tree: you’ll probably need to run the
<code class="docutils literal notranslate"><span class="pre">revert</span></code> command as well to complete the task. In many cases though,
it’s arguably better to leave your history alone and add a new
revision reflecting the content of the last good state.</p>
</div>
<div class="section" id="reverting-to-the-state-of-an-earlier-version">
<h4>1.3.8.8 Reverting to the state of an earlier version<a class="headerlink" href="#reverting-to-the-state-of-an-earlier-version" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you make an unwanted change but it doesn’t make sense to uncommit
it (because that code has been released to users say), you can use
<code class="docutils literal notranslate"><span class="pre">revert</span></code> to take your working tree back to the desired state.
For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">commit</span> <span class="s2">"Fix bug #5"</span>
<span class="n">Committed</span> <span class="n">revision</span> <span class="mf">20.</span>
<span class="p">(</span><span class="n">release</span> <span class="n">the</span> <span class="n">code</span><span class="p">)</span>
<span class="p">(</span><span class="n">hmm</span> <span class="o">-</span> <span class="n">bad</span> <span class="n">fix</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">revert</span> <span class="o">-</span><span class="n">r</span> <span class="mi">19</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Backout fix for bug #5"</span>
</pre></div>
</div>
<p>This will change your entire tree back to the state as of revision 19,
which is probably only what you want if you haven’t made any new commits
since then. If you have, the <code class="docutils literal notranslate"><span class="pre">revert</span></code> would wipe them out as well. In that
case, you probably want to use <a class="reference external" href="adv_merging.html#reverse-cherrypicking">Reverse cherrypicking</a> instead to
back out the bad fix.</p>
<p>Note: As an alternative to using an absolute revision number (like 19), you can
specify one relative to the tip (-1) using a negative number like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">revert</span> <span class="o">-</span><span class="n">r</span> <span class="o">-</span><span class="mi">2</span>
</pre></div>
</div>
</div>
<div class="section" id="correcting-a-tag">
<h4>1.3.8.9 Correcting a tag<a class="headerlink" href="#correcting-a-tag" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have defined a tag prematurely, use the <code class="docutils literal notranslate"><span class="pre">--force</span></code> option of
the <code class="docutils literal notranslate"><span class="pre">tag</span></code> command to redefine it. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">tag</span> <span class="mf">2.0</span><span class="o">-</span><span class="n">beta</span><span class="o">-</span><span class="mi">1</span>
<span class="p">(</span><span class="n">oops</span><span class="p">,</span> <span class="n">we</span><span class="s1">'re not yet ready for that)</span>
<span class="p">(</span><span class="n">make</span> <span class="n">more</span> <span class="n">commits</span> <span class="n">to</span> <span class="n">include</span> <span class="n">more</span> <span class="n">fixes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">tag</span> <span class="mf">2.0</span><span class="o">-</span><span class="n">beta</span><span class="o">-</span><span class="mi">1</span> <span class="o">--</span><span class="n">force</span>
</pre></div>
</div>
</div>
<div class="section" id="clearing-a-tag">
<h4>1.3.8.10 Clearing a tag<a class="headerlink" href="#clearing-a-tag" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have defined a tag and no longer want it defined, use the
<code class="docutils literal notranslate"><span class="pre">--delete</span></code> option of the <code class="docutils literal notranslate"><span class="pre">tag</span></code> command to remove it. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">tag</span> <span class="mf">2.0</span><span class="o">-</span><span class="n">beta</span><span class="o">-</span><span class="mi">4</span>
<span class="p">(</span><span class="n">oops</span><span class="p">,</span> <span class="n">we</span><span class="s1">'re not releasing a 4th beta)</span>
<span class="n">bzr</span> <span class="n">tag</span> <span class="mf">2.0</span><span class="o">-</span><span class="n">beta</span><span class="o">-</span><span class="mi">4</span> <span class="o">--</span><span class="n">delete</span>
</pre></div>
</div>
</div>
</div>
</div>
<div class="section" id="id34">
<h2><a class="toc-backref" href="#id79">1.4 Делимся с другими</a><a class="headerlink" href="#id34" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="working-with-another">
<h3>1.4.1 Working with another<a class="headerlink" href="#working-with-another" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="peer-to-peer-rocks">
<h4>1.4.1.1 Peer-to-peer rocks<a class="headerlink" href="#peer-to-peer-rocks" title="Ссылка на этот заголовок">¶</a></h4>
<p>In many cases, two minds can be better than one. You may be the one
who started a project and someone wishes to help, or perhaps it’s you
who wants to help another. Perhaps you are both members of a larger
team that have been assigned a task together as pair programmers.
Either way, two people need to agree on a process, a set of
guidelines and a toolset in order to work together effectively.</p>
<p>Imagine if you were not allowed to call someone on the phone directly
and the only way to talk to them was by registering a conference call first?
Companies and communities that only share code via a central VCS
repository are living with a similar straitjacket to that every day.
There are times when central control makes a lot of sense and times
when peer-to-peer rocks. Either way, Bazaar is designed to help.</p>
</div>
<div class="section" id="the-partner-workflow">
<h4>1.4.1.2 The partner workflow<a class="headerlink" href="#the-partner-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>While it’s certainly not the only way to do it, the <em>partner workflow</em>
below is a good starting point for a pair of people who wish to
collaborate using Bazaar.</p>
<img alt="../_images/workflows_peer.png" src="../_images/workflows_peer.png" />
<p>Over and above the tasks covered in the previous chapter, this
chapter introduces two essential collaboration activities:</p>
<blockquote>
<div><ul class="simple">
<li>getting a copy of a branch</li>
<li>merging changes between branches.</li>
</ul>
</div></blockquote>
<p>Even when it’s just you working on a code base, it can be very useful
to keep multiple branches around (for different releases say) and
to merge changes between them as appropriate. Your «partner» may indeed
be yourself.</p>
</div>
</div>
<div class="section" id="branching-a-project">
<h3>1.4.2 Branching a project<a class="headerlink" href="#branching-a-project" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="branch-urls">
<h4>1.4.2.1 Branch URLs<a class="headerlink" href="#branch-urls" title="Ссылка на этот заголовок">¶</a></h4>
<p>Before someone else can get a copy of your work, you need to
agree on a transfer technology.
You may decide to make the top level directory of your branch
a network share, an approach familiar to Windows users.
Linux and OS X users might prefer access to be
via SFTP, a secure protocol built-in to most SSH servers.
Bazaar is <em>very</em> flexible in this regard with support for
lots of protocols some of which are given below.</p>
<blockquote>
<div><table border="1" class="docutils">
<colgroup>
<col width="17%" />
<col width="83%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">Prefix</th>
<th class="head">Description</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td><a class="reference external" href="file://">file://</a></td>
<td>Access using the standard filesystem (default)</td>
</tr>
<tr class="row-odd"><td>sftp://</td>
<td>Access using SFTP (most SSH servers provide SFTP).</td>
</tr>
<tr class="row-even"><td>bzr://</td>
<td>Fast access using the Bazaar smart server.</td>
</tr>
<tr class="row-odd"><td><a class="reference external" href="ftp://">ftp://</a></td>
<td>Access using passive FTP.</td>
</tr>
<tr class="row-even"><td><a class="reference external" href="http://">http://</a></td>
<td>Read-only access to branches exported by a web server.</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>As indicated above, branches are identified using URLs with the
prefix indicating the transfer technology. If no prefix is given,
normal filenames are assumed. For a complete list of supported
protocols, see the <code class="docutils literal notranslate"><span class="pre">urlspec</span></code> online help topic or the
<a class="reference external" href="../user-reference/bzr_man.html#url-identifiers">URL Identifiers</a>
section of the Bazaar User Reference.</p>
</div>
<div class="section" id="a-reminder-about-shared-repositories">
<span id="id35"></span><h4>1.4.2.2 Напоминание о разделяемых репозиториях<a class="headerlink" href="#a-reminder-about-shared-repositories" title="Ссылка на этот заголовок">¶</a></h4>
<p>Before getting a copy of a branch, have a quick think about
where to put it on your filesystem. For maximum storage
efficiency down the track, it is recommended that branches
be created somewhere under a directory that has been set up
as a shared repository. (See <a class="reference internal" href="#feature-branches">Feature branches</a> in
n <a class="reference internal" href="#organizing-your-workspace">Organizing your workspace</a> for a commonly used layout.)
For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">my</span><span class="o">-</span><span class="n">repo</span>
<span class="n">cd</span> <span class="n">my</span><span class="o">-</span><span class="n">repo</span>
</pre></div>
</div>
<p>You are now ready to grab a branch from someone else and
hack away.</p>
</div>
<div class="section" id="the-branch-command">
<h4>1.4.2.3 The branch command<a class="headerlink" href="#the-branch-command" title="Ссылка на этот заголовок">¶</a></h4>
<p>To get a branch based on an existing branch, use the <code class="docutils literal notranslate"><span class="pre">branch</span></code> command.
The syntax is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">URL</span> <span class="p">[</span><span class="n">directory</span><span class="p">]</span>
</pre></div>
</div>
<p>If a directory is not given, one is created based on the last part of
the URL. Here are some examples showing a drive qualified path (M:/) and an
SFTP URL respectively:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">M</span><span class="p">:</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">sftp</span><span class="p">:</span><span class="o">//</span><span class="n">bill</span><span class="nd">@mary</span><span class="o">-</span><span class="n">laptop</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">repo</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">trunk</span>
</pre></div>
</div>
<p>This example shows explicitly giving the directory name to use for the
new branch:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="o">/</span><span class="n">home</span><span class="o">/</span><span class="n">mary</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">repo</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">trunk</span> <span class="n">cool</span>
</pre></div>
</div>
</div>
<div class="section" id="time-and-space-considerations">
<h4>1.4.2.4 Time and space considerations<a class="headerlink" href="#time-and-space-considerations" title="Ссылка на этот заголовок">¶</a></h4>
<p>Depending on the size of the branch being transferred and the
speed and latency of the network between your computer and the
source branch, this initial transfer might take some time.
Subsequent updates should be much faster as only the
changes are transferred then.</p>
<p>Keep in mind that Bazaar is transferring the
complete history of the branch, not just the latest snapshot.
As a consequence, you can be off the network (or disconnected
from the network share) after <code class="docutils literal notranslate"><span class="pre">branch</span></code> completes but you’ll
still be able to <code class="docutils literal notranslate"><span class="pre">log</span></code> and <code class="docutils literal notranslate"><span class="pre">diff</span></code> the history of the
branch as much as you want. Furthermore, these operations
are quick as the history is stored locally.</p>
<p>Note that Bazaar uses smart compression technology to
minimize the amount of disk space required to store version
history. In many cases, the complete history of a project
will take up less disk space than the working copy of
the latest version.</p>
<p>As explained in later chapters, Bazaar also has support for
<a class="reference external" href="#getting-a-lightweight-checkout">lightweight checkouts</a>
of a branch, i.e. working trees with
no local storage of history. Of course, disconnected usage
is not available then but that’s a tradeoff you can decide
to make if local disk space is really tight for you. Support for
limited lookback into history - <em>history horizons</em> - is
currently under development as well.</p>
</div>
<div class="section" id="viewing-branch-information">
<h4>1.4.2.5 Viewing branch information<a class="headerlink" href="#viewing-branch-information" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you wish to see information about a branch including where it came from,
use the <code class="docutils literal notranslate"><span class="pre">info</span></code> command. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">info</span> <span class="n">cool</span>
</pre></div>
</div>
<p>If no branch is given, information on the current branch is displayed.</p>
</div>
</div>
<div class="section" id="id36">
<h3>1.4.3 Merging changes<a class="headerlink" href="#id36" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="parallel-development">
<h4>1.4.3.1 Parallel development<a class="headerlink" href="#parallel-development" title="Ссылка на этот заголовок">¶</a></h4>
<p>Once someone has their own branch of a project, they can make
and commit changes in parallel to any development proceeding
on the original branch. Pretty soon though, these independent
lines of development will need to be combined again. This
process is known as <em>merging</em>.</p>
</div>
<div class="section" id="the-merge-command">
<h4>1.4.3.2 The merge command<a class="headerlink" href="#the-merge-command" title="Ссылка на этот заголовок">¶</a></h4>
<p>To incorporate changes from another branch, use the <code class="docutils literal notranslate"><span class="pre">merge</span></code> command.
Its syntax is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="p">[</span><span class="n">URL</span><span class="p">]</span>
</pre></div>
</div>
<p>If no URL is given, a default is used, initially the branch this branch
originated from.
For example, if Bill made a branch from Mary’s work, he can merge her
subsequent changes by simply typing this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span>
</pre></div>
</div>
<p>On the other hand, Mary might want to merge into her branch the work Bill
has done in his. In this case, she needs to explicitly give the URL the
first time, e.g.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">mary</span><span class="nd">@bill</span><span class="o">-</span><span class="n">laptop</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">repo</span><span class="o">/</span><span class="n">cool</span><span class="o">-</span><span class="n">trunk</span>
</pre></div>
</div>
<p>This sets the default merge branch if one is not already set. Use
<code class="docutils literal notranslate"><span class="pre">--no-remember</span></code> to avoid setting it. To change the default after it is set,
use the <code class="docutils literal notranslate"><span class="pre">--remember</span></code> option.</p>
</div>
<div class="section" id="how-does-merging-work">
<h4>1.4.3.3 How does merging work?<a class="headerlink" href="#how-does-merging-work" title="Ссылка на этот заголовок">¶</a></h4>
<p>A variety of algorithms exist for merging changes. Bazaar’s
default algorithm is a variation of <em>3-way merging</em> which
works as follows. Given an ancestor A and two branches B and C,
the following table provides the rules used.</p>
<blockquote>
<div><table border="1" class="docutils">
<colgroup>
<col width="9%" />
<col width="9%" />
<col width="9%" />
<col width="19%" />
<col width="53%" />
</colgroup>
<thead valign="bottom">
<tr class="row-odd"><th class="head">A</th>
<th class="head">B</th>
<th class="head">C</th>
<th class="head">Result</th>
<th class="head">Comment</th>
</tr>
</thead>
<tbody valign="top">
<tr class="row-even"><td>x</td>
<td>x</td>
<td>x</td>
<td>x</td>
<td>unchanged</td>
</tr>
<tr class="row-odd"><td>x</td>
<td>x</td>
<td>y</td>
<td>y</td>
<td>line from C</td>
</tr>
<tr class="row-even"><td>x</td>
<td>y</td>
<td>x</td>
<td>y</td>
<td>line from B</td>
</tr>
<tr class="row-odd"><td>x</td>
<td>y</td>
<td>z</td>
<td>?</td>
<td>conflict</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>Note that some merges can only be completed with the assistance
of a human. Details on how to resolve these are given in
<a class="reference external" href="resolving_conflicts.html">Resolving conflicts</a>.</p>
</div>
<div class="section" id="recording-a-merge">
<h4>1.4.3.4 Recording a merge<a class="headerlink" href="#recording-a-merge" title="Ссылка на этот заголовок">¶</a></h4>
<p>After any conflicts are resolved, the merge needs to be committed.
For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Merged Mary's changes"</span>
</pre></div>
</div>
<p>Even if there are no conflicts, an explicit commit is still required.
Unlike some other tools, this is considered a feature in Bazaar.
A clean merge is not necessarily a good merge so making the commit
a separate explicit step allows you to run your test suite first to
verify all is good. If problems are found, you should correct them
before committing the merge or throw the merge away using <code class="docutils literal notranslate"><span class="pre">revert</span></code>.</p>
</div>
<div class="section" id="merge-tracking">
<h4>1.4.3.5 Merge tracking<a class="headerlink" href="#merge-tracking" title="Ссылка на этот заголовок">¶</a></h4>
<p>One of the most important features of Bazaar is distributed,
high quality <em>merge tracking</em>.
In other words, Bazaar remembers what has been merged already and
uses that information to intelligently choose the best ancestor for
a merge, minimizing the number and size of conflicts.</p>
<p>If you are a refugee from many other VCS tools, it can be really
hard to «unlearn» the <em>please-let-me-avoid-merging-at-any-cost</em> habit.
Bazaar lets you safely merge as often as you like with other people.
By working in a peer-to-peer manner when it makes sense to do so, you
also avoid using a central branch as an «integration swamp», keeping
its quality higher. When the change you’re collaborating on is
truly ready for wider sharing, that’s the time to merge and commit
it to a central branch, not before.</p>
<p>Merging that Just Works truly can change how developers work together.</p>
</div>
</div>
<div class="section" id="id37">
<h3>1.4.4 Resolving conflicts<a class="headerlink" href="#id37" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="workflow">
<h4>1.4.4.1 Workflow<a class="headerlink" href="#workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>Unlike some other tools that force you to resolve each conflict during
the merge process, Bazaar merges as much as it can and then reports the
conflicts. This can make conflict resolution easier because the contents
of the whole post-merge tree are available to help you decide how things
ought to be resolved. You may also wish to selectively run tests as you go
to confirm each resolution or group or resolutions is good.</p>
</div>
<div class="section" id="listing-conflicts">
<h4>1.4.4.2 Listing conflicts<a class="headerlink" href="#listing-conflicts" title="Ссылка на этот заголовок">¶</a></h4>
<p>As well as being reported by the <code class="docutils literal notranslate"><span class="pre">merge</span></code> command, the list of outstanding
conflicts may be displayed at any time by using the <code class="docutils literal notranslate"><span class="pre">conflicts</span></code>
command. It is also included as part of the output from the <code class="docutils literal notranslate"><span class="pre">status</span></code>
command.</p>
</div>
<div class="section" id="resolving-a-conflict">
<h4>1.4.4.3 Resolving a conflict<a class="headerlink" href="#resolving-a-conflict" title="Ссылка на этот заголовок">¶</a></h4>
<p>When a conflict is encountered, the <code class="docutils literal notranslate"><span class="pre">merge</span></code> command puts embedded
markers in each file showing the areas it couldn’t resolve. It also
creates 3 files for each file with a conflict:</p>
<blockquote>
<div><ul class="simple">
<li>foo.BASE</li>
<li>foo.THIS</li>
<li>foo.OTHER</li>
</ul>
</div></blockquote>
<p>where <code class="docutils literal notranslate"><span class="pre">foo</span></code> is the name of the conflicted file.
In many cases, you can resolve conflicts by simply manually editing
each file in question, fixing the relevant areas and removing the
conflict markers as you go.</p>
<p>After fixing all the files in conflict, and removing the markers,
ask Bazaar to mark them as resolved using the <code class="docutils literal notranslate"><span class="pre">resolve</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">resolve</span>
</pre></div>
</div>
<p>Alternatively, after fixing each file, you can mark it as resolved
like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">resolve</span> <span class="n">foo</span>
</pre></div>
</div>
<p>Among other things, the <code class="docutils literal notranslate"><span class="pre">resolve</span></code> command cleans up the BASE,
THIS and OTHER files from your working tree.</p>
</div>
<div class="section" id="using-the-remerge-command">
<h4>1.4.4.4 Using the remerge command<a class="headerlink" href="#using-the-remerge-command" title="Ссылка на этот заголовок">¶</a></h4>
<p>In some cases, you may wish to try a different merge algorithm on a
given file. To do this, use the <code class="docutils literal notranslate"><span class="pre">remerge</span></code> command nominating
the file like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">remerge</span> <span class="o">--</span><span class="n">weave</span> <span class="n">foo</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">foo</span></code> is the file and <code class="docutils literal notranslate"><span class="pre">weave</span></code> is one of the available
merge algorithms. This algorithm is particularly useful when a
so-called <code class="docutils literal notranslate"><span class="pre">criss-cross</span></code> merge is detected, e.g. when two branches
merge the same thing then merge each other. See the online help for
<code class="docutils literal notranslate"><span class="pre">criss-cross</span></code> and <code class="docutils literal notranslate"><span class="pre">remerge</span></code> for further details.</p>
</div>
<div class="section" id="using-external-tools-to-resolve-conflicts">
<h4>1.4.4.5 Using external tools to resolve conflicts<a class="headerlink" href="#using-external-tools-to-resolve-conflicts" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have a GUI tool you like using to resolve conflicts, be sure
to install the <em>extmerge</em> plugin. Once installed, it can be used
like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">extmerge</span> <span class="n">foo</span>
</pre></div>
</div>
<p>where <code class="docutils literal notranslate"><span class="pre">foo</span></code> is the conflicted file. Rather than provide a list of
files to resolve, you can give the <code class="docutils literal notranslate"><span class="pre">--all</span></code> option to implicitly
specify all conflicted files.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">extmerge</span></code> command uses the tool specified by the
<code class="docutils literal notranslate"><span class="pre">external_merge</span></code> setting in your <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> file.
If not set, it will look for some popular merge tools such
as <code class="docutils literal notranslate"><span class="pre">kdiff3</span></code> or <code class="docutils literal notranslate"><span class="pre">opendiff</span></code>, the latter being a command
line interface to the FileMerge utility in OS X.</p>
</div>
</div>
<div class="section" id="annotating-changes">
<h3>1.4.5 Annotating changes<a class="headerlink" href="#annotating-changes" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="seeing-the-origin-of-content">
<h4>1.4.5.1 Seeing the origin of content<a class="headerlink" href="#seeing-the-origin-of-content" title="Ссылка на этот заголовок">¶</a></h4>
<p>When two or more people are working on files, it can be highly
useful at times to see who created or last changed certain content.
To do this, using the annotate command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">annotate</span> <span class="n">readme</span><span class="o">.</span><span class="n">txt</span>
</pre></div>
</div>
<p>If you are a pessimist or an optimist, you might prefer to use
one of built-in aliases for <code class="docutils literal notranslate"><span class="pre">annotate</span></code>: <code class="docutils literal notranslate"><span class="pre">blame</span></code> or <code class="docutils literal notranslate"><span class="pre">praise</span></code>.
Either way, this displays each line of the file together with
information such as:</p>
<blockquote>
<div><ul class="simple">
<li>who changed it last</li>
<li>when it was last changed</li>
<li>the commit message.</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="gui-tools">
<h4>1.4.5.2 GUI tools<a class="headerlink" href="#gui-tools" title="Ссылка на этот заголовок">¶</a></h4>
<p>The various GUI plugins for Bazaar provide graphical tools for
viewing annotation information. For example, the bzr-gtk plugin
provides a GUI tool for this that can be launched using the
<code class="docutils literal notranslate"><span class="pre">gannotate</span></code> command:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">gannotate</span> <span class="n">readme</span><span class="o">.</span><span class="n">txt</span>
</pre></div>
</div>
<p>The GUI tools typically provide a much richer display of
interesting information (e.g. all the changes in each commit)
so you may prefer them over the text-based command.</p>
</div>
</div>
</div>
<div class="section" id="id38">
<h2><a class="toc-backref" href="#id80">1.5 Сотрудничество в команде, централизованный стиль</a><a class="headerlink" href="#id38" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="centralized-development">
<h3>1.5.1 Centralized development<a class="headerlink" href="#centralized-development" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="motivation">
<h4>1.5.1.1 Motivation<a class="headerlink" href="#motivation" title="Ссылка на этот заголовок">¶</a></h4>
<p>Rather than working in parallel and occasionally merging, it can be
useful at times to work in lockstep, i.e. for multiple people to
be continuously committing changes to a central location, merging
their work with the latest content before every commit.</p>
<p>This workflow is very familiar to users of central VCS tools like
Subversion and CVS. It is also applicable to a single developer
who works on multiple machines, e.g. someone who normally works
on a desktop computer but travels with a laptop, or someone who
uses their (Internet connected) home computer to complete office
work out of hours.</p>
<p>If centralized development works well for your team already, that’s
great. Many teams begin using Bazaar this way and experiment with
alternative workflows later.</p>
</div>
<div class="section" id="centralized-workflow">
<h4>1.5.1.2 Centralized workflow<a class="headerlink" href="#centralized-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>The diagram below provides an overview of the <em>centralized workflow</em>.</p>
<img alt="../_images/workflows_centralized.png" src="../_images/workflows_centralized.png" />
<p>Even if your team is planning to use a more distributed workflow, many
of the tasks covered in this chapter may be useful to you, particularly
how to publish branches.</p>
</div>
</div>
<div class="section" id="publishing-a-branch">
<span id="id39"></span><h3>1.5.2 Publishing a branch<a class="headerlink" href="#publishing-a-branch" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="setting-up-a-central-repository">
<h4>1.5.2.1 Setting up a central repository<a class="headerlink" href="#setting-up-a-central-repository" title="Ссылка на этот заголовок">¶</a></h4>
<p>While the centralized workflow can be used by socially nominating
any branch on any computer as the central one, in practice most
teams have a dedicated server for hosting central branches.</p>
<p>Just as it’s best practice to use a shared repository locally,
it’s advisable to put central branches in a shared repository.
Note that central shared branches typically only want to
store history, not working copies of files, so their enclosing
repository is usually creating using the <code class="docutils literal notranslate"><span class="pre">no-trees</span></code> option, e.g.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="o">--</span><span class="n">no</span><span class="o">-</span><span class="n">trees</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span>
</pre></div>
</div>
<p>You can think of this step as similar to setting up a new cvsroot or
Subversion repository. However, Bazaar gives you more flexibility
in how branches may be organised in your repository. See
<a class="reference external" href="shared_repository_layouts.html">Advanced shared repository layouts</a>
in the appendices for guidelines and examples.</p>
</div>
<div class="section" id="starting-a-central-branch">
<h4>1.5.2.2 Starting a central branch<a class="headerlink" href="#starting-a-central-branch" title="Ссылка на этот заголовок">¶</a></h4>
<p>There are two ways of populating a central branch with some initial
content:</p>
<blockquote>
<div><ol class="arabic simple">
<li>Making a local branch and pushing it to a central location</li>
<li>Making an empty central branch then committing content to it.</li>
</ol>
</div></blockquote>
<p>Here is an example of the first way:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">PROJECT</span> <span class="p">(</span><span class="n">prepare</span> <span class="n">local</span> <span class="n">repository</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">init</span> <span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
<span class="n">cd</span> <span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
<span class="p">(</span><span class="n">copy</span> <span class="n">development</span> <span class="n">files</span><span class="p">)</span>
<span class="n">cp</span> <span class="o">-</span><span class="n">ar</span> <span class="o">~/</span><span class="n">PROJECT</span> <span class="o">.</span> <span class="p">(</span><span class="n">copy</span> <span class="n">files</span> <span class="ow">in</span> <span class="n">using</span> <span class="n">OS</span><span class="o">-</span><span class="n">specific</span> <span class="n">tools</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">add</span> <span class="p">(</span><span class="n">populate</span> <span class="n">repository</span><span class="p">;</span> <span class="n">start</span> <span class="n">version</span> <span class="n">control</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Initial import"</span>
<span class="p">(</span><span class="n">publish</span> <span class="n">to</span> <span class="n">central</span> <span class="n">repository</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">push</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
</pre></div>
</div>
<p>Here is an example of the second way:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">PROJECT</span> <span class="p">(</span><span class="n">prepare</span> <span class="n">local</span> <span class="n">repository</span><span class="p">)</span>
<span class="n">cd</span> <span class="n">PROJECT</span>
<span class="n">bzr</span> <span class="n">init</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">checkout</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
<span class="n">cd</span> <span class="n">trunk</span>
<span class="n">cp</span> <span class="o">-</span><span class="n">ar</span> <span class="o">~/</span><span class="n">PROJECT</span> <span class="o">.</span> <span class="p">(</span><span class="n">copy</span> <span class="n">files</span> <span class="ow">in</span> <span class="n">using</span> <span class="n">OS</span><span class="o">-</span><span class="n">specific</span> <span class="n">tools</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">add</span> <span class="p">(</span><span class="n">populate</span> <span class="n">repository</span><span class="p">;</span> <span class="n">start</span> <span class="n">version</span> <span class="n">control</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Initial import"</span>
<span class="p">(</span><span class="n">publish</span> <span class="n">to</span> <span class="n">central</span> <span class="n">repository</span><span class="p">)</span>
</pre></div>
</div>
<p>Note that committing inside a working tree created using
the <code class="docutils literal notranslate"><span class="pre">checkout</span></code> command implicitly commits the content to
the central location as well as locally. Had we used the
<code class="docutils literal notranslate"><span class="pre">branch</span></code> command instead of <code class="docutils literal notranslate"><span class="pre">checkout</span></code> above, the
content would have only been committed locally.</p>
<p>Working trees that are tightly bound to a central location
like this are called <em>checkouts</em>. The rest of this chapter
explains their numerous features in more detail.</p>
</div>
</div>
<div class="section" id="using-checkouts">
<h3>1.5.3 Using checkouts<a class="headerlink" href="#using-checkouts" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="turning-a-branch-into-a-checkout">
<h4>1.5.3.1 Turning a branch into a checkout<a class="headerlink" href="#turning-a-branch-into-a-checkout" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have a local branch and wish to make it a checkout, use the
<code class="docutils literal notranslate"><span class="pre">bind</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">bind</span> <span class="n">sftp</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
</pre></div>
</div>
<p>This is necessary, for example, after creating a central branch using
<code class="docutils literal notranslate"><span class="pre">push</span></code> as illustrated in the previous section.</p>
<p>After this, commits will be applied to the bound branch before
being applied locally.</p>
</div>
<div class="section" id="turning-a-checkout-into-a-branch">
<h4>1.5.3.2 Turning a checkout into a branch<a class="headerlink" href="#turning-a-checkout-into-a-branch" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have a checkout and wish to make it a normal branch, use the
<code class="docutils literal notranslate"><span class="pre">unbind</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">unbind</span>
</pre></div>
</div>
<p>After this, commits will only be applied locally.</p>
</div>
<div class="section" id="getting-a-checkout">
<h4>1.5.3.3 Getting a checkout<a class="headerlink" href="#getting-a-checkout" title="Ссылка на этот заголовок">¶</a></h4>
<p>When working in a team using a central branch, one person needs
to provide some initial content as shown in the previous section.
After that, each person should use the <code class="docutils literal notranslate"><span class="pre">checkout</span></code> command to
create their local checkout, i.e. the sandbox in which they
will make their changes.</p>
<p>Unlike Subversion and CVS, in Bazaar the <code class="docutils literal notranslate"><span class="pre">checkout</span></code> command creates a
local full copy of history in addition to creating a working tree holding
the latest content. This means that operations such as <code class="docutils literal notranslate"><span class="pre">diff</span></code> and <code class="docutils literal notranslate"><span class="pre">log</span></code>
are fast and can still be used when disconnected from the central location.</p>
</div>
<div class="section" id="getting-a-lightweight-checkout">
<span id="id40"></span><h4>1.5.3.4 Создание легковесной рабочей копии<a class="headerlink" href="#getting-a-lightweight-checkout" title="Ссылка на этот заголовок">¶</a></h4>
<p>While Bazaar does its best to efficiently store version history, there
are occasions when the history is simply not wanted. For example, if your
team is managing the content of a web site using Bazaar with a
central repository, then your release process might be as simple as
updating a checkout of the content on the public web server. In this
case, you probably don’t want the history downloaded to that location
as doing so:</p>
<blockquote>
<div><ul class="simple">
<li>wastes disk space holding history that isn’t needed there</li>
<li>exposes a Bazaar branch that you may want kept private.</li>
</ul>
</div></blockquote>
<p>To get a history-less checkout in Bazaar, use the <code class="docutils literal notranslate"><span class="pre">--lightweight</span></code>
option like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">checkout</span> <span class="o">--</span><span class="n">lightweight</span> <span class="n">sftp</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
</pre></div>
</div>
<p>Of course, many of the benefits of a normal checkout are lost by doing
this but that’s a tradeoff you can make if and when it makes sense.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">--lightweight</span></code> option only applies to checkouts, not to all branches.</p>
<p>Note: If your code base is really large and disk space on your computer
is limited, lightweight checkouts may be the right choice for you.
Be sure to consider all your options though including
<a class="reference external" href="#a-reminder-about-shared-repositories">shared repositories</a>,
<a class="reference external" href="#using-stacked-branches">stacked branches</a>, and <a class="reference internal" href="#reusing-a-checkout">reusing a checkout</a>.</p>
</div>
<div class="section" id="updating-to-the-latest-content">
<h4>1.5.3.5 Updating to the latest content<a class="headerlink" href="#updating-to-the-latest-content" title="Ссылка на этот заголовок">¶</a></h4>
<p>One of the important aspects of working in lockstep with others is
keeping your checkout up to date with the latest changes made to
the central branch. Just as you would in Subversion or CVS, you do
this in Bazaar by using the <code class="docutils literal notranslate"><span class="pre">update</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">update</span>
</pre></div>
</div>
<p>This gets any new revisions available in the bound branch and
merges your local changes, if any.</p>
</div>
<div class="section" id="handling-commit-failures">
<h4>1.5.3.6 Handling commit failures<a class="headerlink" href="#handling-commit-failures" title="Ссылка на этот заголовок">¶</a></h4>
<p>Note that your checkout <em>must</em> be up to date with the bound branch
before running <code class="docutils literal notranslate"><span class="pre">commit</span></code>. Bazaar is actually stricter about this
than Subversion or CVS - you need to be up to date with the full
tree, not just for the files you’ve changed. Bazaar will ask you
to run <code class="docutils literal notranslate"><span class="pre">update</span></code> if it detects that a revision has been added to
the central location since you last updated.</p>
<p>If the network connection to the bound branch is lost, the commit will
fail. Some alternative ways of working around that are outlined next.</p>
</div>
</div>
<div class="section" id="working-offline-on-a-central-branch">
<h3>1.5.4 Working offline on a central branch<a class="headerlink" href="#working-offline-on-a-central-branch" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="the-centralized-with-local-commits-workflow">
<h4>1.5.4.1 The centralized with local commits workflow<a class="headerlink" href="#the-centralized-with-local-commits-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you lose your network connection because you are travelling, the central
server goes down, or you simply want to snapshot changes locally without
publishing them centrally just yet, this workflow is for you.</p>
<img alt="../_images/workflows_localcommit.png" src="../_images/workflows_localcommit.png" />
</div>
<div class="section" id="committing-locally">
<h4>1.5.4.2 Committing locally<a class="headerlink" href="#committing-locally" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you’re working in a checkout and need/wish to commit locally only,
add the <code class="docutils literal notranslate"><span class="pre">--local</span></code> option to the <code class="docutils literal notranslate"><span class="pre">commit</span></code> command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">commit</span> <span class="o">--</span><span class="n">local</span>
</pre></div>
</div>
</div>
<div class="section" id="being-disconnected-for-long-time-periods">
<h4>1.5.4.3 Being disconnected for long time periods<a class="headerlink" href="#being-disconnected-for-long-time-periods" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you will be or want to be disconnected from the bound branch for
a while, then remembering to add <code class="docutils literal notranslate"><span class="pre">--local</span></code> to every <code class="docutils literal notranslate"><span class="pre">commit</span></code> command
can be annoying. An alternative is to use the <code class="docutils literal notranslate"><span class="pre">unbind</span></code> command to
make the checkout temporarily into a normal branch followed by the
<code class="docutils literal notranslate"><span class="pre">bind</span></code> command at some later point in time when you want to
keep in lockstep again.</p>
<p>Note that the <code class="docutils literal notranslate"><span class="pre">bind</span></code> command remembers where you were bound to
last time this branch was a checkout so it isn’t necessary to enter
the URL of the remote branch when you use <code class="docutils literal notranslate"><span class="pre">bind</span></code> after an earlier
<code class="docutils literal notranslate"><span class="pre">unbind</span></code>.</p>
</div>
<div class="section" id="merging-a-series-of-local-commits">
<h4>1.5.4.4 Merging a series of local commits<a class="headerlink" href="#merging-a-series-of-local-commits" title="Ссылка на этот заголовок">¶</a></h4>
<p>When you make commits locally independent of ongoing development
on a central branch, then Bazaar treats these as two lines of
development next time you <code class="docutils literal notranslate"><span class="pre">update</span></code>. In this case, <code class="docutils literal notranslate"><span class="pre">update</span></code>
does the following:</p>
<blockquote>
<div><ul class="simple">
<li>it brings the latest revisions from the bound branch down and
makes that the mainline of development within your checkout</li>
<li>it moves your local changes since you last updated into a logical
parallel branch</li>
<li>it merges these together so that your local changes are reported
as a pending merge by <code class="docutils literal notranslate"><span class="pre">status</span></code>.</li>
</ul>
</div></blockquote>
<p>As always, you will need to run <code class="docutils literal notranslate"><span class="pre">commit</span></code> after this to send your
work to the central branch.</p>
</div>
</div>
<div class="section" id="reusing-a-checkout">
<h3>1.5.5 Reusing a checkout<a class="headerlink" href="#reusing-a-checkout" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id41">
<h4>1.5.5.1 Motivation<a class="headerlink" href="#id41" title="Ссылка на этот заголовок">¶</a></h4>
<p>At times, it can be useful to have a single checkout as your
sandbox for working on multiple branches. Some possible reasons
for this include:</p>
<blockquote>
<div><ul class="simple">
<li>saving disk space when the working tree is large</li>
<li>developing in a fixed location.</li>
</ul>
</div></blockquote>
<p>In many cases, working tree disk usage swamps the size of the
<code class="docutils literal notranslate"><span class="pre">.bzr</span></code> directory. If you want to work on multiple branches
but can’t afford the overhead of a full working tree for each,
reusing a checkout across multiples branches is the way to go.</p>
<p>On other occasions, the location of your sandbox might be
configured into numerous development and testing tools. Once
again, reusing a checkout across multiple branches can help.</p>
</div>
<div class="section" id="changing-where-a-branch-is-bound-to">
<h4>1.5.5.2 Changing where a branch is bound to<a class="headerlink" href="#changing-where-a-branch-is-bound-to" title="Ссылка на этот заголовок">¶</a></h4>
<p>To change where a checkout is bound to, follow these steps:</p>
<blockquote>
<div><ol class="arabic simple">
<li>Make sure that any local changes have been committed
centrally so that no work is lost.</li>
<li>Use the <code class="docutils literal notranslate"><span class="pre">bind</span></code> command giving the URL of the new
remote branch you wish to work on.</li>
<li>Make your checkout a copy of the desired branch by using
the <code class="docutils literal notranslate"><span class="pre">update</span></code> command followed by the <code class="docutils literal notranslate"><span class="pre">revert</span></code> command.</li>
</ol>
</div></blockquote>
<p>Note that simply binding to a new branch and running <code class="docutils literal notranslate"><span class="pre">update</span></code>
merges in your local changes, both committed and uncommitted. You need
to decide whether to keep them or not by running either <code class="docutils literal notranslate"><span class="pre">revert</span></code>
or <code class="docutils literal notranslate"><span class="pre">commit</span></code>.</p>
<p>An alternative to the bind+update recipe is using the <code class="docutils literal notranslate"><span class="pre">switch</span></code>
command. This is basically the same as removing the existing
branch and running <code class="docutils literal notranslate"><span class="pre">checkout</span></code> again on the new location, except
that any uncommitted changes in your tree are merged in.</p>
<p>Note: As <code class="docutils literal notranslate"><span class="pre">switch</span></code> can potentially throw away committed changes in
order to make a checkout an accurate cache of a different bound branch,
it will fail by design if there are changes which have been committed
locally but are not yet committed to the most recently bound branch.
To truly abandon these changes, use the <code class="docutils literal notranslate"><span class="pre">--force</span></code> option.</p>
</div>
<div class="section" id="switching-a-lightweight-checkout">
<h4>1.5.5.3 Switching a lightweight checkout<a class="headerlink" href="#switching-a-lightweight-checkout" title="Ссылка на этот заголовок">¶</a></h4>
<p>With a lightweight checkout, there are no local commits and <code class="docutils literal notranslate"><span class="pre">switch</span></code>
effectively changes which branch the working tree is associated with.
One possible setup is to use a lightweight checkout in combination
with a local tree-less repository. This lets you switch what you
are working on with ease. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="o">--</span><span class="n">no</span><span class="o">-</span><span class="n">trees</span> <span class="n">PROJECT</span>
<span class="n">cd</span> <span class="n">PROJECT</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">checkout</span> <span class="o">--</span><span class="n">lightweight</span> <span class="n">trunk</span> <span class="n">my</span><span class="o">-</span><span class="n">sandbox</span>
<span class="n">cd</span> <span class="n">my</span><span class="o">-</span><span class="n">sandbox</span>
<span class="p">(</span><span class="n">hack</span> <span class="n">away</span><span class="p">)</span>
</pre></div>
</div>
<p>Note that trunk in this example will have a <code class="docutils literal notranslate"><span class="pre">.bzr</span></code> directory within it
but there will be no working tree there as the branch was created in
a tree-less repository. You can grab or create as many branches as you
need there and switch between them as required. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">(</span><span class="n">assuming</span> <span class="ow">in</span> <span class="n">my</span><span class="o">-</span><span class="n">sandbox</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">-</span><span class="mf">1.0</span> <span class="o">../</span><span class="n">PROJECT</span><span class="o">-</span><span class="mf">1.0</span>
<span class="n">bzr</span> <span class="n">switch</span> <span class="o">../</span><span class="n">PROJECT</span><span class="o">-</span><span class="mf">1.0</span>
<span class="p">(</span><span class="n">fix</span> <span class="n">bug</span> <span class="ow">in</span> <span class="mf">1.0</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"blah, blah blah"</span>
<span class="n">bzr</span> <span class="n">switch</span> <span class="o">../</span><span class="n">trunk</span>
<span class="p">(</span><span class="n">go</span> <span class="n">back</span> <span class="n">to</span> <span class="n">working</span> <span class="n">on</span> <span class="n">the</span> <span class="n">trunk</span><span class="p">)</span>
</pre></div>
</div>
<p>Note: The branches may be local only or they may be bound to
remote ones (by creating them with <code class="docutils literal notranslate"><span class="pre">checkout</span></code> or by using <code class="docutils literal notranslate"><span class="pre">bind</span></code>
after creating them with <code class="docutils literal notranslate"><span class="pre">branch</span></code>).</p>
</div>
</div>
</div>
<div class="section" id="id42">
<h2><a class="toc-backref" href="#id81">1.6 Сотрудничество в команде, распределенный стиль</a><a class="headerlink" href="#id42" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="distributed-development">
<h3>1.6.1 Distributed development<a class="headerlink" href="#distributed-development" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id43">
<h4>1.6.1.1 Motivation<a class="headerlink" href="#id43" title="Ссылка на этот заголовок">¶</a></h4>
<p>Distributed VCS tools offer new ways of working together,
ways that better reflect the modern world we live in and
ways that enable higher quality outcomes.</p>
</div>
<div class="section" id="the-decentralized-with-shared-mainline-workflow">
<h4>1.6.1.2 The decentralized with shared mainline workflow<a class="headerlink" href="#the-decentralized-with-shared-mainline-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this workflow, each developer has their own branch or branches, plus
a checkout of the main branch. They do their work in their personal
branch, then merge it into the mainline when it is ready.</p>
<img alt="../_images/workflows_shared.png" src="../_images/workflows_shared.png" />
<p>Other distributed workflows are explored later in this chapter.</p>
</div>
</div>
<div class="section" id="organizing-branches">
<h3>1.6.2 Organizing branches<a class="headerlink" href="#organizing-branches" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="mirror-branches">
<h4>1.6.2.1 Mirror branches<a class="headerlink" href="#mirror-branches" title="Ссылка на этот заголовок">¶</a></h4>
<p>A primary difference when using distributed workflows to
develop is that your main local branch is not the place
to make changes. Instead, it is kept as a pristine copy
of the central branch, i.e. it’s a <em>mirror branch</em>.</p>
<p>To create a mirror branch, set-up a shared repository
(if you haven’t already) and then use the <code class="docutils literal notranslate"><span class="pre">branch</span></code>
(or <code class="docutils literal notranslate"><span class="pre">checkout</span></code>) command to create the mirror.
For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">PROJECT</span>
<span class="n">cd</span> <span class="n">PROJECT</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">centralhost</span><span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">PROJECT</span><span class="o">/</span><span class="n">trunk</span>
</pre></div>
</div>
</div>
<div class="section" id="task-branches">
<h4>1.6.2.2 Task branches<a class="headerlink" href="#task-branches" title="Ссылка на этот заголовок">¶</a></h4>
<p>Each new feature or fix is developed in its own branch.
These branches are referred to as <em>feature branches</em> or
<em>task branches</em> - the terms are used interchangeably.</p>
<p>To create a task branch, use the <code class="docutils literal notranslate"><span class="pre">branch</span></code> command
against your mirror branch. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">trunk</span> <span class="n">fix</span><span class="o">-</span><span class="mi">123</span>
<span class="n">cd</span> <span class="n">fix</span><span class="o">-</span><span class="mi">123</span>
<span class="p">(</span><span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">)</span>
</pre></div>
</div>
<p>There are numerous advantages to this approach:</p>
<blockquote>
<div><ol class="arabic simple">
<li>You can work on multiple changes in parallel</li>
<li>There is reduced coupling between changes</li>
<li>Multiple people can work in a peer-to-peer mode
on a branch until it is ready to go.</li>
</ol>
</div></blockquote>
<p>In particular, some changes take longer to cook than others
so you can ask for reviews, apply feedback, ask for another
review, etc. By completing work to sufficient quality in
separate branches before merging into a central branch, the
quality and stability of the central branch are maintained
at higher level than they otherwise would be.</p>
</div>
<div class="section" id="refreshing-a-mirror-branch">
<h4>1.6.2.3 Refreshing a mirror branch<a class="headerlink" href="#refreshing-a-mirror-branch" title="Ссылка на этот заголовок">¶</a></h4>
<p>Use the <code class="docutils literal notranslate"><span class="pre">pull</span></code> command to do this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">pull</span>
</pre></div>
</div>
</div>
<div class="section" id="merging-the-latest-trunk-into-a-feature-branch">
<h4>1.6.2.4 Merging the latest trunk into a feature branch<a class="headerlink" href="#merging-the-latest-trunk-into-a-feature-branch" title="Ссылка на этот заголовок">¶</a></h4>
<p>Use the <code class="docutils literal notranslate"><span class="pre">merge</span></code> command to do this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">fix</span><span class="o">-</span><span class="mi">123</span>
<span class="n">bzr</span> <span class="n">merge</span>
<span class="p">(</span><span class="n">resolve</span> <span class="nb">any</span> <span class="n">conflicts</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"merged trunk"</span>
</pre></div>
</div>
</div>
<div class="section" id="merging-a-feature-into-the-trunk">
<h4>1.6.2.5 Merging a feature into the trunk<a class="headerlink" href="#merging-a-feature-into-the-trunk" title="Ссылка на этот заголовок">¶</a></h4>
<p>The policies for different distributed workflows vary here.
The simple case where all developers have commit rights to
the main trunk are shown below.</p>
<p>If your mirror is a checkout:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">update</span>
<span class="n">bzr</span> <span class="n">merge</span> <span class="o">../</span><span class="n">fix</span><span class="o">-</span><span class="mi">123</span>
<span class="p">(</span><span class="n">resolve</span> <span class="nb">any</span> <span class="n">conflicts</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Fixed bug #123"</span>
</pre></div>
</div>
<p>If your mirror is a branch:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">pull</span>
<span class="n">bzr</span> <span class="n">merge</span> <span class="o">../</span><span class="n">fix</span><span class="o">-</span><span class="mi">123</span>
<span class="p">(</span><span class="n">resolve</span> <span class="nb">any</span> <span class="n">conflicts</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Fixed bug #123"</span>
<span class="n">bzr</span> <span class="n">push</span>
</pre></div>
</div>
</div>
<div class="section" id="backing-up-task-branches">
<h4>1.6.2.6 Backing up task branches<a class="headerlink" href="#backing-up-task-branches" title="Ссылка на этот заголовок">¶</a></h4>
<p>One of the side effects of centralized workflows is that changes
get frequently committed to a central location which is backed up as
part of normal IT operations. When developing on task branches,
it is a good idea to publish your work to a central location
(but not necessarily a shared location) that will be backed up.
You may even wish to bind local task branches to remote ones
established on a backup server just for this purpose.</p>
</div>
</div>
<div class="section" id="using-gatekeepers">
<h3>1.6.3 Using gatekeepers<a class="headerlink" href="#using-gatekeepers" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="the-decentralized-with-human-gatekeeper-workflow">
<h4>1.6.3.1 The decentralized with human gatekeeper workflow<a class="headerlink" href="#the-decentralized-with-human-gatekeeper-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this workflow, one developer (the gatekeeper) has commit rights
to the main branch while other developers have read-only access.
All developers make their changes in task branches.</p>
<img alt="../_images/workflows_gatekeeper.png" src="../_images/workflows_gatekeeper.png" />
<p>When a developer wants their work merged, they ask the gatekeeper
to review their change and merge it if acceptable. If a change fails
review, further development proceeds in the relevant task branch
until it is good to go.</p>
<p>Note that a key aspect of this approach is the inversion of control
that is implied: developers no longer decide when to «commit/push»
changes into the central branch: the code base evolves by gatekeepers
«merging/pulling» changes in a controlled manner. It’s perfectly
acceptable, indeed common, to have multiple central branches with
different gatekeepers, e.g. one branch for the current production
release and another for the next release. In this case, a task branch
holding a bug fix will most likely be advertised to both gatekeepers.</p>
<p>One of the great things about this workflow is that it is hugely
scalable. Large projects can be broken into teams and each
team can have a <em>local master branch</em> managed by a gatekeeper.
Someone can be appointed as the primary gatekeeper to merge
changes from the team master branches into the primary master
branch when team leaders request it.</p>
</div>
<div class="section" id="the-decentralized-with-automatic-gatekeeper-workflow">
<h4>1.6.3.2 The decentralized with automatic gatekeeper workflow<a class="headerlink" href="#the-decentralized-with-automatic-gatekeeper-workflow" title="Ссылка на этот заголовок">¶</a></h4>
<p>To obtain even higher quality, all developers can be required to
submit changes to an automated gatekeeper that only merges and
commits a change if it passes a regression test suite. One
such gatekeeper is a software tool called PQM.</p>
<img alt="../_images/workflows_pqm.png" src="../_images/workflows_pqm.png" />
<p>For further information on PQM, see <a class="reference external" href="https://launchpad.net/pqm">https://launchpad.net/pqm</a>.</p>
</div>
</div>
<div class="section" id="sending-changes">
<h3>1.6.4 Sending changes<a class="headerlink" href="#sending-changes" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id44">
<h4>1.6.4.1 Motivation<a class="headerlink" href="#id44" title="Ссылка на этот заголовок">¶</a></h4>
<p>In many distributed development scenarios, it isn’t always feasible for
developers to share task branches by advertising their URLs.
For example, a developer working on a laptop might take it home overnight
so his/her task branches could well be inaccessible when a gatekeeper
in another timezone wants to review or merge it.</p>
<p>Bazaar provides a neat feature to assist here: <em>merge directives</em>.</p>
</div>
<div class="section" id="understanding-merge-directives">
<h4>1.6.4.2 Understanding merge directives<a class="headerlink" href="#understanding-merge-directives" title="Ссылка на этот заголовок">¶</a></h4>
<p>You can think of a merge directive as a «mini branch» - just the
new growth on a branch since it was created. It’s a software
patch showing what’s new but with added intelligence: metadata
like interim commits, renames and digital signatures.</p>
<p>Another useful metaphor is a packet cake: a merge directive has a recipe
together with the ingredients you need bundled inside it.
To stretch the metaphor, the ingredients are all the metadata on the
changes made to the branch; the recipe is instructions on how those
changes ought to be merged, i.e. information for the <code class="docutils literal notranslate"><span class="pre">merge</span></code> command
to use in selecting common ancestors.</p>
<p>Regardless of how you think of them, merge directives are neat.
They are easy to create, suitable for mailing around as attachments
and can be processed much like branches can on the receiving end.</p>
</div>
<div class="section" id="creating-a-merge-directive">
<h4>1.6.4.3 Creating a merge directive<a class="headerlink" href="#creating-a-merge-directive" title="Ссылка на этот заголовок">¶</a></h4>
<p>To create and optionally send a merge directive, use the <code class="docutils literal notranslate"><span class="pre">send</span></code> command.</p>
<p>By default, <code class="docutils literal notranslate"><span class="pre">send</span></code> will email the merge directive to the «submission
address» for the branch, which is typically the lead developer or the
development mailing list.
<code class="docutils literal notranslate"><span class="pre">send</span></code> without options will create a merge directive, fire up your email
tool and attach it, ready for you to add the explanatory text bit.
(See the online help for <code class="docutils literal notranslate"><span class="pre">send</span></code> and
<a class="reference external" href="../user-reference/index.html#configuration-settings">Configuration Settings</a>
in the User Reference for further details on how to configure this.)</p>
<p>Most projects like people to add some explanation to the mail along with
the patch, explaining the reason for the patch, and why it is done the way
it is. This gives a reviewer some context before going into the
line-by-line diff.</p>
<p>Alternatively, if the <code class="docutils literal notranslate"><span class="pre">--output</span></code> (or <code class="docutils literal notranslate"><span class="pre">-o</span></code>) option is given, <code class="docutils literal notranslate"><span class="pre">send</span></code>
will write the merge directive to a file, so you can mail it yourself,
examine it, or save it for later use. If an output file of <code class="docutils literal notranslate"><span class="pre">-</span></code> is
given, the directive is written to stdout. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="n">X</span><span class="o">-</span><span class="n">fix</span><span class="o">-</span><span class="mi">123</span>
<span class="n">bzr</span> <span class="n">send</span> <span class="o">-</span><span class="n">o</span> <span class="o">../</span><span class="n">fix</span><span class="o">-</span><span class="mf">123.</span><span class="n">patch</span>
</pre></div>
</div>
</div>
<div class="section" id="applying-a-merge-directive">
<h4>1.6.4.4 Applying a merge directive<a class="headerlink" href="#applying-a-merge-directive" title="Ссылка на этот заголовок">¶</a></h4>
<p>Merge directives can be applied in much the same way as branches: by
using the <code class="docutils literal notranslate"><span class="pre">merge</span></code> and <code class="docutils literal notranslate"><span class="pre">pull</span></code> commands.</p>
<p>They can also be useful when communicating with upstream projects
that don’t use Bazaar. In particular, the preview of the overall
change in a merge directive looks like a vanilla software patch, so
they can be applied using <code class="docutils literal notranslate"><span class="pre">patch</span> <span class="pre">-p0</span></code> for example.</p>
</div>
</div>
</div>
<div class="section" id="id46">
<h2><a class="toc-backref" href="#id82">1.7 Различные темы</a><a class="headerlink" href="#id46" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="the-journey-ahead">
<h3>1.7.1 The journey ahead<a class="headerlink" href="#the-journey-ahead" title="Ссылка на этот заголовок">¶</a></h3>
<p>We hope that earlier chapters have given you a solid
understanding of how Bazaar can assist you in being productive
on your own and working effectively with others.
If you are learning Bazaar for the first time, it might be
good to try the procedures covered already for a while,
coming back to this manual once you have mastered them.</p>
<p>Remaining chapters
covers various topics to guide you in further optimizing how you
use Bazaar. Unless stated otherwise, the topics in this and
remaining chapters are independent of each other and can therefore
be read in whichever order you wish.</p>
</div>
<div class="section" id="pseudo-merging">
<h3>1.7.2 Pseudo merging<a class="headerlink" href="#pseudo-merging" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="cherrypicking">
<h4>1.7.2.1 Cherrypicking<a class="headerlink" href="#cherrypicking" title="Ссылка на этот заголовок">¶</a></h4>
<p>At times, it can be useful to selectively merge some of the changes
in a branch, but not all of them. This is commonly referred to as
<em>cherrypicking</em>. Here are some examples of where cherrypicking is
useful:</p>
<ul class="simple">
<li>selectively taking fixes from the main development branch into
a release branch</li>
<li>selectively taking improvements out of an experimental branch into
a feature branch.</li>
</ul>
<p>To merge only the changes made by revision X in branch <code class="docutils literal notranslate"><span class="pre">foo</span></code>,
the command is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="o">-</span><span class="n">c</span> <span class="n">X</span> <span class="n">foo</span>
</pre></div>
</div>
<p>To merge only the changes up to revision X in branch <code class="docutils literal notranslate"><span class="pre">foo</span></code>,
the command is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="o">-</span><span class="n">r</span> <span class="n">X</span> <span class="n">foo</span>
</pre></div>
</div>
<p>To merge only the changes since revision X in branch <code class="docutils literal notranslate"><span class="pre">foo</span></code>,
the command is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="o">-</span><span class="n">r</span> <span class="n">X</span><span class="o">..</span> <span class="n">foo</span>
</pre></div>
</div>
<p>To merge only the changes from revision X to revision Y in branch <code class="docutils literal notranslate"><span class="pre">foo</span></code>,
the command is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="o">-</span><span class="n">r</span> <span class="n">X</span><span class="o">..</span><span class="n">Y</span> <span class="n">foo</span>
</pre></div>
</div>
<p>Like a normal merge, you must explicitly commit a cherrypick. You may wish
to see the changes made using <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">diff</span></code>, and run your test suite if any,
before doing this.</p>
<p>Unlike a normal merge, Bazaar does not currently track cherrypicks.
In particular, the changes look like a normal commit and the (internal)
revision history of the changes from the other branch is lost.
In many cases where they are useful (see above), this is not a major
problem because there are good reasons why a full merge should never
be done at a later time. In other cases, additional conflicts will need
to be resolved when the changes are merged again.</p>
</div>
<div class="section" id="merging-without-parents">
<h4>1.7.2.2 Merging without parents<a class="headerlink" href="#merging-without-parents" title="Ссылка на этот заголовок">¶</a></h4>
<p>A related technique to cherrypicking, in that it makes changes without
reference to the revisions that they came from is to perform a merge, but
forget about the parent revisions before committing. This has the effect of
making all of the changes that would have been in the merge happen in a single
commit. After the merge and before the corresponding commit, you can do:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">revert</span> <span class="o">--</span><span class="n">forget</span><span class="o">-</span><span class="n">merges</span>
</pre></div>
</div>
<p>to keep the changes in the working tree, but remove the record of the
revisions where the changes originated. The next commit would then record
all of those changes without any record of the merged revisions.</p>
<p>This is desired by some users to make their history «cleaner», but you should
be careful that the loss of history does not outweigh the value of cleanliness,
particularly given Bazaar’s capabilities for progressively disclosing merged
revisions. In particular, because this will include the changes from the
source branch, but without attribution to that branch, it can lead to
additional conflicts on later merges that involve the same source and
target branches.</p>
</div>
<div class="section" id="id47">
<h4>1.7.2.3 Reverse cherrypicking<a class="headerlink" href="#id47" title="Ссылка на этот заголовок">¶</a></h4>
<p>Cherrypicking can be used to reverse a set of changes made by giving an
upper bound in the revision range which is <em>below</em> the lower bound.
For example, to back-out changes made in revision 10, the command is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span> <span class="o">-</span><span class="n">r</span> <span class="mf">10.</span><span class="o">.</span><span class="mi">9</span>
</pre></div>
</div>
<p>If you want to take most changes, but not all, from somewhere else, you
may wish to do a normal merge followed by a few reverse cherrypicks.</p>
</div>
<div class="section" id="merging-uncommitted-changes">
<h4>1.7.2.4 Merging uncommitted changes<a class="headerlink" href="#merging-uncommitted-changes" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you have several branches and you accidentally start making changes in the
wrong one, here are the steps to take to correct this. Assuming you began
working in branch <code class="docutils literal notranslate"><span class="pre">foo</span></code> when you meant to work in branch <code class="docutils literal notranslate"><span class="pre">bar</span></code>:</p>
<ol class="arabic simple">
<li>Change into branch <code class="docutils literal notranslate"><span class="pre">bar</span></code>.</li>
<li>Run <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">merge</span> <span class="pre">--uncommitted</span> <span class="pre">foo</span></code></li>
<li>Check the changes came across (<code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">diff</span></code>)</li>
<li>Change into branch <code class="docutils literal notranslate"><span class="pre">foo</span></code></li>
<li>Run <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">revert</span></code>.</li>
</ol>
</div>
<div class="section" id="rebasing">
<h4>1.7.2.5 Rebasing<a class="headerlink" href="#rebasing" title="Ссылка на этот заголовок">¶</a></h4>
<p>Another option to normal merging is <em>rebasing</em>, i.e. making it look like
the current branch originated from a different point than it did.
Rebasing is supported in Bazaar by the <code class="docutils literal notranslate"><span class="pre">rebase</span></code> command provided by
the <code class="docutils literal notranslate"><span class="pre">rebase</span></code> plugin.</p>
<p>The <code class="docutils literal notranslate"><span class="pre">rebase</span></code> command takes the location of another branch on which
the branch in the current working directory will be rebased. If a branch
is not specified then the parent branch is used, and this is usually the
desired result.</p>
<p>The first step identifies the revisions that are in the current branch
that are not in the parent branch. The current branch is then set to be
at the same revision as the target branch, and each revision is replayed
on top of the branch. At the end of the process it will appear as though
your current branch was branched off the current last revision of the target.</p>
<p>Each revision that is replayed may cause conflicts in the tree. If this
happens the command will stop and allow you to fix them up. Resolve the
commits as you would for a <code class="docutils literal notranslate"><span class="pre">merge</span></code>, and then run <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">resolve</span></code> to
marked them as resolved. Once you have resolved all the conflicts, you
should run <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">rebase-continue</span></code> to continue the rebase operation.
If conflicts are encountered and you decide not to continue,
you can run <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">rebase-abort</span></code>. You can also use <code class="docutils literal notranslate"><span class="pre">rebase-todo</span></code> to
show the list of commits still to be replayed.</p>
<p>Note: Some users coming from central VCS tools with poor merge tracking
like rebasing because it’s similar to how they are use to working in older
tools, or because «perfectly clean» history seems important. Before rebasing
in Bazaar, think about whether a normal merge is a better choice. In
particular, rebasing a private branch before sharing it is OK but
rebasing after sharing a branch with someone else is <strong>strongly</strong> discouraged.</p>
</div>
</div>
<div class="section" id="shelving-changes">
<h3>1.7.3 Shelving Changes<a class="headerlink" href="#shelving-changes" title="Ссылка на этот заголовок">¶</a></h3>
<p>Sometimes you will want to temporarily remove changes from your working
tree and restore them later, For instance to commit a small bug-fix you
found while working on something. Bazaar allows you to put changes on
a <code class="docutils literal notranslate"><span class="pre">shelf</span></code> to achieve this. When you want to restore the changes later
you can use <code class="docutils literal notranslate"><span class="pre">unshelve</span></code> to apply them to your working tree again.</p>
<p>For example, consider a working tree with one or more changes made …</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr diff
=== modified file 'description.txt'
--- description.txt
+++ description.txt
@@ -2,7 +2,7 @@
===============
These plugins
-by Michael Ellerman
+written by Michael Ellerman
provide a very
fine-grained 'undo'
facility
@@ -11,6 +11,6 @@
This allows you to
undo some of
your changes,
-commit, and get
+perform a commit, and get
back to where you
were before.
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">shelve</span></code> command interactively asks which changes
you want to retain in the working tree:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr shelve
--- description.txt
+++ description.txt
@@ -2,7 +2,7 @@
===============
These plugins
-by Michael Ellerman
+written by Michael Ellerman
provide a very
fine-grained 'undo'
facility
Shelve? [yNfrq?]: y
--- description.txt
+++ description.txt
@@ -11,6 +11,6 @@
This allows you to
undo some of
your changes,
-commit, and get
+perform a commit, and get
back to where you
were before.
Shelve? [yNfrq?]: n
Shelve 2 change(s)? [yNfrq?]', 'y'
Selected changes:
M description.txt
Changes shelved with id "1".
</pre></div>
</div>
<p>If there are lots of changes in the working tree, you
can provide the <code class="docutils literal notranslate"><span class="pre">shelve</span></code> command with a list of files
and you will only be asked about changes in those files.
After shelving changes, it’s a good idea to use <code class="docutils literal notranslate"><span class="pre">diff</span></code>
to confirm the tree has just the changes you expect:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr diff
=== modified file 'description.txt'
--- description.txt
+++ description.txt
@@ -2,7 +2,7 @@
===============
These plugins
-by Michael Ellerman
+written by Michael Ellerman
provide a very
fine-grained 'undo'
facility
</pre></div>
</div>
<p>Great - you’re ready to commit:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr commit -m "improve first sentence"
</pre></div>
</div>
<p>At some later time, you can bring the shelved changes back into the
working tree using <code class="docutils literal notranslate"><span class="pre">unshelve</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr unshelve
Unshelving changes with id "1".
M description.txt
All changes applied successfully.
</pre></div>
</div>
<p>If you want to, you can put multiple items on the shelf.
Normally each time you run <code class="docutils literal notranslate"><span class="pre">unshelve</span></code> the most recently
shelved changes will be reinstated. However, you can also
unshelve changes in a different order by explicitly
specifying which changes to unshelve.</p>
<p>Bazaar merges the changes in to your working tree, so they
will apply even if you have edited the files since you shelved
them, though they may conflict, in which case you will have to
resolve the conflicts in the same way you do after a conflicted
merge.</p>
</div>
<div class="section" id="filtered-views">
<h3>1.7.4 Filtered views<a class="headerlink" href="#filtered-views" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="introducing-filtered-views">
<h4>1.7.4.1 Introducing filtered views<a class="headerlink" href="#introducing-filtered-views" title="Ссылка на этот заголовок">¶</a></h4>
<p>Views provide a mask over the tree so that users can focus on a subset
of a tree when doing their work. There are several cases where this
masking can be helpful. For example, technical writers and testers on
many large projects may prefer to deal with just the directories/files
in the project of interest to them.</p>
<p>Developers may also wish to break a large set of changes into multiple
commits by using views. While <code class="docutils literal notranslate"><span class="pre">shelve</span></code> and <code class="docutils literal notranslate"><span class="pre">unshelve</span></code> let developers
put some changes aside for a later commit, views let developers specify
what to include in (instead of exclude from) the next commit.</p>
<p>After creating a view, commands that support a list of files - status,
diff, commit, etc - effectively have that list of files implicitly
given each time. An explicit list of files can still be given to these
commands but the nominated files must be within the current view. In
contrast, tree-centric commands - pull, merge, update, etc. - continue
to operate on the whole tree but only report changes relevant to the
current view. In both cases, Bazaar notifies the user each time it uses
a view implicitly so that it is clear that the operation or output is
being masked accordingly.</p>
<p>Note: Filtered views are only supported in format 2a, the default in
Bazaar 2.0, or later.</p>
</div>
<div class="section" id="creating-a-view">
<h4>1.7.4.2 Creating a view<a class="headerlink" href="#creating-a-view" title="Ссылка на этот заголовок">¶</a></h4>
<p>This is done by specifying the files and directories using the <code class="docutils literal notranslate"><span class="pre">view</span></code>
command like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="n">file1</span> <span class="n">file2</span> <span class="n">dir1</span> <span class="o">...</span>
</pre></div>
</div>
<p>The output is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Using</span> <span class="s1">'my'</span> <span class="n">view</span><span class="p">:</span> <span class="n">file1</span><span class="p">,</span> <span class="n">file2</span><span class="p">,</span> <span class="n">dir1</span>
</pre></div>
</div>
</div>
<div class="section" id="listing-the-current-view">
<h4>1.7.4.3 Listing the current view<a class="headerlink" href="#listing-the-current-view" title="Ссылка на этот заголовок">¶</a></h4>
<p>To see the current view, use the <code class="docutils literal notranslate"><span class="pre">view</span></code> command without arguments:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span>
</pre></div>
</div>
<p>If no view is current, a message will be output saying <code class="docutils literal notranslate"><span class="pre">No</span> <span class="pre">current</span> <span class="pre">view.</span></code>.
Otherwise the name and content of the current view will be displayed
like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="s1">'my'</span> <span class="n">view</span> <span class="ow">is</span><span class="p">:</span> <span class="n">a</span><span class="p">,</span> <span class="n">b</span><span class="p">,</span> <span class="n">c</span>
</pre></div>
</div>
</div>
<div class="section" id="switching-between-views">
<h4>1.7.4.4 Switching between views<a class="headerlink" href="#switching-between-views" title="Ссылка на этот заголовок">¶</a></h4>
<p>In most cases, a view has a short life-span: it is created to make a
selected change and is deleted once that change is committed. At other
times, you may wish to create one or more named views and switch
between them.</p>
<p>To define a named view and switch to it:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">name</span> <span class="n">view</span><span class="o">-</span><span class="n">name</span> <span class="n">file1</span> <span class="n">dir1</span> <span class="o">...</span>
</pre></div>
</div>
<p>For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">name</span> <span class="n">doc</span> <span class="n">NEWS</span> <span class="n">doc</span><span class="o">/</span>
<span class="n">Using</span> <span class="n">doc</span> <span class="n">view</span><span class="p">:</span> <span class="n">NEWS</span><span class="p">,</span> <span class="n">doc</span><span class="o">/</span>
</pre></div>
</div>
<p>To list a named view:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">name</span> <span class="n">view</span><span class="o">-</span><span class="n">name</span>
</pre></div>
</div>
<p>To switch to a named view:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">switch</span> <span class="n">view</span><span class="o">-</span><span class="n">name</span>
</pre></div>
</div>
<p>To list all views defined:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="nb">all</span>
</pre></div>
</div>
</div>
<div class="section" id="temporarily-disabling-a-view">
<h4>1.7.4.5 Temporarily disabling a view<a class="headerlink" href="#temporarily-disabling-a-view" title="Ссылка на этот заголовок">¶</a></h4>
<p>To disable the current view without deleting it, you can switch to the
pseudo view called <code class="docutils literal notranslate"><span class="pre">off</span></code>. This can be useful when you need to see the
whole tree for an operation or two (e.g. merge) but want to switch back
to your view after that.</p>
<p>To disable the current view without deleting it:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">switch</span> <span class="n">off</span>
</pre></div>
</div>
<p>After doing the operations you need to, you can switch back to the
view you were using by name. For example, if the previous view used
the default name:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">switch</span> <span class="n">my</span>
</pre></div>
</div>
</div>
<div class="section" id="deleting-views">
<h4>1.7.4.6 Deleting views<a class="headerlink" href="#deleting-views" title="Ссылка на этот заголовок">¶</a></h4>
<p>To delete the current view:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">delete</span>
</pre></div>
</div>
<p>To delete a named view:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">name</span> <span class="n">view</span><span class="o">-</span><span class="n">name</span> <span class="o">--</span><span class="n">delete</span>
</pre></div>
</div>
<p>To delete all views:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">view</span> <span class="o">--</span><span class="n">delete</span> <span class="o">--</span><span class="nb">all</span>
</pre></div>
</div>
</div>
<div class="section" id="things-to-be-aware-of">
<h4>1.7.4.7 Things to be aware of<a class="headerlink" href="#things-to-be-aware-of" title="Ссылка на этот заголовок">¶</a></h4>
<p>Defining a view does not delete the other files in the working
tree - it merely provides a «lens» over the working tree.</p>
<p>Views are stored as working tree metadata. They are not
propagated by branch commands like pull, push and update.</p>
<p>Views are defined in terms of file paths. If you move a
file in a view to a location outside of the view, the view
will no longer track that path. For example, if a view is
defined as <code class="docutils literal notranslate"><span class="pre">doc/</span></code> and <code class="docutils literal notranslate"><span class="pre">doc/NEWS</span></code> gets moved to <code class="docutils literal notranslate"><span class="pre">NEWS</span></code>,
the views stays defined as <code class="docutils literal notranslate"><span class="pre">doc/</span></code> and does not get changed
to <code class="docutils literal notranslate"><span class="pre">doc/</span> <span class="pre">NEWS</span></code>. Likewise, deleting a file in a view does
not remove the file from that view.</p>
<p>The commands that use the current view are:</p>
<ul class="simple">
<li>status</li>
<li>diff</li>
<li>commit</li>
<li>add</li>
<li>remove</li>
<li>revert</li>
<li>mv</li>
<li>ls.</li>
</ul>
<p>Commands that operate on the full tree but only report changes
inside the current view are:</p>
<ul class="simple">
<li>pull</li>
<li>update</li>
<li>merge.</li>
</ul>
<p>Many commands currently ignore the current view. Over time,
some of these commands may be added to the lists above as
the need arises. By design, some commands will most likely
always ignore the current view because showing the whole
picture is the better thing to do. Commands in this group
include:</p>
<ul class="simple">
<li>log</li>
<li>info.</li>
</ul>
</div>
</div>
<div class="section" id="using-stacked-branches">
<span id="id48"></span><h3>1.7.5 Использование стека веток<a class="headerlink" href="#using-stacked-branches" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id49">
<h4>1.7.5.1 Что такое ветка в стеке?<a class="headerlink" href="#id49" title="Ссылка на этот заголовок">¶</a></h4>
<p>Ветка в стеке - это ветка которая знает как найти ревизии в другой ветке. Ветка
в стеке хранит только уникальные ревизии, которые при этом быстрее создавать и
они более эффективны по занимаемому месту. По этим показателям стек веток похож
на разделяемые репозитории. Конечно стек веток имеет дополнительные
преимущества:</p>
<ul class="simple">
<li>Новая ветка может быть в абсолютно другом месте по сравнению с веткой на
которой она основана как стек.</li>
<li>Удаление ветки в стеке на самом деле удаляет ревизии (а не оставляет их в
разделяемом репозитории).</li>
<li>Стек веток более безопасен чем разделяемые репозитории, т.к. репозиторий на
котором основан стек может иметь доступ только для чтения для разработчиков
которые фиксируют изменения на ветке в стеке.</li>
</ul>
<p>Эти преимущества делают стек веток идеальным выбором для различных сценариев,
включая экспериментальные ветки и сайты с хостингом кода.</p>
</div>
<div class="section" id="id50">
<h4>1.7.5.2 Создание ветки в стеке<a class="headerlink" href="#id50" title="Ссылка на этот заголовок">¶</a></h4>
<p>Что бы создать ветку в стеке нужно использовать опцию <code class="docutils literal notranslate"><span class="pre">stacked</span></code> для команды
<code class="docutils literal notranslate"><span class="pre">branch</span></code>. Например:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="o">--</span><span class="n">stacked</span> <span class="n">source</span><span class="o">-</span><span class="n">url</span> <span class="n">my</span><span class="o">-</span><span class="nb">dir</span>
</pre></div>
</div>
<p>Здесь мы создадим <code class="docutils literal notranslate"><span class="pre">my-dir</span></code> как ветку в стеке без локальных ревизий. Если
определено открытая ветка связанная с <code class="docutils literal notranslate"><span class="pre">source-url</span></code> будет использована как
<em>основа стека</em>. Иначе <code class="docutils literal notranslate"><span class="pre">source-url</span></code> будет <em>основой стека</em>.</p>
</div>
<div class="section" id="id51">
<h4>1.7.5.3 Создание рабочего каталога в стеке<a class="headerlink" href="#id51" title="Ссылка на этот заголовок">¶</a></h4>
<p>Поддержка прямого создания рабочего каталога в стеке скоро ожидается. Пока
для этого требуется два шага:</p>
<ol class="arabic simple">
<li>Создать ветку в стеке, как описано выше.</li>
<li>Конвертировать ветку в рабочий каталог используя либо команду
<code class="docutils literal notranslate"><span class="pre">reconfigure</span></code>, либо команду <code class="docutils literal notranslate"><span class="pre">bind</span></code>.</li>
</ol>
</div>
<div class="section" id="id52">
<h4>1.7.5.4 Публикация ветки в стеке<a class="headerlink" href="#id52" title="Ссылка на этот заголовок">¶</a></h4>
<p>Многие изменения в большинстве проектов создаются на основе готовых веток,
таких как <em>основная линия разработки</em>, или <em>текущая стабильная</em>. Создание новой
ветки в стеке основанной на таких ветках легко сделать с использованием команды
<code class="docutils literal notranslate"><span class="pre">push</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">push</span> <span class="o">--</span><span class="n">stacked</span><span class="o">-</span><span class="n">on</span> <span class="n">reference</span><span class="o">-</span><span class="n">url</span> <span class="n">my</span><span class="o">-</span><span class="n">url</span>
</pre></div>
</div>
<p>Эта команда создаст новую ветку <code class="docutils literal notranslate"><span class="pre">my-url</span></code>, которая будет основана на
<code class="docutils literal notranslate"><span class="pre">reference-url</span></code> и содержать только ревизии из текущей ветки, которых еще нет
на ветке <code class="docutils literal notranslate"><span class="pre">reference-url</span></code>.</p>
<p>Если локальная ветка была создана как ветка в стеке то мы можем использовать
опцию <code class="docutils literal notranslate"><span class="pre">--stacked</span></code> для команды <code class="docutils literal notranslate"><span class="pre">push</span></code> и тогда ветка на которой будет основан
стек будет задана неявно. Например:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="o">--</span><span class="n">stacked</span> <span class="n">source</span><span class="o">-</span><span class="n">url</span> <span class="n">my</span><span class="o">-</span><span class="nb">dir</span>
<span class="n">cd</span> <span class="n">my</span><span class="o">-</span><span class="nb">dir</span>
<span class="p">(</span><span class="n">меняем</span><span class="p">,</span> <span class="n">меняем</span><span class="p">,</span> <span class="n">меняем</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"исправление ошибки"</span>
<span class="n">bzr</span> <span class="n">push</span> <span class="o">--</span><span class="n">stacked</span>
</pre></div>
</div>
</div>
<div class="section" id="id53">
<h4>1.7.5.5 Ограничения веток в стеке<a class="headerlink" href="#id53" title="Ссылка на этот заголовок">¶</a></h4>
<p>Важная вещь которую надо запомнить в отношении веток в стеке - ветка на которой
основан стек должна быть доступна практически для всех операций. Конечно это не
проблема если обе ветки локальные, или находятся на одном сервере.</p>
</div>
</div>
<div class="section" id="running-a-smart-server">
<h3>1.7.6 Running a smart server<a class="headerlink" href="#running-a-smart-server" title="Ссылка на этот заголовок">¶</a></h3>
<p>Bazaar does not require a specialised server because it operates over HTTP, FTP
or SFTP. There is an optional smart server that can be invoked over SSH, from
inetd, or in a dedicated mode.</p>
<div class="section" id="dumb-servers">
<h4>1.7.6.1 Dumb servers<a class="headerlink" href="#dumb-servers" title="Ссылка на этот заголовок">¶</a></h4>
<p>We describe HTTP, FTP, SFTP and HTTP-WebDAV as «dumb» servers because they do
not offer any assistance to Bazaar. If you make a Bazaar repository available
over any of these protocols, Bazaar will allow you to read it remotely. Just
enter the URL to the branch in the Bazaar command you are running.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">bazaar</span><span class="o">.</span><span class="n">launchpad</span><span class="o">.</span><span class="n">net</span><span class="o">/~</span><span class="n">bzr</span><span class="o">-</span><span class="n">pqm</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">bzr</span><span class="o">.</span><span class="n">dev</span>
</pre></div>
</div>
<p>Bazaar supports writing over FTP, SFTP and (via a plugin) over HTTP-WebDAV.</p>
</div>
<div class="section" id="high-performance-smart-server">
<h4>1.7.6.2 High-performance smart server<a class="headerlink" href="#high-performance-smart-server" title="Ссылка на этот заголовок">¶</a></h4>
<p>The high-performance smart server (hpss) performs certain operations much faster
than dumb servers are capable of. In future releases, the range of operations
that are improved by using the smart server will increase as we continue to
tune performance.</p>
<p>To maintain the highest security possible, the current
smart server provides read-only access by default. To
enable read-write access, run it with <code class="docutils literal notranslate"><span class="pre">--allow-writes</span></code>. When using
the SSH access method, bzr automatically runs with the
<code class="docutils literal notranslate"><span class="pre">--allow-writes</span></code> option.</p>
<p>The alternative ways of configuring a smart server are explained below.</p>
<div class="section" id="ssh">
<h5>1.7.6.2.1 SSH<a class="headerlink" href="#ssh" title="Ссылка на этот заголовок">¶</a></h5>
<p>Using Bazaar over SSH requires no special configuration on the server; so long
as Bazaar is installed on the server you can use <code class="docutils literal notranslate"><span class="pre">bzr+ssh</span></code> URLs, e.g.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">path</span><span class="o">/</span><span class="n">to</span><span class="o">/</span><span class="n">branch</span>
</pre></div>
</div>
<p>If <cite>bzr</cite> is not installed system-wide on the server you may need to explicitly
tell the local <cite>bzr</cite> where to find the remote <cite>bzr</cite>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">BZR_REMOTE_PATH</span><span class="o">=~/</span><span class="nb">bin</span><span class="o">/</span><span class="n">bzr</span> <span class="n">bzr</span> <span class="n">log</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">path</span><span class="o">/</span><span class="n">to</span><span class="o">/</span><span class="n">branch</span>
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">BZR_REMOTE_PATH</span></code> environment variable adjusts how <cite>bzr</cite> will be
invoked on the remote system. By default, just <cite>bzr</cite> will be invoked,
which requires the <cite>bzr</cite> executable to be on the default search path. You can
also set this permanently per-location in <code class="docutils literal notranslate"><span class="pre">locations.conf</span></code>.</p>
<p>Like SFTP, paths starting with <code class="docutils literal notranslate"><span class="pre">~</span></code> are relative to your home directory, e.g.
<code class="docutils literal notranslate"><span class="pre">bzr+ssh://example.com/~/code/proj</span></code>. Additionally, paths starting with
<code class="docutils literal notranslate"><span class="pre">~user</span></code> will be relative to that user’s home directory.</p>
</div>
<div class="section" id="inetd">
<h5>1.7.6.2.2 inetd<a class="headerlink" href="#inetd" title="Ссылка на этот заголовок">¶</a></h5>
<p>This example shows how to run <cite>bzr</cite> with a dedicated user <cite>bzruser</cite>
for a shared repository in <code class="docutils literal notranslate"><span class="pre">/srv/bzr/repo</span></code> which has a branch at
<code class="docutils literal notranslate"><span class="pre">/srv/bzr/repo/branchname</span></code>.</p>
<p>Running a Bazaar server from inetd requires an inetd.conf entry:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="mi">4155</span> <span class="n">stream</span> <span class="n">TCP</span> <span class="n">nowait</span> <span class="n">bzruser</span> <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="nb">bin</span><span class="o">/</span><span class="n">bzr</span> <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="nb">bin</span><span class="o">/</span><span class="n">bzr</span> <span class="n">serve</span> <span class="o">--</span><span class="n">inet</span> <span class="o">--</span><span class="n">directory</span><span class="o">=/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">repo</span>
</pre></div>
</div>
<p>When running client commands, the URL you supply is a <cite>bzr://</cite> URL relative to
the <code class="docutils literal notranslate"><span class="pre">--directory</span></code> option given in inetd.conf:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">bzr</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">branchname</span>
</pre></div>
</div>
<p>If possible, paths starting with <code class="docutils literal notranslate"><span class="pre">~</span></code> and <code class="docutils literal notranslate"><span class="pre">~user</span></code> will be expanded as for
<code class="docutils literal notranslate"><span class="pre">bzr+ssh</span></code>. Home directories outside the <code class="docutils literal notranslate"><span class="pre">--directory</span></code> specified to <code class="docutils literal notranslate"><span class="pre">bzr</span>
<span class="pre">serve</span></code> will not be accessible.</p>
</div>
<div class="section" id="dedicated">
<h5>1.7.6.2.3 Dedicated<a class="headerlink" href="#dedicated" title="Ссылка на этот заголовок">¶</a></h5>
<p>This mode has the same path and URL behaviour as the inetd mode. To
run as a specific user, you should use <code class="docutils literal notranslate"><span class="pre">su</span></code> or login as that user.</p>
<p>This example runs bzr on its official port number of <cite>4155</cite> and listens on all
interfaces. This allows connections from anywhere in the world that can reach
your machine on port <cite>4155</cite>.</p>
<p>server:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">serve</span> <span class="o">--</span><span class="n">directory</span><span class="o">=/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">repo</span>
</pre></div>
</div>
<p>client:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">bzr</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">branchname</span>
</pre></div>
</div>
<p>This example runs <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">serve</span></code> on <cite>localhost</cite> port <cite>1234</cite>.</p>
<p>server:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">serve</span> <span class="o">--</span><span class="n">listen</span><span class="o">=</span><span class="n">localhost</span> <span class="o">--</span><span class="n">port</span><span class="o">=</span><span class="mi">1234</span> <span class="o">--</span><span class="n">directory</span><span class="o">=/</span><span class="n">srv</span><span class="o">/</span><span class="n">bzr</span><span class="o">/</span><span class="n">repo</span>
</pre></div>
</div>
<p>client:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">bzr</span><span class="p">:</span><span class="o">//</span><span class="n">localhost</span><span class="p">:</span><span class="mi">1234</span><span class="o">/</span><span class="n">branchname</span>
</pre></div>
</div>
</div>
</div>
</div>
<div class="section" id="using-hooks">
<h3>1.7.7 Using hooks<a class="headerlink" href="#using-hooks" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="what-is-a-hook">
<h4>1.7.7.1 What is a hook?<a class="headerlink" href="#what-is-a-hook" title="Ссылка на этот заголовок">¶</a></h4>
<p>One way to customize Bazaar’s behaviour is with <em>hooks</em>. Hooks allow you to
perform actions before or after certain Bazaar operations. The operations
include <code class="docutils literal notranslate"><span class="pre">commit</span></code>, <code class="docutils literal notranslate"><span class="pre">push</span></code>, <code class="docutils literal notranslate"><span class="pre">pull</span></code>, and <code class="docutils literal notranslate"><span class="pre">uncommit</span></code>.
For a complete list of hooks and their parameters, see <a class="reference external" href="../user-reference/index.html#hooks">Hooks</a> in the User Reference.</p>
<p>Most hooks are run on the client, but a few are run on the server. (Also
see the <a class="reference external" href="http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html">push-and-update plugin</a> that handles one special case of
server-side operations.)</p>
</div>
<div class="section" id="id54">
<h4>1.7.7.2 Using hooks<a class="headerlink" href="#id54" title="Ссылка на этот заголовок">¶</a></h4>
<p>To use a hook, you should <a class="reference external" href="http://doc.bazaar.canonical.com/plugins/en/plugin-development.html">write a plugin</a>. Instead of
creating a new command, this plugin will define and install the hook. Here’s
an example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">bzrlib</span> <span class="k">import</span> <span class="n">branch</span>
<span class="k">def</span> <span class="nf">post_push_hook</span><span class="p">(</span><span class="n">push_result</span><span class="p">):</span>
<span class="nb">print</span> <span class="s2">"The new revno is </span><span class="si">%d</span><span class="s2">"</span> <span class="o">%</span> <span class="n">push_result</span><span class="o">.</span><span class="n">new_revno</span>
<span class="n">branch</span><span class="o">.</span><span class="n">Branch</span><span class="o">.</span><span class="n">hooks</span><span class="o">.</span><span class="n">install_named_hook</span><span class="p">(</span><span class="s1">'post_push'</span><span class="p">,</span> <span class="n">post_push_hook</span><span class="p">,</span>
<span class="s1">'My post_push hook'</span><span class="p">)</span>
</pre></div>
</div>
<p>To use this example, create a file named <code class="docutils literal notranslate"><span class="pre">push_hook.py</span></code>, and stick it in
<code class="docutils literal notranslate"><span class="pre">plugins</span></code> subdirectory of your configuration directory. (If you have never
installed any plugins, you may need to create the <code class="docutils literal notranslate"><span class="pre">plugins</span></code> directory).</p>
<p>That’s it! The next time you push, it should show «The new revno is…».
Of course, hooks can be much more elaborate than this, because you have the
full power of Python at your disposal. Now that you know how to use hooks,
what you do with them is up to you.</p>
<p>The plugin code does two things. First, it defines a function that will be
run after <code class="docutils literal notranslate"><span class="pre">push</span></code> completes. (It could instead use an instance method or
a callable object.) All push hooks take a single argument, the
<code class="docutils literal notranslate"><span class="pre">push_result</span></code>.</p>
<p>Second, the plugin installs the hook. The first argument <code class="docutils literal notranslate"><span class="pre">'post_push'</span></code>
identifies where to install the hook. The second argument is the hook
itself. The third argument is a name <code class="docutils literal notranslate"><span class="pre">'My</span> <span class="pre">post_push</span> <span class="pre">hook'</span></code>, which can be
used in progress messages and error messages.</p>
<p>To reduce the start-up time of Bazaar it is also possible to «lazily» install hooks,
using the <code class="docutils literal notranslate"><span class="pre">bzrlib.hooks.install_lazy_named_hook</span></code> function. This removes the need
to load the module that contains the hook point just to install the hook. Here’s lazy
version of the example above:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">bzrlib</span> <span class="k">import</span> <span class="n">hooks</span>
<span class="k">def</span> <span class="nf">post_push_hook</span><span class="p">(</span><span class="n">push_result</span><span class="p">):</span>
<span class="nb">print</span> <span class="s2">"The new revno is </span><span class="si">%d</span><span class="s2">"</span> <span class="o">%</span> <span class="n">push_result</span><span class="o">.</span><span class="n">new_revno</span>
<span class="n">hooks</span><span class="o">.</span><span class="n">install_lazy_named_hook</span><span class="p">(</span><span class="s1">'bzrlib.branch'</span><span class="p">,</span> <span class="s1">'Branch.hooks'</span><span class="p">,</span>
<span class="s1">'post_push'</span><span class="p">,</span> <span class="n">post_push_hook</span><span class="p">,</span> <span class="s1">'My post_push hook'</span><span class="p">)</span>
</pre></div>
</div>
</div>
<div class="section" id="debugging-hooks">
<h4>1.7.7.3 Debugging hooks<a class="headerlink" href="#debugging-hooks" title="Ссылка на этот заголовок">¶</a></h4>
<p>To get a list of installed hooks (and available hook points), use the hidden
<code class="docutils literal notranslate"><span class="pre">hooks</span></code> command:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">hooks</span>
</pre></div>
</div>
</div>
<div class="section" id="example-a-merge-plugin">
<h4>1.7.7.4 Example: a merge plugin<a class="headerlink" href="#example-a-merge-plugin" title="Ссылка на этот заголовок">¶</a></h4>
<p>Here’s a complete plugin that demonstrates the <code class="docutils literal notranslate"><span class="pre">Merger.merge_file_content</span></code>
hook. It installs a hook that forces any merge of a file named <code class="docutils literal notranslate"><span class="pre">*.xml</span></code>
to be a conflict, even if Bazaar thinks it can merge it cleanly.</p>
<p><code class="docutils literal notranslate"><span class="pre">merge_xml.py</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="sd">"""Custom 'merge' logic for *.xml files.</span>
<span class="sd">Always conflicts if both branches have changed the file.</span>
<span class="sd">"""</span>
<span class="kn">from</span> <span class="nn">bzrlib.merge</span> <span class="k">import</span> <span class="n">PerFileMerger</span><span class="p">,</span> <span class="n">Merger</span>
<span class="k">def</span> <span class="nf">merge_xml_files_hook</span><span class="p">(</span><span class="n">merger</span><span class="p">):</span>
<span class="sd">"""Hook to merge *.xml files"""</span>
<span class="k">return</span> <span class="n">AlwaysConflictXMLMerger</span><span class="p">(</span><span class="n">merger</span><span class="p">)</span>
<span class="k">class</span> <span class="nc">AlwaysConflictXMLMerger</span><span class="p">(</span><span class="n">PerFileMerger</span><span class="p">):</span>
<span class="k">def</span> <span class="nf">file_matches</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">params</span><span class="p">):</span>
<span class="n">filename</span> <span class="o">=</span> <span class="bp">self</span><span class="o">.</span><span class="n">get_filename</span><span class="p">(</span><span class="n">params</span><span class="p">,</span> <span class="bp">self</span><span class="o">.</span><span class="n">merger</span><span class="o">.</span><span class="n">this_tree</span><span class="p">)</span>
<span class="k">return</span> <span class="n">filename</span><span class="o">.</span><span class="n">endswith</span><span class="p">(</span><span class="s1">'.xml'</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">merge_matching</span><span class="p">(</span><span class="bp">self</span><span class="p">,</span> <span class="n">params</span><span class="p">):</span>
<span class="k">return</span> <span class="s1">'conflicted'</span><span class="p">,</span> <span class="n">params</span><span class="o">.</span><span class="n">this_lines</span>
<span class="n">Merger</span><span class="o">.</span><span class="n">hooks</span><span class="o">.</span><span class="n">install_named_hook</span><span class="p">(</span>
<span class="s1">'merge_file_content'</span><span class="p">,</span> <span class="n">merge_xml_files_hook</span><span class="p">,</span> <span class="s1">'*.xml file merge'</span><span class="p">)</span>
</pre></div>
</div>
<p><code class="docutils literal notranslate"><span class="pre">merge_file_content</span></code> hooks are executed for each file to be merged. For
a more a complex example look at the <code class="docutils literal notranslate"><span class="pre">news_merge</span></code> plugin that’s bundled with
Bazaar in the <code class="docutils literal notranslate"><span class="pre">bzrlib/plugins</span></code> directory.</p>
</div>
</div>
<div class="section" id="exporting-version-information">
<h3>1.7.8 Exporting version information<a class="headerlink" href="#exporting-version-information" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="getting-the-last-revision-number">
<h4>1.7.8.1 Getting the last revision number<a class="headerlink" href="#getting-the-last-revision-number" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you only need the last revision number in your build scripts, you can
use the <code class="docutils literal notranslate"><span class="pre">revno</span></code> command to get that value like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr revno
3104
</pre></div>
</div>
</div>
<div class="section" id="getting-more-version-information">
<h4>1.7.8.2 Getting more version information<a class="headerlink" href="#getting-more-version-information" title="Ссылка на этот заголовок">¶</a></h4>
<p>The <code class="docutils literal notranslate"><span class="pre">version-info</span></code> command can be used to output more information
about the latest version like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr version-info
revision-id: pqm@pqm.ubuntu.com-20071211175118-s94sizduj201hrs5
date: 2007-12-11 17:51:18 +0000
build-date: 2007-12-13 13:14:51 +1000
revno: 3104
branch-nick: bzr.dev
</pre></div>
</div>
<p>You can easily filter that output using operating system tools or
scripts. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr version-info | grep ^date
date: 2007-12-11 17:51:18 +0000
</pre></div>
</div>
<p>The <code class="docutils literal notranslate"><span class="pre">--all</span></code> option will actually dump version information about
every revision if you need that information for more advanced
post-processing.</p>
</div>
<div class="section" id="python-projects">
<h4>1.7.8.3 Python projects<a class="headerlink" href="#python-projects" title="Ссылка на этот заголовок">¶</a></h4>
<p>If using a Makefile to build your project, you can generate the version
information file as simply as:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">library</span><span class="o">/</span><span class="n">_version</span><span class="o">.</span><span class="n">py</span><span class="p">:</span>
<span class="n">bzr</span> <span class="n">version</span><span class="o">-</span><span class="n">info</span> <span class="o">--</span><span class="nb">format</span> <span class="n">python</span> <span class="o">></span> <span class="n">library</span><span class="o">/</span><span class="n">_version</span><span class="o">.</span><span class="n">py</span>
</pre></div>
</div>
<p>This generates a file which contains 3 dictionaries:</p>
<blockquote>
<div><ul class="simple">
<li><cite>version_info</cite>: A dictionary containing the basic information about the
current state.</li>
<li><cite>revisions</cite>: A dictionary listing all of the revisions in the
history of the tree, along with the commit times and commit
message. This defaults to being empty unless <code class="docutils literal notranslate"><span class="pre">--all</span></code> or
<code class="docutils literal notranslate"><span class="pre">--include-history</span></code> is supplied. This is useful if you want to
track what bug fixes, etc, might be included in the released
version. But for many projects it is more information than needed.</li>
<li><cite>file_revisions</cite>: A dictionary listing the last-modified revision
for all files in the project. This can be used similarly to how
<code class="docutils literal notranslate"><span class="pre">$Id$</span></code> keywords are used in CVS-controlled files. The last
modified date can be determined by looking in the <code class="docutils literal notranslate"><span class="pre">revisions</span></code>
map. This is also empty by default, and enabled only by <code class="docutils literal notranslate"><span class="pre">--all</span></code>
or <code class="docutils literal notranslate"><span class="pre">--include-file-revisions</span></code>.</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="getting-version-info-in-other-formats">
<h4>1.7.8.4 Getting version info in other formats<a class="headerlink" href="#getting-version-info-in-other-formats" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar supports a template-based method for getting version information in
arbitrary formats. The <code class="docutils literal notranslate"><span class="pre">--custom</span></code> option to <code class="docutils literal notranslate"><span class="pre">version-info</span></code> can be
used by providing a <code class="docutils literal notranslate"><span class="pre">--template</span></code> argument that contains variables that
will be expanded based on the status of the working tree. For example, to
generate a C header file with a formatted string containing the current
revision number:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">version</span><span class="o">-</span><span class="n">info</span> <span class="o">--</span><span class="n">custom</span> \
<span class="o">--</span><span class="n">template</span><span class="o">=</span><span class="s2">"#define VERSION_INFO </span><span class="se">\"</span><span class="s2">Project 1.2.3 (r</span><span class="si">{revno}</span><span class="s2">)</span><span class="se">\"\n</span><span class="s2">"</span> \
<span class="o">></span> <span class="n">version_info</span><span class="o">.</span><span class="n">h</span>
</pre></div>
</div>
<p>where the <code class="docutils literal notranslate"><span class="pre">{revno}</span></code> will be replaced by the revision number of the
working tree. (If the example above doesn’t work on your OS, try
entering the command all on one line.) For more information on the
variables that can be used in templates, see <a class="reference external" href="../user-reference/index.html#version-info">Version Info</a> in the
Bazaar User Reference.</p>
<p>Predefined formats for dumping version information in specific languages
are currently in development. Please contact us on the mailing list about
your requirements in this area.</p>
</div>
<div class="section" id="check-clean">
<h4>1.7.8.5 Check clean<a class="headerlink" href="#check-clean" title="Ссылка на этот заголовок">¶</a></h4>
<p>Most information about the contents of the project can be cheaply
determined by just reading the revision entry. However, it can be useful
to know if the working tree was completely up-to-date when it was
packaged, or if there was a local modification. By supplying either
<code class="docutils literal notranslate"><span class="pre">--all</span></code> or <code class="docutils literal notranslate"><span class="pre">--check-clean</span></code>, <code class="docutils literal notranslate"><span class="pre">bzr</span></code> will inspect the working tree, and
set the <code class="docutils literal notranslate"><span class="pre">clean</span></code> flag in <code class="docutils literal notranslate"><span class="pre">version_info</span></code>, as well as set entries in
<code class="docutils literal notranslate"><span class="pre">file_revisions</span></code> as <code class="docutils literal notranslate"><span class="pre">modified</span></code> where appropriate.</p>
</div>
</div>
</div>
<div class="section" id="id55">
<h2><a class="toc-backref" href="#id83">1.8 Краткое описание некоторых популярных плагинов</a><a class="headerlink" href="#id55" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="bzrtools">
<h3>1.8.1 BzrTools<a class="headerlink" href="#bzrtools" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="overview">
<h4>1.8.1.1 Overview<a class="headerlink" href="#overview" title="Ссылка на этот заголовок">¶</a></h4>
<p>BzrTools is a collection of useful enhancements to Bazaar.
For installation instructions, see the BzrTools home page:
<a class="reference external" href="http://wiki.bazaar.canonical.com/BzrTools">http://wiki.bazaar.canonical.com/BzrTools</a>.
Here is a sample of the frequently used commands it provides.</p>
</div>
<div class="section" id="shell">
<h4>1.8.1.2 shell<a class="headerlink" href="#shell" title="Ссылка на этот заголовок">¶</a></h4>
<p><code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">shell</span></code> starts up a command interpreter than understands
Bazaar commands natively. This has several advantages:</p>
<blockquote>
<div><ul class="simple">
<li>There’s no need to type <code class="docutils literal notranslate"><span class="pre">bzr</span></code> at the front of every command.</li>
<li>Intelligent auto-completion is provided.</li>
<li>Commands run slightly faster as there’s no need to load Bazaar’s
libraries each time.</li>
</ul>
</div></blockquote>
</div>
<div class="section" id="cdiff">
<h4>1.8.1.3 cdiff<a class="headerlink" href="#cdiff" title="Ссылка на этот заголовок">¶</a></h4>
<p><code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">cdiff</span></code> provides a colored version of <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">diff</span></code> output.
On GNU/Linux, UNIX and OS X, this is often used like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">cdiff</span> <span class="o">|</span> <span class="n">less</span> <span class="o">-</span><span class="n">R</span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="bzr-svn">
<h3>1.8.2 bzr-svn<a class="headerlink" href="#bzr-svn" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id56">
<h4>1.8.2.1 Overview<a class="headerlink" href="#id56" title="Ссылка на этот заголовок">¶</a></h4>
<p>bzr-svn lets developers use Bazaar as their VCS client on projects
still using a central Subversion repository. Access to Subversion
repositories is largely transparent, i.e. you can use most <code class="docutils literal notranslate"><span class="pre">bzr</span></code>
commands directly on Subversion repositories exactly the same
as if you were using <code class="docutils literal notranslate"><span class="pre">bzr</span></code> on native Bazaar branches.</p>
<p>Many bzr-svn users create a local mirror of the central Subversion
trunk, work in local feature branches, and submit their
overall change back to Subversion when it is ready
to go. This lets them gain many of the advantages of distributed
VCS tools without interrupting existing team-wide processes and
tool integration hooks currently built on top of Subversion. Indeed,
this is a common interim step for teams looking to adopt Bazaar but
who are unable to do so yet for timing or non-technical reasons.</p>
<p>For installation instructions, see the bzr-svn home page:
<a class="reference external" href="http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion">http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion</a>.</p>
</div>
<div class="section" id="a-simple-example">
<h4>1.8.2.2 A simple example<a class="headerlink" href="#a-simple-example" title="Ссылка на этот заголовок">¶</a></h4>
<p>Here’s a simple example of how you can use bzr-svn to hack on a
GNOME project like <strong>beagle</strong>. Firstly, setup a local shared repository
for storing your branches in and checkout the trunk:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">beagle</span><span class="o">-</span><span class="n">repo</span>
<span class="n">cd</span> <span class="n">beagle</span><span class="o">-</span><span class="n">repo</span>
<span class="n">bzr</span> <span class="n">checkout</span> <span class="n">svn</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">svn</span><span class="o">.</span><span class="n">gnome</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">svn</span><span class="o">/</span><span class="n">beagle</span><span class="o">/</span><span class="n">trunk</span> <span class="n">beagle</span><span class="o">-</span><span class="n">trunk</span>
</pre></div>
</div>
<p>Next, create a feature branch and hack away:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">beagle</span><span class="o">-</span><span class="n">trunk</span> <span class="n">beagle</span><span class="o">-</span><span class="n">feature1</span>
<span class="n">cd</span> <span class="n">beagle</span><span class="o">-</span><span class="n">feature1</span>
<span class="p">(</span><span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"blah blah blah"</span>
<span class="p">(</span><span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"blah blah blah"</span>
</pre></div>
</div>
<p>When the feature is cooked, refresh your trunk mirror and merge
your change:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">cd</span> <span class="o">../</span><span class="n">beagle</span><span class="o">-</span><span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">update</span>
<span class="n">bzr</span> <span class="n">merge</span> <span class="o">../</span><span class="n">beagle</span><span class="o">-</span><span class="n">feature1</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Complete comment for SVN commit"</span>
</pre></div>
</div>
<p>As your trunk mirror is a checkout, committing to it implicitly
commits to the real Subversion trunk. That’s it!</p>
</div>
<div class="section" id="using-a-central-repository-mirror">
<h4>1.8.2.3 Using a central repository mirror<a class="headerlink" href="#using-a-central-repository-mirror" title="Ссылка на этот заголовок">¶</a></h4>
<p>For large projects, it often makes sense to tweak the recipe given above.
In particular, the initial checkout can get quite slow so you may wish
to import the Subversion repository into a Bazaar one once and for all
for your project, and then branch from that native Bazaar repository
instead. bzr-svn provides the <code class="docutils literal notranslate"><span class="pre">svn-import</span></code> command for doing this
repository-to-repository conversion. Here’s an example of how to use it:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">svn</span><span class="o">-</span><span class="kn">import</span> <span class="nn">svn</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">svn</span><span class="o">.</span><span class="n">gnome</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">svn</span><span class="o">/</span><span class="n">beagle</span>
</pre></div>
</div>
<p>Here’s the recipe from above updated to use a central Bazaar mirror:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">beagle</span><span class="o">-</span><span class="n">repo</span>
<span class="n">cd</span> <span class="n">beagle</span><span class="o">-</span><span class="n">repo</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">bzr</span><span class="o">+</span><span class="n">ssh</span><span class="p">:</span><span class="o">//</span><span class="n">bzr</span><span class="o">.</span><span class="n">gnome</span><span class="o">.</span><span class="n">org</span><span class="o">/</span><span class="n">beagle</span><span class="o">.</span><span class="n">bzr</span><span class="o">/</span><span class="n">trunk</span> <span class="n">beagle</span><span class="o">-</span><span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">beagle</span><span class="o">-</span><span class="n">trunk</span> <span class="n">beagle</span><span class="o">-</span><span class="n">feature1</span>
<span class="n">cd</span> <span class="n">beagle</span><span class="o">-</span><span class="n">feature1</span>
<span class="p">(</span><span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"blah blah blah"</span>
<span class="p">(</span><span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">,</span> <span class="n">hack</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"blah blah blah"</span>
<span class="n">cd</span> <span class="o">../</span><span class="n">beagle</span><span class="o">-</span><span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">pull</span>
<span class="n">bzr</span> <span class="n">merge</span> <span class="o">../</span><span class="n">beagle</span><span class="o">-</span><span class="n">feature1</span>
<span class="n">bzr</span> <span class="n">commit</span> <span class="o">-</span><span class="n">m</span> <span class="s2">"Complete comment for SVN commit"</span>
<span class="n">bzr</span> <span class="n">push</span>
</pre></div>
</div>
<p>In this case, committing to the trunk only commits the merge locally.
To commit back to the master Subversion trunk, an additional command
(<code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">push</span></code>) is required.</p>
<p>Note: You’ll need to give <code class="docutils literal notranslate"><span class="pre">pull</span></code> and <code class="docutils literal notranslate"><span class="pre">push</span></code> the relevant URLs
the first time you use those commands in the trunk branch. After that,
bzr remembers them.</p>
<p>The final piece of the puzzle in this setup is to put scripts in
place to keep the central Bazaar mirror synchronized with the Subversion
one. This can be done by adding a cron job, using a Subversion hook,
or whatever makes sense in your environment.</p>
</div>
<div class="section" id="limitations-of-bzr-svn">
<h4>1.8.2.4 Limitations of bzr-svn<a class="headerlink" href="#limitations-of-bzr-svn" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar and Subversion are different tools with different capabilities
so there will always be some limited interoperability issues.
Here are some examples current as of bzr-svn 0.5.4:</p>
<blockquote>
<div><ul class="simple">
<li>Bazaar doesn’t support versioned properties</li>
<li>Bazaar doesn’t support tracking of file copies.</li>
</ul>
</div></blockquote>
<p>See the bzr-svn web page,
<a class="reference external" href="http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion">http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion</a>,
for the current list of constraints.</p>
</div>
</div>
</div>
<div class="section" id="id57">
<h2><a class="toc-backref" href="#id84">1.9 Интегрируем Bazaar в нашу среду</a><a class="headerlink" href="#id57" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="web-browsing">
<h3>1.9.1 Web browsing<a class="headerlink" href="#web-browsing" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="id58">
<h4>1.9.1.1 Overview<a class="headerlink" href="#id58" title="Ссылка на этот заголовок">¶</a></h4>
<p>There are a range of options available for providing a web view of a
Bazaar repository, the main one being Loggerhead. The homepage of Loggerhead
can be found at <a class="reference external" href="https://launchpad.net/loggerhead">https://launchpad.net/loggerhead</a>.</p>
<p>A list of alternative web viewers including download links can be found on
<a class="reference external" href="http://wiki.bazaar.canonical.com/WebInterface">http://wiki.bazaar.canonical.com/WebInterface</a>.</p>
<p>Note: If your project is hosted or mirrored on Launchpad,
Loggerhead code browsing is provided as part of the service.</p>
</div>
</div>
<div class="section" id="bug-trackers">
<h3>1.9.2 Bug trackers<a class="headerlink" href="#bug-trackers" title="Ссылка на этот заголовок">¶</a></h3>
<p>Bazaar has a facility that allows you to associate a commit with a bug
in the project’s bug tracker. Other tools (or hooks) can then use this
information to generate hyperlinks between the commit and the bug, or to
automatically mark the bug closed in the branches that contain the commit.</p>
<div class="section" id="associating-commits-and-bugs">
<h4>1.9.2.1 Associating commits and bugs<a class="headerlink" href="#associating-commits-and-bugs" title="Ссылка на этот заголовок">¶</a></h4>
<p>When you make a commit, you can associate it with a bug by using the
<code class="docutils literal notranslate"><span class="pre">--fixes</span></code> option of <code class="docutils literal notranslate"><span class="pre">commit</span></code>. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr commit --fixes lp:12345 -m "Properly close the connection"
</pre></div>
</div>
<p>This records metadata in Bazaar linking the commit with bug 12345 in
Launchpad. If you use a different bug tracker, it can be given its own
tracker code (instead of <code class="docutils literal notranslate"><span class="pre">lp</span></code>) and used instead. For details on how
to configure this for Bugzilla, Trac, Roundup and other bug/issue trackers,
refer to <a class="reference external" href="../user-reference/index.html#bug-tracker-settings">Bug Tracker Settings</a> in the Bazaar User Reference.</p>
</div>
<div class="section" id="metadata-recording-vs-bug-tracker-updating">
<h4>1.9.2.2 Metadata recording vs bug tracker updating<a class="headerlink" href="#metadata-recording-vs-bug-tracker-updating" title="Ссылка на этот заголовок">¶</a></h4>
<p>Recording metadata about bugs fixed at commit time is only
one of the features needed for complete bug tracker integration.
As Bazaar is a distributed VCS, users may be offline while committing
so accessing the bug tracker itself at that time may not be possible.
Instead, it is recommended that a hook be installed to update
the bug tracker when changes are pushed to a central location
appropriate for your project’s workflow.</p>
<p>Note: This second processing stage is part of the integration provided
by Launchpad when it scans external or hosted branches.</p>
</div>
<div class="section" id="making-corrections">
<h4>1.9.2.3 Making corrections<a class="headerlink" href="#making-corrections" title="Ссылка на этот заголовок">¶</a></h4>
<p>This method of associating revisions and bugs does have some limitations. The
first is that the association can only be made at commit time. This means that
if you forget to make the association when you commit, or the bug is reported
after you fix it, you generally cannot go back and add the link later.</p>
<p>Related to this is the fact that the association is immutable. If a bug is
marked as fixed by one commit but that revision does not fully solve the
bug, or there is a later regression, you cannot go back and remove the link.</p>
<p>Of course, <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">uncommit</span></code> can always be used to undo the last commit in
order to make it again with the correct options. This is commonly done
to correct a bad commit message and it equally applies to correcting
metadata recorded (via <code class="docutils literal notranslate"><span class="pre">--fixes</span></code> for example) on the last commit.</p>
<p>Note: <code class="docutils literal notranslate"><span class="pre">uncommit</span></code> is best done before incorrect revisions become public.</p>
</div>
</div>
</div>
<div class="section" id="id59">
<h2><a class="toc-backref" href="#id85">1.10 Приложения</a><a class="headerlink" href="#id59" title="Ссылка на этот заголовок">¶</a></h2>
<div class="section" id="id60">
<h3>1.10.1 Определение ревизий<a class="headerlink" href="#id60" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="revision-identifiers-and-ranges">
<h4>1.10.1.1 Revision identifiers and ranges<a class="headerlink" href="#revision-identifiers-and-ranges" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar has a very expressive way to specify a revision or a range of revisions.
To specify a range of revisions, the upper and lower bounds are separated by the
<code class="docutils literal notranslate"><span class="pre">..</span></code> symbol. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r 1..4
</pre></div>
</div>
<p>You can omit one bound like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r 1..
$ bzr log -r ..4
</pre></div>
</div>
<p>Some commands take only one revision, not a range. For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr cat -r 42 foo.c
</pre></div>
</div>
<p>In other cases, a range is required but you want the length of the range to
be one. For commands where this is relevant, the <code class="docutils literal notranslate"><span class="pre">-c</span></code> option is used like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr diff -c 42
</pre></div>
</div>
</div>
<div class="section" id="available-revision-identifiers">
<h4>1.10.1.2 Available revision identifiers<a class="headerlink" href="#available-revision-identifiers" title="Ссылка на этот заголовок">¶</a></h4>
<p>The revision, or the bounds of the range, can be given using
different format specifications as shown below.</p>
<blockquote>
<div><table border="1" class="docutils">
<colgroup>
<col width="38%" />
<col width="62%" />
</colgroup>
<tbody valign="top">
<tr class="row-odd"><td>argument type</td>
<td>description</td>
</tr>
<tr class="row-even"><td><em>number</em></td>
<td>revision number</td>
</tr>
<tr class="row-odd"><td><strong>revno</strong>:<em>number</em></td>
<td>positive revision number</td>
</tr>
<tr class="row-even"><td><strong>last</strong>:<em>number</em></td>
<td>negative revision number</td>
</tr>
<tr class="row-odd"><td><strong>revid</strong>:<em>guid</em></td>
<td>globally unique revision id</td>
</tr>
<tr class="row-even"><td><strong>before</strong>:<em>rev</em></td>
<td>leftmost parent of „“rev“„</td>
</tr>
<tr class="row-odd"><td><strong>date</strong>:<em>value</em></td>
<td>first entry after a given date</td>
</tr>
<tr class="row-even"><td><strong>tag</strong>:<em>value</em></td>
<td>revision matching a given tag</td>
</tr>
<tr class="row-odd"><td><strong>ancestor</strong>:<em>path</em></td>
<td>last merged revision from a branch</td>
</tr>
<tr class="row-even"><td><strong>branch</strong>:<em>path</em></td>
<td>latest revision on another branch</td>
</tr>
<tr class="row-odd"><td><strong>submit</strong>:<em>path</em></td>
<td>common ancestor with submit branch</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>A brief introduction to some of these formats is given below.
For complete details, see <a class="reference external" href="../user-reference/bzr_man.html#revision-identifiers">Revision Identifiers</a> in the
Bazaar User Reference.</p>
<div class="section" id="numbers">
<h5>1.10.1.2.1 Numbers<a class="headerlink" href="#numbers" title="Ссылка на этот заголовок">¶</a></h5>
<p>Positive numbers denote revision numbers in the current branch. Revision
numbers are labelled as «revno» in the output of <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">log</span></code>. To display
the log for the first ten revisions:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r ..10
</pre></div>
</div>
<p>Negative numbers count from the latest revision, -1 is the last committed
revision.</p>
<p>To display the log for the last ten revisions:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r -10..
</pre></div>
</div>
</div>
<div class="section" id="revid">
<h5>1.10.1.2.2 revid<a class="headerlink" href="#revid" title="Ссылка на этот заголовок">¶</a></h5>
<p><strong>revid</strong> allows specifying a an internal revision ID, as shown by <code class="docutils literal notranslate"><span class="pre">bzr</span>
<span class="pre">log</span></code> and some other commands.</p>
<p>For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r revid:Matthieu.Moy@imag.fr-20051026185030-93c7cad63ee570df
</pre></div>
</div>
</div>
<div class="section" id="before">
<h5>1.10.1.2.3 before<a class="headerlink" href="#before" title="Ссылка на этот заголовок">¶</a></h5>
<dl class="docutils">
<dt><strong>before</strong></dt>
<dd>„“rev““ specifies the leftmost parent of „“rev“„, that is the revision
that appears before „“rev““ in the revision history, or the revision that
was current when „“rev““ was committed.</dd>
</dl>
<p>„“rev““ can be any revision specifier and may be chained.</p>
<p>For example:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r before:before:4
...
revno: 2
...
</pre></div>
</div>
</div>
<div class="section" id="date">
<h5>1.10.1.2.4 date<a class="headerlink" href="#date" title="Ссылка на этот заголовок">¶</a></h5>
<dl class="docutils">
<dt><strong>date</strong></dt>
<dd>„“value““ matches the first history entry after a given date, either at
midnight or at a specified time.</dd>
</dl>
<p>Legal values are:</p>
<blockquote>
<div><ul class="simple">
<li><strong>yesterday</strong></li>
<li><strong>today</strong></li>
<li><strong>tomorrow</strong></li>
<li>A <strong>YYYY-MM-DD</strong> format date.</li>
<li>A <strong>YYYY-MM-DD,HH:MM:SS</strong> format date/time, seconds are optional (note the
comma)</li>
</ul>
</div></blockquote>
<p>The proper way of saying «give me all the log entries for today» is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr log -r date:yesterday..date:today
</pre></div>
</div>
</div>
<div class="section" id="ancestor">
<h5>1.10.1.2.5 Ancestor<a class="headerlink" href="#ancestor" title="Ссылка на этот заголовок">¶</a></h5>
<dl class="docutils">
<dt><strong>ancestor</strong>:<em>path</em></dt>
<dd>specifies the common ancestor between the current branch and a
different branch. This is the same ancestor that would be used for
merging purposes.</dd>
</dl>
<p><em>path</em> may be the URL of a remote branch, or the file path to a local branch.</p>
<p>For example, to see what changes were made on a branch since it was forked
off <code class="docutils literal notranslate"><span class="pre">../parent</span></code>:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr diff -r ancestor:../parent
</pre></div>
</div>
</div>
<div class="section" id="branch">
<h5>1.10.1.2.6 Branch<a class="headerlink" href="#branch" title="Ссылка на этот заголовок">¶</a></h5>
<dl class="docutils">
<dt>branch</dt>
<dd><code class="docutils literal notranslate"><span class="pre">path</span></code> specifies the latest revision in another branch.</dd>
</dl>
<p><code class="docutils literal notranslate"><span class="pre">path</span></code> may be the URL of a remote branch, or the file path to a local branch.</p>
<p>For example, to get the differences between this and another branch:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>$ bzr diff -r branch:http://example.com/bzr/foo.dev
</pre></div>
</div>
</div>
</div>
</div>
<div class="section" id="organizing-your-workspace">
<h3>1.10.2 Organizing your workspace<a class="headerlink" href="#organizing-your-workspace" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="common-workspace-layouts">
<h4>1.10.2.1 Common workspace layouts<a class="headerlink" href="#common-workspace-layouts" title="Ссылка на этот заголовок">¶</a></h4>
<p>The best way for a Bazaar user to organize their workspace for a project
depends on numerous factors including:</p>
<ul class="simple">
<li>user role: project owner vs core developer vs casual contributor</li>
<li>workflows: particularly the workflow the project encourages/mandates
for making contributions</li>
<li>size: large projects have different resource requirements to small ones.</li>
</ul>
<p>There are at least 4 common ways of organizing one’s workspace:</p>
<ul class="simple">
<li>lightweight checkout</li>
<li>standalone tree</li>
<li>feature branches</li>
<li>switchable sandbox.</li>
</ul>
<p>A brief description of each layout follows.</p>
</div>
<div class="section" id="lightweight-checkout">
<h4>1.10.2.2 Lightweight checkout<a class="headerlink" href="#lightweight-checkout" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this layout, the working tree is local and the branch is remote.
This is the standard layout used by CVS and Subversion: it’s simple
and well understood.</p>
<p>To set up:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">checkout</span> <span class="o">--</span><span class="n">lightweight</span> <span class="n">URL</span> <span class="n">project</span>
<span class="n">cd</span> <span class="n">project</span>
</pre></div>
</div>
<p>To work:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">(</span><span class="n">make</span> <span class="n">changes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
<span class="p">(</span><span class="n">make</span> <span class="n">changes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
</pre></div>
</div>
<p>Note that each commit implicitly publishes the change to everyone else
working from that branch. However, you need to be up to date with changes
in the remote branch for the commit to succeed. To grab the latest code
and merge it with your changes, if any:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">update</span>
</pre></div>
</div>
</div>
<div class="section" id="standalone-tree">
<h4>1.10.2.3 Standalone tree<a class="headerlink" href="#standalone-tree" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this layout, the working tree & branch are in the one place. Unless
a shared repository exists in a higher level directory, the repository
is located in that same place as well. This is the default layout in
Bazaar and it’s great for small to moderately sized projects.</p>
<p>To set up:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">URL</span> <span class="n">project</span>
<span class="n">cd</span> <span class="n">project</span>
</pre></div>
</div>
<p>To work:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">(</span><span class="n">make</span> <span class="n">changes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
<span class="p">(</span><span class="n">make</span> <span class="n">changes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
</pre></div>
</div>
<p>To publish changes to a central location:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">push</span> <span class="p">[</span><span class="n">URL</span><span class="p">]</span>
</pre></div>
</div>
<p>The URL for push is only required the first time.</p>
<p>If the central location has, in the meantime, received changes from
other users, then you’ll need to merge those changes into your local
branch before you try to push again:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">merge</span>
<span class="p">(</span><span class="n">resolve</span> <span class="n">conflicts</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
</pre></div>
</div>
<p>As an alternative, a checkout can be used. Like a branch, a checkout
has a full copy of the history stored locally but the local branch
is bound to the remote location so that commits are published to
both locations at once.</p>
<p>Note: A checkout is actually smarter than a local commit followed by
a push. In particular, a checkout wil commit to the remote location
first and only commit locally if the remote commit succeeds.</p>
</div>
<div class="section" id="feature-branches">
<h4>1.10.2.4 Feature branches<a class="headerlink" href="#feature-branches" title="Ссылка на этот заголовок">¶</a></h4>
<p>In this layout, there are multiple branches/trees, typically sharing
a repository. One branch is kept as a mirror of «trunk» and each
unit-of-work (i.e. bug-fix or enhancement) gets its own «feature branch».
This layout is ideal for most projects, particularly moderately sized ones.</p>
<p>To set up:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="n">project</span>
<span class="n">cd</span> <span class="n">project</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">URL</span> <span class="n">trunk</span>
</pre></div>
</div>
<p>To start a feature branch:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">trunk</span> <span class="n">featureX</span>
<span class="n">cd</span> <span class="n">featureX</span>
</pre></div>
</div>
<p>To work:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">(</span><span class="n">make</span> <span class="n">changes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
<span class="p">(</span><span class="n">make</span> <span class="n">changes</span><span class="p">)</span>
<span class="n">bzr</span> <span class="n">commit</span>
</pre></div>
</div>
<p>To publish changes to a mailing list for review & approval:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">send</span>
</pre></div>
</div>
<p>To publish changes to a public branch (that can then be registered as
a Launchpad merge request, say):</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">push</span> <span class="p">[</span><span class="n">URL</span><span class="p">]</span>
</pre></div>
</div>
<p>As a variation, the trunk can be created as a checkout. If you have
commit privileges on trunk, that lets you merge into trunk and the
commit of the merge will implicitly publish your change. Alternatively,
if the trunk URL is read-only (e.g. an HTTP address), that prevents
accidental submission this way - ideal if the project workflow uses
an automated gatekeeper like PQM, say.</p>
</div>
<div class="section" id="local-sandbox">
<h4>1.10.2.5 Local sandbox<a class="headerlink" href="#local-sandbox" title="Ссылка на этот заголовок">¶</a></h4>
<p>This layout is very similar to the feature branches layout except that
the feature branches share a single working tree rather than having one
each. This is similar to git’s default layout and it’s useful for projects
with really large trees (> 10000 files say) or for projects with lots of
build artifacts (like .o or .class files).</p>
<p>To set up:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">init</span><span class="o">-</span><span class="n">repo</span> <span class="o">--</span><span class="n">no</span><span class="o">-</span><span class="n">trees</span> <span class="n">project</span>
<span class="n">cd</span> <span class="n">project</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">URL</span> <span class="n">trunk</span>
<span class="n">bzr</span> <span class="n">checkout</span> <span class="o">--</span><span class="n">lightweight</span> <span class="n">trunk</span> <span class="n">sandbox</span>
<span class="n">cd</span> <span class="n">sandbox</span>
</pre></div>
</div>
<p>While you <em>could</em> start making changes in sandbox now, committing while
the sandbox is pointing to the trunk would mean that trunk is no longer
a mirror of the upstream URL (well unless the trunk is a checkout).
Therefore, you usually want to immediately create a feature branch and
switch your sandbox to it like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="o">../</span><span class="n">trunk</span> <span class="o">../</span><span class="n">featureX</span>
<span class="n">bzr</span> <span class="n">switch</span> <span class="o">../</span><span class="n">featureX</span>
</pre></div>
</div>
<p>The processes for making changes and submitting them are otherwise
pretty much the same as those used for feature branches.</p>
</div>
<div class="section" id="advanced-layouts">
<h4>1.10.2.6 Advanced layouts<a class="headerlink" href="#advanced-layouts" title="Ссылка на этот заголовок">¶</a></h4>
<p>If you wish, you can put together your own layout based on how <strong>you</strong> like
things organized. See <a class="reference external" href="shared_repository_layouts.html">Advanced shared repository layouts</a> for examples and inspiration.</p>
</div>
</div>
<div class="section" id="id62">
<h3>1.10.3 Advanced shared repository layouts<a class="headerlink" href="#id62" title="Ссылка на этот заголовок">¶</a></h3>
<p>Bazaar is designed to give you flexibility in how you layout branches inside a shared repository.
This flexibility allows users to tailor Bazaar to their workflow,
but it also leads to questions about what is a «good» layout.
We present some alternatives and give some discussion about the benefits of each.</p>
<p>One key point which should be mentioned is that any good layout should somehow highlight
what branch a «general» user should grab. In SVN this is deemed the «<code class="docutils literal notranslate"><span class="pre">trunk/</span></code>» branch,
and in most of the layouts this naming convention is preserved. Some would call this
«<code class="docutils literal notranslate"><span class="pre">mainline</span></code>» or «<code class="docutils literal notranslate"><span class="pre">dev</span></code>», and people from CVS often refer to this as «<code class="docutils literal notranslate"><span class="pre">HEAD</span></code>».</p>
<div class="section" id="svn-style-trunk-branches">
<h4>1.10.3.1 »SVN-Style» (<code class="docutils literal notranslate"><span class="pre">trunk/</span></code>, <code class="docutils literal notranslate"><span class="pre">branches/</span></code>)<a class="headerlink" href="#svn-style-trunk-branches" title="Ссылка на этот заголовок">¶</a></h4>
<p>Most people coming from SVN will be familiar with their «standard» project layout.
Which is to layout the repository as:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">repository</span><span class="o">/</span> <span class="c1"># Overall repository</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># The mainline of development</span>
<span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># A container directory</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">foo</span><span class="o">/</span> <span class="c1"># Branch for developing feature foo</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">+-</span> <span class="n">tags</span><span class="o">/</span> <span class="c1"># Container directory</span>
<span class="o">+-</span> <span class="n">release</span><span class="o">-</span><span class="n">X</span> <span class="c1"># A branch specific to mark a given release version</span>
<span class="o">...</span>
</pre></div>
</div>
<p>With Bazaar, that is a perfectly reasonable layout.
It has the benefit of being familiar to people coming from SVN,
and making it clear where the development focus is.</p>
<p>When you have multiple projects in the same repository,
the SVN layout is a little unclear what to do.</p>
<div class="section" id="project-trunk">
<h5>1.10.3.1.1 <code class="docutils literal notranslate"><span class="pre">project/trunk</span></code><a class="headerlink" href="#project-trunk" title="Ссылка на этот заголовок">¶</a></h5>
<p>The preferred method for SVN seems to be to give each project a top level directory for a layout like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">repository</span><span class="o">/</span> <span class="c1"># Overall repository</span>
<span class="o">+-</span> <span class="n">project1</span><span class="o">/</span> <span class="c1"># A container directory</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># The mainline of development of project1</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># A container directory</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">foo</span><span class="o">/</span> <span class="c1"># Branch for developing feature foo of project1</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">|</span>
<span class="o">+-</span> <span class="n">project2</span><span class="o">/</span> <span class="c1"># Container for project2</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># Mainline for project2</span>
<span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># Container for project2 branches</span>
</pre></div>
</div>
<p>This also works with Bazaar.
However, with Bazaar repositories are cheap to create
(a simple <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">init-repo</span></code> away), and their primary benefit is when the
branches share a common ancestry.</p>
<p>So the preferred way for Bazaar would be:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">project1</span><span class="o">/</span> <span class="c1"># A repository for project1</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># The mainline of development of project1</span>
<span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># A container directory</span>
<span class="o">+-</span> <span class="n">foo</span><span class="o">/</span> <span class="c1"># Branch for developing feature foo of project1</span>
<span class="o">...</span>
<span class="n">project2</span><span class="o">/</span> <span class="c1"># A repository for project2</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># Mainline for project2</span>
<span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># Container for project2 branches</span>
</pre></div>
</div>
</div>
<div class="section" id="trunk-project">
<h5>1.10.3.1.2 <code class="docutils literal notranslate"><span class="pre">trunk/project</span></code><a class="headerlink" href="#trunk-project" title="Ссылка на этот заголовок">¶</a></h5>
<p>There are also a few projects who use this layout in SVN:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">repository</span><span class="o">/</span> <span class="c1"># Overall repository</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># A container directory</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project1</span> <span class="c1"># Mainline for project 1</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project2</span> <span class="c1"># Mainline for project 2</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">|</span>
<span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># Container</span>
<span class="o">+-</span> <span class="n">project1</span><span class="o">/</span> <span class="c1"># Container (?)</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">foo</span> <span class="c1"># Branch 'foo' of project1</span>
<span class="o">+-</span> <span class="n">project2</span><span class="o">/</span>
<span class="o">+-</span> <span class="n">bar</span> <span class="c1"># Branch 'bar' of project2</span>
</pre></div>
</div>
<p>A slight variant is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">repository</span><span class="o">/</span> <span class="c1"># Overall repository</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># A container directory</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project1</span> <span class="c1"># Mainline for project 1</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project2</span> <span class="c1"># Mainline for project 2</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">|</span>
<span class="o">+-</span> <span class="n">branches</span><span class="o">/</span> <span class="c1"># Container</span>
<span class="o">+-</span> <span class="n">project1</span><span class="o">-</span><span class="n">foo</span><span class="o">/</span> <span class="c1"># Branch 'foo' of project1</span>
<span class="o">+-</span> <span class="n">project2</span><span class="o">-</span><span class="n">bar</span><span class="o">/</span> <span class="c1"># Branch 'bar' of project2</span>
</pre></div>
</div>
<p>I believe the reason for this in SVN, is so that someone
can checkout all of «<code class="docutils literal notranslate"><span class="pre">trunk/</span></code>» and get the all the mainlines for all projects.</p>
<p>This layout can be used for Bazaar, but it is not generally recommended.</p>
<blockquote>
<div><ol class="arabic simple">
<li><code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">branch/checkout/get</span></code> is a single branch at a time.
So you don’t get the benefit of getting all mainlines with a single command. <a class="footnote-reference" href="#id64" id="id63">[1]</a></li>
<li>It is less obvious of whether <code class="docutils literal notranslate"><span class="pre">repository/trunk/foo</span></code> is the <code class="docutils literal notranslate"><span class="pre">trunk</span></code> of project
<code class="docutils literal notranslate"><span class="pre">foo</span></code> or it is just the <code class="docutils literal notranslate"><span class="pre">foo</span></code> directory in the <code class="docutils literal notranslate"><span class="pre">trunk</span></code> branch.
Some of this confusion is due to SVN, because it uses the same «namespace»
for files in a project that it uses for branches of a project.
In Bazaar, there is a clear distinction of what files make up a project, versus
the location of the Branch. (After all, there is only one <code class="docutils literal notranslate"><span class="pre">.bzr/</span></code> directory per branch,
versus many <code class="docutils literal notranslate"><span class="pre">.svn/</span></code> directories in the checkout).</li>
</ol>
</div></blockquote>
<table class="docutils footnote" frame="void" id="id64" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id63">[1]</a></td><td>Note: <a class="reference external" href="http://wiki.bazaar.canonical.com/NestedTrees">NestedTreeSupport</a> can provide a way to create «meta-projects» which
aggregate multiple projects regardless of the repository layout.
Letting you <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">checkout</span></code> one project, and have it grab all the necessary
sub-projects.</td></tr>
</tbody>
</table>
</div>
</div>
<div class="section" id="nested-style-project-branch-sub-branch">
<h4>1.10.3.2 Nested Style (<code class="docutils literal notranslate"><span class="pre">project/branch/sub-branch/</span></code>)<a class="headerlink" href="#nested-style-project-branch-sub-branch" title="Ссылка на этот заголовок">¶</a></h4>
<p>Another style with Bazaar, which is not generally possible in SVN
is to have branches nested within each-other.
This is possible because Bazaar supports (and recommends) creating repositories
with no working trees (<code class="docutils literal notranslate"><span class="pre">--no-trees</span></code>).
With a <code class="docutils literal notranslate"><span class="pre">--no-trees</span></code> repository, because the working files are not intermixed with
your branch locations, you are free to put a branch in whatever namespace you want.</p>
<p>One possibility is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">project</span><span class="o">/</span> <span class="c1"># The overall repository, *and* the project's mainline branch</span>
<span class="o">+</span> <span class="n">joe</span><span class="o">/</span> <span class="c1"># Developer Joe's primary branch of development</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">feature1</span><span class="o">/</span> <span class="c1"># Developer Joe's feature1 development branch</span>
<span class="o">|</span> <span class="o">|</span> <span class="o">+-</span> <span class="n">broken</span><span class="o">/</span> <span class="c1"># A staging branch for Joe to develop feature1</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">feature2</span><span class="o">/</span> <span class="c1"># Joe's feature2 development branch</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">+</span> <span class="n">barry</span><span class="o">/</span> <span class="c1"># Barry's development branch</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">+</span> <span class="n">releases</span><span class="o">/</span>
<span class="o">+-</span> <span class="mf">1.0</span><span class="o">/</span>
<span class="o">+-</span> <span class="mf">1.1</span><span class="o">.</span><span class="mi">1</span><span class="o">/</span>
</pre></div>
</div>
<p>The idea with this layout is that you are creating a hierarchical layout for branches.
Where changes generally flow upwards in the namespace. It also gives people a little
corner of the namespace to work on their stuff.
One nice feature of this layout, is it makes branching «cheaper» because it gives you
a place to put all the mini branches without cluttering up the global <code class="docutils literal notranslate"><span class="pre">branches/</span></code> namespace.</p>
<p>The other power of this is that you don’t have to repeat yourself when specifying more detail in the
branch name.</p>
<p>For example compare:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">repository</span><span class="o">/</span><span class="n">project</span><span class="o">/</span><span class="n">branches</span><span class="o">/</span><span class="n">joe</span><span class="o">-</span><span class="n">feature</span><span class="o">-</span><span class="n">foo</span><span class="o">-</span><span class="n">bugfix</span><span class="o">-</span><span class="mi">10</span><span class="o">/</span>
</pre></div>
</div>
<p>Versus:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">branch</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">project</span><span class="o">/</span><span class="n">joe</span><span class="o">/</span><span class="n">foo</span><span class="o">/</span><span class="n">bugfix</span><span class="o">-</span><span class="mi">10</span>
</pre></div>
</div>
<p>Also, if you list the <code class="docutils literal notranslate"><span class="pre">repository/project/branches/</span></code> directory you might see something like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">barry</span><span class="o">-</span><span class="n">feature</span><span class="o">-</span><span class="n">bar</span><span class="o">/</span>
<span class="n">barry</span><span class="o">-</span><span class="n">bugfix</span><span class="o">-</span><span class="mi">10</span><span class="o">/</span>
<span class="n">barry</span><span class="o">-</span><span class="n">bugfix</span><span class="o">-</span><span class="mi">12</span><span class="o">/</span>
<span class="n">joe</span><span class="o">-</span><span class="n">bugfix</span><span class="o">-</span><span class="mi">10</span><span class="o">/</span>
<span class="n">joe</span><span class="o">-</span><span class="n">bugfix</span><span class="o">-</span><span class="mi">13</span><span class="o">/</span>
<span class="n">joe</span><span class="o">-</span><span class="n">frizban</span><span class="o">/</span>
</pre></div>
</div>
<p>Versus having these broken out by developer.
If the number of branches are small, <code class="docutils literal notranslate"><span class="pre">branches/</span></code> has the nice advantage
of being able to see all branches in a single view.
If the number of branches is large, <code class="docutils literal notranslate"><span class="pre">branches/</span></code> has the distinct disadvantage
of seeing all the branches in a single view (it becomes difficult to find the
branch you are interested in, when there are 100 branches to look through).</p>
<p>Nested branching seems to scale better to larger number of branches.
However, each individual branch is less discoverable.
(eg. «Is Joe working on bugfix 10 in his feature foo branch, or his feature bar branch?»)</p>
<p>One other small advantage is that you can do something like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span> <span class="n">bzr</span> <span class="n">branch</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">project</span><span class="o">/</span><span class="n">release</span><span class="o">/</span><span class="mi">1</span><span class="o">/</span><span class="mi">1</span><span class="o">/</span><span class="mi">1</span>
<span class="ow">or</span>
<span class="n">bzr</span> <span class="n">branch</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">host</span><span class="o">/</span><span class="n">project</span><span class="o">/</span><span class="n">release</span><span class="o">/</span><span class="mi">1</span><span class="o">/</span><span class="mi">1</span><span class="o">/</span><span class="mi">2</span>
</pre></div>
</div>
<p>To indicate release 1.1.1 and 1.1.2. This again depends on how many releases you have
and whether the gain of splitting things up outweighs the ability to see more at a glance.</p>
</div>
<div class="section" id="sorted-by-status-dev-merged-experimental">
<h4>1.10.3.3 Sorted by Status (<code class="docutils literal notranslate"><span class="pre">dev/</span></code>, <code class="docutils literal notranslate"><span class="pre">merged/</span></code>, <code class="docutils literal notranslate"><span class="pre">experimental/</span></code>)<a class="headerlink" href="#sorted-by-status-dev-merged-experimental" title="Ссылка на этот заголовок">¶</a></h4>
<p>One other way to break up branches is to sort them by their current status.
So you would end up with a layout something like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">project</span><span class="o">/</span> <span class="c1"># Overall layout</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># The development focus branch</span>
<span class="o">+-</span> <span class="n">dev</span><span class="o">/</span> <span class="c1"># Container directory for in-progress work</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">joe</span><span class="o">-</span><span class="n">feature1</span> <span class="c1"># Joe's current feature-1 branch</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">barry</span><span class="o">-</span><span class="n">bugfix10</span> <span class="c1"># Barry's work for bugfix 10</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">+-</span> <span class="n">merged</span><span class="o">/</span> <span class="c1"># Container indicating these branches have been merged</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">bugfix</span><span class="o">-</span><span class="mi">12</span> <span class="c1"># Bugfix which has already been merged.</span>
<span class="o">+-</span> <span class="n">abandonded</span><span class="o">/</span> <span class="c1"># Branches which are considered 'dead-end'</span>
</pre></div>
</div>
<p>This has a couple benefits and drawbacks.
It lets you see what branches are actively being developed on, which is usually
only a small number, versus the total number of branches ever created.
Old branches are not lost (versus deleting them), but they are «filed away»,
such that the more likely you are to want a branch the easier it is to find.
(Conversely, older branches are likely to be harder to find).</p>
<p>The biggest disadvantage with this layout, is that branches move around.
Which means that if someone is following the <code class="docutils literal notranslate"><span class="pre">project/dev/new-feature</span></code> branch,
when it gets merged into <code class="docutils literal notranslate"><span class="pre">trunk/</span></code> suddenly <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">pull</span></code> doesn’t mirror the branch
for them anymore because the branch is now at <code class="docutils literal notranslate"><span class="pre">project/merged/new-feature</span></code>.
There are a couple ways around this. One is to use HTTP redirects to point people
requesting the old branch to the new branch. <code class="docutils literal notranslate"><span class="pre">bzr</span></code> >= 0.15 will let users know
that <code class="docutils literal notranslate"><span class="pre">http://old/path</span> <span class="pre">redirects</span> <span class="pre">to</span> <span class="pre">http://new/path</span></code>. However, this doesn’t help
if people are accessing a branch through methods other than HTTP (SFTP, local filesystem, etc).</p>
<p>It would also be possible to use a symlink for temporary redirecting (as long as the symlink
is within the repository it should cause little trouble). However eventually you want to
remove the symlink, or you don’t get the clutter reduction benefit.
Another possibility instead of a symlink is to use a <code class="docutils literal notranslate"><span class="pre">BranchReference</span></code>. It is currently
difficult to create these through the <code class="docutils literal notranslate"><span class="pre">bzr</span></code> command line, but if people find them useful
that could be changed.
This is actually how <a class="reference external" href="https://launchpad.net">Launchpad</a> allows you to <code class="docutils literal notranslate"><span class="pre">bzr</span> <span class="pre">checkout</span> <span class="pre">https://launchpad.net/bzr</span></code>.
Effectively a <code class="docutils literal notranslate"><span class="pre">BranchReference</span></code> is a symlink, but it allows you to reference any other URL.
If it is extended to support relative references, it would even work over HTTP, SFTP,
and local paths.</p>
</div>
<div class="section" id="sorted-by-date-release-etc-2006-06-2006-07-0-8-0-9">
<h4>1.10.3.4 Sorted by date/release/etc (<code class="docutils literal notranslate"><span class="pre">2006-06/</span></code>, <code class="docutils literal notranslate"><span class="pre">2006-07/</span></code>, <code class="docutils literal notranslate"><span class="pre">0.8/</span></code>, <code class="docutils literal notranslate"><span class="pre">0.9</span></code>)<a class="headerlink" href="#sorted-by-date-release-etc-2006-06-2006-07-0-8-0-9" title="Ссылка на этот заголовок">¶</a></h4>
<p>Another method of allowing some scalability while also allowing the
browsing of «current» branches. Basically, this works on the assumption
that actively developed branches will be «new» branches, and older branches
are either merged or abandoned.</p>
<p>Basically the date layout looks something like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">project</span><span class="o">/</span> <span class="c1"># Overall project repository</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># General mainline</span>
<span class="o">+-</span> <span class="mi">2006</span><span class="o">-</span><span class="mi">06</span><span class="o">/</span> <span class="c1"># containing directory for branches created in this month</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">feature1</span><span class="o">/</span> <span class="c1"># Branch of "project" for "feature1"</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">feature2</span><span class="o">/</span> <span class="c1"># Branch of "project" for "feature2"</span>
<span class="o">+-</span> <span class="mi">2005</span><span class="o">-</span><span class="mi">05</span><span class="o">/</span> <span class="c1"># Containing directory for branches create in a different month</span>
<span class="o">+-</span> <span class="n">feature3</span><span class="o">/</span>
<span class="o">...</span>
</pre></div>
</div>
<p>This answers the question «Where should I put my new branch?» very quickly.
If a feature is developed for a long time, it is even reasonable to copy a
branch into the newest date, and continue working on it there.
Finding an active branch generally means going to the newest date, and
going backwards from there. (A small disadvantage is that most directory
listings sort oldest to the top, which may mean more scrolling).
If you don’t copy old branches to newer locations, it also has the disadvantage
that searching for a branch may take a while.</p>
<p>Another variant is by release target:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">project</span><span class="o">/</span> <span class="c1"># Overall repository</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># Mainline development branch</span>
<span class="o">+-</span> <span class="n">releases</span><span class="o">/</span> <span class="c1"># Container for release branches</span>
<span class="o">|</span> <span class="o">+-</span> <span class="mf">0.8</span><span class="o">/</span> <span class="c1"># The branch for release 0.8</span>
<span class="o">|</span> <span class="o">+-</span> <span class="mf">0.9</span><span class="o">/</span> <span class="c1"># The branch for release 0.9</span>
<span class="o">+-</span> <span class="mf">0.8</span><span class="o">/</span> <span class="c1"># Container for branches targeting release 0.8</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">feature1</span><span class="o">/</span> <span class="c1"># Branch for "feature1" which is intended to be merged into 0.8</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">feature2</span><span class="o">/</span> <span class="c1"># Branch for "feature2" which is targeted for 0.8</span>
<span class="o">+-</span> <span class="mf">0.9</span><span class="o">/</span>
<span class="o">+-</span> <span class="n">feature3</span><span class="o">/</span> <span class="c1"># Branch for "feature3", targeted for release 0.9</span>
</pre></div>
</div>
<p>Some possible variants include having the <code class="docutils literal notranslate"><span class="pre">0.9</span></code> directory imply
that it is branched <em>from</em> 0.9 rather than <em>for</em> 0.9, or having the <code class="docutils literal notranslate"><span class="pre">0.8/release</span></code>
as the official release 0.8 branch.</p>
<p>The general idea is that by targeting a release, you can look at what branches are
waiting to be merged. It doesn’t necessarily give you a good idea of what the
state of the branch (is it in development or finished awaiting review).
It also has a history-hiding effect, and otherwise has the same benefits
and deficits as a date-based sorting.</p>
</div>
<div class="section" id="simple-developer-naming-project-joe-foo-project-barry-bar">
<h4>1.10.3.5 Simple developer naming (<code class="docutils literal notranslate"><span class="pre">project/joe/foo</span></code>, <code class="docutils literal notranslate"><span class="pre">project/barry/bar</span></code>)<a class="headerlink" href="#simple-developer-naming-project-joe-foo-project-barry-bar" title="Ссылка на этот заголовок">¶</a></h4>
<p>Another possibly layout is to give each developer a directory, and then
have a single sub-directory for branches. Something like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">project</span><span class="o">/</span> <span class="c1"># Overall repository</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># Mainline branch</span>
<span class="o">+-</span> <span class="n">joe</span><span class="o">/</span> <span class="c1"># A container for Joe's branches</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">foo</span><span class="o">/</span> <span class="c1"># Joe's "foo" branch of "project"</span>
<span class="o">+-</span> <span class="n">barry</span><span class="o">/</span>
<span class="o">+-</span> <span class="n">bar</span><span class="o">/</span> <span class="c1"># Barry's "bar" branch of "project"</span>
</pre></div>
</div>
<p>The idea is that no branch is «nested» underneath another one, just that each developer
has his/her branches grouped together.</p>
<p>A variant which is used by <a class="reference external" href="https://launchpad.net">Launchpad</a> is:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">repository</span><span class="o">/</span>
<span class="o">+-</span> <span class="n">joe</span><span class="o">/</span> <span class="c1"># Joe's branches</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project1</span><span class="o">/</span> <span class="c1"># Container for Joe's branches of "project1"</span>
<span class="o">|</span> <span class="o">|</span> <span class="o">+-</span> <span class="n">foo</span><span class="o">/</span> <span class="c1"># Joe's "foo" branch of "project1"</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project2</span><span class="o">/</span> <span class="c1"># Container for Joe's "project2" branches</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">bar</span><span class="o">/</span> <span class="c1"># Joe's "bar" branch of "project2"</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">|</span>
<span class="o">+-</span> <span class="n">barry</span><span class="o">/</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">project1</span><span class="o">/</span> <span class="c1"># Container for Barry's branches of "project1"</span>
<span class="o">|</span> <span class="o">+-</span> <span class="n">bug</span><span class="o">-</span><span class="mi">10</span><span class="o">/</span> <span class="c1"># Barry's "bug-10" branch of "project1"</span>
<span class="o">|</span> <span class="o">...</span>
<span class="o">+-</span> <span class="n">group</span><span class="o">/</span>
<span class="o">+-</span> <span class="n">project1</span><span class="o">/</span>
<span class="o">+-</span> <span class="n">trunk</span><span class="o">/</span> <span class="c1"># The main development focus for "project1"</span>
</pre></div>
</div>
<p>This lets you easily browse what each developer is working on. Focus branches
are kept in a «group» directory, which lets you see what branches the «group»
is working on.</p>
<p>This keeps different people’s work separated from each-other, but also makes it
hard to find «all branches for project X». <a class="reference external" href="https://launchpad.net">Launchpad</a> compensates for this
by providing a nice web interface with a database back end, which allows a
«view» to be put on top of this layout.
This is closer to the model of people’s home pages, where each person has a
«<code class="docutils literal notranslate"><span class="pre">~/public_html</span></code>» directory where they can publish their own web-pages.
In general, though, when you are creating a shared repository for centralization
of a project, you don’t want to split it up by person and then project.
Usually you would want to split it up by project and then by person.</p>
</div>
<div class="section" id="summary">
<h4>1.10.3.6 Summary<a class="headerlink" href="#summary" title="Ссылка на этот заголовок">¶</a></h4>
<p>In the end, no single naming scheme will work for everyone. It depends a lot on
the number of developers, how often you create a new branch, what sort of
lifecycles your branches go through. Some questions to ask yourself:</p>
<blockquote>
<div><ol class="arabic simple">
<li>Do you create a few long-lived branches, or do you create lots of «mini» feature branches
(Along with this is: Would you <em>like</em> to create lots of mini feature branches, but can’t
because they are a pain in your current VCS?)</li>
<li>Are you a single developer, or a large team?</li>
<li>If a team, do you plan on generally having everyone working on the same branch at the same
time? Or will you have a «stable» branch that people are expected to track.</li>
</ol>
</div></blockquote>
</div>
</div>
<div class="section" id="configuring-email">
<h3>1.10.4 Configuring email<a class="headerlink" href="#configuring-email" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="why-set-up-an-email-address-with-bazaar">
<h4>1.10.4.1 Why set up an email address with Bazaar?<a class="headerlink" href="#why-set-up-an-email-address-with-bazaar" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar stores the specified email address in revisions when they’re
created so that people can tell who committed which revisions. The
email addresses are not verified, therefore they could be bogus, so
you have to trust the people involved in your project. Additionally,
the email address in a revision gives others a way to contact the
author of a revision for credit and/or blame. :)</p>
</div>
<div class="section" id="how-to-set-up-your-email-address">
<h4>1.10.4.2 How to set up your email address<a class="headerlink" href="#how-to-set-up-your-email-address" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bazaar will try to guess an email address based on your username and the
hostname if none is set. This will probably not be what you want, so three
ways exist to tell Bazaar what email to use:</p>
<p>You can set your email in one of several configuration files. Like
other configuration values, you can set it in <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> as a
general setting. If you want to override the value for a particular
branch, or set of branches, you can use <code class="docutils literal notranslate"><span class="pre">locations.conf</span></code>.
<code class="docutils literal notranslate"><span class="pre">.bzr/branch/branch.conf</span></code> will also work, but will cause all commits
to that branch to use the same email address, even if someone else
does them.</p>
<p>The order of precedence is</p>
<blockquote>
<div><ol class="arabic simple">
<li>If the <code class="docutils literal notranslate"><span class="pre">BZR_EMAIL</span></code> environment variable is set.</li>
<li>If an email is set for your current branch in the <code class="docutils literal notranslate"><span class="pre">locations.conf</span></code>
file.</li>
<li>If an email is set four your current branch in the
<code class="docutils literal notranslate"><span class="pre">.bzr/branch/branch.conf</span></code> file.</li>
<li>If an email is set in the <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> default configuration file.</li>
<li>If the <cite>EMAIL</cite> environment variable is set.</li>
<li>Bazaar will try to guess based on your username and the hostname.</li>
</ol>
</div></blockquote>
<p>To check on what Bazaar thinks your current email is, use the <code class="docutils literal notranslate"><span class="pre">whoami</span></code>
(«who am i?») command:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">whoami</span>
<span class="n">Joe</span> <span class="n">Cool</span> <span class="o"><</span><span class="n">joe</span><span class="nd">@example</span><span class="o">.</span><span class="n">com</span><span class="o">></span>
</pre></div>
</div>
</div>
<div class="section" id="setting-email-via-the-whoami-command">
<h4>1.10.4.3 Setting email via the „whoami“ command<a class="headerlink" href="#setting-email-via-the-whoami-command" title="Ссылка на этот заголовок">¶</a></h4>
<p>You can use the whoami command to set your email globally:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">whoami</span> <span class="s2">"Joe Cool <joe@example.com>"</span>
</pre></div>
</div>
<p>or only for the current branch:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o">%</span> <span class="n">bzr</span> <span class="n">whoami</span> <span class="o">--</span><span class="n">branch</span> <span class="s2">"Joe Cool <joe@example.com>"</span>
</pre></div>
</div>
<p>These modify your global <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> or branch <code class="docutils literal notranslate"><span class="pre">branch.conf</span></code> file, respectively.</p>
</div>
<div class="section" id="setting-email-via-default-configuration-file">
<h4>1.10.4.4 Setting email via default configuration file<a class="headerlink" href="#setting-email-via-default-configuration-file" title="Ссылка на этот заголовок">¶</a></h4>
<p>To use the default ini file, create or edit the <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> file (in
<code class="docutils literal notranslate"><span class="pre">~/.bazaar/</span></code> on Unix and in <code class="docutils literal notranslate"><span class="pre">%APPDATA%\bazaar\2.0\</span></code> in Windows)
and set an email address as shown below. Please note that the word DEFAULT
is case sensitive, and must be in upper-case.</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[</span><span class="n">DEFAULT</span><span class="p">]</span>
<span class="n">email</span><span class="o">=</span><span class="n">Your</span> <span class="n">Name</span> <span class="o"><</span><span class="n">name</span><span class="nd">@isp</span><span class="o">.</span><span class="n">com</span><span class="o">></span>
</pre></div>
</div>
<p>For more information on the ini file format, see <a class="reference external" href="../user-reference/index.html#configuration-settings">Configuration Settings</a> in
the Bazaar User Reference.</p>
</div>
<div class="section" id="setting-email-on-a-per-branch-basis">
<h4>1.10.4.5 Setting email on a per-branch basis<a class="headerlink" href="#setting-email-on-a-per-branch-basis" title="Ссылка на этот заголовок">¶</a></h4>
<p>The second approach is to set email on a branch by branch basis by
using the <code class="docutils literal notranslate"><span class="pre">locations.conf</span></code> configuration file like this:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="p">[</span><span class="o">/</span><span class="n">some</span><span class="o">/</span><span class="n">branch</span><span class="o">/</span><span class="n">location</span><span class="p">]</span>
<span class="n">email</span><span class="o">=</span><span class="n">Your</span> <span class="n">Name</span> <span class="o"><</span><span class="n">name</span><span class="nd">@other</span><span class="o">-</span><span class="n">isp</span><span class="o">.</span><span class="n">com</span><span class="o">></span>
</pre></div>
</div>
<p>This will set your email address in the branch at <code class="docutils literal notranslate"><span class="pre">/some/branch/location</span></code>,
overriding the default specified in the <code class="docutils literal notranslate"><span class="pre">bazaar.conf</span></code> above.</p>
</div>
<div class="section" id="setting-email-via-environment-variable">
<h4>1.10.4.6 Setting email via environment variable<a class="headerlink" href="#setting-email-via-environment-variable" title="Ссылка на этот заголовок">¶</a></h4>
<p>The final method Bazaar will use is checking for the <code class="docutils literal notranslate"><span class="pre">BZR_EMAIL</span></code>
and <code class="docutils literal notranslate"><span class="pre">EMAIL</span></code> environment variables. Generally, you would use this
method to override the email in a script context. If you would like
to set a general default, then please see the ini methods above.</p>
</div>
<div class="section" id="concerns-about-spam">
<h4>1.10.4.7 Concerns about spam<a class="headerlink" href="#concerns-about-spam" title="Ссылка на этот заголовок">¶</a></h4>
<p>Some people want to avoid sharing their email address so as not to get
spam. Bazaar will never disclose your email address, unless you publish
a branch or changeset in a public location. It’s recommended that you
<em>do</em> use a real address, so that people can contact you about your work,
but it’s not required. You can use an address which is obfuscated, which
bounces, or which goes through an anti-spam service such as
<cite>spamgourmet.com</cite>.</p>
</div>
</div>
<div class="section" id="serving-bazaar-with-apache">
<h3>1.10.5 Serving Bazaar with Apache<a class="headerlink" href="#serving-bazaar-with-apache" title="Ссылка на этот заголовок">¶</a></h3>
<p>This document describes one way to set up a Bazaar HTTP smart server,
using Apache 2.0 and FastCGI or mod_python or mod_wsgi.</p>
<p>For more information on the smart server, and other ways to configure it
see the main <a class="reference external" href="server.html">smart server documentation</a>.</p>
<div class="section" id="example">
<h4>1.10.5.1 Example<a class="headerlink" href="#example" title="Ссылка на этот заголовок">¶</a></h4>
<p>You have a webserver already publishing <cite>/srv/example.com/www/code</cite> as
<cite>http://example.com/code/…</cite> with plain HTTP. It contains bzr branches and
directories like <cite>/srv/example.com/www/code/branch-one</cite> and
<cite>/srv/example.com/www/code/my-repo/branch-two</cite>. You want to provide read-only
smart server access to these directories in addition to the existing HTTP
access.</p>
</div>
<div class="section" id="configuring-apache-2-0">
<h4>1.10.5.2 Configuring Apache 2.0<a class="headerlink" href="#configuring-apache-2-0" title="Ссылка на этот заголовок">¶</a></h4>
<div class="section" id="fastcgi">
<h5>1.10.5.2.1 FastCGI<a class="headerlink" href="#fastcgi" title="Ссылка на этот заголовок">¶</a></h5>
<p>First, configure mod_fastcgi, e.g. by adding lines like these to your
httpd.conf:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">LoadModule</span> <span class="n">fastcgi_module</span> <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">apache2</span><span class="o">/</span><span class="n">modules</span><span class="o">/</span><span class="n">mod_fastcgi</span><span class="o">.</span><span class="n">so</span>
<span class="n">FastCgiIpcDir</span> <span class="o">/</span><span class="n">var</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">apache2</span><span class="o">/</span><span class="n">fastcgi</span>
</pre></div>
</div>
<p>In our example, we’re already serving <cite>/srv/example.com/www/code</cite> at
<cite>http://example.com/code</cite>, so our existing Apache configuration would look
like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Alias</span> <span class="o">/</span><span class="n">code</span> <span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">www</span><span class="o">/</span><span class="n">code</span>
<span class="o"><</span><span class="n">Directory</span> <span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">www</span><span class="o">/</span><span class="n">code</span><span class="o">></span>
<span class="n">Options</span> <span class="n">Indexes</span>
<span class="c1"># ...</span>
<span class="o"></</span><span class="n">Directory</span><span class="o">></span>
</pre></div>
</div>
<p>We need to change it to handle all requests for URLs ending in <cite>.bzr/smart</cite>. It
will look like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>Alias /code /srv/example.com/www/code
<Directory /srv/example.com/www/code>
Options Indexes FollowSymLinks
RewriteEngine On
RewriteBase /code
RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
</Directory>
# bzr-smart.fcgi isn't under the DocumentRoot, so Alias it into the URL
# namespace so it can be executed.
Alias /srv/example.com/scripts/bzr-smart.fcgi /srv/example.com/scripts/bzr-smart.fcgi
<Directory /srv/example.com/scripts>
Options ExecCGI
<Files bzr-smart.fcgi>
SetHandler fastcgi-script
</Files>
</Directory>
</pre></div>
</div>
<p>This instructs Apache to hand requests for any URL ending with <cite>/.bzr/smart</cite>
inside <cite>/code</cite> to a Bazaar smart server via FastCGI.</p>
<p>Refer to the <a class="reference external" href="http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html">mod_rewrite</a> and <a class="reference external" href="http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html">mod_fastcgi</a> documentation for further
information.</p>
</div>
<div class="section" id="mod-python">
<h5>1.10.5.2.2 mod_python<a class="headerlink" href="#mod-python" title="Ссылка на этот заголовок">¶</a></h5>
<p>First, configure mod_python, e.g. by adding lines like these to your
httpd.conf:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">LoadModule</span> <span class="n">python_module</span> <span class="o">/</span><span class="n">usr</span><span class="o">/</span><span class="n">lib</span><span class="o">/</span><span class="n">apache2</span><span class="o">/</span><span class="n">modules</span><span class="o">/</span><span class="n">mod_python</span><span class="o">.</span><span class="n">so</span>
</pre></div>
</div>
<p>Define the rewrite rules with mod_rewrite the same way as for FastCGI, except
change:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
</pre></div>
</div>
<p>to:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>RewriteRule ^(.*/)?\.bzr/smart$ /srv/example.com/scripts/bzr-smart.py
</pre></div>
</div>
<p>Like with mod_fastcgi, we also define how our script is to be handled:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">Alias</span> <span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">scripts</span><span class="o">/</span><span class="n">bzr</span><span class="o">-</span><span class="n">smart</span><span class="o">.</span><span class="n">py</span> <span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">scripts</span><span class="o">/</span><span class="n">bzr</span><span class="o">-</span><span class="n">smart</span><span class="o">.</span><span class="n">py</span>
<span class="o"><</span><span class="n">Directory</span> <span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">scripts</span><span class="o">></span>
<span class="o"><</span><span class="n">Files</span> <span class="n">bzr</span><span class="o">-</span><span class="n">smart</span><span class="o">.</span><span class="n">py</span><span class="o">></span>
<span class="n">PythonPath</span> <span class="s2">"sys.path+['/srv/example.com/scripts']"</span>
<span class="n">AddHandler</span> <span class="n">python</span><span class="o">-</span><span class="n">program</span> <span class="o">.</span><span class="n">py</span>
<span class="n">PythonHandler</span> <span class="n">bzr</span><span class="o">-</span><span class="n">smart</span><span class="p">::</span><span class="n">handler</span>
<span class="o"></</span><span class="n">Files</span><span class="o">></span>
<span class="o"></</span><span class="n">Directory</span><span class="o">></span>
</pre></div>
</div>
<p>This instructs Apache to hand requests for any URL ending with <cite>/.bzr/smart</cite>
inside <cite>/code</cite> to a Bazaar smart server via mod_python.</p>
<p>NOTE: If you don’t have bzrlib in your PATH, you will be need to change the
following line:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">PythonPath</span> <span class="s2">"sys.path+['/srv/example.com/scripts']"</span>
</pre></div>
</div>
<p>To:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">PythonPath</span> <span class="s2">"['/path/to/bzr']+sys.path+['/srv/example.com/scripts']"</span>
</pre></div>
</div>
<p>Refer to the <a class="reference external" href="http://www.modpython.org/">mod_python</a> documentation for further information.</p>
</div>
<div class="section" id="mod-wsgi">
<h5>1.10.5.2.3 mod_wsgi<a class="headerlink" href="#mod-wsgi" title="Ссылка на этот заголовок">¶</a></h5>
<p>First, configure mod_wsgi, e.g. enabling the mod with a2enmod wsgi.
We need to change it to handle all requests for URLs ending in <cite>.bzr/smart</cite>. It
will look like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span>WSGIScriptAliasMatch ^/code/.*/\.bzr/smart$ /srv/example.com/scripts/bzr.wsgi
#The three next lines allow regular GETs to work too
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/code/.*/\.bzr/smart$
RewriteRule ^/code/(.*/\.bzr/.*)$ /srv/example.com/www/code/$1 [L]
<Directory /srv/example.com/www/code>
WSGIApplicationGroup %{GLOBAL}
</Directory>
</pre></div>
</div>
<p>This instructs Apache to hand requests for any URL ending with <cite>/.bzr/smart</cite>
inside <cite>/code</cite> to a Bazaar smart server via WSGI, and any other URL inside
<cite>/code</cite> to be served directly by Apache.</p>
<p>Refer to the <a class="reference external" href="http://code.google.com/p/modwsgi/">mod_wsgi</a> documentation for further information.</p>
</div>
</div>
<div class="section" id="id68">
<h4>1.10.5.3 Configuring Bazaar<a class="headerlink" href="#id68" title="Ссылка на этот заголовок">¶</a></h4>
<div class="section" id="id69">
<h5>1.10.5.3.1 FastCGI<a class="headerlink" href="#id69" title="Ссылка на этот заголовок">¶</a></h5>
<p>We’ve configured Apache to run the smart server at
<cite>/srv/example.com/scripts/bzr-smart.fcgi</cite>. This is just a simple script we need
to write to configure a smart server, and glue it to the FastCGI gateway.
Here’s what it looks like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">fcgi</span>
<span class="kn">from</span> <span class="nn">bzrlib.transport.http</span> <span class="k">import</span> <span class="n">wsgi</span>
<span class="n">smart_server_app</span> <span class="o">=</span> <span class="n">wsgi</span><span class="o">.</span><span class="n">make_app</span><span class="p">(</span>
<span class="n">root</span><span class="o">=</span><span class="s1">'/srv/example.com/www/code'</span><span class="p">,</span>
<span class="n">prefix</span><span class="o">=</span><span class="s1">'/code/'</span><span class="p">,</span>
<span class="n">path_var</span><span class="o">=</span><span class="s1">'REQUEST_URI'</span><span class="p">,</span>
<span class="n">readonly</span><span class="o">=</span><span class="kc">True</span><span class="p">,</span>
<span class="n">load_plugins</span><span class="o">=</span><span class="kc">True</span><span class="p">,</span>
<span class="n">enable_logging</span><span class="o">=</span><span class="kc">True</span><span class="p">)</span>
<span class="n">fcgi</span><span class="o">.</span><span class="n">WSGIServer</span><span class="p">(</span><span class="n">smart_server_app</span><span class="p">)</span><span class="o">.</span><span class="n">run</span><span class="p">()</span>
</pre></div>
</div>
<p>The <cite>fcgi</cite> module can be found at <a class="reference external" href="http://svn.saddi.com/py-lib/trunk/fcgi.py">http://svn.saddi.com/py-lib/trunk/fcgi.py</a>. It
is part of <a class="reference external" href="http://www.saddi.com/software/flup/">flup</a>.</p>
</div>
<div class="section" id="id70">
<h5>1.10.5.3.2 mod_python<a class="headerlink" href="#id70" title="Ссылка на этот заголовок">¶</a></h5>
<p>We’ve configured Apache to run the smart server at
<cite>/srv/example.com/scripts/bzr-smart.py</cite>. This is just a simple script we need
to write to configure a smart server, and glue it to the mod_python gateway.
Here’s what it looks like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">import</span> <span class="nn">modpywsgi</span>
<span class="kn">from</span> <span class="nn">bzrlib.transport.http</span> <span class="k">import</span> <span class="n">wsgi</span>
<span class="n">smart_server_app</span> <span class="o">=</span> <span class="n">wsgi</span><span class="o">.</span><span class="n">make_app</span><span class="p">(</span>
<span class="n">root</span><span class="o">=</span><span class="s1">'/srv/example.com/www/code'</span><span class="p">,</span>
<span class="n">prefix</span><span class="o">=</span><span class="s1">'/code/'</span><span class="p">,</span>
<span class="n">path_var</span><span class="o">=</span><span class="s1">'REQUEST_URI'</span><span class="p">,</span>
<span class="n">readonly</span><span class="o">=</span><span class="kc">True</span><span class="p">,</span>
<span class="n">load_plugins</span><span class="o">=</span><span class="kc">True</span><span class="p">,</span>
<span class="n">enable_logging</span><span class="o">=</span><span class="kc">True</span><span class="p">)</span>
<span class="k">def</span> <span class="nf">handler</span><span class="p">(</span><span class="n">request</span><span class="p">):</span>
<span class="sd">"""Handle a single request."""</span>
<span class="n">wsgi_server</span> <span class="o">=</span> <span class="n">modpywsgi</span><span class="o">.</span><span class="n">WSGIServer</span><span class="p">(</span><span class="n">smart_server_app</span><span class="p">)</span>
<span class="k">return</span> <span class="n">wsgi_server</span><span class="o">.</span><span class="n">run</span><span class="p">(</span><span class="n">request</span><span class="p">)</span>
</pre></div>
</div>
<p>The <cite>modpywsgi</cite> module can be found at
<a class="reference external" href="http://ice.usq.edu.au/svn/ice/trunk/apps/ice-server/modpywsgi.py">http://ice.usq.edu.au/svn/ice/trunk/apps/ice-server/modpywsgi.py</a>. It was
part of <a class="reference external" href="http://dev.pocoo.org/projects/pocoo/">pocoo</a>. You sould make sure you place modpywsgi.py in the same
directory as bzr-smart.py (ie. /srv/example.com/scripts/).</p>
</div>
<div class="section" id="id71">
<h5>1.10.5.3.3 mod_wsgi<a class="headerlink" href="#id71" title="Ссылка на этот заголовок">¶</a></h5>
<p>We’ve configured Apache to run the smart server at
<cite>/srv/example.com/scripts/bzr.wsgi</cite>. This is just a simple script we need
to write to configure a smart server, and glue it to the WSGI gateway.
Here’s what it looks like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="kn">from</span> <span class="nn">bzrlib.transport.http</span> <span class="k">import</span> <span class="n">wsgi</span>
<span class="k">def</span> <span class="nf">application</span><span class="p">(</span><span class="n">environ</span><span class="p">,</span> <span class="n">start_response</span><span class="p">):</span>
<span class="n">app</span> <span class="o">=</span> <span class="n">wsgi</span><span class="o">.</span><span class="n">make_app</span><span class="p">(</span>
<span class="n">root</span><span class="o">=</span><span class="s2">"/srv/example.com/www/code/"</span><span class="p">,</span>
<span class="n">prefix</span><span class="o">=</span><span class="s2">"/code"</span><span class="p">,</span>
<span class="n">readonly</span><span class="o">=</span><span class="kc">True</span><span class="p">,</span>
<span class="n">enable_logging</span><span class="o">=</span><span class="kc">False</span><span class="p">)</span>
<span class="k">return</span> <span class="n">app</span><span class="p">(</span><span class="n">environ</span><span class="p">,</span> <span class="n">start_response</span><span class="p">)</span>
</pre></div>
</div>
</div>
</div>
<div class="section" id="clients">
<h4>1.10.5.4 Clients<a class="headerlink" href="#clients" title="Ссылка на этот заголовок">¶</a></h4>
<p>Now you can use <cite>bzr+http://</cite> URLs or just <cite>http://</cite> URLs, e.g.:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">bzr</span><span class="o">+</span><span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">code</span><span class="o">/</span><span class="n">my</span><span class="o">-</span><span class="n">branch</span>
</pre></div>
</div>
<p>Plain HTTP access should continue to work:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span> <span class="n">log</span> <span class="n">http</span><span class="p">:</span><span class="o">//</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">code</span><span class="o">/</span><span class="n">my</span><span class="o">-</span><span class="n">branch</span>
</pre></div>
</div>
</div>
<div class="section" id="advanced-configuration">
<h4>1.10.5.5 Advanced configuration<a class="headerlink" href="#advanced-configuration" title="Ссылка на этот заголовок">¶</a></h4>
<p>Because the Bazaar HTTP smart server is a WSGI application, it can be used with
any 3rd-party WSGI middleware or server that conforms the WSGI standard. The
only requirements are:</p>
<blockquote>
<div><ul class="simple">
<li>to construct a <cite>SmartWSGIApp</cite>, you need to specify a <strong>root transport</strong> that it
will serve.</li>
<li>each request’s <cite>environ</cite> dict must have a <strong>„bzrlib.relpath“</strong> variable set.</li>
</ul>
</div></blockquote>
<p>The <cite>make_app</cite> helper used in the example constructs a <cite>SmartWSGIApp</cite> with a
transport based on the <cite>root</cite> path given to it, and calculates the
„bzrlib.relpath` for each request based on the <cite>prefix</cite> and <cite>path_var</cite>
arguments. In the example above, it will take the „REQUEST_URI“ (which is set
by Apache), strip the „/code/“ prefix and the „/.bzr/smart“ suffix, and set that
as the „bzrlib.relpath“, so that a request for „/code/foo/bar/.bzr/smart“ will
result in a „bzrlib.relpath“ of „foo/bzr“.</p>
<p>It’s possible to configure a smart server for a non-local transport, or that
does arbitrary path translations, etc, by constructing a <cite>SmartWSGIApp</cite>
directly. Refer to the docstrings of <cite>bzrlib.transport.http.wsgi</cite> and the <a class="reference external" href="http://www.python.org/dev/peps/pep-0333/">WSGI
standard</a> for further information.</p>
<div class="section" id="pushing-over-the-http-smart-server">
<h5>1.10.5.5.1 Pushing over the HTTP smart server<a class="headerlink" href="#pushing-over-the-http-smart-server" title="Ссылка на этот заголовок">¶</a></h5>
<p>It is possible to allow pushing data over the HTTP smart server. The
easiest way to do this, is to just supply <code class="docutils literal notranslate"><span class="pre">readonly=False</span></code> to the
<code class="docutils literal notranslate"><span class="pre">wsgi.make_app()</span></code> call. But be careful, because the smart protocol does
not contain any Authentication. So if you enable write support, you will
want to restrict access to <code class="docutils literal notranslate"><span class="pre">.bzr/smart</span></code> URLs to restrict who can
actually write data on your system, e.g. in apache it looks like:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="o"><</span><span class="n">Location</span> <span class="o">/</span><span class="n">code</span><span class="o">></span>
<span class="n">AuthType</span> <span class="n">Basic</span>
<span class="n">AuthName</span> <span class="s2">"example"</span>
<span class="n">AuthUserFile</span> <span class="o">/</span><span class="n">srv</span><span class="o">/</span><span class="n">example</span><span class="o">.</span><span class="n">com</span><span class="o">/</span><span class="n">conf</span><span class="o">/</span><span class="n">auth</span><span class="o">.</span><span class="n">passwd</span>
<span class="o"><</span><span class="n">LimitExcept</span> <span class="n">GET</span><span class="o">></span>
<span class="n">Require</span> <span class="n">valid</span><span class="o">-</span><span class="n">user</span>
<span class="o"></</span><span class="n">LimitExcept</span><span class="o">></span>
<span class="o"></</span><span class="n">Location</span><span class="o">></span>
</pre></div>
</div>
<p>At this time, it is not possible to allow some people to have read-only
access and others to have read-write access to the same URLs. Because at
the HTTP layer (which is doing the Authenticating), everything is just a
POST request. However, it would certainly be possible to have HTTPS
require authentication and use a writable server, and plain HTTP allow
read-only access.</p>
<p>If bzr gives an error like this when accessing your HTTPS site:</p>
<div class="highlight-default notranslate"><div class="highlight"><pre><span></span><span class="n">bzr</span><span class="p">:</span> <span class="n">ERROR</span><span class="p">:</span> <span class="n">Connection</span> <span class="n">error</span><span class="p">:</span> <span class="n">curl</span> <span class="n">connection</span> <span class="n">error</span> <span class="p">(</span><span class="n">server</span> <span class="n">certificate</span> <span class="n">verification</span> <span class="n">failed</span><span class="o">.</span>
<span class="n">CAfile</span><span class="p">:</span><span class="o">/</span><span class="n">etc</span><span class="o">/</span><span class="n">ssl</span><span class="o">/</span><span class="n">certs</span><span class="o">/</span><span class="n">ca</span><span class="o">-</span><span class="n">certificates</span><span class="o">.</span><span class="n">crt</span> <span class="n">CRLfile</span><span class="p">:</span> <span class="n">none</span><span class="p">)</span>
</pre></div>
</div>
<p>You can workaround it by using <code class="docutils literal notranslate"><span class="pre">https+urllib</span></code> rather than <code class="docutils literal notranslate"><span class="pre">http</span></code> in your
URL, or by uninstalling pycurl. See <a class="reference external" href="https://bugs.launchpad.net/bzr/+bug/82086">bug 82086</a> for more details.</p>
</div>
</div>
</div>
<div class="section" id="id72">
<h3>1.10.6 Writing a plugin<a class="headerlink" href="#id72" title="Ссылка на этот заголовок">¶</a></h3>
<div class="section" id="introduction">
<h4>1.10.6.1 Introduction<a class="headerlink" href="#introduction" title="Ссылка на этот заголовок">¶</a></h4>
<p>Plugins are very similar to bzr core functionality. They can import
anything in bzrlib. A plugin may simply override standard functionality,
but most plugins supply new commands.</p>
</div>
<div class="section" id="creating-a-new-command">
<h4>1.10.6.2 Creating a new command<a class="headerlink" href="#creating-a-new-command" title="Ссылка на этот заголовок">¶</a></h4>
<p>To create a command, make a new object that derives from
<code class="docutils literal notranslate"><span class="pre">bzrlib.commands.Command</span></code>, and name it <code class="docutils literal notranslate"><span class="pre">cmd_foo</span></code>, where foo is the name of
your command. If you create a command whose name contains an underscore,
it will appear in the UI with the underscore turned into a hyphen. For
example, <cite>cmd_baz_import</cite> will appear as <cite>baz-import</cite>. For examples of how
to write commands, please see <code class="docutils literal notranslate"><span class="pre">builtins.py</span></code>.</p>
<p>Once you’ve created a command you must register the command with
<code class="docutils literal notranslate"><span class="pre">bzrlib.commands.register_command(cmd_foo)</span></code>. You must register the
command when your file is imported, otherwise bzr will not see it.</p>
</div>
<div class="section" id="installing-a-hook">
<h4>1.10.6.3 Installing a hook<a class="headerlink" href="#installing-a-hook" title="Ссылка на этот заголовок">¶</a></h4>
<p>See <a class="reference external" href="hooks.txt">Using hooks</a>.</p>
<blockquote>
<div></div></blockquote>
</div>
<div class="section" id="specifying-a-plugin-version-number">
<h4>1.10.6.4 Specifying a plugin version number<a class="headerlink" href="#specifying-a-plugin-version-number" title="Ссылка на этот заголовок">¶</a></h4>
<p>Simply define <code class="docutils literal notranslate"><span class="pre">version_info</span></code> to be a tuple defining the current version
number of your plugin. eg.
<code class="docutils literal notranslate"><span class="pre">version_info</span> <span class="pre">=</span> <span class="pre">(0,</span> <span class="pre">9,</span> <span class="pre">0)</span></code>
<code class="docutils literal notranslate"><span class="pre">version_info</span> <span class="pre">=</span> <span class="pre">(0,</span> <span class="pre">9,</span> <span class="pre">0,</span> <span class="pre">'dev',</span> <span class="pre">0)</span></code></p>
</div>
<div class="section" id="plugin-searching-rules">
<h4>1.10.6.5 Plugin searching rules<a class="headerlink" href="#plugin-searching-rules" title="Ссылка на этот заголовок">¶</a></h4>
<p>Bzr will scan <code class="docutils literal notranslate"><span class="pre">~/.bazaar/plugins</span></code> and <code class="docutils literal notranslate"><span class="pre">bzrlib/plugins</span></code> for plugins
by default. You can override this with <code class="docutils literal notranslate"><span class="pre">BZR_PLUGIN_PATH</span></code>
(see <a class="reference external" href="../user-reference/configuration-help.html#bzr-plugin-path">User Reference</a> for details).</p>
<p>Plugins may be either modules or packages. If your plugin is a single
file, you can structure it as a module. If it has multiple files, or if
you want to distribute it as a bzr branch, you should structure it as a
package, i.e. a directory with an <code class="docutils literal notranslate"><span class="pre">__init__.py</span></code> file.</p>
</div>
<div class="section" id="more-information">
<h4>1.10.6.6 More information<a class="headerlink" href="#more-information" title="Ссылка на этот заголовок">¶</a></h4>
<p>Please feel free to contribute your plugin to BzrTools, if you think it
would be useful to other people.</p>
<p>See the <a class="reference external" href="../developer-guide/HACKING.html">Bazaar Developer Guide</a> for details on Bazaar’s development
guidelines and policies.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
<div class="sphinxsidebarwrapper">
<h3><a href="../index.html">Table of Contents</a></h3>
<ul>
<li><a class="reference internal" href="#">1 Руководство пользователя Bazaar</a><ul>
<li><a class="reference internal" href="#id2">1.1 Введение</a><ul>
<li><a class="reference internal" href="#id3">1.1.1 Представляем Bazaar</a><ul>
<li><a class="reference internal" href="#id4">1.1.1.1 Что такое Bazaar?</a></li>
<li><a class="reference internal" href="#id5">1.1.1.2 Краткая история систем контроля версий</a></li>
<li><a class="reference internal" href="#id6">1.1.1.3 Централизованная модель против распределенной</a></li>
<li><a class="reference internal" href="#id7">1.1.1.4 Ключевые особенности Bazaar</a></li>
<li><a class="reference internal" href="#id8">1.1.1.5 Продолжаем изучение</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id12">1.1.2 Основные концепции</a><ul>
<li><a class="reference internal" href="#id13">1.1.2.1 Простая модель для пользователя</a></li>
<li><a class="reference internal" href="#id14">1.1.2.2 Ревизия</a></li>
<li><a class="reference internal" href="#id15">1.1.2.3 Рабочее дерево</a></li>
<li><a class="reference internal" href="#id16">1.1.2.4 Ветка</a></li>
<li><a class="reference internal" href="#id17">1.1.2.5 Репозиторий</a></li>
<li><a class="reference internal" href="#id18">1.1.2.6 Складывая концепции вместе</a></li>
</ul>
</li>
<li><a class="reference internal" href="#workflows">1.1.3 Workflows</a><ul>
<li><a class="reference internal" href="#bazaar-is-just-a-tool">1.1.3.1 Bazaar is just a tool</a></li>
<li><a class="reference internal" href="#solo">1.1.3.2 Solo</a></li>
<li><a class="reference internal" href="#partner">1.1.3.3 Partner</a></li>
<li><a class="reference internal" href="#centralized">1.1.3.4 Centralized</a></li>
<li><a class="reference internal" href="#centralized-with-local-commits">1.1.3.5 Centralized with local commits</a></li>
<li><a class="reference internal" href="#decentralized-with-shared-mainline">1.1.3.6 Decentralized with shared mainline</a></li>
<li><a class="reference internal" href="#decentralized-with-human-gatekeeper">1.1.3.7 Decentralized with human gatekeeper</a></li>
<li><a class="reference internal" href="#decentralized-with-automatic-gatekeeper">1.1.3.8 Decentralized with automatic gatekeeper</a></li>
<li><a class="reference internal" href="#implementing-a-workflow">1.1.3.9 Implementing a workflow</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id22">1.2 Начинаем работать</a><ul>
<li><a class="reference internal" href="#installing-bazaar">1.2.1 Installing Bazaar</a><ul>
<li><a class="reference internal" href="#gnu-linux">1.2.1.1 GNU/Linux</a></li>
<li><a class="reference internal" href="#windows">1.2.1.2 Windows</a></li>
<li><a class="reference internal" href="#other-operating-systems">1.2.1.3 Other operating systems</a></li>
<li><a class="reference internal" href="#installing-from-scratch">1.2.1.4 Installing from scratch</a><ul>
<li><a class="reference internal" href="#installing-into-site-wide-locations">1.2.1.4.1 Installing into site-wide locations</a></li>
</ul>
</li>
<li><a class="reference internal" href="#running-the-development-version">1.2.1.5 Running the development version</a></li>
<li><a class="reference internal" href="#running-multiple-versions">1.2.1.6 Running multiple versions</a></li>
</ul>
</li>
<li><a class="reference internal" href="#entering-commands">1.2.2 Entering commands</a><ul>
<li><a class="reference internal" href="#user-interfaces">1.2.2.1 User interfaces</a></li>
<li><a class="reference internal" href="#using-bzr">1.2.2.2 Using bzr</a></li>
<li><a class="reference internal" href="#common-options">1.2.2.3 Common options</a></li>
</ul>
</li>
<li><a class="reference internal" href="#getting-help">1.2.3 Getting help</a></li>
<li><a class="reference internal" href="#configuring-bazaar">1.2.4 Configuring Bazaar</a><ul>
<li><a class="reference internal" href="#telling-bazaar-about-yourself">1.2.4.1 Telling Bazaar about yourself</a></li>
<li><a class="reference internal" href="#using-a-network-proxy">1.2.4.2 Using a network proxy</a></li>
<li><a class="reference internal" href="#various-ways-to-configure">1.2.4.3 Various ways to configure</a></li>
<li><a class="reference internal" href="#configuration-files">1.2.4.4 Configuration files</a></li>
<li><a class="reference internal" href="#looking-at-the-active-configuration">1.2.4.5 Looking at the active configuration</a></li>
<li><a class="reference internal" href="#modifying-the-active-configuration">1.2.4.6 Modifying the active configuration</a></li>
<li><a class="reference internal" href="#rule-based-preferences">1.2.4.7 Rule-based preferences</a></li>
<li><a class="reference internal" href="#escaping-command-lines">1.2.4.8 Escaping command lines</a></li>
</ul>
</li>
<li><a class="reference internal" href="#using-aliases">1.2.5 Using aliases</a><ul>
<li><a class="reference internal" href="#what-are-aliases">1.2.5.1 What are aliases?</a></li>
<li><a class="reference internal" href="#defining-aliases">1.2.5.2 Defining aliases</a></li>
<li><a class="reference internal" href="#using-the-aliases">1.2.5.3 Using the aliases</a></li>
<li><a class="reference internal" href="#rules-for-aliases">1.2.5.4 Rules for aliases</a></li>
</ul>
</li>
<li><a class="reference internal" href="#using-plugins">1.2.6 Using plugins</a><ul>
<li><a class="reference internal" href="#what-is-a-plugin">1.2.6.1 What is a plugin?</a></li>
<li><a class="reference internal" href="#where-to-find-plugins">1.2.6.2 Where to find plugins</a></li>
<li><a class="reference internal" href="#how-to-install-a-plugin">1.2.6.3 How to install a plugin</a></li>
<li><a class="reference internal" href="#alternative-plugin-locations">1.2.6.4 Alternative plugin locations</a></li>
<li><a class="reference internal" href="#listing-the-installed-plugins">1.2.6.5 Listing the installed plugins</a></li>
<li><a class="reference internal" href="#popular-plugins">1.2.6.6 Popular plugins</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id24">1.2.7 Путь Bazaar</a><ul>
<li><a class="reference internal" href="#id25">1.2.7.1 Глубокое понимание Bazaar</a></li>
<li><a class="reference internal" href="#id26">1.2.7.2 Понимание номеров ревизий</a></li>
<li><a class="reference internal" href="#hierarchical-history-is-good">1.2.7.3 Hierarchical history is good</a></li>
<li><a class="reference internal" href="#each-branch-has-its-own-view-of-history">1.2.7.4 Each branch has its own view of history</a></li>
<li><a class="reference internal" href="#id29">1.2.7.5 Резюме</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id30">1.3 Личный контроль версий</a><ul>
<li><a class="reference internal" href="#going-solo">1.3.1 Going solo</a><ul>
<li><a class="reference internal" href="#a-personal-productivity-tool">1.3.1.1 A personal productivity tool</a></li>
<li><a class="reference internal" href="#the-solo-workflow">1.3.1.2 The solo workflow</a></li>
</ul>
</li>
<li><a class="reference internal" href="#starting-a-project">1.3.2 Starting a project</a><ul>
<li><a class="reference internal" href="#putting-an-existing-project-under-version-control">1.3.2.1 Putting an existing project under version control</a></li>
<li><a class="reference internal" href="#starting-a-new-project">1.3.2.2 Starting a new project</a></li>
</ul>
</li>
<li><a class="reference internal" href="#controlling-file-registration">1.3.3 Controlling file registration</a><ul>
<li><a class="reference internal" href="#what-does-bazaar-track">1.3.3.1 What does Bazaar track?</a></li>
<li><a class="reference internal" href="#selective-registration">1.3.3.2 Selective registration</a></li>
<li><a class="reference internal" href="#ignoring-files">1.3.3.3 Ignoring files</a></li>
<li><a class="reference internal" href="#global-ignores">1.3.3.4 Global ignores</a></li>
</ul>
</li>
<li><a class="reference internal" href="#reviewing-changes">1.3.4 Reviewing changes</a><ul>
<li><a class="reference internal" href="#looking-before-you-leap">1.3.4.1 Looking before you leap</a></li>
<li><a class="reference internal" href="#bzr-status">1.3.4.2 bzr status</a></li>
<li><a class="reference internal" href="#bzr-diff">1.3.4.3 bzr diff</a></li>
</ul>
</li>
<li><a class="reference internal" href="#recording-changes">1.3.5 Recording changes</a><ul>
<li><a class="reference internal" href="#bzr-commit">1.3.5.1 bzr commit</a></li>
<li><a class="reference internal" href="#message-from-an-editor">1.3.5.2 Message from an editor</a></li>
<li><a class="reference internal" href="#selective-commit">1.3.5.3 Selective commit</a></li>
<li><a class="reference internal" href="#giving-credit-for-a-change">1.3.5.4 Giving credit for a change</a></li>
</ul>
</li>
<li><a class="reference internal" href="#browsing-history">1.3.6 Browsing history</a><ul>
<li><a class="reference internal" href="#bzr-log">1.3.6.1 bzr log</a></li>
<li><a class="reference internal" href="#viewing-merged-revisions">1.3.6.2 Viewing merged revisions</a></li>
<li><a class="reference internal" href="#tuning-the-output">1.3.6.3 Tuning the output</a></li>
<li><a class="reference internal" href="#viewing-the-history-for-a-file">1.3.6.4 Viewing the history for a file</a></li>
<li><a class="reference internal" href="#viewing-an-old-version-of-a-file">1.3.6.5 Viewing an old version of a file</a></li>
<li><a class="reference internal" href="#graphical-history-viewers">1.3.6.6 Graphical history viewers</a></li>
</ul>
</li>
<li><a class="reference internal" href="#releasing-a-project">1.3.7 Releasing a project</a><ul>
<li><a class="reference internal" href="#packaging-a-release">1.3.7.1 Packaging a release</a></li>
<li><a class="reference internal" href="#tagging-a-release">1.3.7.2 Tagging a release</a></li>
</ul>
</li>
<li><a class="reference internal" href="#undoing-mistakes">1.3.8 Undoing mistakes</a><ul>
<li><a class="reference internal" href="#mistakes-happen">1.3.8.1 Mistakes happen</a></li>
<li><a class="reference internal" href="#dropping-the-revision-history-for-a-project">1.3.8.2 Dropping the revision history for a project</a></li>
<li><a class="reference internal" href="#deregistering-a-file-or-directory">1.3.8.3 Deregistering a file or directory</a></li>
<li><a class="reference internal" href="#undoing-changes-since-the-last-commit">1.3.8.4 Undoing changes since the last commit</a></li>
<li><a class="reference internal" href="#undoing-changes-to-a-file-since-the-last-commit">1.3.8.5 Undoing changes to a file since the last commit</a></li>
<li><a class="reference internal" href="#undoing-the-last-commit">1.3.8.6 Undoing the last commit</a></li>
<li><a class="reference internal" href="#undoing-multiple-commits">1.3.8.7 Undoing multiple commits</a></li>
<li><a class="reference internal" href="#reverting-to-the-state-of-an-earlier-version">1.3.8.8 Reverting to the state of an earlier version</a></li>
<li><a class="reference internal" href="#correcting-a-tag">1.3.8.9 Correcting a tag</a></li>
<li><a class="reference internal" href="#clearing-a-tag">1.3.8.10 Clearing a tag</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id34">1.4 Делимся с другими</a><ul>
<li><a class="reference internal" href="#working-with-another">1.4.1 Working with another</a><ul>
<li><a class="reference internal" href="#peer-to-peer-rocks">1.4.1.1 Peer-to-peer rocks</a></li>
<li><a class="reference internal" href="#the-partner-workflow">1.4.1.2 The partner workflow</a></li>
</ul>
</li>
<li><a class="reference internal" href="#branching-a-project">1.4.2 Branching a project</a><ul>
<li><a class="reference internal" href="#branch-urls">1.4.2.1 Branch URLs</a></li>
<li><a class="reference internal" href="#a-reminder-about-shared-repositories">1.4.2.2 Напоминание о разделяемых репозиториях</a></li>
<li><a class="reference internal" href="#the-branch-command">1.4.2.3 The branch command</a></li>
<li><a class="reference internal" href="#time-and-space-considerations">1.4.2.4 Time and space considerations</a></li>
<li><a class="reference internal" href="#viewing-branch-information">1.4.2.5 Viewing branch information</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id36">1.4.3 Merging changes</a><ul>
<li><a class="reference internal" href="#parallel-development">1.4.3.1 Parallel development</a></li>
<li><a class="reference internal" href="#the-merge-command">1.4.3.2 The merge command</a></li>
<li><a class="reference internal" href="#how-does-merging-work">1.4.3.3 How does merging work?</a></li>
<li><a class="reference internal" href="#recording-a-merge">1.4.3.4 Recording a merge</a></li>
<li><a class="reference internal" href="#merge-tracking">1.4.3.5 Merge tracking</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id37">1.4.4 Resolving conflicts</a><ul>
<li><a class="reference internal" href="#workflow">1.4.4.1 Workflow</a></li>
<li><a class="reference internal" href="#listing-conflicts">1.4.4.2 Listing conflicts</a></li>
<li><a class="reference internal" href="#resolving-a-conflict">1.4.4.3 Resolving a conflict</a></li>
<li><a class="reference internal" href="#using-the-remerge-command">1.4.4.4 Using the remerge command</a></li>
<li><a class="reference internal" href="#using-external-tools-to-resolve-conflicts">1.4.4.5 Using external tools to resolve conflicts</a></li>
</ul>
</li>
<li><a class="reference internal" href="#annotating-changes">1.4.5 Annotating changes</a><ul>
<li><a class="reference internal" href="#seeing-the-origin-of-content">1.4.5.1 Seeing the origin of content</a></li>
<li><a class="reference internal" href="#gui-tools">1.4.5.2 GUI tools</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id38">1.5 Сотрудничество в команде, централизованный стиль</a><ul>
<li><a class="reference internal" href="#centralized-development">1.5.1 Centralized development</a><ul>
<li><a class="reference internal" href="#motivation">1.5.1.1 Motivation</a></li>
<li><a class="reference internal" href="#centralized-workflow">1.5.1.2 Centralized workflow</a></li>
</ul>
</li>
<li><a class="reference internal" href="#publishing-a-branch">1.5.2 Publishing a branch</a><ul>
<li><a class="reference internal" href="#setting-up-a-central-repository">1.5.2.1 Setting up a central repository</a></li>
<li><a class="reference internal" href="#starting-a-central-branch">1.5.2.2 Starting a central branch</a></li>
</ul>
</li>
<li><a class="reference internal" href="#using-checkouts">1.5.3 Using checkouts</a><ul>
<li><a class="reference internal" href="#turning-a-branch-into-a-checkout">1.5.3.1 Turning a branch into a checkout</a></li>
<li><a class="reference internal" href="#turning-a-checkout-into-a-branch">1.5.3.2 Turning a checkout into a branch</a></li>
<li><a class="reference internal" href="#getting-a-checkout">1.5.3.3 Getting a checkout</a></li>
<li><a class="reference internal" href="#getting-a-lightweight-checkout">1.5.3.4 Создание легковесной рабочей копии</a></li>
<li><a class="reference internal" href="#updating-to-the-latest-content">1.5.3.5 Updating to the latest content</a></li>
<li><a class="reference internal" href="#handling-commit-failures">1.5.3.6 Handling commit failures</a></li>
</ul>
</li>
<li><a class="reference internal" href="#working-offline-on-a-central-branch">1.5.4 Working offline on a central branch</a><ul>
<li><a class="reference internal" href="#the-centralized-with-local-commits-workflow">1.5.4.1 The centralized with local commits workflow</a></li>
<li><a class="reference internal" href="#committing-locally">1.5.4.2 Committing locally</a></li>
<li><a class="reference internal" href="#being-disconnected-for-long-time-periods">1.5.4.3 Being disconnected for long time periods</a></li>
<li><a class="reference internal" href="#merging-a-series-of-local-commits">1.5.4.4 Merging a series of local commits</a></li>
</ul>
</li>
<li><a class="reference internal" href="#reusing-a-checkout">1.5.5 Reusing a checkout</a><ul>
<li><a class="reference internal" href="#id41">1.5.5.1 Motivation</a></li>
<li><a class="reference internal" href="#changing-where-a-branch-is-bound-to">1.5.5.2 Changing where a branch is bound to</a></li>
<li><a class="reference internal" href="#switching-a-lightweight-checkout">1.5.5.3 Switching a lightweight checkout</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id42">1.6 Сотрудничество в команде, распределенный стиль</a><ul>
<li><a class="reference internal" href="#distributed-development">1.6.1 Distributed development</a><ul>
<li><a class="reference internal" href="#id43">1.6.1.1 Motivation</a></li>
<li><a class="reference internal" href="#the-decentralized-with-shared-mainline-workflow">1.6.1.2 The decentralized with shared mainline workflow</a></li>
</ul>
</li>
<li><a class="reference internal" href="#organizing-branches">1.6.2 Organizing branches</a><ul>
<li><a class="reference internal" href="#mirror-branches">1.6.2.1 Mirror branches</a></li>
<li><a class="reference internal" href="#task-branches">1.6.2.2 Task branches</a></li>
<li><a class="reference internal" href="#refreshing-a-mirror-branch">1.6.2.3 Refreshing a mirror branch</a></li>
<li><a class="reference internal" href="#merging-the-latest-trunk-into-a-feature-branch">1.6.2.4 Merging the latest trunk into a feature branch</a></li>
<li><a class="reference internal" href="#merging-a-feature-into-the-trunk">1.6.2.5 Merging a feature into the trunk</a></li>
<li><a class="reference internal" href="#backing-up-task-branches">1.6.2.6 Backing up task branches</a></li>
</ul>
</li>
<li><a class="reference internal" href="#using-gatekeepers">1.6.3 Using gatekeepers</a><ul>
<li><a class="reference internal" href="#the-decentralized-with-human-gatekeeper-workflow">1.6.3.1 The decentralized with human gatekeeper workflow</a></li>
<li><a class="reference internal" href="#the-decentralized-with-automatic-gatekeeper-workflow">1.6.3.2 The decentralized with automatic gatekeeper workflow</a></li>
</ul>
</li>
<li><a class="reference internal" href="#sending-changes">1.6.4 Sending changes</a><ul>
<li><a class="reference internal" href="#id44">1.6.4.1 Motivation</a></li>
<li><a class="reference internal" href="#understanding-merge-directives">1.6.4.2 Understanding merge directives</a></li>
<li><a class="reference internal" href="#creating-a-merge-directive">1.6.4.3 Creating a merge directive</a></li>
<li><a class="reference internal" href="#applying-a-merge-directive">1.6.4.4 Applying a merge directive</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id46">1.7 Различные темы</a><ul>
<li><a class="reference internal" href="#the-journey-ahead">1.7.1 The journey ahead</a></li>
<li><a class="reference internal" href="#pseudo-merging">1.7.2 Pseudo merging</a><ul>
<li><a class="reference internal" href="#cherrypicking">1.7.2.1 Cherrypicking</a></li>
<li><a class="reference internal" href="#merging-without-parents">1.7.2.2 Merging without parents</a></li>
<li><a class="reference internal" href="#id47">1.7.2.3 Reverse cherrypicking</a></li>
<li><a class="reference internal" href="#merging-uncommitted-changes">1.7.2.4 Merging uncommitted changes</a></li>
<li><a class="reference internal" href="#rebasing">1.7.2.5 Rebasing</a></li>
</ul>
</li>
<li><a class="reference internal" href="#shelving-changes">1.7.3 Shelving Changes</a></li>
<li><a class="reference internal" href="#filtered-views">1.7.4 Filtered views</a><ul>
<li><a class="reference internal" href="#introducing-filtered-views">1.7.4.1 Introducing filtered views</a></li>
<li><a class="reference internal" href="#creating-a-view">1.7.4.2 Creating a view</a></li>
<li><a class="reference internal" href="#listing-the-current-view">1.7.4.3 Listing the current view</a></li>
<li><a class="reference internal" href="#switching-between-views">1.7.4.4 Switching between views</a></li>
<li><a class="reference internal" href="#temporarily-disabling-a-view">1.7.4.5 Temporarily disabling a view</a></li>
<li><a class="reference internal" href="#deleting-views">1.7.4.6 Deleting views</a></li>
<li><a class="reference internal" href="#things-to-be-aware-of">1.7.4.7 Things to be aware of</a></li>
</ul>
</li>
<li><a class="reference internal" href="#using-stacked-branches">1.7.5 Использование стека веток</a><ul>
<li><a class="reference internal" href="#id49">1.7.5.1 Что такое ветка в стеке?</a></li>
<li><a class="reference internal" href="#id50">1.7.5.2 Создание ветки в стеке</a></li>
<li><a class="reference internal" href="#id51">1.7.5.3 Создание рабочего каталога в стеке</a></li>
<li><a class="reference internal" href="#id52">1.7.5.4 Публикация ветки в стеке</a></li>
<li><a class="reference internal" href="#id53">1.7.5.5 Ограничения веток в стеке</a></li>
</ul>
</li>
<li><a class="reference internal" href="#running-a-smart-server">1.7.6 Running a smart server</a><ul>
<li><a class="reference internal" href="#dumb-servers">1.7.6.1 Dumb servers</a></li>
<li><a class="reference internal" href="#high-performance-smart-server">1.7.6.2 High-performance smart server</a><ul>
<li><a class="reference internal" href="#ssh">1.7.6.2.1 SSH</a></li>
<li><a class="reference internal" href="#inetd">1.7.6.2.2 inetd</a></li>
<li><a class="reference internal" href="#dedicated">1.7.6.2.3 Dedicated</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#using-hooks">1.7.7 Using hooks</a><ul>
<li><a class="reference internal" href="#what-is-a-hook">1.7.7.1 What is a hook?</a></li>
<li><a class="reference internal" href="#id54">1.7.7.2 Using hooks</a></li>
<li><a class="reference internal" href="#debugging-hooks">1.7.7.3 Debugging hooks</a></li>
<li><a class="reference internal" href="#example-a-merge-plugin">1.7.7.4 Example: a merge plugin</a></li>
</ul>
</li>
<li><a class="reference internal" href="#exporting-version-information">1.7.8 Exporting version information</a><ul>
<li><a class="reference internal" href="#getting-the-last-revision-number">1.7.8.1 Getting the last revision number</a></li>
<li><a class="reference internal" href="#getting-more-version-information">1.7.8.2 Getting more version information</a></li>
<li><a class="reference internal" href="#python-projects">1.7.8.3 Python projects</a></li>
<li><a class="reference internal" href="#getting-version-info-in-other-formats">1.7.8.4 Getting version info in other formats</a></li>
<li><a class="reference internal" href="#check-clean">1.7.8.5 Check clean</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id55">1.8 Краткое описание некоторых популярных плагинов</a><ul>
<li><a class="reference internal" href="#bzrtools">1.8.1 BzrTools</a><ul>
<li><a class="reference internal" href="#overview">1.8.1.1 Overview</a></li>
<li><a class="reference internal" href="#shell">1.8.1.2 shell</a></li>
<li><a class="reference internal" href="#cdiff">1.8.1.3 cdiff</a></li>
</ul>
</li>
<li><a class="reference internal" href="#bzr-svn">1.8.2 bzr-svn</a><ul>
<li><a class="reference internal" href="#id56">1.8.2.1 Overview</a></li>
<li><a class="reference internal" href="#a-simple-example">1.8.2.2 A simple example</a></li>
<li><a class="reference internal" href="#using-a-central-repository-mirror">1.8.2.3 Using a central repository mirror</a></li>
<li><a class="reference internal" href="#limitations-of-bzr-svn">1.8.2.4 Limitations of bzr-svn</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id57">1.9 Интегрируем Bazaar в нашу среду</a><ul>
<li><a class="reference internal" href="#web-browsing">1.9.1 Web browsing</a><ul>
<li><a class="reference internal" href="#id58">1.9.1.1 Overview</a></li>
</ul>
</li>
<li><a class="reference internal" href="#bug-trackers">1.9.2 Bug trackers</a><ul>
<li><a class="reference internal" href="#associating-commits-and-bugs">1.9.2.1 Associating commits and bugs</a></li>
<li><a class="reference internal" href="#metadata-recording-vs-bug-tracker-updating">1.9.2.2 Metadata recording vs bug tracker updating</a></li>
<li><a class="reference internal" href="#making-corrections">1.9.2.3 Making corrections</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id59">1.10 Приложения</a><ul>
<li><a class="reference internal" href="#id60">1.10.1 Определение ревизий</a><ul>
<li><a class="reference internal" href="#revision-identifiers-and-ranges">1.10.1.1 Revision identifiers and ranges</a></li>
<li><a class="reference internal" href="#available-revision-identifiers">1.10.1.2 Available revision identifiers</a><ul>
<li><a class="reference internal" href="#numbers">1.10.1.2.1 Numbers</a></li>
<li><a class="reference internal" href="#revid">1.10.1.2.2 revid</a></li>
<li><a class="reference internal" href="#before">1.10.1.2.3 before</a></li>
<li><a class="reference internal" href="#date">1.10.1.2.4 date</a></li>
<li><a class="reference internal" href="#ancestor">1.10.1.2.5 Ancestor</a></li>
<li><a class="reference internal" href="#branch">1.10.1.2.6 Branch</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#organizing-your-workspace">1.10.2 Organizing your workspace</a><ul>
<li><a class="reference internal" href="#common-workspace-layouts">1.10.2.1 Common workspace layouts</a></li>
<li><a class="reference internal" href="#lightweight-checkout">1.10.2.2 Lightweight checkout</a></li>
<li><a class="reference internal" href="#standalone-tree">1.10.2.3 Standalone tree</a></li>
<li><a class="reference internal" href="#feature-branches">1.10.2.4 Feature branches</a></li>
<li><a class="reference internal" href="#local-sandbox">1.10.2.5 Local sandbox</a></li>
<li><a class="reference internal" href="#advanced-layouts">1.10.2.6 Advanced layouts</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id62">1.10.3 Advanced shared repository layouts</a><ul>
<li><a class="reference internal" href="#svn-style-trunk-branches">1.10.3.1 »SVN-Style» (<code class="docutils literal notranslate"><span class="pre">trunk/</span></code>, <code class="docutils literal notranslate"><span class="pre">branches/</span></code>)</a><ul>
<li><a class="reference internal" href="#project-trunk">1.10.3.1.1 <code class="docutils literal notranslate"><span class="pre">project/trunk</span></code></a></li>
<li><a class="reference internal" href="#trunk-project">1.10.3.1.2 <code class="docutils literal notranslate"><span class="pre">trunk/project</span></code></a></li>
</ul>
</li>
<li><a class="reference internal" href="#nested-style-project-branch-sub-branch">1.10.3.2 Nested Style (<code class="docutils literal notranslate"><span class="pre">project/branch/sub-branch/</span></code>)</a></li>
<li><a class="reference internal" href="#sorted-by-status-dev-merged-experimental">1.10.3.3 Sorted by Status (<code class="docutils literal notranslate"><span class="pre">dev/</span></code>, <code class="docutils literal notranslate"><span class="pre">merged/</span></code>, <code class="docutils literal notranslate"><span class="pre">experimental/</span></code>)</a></li>
<li><a class="reference internal" href="#sorted-by-date-release-etc-2006-06-2006-07-0-8-0-9">1.10.3.4 Sorted by date/release/etc (<code class="docutils literal notranslate"><span class="pre">2006-06/</span></code>, <code class="docutils literal notranslate"><span class="pre">2006-07/</span></code>, <code class="docutils literal notranslate"><span class="pre">0.8/</span></code>, <code class="docutils literal notranslate"><span class="pre">0.9</span></code>)</a></li>
<li><a class="reference internal" href="#simple-developer-naming-project-joe-foo-project-barry-bar">1.10.3.5 Simple developer naming (<code class="docutils literal notranslate"><span class="pre">project/joe/foo</span></code>, <code class="docutils literal notranslate"><span class="pre">project/barry/bar</span></code>)</a></li>
<li><a class="reference internal" href="#summary">1.10.3.6 Summary</a></li>
</ul>
</li>
<li><a class="reference internal" href="#configuring-email">1.10.4 Configuring email</a><ul>
<li><a class="reference internal" href="#why-set-up-an-email-address-with-bazaar">1.10.4.1 Why set up an email address with Bazaar?</a></li>
<li><a class="reference internal" href="#how-to-set-up-your-email-address">1.10.4.2 How to set up your email address</a></li>
<li><a class="reference internal" href="#setting-email-via-the-whoami-command">1.10.4.3 Setting email via the „whoami“ command</a></li>
<li><a class="reference internal" href="#setting-email-via-default-configuration-file">1.10.4.4 Setting email via default configuration file</a></li>
<li><a class="reference internal" href="#setting-email-on-a-per-branch-basis">1.10.4.5 Setting email on a per-branch basis</a></li>
<li><a class="reference internal" href="#setting-email-via-environment-variable">1.10.4.6 Setting email via environment variable</a></li>
<li><a class="reference internal" href="#concerns-about-spam">1.10.4.7 Concerns about spam</a></li>
</ul>
</li>
<li><a class="reference internal" href="#serving-bazaar-with-apache">1.10.5 Serving Bazaar with Apache</a><ul>
<li><a class="reference internal" href="#example">1.10.5.1 Example</a></li>
<li><a class="reference internal" href="#configuring-apache-2-0">1.10.5.2 Configuring Apache 2.0</a><ul>
<li><a class="reference internal" href="#fastcgi">1.10.5.2.1 FastCGI</a></li>
<li><a class="reference internal" href="#mod-python">1.10.5.2.2 mod_python</a></li>
<li><a class="reference internal" href="#mod-wsgi">1.10.5.2.3 mod_wsgi</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id68">1.10.5.3 Configuring Bazaar</a><ul>
<li><a class="reference internal" href="#id69">1.10.5.3.1 FastCGI</a></li>
<li><a class="reference internal" href="#id70">1.10.5.3.2 mod_python</a></li>
<li><a class="reference internal" href="#id71">1.10.5.3.3 mod_wsgi</a></li>
</ul>
</li>
<li><a class="reference internal" href="#clients">1.10.5.4 Clients</a></li>
<li><a class="reference internal" href="#advanced-configuration">1.10.5.5 Advanced configuration</a><ul>
<li><a class="reference internal" href="#pushing-over-the-http-smart-server">1.10.5.5.1 Pushing over the HTTP smart server</a></li>
</ul>
</li>
</ul>
</li>
<li><a class="reference internal" href="#id72">1.10.6 Writing a plugin</a><ul>
<li><a class="reference internal" href="#introduction">1.10.6.1 Introduction</a></li>
<li><a class="reference internal" href="#creating-a-new-command">1.10.6.2 Creating a new command</a></li>
<li><a class="reference internal" href="#installing-a-hook">1.10.6.3 Installing a hook</a></li>
<li><a class="reference internal" href="#specifying-a-plugin-version-number">1.10.6.4 Specifying a plugin version number</a></li>
<li><a class="reference internal" href="#plugin-searching-rules">1.10.6.5 Plugin searching rules</a></li>
<li><a class="reference internal" href="#more-information">1.10.6.6 More information</a></li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<div role="note" aria-label="source link">
<h3>Эта страница</h3>
<ul class="this-page-menu">
<li><a href="../_sources/user-guide/index-plain.txt"
rel="nofollow">Исходный текст</a></li>
</ul>
</div>
<div id="searchbox" style="display: none" role="search">
<h3>Быстрый поиск</h3>
<div class="searchformwrapper">
<form class="search" action="../search.html" method="get">
<input type="text" name="q" />
<input type="submit" value="Искать" />
<input type="hidden" name="check_keywords" value="yes" />
<input type="hidden" name="area" value="default" />
</form>
</div>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="related" role="navigation" aria-label="related navigation">
<h3>Навигация</h3>
<ul>
<li><a href="http://bazaar.canonical.com/">
<img src="../_static/bzr icon 16.png" /> Главная</a> | </li>
<a href="http://doc.bazaar.canonical.com/ru/">Документация</a> | </li>
<li class="nav-item nav-item-0"><a href="../index.html">Содержание (2.7.0)</a> »</li>
</ul>
</div>
<div class="footer" role="contentinfo">
© Copyright 2009-2011 Canonical Ltd.
Создано с помощью <a href="http://sphinx-doc.org/">Sphinx</a> 1.8.4.
</div>
</body>
</html>
