← Back to branch summary

~bzr/ubuntu/lucid/bzr/beta-ppa

« back to all changes in this revision

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

  • Committer: Martin Pool
  • Date: 2010-07-02 07:29:40 UTC
  • mfrom: (129.1.7 packaging-karmic)
  • Revision ID: mbp@sourcefrog.net-20100702072940-hpzq5elg8wjve8rh
http://bugs.debian.org/452024
http://bugs.debian.org/464688
http://bugs.debian.org/523595
http://bugs.debian.org/526233
http://bugs.debian.org/537708
http://bugs.debian.org/555336
http://bugs.debian.org/555343
https://launchpad.net/bugs/249452
https://launchpad.net/bugs/385074
* PPA rebuild.
* PPA rebuild for Karmic.
* PPA rebuild for Jaunty.
* PPA rebuild for Hardy.
* From postinst, actually remove the example bash completion scripts.
  (LP: #249452)
* New upstream release.
* New upstream release.
* New upstream release.
* Revert change to Build-depends: Dapper does not have python-central.
  Should be python-support..
* Target ppa..
* Target ppa..
* Target ppa..
* Target ppa..
* New upstream release.
* Switch to dpkg-source 3.0 (quilt) format.
* Bump standards version to 3.8.4.
* Remove embedded copy of python-configobj. Closes: #555336
* Remove embedded copy of python-elementtree. Closes: #555343
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* Change section from 'Devel' to 'Vcs'..
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* debian/control: Fix obsolete-relation-form-in-source
  lintian warning. 
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Split out docs into bzr-doc package.
* New upstream release.
* Added John Francesco Ferlito to Uploaders.
* Fix install path to quick-reference guide
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to doc paths changing
* New upstream release.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to doc paths changing
* New upstream release.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to doc paths changing
* New upstream release.
* Fix FTBFS due to path changes, again, again.
* Fix FTBFS due to path changes, again.
* Fix FTBFS due to path changes.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Bump standards version to 3.8.3.
* Remove unused patch system.
* New upstream release.
* New upstream release.
* New upstream release.
* Fix copy and paste tab error in .install file
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
 + Fixes compatibility with Python 2.4. Closes: #537708
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream version.
* Bump standards version to 3.8.2.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Add python-pyrex to build-deps to ensure C extensions are always build.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Split documentation into bzr-doc package. ((LP: #385074)
* Multiple packaging changes to make us more linitan clean.
* New upstream release.
* Split documentation into bzr-doc package. ((LP: #385074)
* Multiple packaging changes to make us more linitan clean.
* New upstream release.
* Split documentation into bzr-doc package. ((LP: #385074)
* Multiple packaging changes to make us more linitan clean.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Fix API compatibility version. (Closes: #526233)
* New upstream release.
  + Fixes default format for upgrade command. (Closes: #464688)
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Add missing dependency on zlib development library. (Closes:
  #523595)
* Add zlib build-depends.
* Add zlib build-depends.
* Add zlib build-depends.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Move to section vcs.
* Bump standards version to 3.8.1.
* New upstream release.
* Remove temporary patch for missing .c files from distribution
* New upstream release.
* Remove temporary patch for missing .c files from distribution
* New upstream release.
* Remove temporary patch for missing .c files from distribution
* Add temporary patch for missing .c files from distribution
* Add temporary patch for missing .c files from distribution
* Add temporary patch for missing .c files from distribution
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Recommend ca-certificates. (Closes: #452024)
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Update watch file. bazaar now uses launchpad to host its sources.
* Remove patch for inventory root revision copy, applied upstream.
* New upstream release.
* New upstream release.
* New upstream release
* Force removal of files installed in error to /etc/bash_completion.d/
  (LP: #249452)
* New upstream release.
* New upstream release
* New upstream release.
* Bump standards version.
* Include patch for inventory root revision copy, required for bzr-svn.
* New upstream release.
* Remove unused lintian overrides.
* Correct the package version not to be native.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* New upstream release.
* Final 1.5 release.
* New upstream release.
* New upstream release.
* New upstream release.
* Add myself as a co-maintainer.
* Add a Dm-Upload-Allowed: yes header.
* New upstream bugfix release.
* New upstream release.
* Final 1.3 release.
* New upstream release.
* First release candidate of the upcoming 1.3 release.
* Rebuild to fix the problem caused by a build with a broken python-central.
* New upstream release.
* Rebuild for dapper PPA.
* Apply Lamont's patches to fix build-dependencies on dapper.
  (See: https://bugs.launchpad.net/bzr/+bug/189915)

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