~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/user-guide/shared_repository_layouts.txt

  • Committer: Naoki INADA
  • Date: 2009-10-29 10:01:19 UTC
  • mto: (4634.97.3 2.0)
  • mto: This revision was merged to the branch mainline in revision 4798.
  • Revision ID: inada-n@klab.jp-20091029100119-uckv9t7ej2qrghw3
import doc-ja rev90

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
共用レポジトリのレイアウト
 
2
===========================
 
3
 
 
4
Bazaarは共用ブランチ内部のブランチのレイアウトを柔軟に決められるように設計されました。
 
5
この柔軟性によってユーザーはBazaarを自分のワークフローに合わせることができますが、\
 
6
"よい"レイアウトとは何かということを疑問に持つようになります。
 
7
ここでは代わりになるものをいくつか説明しそれぞれの利点を検討します。
 
8
 
 
9
言及すべき重要な点はよいレイアウトは"一般的な"ユーザーが理解できるように
 
10
ブランチの内容を何らかの形でハイライトします。
 
11
SVNにおいて これは "``trunk/``" ブランチであると考えられ、
 
12
大抵のレイアウトではこの命名規約が守られています。
 
13
これを "``mainline``" もしくは "``dev``" と呼ぶ人もいれば、
 
14
CVSから来た人々はしばし "``HEAD``" と言及します。
 
15
 
 
16
 
 
17
"SVN形式" (``trunk/``, ``branches/``)
 
18
---------------------------------------
 
19
 
 
20
SVNからやってきた人々は次のような"標準的な"プロジェクトのレイアウトに慣れています::
 
21
 
 
22
  repository/       # リポジトリ全体
 
23
   +- trunk/        # 開発のメインライン
 
24
   +- branches/     # コンテナディレクトリ
 
25
   |   +- foo/      # 開発中のfoo機能用ブランチ
 
26
   |     ...
 
27
   +- tags/         # コンテナディレクトリ
 
28
       +- release-X # 特定のリリースバージョンをマークするために専用ブランチ
 
29
          ...
 
30
 
 
31
Bazaarでは、これは完全に適切なレイアウトです。
 
32
SVNからやって来た人が慣れ親しめることが利点で\
 
33
開発の焦点を当てる場所が明確になります。
 
34
 
 
35
同じリポジトリで複数のプロジェクトを持つとき、\
 
36
SVNのレイアウトは何を行うのか少し不透明です。
 
37
 
 
38
 
 
39
``project/trunk``
 
40
~~~~~~~~~~~~~~~~~
 
41
 
 
42
SVN用の望ましい方法はプロジェクトごとにレイアウト用のトップレベルのディレクトリを用意することです::
 
43
 
 
44
  repository/            # リポジトリ全体
 
45
   +- project1/          # コンテナディレクトリ
 
46
   |   +- trunk/         # project1の開発のメインライン
 
47
   |   +- branches/      # コンテナディレクトリ
 
48
   |       +- foo/       # project1のfoo機能の開発用ブランチ
 
49
   |         ...
 
50
   |
 
51
   +- project2/          # project2用のコンテナ
 
52
       +- trunk/         # project2用のメインライン
 
53
       +- branches/      # project2のブランチ用のコンテナ
 
54
 
 
55
 
 
56
これはBazaarでも機能します。
 
57
しかしながら、Bazaarでリポジトリを作るのは簡単で( ``bzr init-repo`` )、
 
58
それらの主要な恩恵を受けられるのは複数のブランチが共通の祖先を共有するときです。
 
59
 
 
60
ですのでBazaarに対して望ましい方法は次のとおりです::
 
61
 
 
62
    project1/          # project1用のリポジトリ
 
63
     +- trunk/         # project1の開発のメインライン
 
64
     +- branches/      # コンテナディレクトリ
 
65
         +- foo/       # project1のfoo機能の開発用ブランチ
 
66
           ...
 
67
 
 
68
    project2/          # project2用のリポジトリ
 
69
     +- trunk/         # project2用のメインライン
 
70
     +- branches/      # project2のブランチ用のコンテナ
 
71
 
 
72
 
 
73
``trunk/project``
 
74
~~~~~~~~~~~~~~~~~
 
