~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/tutorials/tutorial.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:
1
 
.. This file is in Python ReStructuredText format - it can be formatted
2
 
.. into HTML or text.  In the future we plan to extract the example commands
3
 
.. and automatically test them.
4
 
 
5
 
.. This text was previously on the wiki at
6
 
.. http://bazaar.canonical.com/IntroductionToBzr
7
 
.. but has been moved into the source tree so it can be kept in sync with
8
 
.. the source and possibly automatically checked.
9
 
 
10
 
======================
11
 
Bazaar チュートリアル
12
 
======================
13
 
 
14
 
 
15
 
.. Introduction
16
 
 
17
 
はじめに
18
 
============
19
 
 
20
 
もし、もう分散型バージョン管理に慣れ親しんでいるなら、
21
 
"Bazaarに自己紹介する" の節までとばしてください。
22
 
もし、分散型でないバージョン管理に慣れ親しんでいるけれど分散型バージョン管理は\
23
 
よくわからないのであれば、"分散バージョン管理と分散でないバージョン管理の違い"まで\
24
 
とばしてください。
25
 
それ以外の場合、コーヒーか紅茶(訳注:日本茶でもいいですよ)を用意して、\
26
 
リラックスして読み始めてください。
27
 
 
28
 
.. purpose-of-version-control
29
 
 
30
 
バージョン管理の目的
31
 
====================
32
 
 
33
 
なにかのテキストデータ(プログラムのソースコード、Webサイト、Unixシステムでの\
34
 
設定ファイルなど)を扱う作業をしているとしましょう。
35
 
なにかミスをして、重大なデグレードを引き起こしてしまうかもしれません。
36
 
例えばメールサーバーの設定ファイルを消してしまったり、だいじなプロジェクトの\
37
 
ソースコードを壊してしまったりすることがあります。
38
 
だいじな情報を失って、何が何でも取り戻したいと思った経験があるのであれば、\
39
 
きっとあなたはBazaarを使う準備ができています。
40
 
 
41
 
Bazaarをはじめとするバージョン管理システムは、ディレクトリに起こった変更を\
42
 
**ブランチ (branch)** というディレクトリよりも複雑なものの中に入れて\
43
 
管理します。
44
 
ブランチは今ディレクトリの中に何が入っているかだけでなく、過去のいろいろな\
45
 
時点でのディレクトリの中身を格納しています。
46
 
なので、望まぬ変更をしてしまったときには過去の時点の状態に戻すことができます。
47
 
 
48
 
バージョン管理システムは、ユーザーが "**リビジョン (revision)** をコミット"
49
 
することで変更をブランチに保存します。
50
 
このときに生成されるリビジョンとは、本質的にいって、前回保存したときからの\
51
 
変更点になります。
52
 
 
53
 
リビジョンはそれ以外のものも持っています(原文:These revisions have other
54
 
uses as well.)
55
 
たとえば、オプションのログメッセージをつけることで、変更が何を意味して\
56
 
いるのかというコメントを残すことができます。
57
 
実際に利用されるログメッセージは、 "Webテンプレートをテーブルを閉じるように\
58
 
修正" とか "SFTPに対応した。 #595 を修正。" といったものです。
59
 
 
60
 
こういったログが保存されているおかげで、たとえば後になって SFTP に問題が発生\
61
 
したときに、問題が発生するようになったのがどの時点なのか目星をつけることが\
62
 
できます。
63
 
 
64
 
 
65
 
分散バージョン管理と分散でないバージョン管理の違い
66
 
===================================================
67
 
 
68
 
多くのバージョン管理システムはサーバーに配置されています。
69
 
バージョン管理されているコードに対して作業をしたい場合、サーバーに接続して\
70
 
コードを "チェックアウト (checkout)" する必要があります。
71
 
そうすると、変更やコミットができるディレクトリができます。
72
 
バージョン管理システムのクライアントは、バージョン管理システムのサーバーに\
73
 
コミットされた変更を保存します。この方式は集中型として知られています。
74
 
 
75
 
集中型にはいくつかの欠点があります。
76
 
集中型バージョン管理システムは、動作するためにサーバーとの接続を要求します。
77
 
このことは、サーバーがどこかインターネット上にあって、あなたのマシンが\
78
 
インターネットに接続できないときに問題になります。
79
 
もしくは、あなたのマシンがインターネットに接続できてもサーバーが落ちている\
80
 
ときにもやはり問題になります。
81
 
 
82
 
分散バージョン管理システムは、ブランチをクライアントと同じマシンに置くことで\
83
 
この問題を解決しています。
84
 
Bazaarの場合、ブランチはバージョン管理されているコードと同じディレクトリに\
85
 
保存されます。
86
 
これにより、ユーザーは(たとえオフラインであったとしても)好きなときに変更を保存\
87
 
(**コミット (commit)**)することができます。
88
 
インターネット接続が必要になるのは、どこか別の場所にあるブランチの変更にアクセス\
89
 
するときだけです。
90
 
 
91
 
.. TODO:
92
 
.. Performing this tracking by hand is a awkward process that over time
93
 
.. becomes unwieldy. の部分の訳が判らない。
94
 
 
95
 
多くの人が必要としていることは、ディレクトリ内でおこったファイルやサブディレクトリ\
96
 
の変更を追跡することです。
97
 
この追跡を手でおこなうのは面倒で不恰好な作業です。
98
 
これは、Bazaarのようなバージョン管理システムの目的のひとつです。
99
 
バージョン管理システムはユーザーが指示したときにディレクトリツリーの
100
 
**リビジョン (revision)** を作ることでこの作業を自動化します。
101
 
 
102
 
