← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

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

  • Committer: Alexander Belchenko
  • Date: 2006-07-30 16:43:12 UTC
  • mto: (1711.2.111 jam-integration)
  • mto: This revision was merged to the branch mainline in revision 1906.
  • Revision ID: bialix@ukr.net-20060730164312-b025fd3ff0cee59e
rename  gpl.txt => COPYING.txt

Show diffs side-by-side

added added

removed removed

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