75
 
 
76
SVNで次のようなレイアウトを利用するプロジェクトもたまにあります::
 
77
 
 
78
  repository/             # リポジトリ全体
 
79
    +- trunk/             # コンテナディレクトリ
 
80
    |   +- project1       # project1用のメインライン
 
81
    |   +- project2       # project2用のメインライン
 
82
    |         ...
 
83
    |
 
84
    +- branches/          # コンテナ
 
85
        +- project1/      # コンテナ (?)
 
86
        |   +- foo        # project1の'foo'ブランチ
 
87
        +- project2/
 
88
            +- bar        # project2の'bar'ブランチ
 
89
 
 
90
 
 
91
次のレイアウトはちょっと変形させたものです::
 
92
 
 
93
  repository/             # リポジトリ全体
 
94
    +- trunk/             # コンテナディレクトリ
 
95
    |   +- project1       # project1用のメインライン
 
96
    |   +- project2       # project2用のメインライン
 
97
    |         ...
 
98
    |
 
99
    +- branches/          # コンテナ
 
100
        +- project1-foo/  # project1の'foo'ブランチ
 
101
        +- project2-bar/  # project2の'bar'ブランチ
 
102
 
 
103
"``trunk/``" 全体をチェックアウトすることで、すべてのプロジェクト用の\
 
104
メインラインを入手できるようにすることが、このレイアウトが採用されている理由だと\
 
105
筆者は考えます。
 
106
 
 
107
このレイアウトはBazaarでも使えますが、一般的にお勧めできません。
 
108
 
 
109
 1) 一回の ``bzr branch/checkout/get`` は一つのブランチを作ります。
 
110
    単独のコマンドですべてのメインラインを入手する利点が得られません。 [1]_
 
111
 
 
112
 2) ``repository/trunk/foo`` が ``foo`` プロジェクトの ``trunk`` か
 
113
    ``trunk`` ブランチの単なる ``foo`` ディレクトリなのか明らかではありません。
 
114
    この混乱の一部はSVNによるものです。
 
115
    SVNはプロジェクトのブランチ用に使う1つのプロジェクトのファイルに対して同じ"名前空間"を使うからです。
 
116
    Bazaarにおいて、プロジェクトを構成するファイルの明確な定義、もしくはブランチの位置の対立軸があります
 
117
    (ブランチごとに唯一の ``.bzr/`` ディレクトリか、チェックアウトの中にたくさんの
 
118
    ``.svn/`` ディレクトリかという対立軸です)
 
119
 
 
120
.. [1] 注: `NestedTreeSupport`_ は"メタプロジェクト"を作成する方法を提供します。
 
121
    メタプロジェクトはリポジトリのレイアウトにかかわらず複数のプロジェクトを集約します。
 
122
    1つのプロジェクトを ``bzr checkout`` すれば、必要なサブプロジェクトがすべて手に入ります。
 
123
 
 
124
.. _NestedTreeSupport: http://bazaar-vcs.org/NestedTrees
 
125
 
 
126
 
 
127
入れ子形式 (``project/branch/sub-branch/``)
 
128
---------------------------------------------
 
129
 
 
130
SVNではできない、Bazaarによる別のスタイルは、ブランチ同士を\
 
131
入れ子にすることです。
 
132
Bazaarは作業ツリーなしのリポジトリ作成(``--no-trees``)をサポート\
 
133
(と推奨)しているのでこのスタイルが可能になります。
 
134
作業ファイルはブランチの設置場所に混ぜられていないので、 好きな名前空間にブランチを設置できます。
 
135
 
 
136
1つの可能性は次のとおりです::
 
137
 
 
138
  project/             # リポジトリ全体、*と* プロジェクトのメインラインのブランチ
 
139
   + joe/              # 開発者Joeの開発のプライマリブランチ
 
140
   |  +- feature1/     # 開発者Joeのfeature1開発ブランチ
 
141
   |  |   +- broken/   # feature1を開発するためのステージングブランチ
 
142
   |  +- feature2/     # Joeのfeature2開発ブランチ
 
143
   |    ...
 
144
   + barry/            # Barryの開発ブランチ
 
145
   |  ...
 
146
   + releases/
 
147
      +- 1.0/
 