バージョン管理システムは単に保存したりundoしたりするだけではありません。
103
 
たとえばBazaarでは、ソフトウェアのあるブランチから変更を取り出して、\
104
 
関連する別のブランチに適用することができます。このとき、変更を取り出す\
105
 
ブランチは別の人のものであってもかまいません。これにより、開発者のグループは\
106
 
お互いに書き込み権を与えることなく共同作業することができます。
107
 
 
108
 
.. Bazaar remembers the ''ancestry'' of a revision: the previous revisions
109
 
.. that it is based upon.  A single revision may have more than one direct
110
 
.. descendant, each with different changes, representing a divergence in the
111
 
.. evolution of the tree. By branching, Bazaar allows multiple people to
112
 
.. cooperate on the evolution of a project, without all needing to work in
113
 
.. strict lock-step.  Branching can be useful even for a single developer.
114
 
 
115
 
Bazaarではリビジョンの ''親 (ancestry)'' 、つまりそのリビジョンの元になった\
116
 
リビジョンを記録しています。
117
 
ひとつのリビジョンは複数の、それぞれ別の変更を含む子供リビジョンを持つことが\
118
 
あり、それはツリーの進化が分岐していることを意味しています。
119
 
Bazaarではブランチを作ることによって、複数の人が厳しい lock-step をとらなくても\
120
 
協力することができます。
121
 
ブランチを作ることは個人での開発でも便利です。
122
 
 
123
 
.. Introducing yourself to Bazaar
124
 
 
125
 
Bazaarに自己紹介する
126
 
=====================
127
 
 
128
 
.. Bazaar installs a single new command, **bzr**.  Everything else is a
129
 
   subcommand of this.  You can get some help with ``bzr help``. Some arguments
130
 
   are grouped in topics: ``bzr help topics`` to see which topics are available.
131
 
 
132
 
Bazaarは **bzr** という新しいコマンドをひとつインストールします。
133
 
他の全ては bzr のサブコマンドになります。
134
 
``bzr help`` コマンドでいくつかのヘルプを見られます。
135
 
幾つかの話題は topic にまとめられていて、 ``bzr help topics`` で\
136
 
利用可能なトピックの一覧を見られます。
137
 
 
138
 
バージョン管理システムの一つの機能は、誰が何を変更したのかを追跡することです。
139
 
分散型バージョン管理システムでは、各開発者がグローバルユニークなIDを持つ\
140
 
必要があります。
141
 
ほとんどの人はこのIDとして利用できる eメールアドレス を持っています。
142
 
Bazaarはコンピュータのユーザー名とホスト名から自動でメールアドレスを\
143
 
生成します。Bazaarが自動で作成したメールアドレス以外のものを使いたい\
144
 
場合、3つの選択肢があります。
145
 
 
146
 
1. ``bzr whoami`` を使ってメールアドレスを設定します。これはグローバルなIDを設定\
147
 
   する最も簡単な方法です。グローバルなIDを設定するには::
148
 
 
149
 
      % bzr whoami "Your Name <email@example.com>"
150
 
 
151
 
   特定のブランチでべつのアドレスを使いたい場合、そのブランチのディレクトリの\
152
 
   なかで次のコマンドを実行します::
153
 
 
154
 
      % bzr whoami --branch "Your Name <email@example.com>"
155
 
 
156
 
#. ``?/.bazaar/bazaar.conf`` [1]_ の中のメールアドレスを、以下のようにして\
157
 
   設定します。 ``[DEFAULT]`` の部分が大文字と小文字を区別するので注意して\
158
 
   ください::
159
 
 
160
 
       [DEFAULT]
161
 
       email=Your Name <email@isp.com>
162
 
 
163
 
   特定のブランチにおける設定は、 ``?/.bazaar/locations.conf``
164
 
   にブランチのセクションを作成して次のように書くことができます。 ::
165
 
 
166
 
       [/the/path/to/the/branch]
167
 
       email=Your Name <email@isp.com>
168
 
 
169
 
 
170
 
#. 環境変数 ``$BZR_EMAIL`` もしくは ``$EMAIL`` (``$BZR_EMAIL`` の方が優先\
171
 
   されます)にメールアドレスを設定することで、上の二つの方法で設定された\
172
 
   オプションを上書きすることができます。
173
 
 
174
 
.. [1] Windowsではユーザー設定ファイルはアプリケーションデータディレクトリに\
175
 
   おかれます。なので、設定ファイルの場所は ``?/.bazaar/branch.conf`` ではなく\
176
 
   ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``
177
 
   になります。
178
 
   同じことが ``locations.conf``, ``ignore``, ``plugins`` ディレクトリも\
179
 
   同じです。
180
 
 
181
 
ブランチを作る
182
 
==============
183
 
 
184
 
履歴はデフォルトではブランチの .bzr ディレクトリの中に保存されます。
185
 
 
186
 
.. これは現行のバージョンでできるのでは?: In a
187
 
   future version of Bazaar, there will be a facility to store it in a
188
 
   separate repository, which may be remote.
189
 
 
190
 
既存のディレクトリの中で ``bzr init`` をすると新しいブランチを作成できます::
191
 
 
192
 
    % mkdir tutorial
193
 
    % cd tutorial
194
 
    % ls -a
195
 
    ./  ../
196
 
    % pwd
197
 
    /home/mbp/work/bzr.test/tutorial
198
 
    %
199
 
    % bzr init
200
 
    % ls -aF
201
 
    ./  ../  .bzr/
202
 
    %
203
 
 
204
 
ファイルには3つのクラス、 unknown, ignored, versioned があります。
205
 
**add** コマンドはファイルを versioned にし、そのファイルへの変更の記録を\
206
 
