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