<!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>集中型ワークフローのチュートリアル — Bazaar 2.6.0 ドキュメント</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 ドキュメント" href="../index.html" />
<link rel="up" title="チュートリアル" href="index.html" />
<link rel="next" title="Licence" href="licence.html" />
<link rel="prev" title="LaunchpadでBazaarを使う" href="using_bazaar_with_launchpad.html" />
</head>
<body>
<div class="related">
<h3>ナビゲーション</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="licence.html" title="Licence"
accesskey="N">次へ</a></li>
<li class="right" >
<a href="using_bazaar_with_launchpad.html" title="LaunchpadでBazaarを使う"
accesskey="P">前へ</a> |</li>
<li><a href="../index.html">目次 (2.6.0)</a> »</li>
<li><a href="index.html" accesskey="U">チュートリアル</a> »</li>
</ul>
</div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="id1">
<h1>集中型ワークフローのチュートリアル<a class="headerlink" href="#id1" title="このヘッドラインへのパーマリンク">¶</a></h1>
<div class="section" id="id2">
<h2>概要<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>
<div class="section" id="id3">
<h2>初期セットアップ<a class="headerlink" href="#id3" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p><a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。</p>
<div class="section" id="e">
<h3>ユーザのEメールの設定<a class="headerlink" href="#e" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr whoami "John Doe <jdoe@organization.com>"
</pre></div>
</div>
</div>
<div class="section" id="id4">
<h3>ローカルリポジトリのセットアップ<a class="headerlink" href="#id4" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p><a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。
最適化の方法の一つとして、関連するブランチ同士の情報を統合して、新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。</p>
<p>そのための一番いい方法は、 <a class="reference internal" href="#id16">共用リポジトリ</a> を作成することです。
一般に、 <a class="reference internal" href="#id16">共用リポジトリ</a> のサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。
ですので、ホームディレクトリに <a class="reference internal" href="#id16">共用リポジトリ</a> を作成するようにしましょう。
そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr init-repo --trees ~
</pre></div>
</div>
</div>
<div class="section" id="id5">
<h3>リモートリポジトリのセットアップ<a class="headerlink" href="#id5" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。
集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。
たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。)
実際のところ、これは、特に職場ではとてもよい設定です。
蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こってもコミットされたデータはけっして無くなりません。</p>
<p>それでは、プロジェクト内で共有する <tt class="docutils literal"><span class="pre">centralhost</span></tt> というマシーンを用意しましょう。
先ほども言いましたが、ディスクの使用量を節約するために、 <a class="reference internal" href="#id16">共用リポジトリ</a> を使用します。</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
</pre></div>
</div>
<p>この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。
<tt class="docutils literal"><span class="pre">--no-tree</span></tt> オプションの指定によって、ワーキングツリーを作らないようになります。
中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。</p>
<p>ここで、 <tt class="docutils literal"><span class="pre">bzr+ssh</span></tt> というURLを使っていますが、これは、 SSH セキュアシェ
ル上の
Bazaar 独自プロトコルを意味しています。 bzr+ssh サーバーのセットアップに関
する
情報に着いては、管理者向けガイドを参照してください。</p>
</div>
</div>
<div class="section" id="id6">
<h2>既存のプロジェクトからの移行<a class="headerlink" href="#id6" 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">Tracking Upstream</a> の”Converting and keeping history”セクションを見てください。</p>
<div class="section" id="developer-1">
<h3>Developer 1: 最初のリビジョンを作成する<a class="headerlink" href="#developer-1" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。
仮に、”sigil”というプロジェクトをバージョン管理しようとしているとしましょう。</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr init bzr+ssh://centralhost/srv/bzr/sigil
</pre></div>
</div>
<p>これは、CVSで言うところの”HEAD”ブランチ、Subversionなら”trunk”にあたるものだと考えてかまいません。
これを <tt class="docutils literal"><span class="pre">dev</span></tt> ブランチと呼ぶことにしましょう。</p>
<p>他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。
同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~
% mkdir work
% cd work
% mkdir sigil
% cd sigil
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
% cd dev
% cp -ar ~/sigil/* .
% bzr add
% bzr commit -m "Initial import of Sigil"
</pre></div>
</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>この場合、リモートブランチのチェックアウトを持っているので、 <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="developer-n">
<h3>Developer N: プロジェクトの作業コピーを取得する<a class="headerlink" href="#developer-n" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、他のみんなは単にそのブランチをチェックアウトするだけです。
<strong>ただし、</strong> <a class="reference internal" href="#e">ユーザのEメールの設定</a> <strong>と</strong> <a class="reference internal" href="#id4">ローカルリポジトリのセットアップ</a> <strong>は見ておいてください。</strong></p>
<p>現在開発中のツリーのコピーを取得するためには:</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~/work/sigil
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
</pre></div>
</div>
<p>今、二人の人が <tt class="docutils literal"><span class="pre">bzr+ssh://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="id7">
<h2>別ブランチでの開発<a class="headerlink" href="#id7" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>ここまでは、全員が同じブランチで作業して、変更をコミットしていました。
これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があるということです。
また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、全員が問題を抱えることになります。</p>
<p>たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合するというやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。
CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、ブランチ間できちんと同期がとれた状態に保つのは難しいことです。
<a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を適用することができます。</p>
<div class="section" id="id8">
<h3>新しいブランチを作成してそこで作業する<a class="headerlink" href="#id8" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。
そこで、 <tt class="docutils literal"><span class="pre">centralhost</span></tt> 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~/work/sigil
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
% cd doodle-fixes
</pre></div>
</div>
<p>これで、 <tt class="docutils literal"><span class="pre">doodle</span></tt> に必要な修正を当てるための場所ができました。
また、他の部分の修正をする人に邪魔されることもありません。
チェックアウトを持っているため、 <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="id9">[1]</a> <tt class="docutils literal"><span class="pre">dev</span></tt> ブランチと同じように、このようなブランチ上で二人の開発者が共同で作業することもできます。
<a class="footnote-reference" href="#cbranch" id="id10">[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="#id9">[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="#id10">1</a>, <a class="fn-backref" href="#id14">2</a>)</em> たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。
この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> の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:</td></tr>
</tbody>
</table>
<div class="highlight-python"><div class="highlight"><pre>% bzr cbranch dev my-feature-branch
</pre></div>
</div>
</div>
<div class="section" id="id11">
<h3>変更内容をマージする<a class="headerlink" href="#id11" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p><tt class="docutils literal"><span class="pre">doodle-fixes</span></tt> での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。:</p>
<div class="highlight-python"><div class="highlight"><pre>% cd ~/work/sigil/dev
% bzr merge ../doodle-fixes
</pre></div>
</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="id12">[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="#id12">[3]</a></td><td>マージ実行中に競合の解決をさせるシステムもあります。
私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単であることに気づきました。
そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。</td></tr>
</tbody>
</table>
</div>
<div class="section" id="id13">
<h3>推奨のブランチ構成<a class="headerlink" href="#id13" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの作業領域を用意するという方法があります。これは以下のコマンドでできます。:</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
bzr+ssh://centralhost/srv/bzr/sigil/user-a
% bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
bzr+ssh://centralhost/srv/bzr/sigil/user-b
</pre></div>
</div>
<p>これで、開発者ごとに専用の作業用ブランチを割り当てています。
さらに、開発者自身で <a class="footnote-reference" href="#cbranch" id="id14">[2]</a> を使用して新しく新機能開発用ブランチを作成することも簡単にできます。</p>
<div class="highlight-python"><div class="highlight"><pre>% bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
% cd ~/work/sigil
% bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
</pre></div>
</div>
</div>
</div>
<div class="section" id="id15">
<h2>用語解説<a class="headerlink" href="#id15" title="このヘッドラインへのパーマリンク">¶</a></h2>
<div class="section" id="id16">
<h3>共用リポジトリ<a class="headerlink" href="#id16" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p><a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ旧来の概念に似ています。
たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は全くなく、作業ツリーのファイルのチェックアウトがあるだけです。
ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。
開発者間でも共用される <em>かも知れません</em> が、開発者間での共用はスタンドアロンブランチでも可能です。</p>
<p><a class="reference external" href="http://bazaar.canonical.com">Bazaar</a> の用語では、”共用リポジトリ”とは複数のブランチが履歴情報を <strong>共有</strong> できる場所のことです。
分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。
しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方がいいためです。</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="#">集中型ワークフローのチュートリアル</a><ul>
<li><a class="reference internal" href="#id2">概要</a></li>
<li><a class="reference internal" href="#id3">初期セットアップ</a><ul>
<li><a class="reference internal" href="#e">ユーザのEメールの設定</a></li>
<li><a class="reference internal" href="#id4">ローカルリポジトリのセットアップ</a></li>
<li><a class="reference internal" href="#id5">リモートリポジトリのセットアップ</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id6">既存のプロジェクトからの移行</a><ul>
<li><a class="reference internal" href="#developer-1">Developer 1: 最初のリビジョンを作成する</a></li>
<li><a class="reference internal" href="#developer-n">Developer N: プロジェクトの作業コピーを取得する</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id7">別ブランチでの開発</a><ul>
<li><a class="reference internal" href="#id8">新しいブランチを作成してそこで作業する</a></li>
<li><a class="reference internal" href="#id11">変更内容をマージする</a></li>
<li><a class="reference internal" href="#id13">推奨のブランチ構成</a></li>
</ul>
</li>
<li><a class="reference internal" href="#id15">用語解説</a><ul>
<li><a class="reference internal" href="#id16">共用リポジトリ</a></li>
</ul>
</li>
</ul>
</li>
</ul>
<h4>前のトピックへ</h4>
<p class="topless"><a href="using_bazaar_with_launchpad.html"
title="前の章へ">LaunchpadでBazaarを使う</a></p>
<h4>次のトピックへ</h4>
<p class="topless"><a href="licence.html"
title="次の章へ">Licence</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="licence.html" title="Licence"
>次へ</a></li>
<li class="right" >
<a href="using_bazaar_with_launchpad.html" title="LaunchpadでBazaarを使う"
>前へ</a> |</li>
<li><a href="../index.html">目次 (2.6.0)</a> »</li>
<li><a href="index.html" >チュートリアル</a> »</li>
</ul>
</div>
<div class="footer">
© Copyright 2009-2011 Canonical Ltd.
このドキュメントは <a href="http://sphinx-doc.org/">Sphinx</a> 1.2.3 で生成しました。
</div>
</body>
</html>
distrib
>
Mageia
>
5
>
i586
>
media
>
core-updates
>
by-pkgid
>
27647990744ebd9cfe32398f37f67e20
>
files
>
3321