開始します::
207
 
 
208
 
    % echo 'hello world' > hello.txt
209
 
    % bzr status
210
 
    unknown:
211
 
      hello.txt
212
 
    % bzr add hello.txt
213
 
    added hello.txt
214
 
    % bzr status
215
 
    added:
216
 
      hello.txt
217
 
 
218
 
もし間違えたファイルを add してしまった場合、そのファイルを unversioned
219
 
状態に戻すために ``bzr remove`` してください。
220
 
この場合の ``bzr remove`` は、ほかの場合 [2]_ とちがってファイルを削除\
221
 
しません。
222
 
 
223
 
.. [2] ``bzr remove`` はファイルがバージョン管理されていて何も変更されて\
224
 
   いない場合に、そのファイルを削除します。 ``--keep`` オプションで常に\
225
 
   ファイルを残すことができます。 ``--force`` オプションで常にファイルを\
226
 
   削除することもできます。
227
 
 
228
 
.. Branch locations
229
 
 
230
 
ブランチの場所
231
 
===============
232
 
 
233
 
すべての履歴はブランチに格納されます。ブランチとは、管理用のファイルを\
234
 
含んだただのディレクトリです。デフォルトでは、svnやsvkのような、分離した\
235
 
リポジトリやデータベースはありません。分離したリポジトリを作成することも\
236
 
できます(``bzr init-repo`` コマンドを参照してください)。大規模なブランチを\
237
 
利用する場合や、中規模のブランチをたくさん利用する場合にはリポジトリを\
238
 
分離するといいでしょう。
239
 
 
240
 
自分のコンピュータのファイルシステム上にあるブランチを参照するときは\
241
 
ブランチを格納しているディレクトリ名で指定できます。 bzr は SSH, HTTP
242
 
SFTP などを経由してブランチにアクセスすることもできます。例::
243
 
 
244
 
    % bzr log bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
245
 
    % bzr log http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
246
 
    % bzr log sftp://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/
247
 
 
248
 
プラグインをインストールすれば、 rsync プロトコルを使ってブランチにアクセス\
249
 
することもできます。
250
 
 
251
 
ブランチを指定した場所に置く方法については、 `ブランチを公開する`_ 節を\
252
 
ご覧ください。
253
 
 
254
 
.. Reviewing changes
255
 
 
256
 
変更をレビューする
257
 
===================
258
 
 
259
 
一仕事終えたら、それを履歴に **コミット (commit)** しましょう。
260
 
新しい機能を追加したり、バグを直したり、コードやドキュメントを更新したら\
261
 
いつでもコミットするのは良いことです。
262
 
すべてのリビジョンが良い状態であるようにするために、コミットする前にコードを\
263
 
コンパイルしたりテストスイートを実行するのも良い習慣です。
264
 
コミットする前にコミットしようとしているものを確認するためにレビューすることが\
265
 
できます。
266
 
 
267
 
この目的で便利な二つのコマンドがあります。 **status** と **diff** です。
268
 
 
269
 
bzr status
270
 
----------
271
 
 
272
 
**status** コマンドは、今の作業ツリーが最後のリビジョンからどのように\
273
 
変更されたのかを教えてくれます::
274
 
 
275
 
    % bzr status
276
 
    modified:
277
 
       foo
278
 
 
279
 
``bzr status`` は変更が無かったり無視されているファイルを隠します。
280
 
status コマンドはオプションとして、確認対象となる複数のファイル名やディレクトリ名を\
281
 
渡すことができます。
282
 
 
283
 
bzr diff
284
 
--------
285
 
 
286
 
**diff** コマンドは通常の unified diff フォーマットですべてのファイルの\
287
 
テキストの変更を表示します。
288
 
このコマンドの出力を pipe 経由で、''patch'', ''diffstat'', ''fileterdiff'',
289
 
''colordiff'' といったコマンドに渡すことができます。 ::
290
 
 
291
 
    % bzr diff
292
 
    === added file 'hello.txt'
293
 
    --- hello.txt   1970-01-01 00:00:00 +0000
294
 
    +++ hello.txt   2005-10-18 14:23:29 +0000
295
 
    @@ -0,0 +1,1 @@
296
 
    +hello world
297
 
 
298
 
 
299
 
``-r`` オプションをつけると、作業ツリーを古いリビジョンと比較したり、\
300
 
二つのリビジョン間の差分を見ることができます。 ::
301
 
 
302
 
    % bzr diff -r 1000..          # everything since r1000
303
 
    % bzr diff -r 1000..1100      # changes from 1000 to 1100
304
 
 
305
 
``--diff-options`` オプションをつけると、 bzr は外部の diff プログラムに\
306
 
オプションをつけて起動します。 例::
307
 
 
308
 
    % bzr diff --diff-options --side-by-side foo
309
 
 
310
 
プロジェクトによっては二つのファイルに接頭辞がついた patch が好まれます。
311
 
``--prefix`` オプションでそのような接頭辞をつけることができます。
312
 
ショートカットとして、 ``bzr diff -p1`` は ``patch -p1`` コマンドが受け付ける\
313
 
形で差分を出力します。
314
 
 
315
 
 
316
 
.. Committing changes
317
 
 
318
 
変更をコミットする
319
 
==================
320
 
 
321
 
作業ツリーの状態に満足したら、ブランチに **コミット (commit)** しましょう。
322
 
コミットとは作業ツリーの状態のスナップショットを保持するリビジョンを新しく作ることです。
323
 
 
324
 
bzr commit
325
 
----------
326
 
 
327
 
.. The **commit** command takes a message describing the changes in the
328
 
