← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/tutorials/centralized_workflow.txt

  • Committer: John Arbash Meinel
  • Author(s): Mark Hammond
  • Date: 2008-09-09 17:02:21 UTC
  • mto: This revision was merged to the branch mainline in revision 3697.
  • Revision ID: john@arbash-meinel.com-20080909170221-svim3jw2mrz0amp3
An updated transparent icon for bzr.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/tutorials/centralized_workflow.txt
1
 
========================================
2
 
集中型ワークフローのチュートリアル
3
 
========================================
4
 
 
5
 
 
6
 
概要
7
 
====
8
 
 
9
 
この文書では、 Bazaar_ を使用することで実現可能なワークフローについて説明します。
10
 
つまり、分散バージョンコントロールシステムである Bazaar_ を、集中型のやり方で使用するためのワークフローです。 
11
 
Bazaar_ は、非常にフレキシブルに設計されており、完全な分散型からほとんど集中型のワークフローまで、\
12
 
いくつかの異なるワークフローを受け入れることができます。
13
 
このワークフローは、初めてのユーザでも簡単に Bazaar_ を使いこなすことができ、\
14
 
分散型と集中型のオペレーションを組み合わせた業務にも対応できるようになっています。
15
 
 
16
 
基本的に、この文書はCVSや Subversion のような集中型バージョンコントロールシステムの経験があるユーザ向けに書かれています。
17
 
これらの環境では、一般的に、コードベースをホストする単一の中央サーバが存在し、複数の人々がこのコードベース上で作業して、\
18
 
お互いの作業の同期をとることになります。 
19
 
また、このワークフローは、一人の開発者が複数のマシーン上で作業をする場合にも適用できます。
20
 
 
21
 
.. _Bazaar: http://bazaar.canonical.com
22
 
 
23
 
 
24
 
初期セットアップ
25
 
================
26
 
 
27
 
Bazaar_ がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。
28
 
 
29
 
ユーザのEメールの設定
30
 
---------------------
31
 
 
32
 
ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、\
33
 
ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。
34
 
 
35
 
::
36
 
 
37
 
   % bzr whoami "John Doe <jdoe@organization.com>"
38
 
 
39
 
 
40
 
ローカルリポジトリのセットアップ
41
 
--------------------------------
42
 
 
43
 
Bazaar_ のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。
44
 
最適化の方法の一つとして、関連するブランチ同士の情報を統合して、\
45
 
新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。
46
 
 
47
 
そのための一番いい方法は、 `共用リポジトリ`_ を作成することです。
48
 
一般に、 `共用リポジトリ`_ のサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。
49
 
ですので、ホームディレクトリに `共用リポジトリ`_ を作成するようにしましょう。
50
 
そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。
51
 
 
52
 
::
53
 
 
54
 
  % bzr init-repo --trees ~
55
 
 
56
 
 
57
 
リモートリポジトリのセットアップ
58
 
---------------------------------
59
 
 
60
 
作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。
61
 
集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。
62
 
たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。)
63
 
実際のところ、これは、特に職場ではとてもよい設定です。
64
 
蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こっても\
65
 
コミットされたデータはけっして無くなりません。
66
 
 
67
 
それでは、プロジェクト内で共有する ``centralhost`` というマシーンを用意しましょう。
68
 
先ほども言いましたが、ディスクの使用量を節約するために、 `共用リポジトリ`_ を使用します。
69
 
 
70
 
::
71
 
 
72
 
  % bzr init-repo --no-trees bzr+ssh://centralhost/srv/bzr/
73
 
 
74
 
この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。
75
 
``--no-tree`` オプションの指定によって、ワーキングツリーを作らないようになります。
76
 
中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。
77
 
 
78
 
ここで、 ``bzr+ssh`` というURLを使っていますが、これは、 SSH セキュアシェ
79
 
ル上の
80
 
Bazaar 独自プロトコルを意味しています。 bzr+ssh サーバーのセットアップに関
81
 
する
82
 
情報に着いては、管理者向けガイドを参照してください。
83
 
 
84
 
 
85
 
 
86
 
既存のプロジェクトからの移行
87
 
=============================
88
 
 
89
 
リポジトリができましたので、プロジェクトの作成にかかりましょう。
90
 
たいていの場合、 Bazaar_ でバージョン管理したい作業中のコードがすでにあるはずです。
91
 
もし、そのコードがもともとソース管理されていたのであれば、履歴の情報を保ったまま Bazaar_ に\
92
 
変換する方法がたくさんあります。
93
 
しかしながら、それについてはここでは説明しません。詳しくは、 `Tracking Upstream`_ の\
94
 
