← Back to branch summary

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

« back to all changes in this revision

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