2
===========================
4
Bazaarは共用ブランチ内部のブランチのレイアウトを柔軟に決められるように設計されました。
5
この柔軟性によってユーザーはBazaarを自分のワークフローに合わせることができますが、\
6
"よい"レイアウトとは何かということを疑問に持つようになります。
7
ここでは代わりになるものをいくつか説明しそれぞれの利点を検討します。
9
言及すべき重要な点はよいレイアウトは"一般的な"ユーザーが理解できるように
10
ブランチの内容を何らかの形でハイライトします。
11
SVNにおいて これは "``trunk/``" ブランチであると考えられ、
12
大抵のレイアウトではこの命名規約が守られています。
13
これを "``mainline``" もしくは "``dev``" と呼ぶ人もいれば、
14
CVSから来た人々はしばし "``HEAD``" と言及します。
17
"SVN形式" (``trunk/``, ``branches/``)
18
---------------------------------------
20
SVNからやってきた人々は次のような"標準的な"プロジェクトのレイアウトに慣れています::
24
+- branches/ # コンテナディレクトリ
25
| +- foo/ # 開発中のfoo機能用ブランチ
28
+- release-X # 特定のリリースバージョンをマークするために専用ブランチ
31
Bazaarでは、これは完全に適切なレイアウトです。
32
SVNからやって来た人が慣れ親しめることが利点で\
35
同じリポジトリで複数のプロジェクトを持つとき、\
36
SVNのレイアウトは何を行うのか少し不透明です。
42
SVN用の望ましい方法はプロジェクトごとにレイアウト用のトップレベルのディレクトリを用意することです::
45
+- project1/ # コンテナディレクトリ
46
| +- trunk/ # project1の開発のメインライン
47
| +- branches/ # コンテナディレクトリ
48
| +- foo/ # project1のfoo機能の開発用ブランチ
51
+- project2/ # project2用のコンテナ
52
+- trunk/ # project2用のメインライン
53
+- branches/ # project2のブランチ用のコンテナ
57
しかしながら、Bazaarでリポジトリを作るのは簡単で( ``bzr init-repo`` )、
58
それらの主要な恩恵を受けられるのは複数のブランチが共通の祖先を共有するときです。
60
ですのでBazaarに対して望ましい方法は次のとおりです::
62
project1/ # project1用のリポジトリ
63
+- trunk/ # project1の開発のメインライン
64
+- branches/ # コンテナディレクトリ
65
+- foo/ # project1のfoo機能の開発用ブランチ
68
project2/ # project2用のリポジトリ
69
+- trunk/ # project2用のメインライン
70
+- branches/ # project2のブランチ用のコンテナ
76
SVNで次のようなレイアウトを利用するプロジェクトもたまにあります::
79
+- trunk/ # コンテナディレクトリ
80
| +- project1 # project1用のメインライン
81
| +- project2 # project2用のメインライン
85
+- project1/ # コンテナ (?)
86
| +- foo # project1の'foo'ブランチ
88
+- bar # project2の'bar'ブランチ
91
次のレイアウトはちょっと変形させたものです::
94
+- trunk/ # コンテナディレクトリ
95
| +- project1 # project1用のメインライン
96
| +- project2 # project2用のメインライン
100
+- project1-foo/ # project1の'foo'ブランチ
101
+- project2-bar/ # project2の'bar'ブランチ
103
"``trunk/``" 全体をチェックアウトすることで、すべてのプロジェクト用の\
104
メインラインを入手できるようにすることが、このレイアウトが採用されている理由だと\
107
このレイアウトはBazaarでも使えますが、一般的にお勧めできません。
109
1) 一回の ``bzr branch/checkout/get`` は一つのブランチを作ります。
110
単独のコマンドですべてのメインラインを入手する利点が得られません。 [1]_
112
2) ``repository/trunk/foo`` が ``foo`` プロジェクトの ``trunk`` か
113
``trunk`` ブランチの単なる ``foo`` ディレクトリなのか明らかではありません。
115
SVNはプロジェクトのブランチ用に使う1つのプロジェクトのファイルに対して同じ"名前空間"を使うからです。
116
Bazaarにおいて、プロジェクトを構成するファイルの明確な定義、もしくはブランチの位置の対立軸があります
117
(ブランチごとに唯一の ``.bzr/`` ディレクトリか、チェックアウトの中にたくさんの
118
``.svn/`` ディレクトリかという対立軸です)
120
.. [1] 注: `NestedTreeSupport`_ は"メタプロジェクト"を作成する方法を提供します。
121
メタプロジェクトはリポジトリのレイアウトにかかわらず複数のプロジェクトを集約します。
122
1つのプロジェクトを ``bzr checkout`` すれば、必要なサブプロジェクトがすべて手に入ります。
124
.. _NestedTreeSupport: http://wiki.bazaar.canonical.com/NestedTrees
127
入れ子形式 (``project/branch/sub-branch/``)
128
---------------------------------------------
130
SVNではできない、Bazaarによる別のスタイルは、ブランチ同士を\
132
Bazaarは作業ツリーなしのリポジトリ作成(``--no-trees``)をサポート\
133
(と推奨)しているのでこのスタイルが可能になります。
134
作業ファイルはブランチの設置場所に混ぜられていないので、 好きな名前空間にブランチを設置できます。
138
project/ # リポジトリ全体、*と* プロジェクトのメインラインのブランチ
139
+ joe/ # 開発者Joeの開発のプライマリブランチ
140
| +- feature1/ # 開発者Joeのfeature1開発ブランチ
141
| | +- broken/ # feature1を開発するためのステージングブランチ
142
| +- feature2/ # Joeのfeature2開発ブランチ
144
+ barry/ # Barryの開発ブランチ
150
このレイアウトのアイディアはブランチ用の階層的なレイアウトを作ることです。
151
変更はたいていより上位の名前空間のブランチへと流れていきます。
152
また、このレイアウトではユーザーに独自の作業をするための場所も提供します。
153
このレイアウトの素晴らしい点の1つは、グローバルな ``branches`` 名前空間を\
154
散らかさずにミニブランチを置けるので、ブランチ作成が"手軽"になることです。
156
このレイアウトのもう一つの利点は、ブランチの名前の中で詳細な内容を指定する際に\
161
bzr branch http://host/repository/project/branches/joe-feature-foo-bugfix-10/
165
bzr branch http://host/project/joe/foo/bugfix-10
168
また、 ``repository/project/branches/`` ディレクトリの中のリストがあれが何かわかるかもしれません::
177
Versus こういったブランチが開発者のディレクトリに分散している。
178
ブランチの数が少なければ、 ``branches/`` は一見するだけですべての\
179
ブランチが見えるという素晴らしい利点があります。
180
ブランチの数が多ければ、 ``branches/`` はすべてのブランチが\
181
見えてしまうというはっきりした欠点があります。
182
(調べるブランチが100あるとき、興味のあるブランチを見つけるのが難しくなります)。
184
入れ子ブランチはたくさんのブランチよりもスケーラブルのようです。
185
しかしながら、それぞれの個別のブランチは見つけにくいです。
186
(たとえば"Joeはfoo機能ブランチでバグ修正10に取り組んでいるのか、\
187
それともbarの機能ブランチを取り組んでいるのか？")
191
bzr branch http://host/project/release/1/1/1
193
bzr branch http://host/project/release/1/1/2
195
1.1.1と1.1.2のリリースを示します。
196
これはリリースする数と一度に見られる能力よりも分割する方がゲインが多いかによります。
199
ステータスによる種類分け (``dev/``, ``merged/``, ``experimental/``)
200
---------------------------------------------------------------------
202
ブランチをbreak upする他の方法はこれらを現在のステータス順でソートすることです。
203
そうするとレイアウトは次のようになります::
206
+- trunk/ # 開発に焦点を当てたブランチ
207
+- dev/ # 進行中の作業用コンテナディレクトリ
208
| +- joe-feature1 # Joeの現在のfeature-1ブランチ
209
| +- barry-bugfix10 # bugfix 10に対するBarryの作業内容
211
+- merged/ # これらのブランチがマージされたことを示すコンテナ
212
| +- bugfix-12 # すでにマージされたバグ修正
213
+- abandonded/ # 'dead-end'と見なされているブランチ
217
あまり多くない数のアクティブに開発されているブランチを見ることができるか、\
218
今までに作られた全てのブランチが見えるかという違いがあります。
219
古いブランチは削除しない限り失われませんが、別ディレクトリへと整理されるので\
220
たいていの場合お目当てのブランチを見つけやすくなります。
221
(反対に、古いブランチは見つけにくくなります)。
223
このレイアウトで最大の欠点、ブランチが移動することです。
224
誰かが ``project/dev/new-feature`` ブランチをフォローしているとき、
225
そのブランチが ``trunk/`` にマージされると ``project/merged/new-feature``
226
に移動するので ``bzr pull`` が突然機能しなくなります。
228
1つは利用者を導くために古いブランチから新しいブランチにリクエストする\
230
``bzr`` >= 0.15 ではユーザーに ``http://old/path が http://new/path``
231
にリダイレクトされることを教えてくれます。
232
しかしながら、HTTP以外の方法(SFTP、ローカルファイルシステム、など)を\
233
通してブランチにアクセスしている場合は役に立ちません。
235
一時的なリダイレクト用にシンボリックリンクを利用することも可能です
236
(シンボリックリンクがリポジトリ内にある限りトラブルはほんのわずかしかありません)。
237
しかし、シンボリックリンクを結局削除したくなったり、散乱の削減の恩恵を得られません。
238
シンボリックリンクの代わりの別の可能性は ``BranchReference`` を使うことです。
239
``bzr`` コマンドを通してこれらを作るのは現時点では難しいですが、便利だと思う人がいれば変わるかもしれません。
240
これは実際には `Launchpad`_ が ``bzr checkout https://launchpad.net/bzr`` をできるようにしている方法です。
241
``BranchReference`` は機能的にはシンボリックリンクですが、他のURLの参照ができます。
242
相対パスによる参照ができるように拡張されれば、http、sftp、ローカルパスを通しても\
245
.. _Launchpad: https://launchpad.net
248
日付/リリース/その他で種類分け (``2006-06/``, ``2006-07/``, ``0.8/``, ``0.9``)
249
------------------------------------------------------------------------------
251
スケーラビリティを可能にする別の方法は"現在の"ブランチのブラウジングを許可することです。
252
基本的に、活発に開発されるブランチは新しく作られ古いブランチはマージもしくは\
255
基本的に日付レイアウトは次のようになります::
257
project/ # projectリポジトリ全体
258
+- trunk/ # 一般的なメインライン
259
+- 2006-06/ # この月に作成されたブランチ用のディレクトリのコンテナ
260
| +- feature1/ # "project"の"feature1"用ブランチ
261
| +- feature2/ # "project"の"feature2"用ブランチ
262
+- 2005-05/ # 異なる月に作成されるブランチ用のコンテナディレクトリ
266
これは "私の新しいブランチをどこに設置すればいいの？" という質問に素早く答えてくれます。
267
機能が長期間開発されるのであれば、ブランチを最新の日付にコピーして、\
268
そこで作業を続けることも道理にかなっています。
269
最新の日付と、そこからのさかのぼっていくことで活発なブランチを見つけることができます。
270
(小さな欠点は 大抵のディレクトリリストは古い順にソートされているので、\
271
多くの場合新しいブランチにたどり着くために余計なスクロールが必要になることです)。
272
古いブランチを新しい位置にコピーしたくない場合、ブランチを探すのが面倒になるのも欠点です。
274
別の候補は、リリースをターゲットにしたものです::
277
+- trunk/ # メインラインの開発ブランチ
278
+- releases/ # リリースブランチ用のコンテナ
279
| +- 0.8/ # リリース0.8のブランチ
280
| +- 0.9/ # リリース0.9のブランチ
281
+- 0.8/ # リリース0.8をターゲットとするブランチ用のコンテナ
282
| +- feature1/ # 0.8にマージする予定の"feature1"用のブランチ
283
| +- feature2/ # "リリース0.8をターゲットとしたfeature2"用のブランチ
285
+- feature3/ # リリース0.9をターゲットとした"feature3"用のブランチ
288
その派生として、ブランチが ``0.9`` ディレクトリに入っていることが 0.9に *向けた*
289
ブランチであることではなく 0.9 *から* 派生したブランチであることを意味するように\
290
することや、 ``0.8/release`` が0.8ブランチの公式リリースであることを意味するように\
293
一般的なアイディアはリリースをターゲットにすることで、何のブランチがマージ\
294
されるのを待っているのか調べることができます。
295
このレイアウトはブランチの状態(開発中なのか、終了してレビューを待っているのか)\
297
これは履歴を隠す効果もあり、日付ベースの種類分けと同じような利点と欠点を持っています。
299
シンプルな開発者名 (``project/joe/foo``, ``project/barry/bar``)
300
----------------------------------------------------------------
302
別の利用できるレイアウトは、開発者ごとにディレクトリを割り当てて、\
303
その下にブランチのためのサブディレクトリを作ることです。次のようになります::
306
+- trunk/ # メインラインのブランチ
307
+- joe/ # Joeのブランチ用のコンテナ
308
| +- foo/ # Joeの"project"の"foo"ブランチ
310
+- bar/ # Barryの"project"の"bar"ブランチ
312
このアイデアでは、branchは入れ子になっておらず、branchは開発者によってのみ\
315
`Launchpad`_ で使われている派生系はこのようになっています::
319
| +- project1/ # Joeのブランチである"project1"用のコンテナ
320
| | +- foo/ # Joeの"project1"の"foo"ブランチ
321
| +- project2/ # Joeの"project2"ブランチ用のコンテナ
322
| +- bar/ # Joeの"project2"の"bar"ブランチ
326
| +- project1/ # Barryの"project1"のブランチ用のコンテナ
327
| +- bug-10/ # Barryの"project1"の"bug-10"ブランチ
331
+- trunk/ # "project1"に焦点をあてたメイン開発
334
このレイアウトではそれぞれの開発者が取り組んでいるものを簡単に見ることができます。
335
焦点のブランチは"group" ディレクトリに保存されます。
336
これによって"グループ"が取り組んでいるブランチを見分けられます。
338
これによって異なる人々の作業内容をそれぞれ分離できますが、\
339
"プロジェクトX用のすべてのブランチ"を見つけるのが難しくなります。
340
`Launchpad`_ はデータベースバックエンドを伴う素晴らしいウェブインターフェイス\
341
を提供していて、"view"をこのレイアウトのトップに追加することでこの欠点を補っています。
342
これはそれぞれの個人が "``~/public_html``" ディレクトリを持ち、そこで独自の\
343
ウェブページを公開する個人用ホームページのモデルに近いです。
344
一般的に、集中型のプロジェクト用に共用リポジトリを作成するとき、\
345
個人単位で分割してからプロジェクト単位に分割することを望まないでしょう。
346
通常はプロジェクト単位で分割してから個人単位で分割するとよいでしょう。
351
最後に、誰にとってもうまくいく唯一の命名規則はありません。
352
開発者の人数、新しいブランチが作成される頻度、ブランチのライフサイクルなどに\
356
1) 寿命の長い少数のブランチを作るか、もしくはたくさんの"ミニ"機能ブランチを作るか
357
(加えて: ミニ機能ブランチをたくさん *作りたい* が現在のVCSでは苦痛なのでできないのではないか？)
359
2) 1人で開発しているのか、大きなチームか？
361
3) チームであれば、一般的に全員が同時に同じブランチに取り組むことを計画しているか？
362
もしくは人々が追跡することを想定した"安定"ブランチを持つか。
added
removed
doc/ja/user-guide/shared_repository_layouts.txt