"Converting and keeping history"セクションを見てください。
95
 
 
96
 
.. _Tracking Upstream: http://wiki.bazaar.canonical.com/TrackingUpstream
97
 
 
98
 
..
99
 
   XXX: プロジェクトの変換について話をするための別の文書が必要なのですが、\
100
 
   今ある中ではTrackingUpstreamが一番よい文書です。
101
 
 
102
 
 
103
 
Developer 1: 最初のリビジョンを作成する
104
 
-----------------------------------------
105
 
 
106
 
まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。
107
 
仮に、"sigil"というプロジェクトをバージョン管理しようとしているとしましょう。
108
 
 
109
 
::
110
 
 
111
 
  % bzr init bzr+ssh://centralhost/srv/bzr/sigil
112
 
 
113
 
これは、CVSで言うところの"HEAD"ブランチ、Subversionなら"trunk"にあたるものだと考えてかまいません。
114
 
これを ``dev`` ブランチと呼ぶことにしましょう。
115
 
 
116
 
他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。
117
 
同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。 
118
 
::
119
 
 
120
 
  % cd ~
121
 
  % mkdir work
122
 
  % cd work
123
 
  % mkdir sigil
124
 
  % cd sigil
125
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
126
 
  % cd dev
127
 
  % cp -ar ~/sigil/* .
128
 
  % bzr add
129
 
  % bzr commit -m "Initial import of Sigil"
130
 
 
131
 
前のセクションでは、空のブランチ(``sigil`` ブランチ)を ``centralhost`` に作成して、\
132
 
それをクライアント端末にチェックアウトしたあと、元々あったプロジェクトのファイルを追加しています。
133
 
作業ディレクトリをセットアップするための方法はたくさんありますが、この方法を使うと機能追加用/バグフィックス用\
134
 
のブランチを使った作業が簡単にできます。
135
 
そして、複数のブランチをとてもうまく扱えるというのが、 Bazaar_ の長所の一つなのです。
136
 
 
137
 
この場合、リモートブランチのチェックアウトを持っているので、 ``~/work/sigil/dev/`` に対してコミットした内容が、\
138
 
ローカルと ``centralhost`` の両方に自動的に保存される訳です。
139
 
 
140
 
 
141
 
Developer N: プロジェクトの作業コピーを取得する
142
 
--------------------------------------------------
143
 
 
144
 
プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、\
145
 
他のみんなは単にそのブランチをチェックアウトするだけです。
146
 
**ただし、** `ユーザのEメールの設定`_ **と** `ローカルリポジトリのセットアップ`_ **は見ておいてください。**
147
 
 
148
 
現在開発中のツリーのコピーを取得するためには::
149
 
 
150
 
  % cd ~/work/sigil
151
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil dev
152
 
 
153
 
今、二人の人が ``bzr+ssh://centralhost/srv/bzr/sigil`` のチェックアウトを持っている状態なので、\
154
 
片方のチェックアウトが最新のものより古くなってしまうタイミングが出てきます。
155
 
コミットの時に、チェックアウトが古いければ Bazaar_ がエラーを返して、コミットは失敗します。
156
 
チェックアウトを最新にするには、よそで変更されたツリーに対して ``bzr update`` を使用します。
157
 
この時、もし同じファイルが変更されていれば、競合の解決が必要になるかもしれません。
158
 
 
159
 
 
160
 
別ブランチでの開発
161
 
====================
162
 
 
163
 
ここまでは、全員が同じブランチで作業して、変更をコミットしていました。
164
 
これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があると\
165
 
いうことです。
166
 
また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、\
167
 
全員が問題を抱えることになります。
168
 
 
169
 
たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合する\
170
 
というやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。
171
 
CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、\
172
 
ブランチ間できちんと同期がとれた状態に保つのは難しいことです。
173
 
Bazaar_ は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を\
174
 
適用することができます。
175
 
 
176
 
 
177
 
新しいブランチを作成してそこで作業する
178
 
---------------------------------------
179
 
まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。
180
 
そこで、 ``centralhost`` 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。
181
 
 
182
 
::
183
 
 
184
 
  % cd ~/work/sigil
185
 
  % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
186
 
               bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes
187
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
188
 
  % cd doodle-fixes
189
 
 
190
 
これで、 ``doodle`` に必要な修正を当てるための場所ができました。
191
 
また、他の部分の修正をする人に邪魔されることもありません。
192
 
チェックアウトを持っているため、 ``~/work/sigil/doodle-fixes/`` に対してコミットした内容は\
193
 
``centralhost`` 上にも現れます。
194
 
[#nestedbranches]_ ``dev`` ブランチと同じように、このようなブランチ上で二人の開発者が共同で\
195
 
作業することもできます。
196
 
[#cbranch]_
197
 
 
198
 
.. [#nestedbranches] あるブランチのサブディレクトリに別のブランチがあるというのはおかしなこと\
199
 
   に見えるかもしれませんが、これは何もおかしくありません。入れ子になったブランチは外側のブランチ\
200
 
   から派生しているという点で、名前空間の階層と同じようなものだと考えることができます。
201
 
 
202
 
.. [#cbranch] たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。
203
 
   このURLの入力を簡単にするために、ブランチエイリアスなどたくさんの方法を検討しています。
204
 
   今のところ、 bzrtools_ プラグインが ``bzr cbranch`` コマンドを提供しています。
205
 
   これは、ベースとなるブランチを指定して、新しく公開ブランチを作成し、そのチェックアウトを作成する\
206
 
   ことを少ない入力でできるように設計されています。
207
 
   ``cbranch`` の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:
208
 
 
209
 
::
210
 
 
211
 
   % bzr cbranch dev my-feature-branch
212
 
 
213
 
.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
214
 
 
215
 
 
216
 
変更内容をマージする
217
 
----------------------
218
 
 
219
 
``doodle-fixes`` での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。::
220
 
 
221
 
  % cd ~/work/sigil/dev
222
 
  % bzr merge ../doodle-fixes
223
 
 
224
 
これで、変更内容は ``dev`` ブランチ上でもアクセスできるようになりますが、まだコミットはされていません。
225
 
最終的な変更内容をレビューして、コードがちゃんとコンパイルでき、テストをパスすることを確認したいならこの時です。
226
 
``bzr status`` コマンドと ``bzr diff`` コマンドがここで役立ちます。
227
 
また、競合を解決するのもこの時です。Bazaar_ では、競合を解決するまではコミットできないようになっています。
228
 
そのため、間違って競合マーカーをコミットしてしまうことはありません。
229
 
``bzr status`` コマンドを使えば、他の変更内容と一緒に競合の情報も表示されます。
230
 
``bzr conflicts`` なら、競合の情報だけが表示されます。
231
 
競合を解決し終わったら、``bzr resolve file/name`` か ``bzr resolve --all`` を実行してください。
232
 
[#resolve]_ もし、解決が特に難しい競合がある場合は、 ``bzr remerge`` コマンドを使いたいと思うかもしれません。
233
 
このコマンドで、別のマージアルゴリズムを試してみることができ、さらに元のソース行を表示する\
234
 
こともできます。(``--show-base``)
235
 
 
236
 
.. [#resolve] マージ実行中に競合の解決をさせるシステムもあります。
237
 
   私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単である\
238
 
   ことに気づきました。
239
 
   そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。
240
 
 
241
 
 
242
 
推奨のブランチ構成
243
 
---------------------
244
 
 
245
 
とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの\
246
 
作業領域を用意するという方法があります。これは以下のコマンドでできます。::
247
 
 
248
 
  % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
249
 
               bzr+ssh://centralhost/srv/bzr/sigil/user-a
250
 
  % bzr branch bzr+ssh://centralhost/srv/bzr/sigil \
251
 
               bzr+ssh://centralhost/srv/bzr/sigil/user-b
252
 
 
253
 
これで、開発者ごとに専用の作業用ブランチを割り当てています。
254
 
さらに、開発者自身で [#cbranch]_ を使用して新しく新機能開発用ブランチを作成することも簡単にできます。
255
 
::
256
 
 
257
 
  % bzr branch bzr+ssh://centralhost/srv/bzr/sigil/user-a \
258
 
               bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature
259
 
  % cd ~/work/sigil
260
 
  % bzr checkout bzr+ssh://centralhost/srv/bzr/sigil/user-a/feature myfeature
261
 
 
262
 
 
263
 
用語解説
264
 
=========
265
 
 
266
 
共用リポジトリ
267
 
--------------
268
 
 
269
 
Bazaar_ には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ\
270
 
旧来の概念に似ています。
271
 
たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は\
272
 
全くなく、作業ツリーのファイルのチェックアウトがあるだけです。
273
 
ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。
274
 
開発者間でも共用される *かも知れません* が、開発者間での共用はスタンドアロンブランチでも可能です。
275
 
 
276
 
Bazaar_ の用語では、"共用リポジトリ"とは複数のブランチが履歴情報を **共有** できる場所のことです。
277
 
分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。
278
 
しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方が\
279
 
いいためです。
280
 
 
281
 
 
282
 
..
283
 
   vim: tw=74 ft=rst