148
          +- 1.1.1/
 
149
 
 
150
このレイアウトのアイディアはブランチ用の階層的なレイアウトを作ることです。
 
151
変更はたいていより上位の名前空間のブランチへと流れていきます。
 
152
また、このレイアウトではユーザーに独自の作業をするための場所も提供します。
 
153
このレイアウトの素晴らしい点の1つは、グローバルな ``branches`` 名前空間を\
 
154
散らかさずにミニブランチを置けるので、ブランチ作成が"手軽"になることです。
 
155
 
 
156
このレイアウトのもう一つの利点は、ブランチの名前の中で詳細な内容を指定する際に\
 
157
繰り返しが減ることです。
 
158
 
 
159
例です::
 
160
 
 
161
  bzr branch http://host/repository/project/branches/joe-feature-foo-bugfix-10/
 
162
 
 
163
上と下を比較します::
 
164
 
 
165
  bzr branch http://host/project/joe/foo/bugfix-10
 
166
 
 
167
 
 
168
また、 ``repository/project/branches/`` ディレクトリの中のリストがあれが何かわかるかもしれません::
 
169
 
 
170
  barry-feature-bar/
 
171
  barry-bugfix-10/
 
172
  barry-bugfix-12/
 
173
  joe-bugfix-10/
 
174
  joe-bugfix-13/
 
175
  joe-frizban/
 
176
 
 
177
Versus こういったブランチが開発者のディレクトリに分散している。
 
178
ブランチの数が少なければ、 ``branches/`` は一見するだけですべての\
 
179
ブランチが見えるという素晴らしい利点があります。
 
180
ブランチの数が多ければ、 ``branches/`` はすべてのブランチが\
 
181
見えてしまうというはっきりした欠点があります。
 
182
(調べるブランチが100あるとき、興味のあるブランチを見つけるのが難しくなります)。
 
183
 
 
184
入れ子ブランチはたくさんのブランチよりもスケーラブルのようです。
 
185
しかしながら、それぞれの個別のブランチは見つけにくいです。
 
