<!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"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>1 Работа в централизованном стиле — Bazaar 2.6.0 documentation</title> <link rel="stylesheet" href="../_static/default.css" type="text/css" /> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" /> <script type="text/javascript"> var DOCUMENTATION_OPTIONS = { URL_ROOT: '../', VERSION: '2.6.0', COLLAPSE_INDEX: false, FILE_SUFFIX: '.html', HAS_SOURCE: true }; </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/translations.js"></script> <link rel="shortcut icon" href="../_static/bzr.ico"/> <link rel="top" title="Bazaar 2.6.0 documentation" href="../index.html" /> <link rel="prev" title="1 Использование Bazaar с Launchpad" href="using_bazaar_with_launchpad.html" /> </head> <body> <div class="related"> <h3>Просмотр</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="using_bazaar_with_launchpad.html" title="1 Использование Bazaar с Launchpad" accesskey="P">предыдущий</a></li> <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><a href="../index.html">Содержание (2.6.0)</a> »</li> </ul> </div> <div class="document"> <div class="documentwrapper"> <div class="bodywrapper"> <div class="body"> <div class="section" id="id1"> <h1><a class="toc-backref" href="#id20">1 Работа в централизованном стиле</a><a class="headerlink" href="#id1" title="Ссылка на этот заголовок">¶</a></h1> <div class="section" id="id2"> <h2><a class="toc-backref" href="#id21">1.1 Обзор</a><a class="headerlink" href="#id2" title="Ссылка на этот заголовок">¶</a></h2> <p>Этот документ описывает один из возможных подходов к использованию <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>. А именно, использование распределенной системы контроля версий <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>, в централизованном стиле. <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> разработана, что бы быть гибкой и допускать различные подходы к работе, начиная от полностью децентрализованного, до практически централизованного. Подход описанный здесь позволяет новым пользователям проще вникнуть в более продвинутое использование <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> и смешивать централизованные и децентрализованные операции.</p> <p>В общем случае, данный документ интересен для пользователей переходящих с централизованных систем, таких как CVS, или Subversion. В таких системах обычно есть единственный центральный сервер на котором хранится код проекта и участники команды работают над этим кодом, синхронизируя свою работу. Такой режим так же подходит для разработчика-одиночки, работающего на нескольких различных машинах.</p> <div class="contents topic" id="id3"> <p class="topic-title first">Содержание</p> <ul class="auto-toc simple"> <li><a class="reference internal" href="#id1" id="id20">1 Работа в централизованном стиле</a><ul class="auto-toc"> <li><a class="reference internal" href="#id2" id="id21">1.1 Обзор</a></li> <li><a class="reference internal" href="#id4" id="id22">1.2 Начальные установки</a><ul class="auto-toc"> <li><a class="reference internal" href="#e-mail" id="id23">1.2.1 Настройка e-mail пользователя</a></li> <li><a class="reference internal" href="#id5" id="id24">1.2.2 Настройка локального репозитория</a></li> <li><a class="reference internal" href="#id6" id="id25">1.2.3 Настройка удаленного репозитория</a></li> </ul> </li> <li><a class="reference internal" href="#id7" id="id26">1.3 Миграция рабочего проекта в Bazaar</a><ul class="auto-toc"> <li><a class="reference internal" href="#id9" id="id27">1.3.1 Разработчик 1: Создание первой ревизии</a></li> <li><a class="reference internal" href="#n" id="id28">1.3.2 Разработчик N: Получение рабочей копии проекта</a></li> </ul> </li> <li><a class="reference internal" href="#id10" id="id29">1.4 Разработка на отдельных ветках</a><ul class="auto-toc"> <li><a class="reference internal" href="#id11" id="id30">1.4.1 Создание и работа на новой ветке</a></li> <li><a class="reference internal" href="#id14" id="id31">1.4.2 Объединение изменений обратно</a></li> <li><a class="reference internal" href="#id16" id="id32">1.4.3 Рекомендации по созданию веток</a></li> </ul> </li> <li><a class="reference internal" href="#id18" id="id33">1.5 Глоссарий</a><ul class="auto-toc"> <li><a class="reference internal" href="#id19" id="id34">1.5.1 Разделяемый репозиторий</a></li> </ul> </li> </ul> </li> </ul> </div> </div> <div class="section" id="id4"> <h2><a class="toc-backref" href="#id22">1.2 Начальные установки</a><a class="headerlink" href="#id4" title="Ссылка на этот заголовок">¶</a></h2> <p>В самом начале, для более удобной работы с <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>, желательно осуществить достаточно простые шаги по настройке.</p> <div class="section" id="e-mail"> <h3><a class="toc-backref" href="#id23">1.2.1 Настройка e-mail пользователя</a><a class="headerlink" href="#e-mail" title="Ссылка на этот заголовок">¶</a></h3> <p>Строка идентифицирующая пользователя сохраняется при каждой фиксации. Хотя она не обязательно должна быть аккуратной или уникальной она будет использоваться в сообщениях журнала и аннотациях, таким образом лучше что бы она была похожа на что-то реальное.</p> <div class="highlight-python"><pre>% bzr whoami "Иван Пупкин <ivan@pupkin.ru>"</pre> </div> </div> <div class="section" id="id5"> <h3><a class="toc-backref" href="#id24">1.2.2 Настройка локального репозитория</a><a class="headerlink" href="#id5" title="Ссылка на этот заголовок">¶</a></h3> <p>В общем случае ветки <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> копируют полную историю изменений вместе с собой, что, кстати, позволяет работать в полностью децентрализованном стиле. Как оптимизация для связанных веток возможно объединять их хранилища таким образом, что отпадает необходимость в копировании полной истории изменений при создании новой ветки.</p> <p>Лучший способ сделать это - создать <a class="reference internal" href="#id19">Разделяемый репозиторий</a>. В общем случае, ветки будут разделять хранилище если они находятся в подкаталоге этого репозитория. Давайте создадим <a class="reference internal" href="#id19">Разделяемый репозиторий</a> в нашем домашнем каталоге и таким образом все ветки которые мы будем создавать под ним будут разделять хранилище истории.</p> <div class="highlight-python"><pre>% bzr init-repo --trees ~</pre> </div> </div> <div class="section" id="id6"> <h3><a class="toc-backref" href="#id25">1.2.3 Настройка удаленного репозитория</a><a class="headerlink" href="#id6" title="Ссылка на этот заголовок">¶</a></h3> <p>Во многих случаях нужно создавать место где данные хранятся отдельно от рабочего каталога. Такой подход необходим для централизованных систем (CVS/SVN). Обычно эти каталоги находятся на различных машинах, хотя и не всегда. На самом деле это достаточно хороший подход, особенно в рабочей среде. Так как здесь существует центральная точка, где могут быть сохранены все данные и даже если что-то случится с машиной разработчика зафиксированная работа не будет потеряна.</p> <p>Давайте создадим разделяемое место для нашего проекта на удаленной машине и назовем его <tt class="docutils literal"><span class="pre">centralhost</span></tt>. Мы снова используем <a class="reference internal" href="#id19">Разделяемый репозиторий</a> для оптимизации использования дисков.</p> <div class="highlight-python"><pre>% bzr init-repo --no-trees sftp://centralhost/srv/bzr/</pre> </div> <p>Можно рассматривать этот шаг как похожий на установку CVSROOT, или репозитория Subversion. Опция <tt class="docutils literal"><span class="pre">--no-trees</span></tt> указывает Bazaar не создавать рабочий каталог в репозитории. Нам это подходит, т.к. никто не будет напрямую что-то изменять на ветках в центральном репозитории.</p> </div> </div> <div class="section" id="id7"> <h2><a class="toc-backref" href="#id26">1.3 Миграция рабочего проекта в Bazaar</a><a class="headerlink" href="#id7" title="Ссылка на этот заголовок">¶</a></h2> <p>Теперь, когда у нас есть репозиторий давайте создадим проект под контролем версий. В большинстве случаев у вас уже есть какой-то код с которым вы работаете и для хранения которого вы хотели бы использовать <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a>. Если код изначально уже был под контролем версий существует много способов конвертировать проект в <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> без потери истории изменений. Но эти способы находятся вне тем рассматриваемых в данном документе. Смотрите <a class="reference external" href="http://wiki.bazaar.canonical.com/TrackingUpstream">Отслеживание изменений на основной ветке</a> для некоторых способов (секция “Конвертирование и сохранение истории”).</p> <div class="section" id="id9"> <h3><a class="toc-backref" href="#id27">1.3.1 Разработчик 1: Создание первой ревизии</a><a class="headerlink" href="#id9" title="Ссылка на этот заголовок">¶</a></h3> <p>Сначала нам нужно создать ветку в нашем удаленном репозитории, там где мы хотели бы хранить наш проект. Допустим, что у нас уже есть проект “sigil”, который мы хотели бы хранить под контролем версий.</p> <div class="highlight-python"><pre>% bzr init sftp://centralhost/srv/bzr/sigil</pre> </div> <p>Это можно рассматривать как ветку “HEAD” в терминах CVS, или как “trunk” в терминах Subversion. Назовем это веткой разработки <tt class="docutils literal"><span class="pre">dev</span></tt>.</p> <p>Я предпочитаю работать в подкаталоге моего домашнего каталога, что бы избегать коллизий со всеми другими файлами которые в ней находятся. Также нам понадобится каталог для проекта где мы сможем хранить различные ветки проекта над которыми работаем.</p> <div class="highlight-python"><pre>% cd ~ % mkdir work % cd work % mkdir sigil % cd sigil % bzr checkout sftp://centralhost/srv/bzr/sigil dev % cd dev % cp -ar ~/sigil/* . % bzr add % bzr commit -m "Первый импорт Sigil"</pre> </div> <p>Выше мы создали пустую ветку <tt class="docutils literal"><span class="pre">/sigil</span></tt> на <tt class="docutils literal"><span class="pre">centralhost</span></tt> и затем загрузили эту пустую ветку на нашу рабочую машину что бы добавить файлы из нашего старого проекта. Есть много способов настроить свой рабочий каталог, но шаги выше упрощают дальнейшую работу с ветками для работы над ошибками, или новыми функциями. И одна из наиболее сильных сторон <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> - это именно отличная работа с ветками.</p> <p>На этом этапе, т.к. мы создали рабочую копию (checkout) удаленной ветки, все фиксации которые будут сделаны в <tt class="docutils literal"><span class="pre">~/work/sigil/dev/</span></tt> будут автоматически сохранены и локально и на <tt class="docutils literal"><span class="pre">centralhost</span></tt>.</p> </div> <div class="section" id="n"> <h3><a class="toc-backref" href="#id28">1.3.2 Разработчик N: Получение рабочей копии проекта</a><a class="headerlink" href="#n" title="Ссылка на этот заголовок">¶</a></h3> <p>Так как первый разработчик проделал всю работу по созданию проекта все остальные разработчики могут просто получить рабочую копию ветки. Хотя <strong>они все еще должны следовать</strong> разделам <a class="reference internal" href="#e-mail">Настройка e-mail пользователя</a> и <a class="reference internal" href="#id5">Настройка локального репозитория</a>.</p> <p>Получим рабочую копию текущего дерева разработки:</p> <div class="highlight-python"><pre>% cd ~/work/sigil % bzr checkout sftp://centralhost/srv/bzr/sigil dev</pre> </div> <p>Теперь, когда два человека имею рабочую копию <tt class="docutils literal"><span class="pre">sftp://centralhost/srv/bzr/sigil</span></tt> будут ситуации когда одна из копий будет не синхронизирована с текущей версией. Во время фиксации <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> проинформирует пользователя об этом и не допустит фиксации. Для получения последних изменений нужно использовать <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">update</span></tt>. Эта команда может потребовать разрешения конфликтов если были изменены одни и те же файлы.</p> </div> </div> <div class="section" id="id10"> <h2><a class="toc-backref" href="#id29">1.4 Разработка на отдельных ветках</a><a class="headerlink" href="#id10" title="Ссылка на этот заголовок">¶</a></h2> <p>До этого момента все работали и фиксировали изменения на одну и ту же ветку. Это значит, что каждый должен периодически обновлять свою ветку и иметь дело с изменениями других разработчиков. Так же если один разработчик фиксирует что-то, что приводит к ошибкам, то после синхронизации эта проблема коснется каждого.</p> <p>Обычно лучше вести разработку на различных ветках и затем, как только изменения достаточно стабильны, интегрировать их обратно на основную ветку. Это одно из наибольших изменений по сравнению с работой в CVS/SVN. Обе эти системы позволяют работать с отдельными ветками, но их алгоритмы объединения достаточно слабы и поэтому с ними сложно держать все синхронизировано. <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> отслеживает что уже было объединено и может даже прикладывать изменения к файлам которые были переименованы.</p> <div class="section" id="id11"> <h3><a class="toc-backref" href="#id30">1.4.1 Создание и работа на новой ветке</a><a class="headerlink" href="#id11" title="Ссылка на этот заголовок">¶</a></h3> <p>Мы бы хотели, что бы наши изменения были доступны другим даже если они пока еще не закончены. Таким образом мы создадим новую публичную ветку на <tt class="docutils literal"><span class="pre">centralhost</span></tt> и будем отслеживать ее локально.</p> <div class="highlight-python"><pre>% cd ~/work/sigil % bzr branch sftp://centralhost/srv/bzr/sigil \ sftp://centralhost/srv/bzr/sigil/doodle-fixes % bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes % cd doodle-fixes</pre> </div> <p>Теперь у нас есть место где мы можем исправлять все ошибки для <tt class="docutils literal"><span class="pre">doodle</span></tt>. И мы не будем прерывать никого кто работает над другими частями кода. Так как у нас есть рабочая копия (checkout) все фиксации которые мы делаем на <tt class="docutils literal"><span class="pre">~/work/sigil/doodle-fixes/</span></tt> так же появятся и на <tt class="docutils literal"><span class="pre">centralhost</span></tt>. <a class="footnote-reference" href="#nestedbranches" id="id12">[1]</a> Также возможно, что бы два разработчика совместно работали над одной из этих веток, так же как они совместно работают над веткой <tt class="docutils literal"><span class="pre">dev</span></tt>. <a class="footnote-reference" href="#cbranch" id="id13">[2]</a></p> <table class="docutils footnote" frame="void" id="nestedbranches" rules="none"> <colgroup><col class="label" /><col /></colgroup> <tbody valign="top"> <tr><td class="label"><a class="fn-backref" href="#id12">[1]</a></td><td>Может показаться странным иметь ветку в подкаталоге другой ветки. Но это нормально, можно думать об этом как о иерархическом пространстве имен где вложенная ветка является производной от внешней ветки.</td></tr> </tbody> </table> <table class="docutils footnote" frame="void" id="cbranch" rules="none"> <colgroup><col class="label" /><col /></colgroup> <tbody valign="top"> <tr><td class="label">[2]</td><td><em>(<a class="fn-backref" href="#id13">1</a>, <a class="fn-backref" href="#id17">2</a>)</em> <p>Когда используется множество независимых веток каждый раз набирать полный URL занимает много времени. Мы рассматриваем различные методы, что бы обойти это, например псевдонимы для веток и т.п. Но пока плагин <a class="reference external" href="http://wiki.bazaar.canonical.com/BzrTools">bzrtools</a> предоставляет команду <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">cbranch</span></tt>. Эта команда на основе базовой ветки создает новую публичную ветку и рабочую копию этой ветки всего одной командой. Конфигурирование <tt class="docutils literal"><span class="pre">cbranch</span></tt> не входит в рамки описания этого документа, но финальная команда выглядит следующим образом:</p> <div class="last highlight-python"><pre>% bzr cbranch dev my-feature-branch</pre> </div> </td></tr> </tbody> </table> </div> <div class="section" id="id14"> <h3><a class="toc-backref" href="#id31">1.4.2 Объединение изменений обратно</a><a class="headerlink" href="#id14" title="Ссылка на этот заголовок">¶</a></h3> <p>Когда решено что некоторые изменения из <tt class="docutils literal"><span class="pre">doodle-fixes</span></tt> готовы для объединения на основную ветку нужно просто сделать следующее:</p> <div class="highlight-python"><pre>% cd ~/work/sigil/dev % bzr merge ../doodle-fixes</pre> </div> <p>Теперь изменения доступны на ветке <tt class="docutils literal"><span class="pre">dev</span></tt>, но они пока еще не были зафиксированы. В этот момент нужно просмотреть финальные изменения и проверить, что код компилируется и проходят все тесты. Команды <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">status</span></tt> и <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">diff</span></tt> хорошие инструменты для этого. Так же нужно разрешить возможные конфликты. <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> не допустит фиксации пока не будут разрешены все конфликты. В этом случае вы случайно не зафиксируете маркеры конфликта. Команда <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">status</span></tt> покажет конфликты и изменения, или можно использовать <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">conflicts</span></tt> что бы увидеть только конфликты. Используйте <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">resolve</span> <span class="pre">file/name</span></tt>, или <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">resolve</span> <span class="pre">--all</span></tt> как только конфликты были разрешены. <a class="footnote-reference" href="#resolve" id="id15">[3]</a> Если существуют конфликты которые особенно сложно разрешить можно использовать команду <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">remerge</span></tt>. Эта команда позволит использовать другие алгоритмы объединения и также позволит увидеть строки оригинального кода (<tt class="docutils literal"><span class="pre">--show-base</span></tt>).</p> <table class="docutils footnote" frame="void" id="resolve" rules="none"> <colgroup><col class="label" /><col /></colgroup> <tbody valign="top"> <tr><td class="label"><a class="fn-backref" href="#id15">[3]</a></td><td>Некоторые системы позволяют разрешать конфликты как часть процесса объединения. Мы обнаружили, что обычно проще разрешать конфликты когда можно просматривать полное дерево, а не только отдельные файлы. Это дает намного больше контекста и также позволяет запускать тесты когда проблема будет решена.</td></tr> </tbody> </table> </div> <div class="section" id="id16"> <h3><a class="toc-backref" href="#id32">1.4.3 Рекомендации по созданию веток</a><a class="headerlink" href="#id16" title="Ссылка на этот заголовок">¶</a></h3> <p>Один из часто используемых способов работы с набором веток - это дать каждому разработчику свою собственную ветку и собственное место для работы на центральном сервере. Это можно сделать так:</p> <div class="highlight-python"><pre>% bzr branch sftp://centralhost/srv/bzr/sigil \ sftp://centralhost/srv/bzr/sigil/user-a % bzr branch sftp://centralhost/srv/bzr/sigil \ sftp://centralhost/srv/bzr/sigil/user-b</pre> </div> <p>Это дает каждому разработчику собственную ветку для работы. И они смогут легко создать новые ветки с помощью <a class="footnote-reference" href="#cbranch" id="id17">[2]</a></p> <div class="highlight-python"><pre>% bzr branch sftp://centralhost/srv/bzr/sigil/user-a \ sftp://centralhost/srv/bzr/sigil/user-a/feature % cd ~/work/sigil % bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature</pre> </div> </div> </div> <div class="section" id="id18"> <h2><a class="toc-backref" href="#id33">1.5 Глоссарий</a><a class="headerlink" href="#id18" title="Ссылка на этот заголовок">¶</a></h2> <div class="section" id="id19"> <h3><a class="toc-backref" href="#id34">1.5.1 Разделяемый репозиторий</a><a class="headerlink" href="#id19" title="Ссылка на этот заголовок">¶</a></h3> <p><a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> поддерживает концепцию “Разделяемый репозиторий”. Эта концепция похожа на традиционные концепции репозиториев в других системах контроля версий, таких как CVS, или Subversion. Например, в Subversion у вас есть удаленный репозиторий, где хранится вся история и локально история не хранится, а хранится только рабочая копия файлов. Конечно “Разделяемый” в данном контексте значит, что он разделен между ветками. Он <em>может</em> быть разделен между людьми, но отдельные ветки также могут быть разделены между людьми.</p> <p>В <a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> термин “Разделяемый репозиторий” - это место где несколько веток могут <em>разделять</em> их историю ревизий. Что бы поддерживать децентрализованную схему работы каждая ветка может хранить свою собственную историю ревизий. Но часто это не эффективно, т.к. зависимые ветки разделяют историю и они могут так же разделять и хранилище истории.</p> </div> </div> </div> </div> </div> </div> <div class="sphinxsidebar"> <div class="sphinxsidebarwrapper"> <h3><a href="../index.html">Содержание</a></h3> <ul> <li><a class="reference internal" href="#">1 Работа в централизованном стиле</a><ul> <li><a class="reference internal" href="#id2">1.1 Обзор</a></li> <li><a class="reference internal" href="#id4">1.2 Начальные установки</a><ul> <li><a class="reference internal" href="#e-mail">1.2.1 Настройка e-mail пользователя</a></li> <li><a class="reference internal" href="#id5">1.2.2 Настройка локального репозитория</a></li> <li><a class="reference internal" href="#id6">1.2.3 Настройка удаленного репозитория</a></li> </ul> </li> <li><a class="reference internal" href="#id7">1.3 Миграция рабочего проекта в Bazaar</a><ul> <li><a class="reference internal" href="#id9">1.3.1 Разработчик 1: Создание первой ревизии</a></li> <li><a class="reference internal" href="#n">1.3.2 Разработчик N: Получение рабочей копии проекта</a></li> </ul> </li> <li><a class="reference internal" href="#id10">1.4 Разработка на отдельных ветках</a><ul> <li><a class="reference internal" href="#id11">1.4.1 Создание и работа на новой ветке</a></li> <li><a class="reference internal" href="#id14">1.4.2 Объединение изменений обратно</a></li> <li><a class="reference internal" href="#id16">1.4.3 Рекомендации по созданию веток</a></li> </ul> </li> <li><a class="reference internal" href="#id18">1.5 Глоссарий</a><ul> <li><a class="reference internal" href="#id19">1.5.1 Разделяемый репозиторий</a></li> </ul> </li> </ul> </li> </ul> <h4>Предыдущий раздел</h4> <p class="topless"><a href="using_bazaar_with_launchpad.html" title="предыдущая глава">1 Использование Bazaar с Launchpad</a></p> <h3>На этой странице</h3> <ul class="this-page-menu"> <li><a href="../_sources/tutorials/centralized_workflow.txt" rel="nofollow">Показать исходный текст</a></li> </ul> <div id="searchbox" style="display: none"> <h3>Быстрый поиск</h3> <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> <p class="searchtip" style="font-size: 90%"> Введите слова для поиска или имя модуля, класса или функции. </p> </div> <script type="text/javascript">$('#searchbox').show(0);</script> </div> </div> <div class="clearer"></div> </div> <div class="related"> <h3>Просмотр</h3> <ul> <li class="right" style="margin-right: 10px"> <a href="using_bazaar_with_launchpad.html" title="1 Использование Bazaar с Launchpad" >предыдущий</a></li> <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><a href="../index.html">Содержание (2.6.0)</a> »</li> </ul> </div> <div class="footer"> © Copyright 2009-2011 Canonical Ltd. При создании использован <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.1.3. </div> </body> </html>