.. revision.  It also records your userid, the current time and timezone, and
329
 
.. the inventory and contents of the tree.  The commit message is specified
330
 
.. by the ``-m`` or ``--message`` option. You can enter a multi-line commit
331
 
.. message; in most shells you can enter this just by leaving the quotes open
332
 
.. at the end of the line.
333
 
 
334
 
**commit** コマンドはそのリビジョンの変更を説明するメッセージを受け取ります。
335
 
また、あなたのユーザーID、今の時間とタイムゾーン、ツリーの内容をあわせて記録します。
336
 
コミットメッセージは ``-m`` もしくは ``--message`` オプションで指定できます。
337
 
複数行のコメントも利用できます。多くのシェルはクォートを開いたままで改行する\
338
 
ことで複数行の入力が可能です。
339
 
 
340
 
::
341
 
 
342
 
    % bzr commit -m "added my first file"
343
 
 
344
 
.. You can also use the ``-F`` option to take the message from a file.  Some
345
 
.. people like to make notes for a commit message while they work, then
346
 
.. review the diff to make sure they did what they said they did.  (This file
347
 
.. can also be useful when you pick up your work after a break.)
348
 
 
349
 
メッセージをファイルで渡すには ``-F`` オプションを使います。
350
 
コミットメッセージを先に作成し、それとdiffを合わせてレビューすることで、
351
 
コミットメッセージとコミット内容が一致していることを確認する人もいます。
352
 
(このファイルは休憩から戻ってきて作業を思い出すときにも役に立つでしょう)
353
 
 
354
 
.. Message from an editor
355
 
 
356
 
エディタからメッセージを入力する
357
 
----------------------------------
358
 
 
359
 
.. If you use neither the ``-m`` nor the ``-F`` option then bzr will open an
360
 
.. editor for you to enter a message.  The editor to run is controlled by
361
 
.. your ``$VISUAL`` or ``$EDITOR`` environment variable, which can be overridden
362
 
.. by the ``editor`` setting in ``?/.bazaar/bazaar.conf``; ``$BZR_EDITOR`` will
363
 
.. override either of the above mentioned editor options.  If you quit the
364
 
.. editor without making any changes, the commit will be cancelled.
365
 
 
366
 
``-m`` オプションも ``-F`` オプションも指定しなかった場合、 bzr はメッセージを\
367
 
入力するためにエディタを立ち上げます。
368
 
このエディタは ``$VISUAL`` か ``$EDITOR`` 環境変数で制御することができます。
369
 
この環境変数を `` /.bazaar/bazaar.conf`` 内の ``editor`` を設定して上書き\
370
 
することができ、さらに ``$BZR_EDITOR`` 環境変数がそれらすべてを上書きします。
371
 
もし何も変更せずにエディタを閉じたなら、コミットはキャンセルされます。
372
 
 
373
 
.. The file that is opened in the editor contains a horizontal line. The part
374
 
.. of the file below this line is included for information only, and will not
375
 
.. form part of the commit message. Below the separator is shown the list of
376
 
.. files that are changed in the commit. You should write your message above
377
 
.. the line, and then save the file and exit.
378
 
 
379
 
エディタで開かれるファイルには水平線が含まれています。この線より下の部分は\
380
 
参考用であり、コミットメッセージには含まれません。
381
 
水平線の下にはコミットで変更されるファイルのリストが表示されます。
382
 
メッセージは水平線の上に書く必要があります。そうしたら、ファイルを保存して\
383
 
エディタを終了してください。
384
 
 
385
 
.. If you would like to see the diff that will be committed as you edit the
386
 
.. message you can use the ``--show-diff`` option to ``commit``. This will include
387
 
.. the diff in the editor when it is opened, below the separator and the
388
 
.. information about the files that will be committed. This means that you can
389
 
.. read it as you write the message, but the diff itself wont be seen in the
390
 
.. commit message when you have finished. If you would like parts to be
391
 
.. included in the message you can copy and paste them above the separator.
392
 
 
393
 
``commit`` コマンドに ``--show-diff`` オプションをつけると、コミットされる\
394
 
変更の diff を見ることができます。この diff はエディタが開いたときに水平線\
395
 
やコミットされるファイルの情報よりも下に含まれます。
396
 
なので、コミットメッセージを書くときに diff を見ることができますが、\
397
 
コミットメッセージ自体には diff が含まれません。
398
 
コミットメッセージに diff を含めたい場合は、水平線より上にコピーペースト\
399
 
してください。
400
 
 
401
 
 
402
 
.. Marking bugs as fixed
403
 
 
404
 
解決したバグの記録をつける
405
 
----------------------------
406
 
 
407
 
プロジェクトにおいて多くの変更はバグの修正のために行われます。
408
 
Bazaar は、コミットするときに解決したバグについてメタデータに記録することが
409
 
できます。
410
 
これを行うには、 ``--fixes`` オプションを使います。
411
 
このオプションは次のような形の引数を取ります。
412
 
 
413
 
    % bzr commit --fixes <tracker>:<id>
414
 
 
415
 
``<tracker>`` の部分にはバグ管理システムを指定するIDを書き、
416
 
``<id>`` の部分にはそのバグ管理システム上で管理されているバグの
417
 
IDを書きます。 ``<id>`` はたいてい数値になるでしょう。
418
 
Bazaar は最初からいくつかの有名なバグ管理システムを知っています。
419
 
bugs.launchpad.net, bugs.debian.org bugzilla.gnome.org です。
420
 
これらは、それぞれ独自のIDとして lp, deb, gnome を持っています。
421
 
例えば、 bugs.launchpad.net 上のバグ #1234 を解決する場合は、
422
 
