<!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="Bazaarユーザーガイド" href="index.html" />
<link rel="next" title="Eメールを設定する" href="setting_up_email.html" />
<link rel="prev" title="作業スペースを構成する" href="organizing_your_workspace.html" />
</head>
<body>
<div class="related">
<h3>ナビゲーション</h3>
<ul>
<li class="right" style="margin-right: 10px">
<a href="setting_up_email.html" title="Eメールを設定する"
accesskey="N">次へ</a></li>
<li class="right" >
<a href="organizing_your_workspace.html" title="作業スペースを構成する"
accesskey="P">前へ</a> |</li>
<li><a href="../index.html">目次 (2.6.0)</a> »</li>
<li><a href="index.html" accesskey="U">Bazaarユーザーガイド</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>
<p>Bazaarは共用ブランチ内部のブランチのレイアウトを柔軟に決められるように設計されました。
この柔軟性によってユーザーはBazaarを自分のワークフローに合わせることができますが、”よい”レイアウトとは何かということを疑問に持つようになります。
ここでは代わりになるものをいくつか説明しそれぞれの利点を検討します。</p>
<p>言及すべき重要な点はよいレイアウトは”一般的な”ユーザーが理解できるように
ブランチの内容を何らかの形でハイライトします。
SVNにおいて これは “<tt class="docutils literal"><span class="pre">trunk/</span></tt>” ブランチであると考えられ、
大抵のレイアウトではこの命名規約が守られています。
これを “<tt class="docutils literal"><span class="pre">mainline</span></tt>” もしくは “<tt class="docutils literal"><span class="pre">dev</span></tt>” と呼ぶ人もいれば、
CVSから来た人々はしばし “<tt class="docutils literal"><span class="pre">HEAD</span></tt>” と言及します。</p>
<div class="section" id="svn-trunk-branches">
<h2>“SVN形式” (<tt class="docutils literal"><span class="pre">trunk/</span></tt>, <tt class="docutils literal"><span class="pre">branches/</span></tt>)<a class="headerlink" href="#svn-trunk-branches" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>SVNからやってきた人々は次のような”標準的な”プロジェクトのレイアウトに慣れています:</p>
<div class="highlight-python"><div class="highlight"><pre>repository/ # リポジトリ全体
+- trunk/ # 開発のメインライン
+- branches/ # コンテナディレクトリ
| +- foo/ # 開発中のfoo機能用ブランチ
| ...
+- tags/ # コンテナディレクトリ
+- release-X # 特定のリリースバージョンをマークするために専用ブランチ
...
</pre></div>
</div>
<p>Bazaarでは、これは完全に適切なレイアウトです。
SVNからやって来た人が慣れ親しめることが利点で開発の焦点を当てる場所が明確になります。</p>
<p>同じリポジトリで複数のプロジェクトを持つとき、SVNのレイアウトは何を行うのか少し不透明です。</p>
<div class="section" id="project-trunk">
<h3><tt class="docutils literal"><span class="pre">project/trunk</span></tt><a class="headerlink" href="#project-trunk" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>SVN用の望ましい方法はプロジェクトごとにレイアウト用のトップレベルのディレクトリを用意することです:</p>
<div class="highlight-python"><div class="highlight"><pre>repository/ # リポジトリ全体
+- project1/ # コンテナディレクトリ
| +- trunk/ # project1の開発のメインライン
| +- branches/ # コンテナディレクトリ
| +- foo/ # project1のfoo機能の開発用ブランチ
| ...
|
+- project2/ # project2用のコンテナ
+- trunk/ # project2用のメインライン
+- branches/ # project2のブランチ用のコンテナ
</pre></div>
</div>
<p>これはBazaarでも機能します。
しかしながら、Bazaarでリポジトリを作るのは簡単で( <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">init-repo</span></tt> )、
それらの主要な恩恵を受けられるのは複数のブランチが共通の祖先を共有するときです。</p>
<p>ですのでBazaarに対して望ましい方法は次のとおりです:</p>
<div class="highlight-python"><div class="highlight"><pre>project1/ # project1用のリポジトリ
+- trunk/ # project1の開発のメインライン
+- branches/ # コンテナディレクトリ
+- foo/ # project1のfoo機能の開発用ブランチ
...
project2/ # project2用のリポジトリ
+- trunk/ # project2用のメインライン
+- branches/ # project2のブランチ用のコンテナ
</pre></div>
</div>
</div>
<div class="section" id="trunk-project">
<h3><tt class="docutils literal"><span class="pre">trunk/project</span></tt><a class="headerlink" href="#trunk-project" title="このヘッドラインへのパーマリンク">¶</a></h3>
<p>SVNで次のようなレイアウトを利用するプロジェクトもたまにあります:</p>
<div class="highlight-python"><div class="highlight"><pre>repository/ # リポジトリ全体
+- trunk/ # コンテナディレクトリ
| +- project1 # project1用のメインライン
| +- project2 # project2用のメインライン
| ...
|
+- branches/ # コンテナ
+- project1/ # コンテナ (?)
| +- foo # project1の'foo'ブランチ
+- project2/
+- bar # project2の'bar'ブランチ
</pre></div>
</div>
<p>次のレイアウトはちょっと変形させたものです:</p>
<div class="highlight-python"><div class="highlight"><pre>repository/ # リポジトリ全体
+- trunk/ # コンテナディレクトリ
| +- project1 # project1用のメインライン
| +- project2 # project2用のメインライン
| ...
|
+- branches/ # コンテナ
+- project1-foo/ # project1の'foo'ブランチ
+- project2-bar/ # project2の'bar'ブランチ
</pre></div>
</div>
<p>“<tt class="docutils literal"><span class="pre">trunk/</span></tt>” 全体をチェックアウトすることで、すべてのプロジェクト用のメインラインを入手できるようにすることが、このレイアウトが採用されている理由だと筆者は考えます。</p>
<p>このレイアウトはBazaarでも使えますが、一般的にお勧めできません。</p>
<blockquote>
<div><ol class="arabic simple">
<li>一回の <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">branch/checkout/get</span></tt> は一つのブランチを作ります。
単独のコマンドですべてのメインラインを入手する利点が得られません。 <a class="footnote-reference" href="#id3" id="id2">[1]</a></li>
<li><tt class="docutils literal"><span class="pre">repository/trunk/foo</span></tt> が <tt class="docutils literal"><span class="pre">foo</span></tt> プロジェクトの <tt class="docutils literal"><span class="pre">trunk</span></tt> か
<tt class="docutils literal"><span class="pre">trunk</span></tt> ブランチの単なる <tt class="docutils literal"><span class="pre">foo</span></tt> ディレクトリなのか明らかではありません。
この混乱の一部はSVNによるものです。
SVNはプロジェクトのブランチ用に使う1つのプロジェクトのファイルに対して同じ”名前空間”を使うからです。
Bazaarにおいて、プロジェクトを構成するファイルの明確な定義、もしくはブランチの位置の対立軸があります
(ブランチごとに唯一の <tt class="docutils literal"><span class="pre">.bzr/</span></tt> ディレクトリか、チェックアウトの中にたくさんの
<tt class="docutils literal"><span class="pre">.svn/</span></tt> ディレクトリかという対立軸です)</li>
</ol>
</div></blockquote>
<table class="docutils footnote" frame="void" id="id3" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2">[1]</a></td><td>注: <a class="reference external" href="http://wiki.bazaar.canonical.com/NestedTrees">NestedTreeSupport</a> は”メタプロジェクト”を作成する方法を提供します。
メタプロジェクトはリポジトリのレイアウトにかかわらず複数のプロジェクトを集約します。
1つのプロジェクトを <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">checkout</span></tt> すれば、必要なサブプロジェクトがすべて手に入ります。</td></tr>
</tbody>
</table>
</div>
</div>
<div class="section" id="project-branch-sub-branch">
<h2>入れ子形式 (<tt class="docutils literal"><span class="pre">project/branch/sub-branch/</span></tt>)<a class="headerlink" href="#project-branch-sub-branch" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>SVNではできない、Bazaarによる別のスタイルは、ブランチ同士を入れ子にすることです。
Bazaarは作業ツリーなしのリポジトリ作成(<tt class="docutils literal"><span class="pre">--no-trees</span></tt>)をサポート(と推奨)しているのでこのスタイルが可能になります。
作業ファイルはブランチの設置場所に混ぜられていないので、 好きな名前空間にブランチを設置できます。</p>
<p>1つの可能性は次のとおりです:</p>
<div class="highlight-python"><div class="highlight"><pre>project/ # リポジトリ全体、*と* プロジェクトのメインラインのブランチ
+ joe/ # 開発者Joeの開発のプライマリブランチ
| +- feature1/ # 開発者Joeのfeature1開発ブランチ
| | +- broken/ # feature1を開発するためのステージングブランチ
| +- feature2/ # Joeのfeature2開発ブランチ
| ...
+ barry/ # Barryの開発ブランチ
| ...
+ releases/
+- 1.0/
+- 1.1.1/
</pre></div>
</div>
<p>このレイアウトのアイディアはブランチ用の階層的なレイアウトを作ることです。
変更はたいていより上位の名前空間のブランチへと流れていきます。
また、このレイアウトではユーザーに独自の作業をするための場所も提供します。
このレイアウトの素晴らしい点の1つは、グローバルな <tt class="docutils literal"><span class="pre">branches</span></tt> 名前空間を散らかさずにミニブランチを置けるので、ブランチ作成が”手軽”になることです。</p>
<p>このレイアウトのもう一つの利点は、ブランチの名前の中で詳細な内容を指定する際に繰り返しが減ることです。</p>
<p>例です:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr branch http://host/repository/project/branches/joe-feature-foo-bugfix-10/
</pre></div>
</div>
<p>上と下を比較します:</p>
<div class="highlight-python"><div class="highlight"><pre>bzr branch http://host/project/joe/foo/bugfix-10
</pre></div>
</div>
<p>また、 <tt class="docutils literal"><span class="pre">repository/project/branches/</span></tt> ディレクトリの中のリストがあれが何かわかるかもしれません:</p>
<div class="highlight-python"><div class="highlight"><pre>barry-feature-bar/
barry-bugfix-10/
barry-bugfix-12/
joe-bugfix-10/
joe-bugfix-13/
joe-frizban/
</pre></div>
</div>
<p>Versus こういったブランチが開発者のディレクトリに分散している。
ブランチの数が少なければ、 <tt class="docutils literal"><span class="pre">branches/</span></tt> は一見するだけですべてのブランチが見えるという素晴らしい利点があります。
ブランチの数が多ければ、 <tt class="docutils literal"><span class="pre">branches/</span></tt> はすべてのブランチが見えてしまうというはっきりした欠点があります。
(調べるブランチが100あるとき、興味のあるブランチを見つけるのが難しくなります)。</p>
<p>入れ子ブランチはたくさんのブランチよりもスケーラブルのようです。
しかしながら、それぞれの個別のブランチは見つけにくいです。
(たとえば”Joeはfoo機能ブランチでバグ修正10に取り組んでいるのか、それともbarの機能ブランチを取り組んでいるのか？”)</p>
<p>他の小さな利点は次のようなものです:</p>
<div class="highlight-python"><div class="highlight"><pre> bzr branch http://host/project/release/1/1/1
もしくは
bzr branch http://host/project/release/1/1/2
</pre></div>
</div>
<p>1.1.1と1.1.2のリリースを示します。
これはリリースする数と一度に見られる能力よりも分割する方がゲインが多いかによります。</p>
</div>
<div class="section" id="dev-merged-experimental">
<h2>ステータスによる種類分け (<tt class="docutils literal"><span class="pre">dev/</span></tt>, <tt class="docutils literal"><span class="pre">merged/</span></tt>, <tt class="docutils literal"><span class="pre">experimental/</span></tt>)<a class="headerlink" href="#dev-merged-experimental" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>ブランチをbreak upする他の方法はこれらを現在のステータス順でソートすることです。
そうするとレイアウトは次のようになります:</p>
<div class="highlight-python"><div class="highlight"><pre>project/ # レイアウト全体
+- trunk/ # 開発に焦点を当てたブランチ
+- dev/ # 進行中の作業用コンテナディレクトリ
| +- joe-feature1 # Joeの現在のfeature-1ブランチ
| +- barry-bugfix10 # bugfix 10に対するBarryの作業内容
| ...
+- merged/ # これらのブランチがマージされたことを示すコンテナ
| +- bugfix-12 # すでにマージされたバグ修正
+- abandonded/ # 'dead-end'と見なされているブランチ
</pre></div>
</div>
<p>これはたくさんの利点と欠点があります。
あまり多くない数のアクティブに開発されているブランチを見ることができるか、今までに作られた全てのブランチが見えるかという違いがあります。
古いブランチは削除しない限り失われませんが、別ディレクトリへと整理されるのでたいていの場合お目当てのブランチを見つけやすくなります。
(反対に、古いブランチは見つけにくくなります)。</p>
<p>このレイアウトで最大の欠点、ブランチが移動することです。
誰かが <tt class="docutils literal"><span class="pre">project/dev/new-feature</span></tt> ブランチをフォローしているとき、
そのブランチが <tt class="docutils literal"><span class="pre">trunk/</span></tt> にマージされると <tt class="docutils literal"><span class="pre">project/merged/new-feature</span></tt>
に移動するので <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">pull</span></tt> が突然機能しなくなります。
この回避策はいくつかあります。
1つは利用者を導くために古いブランチから新しいブランチにリクエストするHTTPリダイレクトを使うことです。
<tt class="docutils literal"><span class="pre">bzr</span></tt> >= 0.15 ではユーザーに <tt class="docutils literal"><span class="pre">http://old/path</span> <span class="pre">が</span> <span class="pre">http://new/path</span></tt>
にリダイレクトされることを教えてくれます。
しかしながら、HTTP以外の方法(SFTP、ローカルファイルシステム、など)を通してブランチにアクセスしている場合は役に立ちません。</p>
<p>一時的なリダイレクト用にシンボリックリンクを利用することも可能です
(シンボリックリンクがリポジトリ内にある限りトラブルはほんのわずかしかありません)。
しかし、シンボリックリンクを結局削除したくなったり、散乱の削減の恩恵を得られません。
シンボリックリンクの代わりの別の可能性は <tt class="docutils literal"><span class="pre">BranchReference</span></tt> を使うことです。
<tt class="docutils literal"><span class="pre">bzr</span></tt> コマンドを通してこれらを作るのは現時点では難しいですが、便利だと思う人がいれば変わるかもしれません。
これは実際には <a class="reference external" href="https://launchpad.net">Launchpad</a> が <tt class="docutils literal"><span class="pre">bzr</span> <span class="pre">checkout</span> <span class="pre">https://launchpad.net/bzr</span></tt> をできるようにしている方法です。
<tt class="docutils literal"><span class="pre">BranchReference</span></tt> は機能的にはシンボリックリンクですが、他のURLの参照ができます。
相対パスによる参照ができるように拡張されれば、HTTP、SFTP、ローカルパスを通しても動作するでしょう。</p>
</div>
<div class="section" id="id4">
<h2>日付/リリース/その他で種類分け (<tt class="docutils literal"><span class="pre">2006-06/</span></tt>, <tt class="docutils literal"><span class="pre">2006-07/</span></tt>, <tt class="docutils literal"><span class="pre">0.8/</span></tt>, <tt class="docutils literal"><span class="pre">0.9</span></tt>)<a class="headerlink" href="#id4" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>スケーラビリティを可能にする別の方法は”現在の”ブランチのブラウジングを許可することです。
基本的に、活発に開発されるブランチは新しく作られ古いブランチはマージもしくは廃棄されることを前提とします。</p>
<p>基本的に日付レイアウトは次のようになります:</p>
<div class="highlight-python"><div class="highlight"><pre>project/ # projectリポジトリ全体
+- trunk/ # 一般的なメインライン
+- 2006-06/ # この月に作成されたブランチ用のディレクトリのコンテナ
| +- feature1/ # "project"の"feature1"用ブランチ
| +- feature2/ # "project"の"feature2"用ブランチ
+- 2005-05/ # 異なる月に作成されるブランチ用のコンテナディレクトリ
+- feature3/
...
</pre></div>
</div>
<p>これは “私の新しいブランチをどこに設置すればいいの？” という質問に素早く答えてくれます。
機能が長期間開発されるのであれば、ブランチを最新の日付にコピーして、そこで作業を続けることも道理にかなっています。
最新の日付と、そこからのさかのぼっていくことで活発なブランチを見つけることができます。
(小さな欠点は 大抵のディレクトリリストは古い順にソートされているので、多くの場合新しいブランチにたどり着くために余計なスクロールが必要になることです)。
古いブランチを新しい位置にコピーしたくない場合、ブランチを探すのが面倒になるのも欠点です。</p>
<p>別の候補は、リリースをターゲットにしたものです:</p>
<div class="highlight-python"><div class="highlight"><pre>project/ # リポジトリ概要
+- trunk/ # メインラインの開発ブランチ
+- releases/ # リリースブランチ用のコンテナ
| +- 0.8/ # リリース0.8のブランチ
| +- 0.9/ # リリース0.9のブランチ
+- 0.8/ # リリース0.8をターゲットとするブランチ用のコンテナ
| +- feature1/ # 0.8にマージする予定の"feature1"用のブランチ
| +- feature2/ # "リリース0.8をターゲットとしたfeature2"用のブランチ
+- 0.9/
+- feature3/ # リリース0.9をターゲットとした"feature3"用のブランチ
</pre></div>
</div>
<p>その派生として、ブランチが <tt class="docutils literal"><span class="pre">0.9</span></tt> ディレクトリに入っていることが 0.9に <em>向けた</em>
ブランチであることではなく 0.9 <em>から</em> 派生したブランチであることを意味するようにすることや、 <tt class="docutils literal"><span class="pre">0.8/release</span></tt> が0.8ブランチの公式リリースであることを意味するようにすることが考えられます。</p>
<p>一般的なアイディアはリリースをターゲットにすることで、何のブランチがマージされるのを待っているのか調べることができます。
このレイアウトはブランチの状態(開発中なのか、終了してレビューを待っているのか)に関する情報を提供しません。
これは履歴を隠す効果もあり、日付ベースの種類分けと同じような利点と欠点を持っています。</p>
</div>
<div class="section" id="project-joe-foo-project-barry-bar">
<h2>シンプルな開発者名 (<tt class="docutils literal"><span class="pre">project/joe/foo</span></tt>, <tt class="docutils literal"><span class="pre">project/barry/bar</span></tt>)<a class="headerlink" href="#project-joe-foo-project-barry-bar" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>別の利用できるレイアウトは、開発者ごとにディレクトリを割り当てて、その下にブランチのためのサブディレクトリを作ることです。次のようになります:</p>
<div class="highlight-python"><div class="highlight"><pre>project/ # リポジトリ全体
+- trunk/ # メインラインのブランチ
+- joe/ # Joeのブランチ用のコンテナ
| +- foo/ # Joeの"project"の"foo"ブランチ
+- barry/
+- bar/ # Barryの"project"の"bar"ブランチ
</pre></div>
</div>
<p>このアイデアでは、branchは入れ子になっておらず、branchは開発者によってのみグループ化されます。</p>
<p><a class="reference external" href="https://launchpad.net">Launchpad</a> で使われている派生系はこのようになっています:</p>
<div class="highlight-python"><div class="highlight"><pre>repository/
+- joe/ # Joeのブランチ
| +- project1/ # Joeのブランチである"project1"用のコンテナ
| | +- foo/ # Joeの"project1"の"foo"ブランチ
| +- project2/ # Joeの"project2"ブランチ用のコンテナ
| +- bar/ # Joeの"project2"の"bar"ブランチ
| ...
|
+- barry/
| +- project1/ # Barryの"project1"のブランチ用のコンテナ
| +- bug-10/ # Barryの"project1"の"bug-10"ブランチ
| ...
+- group/
+- project1/
+- trunk/ # "project1"に焦点をあてたメイン開発
</pre></div>
</div>
<p>このレイアウトではそれぞれの開発者が取り組んでいるものを簡単に見ることができます。
焦点のブランチは”group” ディレクトリに保存されます。
これによって”グループ”が取り組んでいるブランチを見分けられます。</p>
<p>これによって異なる人々の作業内容をそれぞれ分離できますが、”プロジェクトX用のすべてのブランチ”を見つけるのが難しくなります。
<a class="reference external" href="https://launchpad.net">Launchpad</a> はデータベースバックエンドを伴う素晴らしいウェブインターフェイスを提供していて、”view”をこのレイアウトのトップに追加することでこの欠点を補っています。
これはそれぞれの個人が “<tt class="docutils literal"><span class="pre">~/public_html</span></tt>” ディレクトリを持ち、そこで独自のウェブページを公開する個人用ホームページのモデルに近いです。
一般的に、集中型のプロジェクト用に共用リポジトリを作成するとき、個人単位で分割してからプロジェクト単位に分割することを望まないでしょう。
通常はプロジェクト単位で分割してから個人単位で分割するとよいでしょう。</p>
</div>
<div class="section" id="id5">
<h2>要約<a class="headerlink" href="#id5" title="このヘッドラインへのパーマリンク">¶</a></h2>
<p>最後に、誰にとってもうまくいく唯一の命名規則はありません。
開発者の人数、新しいブランチが作成される頻度、ブランチのライフサイクルなどによって異なります。
自身に問いかける質問は次のとおりです:</p>
<blockquote>
<div><ol class="arabic simple">
<li>寿命の長い少数のブランチを作るか、もしくはたくさんの”ミニ”機能ブランチを作るか
(加えて: ミニ機能ブランチをたくさん <em>作りたい</em> が現在のVCSでは苦痛なのでできないのではないか？)</li>
<li>1人で開発しているのか、大きなチームか？</li>
<li>チームであれば、一般的に全員が同時に同じブランチに取り組むことを計画しているか？
もしくは人々が追跡することを想定した”安定”ブランチを持つか。</li>
</ol>
</div></blockquote>
</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="#svn-trunk-branches">“SVN形式” (<tt class="docutils literal"><span class="pre">trunk/</span></tt>, <tt class="docutils literal"><span class="pre">branches/</span></tt>)</a><ul>
<li><a class="reference internal" href="#project-trunk"><tt class="docutils literal"><span class="pre">project/trunk</span></tt></a></li>
<li><a class="reference internal" href="#trunk-project"><tt class="docutils literal"><span class="pre">trunk/project</span></tt></a></li>
</ul>
</li>
<li><a class="reference internal" href="#project-branch-sub-branch">入れ子形式 (<tt class="docutils literal"><span class="pre">project/branch/sub-branch/</span></tt>)</a></li>
<li><a class="reference internal" href="#dev-merged-experimental">ステータスによる種類分け (<tt class="docutils literal"><span class="pre">dev/</span></tt>, <tt class="docutils literal"><span class="pre">merged/</span></tt>, <tt class="docutils literal"><span class="pre">experimental/</span></tt>)</a></li>
<li><a class="reference internal" href="#id4">日付/リリース/その他で種類分け (<tt class="docutils literal"><span class="pre">2006-06/</span></tt>, <tt class="docutils literal"><span class="pre">2006-07/</span></tt>, <tt class="docutils literal"><span class="pre">0.8/</span></tt>, <tt class="docutils literal"><span class="pre">0.9</span></tt>)</a></li>
<li><a class="reference internal" href="#project-joe-foo-project-barry-bar">シンプルな開発者名 (<tt class="docutils literal"><span class="pre">project/joe/foo</span></tt>, <tt class="docutils literal"><span class="pre">project/barry/bar</span></tt>)</a></li>
<li><a class="reference internal" href="#id5">要約</a></li>
</ul>
</li>
</ul>
<h4>前のトピックへ</h4>
<p class="topless"><a href="organizing_your_workspace.html"
title="前の章へ">作業スペースを構成する</a></p>
<h4>次のトピックへ</h4>
<p class="topless"><a href="setting_up_email.html"
title="次の章へ">Eメールを設定する</a></p>
<h3>このページ</h3>
<ul class="this-page-menu">
<li><a href="../_sources/user-guide/shared_repository_layouts.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="setting_up_email.html" title="Eメールを設定する"
>次へ</a></li>
<li class="right" >
<a href="organizing_your_workspace.html" title="作業スペースを構成する"
>前へ</a> |</li>
<li><a href="../index.html">目次 (2.6.0)</a> »</li>
<li><a href="index.html" >Bazaarユーザーガイド</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>
