← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

Turn completion assertions into separate methods.

Many common assertions used to be expressed as arguments to the complete
method.  This makes the checks more explicit, and the code easier to read.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/user-guide/zen.txt
1
 
Bazaarの哲学
2
 
============
3
 
 
4
 
Bazaarを完全に理解する
5
 
-----------------------
6
 
 
7
 
Bazaarは多くの点で他のVCSに似ていますが、最初見たときに必ずしも明らかではない大きな違いがいくつかあります。
8
 
このセクションでは Bazaarを"grok"するため、すなわち深く理解するために、
9
 
ユーザーが知る必要のあるいくつかの内容の説明を試みます。
10
 
 
11
 
注: Bazaarを使うためにこのセクションを十分に理解する必要はありません。
12
 
このセクションをさっと読んで後で戻るとよいでしょう。
13
 
 
14
 
リビジョン番号を理解する
15
 
------------------------
16
 
 
17
 
ブランチのメインラインのすべてのリビジョンは単純に増加する整数を持ちます(最初のコミットは1、10番目のコミットは10などです)。
18
 
これによって "私のブランチから10番目のリビジョンを獲得する"、もしくは "リビジョン3050で修正した" という言い方が自然になります。
19
 
 
20
 
ブランチにマージされるリビジョンに関しては、ドットつきのバージョンが使われます(たとえば、3112.1.5)。
21
 