その解決をコミットするときに次のようなコマンドを利用できます。 ::
423
 
 
424
 
    % bzr commit -m "fixed my first bug" --fixes lp:1234
425
 
 
426
 
For more information on this topic or for information on how to configure
427
 
other bug trackers please read `Bug Tracker Settings`_.
428
 
 
429
 
このトピックに着いてのさらなる情報や、他のバグ管理システムを設定する方法
430
 
については、 `Bug Tracker Settings`_ を参照してください。
431
 
 
432
 
.. _Bug Tracker Settings: ../user-reference/index.html#bug-tracker-settings
433
 
 
434
 
.. Selective commit
435
 
 
436
 
選択コミット
437
 
----------------
438
 
 
439
 
.. If you give file or directory names on the commit command line then only
440
 
.. the changes to those files will be committed.  For example::
441
 
 
442
 
commit コマンドにファイル名やディレクトリ名を渡したとき、それらのファイルの\
443
 
変更だけがコミットされます。 例 ::
444
 
 
445
 
    % bzr commit -m "documentation fix" commit.py
446
 
 
447
 
.. By default bzr always commits all changes to the tree, even if run from a
448
 
.. subdirectory.  To commit from only the current directory down, use::
449
 
 
450
 
デフォルトでは bzr は、サブディレクトリから実行される場合でもすべての変更を\
451
 
コミットします。
452
 
カレントディレクトリ以下だけをコミットする場合は、次のようにします ::
453
 
 
454
 
    % bzr commit .
455
 
 
456
 
 
457
 
.. Removing uncommitted changes
458
 
 
459
 
コミットされていない変更を削除する
460
 
===================================
461
 
 
462
 
.. If you've made some changes and don't want to keep them, use the
463
 
.. **revert** command to go back to the previous head version.  It's a good
464
 
.. idea to use ``bzr diff`` first to see what will be removed. By default the
465
 
.. revert command reverts the whole tree; if file or directory names are
466
 
.. given then only those ones will be affected. ``bzr revert`` also clears the
467
 
.. list of pending merges revisions.
468
 
 
469
 
不要な変更がある場合、 **revert** コマンドで最後のリビジョンの状態に戻る\
470
 
ことができます。
471
 
revert するまえに ``bzr diff`` で何が削除されるのかを確認しておくと良いでしょう。
472
 
デフォルトでは revert コマンドはツリー全体を revert します。ファイル名や\
473
 
ディレクトリ名が指定されている場合は、そのファイルだけが revert されます。
474
 
``bzr revert`` はマージ待ちリビジョンのリストも削除します。
475
 
 
476
 
 
477
 
.. Ignoring files
478
 
 
479
 
ファイルを無視する
480
 
===================
481
 
 
482
 
.. The .bzrignore file
483
 
 
484
 
.bzrignore ファイル
485
 
-------------------
486
 
 
487
 
.. Many source trees contain some files that do not need to be versioned,
488
 
.. such as editor backups, object or bytecode files, and built programs.  You
489
 
.. can simply not add them, but then they'll always crop up as unknown files.
490
 
.. You can also tell bzr to ignore these files by adding them to a file
491
 
.. called ``.bzrignore`` at the top of the tree.
492
 
 
493
 
多くのソースツリーはバージョン管理する必要のないファイルをたくさん含んでいます。
494
 
たとえば、エディタのバックアップファイルや、オブジェクトファイル、バイトコード、
495
 
ビルドされたプログラムなどです。
496
 
こういったファイルを単に add しないこともできますが、そうすると毎回 unknown file
497
 
としてたびたび出現することになります。
498
 
ツリートップにある ``.bzrignore`` とよばれるファイルにそれらのファイルを追加する\
499
 
ことで、bzrにそれらのファイルを無視させることができます。
500
 
 
501
 
.. This file contains a list of file wildcards (or "globs"), one per line.
502
 
.. Typical contents are like this::
503
 
 
504
 
このファイルは行ごとにワイルドカード (もしくは"glob") のリストを含みます。
505
 
典型的な内容の例です::
506
 
 
507
 
    *.o
508
 
    *?
509
 
    *.tmp
510
 
    *.py[co]
511
 
 
512
 
.. If a glob contains a slash, it is matched against the whole path from the
513
 
.. top of the tree; otherwise it is matched against only the filename.  So
514
 
.. the previous example ignores files with extension ``.o`` in all
515
 
.. subdirectories, but this example ignores only ``config.h`` at the top level
516
 
.. and HTML files in ``doc/``::
517
 
 
518
 
glob がスラッシュを含む場合、ツリーのトップからのパス全体にマッチします。
519
 
そうでない場合は、単にファイル名にマッチします。
520
 
なので、上の例はすべてのサブディレクトリの ``.o`` 拡張子を持つファイルを無視\
521
 
しますが、次の例ではツリーのトップにある ``config.h`` ファイルと、 ``doc/``
522
 
ディレクトリ以下のHTMLファイルだけを無視します::
523
 
 
524
 
    ./config.h
