1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
.. _organizing-your-workspace:
作業スペースを構成する
=========================
.. _common-workspace-layouts:
一般的なレイアウト
---------------------
Bazaarのユーザーがプロジェクトのための作業スペースを構成するベストな方法は、\
次のような要素に依存します:
* ユーザーの役割: プロジェクトオーナー vs コア開発者 vs カジュアルな貢献者
* ワークフロー: プロジェクトが推奨/強制している、貢献のためのワークフロー
* サイズ: 大きいプロジェクトは小さいプロジェクトよりもリソースを要求します。
少なくとも4つの一般的なワークスペースの構成方法があります。
* lightweight checkout
* standalone tree
* feature branches
* switchable sandbox.
各レイアウトの簡単な説明を以下に記します。
軽量チェックアウト
--------------------
このレイアウトでは、作業ツリーはローカルですがブランチはリモートにあります。
これはCVSやSVNで一般的に利用されるレイアウトで、シンプルで簡単に理解できます。
セットアップするには::
bzr checkout --lightweight URL project
cd project
作業するには::
(make changes)
bzr commit
(make changes)
bzr commit
各コミットが暗黙的に変更を同じブランチを利用している他の人に公開していることに\
注意してください。ただし、コミットが成功するには作業ツリーがリモートのブランチの\
最新の状態になっている必要があります。最新のコードを取得してマージするには、::
bzr update
スタンドアロンツリー
----------------------
このレイアウトでは、作業ツリーとブランチは一つの場所にあります。
共有リポジトリが上位のディレクトリに無い限り、リポジトリも同じ場所に\
格納されます。これはBazaarのデフォルトレイアウトで、小規模から中規模の\
大きさのプロジェクトに適しています。
セットアップ::
bzr branch URL project
cd project
作業::
(make changes)
bzr commit
(make changes)
bzr commit
変更を中央の場所に公開する::
bzr push [URL]
pushするURLは最初の一回だけ要求されます。
もし中央の場所が、pushするまでの間に他のユーザーからの変更を受け取っていた\
場合、pushする前にそれらの変更をローカルブランチにmergeする必要があります::
bzr merge
(resolve conflicts)
bzr commit
代替手段として、チェックアウトを使うこともできます。ブランチと同じように\
チェックアウトも履歴全体をローカルにコピーしますが、ローカルブランチが\
リモートの場所に束縛されているので、両方のブランチに一度にコミットされます。
注意: チェックアウトはローカルコミット+pushに比べてスマートです。
チェックアウトはまずリモートにコミットして、それが成功したときにだけ\
ローカルにもコミットします。
.. _feature-branches:
機能ブランチ
--------------
このレイアウトでは、いくつかのブランチとツリーがあって、一般的にリポジトリを共有します。
一つのブランチは "trunk" のミラーを保存していて、それ以外の作業単位(例:バグ修正や
機能追加)にはそれぞれの "機能ブランチ" を作ります。
このレイアウトはほとんどのプロジェクト、特に中規模のものにとって理想的です。
セットアップ::
bzr init-repo project
cd project
bzr branch URL trunk
機能ブランチを開始する::
bzr branch trunk featureX
cd featureX
作業する::
(make changes)
bzr commit
(make changes)
bzr commit
変更をメーリングリストに公開してレビュー&承認してもらう::
bzr send
変更を公開ブランチで公開する(たとえばLaunchpad上でmerge要求を出すために)::
bzr push [URL]
変化形として、trunkをチェックアウトとして作ることもできます。
もしtrunkへのコミット権限を持っているのであれば、trunkへマージして\
コミットするとその変更は暗黙的に公開されます。
他には、trunkのURLが読み込み専用だった場合(例: HTTP アドレス)、チェックアウトを\
利用することはローカルのtrunkミラーに間違えて変更を登録してしまうことを\
防止します。これはプロジェクトがPQMなどのゲートキーパー型のワークフロー\
を利用していたときに有用です。
.. _local-sandbox:
ローカルのsandbox
------------------
このレイアウトは機能ブランチのレイアウトとほぼ同じですが、機能ブランチが\
それぞれ作業ツリーを持つ代わりに一つの作業ツリーを共用する点が違います。
これはgitのデフォルトレイアウトに似ていて、大きなツリー(10000ファイル以上\
とか)を持つプロジェクトや、ビルドによる加工物(.oや.classファイルといった)\
を大量に作るプロジェクトに適しています。
セットアップ::
bzr init-repo --no-trees project
cd project
bzr branch URL trunk
bzr checkout --lightweight trunk sandbox
cd sandbox
これでsandboxで作業を開始できますが、sandboxがtrunkを参照したままコミット\
してしまうと、(trunkがcheckoutで無い限り)trunkが元のtrunkのミラーでは\
なくなってしまいます。
なので、まず機能branchを作ってsandboxをそちらに紐づけましょう::
bzr branch ../trunk ../featureX
bzr switch ../featureX
この後の、変更を行ったりその変更を公開して適用してもらうまでの\
プロセスは機能ブランチレイアウトの時と同じです。
進んだレイアウト
----------------
お望みとあれば、あなたのお好みの構成に合わせてレイアウトを決めることができます。
例やアイデアについては `共有リポジトリのレイアウト <shared_repository_layouts.html>`_
を参照してください。
|