186
(たとえば"Joeはfoo機能ブランチでバグ修正10に取り組んでいるのか、\
 
187
それともbarの機能ブランチを取り組んでいるのか?")
 
188
 
 
189
他の小さな利点は次のようなものです::
 
190
 
 
191
   bzr branch http://host/project/release/1/1/1
 
192
  もしくは
 
193
   bzr branch http://host/project/release/1/1/2
 
194
 
 
195
1.1.1と1.1.2のリリースを示します。
 
196
これはリリースする数と一度に見られる能力よりも分割する方がゲインが多いかによります。
 
197
 
 
198
 
 
199
ステータスによる種類分け (``dev/``, ``merged/``, ``experimental/``)
 
200
---------------------------------------------------------------------
 
201
 
 
202
ブランチをbreak upする他の方法はこれらを現在のステータス順でソートすることです。
 
203
そうするとレイアウトは次のようになります::
 
204
 
 
205
  project/               # レイアウト全体
 
206
   +- trunk/             # 開発に焦点を当てたブランチ
 
207
   +- dev/               # 進行中の作業用コンテナディレクトリ
 
208
   |   +- joe-feature1   # Joeの現在のfeature-1ブランチ
 
209
   |   +- barry-bugfix10 # bugfix 10に対するBarryの作業内容
 
210
   |    ...
 
211
   +- merged/            # これらのブランチがマージされたことを示すコンテナ
 
212
   |   +- bugfix-12      # すでにマージされたバグ修正
 
213
   +- abandonded/        # 'dead-end'と見なされているブランチ
 
214
 
 
215
 
 
216
これはたくさんの利点と欠点があります。
 
217
あまり多くない数のアクティブに開発されているブランチを見ることができるか、\
 
218
今までに作られた全てのブランチが見えるかという違いがあります。
 
219
古いブランチは削除しない限り失われませんが、別ディレクトリへと整理されるので\
 
220
たいていの場合お目当てのブランチを見つけやすくなります。
 
221
(反対に、古いブランチは見つけにくくなります)。
 
222
 
 
223
このレイアウトで最大の欠点、ブランチが移動することです。
 
224
誰かが ``project/dev/new-feature`` ブランチをフォローしているとき、
 
225
そのブランチが  ``trunk/`` にマージされると ``project/merged/new-feature``
 
226
に移動するので ``bzr pull`` が突然機能しなくなります。
 
227
この回避策はいくつかあります。
 
228
1つは利用者を導くために古いブランチから新しいブランチにリクエストする\
 
229
HTTPリダイレクトを使うことです。
 
230
``bzr`` >= 0.15 ではユーザーに ``http://old/path が http://new/path``
 
231
にリダイレクトされることを教えてくれます。
 
232
しかしながら、HTTP以外の方法(SFTP、ローカルファイルシステム、など)を\
 
233
通してブランチにアクセスしている場合は役に立ちません。
 
234
 
 
235
一時的なリダイレクト用にシンボリックリンクを利用することも可能です
 
236
(シンボリックリンクがリポジトリ内にある限りトラブルはほんのわずかしかありません)。
 
237
しかし、シンボリックリンクを結局削除したくなったり、散乱の削減の恩恵を得られません。
 
238
シンボリックリンクの代わりの別の可能性は ``BranchReference`` を使うことです。
 
239
``bzr`` コマンドを通してこれらを作るのは現時点では難しいですが、便利だと思う人がいれば変わるかもしれません。
 
240
これは実際には `Launchpad`_ が ``bzr checkout https://launchpad.net/bzr`` をできるようにしている方法です。
 
241
``BranchReference`` は機能的にはシンボリックリンクですが、他のURLの参照ができます。
 
242
相対パスによる参照ができるように拡張されれば、http、sftp、ローカルパスを通しても\
 
243
動作するでしょう。
 
244
 
 
245
.. _Launchpad: https://launchpad.net
 
246
 
 
247
 
 
248
日付/リリース/その他で種類分け (``2006-06/``, ``2006-07/``, ``0.8/``, ``0.9``)
 
249
------------------------------------------------------------------------------
 
250
 
 
251
スケーラビリティを可能にする別の方法は"現在の"ブランチのブラウジングを許可することです。
 
252
基本的に、活発に開発されるブランチは新しく作られ古いブランチはマージもしくは\
 
253
廃棄されることを前提とします。
 
254
 
 
255
基本的に日付レイアウトは次のようになります::
 
256
 
 
257
  project/                # projectリポジトリ全体
 
258
   +- trunk/              # 一般的なメインライン
 
259
   +- 2006-06/            # この月に作成されたブランチ用のディレクトリのコンテナ
 
260
   |   +- feature1/       # "project"の"feature1"用ブランチ
 
261
   |   +- feature2/       # "project"の"feature2"用ブランチ
 
262
   +- 2005-05/            # 異なる月に作成されるブランチ用のコンテナディレクトリ
 
263
       +- feature3/
 
264
       ...
 
265
 
 
266
これは "私の新しいブランチをどこに設置すればいいの?" という質問に素早く答えてくれます。
 
267
機能が長期間開発されるのであれば、ブランチを最新の日付にコピーして、\
 
268
そこで作業を続けることも道理にかなっています。
 
269
最新の日付と、そこからのさかのぼっていくことで活発なブランチを見つけることができます。
 
270
(小さな欠点は 大抵のディレクトリリストは古い順にソートされているので、\
 
271
多くの場合新しいブランチにたどり着くために余計なスクロールが必要になることです)。
 
272
古いブランチを新しい位置にコピーしたくない場合、ブランチを探すのが面倒になるのも欠点です。
 
273
 
 
274
別の候補は、リリースをターゲットにしたものです::
 
275
 
 
276
  project/          # リポジトリ概要
 
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"用のブランチ
 
284
   +- 0.9/
 
285
       +- feature3/ # リリース0.9をターゲットとした"feature3"用のブランチ
 
286
 
 
287
 
 
288
その派生として、ブランチが ``0.9`` ディレクトリに入っていることが 0.9に *向けた*
 
289
ブランチであることではなく 0.9 *から* 派生したブランチであることを意味するように\
 
290
することや、 ``0.8/release`` が0.8ブランチの公式リリースであることを意味するように\
 
291
することが考えられます。
 
292
 
 
293
一般的なアイディアはリリースをターゲットにすることで、何のブランチがマージ\
 
294
されるのを待っているのか調べることができます。
 
295
このレイアウトはブランチの状態(開発中なのか、終了してレビューを待っているのか)\
 
296
に関する情報を提供しません。
 
297
これは履歴を隠す効果もあり、日付ベースの種類分けと同じような利点と欠点を持っています。
 
298
 
 
299
シンプルな開発者名 (``project/joe/foo``, ``project/barry/bar``)
 
300
----------------------------------------------------------------
 
301
 
 
302
別の利用できるレイアウトは、開発者ごとにディレクトリを割り当てて、\
 
303
その下にブランチのためのサブディレクトリを作ることです。次のようになります::
 
304
 
 
305
  project/      # リポジトリ全体
 
306
   +- trunk/    # メインラインのブランチ
 
307
   +- joe/      # Joeのブランチ用のコンテナ
 
308
   |   +- foo/  # Joeの"project"の"foo"ブランチ
 
309
   +- barry/
 
310
       +- bar/  # Barryの"project"の"bar"ブランチ
 
311
 
 
312
このアイデアでは、branchは入れ子になっておらず、branchは開発者によってのみ\
 
313
グループ化されます。
 
314
 
 
315
`Launchpad`_ で使われている派生系はこのようになっています::
 
316
 
 
317
  repository/
 
318
   +- joe/             # Joeのブランチ
 
319
   |   +- project1/    # Joeのブランチである"project1"用のコンテナ
 
320
   |   |   +- foo/     # Joeの"project1"の"foo"ブランチ
 
321
   |   +- project2/    # Joeの"project2"ブランチ用のコンテナ
 
322
   |       +- bar/     # Joeの"project2"の"bar"ブランチ
 
323
   |        ...
 
324
   |
 
325
   +- barry/
 
326
   |   +- project1/    # Barryの"project1"のブランチ用のコンテナ
 
327
   |       +- bug-10/  # Barryの"project1"の"bug-10"ブランチ
 
328
   |   ...
 
329
   +- group/
 
330
       +- project1/
 
331
           +- trunk/   # "project1"に焦点をあてたメイン開発
 
332
 
 
333
 
 
334
このレイアウトではそれぞれの開発者が取り組んでいるものを簡単に見ることができます。
 
335
焦点のブランチは"group" ディレクトリに保存されます。
 
336
これによって"グループ"が取り組んでいるブランチを見分けられます。
 
337
 
 
338
これによって異なる人々の作業内容をそれぞれ分離できますが、\
 
339
"プロジェクトX用のすべてのブランチ"を見つけるのが難しくなります。
 
340
`Launchpad`_ はデータベースバックエンドを伴う素晴らしいウェブインターフェイス\
 
341
を提供していて、"view"をこのレイアウトのトップに追加することでこの欠点を補っています。
 
342
これはそれぞれの個人が "``~/public_html``" ディレクトリを持ち、そこで独自の\
 
343
ウェブページを公開する個人用ホームページのモデルに近いです。
 
344
一般的に、集中型のプロジェクト用に共用リポジトリを作成するとき、\
 
345
個人単位で分割してからプロジェクト単位に分割することを望まないでしょう。
 
346
通常はプロジェクト単位で分割してから個人単位で分割するとよいでしょう。
 
347
 
 
348
要約
 
349
-----
 
350
 
 
351
最後に、誰にとってもうまくいく唯一の命名規則はありません。
 
352
開発者の人数、新しいブランチが作成される頻度、ブランチのライフサイクルなどに\
 
353
よって異なります。
 
354
自身に問いかける質問は次のとおりです:
 
355
 
 
356
  1) 寿命の長い少数のブランチを作るか、もしくはたくさんの"ミニ"機能ブランチを作るか
 
357
     (加えて:  ミニ機能ブランチをたくさん *作りたい* が現在のVCSでは苦痛なのでできないのではないか?)
 
358
 
 
359
  2) 1人で開発しているのか、大きなチームか?
 
360
 
 
361
  3) チームであれば、一般的に全員が同時に同じブランチに取り組むことを計画しているか?
 
362
     もしくは人々が追跡することを想定した"安定"ブランチを持つか。
 
363