525
 
    doc/*.html
526
 
 
527
 
.. To get a list of which files are ignored and what pattern they matched,
528
 
.. use ``bzr ignored``::
529
 
 
530
 
どのファイルがどのパターンにマッチして無視されているのかを、 ``bzr ignored``
531
 
コマンドで表示することができます::
532
 
 
533
 
    % bzr ignored
534
 
    config.h                 ./config.h
535
 
    configure.in?            *?
536
 
 
537
 
.. It is OK to have either an ignore pattern match a versioned file, or to
538
 
.. add an ignored file.  Ignore patterns have no effect on versioned files;
539
 
.. they only determine whether unversioned files are reported as unknown or
540
 
.. ignored.
541
 
 
542
 
バージョン管理されているファイルが無視パターンにマッチしたり無視リストに\
543
 
入っていても大丈夫です。無視パターンはバージョン管理されたファイルには\
544
 
影響しません。バージョン管理されていないファイルを 'unknown' として扱うか\
545
 
'ignored' として扱うかを決めるためだけに使われます。
546
 
 
547
 
 
548
 
.. The ``.bzrignore`` file should normally be versioned, so that new copies
549
 
.. of the branch see the same patterns::
550
 
 
551
 
``.bzrignore`` ファイルは普通はバージョン管理されます。なのでそのブランチの\
552
 
コピーでも同じパターンが無視されます。 ::
553
 
 
554
 
    % bzr add .bzrignore
555
 
    % bzr commit -m "Add ignore patterns"
556
 
 
557
 
 
558
 
bzr ignore
559
 
----------
560
 
 
561
 
``.bzrignore`` ファイルを直接編集する代わりに、 ``bzr ignore`` コマンドを
562
 
利用することができます。 ``bzr ignore`` コマンドはファイル名かパターンを
563
 
引数に受け取って、それを ``.bzrignore`` ファイルに追加します。
564
 
``.bzrignore`` ファイルが存在しない場合、 ``bzr ignore`` コマンドは
565
 
自動的にそのファイルを作成してバージョン管理に追加します。 ::
566
 
 
567
 
    % bzr ignore tags
568
 
    % bzr status
569
 
    added:
570
 
      .bzrignore
571
 
 
572
 
 
573
 
``.bzrignore`` ファイルを自分で修正したときと同じく、コマンドを実行したあとに
574
 
``.bzrignore`` ファイルをコミットしなければなりません。 ::
575
 
 
576
 
    % bzr commit -m "Added tags to ignore file"
577
 
 
578
 
 
579
 
.. Global ignores
580
 
 
581
 
グローバルの無視設定
582
 
---------------------
583
 
 
584
 
.. There are some ignored files which are not project specific, but more user
585
 
.. specific. Things like editor temporary files, or personal temporary files.
586
 
.. Rather than add these ignores to every project, bzr supports a global
587
 
.. ignore file in ``?/.bazaar/ignore`` [1]_. It has the same syntax as the
588
 
.. per-project ignore file.
589
 
 
590
 
エディタの一時ファイルや個人の一時ファイルなど、\
591
 
幾つかの無視ファイルはプロジェクト依存ではなくてユーザー依存です。
592
 
こういったファイルを全プロジェクトで無視設定するかわりに、グローバルの\
593
 
無視設定ファイル ``~/.bazaar/ignore`` を利用できます。
594
 
これはプロジェクトの ignore ファイルと同じ文法で記述します。
595
 
 
596
 
 
597
 
.. Examining history
598
 
 
599
 
履歴を閲覧する
600
 
===============
601
 
 
602
 
bzr log
603
 
-------
604
 
 
605
 
.. The ``bzr log`` command shows a list of previous revisions. The ``bzr log
606
 
.. --forward`` command does the same in chronological order to get most
607
 
.. recent revisions printed at last.
608
 
 
609
 
``bzr log`` コマンドは過去のリビジョンのリストを表示します。
610
 
``bzr log --forward`` コマンドは同じ内容を、時系列順で最新のものが最後に\
611
 
くるように出力します。
612
 
 
613
 
.. As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
614
 
 
615
 
``bzr diff`` と同じように、 ``bzr log`` も ``-r`` 引数をサポートします::
616
 
 
617
 
    % bzr log -r 1000..          # リビジョン r1000 とそれ以降すべて
618
 
    % bzr log -r ..1000          # r1000 とそれ以前のすべて
619
 
    % bzr log -r 1000..1100      # r1000 から r1100 まで
620
 
    % bzr log -r 1000            # リビジョン r1000 だけ
621
 
 
622
 
..    % bzr log -r 1000..          # Revision 1000 and everything after it
623
 
..    % bzr log -r ..1000          # Everything up to and including r1000
624
 
..    % bzr log -r 1000..1100      # changes from 1000 to 1100
625
 
..    % bzr log -r 1000            # The changes in only revision 1000
626
 
 
627
 
 
628
 
.. Branch statistics
629
 
 
630
 
ブランチの情報
631
 
=================
632
 
 
633
 
.. The ``bzr info`` command shows some summary information about the working
634
 
.. tree and the branch history.
635
 
 
636
 
``bzr info`` コマンドは作業ツリーとブランチの履歴に関する情報の要約を表示します。
637
 
 
638
 
 
639
 
.. Versioning directories
640
 
 
641
 
ディレクトリをバージョン管理する
642
 
================================
643
 
 
644
 
.. bzr versions files and directories in a way that can keep track of renames
645
 
.. and intelligently merge them::
646
 
 
647
 
bzr はファイルとディレクトリを、名前の変更を追跡して賢くマージできるように\
648
 
バージョン管理します::
649
 
 
650
 
    % mkdir src
651
 
    % echo 'int main() {}' > src/simple.c
652
 
    % bzr add src
653
 
    added src
654
 
    added src/simple.c
655
 
    % bzr status
656
 
    added:
657
 
      src/
658
 
      src/simple.c
659
 
 
660
 
 
661
 
.. Deleting and removing files
662
 
 
663
 
ファイルを削除する
664
 
===================
665
 
 
666
 
.. You can delete files or directories by just deleting them from the working
667
 
.. directory.  This is a bit different to CVS, which requires that you also
668
 
.. do ``cvs remove``.
669
 
 
670
 
ファイルを削除するのは、単純に作業ツリーからファイルを削除するだけでできます。
671
 
これは、 ``cvs remove`` が必要な CVS とは少し異なります。
672
 
 
673
 
.. ``bzr remove`` makes the file un-versioned, but may or may not delete the
674
 
.. working copy [2]_.  This is useful when you add the wrong file, or decide that
675
 
.. a file should actually not be versioned.
676
 
 
677
 
``bzr remove`` はファイルをバージョン管理対象からはずしますが、作業ツリーから\
678
 
削除することも削除しないこともできます。 [2]_
679
 
これは間違ったファイルを追加してしまったり、あるファイルをバージョン管理するのを\
680
 
やめる場合に便利です。
681
 
 
682
 
::
683
 
 
684
 
    % rm -r src
685
 
    % bzr remove -v hello.txt
686
 
    ?       hello.txt
687
 
    % bzr status
688
 
    removed:
689
 
      hello.txt
690
 
      src/
691
 
      src/simple.c
692
 
    unknown:
693
 
      hello.txt
694
 
 
695
 
.. If you remove the wrong file by accident, you can use ``bzr revert`` to
696
 
.. restore it.
697
 
 
698
 
もし間違ってファイルを削除してしまった場合、 ``bzr revert`` でリストアできます。
699
 
 
700
 
 
701
 
.. Branching
702
 
 
703
 
ブランチを作る
704
 
==============
705
 
 
706
 
.. Often rather than starting your own project, you will want to submit a
707
 
.. change to an existing project.  To do this, you'll need to get a copy of
708
 
.. the existing branch.  Because this new copy is potentially a new branch,
709
 
.. the command is called **branch**::
710
 
 
711
 
自分でプロジェクトを始めるのではなく、既存のプロジェクトに変更を加えたい場合があります。
712
 
この場合、既存のブランチのコピーを取得する必要があります。
713
 
このコピーは新しいブランチになるので、このコマンドは **branch** という名前になっています::
714
 
 
715
 
    % bzr branch lp:bzr bzr.dev
716
 
    % cd bzr.dev
717
 
 
718
 
.. This copies down the complete history of this branch, so we can do all
719
 
.. operations on it locally: log, annotate, making and merging branches.
720
 
.. There will be an option to get only part of the history if you wish.
721
 
 
722
 
.. XXX: There will be の訳これでいい?
723
 
 
724
 
これでブランチの完全な履歴をコピーできたので、すべての操作 (log, annotate,
725
 
branch の作成とマージなど) をローカルで実行できます。
726
 
履歴の一部だけを取得するオプションも追加される予定です。
727
 
 
728
 
.. You can also get a copy of an existing branch by copying its directory,
729
 
.. expanding a tarball, or by a remote copy using something like rsync.
730
 
 
731
 
既存のブランチをコピーするには、普通にディレクトリをコピーしたり、tarballを\
732
 
展開したり、リモートから rsync のような方法でコピーすることもできます。
733
 
 
734
 
.. Following upstream changes
735
 
 
736
 
上流の変更を追いかける
737
 
==========================
738
 
 
739
 
.. You can stay up-to-date with the parent branch by "pulling" in their
740
 
   changes::
741
 
 
742
 
変更を "pull" することで手元のブランチを上流のブランチに対して最新に保つことが\
743
 
できます。
744
 
 
745
 
    % bzr pull
746
 
 
747
 
.. After this change, the local directory will be a mirror of the source. This
748
 
.. includes the ''revision-history'' - which is a list of the commits done in
749
 
.. this branch, rather than merged from other branches.
750
 
 
751
 
.. XXX This includes~がわからない.
752
 
 
753
 
このコマンドを実行した後、ローカルディレクトリはpull元のミラーになります。
754
 
ミラーするものには、 ''revision-history'' を含みます。つまり、別のブランチから\
755
 
マージするのではなくて、このブランチに対してコミットした履歴になります。
756
 
 
757
 
.. This command only works if your local (destination) branch is either an
758
 
.. older copy of the parent branch with no new commits of its own, or if the
759
 
.. most recent commit in your local branch has been merged into the parent
760
 
.. branch.
761
 
 
762
 
このコマンドはローカルの(pull先)ブランチが親ブランチの古いコピーで独自の\
763
 
あたらしいリビジョンを一切含まないか、ローカルブランチへの最新のコミットが\
764
 
親ブランチにマージされているときにのみ成功します。
765
 
 
766
 
.. Merging from related branches
767
 
 
768
 
関連ブランチからマージする
769
 
=============================
770
 
 
771
 
.. If two branches have diverged (both have unique changes) then ``bzr
772
 
.. merge`` is the appropriate command to use. Merge will automatically
773
 
.. calculate the changes that exist in the branch you're merging from that
774
 
.. are not in your branch and attempt to apply them in your branch.
775
 
 
776
 
二つのブランチが分岐している(互いに異なる変更を持っている)とき、
777
 
``bzr merge`` コマンドの出番です。
778
 
merge はマージ元ブランチにあって手元のブランチにない変更を自動で探して、\
779
 
その変更を手元に適用しようと試みます。
780
 
 
781
 
::
782
 
 
783
 
  % bzr merge URL
784
 
 
785
 
 
786
 
.. If there is a conflict during a merge, 3 files with the same basename
787
 
.. are created. The filename of the common base is appended with ".BASE",
788
 
.. the filename of the file containing your changes is appended with
789
 
.. ".THIS" and the filename with the changes from the other tree is
790
 
.. appended with ".OTHER".  Using a program such as kdiff3, you can now
791
 
.. comfortably merge them into one file.  In order to commit you have to
792
 
.. rename the merged file (".THIS") to the original file name.  To
793
 
.. complete the conflict resolution you must use the resolve command,
794
 
.. which will remove the ".OTHER" and ".BASE" files.  As long as there
795
 
.. exist files with .BASE, .THIS or .OTHER the commit command will
796
 
.. report an error.
797
 
 
798
 
マージ中に衝突(conflict)が発生した場合、同じ基本名(basename)をもつ\
799
 
3つのファイルが作成されます。
800
 
共通の祖先になるファイルのファイル名には ".BASE" が、
801
 
手元のブランチの変更を含むファイル名には ".THIS" が、
802
 
マージ元の変更を含むファイル名には ".OTHER" が末尾に追加されます。
803
 
kdiff3 のようなプログラムを利用してこれらのファイルをひとつに\
804
 
マージすることができます。
805
 
コミットするには、マージされた ".THIS" ファイルを元のファイル名に\
806
 
リネームします。
807
 
衝突の解決を完了するには、 resolve コマンドを使います。
808
 
このコマンドは ".OTHER" と ".BASE" ファイルを削除します。
809
 
.BASE, .THIS, .OTHER ファイルが残っている場合、 commit コマンドは\
810
 
エラーを報告します。
811
 
 
812
 
::
813
 
 
814
 
  % kdiff3 file.BASE file.OTHER file.THIS
815
 
  % mv file.THIS file
816
 
  % bzr resolve file
817
 
 
818
 
[**TODO**: explain conflict markers within files]
819
 
 
820
 
 
821
 
ブランチを公開する
822
 
======================
823
 
 
824
 
.. You don't need a special server to publish a bzr branch, just a normal web
825
 
.. server.  Just mirror the files to your server, including the .bzr
826
 
.. directory.  One can push a branch (or the changes for a branch) by one of
827
 
.. the following three methods:
828
 
 
829
 
bzrのブランチを公開するには特別なサーバーは必要ありません、普通のWebサーバーが\
830
 
使えます。
831
 
.bzr ディレクトリを含めてファイルをサーバーにミラーしてください。
832
 
ブランチをpush(やブランチに対する操作)するのに以下の3つの方法があります。
833
 
 
834
 
.. * The best method is to use bzr itself to do it.
835
 
 
836
 
* 最良の方法は bzr 自体を使うことです。
837
 
 
838
 
  ::
839
 
 
840
 
    % bzr push bzr+ssh://servername.com/path/to/directory
841
 
 
842
 
..   (The destination directory must already exist unless the
843
 
..   ``--create-prefix`` option is used.)
844
 
 
845
 
  (push先ディレクトリがすでに存在するか、 ``--create-prefix`` オプションを\
846
 
  利用する必要があります。)
847
 
 
848
 
.. * Another option is the ``rspush`` plugin that comes with BzrTools, which
849
 
..   uses rsync to push the changes to the revision history and the working
850
 
..   tree.
851
 
 
852
 
* 別の選択肢は bzrtools に含まれる ``rspush`` プラグインを利用することです。
853
 
  これはリモートの履歴と作業ツリーに変更を push するのに rsync を利用します。
854
 
 
855
 
.. * You can also copy the files around manually, by sending a tarball, or using
856
 
..   rsync, or other related file transfer methods.  This is usually less safe
857
 
..   than using ``push``, but may be faster or easier in some situations.
858
 
 
859
 
* tarball を送ったり rsync を使ったりほかの転送方法を利用して、手動でファイルを\
860
 
  コピーすることもできます。
861
 
  これはたいてい ``push`` ほど安全ではありませんが、場合によって高速だったり、\
862
 
  簡単だったりするかもしれません。
863
 
 
864
 
 
865
 
.. Moving changes between trees
866
 
 
867
 
変更をツリー間で移動する
868
 
============================
869
 
 
870
 
.. It happens to the best of us: sometimes you'll make changes in the wrong
871
 
.. tree.  Maybe because you've accidentally started work in the wrong directory,
872
 
.. maybe because as you're working, the change turns out to be bigger than you
873
 
.. expected, so you start a new branch for it.
874
 
 
875
 
どんな人にでもありえることですが、適切ではないツリー上で変更してしまうことがあります。
876
 
単純に作業するディレクトリを間違えたり、変更が予想よりも大きくなってしまったりして、
877
 
その変更のために新しいブランチを作りなおすことがあります。
878
 
 
879
 
.. To move your changes from one tree to another, use
880
 
 
881
 
変更をあるツリーから別のツリーに移動するには
882
 
 
883
 
::
884
 
 
885
 
  % cd NEWDIR
886
 
  % bzr merge --uncommitted OLDDIR
887
 
 
888
 
.. This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
889
 
.. It will not apply committed changes, even if they could be applied to NEWDIR
890
 
.. with a regular merge.  The changes will remain in OLDDIR, but you can use ``bzr
891
 
.. revert OLDDIR`` to remove them, once you're satisfied with NEWDIR.
892
 
 
893
 
これですべてのコミットされていないOLDDIR上の変更がNEWDIRに適用されます。
894
 
コミットされていない変更は、通常のmergeでNEWDIRに適用することができる場合でも適用されません。
895
 
OLDDIR上の変更はそのまま残りますが、NEWDIRの状態に満足したら ``bzr revert OLDDIR``
896
 
で削除することができます。
897
 
 
898
 
.. NEWDIR does not have to be a copy of OLDDIR, but they should be related.
899
 
.. The more different they are, the greater the chance of conflicts.
900
 
 
901
 
NEWDIRはOLDDIRのコピーである必要はありませんが、関連しているべきです。
902
 
両者の違いが大きければそれだけ衝突が起こる可能性が大きくなります。