ドットつきのリビジョン番号は3つの番号を持ちます [#]_.
22
 
最初の番号はメインのリビジョンの変更の由来を示します。
23
 
2番目の番号はブランチのカウンターです。
24
 
同じリビジョンから多くのブランチが由来することがあり得るので、それらのブランチはユニークな番号を取得します。
25
 
3番目の番号はブランチの開始以降のリビジョン番号です。
26
 
たとえば、3112.1.5はリビジョン3112からの最初のブランチで、そのブランチ上の5番目のリビジョンです。
27
 
 
28
 
.. [#] バージョン1.2以前のbzrでは少し異なるアルゴリズムが使われていました。
29
 
   いくつかの入れ子のブランチはよりシンプルな3つの番号システムではなく追加の番号(たとえば1.1.1.1.1)を取得します。
30
 
 
31
 
階層形式の履歴はよいものである
32
 
-------------------------------
33
 
 
34
 
多くの変更が一連のコミットで構成される状況で複数の開発者が変更を投稿するプロジェクトを想像してください。
35
 
具体例を示すために、次の事例を考えてみましょう:
36
 
 
37
 
 * プロジェクトのトランクのチップはリビジョン100です。
38
 
 * Maryは機能Xを配信するために3つの変更を行う
39
 
 * Billは機能Yを配信するために4つの変更を行う
40
 
 
41
 
開発者が並行して作業して伝統的な集中型のVCSのアプローチを利用する場合、
42
 
大抵の場合プロジェクトの履歴は次のようにMaryの変更とBillの変更が交互に混ざります::
43
 
 
44
 
  107: Add documentation for Y
45
 
  106: Fix bug found in testing Y
46
 
  105: Fix bug found in testing X
47
 
  104: Add code for Y
48
 
  103: Add documentation for X
49
 
  102: Add code and tests for X
50
 
  101: Add tests for Y
51
 
  100: ...
52
 
 
53
 
多くのチームはこのアプローチを利用します。彼らのツールではブランチの作成とマージが難しいからです。
54
 
結果として、開発者はトランクからの更新とコミットを頻繁に行い、すべてのコミットを通してそれを広げることで統合の苦痛を最小化します。
55
 
望むのであれば、このようにBazaarを使うことができます。
56
 
Bazaarは考慮すべき別の方法を提供します。
57
 
 
58
 
分散型のVCSツールによって推奨される代替のアプローチは機能ブランチを作り、準備ができたらそれらを統合することです。
59
 
この場合、Maryの機能ブランチは次のようになります::
60
 
 
61
 
  103: Fix bug found in testing X
62
 
  102: Add documentation for X
63
 
  101: Add code and tests for X
64
 
  100: ...
65
 
 
66
 
そしてBillのものは次のようになります::
67
 
 
68
 
  104: Add documentation for Y
69
 
  103: Fix bug found in testing Y
70
 
  102: Add code for Y
71
 
  101: Add tests for Y
72
 
  100: ...
73
 
 
74
 
機能が独立していてリニアな履歴を維持したいのであれば、変更はバッチでトランクにpushされます。
75
 
(技術的には、これを行う方法は無数にありますがこの検討内容の範囲を超えます。)
76
 
結果の履歴は次のようになります::
77
 
 
78
 
  107: Fix bug found in testing X
79
 
  106: Add documentation for X
80
 
  105: Add code and tests for X
81
 
  104: Add documentation for Y
82
 
  103: Fix bug found in testing Y
83
 
  102: Add code for Y
84
 
  101: Add tests for Y
85
 
  100: ...
86
 
 
87
 
これを実現するために少し努力が必要な一方で、リビジョンをランダムに織り交ぜるよりもいくつかの利点があります。
88
 
よりベターですが、non-linearな履歴を形成してブランチは一緒にマージできます。
89
 
結果は次のようになります::
90
 
 
91
 
  102: Merge feature X
92
 
       100.2.3: Fix bug found in testing X
93
 
       100.2.2: Add documentation for X
94
 
       100.2.1: Add code and tests for X
95
 
  101: Merge feature Y
96
 
       100.1.4: Add documentation for Y
97
 
       100.1.3: Fix bug found in testing Y
98
 
       100.1.2: Add code for Y
99
 
       100.1.1: Add tests for Y
100
 
  100: ...
101
 
 
102
 
もしくは次のようになります::
103
 
 
104
 
  102: Merge feature X
105
 
       100.2.3: Fix bug
106
 
       100.2.2: Add documentation
107
 
       100.2.1: Add code and tests
108
 
  101: Merge feature Y
109
 
       100.1.4: Add documentation
110
 
       100.1.3: Fix bug found in testing
111
 
       100.1.2: Add code
112
 
       100.1.1: Add tests
113
 
  100: ...
114
 
 
115
 
多くの理由からこれはよいものと考えられます:
116
 
 
117
 
 * プロジェクトの履歴を理解するのが楽になります。
118
 
   関連した変更はクラスターを形成し明確に区切られます。
119
 
 
120
 
 * ブランチのメインライン上のコミットだけを見るために履歴を簡単に折りたたむことができます。
121
 
   (このレベルでは興味のない膨大な数のコミットの代わりに)
122
 
   このようなトランクの履歴を閲覧するとき、高いレベルのコミットだけ見えます。
123
 
 
124
 
 * 必要であれば、より簡単に機能の変更を取り消します
125
 
 
126
 
 * 継続的インテグレーション(Continuous integration: CI)ツールは
127
 
   マージをメインラインにコミットするためにすべてのテストが合格することを保証するために使われます。
128
 
   (多くの場合、すべての単独のコミットの後でCIツールの引き金を引くのは適切ではありません。
129
 
   テストの中には開発の間に失敗するものがあるからです。
130
 
   実際、テストファーストの追加 - テスト駆動開発(TDD)のスタイル - によってこれが保証されます！)
131
 
 
132
 
要約すると、重要な点は次のとおりです:
133
 
 
134
 
  *ブランチを利用してあなたの作業内容を編成する*
135
 
 
136
 
  *マージ機能を利用して変更を統合する*
137
 
 
138
 
  *順序つきの番号と階層によって履歴を追跡するのが楽になる*
139
 
 
140
 
 
141
 
それぞれのブランチは履歴の独自のビューを持つ
142
 
---------------------------------------------
143
 
 
144
 
上述のように、Bazaarは次の内容を区別します:
145
 
 
146
 
 * メインラインのリビジョン、すなわちブランチにコミットしたもの
147
 
 
148
 
 * マージしたリビジョン、マージをコミットすることで祖先として追加されるもの
149
 
 
150
 
それぞれのブランチは効率的に履歴の独自ビューを持ち、すなわち、
151
 
異なるブランチは同じリビジョンに異なる"ローカルな"リビジョン番号を与えます。
152
 
 
153
 
マージされたリビジョンは常にドットつきのリビジョン番号を入手するのに対して
154
 
メインラインのリビジョンは常に単独の数字のリビジョン番号が割り当てられます。
155
 
 
156
 
上記の例を拡張するためには、Maryが変更を完了させた後でプロジェクトのトランクにマージした後に
157
 
Maryのブランチのリビジョンの履歴は次のようになります::
158
 
 
159
 
  104: Merge mainline
160
 
       100.2.1: Merge feature Y
161
 
       100.1.4: Add documentation
162
 
       100.1.3: Fix bug found in testing
163
 
       100.1.2: Add code
164
 
       100.1.1: Add tests
165
 
  103: Fix bug found in testing X
166
 
  102: Add documentation for X
167
 
  101: Add code and tests for X
168
 
  100: ...
169
 
 
170
 
繰り返しますが、Maryはこの変更を開発するためにステップを見るために彼女の履歴のトップレベルを調べることが簡単になります。
171
 
この文脈では、トランクのマージ(とそれを行うことによる衝突の解消)はこのブランチの履歴に関しては単なる1つのステップです。
172
 
 
173
 
Bazaarは履歴を変更するのでなければグローバルなリビジョン識別子を変更するのでもないことを覚えておくのは大事です。
174
 
本当に望むのであれば常に後者を使用できます。
175
 
実際、ブランチのURLをコンテクストとして提供する *限り* コミュニケーションをするときに特定のリビジョン番号を使うことができます。
176
 
(多くのBazaarのプロジェクトでは、開発者はブランチURLなしでリビジョン番号を交換するとき中心のトランクのブランチをほのめかします)
177
 
 
178
 
マージはブランチのリビジョン番号を変更しません。それらはローカルのリビジョン番号を新しくマージしたリビジョンに割り当てるからです。
179
 
Bazaarがブランチのリビジョン番号を変更する唯一のときはあなたが明示的に別のブランチをミラーリングするように頼むときです。
180
 
 
181
 
注: リビジョンは安定した方法で番号づけされます: 2つのブランチがメインラインで同じリビジョン番号を持つとき、
182
 
そのリビジョンの祖先のすべてのリビジョンは同じリビジョン番号を持ちます。
183
 
たとえば、AliceとBobのブランチがリビジョン10に一致するのであれば、それらはそれ以前のすべてのリビジョンで一致します。
184
 
 
185
 
要約
186
 
-----
187
 
 
188
 
一般的に、前に示されたアドバイスに従うのであれば - ブランチの中で作業し、\
189
 
連携するためにマージを使う -
190
 
Bazaarが一般的にあなたが期待することを行うことがわかります。
191
 
 
192
 
次の章では、Bazaarを利用したさまざまな方法: もっとも単純なプロジェクト、個人プロジェクトなどを試します。
193
 
 
194
 
..
195
 
   vim: ft=rst tw=74 ai