Bazaar

Merge lp:~songofacandy/bzr/doc-ja into lp:bzr/2.0

  1. doc-ja
  2. Merge into 2.0
Proposed by methane
Status: Merged
Approved by: Ian Clatworthy
Approved revision: no longer in the source branch.
Merged at revision: not available
Proposed branch: lp:~songofacandy/bzr/doc-ja
Merge into: lp:bzr/2.0
Diff against target: 22912 lines
0 files modified
To merge this branch: bzr merge lp:~songofacandy/bzr/doc-ja
Reviewer Review Type Date Requested Status
Ian Clatworthy Approve
John A Meinel Approve
Review via email: mp+14182@code.launchpad.net
To post a comment you must log in.
Revision history for this message
methane (songofacandy) wrote :

Import Japanese documents.

Revision history for this message
John A Meinel (jameinel) wrote :

I don't have any way to review the actual Japanese content, but assuming that even a bad translation is better than no translation, everything looks reasonable.

This section was not translated at all:

Finding and browsing branches using Launchpad

Is there any specific reason?

review: Approve
Revision history for this message
Ian Clatworthy (ian-clatworthy) wrote :

I can't review the text but the other changes look ok. Thanks a heap for this. I'll merge.

review: Approve
Revision history for this message
Andrew Bennetts (spiv) wrote :

Sent to PQM.

Revision history for this message
Martin Pool (mbp) wrote :

2009/10/30 INADA Naoki <email address hidden>:
> INADA Naoki has proposed merging lp:~songofacandy/bzr/doc-ja into lp:bzr/2.0.
>
>    Requested reviews:
>    bzr-core (bzr-core)
>
>
> Import Japanese documents.The attached diff has been truncated due to its size.

I'm delighted to see these documents come in. Thanks!

This branch adds a doc/ja sphinx configuration, when there is not one
for the other languages, and it in turn tries to import whatever
bzrlib is on the path. This has temporarily stopped the
doc.bazaar-vcs.org copy of the docs building; it may also in some
cases mark the docs with the version of the installed copy of bzrlib,
not the one whose documentation you're building.

I'm just going to put in as trivial this change
<http://bazaar.launchpad.net/~mbp/bzr/trivial/revision/4801> to delete
that file, so that the automatic builds can resume. Ian suggested
this on irc and I think we decided during the earlier reviews these
weren't needed.

--
Martin <http://launchpad.net/~mbp/>

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== modified file 'Makefile'
2--- Makefile 2009-10-19 15:14:04 +0000
3+++ Makefile 2009-10-29 17:00:30 +0000
4@@ -116,6 +116,7 @@
5 clean-sphinx:
6 cd doc/en && make clean
7 cd doc/es && make clean
8+ cd doc/ja && make clean
9 cd doc/ru && make clean
10 cd doc/developers && make clean
11
12@@ -124,6 +125,8 @@
13 doc/en/user-reference/index.txt \
14 doc/es/Makefile \
15 doc/es/make.bat \
16+ doc/ja/Makefile \
17+ doc/ja/make.bat \
18 doc/ru/Makefile \
19 doc/ru/make.bat \
20 doc/developers/Makefile \
21@@ -146,6 +149,7 @@
22 cd doc/en && make html
23 cd doc/es && make html
24 cd doc/ru && make html
25+ cd doc/ja && make html
26 cd doc/developers && make html
27
28 # Build the PDF docs using Sphinx. This requires numerous LaTeX
29@@ -156,6 +160,7 @@
30 pdf-sphinx: $(SPHINX_DEPENDENCIES)
31 cd doc/en && make latex
32 cd doc/es && make latex
33+ cd doc/ja && make latex
34 cd doc/developers && make latex
35 cd doc/en/_build/latex && make all-pdf
36 cd doc/es/_build/latex && make all-pdf
37@@ -168,6 +173,7 @@
38 cd doc/en && make htmlhelp
39 cd doc/es && make htmlhelp
40 cd doc/ru && make htmlhelp
41+ cd doc/ja && make htmlhelp
42 cd doc/developers && make htmlhelp
43
44
45@@ -201,7 +207,10 @@
46 doc/en/tutorials/using_bazaar_with_launchpad.txt \
47 doc/en/tutorials/centralized_workflow.txt \
48 $(wildcard doc/es/tutorials/*.txt) \
49- $(wildcard doc/ru/tutorials/*.txt) \
50+ $(wildcard doc/ru/tutorials/*.txt) \
51+ doc/ja/tutorials/tutorial.txt \
52+ doc/ja/tutorials/using_bazaar_with_launchpad.txt \
53+ doc/ja/tutorials/centralized_workflow.txt \
54 $(wildcard doc/*/mini-tutorial/index.txt) \
55 $(wildcard doc/*/user-guide/index-plain.txt) \
56 $(wildcard doc/es/guia-usario/*.txt) \
57@@ -212,6 +221,7 @@
58 txt_nohtml = \
59 doc/en/user-guide/index.txt \
60 doc/es/user-guide/index.txt \
61+ doc/ja/user-guide/index.txt \
62 doc/ru/user-guide/index.txt
63 txt_files = $(filter-out $(txt_nohtml), $(txt_all))
64 htm_files = $(patsubst %.txt, %.html, $(txt_files))
65
66=== added file 'doc/index.ja.txt'
67--- doc/index.ja.txt 1970-01-01 00:00:00 +0000
68+++ doc/index.ja.txt 2009-10-29 17:00:30 +0000
69@@ -0,0 +1,85 @@
70+===========================
71+Bazaarのメインドキュメント
72+===========================
73+
74+これらのドキュメントの最新版はBazaarのドキュメントのサイト、 http://doc.bazaar-vcs.org/ から入手可能で、
75+詳しい情報は http://bazaar-vcs.org/Documentation のページからリンクされています。
76+
77+
78+コアドキュメント
79+================
80+
81+* `ユーザーガイド <ja/user-guide/index.html>`_
82+
83+* `ユーザーリファレンス <ja/user-reference/bzr_man.html>`_
84+
85+* `クィックスタートカード(PNG) <http://gigo-ice.org/scm/bazaar/wiki/bzr-quickref.ja.png>`_
86+ `(PDF) <http://gigo-ice.org/scm/bazaar/wiki/bzr-quickref.ja.pdf>`_
87+
88+* `リリースノート(英語) <en/release-notes/NEWS.html>`_
89+
90+* `2.0 Upgrade Guide (英語) <en/upgrade-guide/index.html>`_
91+
92+チュートリアル
93+===============
94+
95+* `5分でBazaar <ja/mini-tutorial/index.html>`_
96+
97+* `A longer tutorial (英語) <en/tutorials/tutorial.html>`_
98+
99+* `Using Bazaar with Launchpad (英語) <en/tutorials/using_bazaar_with_launchpad.html>`_
100+
101+* `Centralized workflow (英語) <en/tutorials/centralized_workflow.html>`_
102+
103+
104+Developer Documentation
105+=======================
106+
107+* `Developer Document Catalog <developers/index-plain.html>`_ |--| for developers
108+ of Bazaar and plugins
109+
110+
111+ウェブリンク
112+=============
113+
114+* `切り替えガイド <http://bazaar-vcs.org/BzrSwitching>`_
115+ |--| 別のVCSツールから移ってきたユーザー用
116+
117+* `移行ガイド <http://bazaar-vcs.org/BzrMigration>`_
118+ |--| 別のVCSツールから履歴を移行するチーム用
119+
120+* `用語 <http://bazaar-vcs.org/BzrGlossary>`_
121+
122+* `よく聞かれる質問 <http://bazaar-vcs.org/FAQ>`_
123+
124+
125+TortoiseBzrをインストールするには？
126+===================================
127+
128+https://launchpad.net/bzr/+download からbzr-setup-x.xxx.exeを入手し、
129+ファイルをダブルクリックをしてインストールウィザードを起動させます。
130+その後の作業はインストールウィザードに従います。
131+インストールウィザードが終了した後で再起動します。
132+
133+最新バージョンでも正常に動作しないことがあるので、
134+その場合は古いバージョンをインストールします。
135+2009年1月時点で筆者はbzr-setup-1.9.exeの基本的な動作を確認しています。
136+
137+もしPythonインタープリタにbzrをインストールした場合、インストールしたディレクトリによって
138+bzr.exe(デフォルトでは `C:\Program Files\Bazaar` )よりもbzr.bat(`C:\PythonXX\Scripts`)が
139+優先されるので、コマンドプロンプトでbzrと入力したときにbzr.exeが実行されるようにするには、
140+bzr.batをbzr.txtなどにリネームします。
141+
142+
143+Other Languages
144+===============
145+
146+* `Spanish Documentation <index.es.html>`_
147+* `Russian Documentation <index.ru.html>`_ |--| документация на русском
148+* `Japanese Documentation <index.ja.html>`_ |--| 日本語ドキュメント
149+
150+
151+.. |--| unicode:: U+2014
152+
153+..
154+ vim: ft=rst tw=74 ai
155
156=== modified file 'doc/index.txt'
157--- doc/index.txt 2009-09-10 02:09:26 +0000
158+++ doc/index.txt 2009-10-29 17:00:30 +0000
159@@ -9,9 +9,9 @@
160 Core Documentation
161 ==================
162
163-* `User Guide <en/user-guide/index-plain.html>`_
164+* `User Guide <en/user-guide/index-plain.html>`_
165
166-* `User Reference <en/user-reference/bzr_man.html>`_
167+* `User Reference <en/user-reference/bzr_man.html>`_
168
169 * `Quick Start Card <en/_static/en/bzr-en-quick-reference.svg>`_
170 (`PDF <en/_static/en/bzr-en-quick-reference.pdf>`_,
171@@ -19,19 +19,19 @@
172
173 * `Release Notes <en/release-notes/NEWS.html>`_
174
175-* `2.0 Upgrade Guide <en/upgrade-guide/index.html>`_
176+* `2.0 Upgrade Guide <en/upgrade-guide/index.html>`_
177
178
179 Tutorials
180 =========
181
182-* `Bazaar in five minutes <en/mini-tutorial/index.html>`_
183-
184-* `A longer tutorial <en/tutorials/tutorial.html>`_
185-
186-* `Using Bazaar with Launchpad <en/tutorials/using_bazaar_with_launchpad.html>`_
187-
188-* `Centralized workflow <en/tutorials/centralized_workflow.html>`_
189+* `Bazaar in five minutes <en/mini-tutorial/index.html>`_
190+
191+* `A longer tutorial <en/tutorials/tutorial.html>`_
192+
193+* `Using Bazaar with Launchpad <en/tutorials/using_bazaar_with_launchpad.html>`_
194+
195+* `Centralized workflow <en/tutorials/centralized_workflow.html>`_
196
197
198 Developer Documentation
199@@ -43,7 +43,7 @@
200 Web links
201 =========
202
203-* `Switching Guides <http://bazaar-vcs.org/BzrSwitching>`_
204+* `Switching Guides <http://bazaar-vcs.org/BzrSwitching>`_
205 |--| for users moving from another VCS tool
206
207 * `Migration Guide <http://bazaar-vcs.org/BzrMigration>`_
208@@ -59,6 +59,7 @@
209
210 * `Spanish Documentation <index.es.html>`_
211 * `Russian Documentation <index.ru.html>`_ |--| документация на русском
212+* `Japanese Documentation <index.ja.html>`_ |--| 日本語のドキュメント
213
214 .. |--| unicode:: U+2014
215
216
217=== added directory 'doc/ja'
218=== added directory 'doc/ja/_static'
219=== added file 'doc/ja/_static/bzr icon 16.png'
220Binary files doc/ja/_static/bzr icon 16.png 1970-01-01 00:00:00 +0000 and doc/ja/_static/bzr icon 16.png 2009-10-29 17:00:30 +0000 differ
221=== added file 'doc/ja/_static/bzr.ico'
222Binary files doc/ja/_static/bzr.ico 1970-01-01 00:00:00 +0000 and doc/ja/_static/bzr.ico 2009-10-29 17:00:30 +0000 differ
223=== added directory 'doc/ja/_templates'
224=== added file 'doc/ja/conf.py'
225--- doc/ja/conf.py 1970-01-01 00:00:00 +0000
226+++ doc/ja/conf.py 2009-10-29 17:00:30 +0000
227@@ -0,0 +1,91 @@
228+# -*- coding: utf-8 -*-
229+#
230+# Bazaar documentation build configuration file, created by
231+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
232+#
233+# This file is execfile()d with the current directory set to its containing dir.
234+
235+import sys, os
236+
237+# If extensions (or modules to document with autodoc) are in another directory,
238+# add these directories to sys.path here. If the directory is relative to the
239+# documentation root, use os.path.abspath to make it absolute, like shown here.
240+#sys.path = [os.path.abspath('../..')] + sys.path
241+sys.path = [os.path.abspath('.')] + sys.path
242+
243+# Most of the configuration for Bazaar docs is defined here ...
244+#from bzrlib.doc_generate.sphinx_conf import *
245+from sphinx_conf import *
246+
247+
248+## Configuration specific to this site ##
249+
250+# The locale code for this documentation set
251+bzr_locale = 'ja'
252+
253+# Translations & supporting helper function
254+bzr_titles = {
255+ u'Table of Contents (%s)': u'目次 (%s)',
256+ u'Bazaar User Guide': u'ユーザーガイド',
257+ u'Bazaar User Reference': u'ユーザーリファレンス',
258+ u'Bazaar Release Notes': u'リリースノート',
259+ u'Bazaar Upgrade Guide': u'アップグレードガイド',
260+ u'Bazaar in five minutes': u'5分でBazaar',
261+ u'Bazaar Tutorial': u'チュートリアル',
262+ u'Using Bazaar With Launchpad': None,
263+ u'Centralized Workflow Tutorial': None,
264+ }
265+def bzr_title(s):
266+ return bzr_titles.get(s) or s
267+
268+# The language for content autogenerated by Sphinx. Refer to documentation
269+# for a list of supported languages.
270+language = bzr_locale
271+
272+# A shorter title for the navigation bar. Default is the same as html_title.
273+html_short_title = bzr_title(u"Table of Contents (%s)") % (release,)
274+
275+# Additional templates that should be rendered to pages, maps page names to
276+# template names.
277+#html_additional_pages = {'index': 'index.html'}
278+
279+# Output file base name for HTML help builder.
280+htmlhelp_basename = 'bzr-%s' % (bzr_locale,)
281+
282+# Grouping the document tree into LaTeX files. List of tuples
283+# (source start file, target name, title, author, documentclass [howto/manual]).
284+latex_documents = [
285+ # Manuals
286+ ('user-guide/index', 'bzr-%s-user-guide.tex' % (bzr_locale,),
287+ bzr_title(u'Bazaar User Guide'), bzr_team, 'manual'),
288+ ('user-reference/bzr_man', 'bzr-%s-user-reference.tex' % (bzr_locale,),
289+ bzr_title(u'Bazaar User Reference'), bzr_team, 'manual'),
290+ #('release-notes/NEWS', 'bzr-%s-release-notes.tex' % (bzr_locale,),
291+ # bzr_title(u'Bazaar Release Notes'), bzr_team, 'manual'),
292+ #('upgrade-guide/index', 'bzr-%s-upgrade-guide.tex' % (bzr_locale,),
293+ # bzr_title(u'Bazaar Upgrade Guide'), bzr_team, 'manual'),
294+ # Tutorials
295+ ('mini-tutorial/index', 'bzr-%s-tutorial-mini.tex' % (bzr_locale,),
296+ bzr_title(u'Bazaar in five minutes'), bzr_team, 'howto'),
297+ #('tutorials/tutorial', 'bzr-%s-tutorial.tex' % (bzr_locale,),
298+ # bzr_title(u'Bazaar Tutorial'), bzr_team, 'howto'),
299+ #('tutorials/using_bazaar_with_launchpad',
300+ # 'bzr-%s-tutorial-with-launchpad.tex' % (bzr_locale,),
301+ # bzr_title(u'Using Bazaar With Launchpad'), bzr_team, 'howto'),
302+ #('tutorials/centralized_workflow',
303+ # 'bzr-%s-tutorial-centralized.tex' % (bzr_locale,),
304+ # bzr_title(u'Centralized Workflow Tutorial'), bzr_team, 'howto'),
305+]
306+
307+# List of documents that shouldn't be included in the build.
308+unused_docs = [
309+ # Subtopics that get included
310+ 'upgrade-guide/overview',
311+ 'upgrade-guide/data_migration',
312+ 'upgrade-guide/tips_and_tricks',
313+ #'user-guide/resolving_conflicts',
314+ #'user-guide/version_info',
315+ # Plain-style documentation generation stuff
316+ #'user-guide/index-plain',
317+]
318+
319
320=== added file 'doc/ja/index.txt'
321--- doc/ja/index.txt 1970-01-01 00:00:00 +0000
322+++ doc/ja/index.txt 2009-10-29 17:00:30 +0000
323@@ -0,0 +1,56 @@
324+===========================
325+Bazaarのメインドキュメント
326+===========================
327+
328+これらのドキュメントの最新版はBazaarのドキュメントのサイト、 http://doc.bazaar-vcs.org/ から入手可能で、
329+詳しい情報は http://bazaar-vcs.org/Documentation のページからリンクされています。
330+
331+
332+目次
333+=====
334+
335+.. toctree::
336+ :maxdepth: 1
337+
338+ tutorials/index
339+ user-guide/index
340+ user-reference/bzr_man
341+
342+
343+ウェブリンク
344+=============
345+
346+* `切り替えガイド <http://bazaar-vcs.org/BzrSwitching>`_
347+ |--| 別のVCSツールから移ってきたユーザー用
348+
349+* `移行ガイド <http://bazaar-vcs.org/BzrMigration>`_
350+ |--| 別のVCSツールから履歴を移行するチーム用
351+
352+* `用語 <http://bazaar-vcs.org/BzrGlossary>`_
353+
354+* `よく聞かれる質問 <http://bazaar-vcs.org/FAQ>`_
355+
356+
357+TortoiseBzrをインストールするには？
358+===================================
359+
360+https://launchpad.net/bzr/+download からbzr-setup-x.xxx.exeを入手し、
361+ファイルをダブルクリックをしてインストールウィザードを起動させます。
362+その後の作業はインストールウィザードに従います。
363+インストールウィザードが終了した後で再起動します。
364+
365+最新バージョンでも正常に動作しないことがあるので、
366+その場合は古いバージョンをインストールします。
367+2009年1月時点で筆者はbzr-setup-1.9.exeの基本的な動作を確認しています。
368+
369+もしPythonインタープリタにbzrをインストールした場合、インストールしたディレクトリによって
370+bzr.exe(デフォルトでは ``C:\Program Files\Bazaar`` )よりもbzr.bat(``C:\PythonXX\Scripts``)が
371+優先されるので、コマンドプロンプトでbzrと入力したときにbzr.exeが実行されるようにするには、
372+bzr.batをbzr.txtなどにリネームします。
373+
374+
375+
376+.. |--| unicode:: U+2014
377+
378+..
379+ vim: ft=rst tw=74 ai
380
381=== added directory 'doc/ja/mini-tutorial'
382=== added file 'doc/ja/mini-tutorial/index.txt'
383--- doc/ja/mini-tutorial/index.txt 1970-01-01 00:00:00 +0000
384+++ doc/ja/mini-tutorial/index.txt 2009-10-29 17:00:30 +0000
385@@ -0,0 +1,275 @@
386+=================
387+5分でわかるBazaar
388+=================
389+
390+.. _introduction:
391+
392+イントロダクション
393+===================
394+
395+Bazaarは分散型バージョン管理システムで、ソフトウェアプロジェクトの共同作業を楽にしてくれます。
396+
397+これから5分ほどで、ファイルをバージョン管理下に置き、変更をそれらに記録して、\
398+作業内容を確認し、公開して作業内容をマージしてもらうためにプロジェクトのtrunkに\
399+送る方法などを学びます。
400+
401+詳細な紹介内容を望むのであれば、 `さらに学ぶ`_ をご覧ください。
402+
403+
404+インストール方法
405+=================
406+
407+このガイドではBazaarをインストールする方法を説明しませんが、通常はとても簡単です。
408+インストール方法の手引きは次の通りです:
409+
410+- **GNU/Linux:** おそらくBazaarはあなたのGNU/Linuxディストリビューションに含まれています。
411+- **Windows:** `Windowsのためのインストールの手引き`_.
412+- **Mac OS X:** `Mac OS Xのためのインストールの手引き`_.
413+
414+別のプラットフォームとソースコードからインストールする方法に関しては、 ダウンロード_
415+と インストール方法_ のページを参照してください。
416+
417+.. _Windowsのためのインストールの手引き: http://bazaar-vcs.org/WindowsDownloads
418+.. _Mac OS Xのためのインストールの手引き: http://bazaar-vcs.org/MacOSXBundle
419+.. _ダウンロード: http://bazaar-vcs.org/Download
420+.. _インストール方法: http://bazaar-vcs.org/InstallationFaq
421+
422+
423+まずは自己紹介
424+=================
425+
426+作業にとりかかる前に、まずあなたが誰なのかをBazaarに教えてあげましょう。
427+そうすることで、履歴の中からあなたの作業を正確に識別することができます。
428+
429+次のように入力してください(もちろん、あなたの名前とEメールアドレスで)::
430+
431+ $ bzr whoami "John Doe <john.doe@gmail.com>"
432+
433+こうするとBazaarは、あなたの名前やEメールアドレスが入った設定ファイルを作成\
434+もしくは修正します。
435+
436+名前とEメールアドレスが正しく登録されているか確認しましょう ::
437+
438+ $ bzr whoami
439+ John Doe <john.doe@gmail.com>
440+
441+
442+ファイルをバージョン管理する
443+=============================
444+
445+Bazaarで扱うディレクトリといくつかのファイルを作りましょう::
446+
447+ $ mkdir myproject
448+ $ cd myproject
449+ $ mkdir subdirectory
450+ $ touch test1.txt test2.txt test3.txt subdirectory/test4.txt
451+
452+**Windowsユーザーのための注意:** Windows Explorerを使ってディレクトリを作成し、\
453+そのディレクトリの中で右クリックをして ``新規作成`` を選択し、ファイルを作成します。
454+
455+Bazaarにあなたのプロジェクトディレクトリを初期化させましょう::
456+
457+ $ bzr init
458+
459+何も起きていないように見えても心配しないでください。
460+Bazaarはファイルとリビジョンの履歴を保存する branch_ を作りました。
461+
462+.. _branch: http://bazaar-vcs.org/Branch
463+
464+次のステップはBazaarに管理して欲しいファイルを教えることです。
465+``bzr add`` を実行するとすべてのディレクトリとファイルがプロジェクトに\
466+再帰的に追加されます::
467+
468+ $ bzr add
469+ added subdirectory
470+ added test1.txt
471+ added test2.txt
472+ added test3.txt
473+ added subdirectory/test4.txt
474+
475+次に、これらをブランチにコミットしてスナップショットをとります。
476+コミットを行った理由を説明するメッセージを追加します::
477+
478+ $ bzr commit -m "Initial import"
479+
480+Bazaarは分散型バージョン管理システムなので、コミットするために\
481+サーバーに接続する必要はありません。
482+代わりに、Bazaarはブランチとすべてのコミットをあなたが作業している\
483+ディレクトリ内部に保存します;
484+``.bzr`` というサブディレクトリをご覧ください。
485+
486+
487+ファイルを変更する
488+===================
489+
490+ファイルを変更してブランチにその変更をコミットしてみましょう。
491+
492+好きなエディタで ``test1.txt`` を編集し、何を行ったのかを確認します::
493+
494+ $ bzr diff
495+ === modified file 'test1.txt'
496+ --- test1.txt 2007-10-08 17:56:14 +0000
497+ +++ test1.txt 2007-10-08 17:46:22 +0000
498+ @@ -0,0 +1,1 @@
499+ +test test test
500+
501+作業をBazaarのブランチにコミットします::
502+
503+ $ bzr commit -m "Added first line of text"
504+ Committed revision 2.
505+
506+
507+リビジョンのログを眺める
508+=========================
509+
510+ログを閲覧することでブランチの履歴がわかります::
511+
512+ $ bzr log
513+ ------------------------------------------------------------
514+ revno: 2
515+ committer: John Doe <john.doe@gmail.com>
516+ branch nick: myproject
517+ timestamp: Mon 2007-10-08 17:56:14 +0000
518+ message:
519+ Added first line of text
520+ ------------------------------------------------------------
521+ revno: 1
522+ committer: John Doe <john.doe@gmail.com>
523+ branch nick: myproject
524+ timestamp: Mon 2006-10-08 17:46:22 +0000
525+ message:
526+ Initial import
527+
528+
529+sftpでブランチを公開する
530+=========================
531+
532+ブランチを公開する方法は複数あります。
533+SFTPサーバーがすでにあるもしくは容易にセットアップできるのであれば、\
534+ブランチをそこで公開できます。
535+
536+そうでなければ、このセクションをとばして、Bazaarのための無料ホスティング\
537+サービスである、 Launchpad_ で公開しましょう。
538+
539+.. _Launchpad: https://launchpad.net/
540+
541+``www.example.com/myproject`` でブランチを公開することを前提とします::
542+
543+ $ bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject
544+ 2 revision(s) pushed.
545+
546+Bazaarはリモートサーバー上で ``myproject`` ディレクトリを作りブランチを\
547+そこにpushします。
548+
549+これで誰でも次のコマンドを入力すればあなたのブランチをコピーできます::
550+
551+ $ bzr branch http://www.example.com/myproject
552+
553+**注:** sftpを使うためには、 ``paramiko`` と ``pyCrypto`` をインストールする必要があります。
554+詳細は http://bazaar-vcs.org/InstallationFaq を参照してください。
555+
556+
557+Launchpadでブランチを公開する
558+==============================
559+
560+Launchpadはフリーソフトウェアのための開発とホスティングのためのツールが\
561+ひとまとめになったものです。これをブランチを公開するために利用できます。
562+
563+Launchpadのアカウントを持っていなければ、 `アカウントのサインアップのガイド`_
564+に従ってアカウントを作り、 `SSHキーを登録`_ してください。
565+
566+.. _アカウントのサインアップのガイド: https://help.launchpad.net/CreatingYourLaunchpadAccount
567+.. _SSHキーを登録: https://launchpad.net/people/+me/+editsshkeys
568+
569+次のコマンドを(``john.doe`` を自分のLaunchpadアカウント名に変更して)実行してください::
570+
571+ $ bzr push bzr+ssh://john.doe@bazaar.launchpad.net/~john.doe/+junk/myproject
572+
573+**注:** ``+junk`` はこのブランチがLaunchpad上の特定のプロジェクトに関連していないことを意味します。
574+
575+これで、誰でも次のコマンドを入力することでブランチのコピーを作ることができます::
576+
577+ $ bzr branch http://bazaar.launchpad.net/~john.doe/+junk/myproject
578+
579+ブランチとリビジョンの履歴に関する情報は https://code.launchpad.net/people/+me/+junk/myproject
580+でも見ることができます。
581+
582+別のブランチから自分用のコピーを作る
583+=====================================
584+
585+他人のコードに取り組むために、ブランチのコピーを作ることができます。
586+実際の世界の例として、BazaarのGTKインターフェイスを見てみましょう::
587+
588+ $ bzr branch http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk bzr-gtk.john
589+ Branched 292 revision(s).
590+
591+Bazaarはbzr-gtkのtrunkブランチからすべてのファイルをダウンロードして\
592+リビジョンの履歴をそろえ、bzr-gtk.johnというコピーを作ります。
593+
594+これで、ブランチのコピーを手に入れたのでネットの接続のあるなしに\
595+関わらず変更をコミットできます。
596+ブランチはいつでも公開することで共有でき、bzr-gtkチームがあなたの作品を\
597+使いたいと思ったときにBazaarは彼らがあなたのブランチから彼らのブランチに\
598+マージし直す作業を簡単にしてくれます。
599+
600+
601+メインのブランチから自分のブランチを更新する
602+=============================================
603+
604+変更を自分のブランチにコミットする一方で、他の人がコードを親のブランチに\
605+コミットしているということもよくあります。
606+
607+自分のブランチを最新に維持するには、親ブランチから自分のブランチへと変更を\
608+マージします::
609+
610+ $ bzr merge
611+ Merging from saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
612+ All changes applied successfully.
613+
614+何が変更されたのか確認します::
615+
616+ $ bzr diff
617+
618+変更に満足したら、それらを自分のブランチにコミットします::
619+
620+ $ bzr commit -m "Merge from main branch"
621+ Committed revision 295.
622+
623+
624+作業を親のブランチにマージする
625+==============================
626+
627+bzr-gtkの個人ブランチに取り組んだ後で、あなたの変更を上流のプロジェクトに\
628+戻したいことがあるかもしれません。
629+最も簡単な方法はマージディレクティブを使うことです。
630+
631+マージディレクティブ(merge directive)とは、コンピュータに特定のマージを実行\
632+させるためのリクエストです。
633+マージディレクティブは大抵、マージをレビューするためのパッチと、マージを実行する\
634+のに必要となるリビジョン、もしくはリビジョンを取得できるブランチを含みます。
635+
636+次のコマンドの ``mycode.patch`` を適当な名前に書き換えて、マージのディレクティブを作ります::
637+
638+ $ bzr send -o mycode.patch
639+ Using saved parent location: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
640+
641+これでbzr-gtkのプロジェクトにマージディレクティブをEメールで送ることが可能に\
642+なりました。彼らが納得すれば、親ブランチにマージすることができます。
643+
644+
645+さらに学ぶ
646+==========
647+
648+Bazaarに関する詳細な内容は `Bazaarのユーザーガイド <../user-guide/index.html>`_ で調べることができます。
649+
650+コマンドラインでBazaarを学ぶには::
651+
652+ $ bzr help
653+
654+Bazaarのコマンドを学ぶには::
655+
656+ $ bzr help commands
657+
658+''foo'' トピックもしくはコマンドを学ぶには::
659+
660+ $ bzr help foo
661
662=== added file 'doc/ja/sphinx_conf.py'
663--- doc/ja/sphinx_conf.py 1970-01-01 00:00:00 +0000
664+++ doc/ja/sphinx_conf.py 2009-10-29 17:00:30 +0000
665@@ -0,0 +1,214 @@
666+# -*- coding: utf-8 -*-
667+#
668+# Bazaar documentation build configuration file, created by
669+# sphinx-quickstart on Tue Jul 21 17:04:52 2009.
670+#
671+# All configuration values have a default; values that are commented out
672+# serve to show the default.
673+
674+import sys, os
675+
676+# If extensions (or modules to document with autodoc) are in another directory,
677+# add these directories to sys.path here. If the directory is relative to the
678+# documentation root, use os.path.abspath to make it absolute, like shown here.
679+#sys.path.append(os.path.abspath('.'))
680+
681+
682+# -- General configuration -----------------------------------------------------
683+
684+# Add any Sphinx extension module names here, as strings. They can be extensions
685+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
686+extensions = ['sphinx.ext.ifconfig']
687+
688+# Add any paths that contain templates here, relative to this directory.
689+templates_path = ['_templates']
690+
691+# The suffix of source filenames.
692+source_suffix = '.txt'
693+
694+# The encoding of source files.
695+#source_encoding = 'utf-8'
696+
697+# The master toctree document.
698+master_doc = 'index'
699+
700+# General information about the project.
701+project = u'Bazaar'
702+copyright = u'2009, Canonical Ltd'
703+
704+# The version info for the project you're documenting, acts as replacement for
705+# |version| and |release|, also used in various other places throughout the
706+# built documents.
707+#
708+# The short X.Y version.
709+import bzrlib
710+version = '.'.join(str(p) for p in bzrlib.version_info[:2])
711+# The full version, including alpha/beta/rc tags.
712+release = bzrlib.version_string
713+
714+# The language for content autogenerated by Sphinx. Refer to documentation
715+# for a list of supported languages.
716+#language = None
717+
718+# There are two options for replacing |today|: either, you set today to some
719+# non-false value, then it is used:
720+#today = ''
721+# Else, today_fmt is used as the format for a strftime call.
722+#today_fmt = '%B %d, %Y'
723+
724+# List of documents that shouldn't be included in the build.
725+#unused_docs = []
726+
727+# List of directories, relative to source directory, that shouldn't be searched
728+# for source files.
729+exclude_trees = ['_build']
730+
731+# The reST default role (used for this markup: `text`) to use for all documents.
732+#default_role = None
733+
734+# If true, '()' will be appended to :func: etc. cross-reference text.
735+#add_function_parentheses = True
736+
737+# If true, the current module name will be prepended to all description
738+# unit titles (such as .. function::).
739+#add_module_names = True
740+
741+# If true, sectionauthor and moduleauthor directives will be shown in the
742+# output. They are ignored by default.
743+#show_authors = False
744+
745+# The name of the Pygments (syntax highlighting) style to use.
746+pygments_style = 'sphinx'
747+
748+# A list of ignored prefixes for module index sorting.
749+#modindex_common_prefix = []
750+
751+
752+# -- Options for HTML output ---------------------------------------------------
753+
754+# The theme to use for HTML and HTML Help pages. Major themes that come with
755+# Sphinx are currently 'default' and 'sphinxdoc'.
756+html_theme = 'default'
757+
758+# Theme options are theme-specific and customize the look and feel of a theme
759+# further. For a list of options available for each theme, see the
760+# documentation.
761+html_theme_options = {
762+ # Unfortunately, the right sidebar breaks under IE6 and maybe IE7.
763+ # So we stick with the default left placement to cater for users stuck
764+ # on those browsers.
765+ #'rightsidebar': True,
766+
767+ # Non-document areas: header (relbar), footer, sidebar, etc.
768+ # Some useful colours here:
769+ # * blue: darkblue, mediumblue, darkslateblue, cornflowerblue, royalblue,
770+ # midnightblue
771+ # * gray: dimgray, slategray, lightslategray
772+ 'sidebarbgcolor': "cornflowerblue",
773+ 'sidebarlinkcolor': "midnightblue",
774+ 'relbarbgcolor': "darkblue",
775+ 'footerbgcolor': "lightslategray",
776+
777+ # Text, heading and code colouring
778+ 'codebgcolor': "lightyellow",
779+ 'codetextcolor': "firebrick",
780+ 'linkcolor': "mediumblue",
781+ }
782+
783+# Add any paths that contain custom themes here, relative to this directory.
784+#html_theme_path = []
785+
786+# The name for this set of Sphinx documents. If None, it defaults to
787+# "<project> v<release> documentation".
788+#html_title = None
789+
790+# A shorter title for the navigation bar. Default is the same as html_title.
791+#html_short_title = None
792+
793+# The name of an image file (relative to this directory) to place at the top
794+# of the sidebar.
795+#html_logo = None
796+
797+# The name of an image file (within the static path) to use as favicon of the
798+# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
799+# pixels large.
800+html_favicon = "bzr.ico"
801+
802+# Add any paths that contain custom static files (such as style sheets) here,
803+# relative to this directory. They are copied after the builtin static files,
804+# so a file named "default.css" will overwrite the builtin "default.css".
805+html_static_path = ['_static']
806+
807+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
808+# using the given strftime format.
809+#html_last_updated_fmt = '%b %d, %Y'
810+
811+# If true, SmartyPants will be used to convert quotes and dashes to
812+# typographically correct entities.
813+#html_use_smartypants = True
814+
815+# Custom sidebar templates, maps document names to template names.
816+#html_sidebars = {}
817+
818+# Additional templates that should be rendered to pages, maps page names to
819+# template names.
820+#html_additional_pages = {}
821+
822+# If false, no module index is generated.
823+html_use_modindex = False
824+
825+# If false, no index is generated.
826+html_use_index = False
827+
828+# If true, the index is split into individual pages for each letter.
829+#html_split_index = False
830+
831+# If true, links to the reST sources are added to the pages.
832+html_show_sourcelink = True
833+
834+# If true, an OpenSearch description file will be output, and all pages will
835+# contain a <link> tag referring to it. The value of this option must be the
836+# base URL from which the finished HTML is served.
837+#html_use_opensearch = ''
838+
839+# If nonempty, this is the file name suffix for HTML files (e.g. ".xhtml").
840+#html_file_suffix = ''
841+
842+# Output file base name for HTML help builder.
843+htmlhelp_basename = 'bzr-docs'
844+
845+
846+# -- Options for LaTeX output --------------------------------------------------
847+
848+# The paper size ('letter' or 'a4').
849+#latex_paper_size = 'letter'
850+
851+# The font size ('10pt', '11pt' or '12pt').
852+#latex_font_size = '10pt'
853+
854+# Grouping the document tree into LaTeX files. List of tuples
855+# (source start file, target name, title, author, documentclass [howto/manual]).
856+latex_documents = []
857+
858+# The name of an image file (relative to this directory) to place at the top of
859+# the title page.
860+latex_logo = '../Bazaar-Logo-For-Manuals.png'
861+
862+# For "manual" documents, if this is true, then toplevel headings are parts,
863+# not chapters.
864+#latex_use_parts = False
865+
866+# Additional stuff for the LaTeX preamble.
867+#latex_preamble = ''
868+
869+# Documents to append as an appendix to all manuals.
870+#latex_appendices = []
871+
872+# If false, no module index is generated.
873+#latex_use_modindex = True
874+
875+
876+# -- Bazaar-specific configuration ---------------------------------------------
877+
878+# Authors of the documents
879+bzr_team = u'Bazaar Developers'
880
881=== added directory 'doc/ja/tutorials'
882=== added file 'doc/ja/tutorials/centralized_workflow.txt'
883--- doc/ja/tutorials/centralized_workflow.txt 1970-01-01 00:00:00 +0000
884+++ doc/ja/tutorials/centralized_workflow.txt 2009-10-29 17:00:30 +0000
885@@ -0,0 +1,276 @@
886+========================================
887+集中型ワークフローのチュートリアル
888+========================================
889+
890+
891+概要
892+====
893+
894+この文書では、 Bazaar_ を使用することで実現可能なワークフローについて説明します。
895+つまり、分散バージョンコントロールシステムである Bazaar_ を、集中型のやり方で使用するためのワークフローです。
896+Bazaar_ は、非常にフレキシブルに設計されており、完全な分散型からほとんど集中型のワークフローまで、\
897+いくつかの異なるワークフローを受け入れることができます。
898+このワークフローは、初めてのユーザでも簡単に Bazaar_ を使いこなすことができ、\
899+分散型と集中型のオペレーションを組み合わせた業務にも対応できるようになっています。
900+
901+基本的に、この文書はCVSやSubvresionのような集中型バージョンコントロールシステムの経験があるユーザ向けに書かれています。
902+これらの環境では、一般的に、コードベースをホストする単一の中央サーバが存在し、複数の人々がこのコードベース上で作業して、\
903+お互いの作業の同期をとることになります。
904+また、このワークフローは、一人の開発者が複数のマシーン上で作業をする場合にも適用できます。
905+
906+.. _Bazaar: http://bazaar-vcs.org
907+
908+
909+初期セットアップ
910+================
911+
912+Bazaar_ がうまく動くようにするための、まあまあ簡単なセットアップ手順があります。
913+
914+ユーザのEメールの設定
915+---------------------
916+
917+ユーザIDは各コミットに保存されます。これは正確だったり一意だったりする必要はありませんが、\
918+ログメッセージや注釈で使用されるため、何かしら実在する値を設定しておいた方がよいでしょう。
919+
920+::
921+
922+ % bzr whoami "John Doe <jdoe@organization.com>"
923+
924+
925+ローカルリポジトリのセットアップ
926+--------------------------------
927+
928+Bazaar_ のブランチは、通常は履歴のコピーを持っています。そのおかげで分散型での作業ができるわけです。
929+最適化の方法の一つとして、関連するブランチ同士の情報を統合して、\
930+新しいブランチを作るたびに履歴情報を丸ごとコピーしなくてもいいようにすることができます。
931+
932+そのための一番いい方法は、 `共用リポジトリ`_ を作成することです。
933+一般に、 `共用リポジトリ`_ のサブディレクトリ内に複数のブランチがある場合、お互いの記憶領域を共有します。
934+ですので、ホームディレクトリに `共用リポジトリ`_ を作成するようにしましょう。
935+そうすれば、その下に作成したすべてのブランチは、履歴情報の領域を共有することになります。
936+
937+::
938+
939+ % bzr init-repo --trees ~
940+
941+
942+リモートリポジトリのセットアップ
943+---------------------------------
944+
945+作業用の領域とは別に、データを蓄積しておく領域が欲しいというのはよくあることです。
946+集中型のシステム(CVS/SVN)では、このようなワークフローが必要になります。
947+たいていは、これらは別々のマシーンに分けて配置されます。(そうでないこともあります。)
948+実際のところ、これは、特に職場ではとてもよい設定です。
949+蓄積されたデータはバックアップを確実にとることができ、開発者のマシーンに何かトラブルが起こっても\
950+コミットされたデータはけっして無くなりません。
951+
952+それでは、プロジェクト内で共有する ``centralhost`` というマシーンを用意しましょう。
953+先ほども言いましたが、ディスクの使用量を節約するために、 `共用リポジトリ`_ を使用します。
954+
955+::
956+
957+ % bzr init-repo --no-trees sftp://centralhost/srv/bzr/
958+
959+この手順は、新しくcvsrootやSubversionのリポジトリを作るのと同じようなものだと考えることができます。
960+{{{--no-tree}}} オプションの指定によって、ワーキングツリーを作らないようになります。
961+中央リポジトリ内のブランチを直接変更することは無いので、このオプションを指定しておくとよいでしょう。
962+
963+
964+既存のプロジェクトからの移行
965+=============================
966+
967+リポジトリができましたので、プロジェクトの作成にかかりましょう。
968+たいていの場合、 Bazaar_ でバージョン管理したい作業中のコードがすでにあるはずです。
969+もし、そのコードがもともとソース管理されていたのであれば、履歴の情報を保ったまま Bazaar_ に\
970+変換する方法がたくさんあります。
971+しかしながら、それについてはここでは説明しません。詳しくは、 `Tracking Upstream`_ の\
972+"Converting and keeping history"セクションを見てください。
973+
974+.. _Tracking Upstream: http://bazaar-vcs.org/TrackingUpstream
975+
976+..
977+ XXX: プロジェクトの変換について話をするための別の文書が必要なのですが、\
978+ 今ある中ではTrackingUpstreamが一番よい文書です。
979+
980+
981+Developer 1: 最初のリビジョンを作成する
982+-----------------------------------------
983+
984+まず最初に、プロジェクトをホストするリモートリポジトリに、ブランチを作成したいと思います。
985+仮に、"sigil"というプロジェクトをバージョン管理しようとしているとしましょう。
986+
987+::
988+
989+ % bzr init sftp://centralhost/srv/bzr/sigil
990+
991+これは、CVSで言うところの"HEAD"ブランチ、Subversionなら"trunk"にあたるものだと考えてかまいません。
992+これを ``dev`` ブランチと呼ぶことにしましょう。
993+
994+他のファイルとの競合を避けるために、ホームディレクトリのサブディレクトリ内で作業するのが私の好みです。
995+同じように、最終的にでき上がるすべてのブランチを格納できるプロジェクトディレクトリも欲しいですね。
996+::
997+
998+ % cd ~
999+ % mkdir work
1000+ % cd work
1001+ % mkdir sigil
1002+ % cd sigil
1003+ % bzr checkout sftp://centralhost/srv/bzr/sigil dev
1004+ % cd dev
1005+ % cp -ar ~/sigil/* .
1006+ % bzr add
1007+ % bzr commit -m "Initial import of Sigil"
1008+
1009+前のセクションでは、空のブランチ(``sigil`` ブランチ)を ``centralhost`` に作成して、\
1010+それをクライアント端末にチェックアウトしたあと、元々あったプロジェクトのファイルを追加しています。
1011+作業ディレクトリをセットアップするための方法はたくさんありますが、この方法を使うと機能追加用/バグフィックス用\
1012+のブランチを使った作業が簡単にできます。
1013+そして、複数のブランチをとてもうまく扱えるというのが、 Bazaar_ の長所の一つなのです。
1014+
1015+この場合、リモートブランチのチェックアウトを持っているので、 ``~/work/sigil/dev/`` に対してコミットした内容が、\
1016+ローカルと ``centralhost`` の両方に自動的に保存される訳です。
1017+
1018+
1019+Developer N: プロジェクトの作業コピーを取得する
1020+--------------------------------------------------
1021+
1022+プロジェクトの作成に関するすべての作業は1人目の開発者がしてしまっているので、\
1023+他のみんなは単にそのブランチをチェックアウトするだけです。
1024+**ただし、** `ユーザのEメールの設定`_ **と** `ローカルリポジトリのセットアップ`_ **は見ておいてください。**
1025+
1026+現在開発中のツリーのコピーを取得するためには::
1027+
1028+ % cd ~/work/sigil
1029+ % bzr checkout sftp://centralhost/srv/bzr/sigil dev
1030+
1031+今、二人の人が ``sftp://centralhost/srv/bzr/sigil`` のチェックアウトを持っている状態なので、\
1032+片方のチェックアウトが最新のものより古くなってしまうタイミングが出てきます。
1033+コミットの時に、チェックアウトが古いければ Bazaar_ がエラーを返して、コミットは失敗します。
1034+チェックアウトを最新にするには、よそで変更されたツリーに対して ``bzr update`` を使用します。
1035+この時、もし同じファイルが変更されていれば、競合の解決が必要になるかもしれません。
1036+
1037+
1038+別ブランチでの開発
1039+====================
1040+
1041+ここまでは、全員が同じブランチで作業して、変更をコミットしていました。
1042+これはつまり、全員が適正かつ定期的にアップデートを行い、他の人の変更を取り扱う必要があると\
1043+いうことです。
1044+また、誰か一人が何かコードを壊すような変更をコミットして、それが同期されれば、\
1045+全員が問題を抱えることになります。
1046+
1047+たいていの場合、別のブランチ上で開発を行い、コードが安定してからメインのブランチに統合する\
1048+というやり方の方が優れています。これが、CVSやSVNとの一番大きな違いです。
1049+CVSやSVNも別ブランチでの開発はできますが、マージのアルゴリズムがかなり貧弱なので、\
1050+ブランチ間できちんと同期がとれた状態に保つのは難しいことです。
1051+Bazaar_ は、何がマージ済みかを記憶し、たとえファイルが変名されてる場合でもちゃんと変更を\
1052+適用することができます。
1053+
1054+
1055+新しいブランチを作成してそこで作業する
1056+---------------------------------------
1057+まだ変更が完了していない場合でも、他の人がその変更内容にアクセスできるようにしておきたいですよね。
1058+そこで、 ``centralhost`` 上に新しい公開ブランチを作成して、それを手元に持ってくることにしましょう。
1059+
1060+::
1061+
1062+ % cd ~/work/sigil
1063+ % bzr branch sftp://centralhost/srv/bzr/sigil \
1064+ sftp://centralhost/srv/bzr/sigil/doodle-fixes
1065+ % bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
1066+ % cd doodle-fixes
1067+
1068+これで、 ``doodle`` に必要な修正を当てるための場所ができました。
1069+また、他の部分の修正をする人に邪魔されることもありません。
1070+チェックアウトを持っているため、 ``~/work/sigil/doodle-fixes/`` に対してコミットした内容は\
1071+``centralhost`` 上にも現れます。
1072+[#nestedbranches]_ ``dev`` ブランチと同じように、このようなブランチ上で二人の開発者が共同で\
1073+作業することもできます。
1074+[#cbranch]_
1075+
1076+.. [#nestedbranches] あるブランチのサブディレクトリに別のブランチがあるというのはおかしなこと\
1077+ に見えるかもしれませんが、これは何もおかしくありません。入れ子になったブランチは外側のブランチ\
1078+ から派生しているという点で、名前空間の階層と同じようなものだと考えることができます。
1079+
1080+.. [#cbranch] たくさんの独立したブランチを使っている場合、毎回フルURLを入力するのは大変です。
1081+ このURLの入力を簡単にするために、ブランチエイリアスなどたくさんの方法を検討しています。
1082+ 今のところ、 bzrtools_ プラグインが ``bzr cbranch`` コマンドを提供しています。
1083+ これは、ベースとなるブランチを指定して、新しく公開ブランチを作成し、そのチェックアウトを作成する\
1084+ ことを少ない入力でできるように設計されています。
1085+ ``cbranch`` の使い方についてはこの文書の範囲外ですが、最後のコマンドについてはこんな感じです。:
1086+
1087+::
1088+
1089+ % bzr cbranch dev my-feature-branch
1090+
1091+.. _bzrtools: http://bazaar-vcs.org/BzrTools
1092+
1093+
1094+変更内容をマージする
1095+----------------------
1096+
1097+``doodle-fixes`` での変更内容をメインのブランチにマージすることになったら、単にこうするだけです。::
1098+
1099+ % cd ~/work/sigil/dev
1100+ % bzr merge ../doodle-fixes
1101+
1102+これで、変更内容は ``dev`` ブランチ上でもアクセスできるようになりますが、まだコミットはされていません。
1103+最終的な変更内容をレビューして、コードがちゃんとコンパイルでき、テストをパスすることを確認したいならこの時です。
1104+``bzr status`` コマンドと ``bzr diff`` コマンドがここで役立ちます。
1105+また、競合を解決するのもこの時です。Bazaar_ では、競合を解決するまではコミットできないようになっています。
1106+そのため、間違って競合マーカーをコミットしてしまうことはありません。
1107+``bzr status`` コマンドを使えば、他の変更内容と一緒に競合の情報も表示されます。
1108+``bzr conflicts`` なら、競合の情報だけが表示されます。
1109+競合を解決し終わったら、``bzr resolve file/name`` か ``bzr resolve --all`` を実行してください。
1110+[#resolve]_ もし、解決が特に難しい競合がある場合は、 ``bzr remerge`` コマンドを使いたいと思うかもしれません。
1111+このコマンドで、別のマージアルゴリズムを試してみることができ、さらに元のソース行を表示する\
1112+こともできます。(``--show-base``)
1113+
1114+.. [#resolve] マージ実行中に競合の解決をさせるシステムもあります。
1115+ 私たちは、ファイルごとに競合を解決するよりも、ツリー全体を見ながら競合を解決する方がたいていは簡単である\
1116+ ことに気づきました。
1117+ そうすれば、よりたくさんの情報を得られますし、問題を解決したときにテストを実行することもできます。
1118+
1119+
1120+推奨のブランチ構成
1121+---------------------
1122+
1123+とても一般的なブランチ構成として、開発者ごとにひとつずつ専用のブランチを割り当て、中央サーバにも開発者ごとの\
1124+作業領域を用意するという方法があります。これは以下のコマンドでできます。::
1125+
1126+ % bzr branch sftp://centralhost/srv/bzr/sigil \
1127+ sftp://centralhost/srv/bzr/sigil/user-a
1128+ % bzr branch sftp://centralhost/srv/bzr/sigil \
1129+ sftp://centralhost/srv/bzr/sigil/user-b
1130+
1131+これで、開発者ごとに専用の作業用ブランチを割り当てています。
1132+さらに、開発者自身で [#cbranch]_ を使用して新しく新機能開発用ブランチを作成することも簡単にできます。
1133+::
1134+
1135+ % bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
1136+ sftp://centralhost/srv/bzr/sigil/user-a/feature
1137+ % cd ~/work/sigil
1138+ % bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
1139+
1140+
1141+用語解説
1142+=========
1143+
1144+共用リポジトリ
1145+--------------
1146+
1147+Bazaar_ には、”共用リポジトリ”という概念があります。これは、CVSやSubversionのようなの他のRCSが持つ\
1148+旧来の概念に似ています。
1149+たとえば、Subversionでは、サーバ上のリポジトリにすべての履歴情報が保存されていて、手元には履歴情報は\
1150+全くなく、作業ツリーのファイルのチェックアウトがあるだけです。
1151+ここで言う”共用”というのは、ブランチ同士の間で共用するという意味であることに注意してください。
1152+開発者間でも共用される *かも知れません* が、開発者間での共用はスタンドアロンブランチでも可能です。
1153+
1154+Bazaar_ の用語では、"共用リポジトリ"とは複数のブランチが履歴情報を **共有** できる場所のことです。
1155+分散型のワークフローに対応するためには、それぞれのブランチが履歴情報を持っている必要があります。
1156+しかし、しばしばこれは非効率です。関連するブランチ同士は履歴を共有しており、ディスクも共有した方が\
1157+いいためです。
1158+
1159+
1160+..
1161+ vim: tw=74 ft=rst
1162
1163=== added file 'doc/ja/tutorials/index.txt'
1164--- doc/ja/tutorials/index.txt 1970-01-01 00:00:00 +0000
1165+++ doc/ja/tutorials/index.txt 2009-10-29 17:00:30 +0000
1166@@ -0,0 +1,11 @@
1167+チュートリアル
1168+==============
1169+
1170+.. toctree::
1171+ :maxdepth: 1
1172+
1173+ ../mini-tutorial/index
1174+ tutorial
1175+ using_bazaar_with_launchpad
1176+ centralized_workflow
1177+
1178
1179=== added file 'doc/ja/tutorials/tutorial.txt'
1180--- doc/ja/tutorials/tutorial.txt 1970-01-01 00:00:00 +0000
1181+++ doc/ja/tutorials/tutorial.txt 2009-10-29 17:00:30 +0000
1182@@ -0,0 +1,843 @@
1183+.. This file is in Python ReStructuredText format - it can be formatted
1184+.. into HTML or text. In the future we plan to extract the example commands
1185+.. and automatically test them.
1186+
1187+.. This text was previously on the wiki at
1188+.. http://bazaar.canonical.com/IntroductionToBzr
1189+.. but has been moved into the source tree so it can be kept in sync with
1190+.. the source and possibly automatically checked.
1191+
1192+======================
1193+Bazaar チュートリアル
1194+======================
1195+
1196+
1197+.. Introduction
1198+
1199+はじめに
1200+============
1201+
1202+もし、もう分散型バージョン管理に慣れ親しんでいるなら、
1203+"Bazaarに自己紹介する" の節までとばしてください。
1204+もし、分散型でないバージョン管理に慣れ親しんでいるけれど分散型バージョン管理は\
1205+よくわからないのであれば、"分散バージョン管理と分散でないバージョン管理の違い"まで\
1206+とばしてください。
1207+それ以外の場合、コーヒーか紅茶(訳注:日本茶でもいいですよ)を用意して、\
1208+リラックスして読み始めてください。
1209+
1210+バージョン管理の目的
1211+====================
1212+
1213+なにかのテキストデータ(プログラムのソースコード、Webサイト、Unixシステムでの\
1214+設定ファイルなど)を扱う作業をしているとしましょう。
1215+なにかミスをして、重大なデグレードを引き起こしてしまうかもしれません。
1216+例えばメールサーバーの設定ファイルを消してしまったり、だいじなプロジェクトの\
1217+ソースコードを壊してしまったりすることがあります。
1218+だいじな情報を失って、何が何でも取り戻したいと思った経験があるのであれば、\
1219+きっとあなたはBazaarを使う準備ができています。
1220+
1221+Bazaarをはじめとするバージョン管理システムは、ディレクトリに起こった変更を\
1222+**ブランチ (branch)** というディレクトリよりも複雑なものの中に入れて\
1223+追跡します。
1224+ブランチはディレクトリの中に何が入っているかだけでなく、過去のいろいろな\
1225+時点でのディレクトリの中身を格納しています。
1226+なので、望まぬ変更をしてしまったときには過去の時点の状態に戻すことができます。
1227+
1228+バージョン管理システムは、ユーザーが "**リビジョン (revision)** をコミット"
1229+することで変更をブランチに保存します。
1230+このときに生成されるリビジョンとは、本質的にいって、前回保存したときからの\
1231+変更点になります。
1232+
1233+リビジョンはそれ以外のものも持っています(原文:These revisions have other
1234+uses as well.)
1235+たとえば、オプションのログメッセージをつけることで、変更が何を意味して\
1236+いるのかというコメントを残すことができます。
1237+実際に利用されるログメッセージは、 "Webテンプレートをテーブルを閉じるように\
1238+修正" とか "sftpに対応した。 #595 を修正。" といったものです。
1239+
1240+こういったログが保存されているおかげで、たとえば後になって sftp に問題が発生\
1241+したときに、問題が発生するようになったのがどの時点なのか目星をつけることが\
1242+できます。
1243+
1244+
1245+分散バージョン管理と分散でないバージョン管理の違い
1246+===================================================
1247+
1248+多くのバージョン管理システムはサーバーに配置されています。
1249+バージョン管理されているコードに対して作業をしたい場合、サーバーに接続して\
1250+コードを "チェックアウト (checkout)" する必要があります。
1251+そうすると、変更やコミットができるディレクトリができます。
1252+バージョン管理システムのクライアントは、バージョン管理システムのサーバーに\
1253+コミットされた変更を保存します。この方式は集中型として知られています。
1254+
1255+集中型にはいくつかの欠点があります。
1256+集中型バージョン管理システムは、動作するためにサーバーとの接続を要求します。
1257+このことは、サーバーがどこかインターネット上にあって、あなたのマシンが\
1258+インターネットに接続できないときに問題になります。
1259+もしくは、あなたのマシンがインターネットに接続できてもサーバーが落ちている\
1260+ときにもやはり問題になります。
1261+
1262+分散バージョン管理システムは、ブランチをクライアントと同じマシンに置くことで\
1263+この問題を解決しています。
1264+Bazaarの場合、ブランチはバージョン管理されているコードと同じディレクトリに\
1265+保存されます。
1266+これにより、ユーザーは(たとえオフラインであったとしても)好きなときに変更を保存\
1267+(**コミット (commit)**)することができます。
1268+インターネット接続が必要になるのは、どこか別の場所にあるブランチの変更にアクセス\
1269+するときだけです。
1270+
1271+.. TODO:
1272+.. Performing this tracking by hand is a awkward process that over time
1273+.. becomes unwieldy. の部分の訳が判らない。
1274+
1275+多くの人が必要としていることは、ディレクトリ内でおこったファイルやサブディレクトリ\
1276+の変更を追跡することです。
1277+この追跡を手でおこなうのは面倒で不恰好な作業です。
1278+これは、Bazaarのようなバージョン管理システムの目的のひとつです。
1279+バージョン管理システムはユーザーが指示したときにディレクトリツリーの
1280+**リビジョン (revision)** を作ることでこの作業を自動化します。
1281+
1282+バージョン管理システムは単に保存したりundoしたりするだけではありません。
1283+たとえばBazaarでは、ソフトウェアのあるブランチから変更を取り出して、\
1284+関連する別のブランチに適用することができます。このとき、変更を取り出す\
1285+ブランチは別の人のものであってもかまいません。これにより、開発者のグループは\
1286+お互いに書き込み権を与えることなく共同作業することができます。
1287+
1288+.. Bazaar remembers the ''ancestry'' of a revision: the previous revisions
1289+.. that it is based upon. A single revision may have more than one direct
1290+.. descendant, each with different changes, representing a divergence in the
1291+.. evolution of the tree. By branching, Bazaar allows multiple people to
1292+.. cooperate on the evolution of a project, without all needing to work in
1293+.. strict lock-step. Branching can be useful even for a single developer.
1294+
1295+Bazaarではリビジョンの ''親 (ancestry)'' 、つまりそのリビジョンの元になった\
1296+リビジョンを記録しています。
1297+ひとつのリビジョンは複数の、それぞれ別の変更を含む子供リビジョンを持つことが\
1298+あり、それはツリーの進化が分岐していることを意味しています。
1299+Bazaarではブランチを作ることによって、複数の人が厳しい lock-step をとらなくても\
1300+協力することができます。
1301+ブランチを作ることは個人での開発でも便利です。
1302+
1303+.. Introducing yourself to Bazaar
1304+
1305+Bazaarに自己紹介する
1306+=====================
1307+
1308+.. Bazaar installs a single new command, **bzr**. Everything else is a
1309+ subcommand of this. You can get some help with ``bzr help``. Some arguments
1310+ are grouped in topics: ``bzr help topics`` to see which topics are available.
1311+
1312+Bazaarは **bzr** という新しいコマンドをひとつインストールします。
1313+他の全ては bzr のサブコマンドになります。
1314+``bzr help`` コマンドでいくつかのヘルプを見られます。
1315+幾つかの話題は topic にまとめられていて、 ``bzr help topics`` で\
1316+利用可能なトピックの一覧を見られます。
1317+
1318+バージョン管理システムの一つの機能は、誰が何を変更したのかを追跡することです。
1319+分散型バージョン管理システムでは、各開発者がグローバルユニークなIDを持つ\
1320+必要があります。
1321+ほとんどの人はこのIDとして利用できる eメールアドレス を持っています。
1322+Bazaarはコンピュータのユーザー名とホスト名から自動でメールアドレスを\
1323+生成します。Bazaarが自動で作成したメールアドレス以外のものを使いたい\
1324+場合、３つの選択肢があります。
1325+
1326+1. ``bzr whoami`` を使ってメールアドレスを設定します。これはグローバルなIDを設定\
1327+ する最も簡単な方法です。グローバルなIDを設定するには::
1328+
1329+ % bzr whoami "Your Name <email@example.com>"
1330+
1331+ 特定のブランチでべつのアドレスを使いたい場合、そのブランチのディレクトリの\
1332+ なかで次のコマンドを実行します::
1333+
1334+ % bzr whoami --branch "Your Name <email@example.com>"
1335+
1336+#. ``?/.bazaar/bazaar.conf`` [1]_ の中のメールアドレスを、以下のようにして\
1337+ 設定します。 ``[DEFAULT]`` の部分が大文字と小文字を区別するので注意して\
1338+ ください::
1339+
1340+ [DEFAULT]
1341+ email=Your Name <email@isp.com>
1342+
1343+ 特定のブランチにおける設定は、 ``?/.bazaar/locations.conf``
1344+ にブランチのセクションを作成して次のように書くことができます。 ::
1345+
1346+ [/the/path/to/the/branch]
1347+ email=Your Name <email@isp.com>
1348+
1349+
1350+#. 環境変数 ``$BZR_EMAIL`` もしくは ``$EMAIL`` (``$BZR_EMAIL`` の方が優先\
1351+ されます)にメールアドレスを設定することで、上の二つの方法で設定された\
1352+ オプションを上書きすることができます。
1353+
1354+.. [1] Windowsではユーザー設定ファイルはアプリケーションデータディレクトリに\
1355+ おかれます。なので、設定ファイルの場所は ``?/.bazaar/branch.conf`` ではなく\
1356+ ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``
1357+ になります。
1358+ 同じことが ``locations.conf``, ``ignore``, ``plugins`` ディレクトリも\
1359+ 同じです。
1360+
1361+ブランチを作る
1362+==============
1363+
1364+履歴はデフォルトではブランチの .bzr ディレクトリの中に保存されます。
1365+
1366+.. これは現行のバージョンでできるのでは？: In a
1367+ future version of Bazaar, there will be a facility to store it in a
1368+ separate repository, which may be remote.
1369+
1370+既存のディレクトリの中で ``bzr init`` をすると新しいブランチを作成できます::
1371+
1372+ % mkdir tutorial
1373+ % cd tutorial
1374+ % ls -a
1375+ ./ ../
1376+ % pwd
1377+ /home/mbp/work/bzr.test/tutorial
1378+ %
1379+ % bzr init
1380+ % ls -aF
1381+ ./ ../ .bzr/
1382+ %
1383+
1384+ファイルには３つのクラス、 unknown, ignored, versioned があります。
1385+**add** コマンドはファイルを versioned にし、そのファイルへの変更の記録を\
1386+開始します::
1387+
1388+ % echo 'hello world' > hello.txt
1389+ % bzr status
1390+ unknown:
1391+ hello.txt
1392+ % bzr add hello.txt
1393+ added hello.txt
1394+ % bzr status
1395+ added:
1396+ hello.txt
1397+
1398+もし間違えたファイルを add してしまった場合、そのファイルを unversioned
1399+状態に戻すために ``bzr remove`` してください。
1400+この場合の ``bzr remove`` は、ほかの場合 [2]_ とちがってファイルを削除\
1401+しません。
1402+
1403+.. [2] ``bzr remove`` はファイルがバージョン管理されていて何も変更されて\
1404+ いない場合に、そのファイルを削除します。 ``--keep`` オプションで常に\
1405+ ファイルを残すことができます。 ``--force`` オプションで常にファイルを\
1406+ 削除することもできます。
1407+
1408+.. Branch locations
1409+
1410+ブランチの場所
1411+===============
1412+
1413+すべての履歴はブランチに格納されます。ブランチとは、管理用のファイルを\
1414+含んだただのディレクトリです。デフォルトでは、svnやsvkのような、分離した\
1415+リポジトリやデータベースはありません。分離したリポジトリを作成することも\
1416+できます(``bzr init-repo`` コマンドを参照してください)。大規模なブランチを\
1417+利用する場合や、中規模のブランチをたくさん利用する場合にはリポジトリを\
1418+分離するといいでしょう。
1419+
1420+自分のコンピュータのファイルシステム上にあるブランチを参照するときは\
1421+ブランチを格納しているディレクトリ名で指定できます。 bzr は http や ftp\
1422+経由でブランチにアクセスすることもできます。例::
1423+
1424+ % bzr log http://bazaar-vcs.org/bzr/bzr.dev/
1425+ % bzr log sftp://bazaar-vcs.org/bzr/bzr.dev/
1426+
1427+プラグインをインストールすれば、 rsync プロトコルを使ってブランチにアクセス\
1428+することもできます。
1429+
1430+ブランチを指定した場所に置く方法については、 `ブランチを公開する`_ 節を\
1431+ご覧ください。
1432+
1433+.. Reviewing changes
1434+
1435+変更をレビューする
1436+===================
1437+
1438+一仕事終えたら、それを履歴に **コミット (commit)** しましょう。
1439+新しい機能を追加したり、バグを直したり、コードやドキュメントを更新したら\
1440+いつでもコミットするのは良いことです。
1441+すべてのリビジョンが良い状態であるようにするために、コミットする前にコードを\
1442+コンパイルしたりテストスイートを実行するのも良い習慣です。
1443+コミットする前にコミットしようとしているものを確認するためにレビューすることが\
1444+できます。
1445+
1446+この目的で便利な二つのコマンドがあります。 **status** と **diff** です。
1447+
1448+bzr status
1449+----------
1450+
1451+**status** コマンドは、今の作業ツリーが最後のリビジョンからどのように\
1452+変更されたのかを教えてくれます::
1453+
1454+ % bzr status
1455+ modified:
1456+ foo
1457+
1458+``bzr status`` は変更が無かったり無視されているファイルを隠します。
1459+status コマンドはオプションとして、確認対象となる複数のファイル名やディレクトリ名を\
1460+渡すことができます。
1461+
1462+bzr diff
1463+--------
1464+
1465+**diff** コマンドは通常の unified diff フォーマットですべてのファイルの\
1466+テキストの変更を表示します。
1467+このコマンドの出力を pipe 経由で、''patch'', ''diffstat'', ''fileterdiff'',
1468+''colordiff'' といったコマンドに渡すことができます。 ::
1469+
1470+ % bzr diff
1471+ === added file 'hello.txt'
1472+ --- hello.txt 1970-01-01 00:00:00 +0000
1473+ +++ hello.txt 2005-10-18 14:23:29 +0000
1474+ @@ -0,0 +1,1 @@
1475+ +hello world
1476+
1477+
1478+``-r`` オプションをつけると、作業ツリーを古いリビジョンと比較したり、\
1479+二つのリビジョン間の差分を見ることができます。 ::
1480+
1481+ % bzr diff -r 1000.. # everything since r1000
1482+ % bzr diff -r 1000..1100 # changes from 1000 to 1100
1483+
1484+``--diff-options`` オプションをつけると、 bzr は外部の diff プログラムに\
1485+オプションをつけて起動します。 例::
1486+
1487+ % bzr diff --diff-options --side-by-side foo
1488+
1489+プロジェクトによっては二つのファイルに接頭辞がついた patch が好まれます。
1490+``--prefix`` オプションでそのような接頭辞をつけることができます。
1491+ショートカットとして、 ``bzr diff -p1`` は ``patch -p1`` コマンドが受け付ける\
1492+形で差分を出力します。
1493+
1494+
1495+.. Committing changes
1496+
1497+変更をコミットする
1498+==================
1499+
1500+作業ツリーの状態に満足したら、ブランチに **コミット (commit)** しましょう。
1501+コミットとは作業ツリーの状態のスナップショットを保持するリビジョンを新しく作ることです。
1502+
1503+bzr commit
1504+----------
1505+
1506+.. The **commit** command takes a message describing the changes in the
1507+.. revision. It also records your userid, the current time and timezone, and
1508+.. the inventory and contents of the tree. The commit message is specified
1509+.. by the ``-m`` or ``--message`` option. You can enter a multi-line commit
1510+.. message; in most shells you can enter this just by leaving the quotes open
1511+.. at the end of the line.
1512+
1513+**commit** コマンドはそのリビジョンの変更を説明するメッセージを受け取ります。
1514+また、あなたのユーザーID、今の時間とタイムゾーン、ツリーの内容をあわせて記録します。
1515+コミットメッセージは ``-m`` もしくは ``--message`` オプションで指定できます。
1516+複数行のコメントも利用できます。多くのシェルはクォートを開いたままで改行する\
1517+ことで複数行の入力が可能です。
1518+
1519+::
1520+
1521+ % bzr commit -m "added my first file"
1522+
1523+.. You can also use the ``-F`` option to take the message from a file. Some
1524+.. people like to make notes for a commit message while they work, then
1525+.. review the diff to make sure they did what they said they did. (This file
1526+.. can also be useful when you pick up your work after a break.)
1527+
1528+メッセージをファイルで渡すには ``-F`` オプションを使います。
1529+コミットメッセージを先に作成し、それとdiffを合わせてレビューすることで、
1530+コミットメッセージとコミット内容が一致していることを確認する人もいます。
1531+(このファイルは休憩から戻ってきて作業を思い出すときにも役に立つでしょう)
1532+
1533+.. Message from an editor
1534+
1535+エディタからメッセージを入力する
1536+----------------------------------
1537+
1538+.. If you use neither the ``-m`` nor the ``-F`` option then bzr will open an
1539+.. editor for you to enter a message. The editor to run is controlled by
1540+.. your ``$VISUAL`` or ``$EDITOR`` environment variable, which can be overridden
1541+.. by the ``editor`` setting in ``?/.bazaar/bazaar.conf``; ``$BZR_EDITOR`` will
1542+.. override either of the above mentioned editor options. If you quit the
1543+.. editor without making any changes, the commit will be cancelled.
1544+
1545+``-m`` オプションも ``-F`` オプションも指定しなかった場合、 bzr はメッセージを\
1546+入力するためにエディタを立ち上げます。
1547+このエディタは ``$VISUAL`` か ``$EDITOR`` 環境変数で制御することができます。
1548+この環境変数を `` /.bazaar/bazaar.conf`` 内の ``editor`` を設定して上書き\
1549+することができ、さらに ``$BZR_EDITOR`` 環境変数がそれらすべてを上書きします。
1550+もし何も変更せずにエディタを閉じたなら、コミットはキャンセルされます。
1551+
1552+.. The file that is opened in the editor contains a horizontal line. The part
1553+.. of the file below this line is included for information only, and will not
1554+.. form part of the commit message. Below the separator is shown the list of
1555+.. files that are changed in the commit. You should write your message above
1556+.. the line, and then save the file and exit.
1557+
1558+エディタで開かれるファイルには水平線が含まれています。この線より下の部分は\
1559+参考用であり、コミットメッセージには含まれません。
1560+水平線の下にはコミットで変更されるファイルのリストが表示されます。
1561+メッセージは水平線の上に書く必要があります。そうしたら、ファイルを保存して\
1562+エディタを終了してください。
1563+
1564+.. If you would like to see the diff that will be committed as you edit the
1565+.. message you can use the ``--show-diff`` option to ``commit``. This will include
1566+.. the diff in the editor when it is opened, below the separator and the
1567+.. information about the files that will be committed. This means that you can
1568+.. read it as you write the message, but the diff itself wont be seen in the
1569+.. commit message when you have finished. If you would like parts to be
1570+.. included in the message you can copy and paste them above the separator.
1571+
1572+``commit`` コマンドに ``--show-diff`` オプションをつけると、コミットされる\
1573+変更の diff を見ることができます。この diff はエディタが開いたときに水平線\
1574+やコミットされるファイルの情報よりも下に含まれます。
1575+なので、コミットメッセージを書くときに diff を見ることができますが、\
1576+コミットメッセージ自体には diff が含まれません。
1577+コミットメッセージに diff を含めたい場合は、水平線より上にコピーペースト\
1578+してください。
1579+
1580+.. Selective commit
1581+
1582+選択コミット
1583+----------------
1584+
1585+.. If you give file or directory names on the commit command line then only
1586+.. the changes to those files will be committed. For example::
1587+
1588+commit コマンドにファイル名やディレクトリ名を渡したとき、それらのファイルの\
1589+変更だけがコミットされます。 例 ::
1590+
1591+ % bzr commit -m "documentation fix" commit.py
1592+
1593+.. By default bzr always commits all changes to the tree, even if run from a
1594+.. subdirectory. To commit from only the current directory down, use::
1595+
1596+デフォルトでは bzr は、サブディレクトリから実行される場合でもすべての変更を\
1597+コミットします。
1598+カレントディレクトリ以下だけをコミットする場合は、次のようにします ::
1599+
1600+ % bzr commit .
1601+
1602+
1603+.. Removing uncommitted changes
1604+
1605+コミットされていない変更を削除する
1606+===================================
1607+
1608+.. If you've made some changes and don't want to keep them, use the
1609+.. **revert** command to go back to the previous head version. It's a good
1610+.. idea to use ``bzr diff`` first to see what will be removed. By default the
1611+.. revert command reverts the whole tree; if file or directory names are
1612+.. given then only those ones will be affected. ``bzr revert`` also clears the
1613+.. list of pending merges revisions.
1614+
1615+不要な変更がある場合、 **revert** コマンドで最後のリビジョンの状態に戻る\
1616+ことができます。
1617+revert するまえに ``bzr diff`` で何が削除されるのかを確認しておくと良いでしょう。
1618+デフォルトでは revert コマンドはツリー全体を revert します。ファイル名や\
1619+ディレクトリ名が指定されている場合は、そのファイルだけが revert されます。
1620+``bzr revert`` はマージ待ちリビジョンのリストも削除します。
1621+
1622+
1623+.. Ignoring files
1624+
1625+ファイルを無視する
1626+===================
1627+
1628+.. The .bzrignore file
1629+
1630+.bzrignore ファイル
1631+-------------------
1632+
1633+.. Many source trees contain some files that do not need to be versioned,
1634+.. such as editor backups, object or bytecode files, and built programs. You
1635+.. can simply not add them, but then they'll always crop up as unknown files.
1636+.. You can also tell bzr to ignore these files by adding them to a file
1637+.. called ``.bzrignore`` at the top of the tree.
1638+
1639+多くのソースツリーはバージョン管理する必要のないファイルをたくさん含んでいます。
1640+たとえば、エディタのバックアップファイルや、オブジェクトファイル、バイトコード、
1641+ビルドされたプログラムなどです。
1642+こういったファイルを単に add しないこともできますが、そうすると毎回 unknown file
1643+としてたびたび出現することになります。
1644+ツリートップにある ``.bzrignore`` とよばれるファイルにそれらのファイルを追加する\
1645+ことで、bzrにそれらのファイルを無視させることができます。
1646+
1647+.. This file contains a list of file wildcards (or "globs"), one per line.
1648+.. Typical contents are like this::
1649+
1650+このファイルは行ごとにワイルドカード (もしくは"glob") のリストを含みます。
1651+典型的な内容の例です::
1652+
1653+ *.o
1654+ *?
1655+ *.tmp
1656+ *.py[co]
1657+
1658+.. If a glob contains a slash, it is matched against the whole path from the
1659+.. top of the tree; otherwise it is matched against only the filename. So
1660+.. the previous example ignores files with extension ``.o`` in all
1661+.. subdirectories, but this example ignores only ``config.h`` at the top level
1662+.. and HTML files in ``doc/``::
1663+
1664+glob がスラッシュを含む場合、ツリーのトップからのパス全体にマッチします。
1665+そうでない場合は、単にファイル名にマッチします。
1666+なので、上の例はすべてのサブディレクトリの ``.o`` 拡張子を持つファイルを無視\
1667+しますが、次の例ではツリーのトップにある ``config.h`` ファイルと、 ``doc/``
1668+ディレクトリ以下のHTMLファイルだけを無視します::
1669+
1670+ ./config.h
1671+ doc/*.html
1672+
1673+.. To get a list of which files are ignored and what pattern they matched,
1674+.. use ``bzr ignored``::
1675+
1676+どのファイルがどのパターンにマッチして無視されているのかを、 ``bzr ignored``
1677+コマンドで表示することができます::
1678+
1679+ % bzr ignored
1680+ config.h ./config.h
1681+ configure.in? *?
1682+
1683+.. It is OK to have either an ignore pattern match a versioned file, or to
1684+.. add an ignored file. Ignore patterns have no effect on versioned files;
1685+.. they only determine whether unversioned files are reported as unknown or
1686+.. ignored.
1687+
1688+バージョン管理されているファイルが無視パターンにマッチしたり無視リストに\
1689+入っていても大丈夫です。無視パターンはバージョン管理されたファイルには\
1690+影響しません。バージョン管理されていないファイルを 'unknown' として扱うか\
1691+'ignored' として扱うかを決めるためだけに使われます。
1692+
1693+
1694+.. The ``.bzrignore`` file should normally be versioned, so that new copies
1695+.. of the branch see the same patterns::
1696+
1697+``.bzrignore`` ファイルは普通はバージョン管理されます。なのでそのブランチの\
1698+コピーでも同じパターンが無視されます。 ::
1699+
1700+ % bzr add .bzrignore
1701+ % bzr commit -m "Add ignore patterns"
1702+
1703+
1704+.. Global ignores
1705+
1706+グローバルの無視設定
1707+---------------------
1708+
1709+.. There are some ignored files which are not project specific, but more user
1710+.. specific. Things like editor temporary files, or personal temporary files.
1711+.. Rather than add these ignores to every project, bzr supports a global
1712+.. ignore file in ``?/.bazaar/ignore`` [1]_. It has the same syntax as the
1713+.. per-project ignore file.
1714+
1715+エディタの一時ファイルや個人の一時ファイルなど、\
1716+幾つかの無視ファイルはプロジェクト依存ではなくてユーザー依存です。
1717+こういったファイルを全プロジェクトで無視設定するかわりに、グローバルの\
1718+無視設定ファイル ``~/.bazaar/ignore`` を利用できます。
1719+これはプロジェクトの ignore ファイルと同じ文法で記述します。
1720+
1721+
1722+.. Examining history
1723+
1724+履歴を閲覧する
1725+===============
1726+
1727+bzr log
1728+-------
1729+
1730+.. The ``bzr log`` command shows a list of previous revisions. The ``bzr log
1731+.. --forward`` command does the same in chronological order to get most
1732+.. recent revisions printed at last.
1733+
1734+``bzr log`` コマンドは過去のリビジョンのリストを表示します。
1735+``bzr log --forward`` コマンドは同じ内容を、時系列順で最新のものが最後に\
1736+くるように出力します。
1737+
1738+.. As with ``bzr diff``, ``bzr log`` supports the ``-r`` argument::
1739+
1740+``bzr diff`` と同じように、 ``bzr log`` も ``-r`` 引数をサポートします::
1741+
1742+ % bzr log -r 1000.. # リビジョン r1000 とそれ以降すべて
1743+ % bzr log -r ..1000 # r1000 とそれ以前のすべて
1744+ % bzr log -r 1000..1100 # r1000 から r1100 まで
1745+ % bzr log -r 1000 # リビジョン r1000 だけ
1746+
1747+.. % bzr log -r 1000.. # Revision 1000 and everything after it
1748+.. % bzr log -r ..1000 # Everything up to and including r1000
1749+.. % bzr log -r 1000..1100 # changes from 1000 to 1100
1750+.. % bzr log -r 1000 # The changes in only revision 1000
1751+
1752+
1753+.. Branch statistics
1754+
1755+ブランチの情報
1756+=================
1757+
1758+.. The ``bzr info`` command shows some summary information about the working
1759+.. tree and the branch history.
1760+
1761+``bzr info`` コマンドは作業ツリーとブランチの履歴に関する情報の要約を表示します。
1762+
1763+
1764+.. Versioning directories
1765+
1766+ディレクトリをバージョン管理する
1767+================================
1768+
1769+.. bzr versions files and directories in a way that can keep track of renames
1770+.. and intelligently merge them::
1771+
1772+bzr はファイルとディレクトリを、名前の変更を追跡して賢くマージできるように\
1773+バージョン管理します::
1774+
1775+ % mkdir src
1776+ % echo 'int main() {}' > src/simple.c
1777+ % bzr add src
1778+ added src
1779+ added src/simple.c
1780+ % bzr status
1781+ added:
1782+ src/
1783+ src/simple.c
1784+
1785+
1786+.. Deleting and removing files
1787+
1788+ファイルを削除する
1789+===================
1790+
1791+.. You can delete files or directories by just deleting them from the working
1792+.. directory. This is a bit different to CVS, which requires that you also
1793+.. do ``cvs remove``.
1794+
1795+ファイルを削除するのは、単純に作業ツリーからファイルを削除するだけでできます。
1796+これは、 ``cvs remove`` が必要な CVS とは少し異なります。
1797+
1798+.. ``bzr remove`` makes the file un-versioned, but may or may not delete the
1799+.. working copy [2]_. This is useful when you add the wrong file, or decide that
1800+.. a file should actually not be versioned.
1801+
1802+``bzr remove`` はファイルをバージョン管理対象からはずしますが、作業ツリーから\
1803+削除することも削除しないこともできます。 [2]_
1804+これは間違ったファイルを追加してしまったり、あるファイルをバージョン管理するのを\
1805+やめる場合に便利です。
1806+
1807+::
1808+
1809+ % rm -r src
1810+ % bzr remove -v hello.txt
1811+ ? hello.txt
1812+ % bzr status
1813+ removed:
1814+ hello.txt
1815+ src/
1816+ src/simple.c
1817+ unknown:
1818+ hello.txt
1819+
1820+.. If you remove the wrong file by accident, you can use ``bzr revert`` to
1821+.. restore it.
1822+
1823+もし間違ってファイルを削除してしまった場合、 ``bzr revert`` でリストアできます。
1824+
1825+
1826+.. Branching
1827+
1828+ブランチを作る
1829+==============
1830+
1831+.. Often rather than starting your own project, you will want to submit a
1832+.. change to an existing project. To do this, you'll need to get a copy of
1833+.. the existing branch. Because this new copy is potentially a new branch,
1834+.. the command is called **branch**::
1835+
1836+自分でプロジェクトを始めるのではなく、既存のプロジェクトに変更を加えたい場合があります。
1837+この場合、既存のブランチのコピーを取得する必要があります。
1838+このコピーは新しいブランチになるので、このコマンドは **branch** という名前になっています::
1839+
1840+ % bzr branch http://bazaar-vcs.org/bzr/bzr.dev
1841+ % cd bzr.dev
1842+
1843+.. This copies down the complete history of this branch, so we can do all
1844+.. operations on it locally: log, annotate, making and merging branches.
1845+.. There will be an option to get only part of the history if you wish.
1846+
1847+.. XXX: There will be の訳これでいい？
1848+
1849+これでブランチの完全な履歴をコピーできたので、すべての操作 (log, annotate,
1850+branch の作成とマージなど) をローカルで実行できます。
1851+履歴の一部だけを取得するオプションも追加される予定です。
1852+
1853+.. You can also get a copy of an existing branch by copying its directory,
1854+.. expanding a tarball, or by a remote copy using something like rsync.
1855+
1856+既存のブランチをコピーするには、普通にディレクトリをコピーしたり、tarballを\
1857+展開したり、リモートから rsync のような方法でコピーすることもできます。
1858+
1859+.. Following upstream changes
1860+
1861+上流の変更を追いかける
1862+==========================
1863+
1864+.. You can stay up-to-date with the parent branch by "pulling" in their
1865+ changes::
1866+
1867+変更を "pull" することで手元のブランチを上流のブランチに対して最新に保つことが\
1868+できます。
1869+
1870+ % bzr pull
1871+
1872+.. After this change, the local directory will be a mirror of the source. This
1873+.. includes the ''revision-history'' - which is a list of the commits done in
1874+.. this branch, rather than merged from other branches.
1875+
1876+.. XXX This includes～がわからない.
1877+
1878+このコマンドを実行した後、ローカルディレクトリはpull元のミラーになります。
1879+ミラーするものには、 ''revision-history'' を含みます。つまり、別のブランチから\
1880+マージするのではなくて、このブランチに対してコミットした履歴になります。
1881+
1882+.. This command only works if your local (destination) branch is either an
1883+.. older copy of the parent branch with no new commits of its own, or if the
1884+.. most recent commit in your local branch has been merged into the parent
1885+.. branch.
1886+
1887+このコマンドはローカルの(pull先)ブランチが親ブランチの古いコピーで独自の\
1888+あたらしいリビジョンを一切含まないか、ローカルブランチへの最新のコミットが\
1889+親ブランチにマージされているときにのみ成功します。
1890+
1891+.. Merging from related branches
1892+
1893+関連ブランチからマージする
1894+=============================
1895+
1896+.. If two branches have diverged (both have unique changes) then ``bzr
1897+.. merge`` is the appropriate command to use. Merge will automatically
1898+.. calculate the changes that exist in the branch you're merging from that
1899+.. are not in your branch and attempt to apply them in your branch.
1900+
1901+二つのブランチが分岐している(互いに異なる変更を持っている)とき、
1902+``bzr merge`` コマンドの出番です。
1903+merge はマージ元ブランチにあって手元のブランチにない変更を自動で探して、\
1904+その変更を手元に適用しようと試みます。
1905+
1906+::
1907+
1908+ % bzr merge URL
1909+
1910+
1911+.. If there is a conflict during a merge, 3 files with the same basename
1912+.. are created. The filename of the common base is appended with ".BASE",
1913+.. the filename of the file containing your changes is appended with
1914+.. ".THIS" and the filename with the changes from the other tree is
1915+.. appended with ".OTHER". Using a program such as kdiff3, you can now
1916+.. comfortably merge them into one file. In order to commit you have to
1917+.. rename the merged file (".THIS") to the original file name. To
1918+.. complete the conflict resolution you must use the resolve command,
1919+.. which will remove the ".OTHER" and ".BASE" files. As long as there
1920+.. exist files with .BASE, .THIS or .OTHER the commit command will
1921+.. report an error.
1922+
1923+マージ中に衝突(conflict)が発生した場合、同じ基本名(basename)をもつ\
1924+3つのファイルが作成されます。
1925+共通の祖先になるファイルのファイル名には ".BASE" が、
1926+手元のブランチの変更を含むファイル名には ".THIS" が、
1927+マージ元の変更を含むファイル名には ".OTHER" が末尾に追加されます。
1928+kdiff3 のようなプログラムを利用してこれらのファイルをひとつに\
1929+マージすることができます。
1930+コミットするには、マージされた ".THIS" ファイルを元のファイル名に\
1931+リネームします。
1932+衝突の解決を完了するには、 resolve コマンドを使います。
1933+このコマンドは ".OTHER" と ".BASE" ファイルを削除します。
1934+.BASE, .THIS, .OTHER ファイルが残っている場合、 commit コマンドは\
1935+エラーを報告します。
1936+
1937+::
1938+
1939+ % kdiff3 file.BASE file.OTHER file.THIS
1940+ % mv file.THIS file
1941+ % bzr resolve file
1942+
1943+[**TODO**: explain conflict markers within files]
1944+
1945+
1946+ブランチを公開する
1947+======================
1948+
1949+.. You don't need a special server to publish a bzr branch, just a normal web
1950+.. server. Just mirror the files to your server, including the .bzr
1951+.. directory. One can push a branch (or the changes for a branch) by one of
1952+.. the following three methods:
1953+
1954+bzrのブランチを公開するには特別なサーバーは必要ありません、普通のWebサーバーが\
1955+使えます。
1956+.bzr ディレクトリを含めてファイルをサーバーにミラーしてください。
1957+ブランチをpush(やブランチに対する操作)するのに以下の3つの方法があります。
1958+
1959+.. * The best method is to use bzr itself to do it.
1960+
1961+* 最良の方法は bzr 自体を使うことです。
1962+
1963+ ::
1964+
1965+ % bzr push sftp://servername.com/path/to/directory
1966+
1967+.. (The destination directory must already exist unless the
1968+.. ``--create-prefix`` option is used.)
1969+
1970+ (push先ディレクトリがすでに存在するか、 ``--create-prefix`` オプションを\
1971+ 利用する必要があります。)
1972+
1973+.. * Another option is the ``rspush`` plugin that comes with BzrTools, which
1974+.. uses rsync to push the changes to the revision history and the working
1975+.. tree.
1976+
1977+* 別の選択肢は bzrtools に含まれる ``rspush`` プラグインを利用することです。
1978+ これはリモートの履歴と作業ツリーに変更を push するのに rsync を利用します。
1979+
1980+.. * You can also copy the files around manually, by sending a tarball, or using
1981+.. rsync, or other related file transfer methods. This is usually less safe
1982+.. than using ``push``, but may be faster or easier in some situations.
1983+
1984+* 手動で、 tarball を送ったり rsync を使ったりほかの転送方法を利用してファイルを\
1985+ 送ることで
1986+
1987+
1988+.. Moving changes between trees
1989+
1990+変更をツリー間で移動する
1991+============================
1992+
1993+.. It happens to the best of us: sometimes you'll make changes in the wrong
1994+.. tree. Maybe because you've accidentally started work in the wrong directory,
1995+.. maybe because as you're working, the change turns out to be bigger than you
1996+.. expected, so you start a new branch for it.
1997+
1998+どんな人にでもありえることですが、適切ではないツリー上で変更してしまうことがあります。
1999+単純に作業するディレクトリを間違えたり、変更がよそうよりも大きくなってしまったりして、
2000+その変更のために新しいブランチを作りなおすことがあります。
2001+
2002+.. To move your changes from one tree to another, use
2003+
2004+変更をあるツリーから別のツリーに移動するには
2005+
2006+::
2007+
2008+ % cd NEWDIR
2009+ % bzr merge --uncommitted OLDDIR
2010+
2011+.. This will apply all of the uncommitted changes you made in OLDDIR to NEWDIR.
2012+.. It will not apply committed changes, even if they could be applied to NEWDIR
2013+.. with a regular merge. The changes will remain in OLDDIR, but you can use ``bzr
2014+.. revert OLDDIR`` to remove them, once you're satisfied with NEWDIR.
2015+
2016+これですべてのコミットされていないOLDDIR上の変更がNEWDIRに適用されます。
2017+コミットされていない変更は、通常のmergeでNEWDIRに適用することができる場合でも適用されません。
2018+OLDDIR上の変更はそのまま残りますが、NEWDIRの状態に満足したら ``bzr revert OLDDIR``
2019+で削除することができます。
2020+
2021+.. NEWDIR does not have to be a copy of OLDDIR, but they should be related.
2022+.. The more different they are, the greater the chance of conflicts.
2023+
2024+NEWDIRはOLDDIRのコピーである必要はありませんが、関連しているべきです。
2025+両者の違いが大きければそれだけ衝突が起こる可能性が大きくなります。
2026
2027=== added file 'doc/ja/tutorials/using_bazaar_with_launchpad.txt'
2028--- doc/ja/tutorials/using_bazaar_with_launchpad.txt 1970-01-01 00:00:00 +0000
2029+++ doc/ja/tutorials/using_bazaar_with_launchpad.txt 2009-10-29 17:00:30 +0000
2030@@ -0,0 +1,552 @@
2031+===========================
2032+LaunchpadでBazaarを使う
2033+===========================
2034+
2035+
2036+動機付け
2037+==========
2038+
2039+コミュニティはチームとは違う
2040+----------------------------------
2041+
2042+ソフトウェアの初回リリースをしなければならない人々のチームというのは、\
2043+一人から数千人まで、その規模は多岐に渡ります。
2044+その要求に応じて、技術的な課題、経営上の課題、その両方が非常に大きなもの\
2045+になる可能性があります。
2046+Bazaarユーザガイドで説明したように、"ふさわしい"プロセスを選択し、\
2047+それに見合ったワークフローをサポートするBazaarのようなツールを使うことは、\
2048+大きな手助けになるでしょう。
2049+
2050+.. The team of people required to create the initial release
2051+ of a piece of software may vary in size from one person
2052+ to several thousand people. Depending on the requirements,
2053+ the challenges involved, both technical and managerial,
2054+ can be immense. As explained in the Bazaar User Guide, selecting
2055+ "just right" processes and using tools like Bazaar to support
2056+ matching workflows can greatly help.
2057+
2058+しかし、ソフトウェアによる成功のためには、すばらしいチーム以上のものが\
2059+必要です。 - それは、健全で活発な *コミュニティ* です。
2060+このグループは、通常はチームよりもはるかに大きく、なぜならそのソフトウェアに\
2061+関心のあるすべての人 - 開発チーム、ユーザ、トレーニングパートナー、\
2062+サポートパートナー、サードパーティの開発者など - を含むからです。
2063+
2064+.. Success with software though requires more than a great team - it
2065+ requires a healthy, active *community*. This group is typically
2066+ far larger than the team as it includes everyone interested in
2067+ the software: the team, users, training partners, support partners,
2068+ third-party developers and so on.
2069+
2070+すばらしいコミュニティというものはオープンソースの世界では良く理解されています。
2071+しかし、その適用はオープンソースの世界を越えて広がっています。: もっとも成功している\
2072+商業ソフトウェアのベンダーは、そのフラッグシッププロダクトと共に成長するコミュニティ\
2073+を作り上げ、運営することがたくみなのです。
2074+
2075+.. Great communities are well understood in the open source world.
2076+ Their applicability extends well beyond that though: most
2077+ successful commercial software vendors are well skilled at
2078+ building and managing the communities that grow up around
2079+ their flagship products.
2080+
2081+すばらしいチームと同じように、すばらしいコミュニティも偶然できるものではありません。
2082+良いポリシーとガイドラインが、参加者同士の健全なコミュニケーションと正しい振る舞い\
2083+を育てるために不可欠です。
2084+この話題についてもっと深く知りたければ、Karl Fogelのすばらしい著書 - \
2085+`Producing Open Source Software <http://www.producingoss.com/>`_ - を見てください。
2086+
2087+.. Like great teams, great communities don't just happen.
2088+ Good policies and guidelines are essential for
2089+ fostering the right sort of behaviour and healthy
2090+ relationships between participants. For a deeper look at
2091+ this topic, see Karl Fogel's landmark book:
2092+ `Producing Open Source Software <http://www.producingoss.com/>`_.
2093+
2094+
2095+協調開発に必要なもの
2096+---------------------------------------------------
2097+
2098+コミュニティの情報とワークフローを追跡し、管理するためには、賢いツールセットが重要です。
2099+そのようなツールを、協調開発環境(Collaborative Development Environments : CDEs)と呼びます。
2100+一般的には、WEBベースでアナウンスや案件、バグを管理します。
2101+`Launchpad <https://launchpad.net>`_ 、
2102+`SourceForge <http://sourceforge.net>`_ 、
2103+`java.net <http://java.net>`_ 、
2104+`SAP Community Network <https://www.sdn.sap.com/irj/sdn>`_ などに、CDEsの例があります。
2105+
2106+.. An intelligent toolset is also important for tracking and managing
2107+ community information and workflows. These tools are called
2108+ Collaborative Development Environments (CDEs). These toolsets are
2109+ typically web-based and manage things such as announcements,
2110+ issues/bugs, questions and answers, downloads, documents and
2111+ source code. Some examples of CDEs include
2112+ `Launchpad <https://launchpad.net>`_,
2113+ `SourceForge <http://sourceforge.net>`_,
2114+ `java.net <http://java.net>`_ and
2115+ `SAP Community Network <https://www.sdn.sap.com/irj/sdn>`_.
2116+
2117+
2118+関係するコミュニティとの協調を助ける
2119+-------------------------------------------------
2120+
2121+多くの成功しているプロダクトは、その下流にそれを使うたくさんのプロダクトがあります。
2122+言いかえると、他のコミュニティとやりとりをして、自分の変更が彼らにどんな影響を与えるかを\
2123+理解することで、新しい挑戦が成功するのです。
2124+これは、以下のようなプロダクトで特に明白です。:
2125+
2126+* プログラム言語、たとえばPyhon、PHP、Ruby、Java、Perlなど
2127+* コンパイラ、たとえばgcc、JDKなど
2128+* ライブラリ、たとえばzlib、opensslなど
2129+* フレームワーク、たとえばZope、Ruby on Rails、Springなど
2130+
2131+.. XXX downstream dependenciesは、直訳だとわかりづらい気がするのでやや意訳
2132+ In other wordからの一文の訳がよくわからない
2133+
2134+.. Many successful products have a huge number of downstream dependencies.
2135+ In other words, a new challenge arises with success: dealing with other
2136+ communities and understanding how your changes will impact them. This is
2137+ most obvious for projects like:
2138+
2139+.. * software languages, e.g. Python, PHP, Ruby, Java, Perl, etc.
2140+ * compilers, e.g. gcc, JDK, etc.
2141+ * libraries, e.g. zlib, openssl, etc.
2142+ * frameworks, e.g. Zope, Ruby on Rails, Spring, etc.
2143+
2144+しかし、アドオン機能を持つメジャーなアプリケーション、たとえばFirefox、Thundervird、\
2145+OpenOffice.org、Drupal、Wordpress、Joomlaなどにも、このことはあてはまります。
2146+
2147+.. However it applies equally for popular applications on which add-ons are
2148+ built, e.g. Firefox, Thunderbird, OpenOffice.org, Drupal, Wordpress, Joomla,
2149+ etc.
2150+
2151+コミュニティの境界をこえて案件や障害修正の追跡と管理をするための作業をサポートして\
2152+くれるツールが必要です。
2153+そのようなツールは、両極端にいるどちらのユーザも助けてくれます。:
2154+
2155+* 自分のことばで問題を報告することができるユーザ。
2156+ たとえば、「オペレーションシステムX上のアプリケーションYで、Zタイプのイメージの\
2157+ レンダリングがおかしい」など
2158+
2159+* 変更や障害修正が下流のプロダクトに与える影響をよりよく評価できる開発者。
2160+ たとえば、「グラフィックライブラリのバグを修正することにより、これらの10個のOS上の\
2161+ 5つのアプリケーションに恩恵がある」など
2162+
2163+.. Tools that assist communities work together to track and manage
2164+ issues and fixes across community boundaries are required. These
2165+ tools help people at both ends of the spectrum:
2166+
2167+.. * users can report problems in their terms, e.g. rendering of image
2168+ type X is broken in application Y on operating system Z
2169+
2170+.. * developers can better appreciate the downstream impact of making a
2171+ change or fix, e.g. fixing this bug in a graphics library will
2172+ make the users of these 5 applications on these 10 operating
2173+ systems happy.
2174+
2175+その間にいる人々は、 *点線をつなぎ* 、上流と下流との間のコミュニケーションを担うという\
2176+重要な役割を果たします。
2177+多くの場合、彼らはエンドユーザのためにバグを修正したり、パッチをリリースしたり、上流の\
2178+開発チームに修正内容を提示したりします。
2179+それらすべてを持続可能な方法で常に追跡しつづけることは、簡単なことではありません。
2180+
2181+.. People in the middle play the essential role of *joining the dots* and
2182+ communicating up and down the line. In many cases, they may also fix the
2183+ problem for end users, releasing a patch and pushing a suggested fix
2184+ to the upstream development team. Keeping track of all that over time
2185+ in a sustainable way is no easy task.
2186+
2187+
2188+Launchpad: 開発をもっと効果的に、摩擦は少なく
2189+-------------------------------------------------
2190+
2191+`Ubuntu <http://www.ubuntu.com>`_ の開発に出資しているのと同じように、Canonicalは\
2192+オープンソースコミュニティ向けの無料のサービスとしてLaunchpad(https:launchpad.net)も\
2193+提供しています。
2194+Launchpadは、以下の注目すべき理由から、もっともエキサイティングなCDEsのひとつです。:
2195+
2196+* トラッキング対象のたくさんのもの同士の関係を具体化しています。
2197+ たとえば、ソースコードのブランチをバグ修正に関連づけることができます。
2198+
2199+* これまでの資産を管理するのと同じように、ロードマップ、マイルストーン、ブループリントの\
2200+ 機能によってこれからの開発の計画や追跡もできます。
2201+
2202+* 翻訳ツールやパッケージングサービスを提供することで、翻訳者やテスターがコミュニティに参加し、\
2203+ 貢献するときの抵抗を少なくしています。
2204+
2205+* 違うコミュニティ同士が、関連する案件やロードマップに対してともに作業するための結びつきを\
2206+ 提供します。
2207+
2208+.. As well as sponsoring `Ubuntu <http://www.ubuntu.com>`_ and
2209+ `Bazaar <http://bazaar-vcs.org>`_ development, Canonical
2210+ provides Launchpad, https://launchpad.net, as a free service
2211+ for the open source community. Launchpad is one of the most
2212+ exciting CDEs around for several notable reasons:
2213+
2214+.. * it models relationships between many of things tracked, e.g.
2215+ source code branches can be associated with bug fixes
2216+
2217+.. * as well are managing historical knowledge,
2218+ it supports future development planning and tracking by providing
2219+ features such as roadmaps, milestones and blueprints
2220+
2221+.. * it provides translation tools and packaging services so that
2222+ barriers are reduced for translators and testers wishing to
2223+ join your community and help out
2224+
2225+.. * it provides a nexus for different communities to work
2226+ together on related issues and roadmaps.
2227+
2228+言いかえると、Launchpadは、あなたのコミュニティの成長を助け、 *コミュニティ内* と\
2229+*コミュニティ間* との両方でワークフローの摩擦を減らすようにデザインされています。
2230+究極的には、機械的なタスクにつかう時間をなくし、興味ぶかい開発により多くの時間を\
2231+さけるようにすることを意味しています。
2232+
2233+.. In other words, Launchpad has been designed to help your
2234+ community grow and to reduce the workflow friction both
2235+ *within* your community and *between* communities. Ultimately,
2236+ that means less time on mechanical tasks and more time for
2237+ interesting development.
2238+
2239+
2240+Bazaar: Launchpadのバージョン管理クライアント
2241+---------------------------------------------
2242+
2243+このチュートリアルは、BazaarとLaunchpadがどのようにして一緒に使うことができ、\
2244+どれだけお互いを引き立てあうのかを考えます。
2245+以下のことは覚えておいてください。:
2246+
2247+1. BazaarはLaunchpadなしで使うこともできます。
2248+2. LaunchpadはBazaarなしで使うこともできます。
2249+
2250+それでも、別々に使うよりも一緒に使った方がよりパワフルになるよう設計されています。
2251+
2252+.. This tutorial looks at how Bazaar and Launchpad can be used together
2253+ and how they complement each other. It is important to remember that:
2254+
2255+.. 1. Bazaar can be used without Launchpad
2256+.. 2. Launchpad can be used without Bazaar.
2257+
2258+.. By design though, their sum is greater than the individual
2259+ parts.
2260+
2261+
2262+Finding and browsing branches using Launchpad
2263+=============================================
2264+
2265+Finding available branches
2266+--------------------------
2267+
2268+While there are many advantages in adopting distributed version
2269+control, one of the things that disappears is the all-knowing
2270+central server with knowledge about all available branches. Indeed
2271+in a distributed environment, interesting branches can literally
2272+exist in 100s of locations across the Internet (or within an
2273+Intranet for that matter).
2274+
2275+Launchpad fills this gap by providing a registry of branches.
2276+
2277+
2278+Registering branches
2279+--------------------
2280+
2281+Branches can be uploaded to Launchpad or simply registered
2282+as being available in an external location. Branches can also
2283+be given a Status such as *New*, *Development*, *Mature* or
2284+*Abandoned*.
2285+
2286+Note: External branches can even be hosted in legacy version control
2287+tools, i.e. CVS and Subversion. Code in these systems will be
2288+scanned and converted to Bazaar branches on a periodic basis.
2289+For maximum fidelity of course, it is preferable for external
2290+branches to be hosted in Bazaar.
2291+
2292+
2293+Browsing branches
2294+-----------------
2295+
2296+Branches can be listed, filtered and sorted by numerous
2297+attributes including Name, Registrant, Author, Status, Age and
2298+time of last commit. Browsing of branches is also provided making
2299+it easy to see things such as:
2300+
2301+* where the branch can be downloaded from
2302+* how to upload changes
2303+* recent commits and the changes made by each
2304+* the source code of individual files for a given version.
2305+
2306+
2307+Accessing code in Launchpad using Bazaar
2308+========================================
2309+
2310+Getting the code for an open source project
2311+-------------------------------------------
2312+
2313+As Launchpad keeps track of thousands of open source projects
2314+and their latest code whether it be managed by Bazaar, CVS or Subversion,
2315+Bazaar users can grab that code as easily as this::
2316+
2317+ bzr branch lp:project-name
2318+
2319+where `project-name` is the Launchpad project ID. Here are some examples::
2320+
2321+ bzr branch lp:inkscape
2322+ bzr branch lp:amarok
2323+ bzr branch lp:python
2324+ bzr branch lp:rails
2325+ bzr branch lp:java-gnome
2326+
2327+You can then browse the code locally using your favorite editor or IDE and
2328+change the code if you wish.
2329+
2330+If a project has multiple series registered (e.g. a development series and a
2331+maintenance series), the latest code for a given series can be fetched using::
2332+
2333+ bzr branch lp:project-name/series
2334+
2335+Publishing your changes
2336+-----------------------
2337+
2338+Having fixed that annoying bug or added that cool feature you've always
2339+wanted, it's time to impress your friends and make the world a better
2340+place by making your code available to others. As explained earlier,
2341+Launchpad is a free Bazaar code hosting service so you can push your
2342+branch to it and others can access your code from there. For example,
2343+assuming you are a member of the relevant team, login to launchpad like this::
2344+
2345+ bzr launchpad-login userid
2346+
2347+where `userid` is your Launchpad user ID.
2348+You can then push your changes to a team branch like this::
2349+
2350+ bzr push lp:~team-name/project-name/branch-name
2351+
2352+Others can then download your code like this::
2353+
2354+ bzr branch lp:~team-name/project-name/branch-name
2355+
2356+
2357+Personal branches
2358+-----------------
2359+
2360+Even if you are not a member of a team, Launchpad can be used to publish
2361+your changes. In this case, simply create a personal branch like this::
2362+
2363+ bzr push lp:~userid/project-name/branch-name
2364+
2365+Others can then download your code like this::
2366+
2367+ bzr branch lp:~userid/project-name/branch-name
2368+
2369+Note: Even when publishing to a personal branch, it is polite to notify the
2370+upstream developers about your branch so they can pull your changes from
2371+it if they are generally applicable to all users and meet the project's
2372+quality standards.
2373+
2374+
2375+Linking branches using Launchpad
2376+================================
2377+
2378+Associating a branch with a bug
2379+-------------------------------
2380+
2381+After registering a branch, you can associate it to a bug so that
2382+people interested in that bug can track and download the fix as
2383+it becomes available.
2384+
2385+To do this, the steps are:
2386+
2387+1. Navigate to the bug in question.
2388+
2389+2. Select `Add branch` under `Actions`.
2390+
2391+3. Select the branch.
2392+
2393+4. Optionally set the State of the relationship. This is
2394+ *Fix In Progress* by default but you may wish to set it
2395+ to another state such as *Fix Available* if the branch already
2396+ addresses the issue.
2397+
2398+If you wish, you can also provide some arbitrary comments about
2399+the relationship between the bug and the branch.
2400+
2401+
2402+Changing the state in Launchpad while committing in Bazaar
2403+----------------------------------------------------------
2404+
2405+Bazaar and Launchpad can work together to reduce some of
2406+the status housekeeping for you. When you commit using Bazaar,
2407+use the --fixes option like this::
2408+
2409+ bzr commit --fixes lp:1234 -m "..."
2410+
2411+where 1234 is the bug ID. This will changes the State of the
2412+bug-branch relationship to *Fix Available*. If the one commit
2413+fixes multiple issues, the --fixes option can be specified multiple
2414+times.
2415+
2416+One of the cool things about this feature is that Launchpad does
2417+not need to be accessible when making the commit. The ``--fixes``
2418+option works by storing metadata which Launchpad will detect next
2419+time the branch is pushed to it or scanned once online again.
2420+
2421+Note: Launchpad will not implicitly close a bug just because a
2422+branch is available that fixes it. There are several reasons for this.
2423+Firstly, the branch usually needs to be merged into the trunk
2424+(main development branch) before most teams consider it fixed.
2425+Secondly, many teams have a separate process for confirming
2426+bugs are fixed over and above a developer saying so.
2427+
2428+As explained later, merge control features are currently under
2429+development in Launchpad and automatically changing the status of
2430+bugs to *Fix Committed* will be more appropriate once those features
2431+are in place.
2432+
2433+
2434+Associating a branch with a blueprint
2435+-------------------------------------
2436+
2437+After registering a branch, you can associate it to a blueprint so that
2438+people interested in that blueprint can track and test the feature as
2439+it develops.
2440+
2441+To do this, the steps are:
2442+
2443+1. Navigate to the blueprint in question.
2444+
2445+2. Select `Link branch` under `Actions`.
2446+
2447+3. Select the branch.
2448+
2449+If you wish, you can also provide some arbitrary comments about
2450+the relationship between the blueprint and the branch.
2451+
2452+
2453+Managing releases using Launchpad
2454+=================================
2455+
2456+Integrating changes
2457+-------------------
2458+
2459+Once a branch has been developed and published, communities
2460+typically go through a rigorous process before those changes
2461+are integrated into the core product and rolled out to end users.
2462+Some of the steps involved may include:
2463+
2464+* peer review of the changes
2465+
2466+* deciding which releases to include the changes in, e.g. the
2467+ next maintenance release, the next major release, or both
2468+
2469+* running functional regression tests
2470+
2471+* benchmarking to ensure performance remains acceptable
2472+
2473+* packaging into early access releases for end user testing
2474+
2475+* documentation updates, e.g. Release Notes for the targeted
2476+ releases
2477+
2478+* translation of the user interface and documentation into
2479+ multiple languages.
2480+
2481+This section briefly looks at some of the features in Launchpad that
2482+help get good quality code into production. Strong integration with
2483+Bazaar is core to making this happen smoothly.
2484+
2485+Note: Where indicated, some of the features below are still under
2486+development. If one or more of these features interest you, please
2487+consider joining the Launchpad beta test team at this link:
2488+https://help.launchpad.net/JoiningLaunchpadBetaTesters. You can
2489+then get early access to features and provide feedback to the
2490+developers before wider roll-out.
2491+
2492+
2493+Branch merge proposals
2494+----------------------
2495+
2496+After navigating to a branch in Launchpad, one of the available actions
2497+is *Propose for merging*. This lets you nominate which branch this code
2498+ought to be merged into.
2499+
2500+Tracking the knowledge about which branches are proposed to be merged
2501+into a codeline helps Release Managers keep on top of what still needs
2502+to be completed, or can be completed, before a ship date. Using this
2503+information, they can ensure branches are merged after completing any
2504+necessary reviews. In the simple case, the Release Manager may manually
2505+merge branches. In more advanced cases, the merging could be automatically
2506+done by a robot (like `PQM`_) when the branch reaches the right state
2507+(e.g. *Review completed*).
2508+
2509+.. _PQM: https://launchpad.net/pqm
2510+
2511+
2512+Code review tracking
2513+--------------------
2514+
2515+A number of features are under development in Launchpad to track the
2516+states, conversations and outcomes of code reviews. These features are
2517+expected to be integrated with branch merge proposals and branch
2518+browsing features.
2519+
2520+
2521+Personal Package Archives (PPAs)
2522+--------------------------------
2523+
2524+PPAs help developers and development teams get custom builds into the
2525+hands of users for early testing and feedback. In other words, a PPA
2526+allows a developer to form a community of testers who are interested
2527+in their changes. The testing community can install the packages,
2528+run them for the test period and then remove them cleanly from their
2529+system.
2530+
2531+See https://help.launchpad.net/PPAQuickStart for further details.
2532+
2533+
2534+Translations
2535+------------
2536+
2537+The Translations module in Launchpad is designed to make it easy for
2538+anyone to get involved translating applications to languages they know.
2539+Translators are shielded from the low level details.
2540+
2541+Launchpad keeps track of the translations for each major version of a
2542+project separately, allowing translators to continue to improve the
2543+translations of your stable releases while others start work on newer
2544+versions that are still in development. Translation speed in reduced
2545+by sharing resources across projects. Automatic suggestions, from a
2546+library of 750,000 translated strings, and a community of 19,000
2547+registered translators can radically cut the time required to
2548+localise your project into many languages.
2549+
2550+
2551+Summary
2552+=======
2553+
2554+The communities we join, whether off-line or on-line,
2555+say a lot about the sort of people we are. The flip-side
2556+to this is that the tools you choose for your community - particularly
2557+the CDE and version control tool - can have a large impact on who
2558+joins and how easily they can contribute.
2559+
2560+In their own right, Launchpad and Bazaar are highly useful tools.
2561+Together, they can:
2562+
2563+* help your community track major assets such as source code and knowledge
2564+* help it grow by reducing barriers to entry
2565+* help it interact with related communities.
2566+
2567+In particular, Launchpad is a free code hosting service for your Bazaar
2568+branches, branches can be browsed online, branches can be linked to bugs
2569+and blueprints, and the status of bug-branch relationships can be
2570+automatically managed by mentioning the bug while committing in Bazaar.
2571+Further integration is under development with the aim of streamlining
2572+the process from *great idea* to *running code in the hands of end users*.
2573+
2574+If you have any feedback on how you'd like to see Bazaar and Launchpad
2575+further integrated, please contact us on the Bazaar mailing list,
2576+bazaar@lists.canonical.com.
2577+
2578+While designed as a free service to support open source projects,
2579+Canonical may make Launchpad available to commercial software developers
2580+depending on their requirements. We would be happy to hear from you
2581+if you think Launchpad would be useful for managing your community,
2582+open source or otherwise.
2583
2584=== added directory 'doc/ja/upgrade-guide'
2585=== added file 'doc/ja/upgrade-guide/data_migration.txt'
2586--- doc/ja/upgrade-guide/data_migration.txt 1970-01-01 00:00:00 +0000
2587+++ doc/ja/upgrade-guide/data_migration.txt 2009-10-29 17:00:30 +0000
2588@@ -0,0 +1,130 @@
2589+データ移行
2590+###############
2591+
2592+データ移行の準備
2593+-------------------
2594+
2595+移行を開始する前に、最初におこなうべきことがあります。
2596+
2597+1. 完全にバックアップをとってください。
2598+
2599+2. 古いブランチを消去(purge)する時間をとってください。
2600+
2601+完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。
2602+
2603+古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを
2604+`Finding obsolete branches`_　でご覧ください。
2605+
2606+移行に関連するコマンドの紹介
2607+----------------------------------
2608+
2609+データ移行時には注意すべき3つの重要なコマンドがあります。
2610+
2611+* **check** - リポジトリ、ブランチやツリーのデータ完全性に関するエラーのチェック。
2612+
2613+* **reconcile** - データ完全性に関するエラーの修復。
2614+
2615+* **upgrade** - 異なるデータフォーマットへの移行。
2616+
2617+**reconcile** はめったに必要ではありませんが **check** を **upgrade** の前後で行うことは良い習慣です。
2618+
2619+これらのコマンドの詳細なヘルプは `Bazaarユーザーリファレンス`_ をごらんください。
2620+
2621+.. _Bazaarユーザーリファレンス: ../user-reference/index.html
2622+
2623+
2624+あなたのコミュニティとのコミュニケーション
2625+---------------------------------------------------------
2626+
2627+新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:
2628+
2629+1. trunkの移行を行う責任者を1人きめること。
2630+
2631+2. trunkの移行試験が成功すること。
2632+
2633+3. trunkを移行する時間の予定をたてることと、前もってあなたのコミュニティに知らせておくこと。
2634+
2635+事前に警告をしておくことによりコミュニティに所属する人々が 移行日より前に Bazaarや必要なpluginを移行するのに十分な余裕を持つことができるでしょう。
2636+
2637+さらに大きなコミュニティにおいては、移行それ自身に要する時間に配慮しましょう。
2638+試験移行の後でどのくらい移行に時間がかかるのかに関する良い案を持っておくべきです。移行を週末か金曜日に行うことで問題が発生したときにあなた自身が一息つける時間をとることができることは道理にかなっているでしょう。
2639+
2640+trunkが移行したら、あなたはコミュニティに対して適切にお知らせし、彼らに彼ら自身のローカルブランチの移行説明書を示す必要があります。後ほど説明書の例を示します。
2641+
2642+
2643+スタンドアロンブランチの移行
2644+------------------------------------
2645+
2646+作業手順は以下のとおりです。:
2647+
2648+1. **bzr check** を起動します。
2649+
2650+2. もしエラーが発生したら、**bzr reconcile** を使ってエラーの修復をこころみてください。もしこれが失敗したら問題を解決してあなたのtrunkをクリーンにするために私たちがお手伝いできるようバグの報告ください。もし成功したならクリーンなtrunkなうちにバックアップをとってください。
2651+
2652+3. **bzr upgrade --format** を実行してください。**format** は 2a またはそれ以降のことです。
2653+
2654+4. **bzr check** を起動して最終結果が正しいかどうかを確認してください。
2655+
2656+
2657+共用リポジトリ中のブランチを移行
2658+-----------------------------------------
2659+
2660+移行は以下の手順で行ってください:
2661+
2662+1. 共用リポジトリの移行。
2663+
2664+2. ブランチの移行。
2665+
2666+3. 軽量チェックアウトの移行。
2667+
2668+スタンドアロンブランチの例のように **check** を移行の前後に行って問題が存在していないか、あるいは問題がひきおこされていないかを確認してください。
2669+
2670+
2671+Launchpad上のブランチを移行
2672+-------------------------------
2673+
2674+公開ブランチとプライベートブランチを独立させるために、Launchpadでは共用リポジトリではなく、スタックブランチをディスク容量の効率化の中心技術として使用しています。したがってLaunchpadをコードホスティングに使用しているプロジェクトでは新しいフォーマットへの移行は個人や社内でしようしているとはことなります。
2675+
2676+手順は次のようになります:
2677+
2678+1. 指名された人がtrunkのコピーを持ち移行作業を実施します。
2679+
2680+2. Launchpadにおいては 現在のtrunkを開発の中心(focus)からはずします。(これは *必ず* 実施してください、そうしないとこの後の手順が期待通りになりません。)
2681+
2682+3. 移行した trunk をLaunchpadに push します。
2683+
2684+4. 開発の中心(focus)に設定します。
2685+
2686+5. 古い trunk に登録しているユーザに対して新しい trunk へ登録するよう依頼します。
2687+
2688+つまり、これらの手順の意味は　古い trunk がいぜんとして有効でスタックされたブランチが存在し続けるということです。しかしながら開発の中心は移行後の trunk に切り替わっており、以後のLaunchpadにpushされるあなたのプロジェクトの新しいブランチは(移行後のtrunkに)スタックされます。
2689+
2690+この時点であなたはあなたのコミュニティに対して 新しいtrunkが有効になったことを知らせ、彼らに彼らのローカルブランチを移行する説明する準備ができました。
2691+
2692+
2693+中央の trunk が移行した後のローカルブランチ移行
2694+-----------------------------------------------------------
2695+
2696+スタンドアロンブランチの移行手順:
2697+
2698+1. 中央リポジトリの場所から最新のブランチを新しいディレクトリに取得します。
2699+
2700+2. 既存のブランチの中のあなたが行った修正を新しいブランチへpullあるいはmergeします。
2701+
2702+ブランチを共用リポジトリに移行する手順:
2703+
2704+1. 新しい共用リポジトリを新フォーマット(2aあるいはそれ以降)で作成します。
2705+
2706+2. 中央リポジトリから最新のブランチを作成した共用リポジトリへ格納します。
2707+
2708+3. あなたのローカルブランチで移行したいものを決定します。(もし決定していなければ、もちろんバックアップした後、 `Finding obsolete branches`_　してそのブランチを消去するのによい時間です。)
2709+
2710+4. 各ローカルブランチの移行に関して2つ選択肢があります。
2711+
2712+ * 新しいリポジトリで1つ空のブランチを **init** して古いリポジトリからリビジョンを **pull** する。
2713+
2714+ * 新リポジトリにおいて、 trunkから新しいブランチに **branch** した後古いリポジトリにおいてあなたが行った変更を **merge** する。
2715+
2716+前者の方法は(リビジョンの履歴という意味において)古いブランチと同一のブランチを得ることができる一方、parentブランチは古いブランチを指してしまい、新しいtrunkをさしません。もしあなたがこの方法をとった場合、おそらく branch.conf ファイルの parentブランチに関する設定をしなおしたくなるでしょう。
2717+
2718+それに比較して後者の方法は parentブランチは正確に設定されます。しかし、もしあなたがすべての最新のリビジョンをtrunkからそのブランチにincludeする用意ができていない限り理想的な方法にはなりません。
2719
2720=== added file 'doc/ja/upgrade-guide/index.txt'
2721--- doc/ja/upgrade-guide/index.txt 1970-01-01 00:00:00 +0000
2722+++ doc/ja/upgrade-guide/index.txt 2009-10-29 17:00:30 +0000
2723@@ -0,0 +1,13 @@
2724+###########################
2725+Bazaar 2.0 移行ガイド
2726+###########################
2727+
2728+.. Please mark sections in included files as following:
2729+.. level 1 ========
2730+.. level 2 --------
2731+.. level 3 ~~~~~~~~
2732+.. level 4 ^^^^^^^^ (it is better not to use nesting deeper than 3 levels)
2733+
2734+.. include:: overview.txt
2735+.. include:: data_migration.txt
2736+.. include:: tips_and_tricks.txt
2737
2738=== added file 'doc/ja/upgrade-guide/overview.txt'
2739--- doc/ja/upgrade-guide/overview.txt 1970-01-01 00:00:00 +0000
2740+++ doc/ja/upgrade-guide/overview.txt 2009-10-29 17:00:30 +0000
2741@@ -0,0 +1,77 @@
2742+概要
2743+########
2744+
2745+移行手順の概要
2746+----------------
2747+
2748+Bazaar 2.xへのアップグレード作業は3段階あります:
2749+
2750+1. コアソフトウェアの移行
2751+
2752+2. 必要なプラグインの移行
2753+
2754+3. 新しいデフォルトフォーマットへのデータ移行
2755+
2756+Bazaar 2.xは以前のブランチのフォーマットをサポートしているので、厳密には3番目の手順は
2757+必要ありません。しかし、Bazaar 2.xの新しいデフォルトフォーマットはより効率よく領域を使用する、
2758+巨大なプロジェクトでより高速になる、さまざまな新しい特徴をそなえている、などの理由からほとんどのプロジェクトについて都合のよいときにでもアップグレードすることをおすすめします。
2759+
2760+ほとんどのユーザの方は2.xへのアップグレードと新しいフォーマットへの移行に苦労しません。
2761+しかしながら、大勢の開発者がいる(もしくは多くの開発者をようする)プロジェクトでは移行作業に手間がかかります。
2762+この場合、注意深く計画をたてることとよいコミュニケーションが必要不可欠となります。
2763+本文書はこの視点からの一般的なアドバイスを記載しています。
2764+不安な点がありましたら、メーリングリストやIRCチャンネルで私たちにおたずねください。
2765+
2766+
2767+コアソフトウェアの移行
2768+-----------------------
2769+
2770+コアソフトウェアの移行手順はオペレーティングシステムによって異なります。
2771+Bazaar 1.xからBazaar 1.yへの移行とBazaar 1.xからBazaar 2.0への移行には特に違いはありません。手順の概要は以下のようになります。
2772+
2773+Linuxでの移行手順:
2774+
2775+1. 必要なソフトウェアのソースに関してお使いのパッケージマネージャの設定をおこなう。
2776+ たとえばUbuntuの正式なリリースのPPAは https://launchpad.net/~bzr/+archive です。
2777+
2778+2. パッケージマネージャを使用して最新バージョンに移行する。
2779+
2780+Windowsでの移行手順:
2781+
2782+1. 「プログラムの追加と削除」で古いバージョンを削除する。
2783+
2784+2. 新しいバージョンのインストーラでインストールする。
2785+
2786+OS Xでの移行手順(インストーラを使用):
2787+
2788+1. 新しいバージョンのインストーラでインストールする。
2789+
2790+OS Xでの移行手順 (MacPortを使用):
2791+
2792+1. package metadataを更新する。 **sudo port selfupdate**
2793+
2794+2. 最新のバージョンに更新する。 **sudo port upgrade bzr**
2795+
2796+インストールや移行に関する詳しい情報については http://bazaar-vcs.org/Download
2797+をごらんください。
2798+
2799+必要なプラグインの移行
2800+-----------------------
2801+
2802+多くのプラグインは特定のBazaarのバージョンに依存していないので、任意の作業です。
2803+他のプラグイン、特にbzrtoolsとbzr-svnはBazaarのAPIにかたく結びついているので、
2804+大体はコアソフトウェアとあわせて移行する必要があります。
2805+
2806+WindowsやOS Xをお使いのかたは、bzrtoolsとbzr-svnはインストーラに付属していますので
2807+移行にあたって特別な作業は必要ありません。LinuxやUNIXをお使いのかたは、bzrtools、bzr-svn
2808+や他の著名なプラグインをインストールしたり移行作業をお使いのプラットホームのパッケージマネージャ
2809+(たとえばUbuntuのSynaptic)でおこなうことができます。
2810+
2811+
2812+新しいデフォルトフォーマットへのデータ移行
2813+-------------------------------------------
2814+
2815+冒頭でも説明しましたように新しいフォーマットへの移行に伴う複雑さはいくつかの要因、特にプロジェクトの
2816+コミュニティの大きさに依存します。また、データがどのように保存されているかにも依存します。たとえば
2817+standaloneブランチとか、複数のブランチがshared repositoryに格納されているかとか、Launchpad上の
2818+stackedブランチかなどです。これらのシナリオについては次章で説明します。
2819
2820=== added file 'doc/ja/upgrade-guide/tips_and_tricks.txt'
2821--- doc/ja/upgrade-guide/tips_and_tricks.txt 1970-01-01 00:00:00 +0000
2822+++ doc/ja/upgrade-guide/tips_and_tricks.txt 2009-10-29 17:00:30 +0000
2823@@ -0,0 +1,23 @@
2824+役立つヒントとコツ
2825+######################
2826+
2827+古いブランチを見つけるには
2828+-----------------------------
2829+
2830+もしあなたが開発における各変更や個々に行っている拡張のためにブランチの機能を使っている場合、いくつかのもう必要とされないブランチを持つことになるかもしれません。たいていの場合、関係のある変更は trunkにマージされているはずです。そのほかの場合ブランチは自分あるいは他人が行った別の変更の結果、古くなっているはずです。
2831+
2832+古いブランチをチェックするときには特に3つの点に注意があります。
2833+
2834+1. ワーキングツリーは変更の途中でないこと。
2835+
2836+2. ワーキングツリー内にはbzr shelveコマンドによって退避された変更をふくんでいないこと。
2837+
2838+3. どんなローカルでコミットされたリビジョンもparentブランチにマージされていること。
2839+
2840+ブランチのルートディレクトリに移動したあと、これらの点を個々にチェックするためのコマンドは以下です::
2841+
2842+ bzr status
2843+ bzr shelve --list
2844+ bzr missing --mine-only
2845+
2846+もしあなたのブランチがローカルの共用リポジトリに入っているならば、(revision 159またはそれ以降の)Bazaar Explorerのリポジトリビューの中の *Local Changed* タブがあなたが選択したブランチについて、いまのところはshelveコマンドによって退避された変更を除き、上記の情報の概要を表示するので有用です。
2847
2848=== added directory 'doc/ja/user-guide'
2849=== added file 'doc/ja/user-guide/adv_merging.txt'
2850--- doc/ja/user-guide/adv_merging.txt 1970-01-01 00:00:00 +0000
2851+++ doc/ja/user-guide/adv_merging.txt 2009-10-29 17:00:30 +0000
2852@@ -0,0 +1,105 @@
2853+疑似マージ
2854+===========
2855+
2856+チェリーピッキング
2857+------------------
2858+
2859+時々、ブランチの変更の全部ではなく一部だけを選んでマージすることが\
2860+便利であることがあります。
2861+これは一般的に *チェリーピッキング(cherrypicking)* として言及されます。
2862+
2863+チェリーピッキングが役に立ついくつかの事例:
2864+
2865+* メインの開発ブランチから修正の一部を取り出してリリースブランチに取り込む
2866+
2867+* 実験ブランチから改善内容を選別して機能ブランチに取り込む
2868+
2869+``foo`` ブランチのリビジョン Xによってなされた変更のみをマージするためには::
2870+
2871+ bzr merge -c X foo
2872+
2873+``foo`` ブランチのリビジョンXまでの変更のみをマージするためには::
2874+
2875+ bzr merge -r X foo
2876+
2877+``foo`` のリビジョンX以降の変更のみをマージするためには::
2878+
2879+ bzr merge -r X.. foo
2880+
2881+``foo`` ブランチのリビジョンXからリビジョンYまでの変更のみをマージするには::
2882+
2883+ bzr merge -r X..Y foo
2884+
2885+通常のマージと同じように、チェリーピックは明示的にコミットしなければなりません。
2886+これを行う前に、 ``bzr diff`` を利用した変更を見て何かあればテストスイートを\
2887+実行するとよいでしょう。
2888+
2889+通常のマージとは異なり、Bazaarは現在はチェリーピックを追跡しません。
2890+具体的に言うと、変更は通常のコミットと同じようになり、他のブランチから来た(内部の)変更履歴は失われます。
2891+上記のようなチェリーピックが役に立つ場面では、このことはたいてい重大な問題ではありません。
2892+フルマージが後で行われることはけっしてないと言える十分な理由があるからです。
2893+そうではない場面では、変更が再びマージされたときにまた衝突を解消する必要があります。
2894+
2895+.. _reverse-cherrypicking:
2896+
2897+リバースチェリーピッキング
2898+---------------------------
2899+
2900+チェリーピッキングは一連の変更を元に戻すことができます。この場合、リビジョン範囲の\
2901+上界(upper bound)が下界(lower bound)よりも *小さく* なります。
2902+たとえば、リビジョン10の変更を取り消すためのコマンドはこうなります::
2903+
2904+ bzr merge -r 10..9
2905+
2906+どこかから、すべてではない大半の変更を得たい場合通常のマージをした後に少しの\
2907+リバースチェリーピックを行うとよいでしょう。
2908+
2909+
2910+コミットされていない変更をマージする
2911+-------------------------------------
2912+
2913+複数のブランチを持っており、間違えて別のブランチを変更し始めた場合、訂正をとるステップは次のとおりです。
2914+ブランチ ``bar`` で作業したかったのに、ブランチ ``foo`` で作業を始めてしまったという場合を前提とします:
2915+
2916+1. ``bar`` ブランチに移動する
2917+2. ``bzr merge --uncommitted foo`` を実行する
2918+3. やってくる変更をチェックする (``bzr diff``)
2919+4. ``foo`` ブランチに変更する
2920+5. ``bzr revert`` を実行する
2921+
2922+.. TODO Selective file merging?
2923+
2924+
2925+リベースする
2926+--------------
2927+
2928+通常のマージの別のオプションは *リベース(rebase)* です。
2929+すなわち、現在のブランチが本来とは異なる地点をベースにするようにします。
2930+リベースは ``rebase`` プラグインによって提供される ``rebase`` コマンド\
2931+によってサポートされます。
2932+
2933+``rebase`` コマンドは現在の作業ディレクトリ内のリベースされるブランチ上で\
2934+別のブランチの位置をとります。
2935+ブランチが指定されないと親のブランチが使われ、通常これは望まれる結果です。
2936+
2937+最初のステップは現在のブランチのものであるが親のブランチではないリビジョンを\
2938+特定することです。
2939+現在のブランチはターゲットブランチと同じリビジョンに設定され、それぞれの\
2940+リビジョンはブランチのトップで再現されます。
2941+プロセスの終了時に現在のブランチがターゲットの最終リビジョンからブランチ\
2942+されたようになります。
2943+
2944+再現されるそれぞれのリビジョンがツリーの中で衝突を起こすことがあります。
2945+これが起きたらコマンドは停止してそれらを修正しなければなりません。
2946+``merge`` するためにコミットを解消し、それらが解消されたものとしてマークするために
2947+``bzr resolve`` を実行します。
2948+すべての衝突を解消したら、リベースオペレーションを続けるために ``bzr rebase-continue``
2949+を実行します。
2950+衝突に遭遇せず続けないことを決めたら、 ``bzr rebase-abort`` を実行できます。
2951+リプレイされるコミットの一覧を表示するために ``rebase-todo`` を利用することもできます。
2952+
2953+注: マージトラッキング機能が貧弱なVCSツールから来たユーザーの中にはリベースを好む人がいます。
2954+古いツールでの作業方法に似ている、もしくは"完璧にきれいな" 履歴が重要だからです。
2955+Bazaarでリベースする前に、通常のマージがベターな選択肢ではないのか考えてください。
2956+とりわけ、始める前にプライベートなブランチをリベースするのは大丈夫ですが、
2957+他の誰かとブランチを共有した後のリベースは **強く非推奨** です。
2958
2959=== added file 'doc/ja/user-guide/annotating_changes.txt'
2960--- doc/ja/user-guide/annotating_changes.txt 1970-01-01 00:00:00 +0000
2961+++ doc/ja/user-guide/annotating_changes.txt 2009-10-29 17:00:30 +0000
2962@@ -0,0 +1,34 @@
2963+変更に注釈を付ける
2964+===================
2965+
2966+内容の起源を探し出す
2967+--------------------
2968+
2969+複数の人がファイルに取り組むとき、
2970+誰が作ったのかもしくは最後に変更された内容を一度に見ることができるのは非常に便利です。
2971+これを行うためには、annotateコマンドを使います::
2972+
2973+ bzr annotate readme.txt
2974+
2975+悲観主義者もしくは楽観主義者のどちらかであるなら、
2976+``annotate`` の組み込みのエイリアスである ``blame`` もしくは ``praise``
2977+を使うことを好むかもしれません。
2978+どの方法であれ、次のような情報と一緒にファイルのそれぞれの行が表示されます:
2979+
2980+ * 最後に変更した人
2981+ * 最後に変更した時間
2982+ * コミットメッセージ
2983+
2984+GUIツール
2985+----------
2986+
2987+Bazaar用のさまざまなGUIは注釈の情報を閲覧するためのグラフィカルなツールを提供します。
2988+たとえば、bzr-gtkプラグインはこの機能を ``gannotate`` コマンドを使用して起動できる\
2989+GUIツールとして提供します::
2990+
2991+ bzr gannotate readme.txt
2992+
2993+GUIツールは関心のある情報をより豊かに表現するので
2994+(たとえばそれぞれのコミットのすべての変更内容)、\
2995+テキストベースよりも好ましいかもしれません。
2996+
2997
2998=== added file 'doc/ja/user-guide/bazaar_workflows.txt'
2999--- doc/ja/user-guide/bazaar_workflows.txt 1970-01-01 00:00:00 +0000
3000+++ doc/ja/user-guide/bazaar_workflows.txt 2009-10-29 17:00:30 +0000
3001@@ -0,0 +1,181 @@
3002+ワークフロー
3003+=============
3004+
3005+Bazaarはただのツール
3006+---------------------
3007+
3008+Bazaarは多くの異なる共同作業の方法を支援します。
3009+このことはあるワークフローで始めて状況が変われば別のワークフローを\
3010+採用できることを意味します。
3011+"唯一の正しい方法"は存在しませんし今後も現れることはりません。
3012+このセクションではBazaarによってサポートされる人気のあるいくつかの\
3013+ワークフローの手短な概要を提供します。
3014+
3015+これらのワークフローはBazaarの使い方の *一部* であることを念頭にお願いします。
3016+ここに記載されていないワークフローを利用したいのであれば、\
3017+下記に記載されているアイディアを足場にします。
3018+
3019+ソロ
3020+----
3021+
3022+ソフトウェアを開発する、ドキュメントを編集するもしくは設定ファイルを\
3023+変更するのであれ、簡単に使えるVCSは手助けになります。
3024+投稿者が1人であるプロジェクトを複数管理するために\
3025+単独のユーザーはこのワークフローを効率的に利用できます。
3026+
3027+.. image:: images/workflows_single.png
3028+
3029+まったくバージョン管理を使わない場合と比べたこのワークフローの利点は次のとおりです:
3030+
3031+ * 古いバージョンのバックアップ
3032+ * 前の状態へのロールバック
3033+ * 履歴の追跡
3034+
3035+このワークフローに適切なBazaarの主要な機能は管理作業が少ない\
3036+(サーバーのセットアップは不要)ことと簡単に利用できることです。
3037+
3038+
3039+パートナー
3040+-----------
3041+
3042+時に2人で変更を共有して共同作業をする必要があります。
3043+これは一般的に *ソロ* のワークフロー (上記を参照) もしくは\
3044+チーム指向のワークフロー(下記を参照)として始まります。
3045+ある時点で、2人目の人が最初の人が行った内容(履歴も含む)を含む\
3046+ブランチを作ります。
3047+適切なときにマージして変更内容を交換することで並行して作業できます。
3048+
3049+.. image:: images/workflows_peer.png
3050+
3051+*ソロ* を上回る利点は次のとおりです:
3052+
3053+ * 変更の共有が簡単
3054+ * それぞれのテキストファイルのそれぞれの行は変更した人、\
3055+ 時間と理由を含む特定の変更と結びつけられています。
3056+
3057+このワークフローを採用する場合、BazaarはCVSとSubversionに対して
3058+次のような利点があります:
3059+
3060+ * サーバーのセットアップが不要
3061+ * インテリジェントなマージ機能により複数回のマージ作業が苦痛では
3062+ なくなります。
3063+
3064+
3065+集中型
3066+-------
3067+
3068+*lock-step* としても知られますが、これはCVSとSubversionによって\
3069+推奨/強制されるワークフローと本質的に同じです。
3070+すべての開発者が同じブランチに取り組みます。
3071+最新の内容をチェックアウトするために ``bzr update`` を実行し、\
3072+変更内容を中心位置にコミットするために ``bzr commit`` を実行します。
3073+
3074+.. image:: images/workflows_centralized.png
3075+
3076+このワークフローを導入するのであればSubversionとCVSも簡単なのでよい選択肢です。
3077+Bazaarはこのワークフローも直接サポートしていて、CVSとSubversionを上回る利点を\
3078+いくつかもちます:
3079+
3080+ * よりよいブランチとマージ
3081+ * よりよいリネームのサポート
3082+
3083+
3084+ローカルなコミットで集中型
3085+---------------------------
3086+
3087+このワークフローは、開発者が ``commit --local`` もしくはチェックアウトをunbind\
3088+して一連の変更を行うこと以外は、 *集中型* モデルと基本的に同じです。
3089+こういった一連の変更が完了するとき、開発者は作業内容を共用のメインラインに\
3090+コミットします。
3091+
3092+.. image:: images/workflows_localcommit.png
3093+
3094+*集中型* を越える利点:
3095+
3096+ * 旅行の間にネットに接続していないなどのオフラインで作業できます
3097+ * 誰かの作業を妨げる良くないコミットをする機会が少なくなります
3098+
3099+SubversionとCVSはこのモデルをサポートしません。
3100+他の分散型VCSツールはこれをサポートしますが、Bazaarよりも直接的ではありません。
3101+
3102+
3103+共用のメインラインで分散型
3104+-----------------------------
3105+
3106+このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
3107+加えてメインブランチにコミットする権限があります。
3108+開発者は個人のブランチに取り組み、準備ができたらそれをメインラインに\
3109+マージします。
3110+
3111+.. image:: images/workflows_shared.png
3112+
3113+*ローカルコミットつきの集中型* を越える利点は次のとおりです:
3114+
3115+ * 作業内容の編成が簡単になる - それぞれのブランチで個別の変更を開発できます。
3116+ * 開発者は共同作業に取り組むときに別の人の個人ブランチをマージできます。
3117+
3118+SubversionとCVSはこのモデルをサポートしません。\
3119+他の分散型VCSツールはサポートします。
3120+Bazaarの多くの機能は、簡単な利用、共用レポジトリ、統合されたマージ機能と\
3121+リッチなメタデータ(ディレクトリのリネームの追跡を含む)を\
3122+含めてこのワークフローに有効です。
3123+
3124+人間のゲートキーパーで分散型
3125+-----------------------------
3126+
3127+このワークフローにおいて、それぞれの開発者は独自のブランチを持ち、\
3128+それに加えてメインのブランチに対してリードオンリーのアクセス権限を持ちます。
3129+1人の開発者(ゲートキーパー)はメインのブランチにコミットする権限を持ちます。
3130+1人の開発者が彼らの作業をマージしたい場合、ゲートキーパーに\
3131+マージしてくれるように頼みます。
3132+ゲートキーパーはコードのレビューを行い、必須の基準を満たすのであれば\
3133+作業内容をメインブランチにマージします。
3134+
3135+.. image:: images/workflows_gatekeeper.png
3136+
3137+*共用のメインラインによる分散型* に対する利点は次のとおりです:
3138+
3139+ * 常にコードはメインラインに入る前にレビューされます。
3140+ * 変更をメインラインに組み込むときに厳格なコントロールができます
3141+
3142+Bundle Buggyと呼ばれるBazaarのコンパニオンツールはどんな変更が\
3143+レビュー待ちになっているのか、その変更のステータスとレビューアの\
3144+コメントを追跡するのにとても便利です。
3145+
3146+
3147+自動的なゲートキーパーで分散型
3148+-------------------------------
3149+
3150+このワークフローにおいて、それぞれの開発者は独自のブランチを持つのに加えて、\
3151+メインストリームにリードオンリーのアクセス権限を持ちます。
3152+ソフトウエアのゲートキーパーはメインのブランチにコミットする権限を持ちます。
3153+開発者が作業内容をマージしたいとき、開発者は別の人にレビューを頼みます。
3154+レビューに合格したら、チームの方針によって、オリジナルの著者もしくは
3155+レビューワがゲートキーパーソフトウェアにマージするように頼み、
3156+ゲートキーパーソフトウェアはマージし、コンパイルし、テストスィートを実行します。コードがパスする場合のみ、メインラインにマージされます。
3157+
3158+注: 代替として、レビューのステップをスキップして著者は変更を自動化された\
3159+ゲートキーパーに投稿できます。
3160+(これはコードのレビューを別のステップとしてではなくジャストインタイムの\
3161+レビューを効果的に推進するペアプログラミングといった習慣を利用している\
3162+ときにとりわけ適切です。)
3163+
3164+.. image:: images/workflows_pqm.png
3165+
3166+*人間のゲートキーパーによる分散型* に対する利点は次のとおりです:
3167+
3168+ * コードはメインラインに入る前に常にテストされます
3169+ (メインラインの完全性が高まります)
3170+ * チームの規模の成長に対応できます
3171+
3172+BazaarのコンパニオンツールであるPatch Queue Manager (PQM)
3173+は自動化ゲートキーパーの機能を提供します。
3174+
3175+
3176+ワークフローを実施する
3177+-----------------------
3178+
3179+上記のそれぞれのワークフローを実施する方法を詳しく知りたいのであれば、\
3180+このマニュアルの3章から6章までを参照してください。最初に、2章で、\
3181+インストール方法、一般的な使い方の手引きと設定方法に関するティップス\
3182+が説明されています。
3183
3184=== added file 'doc/ja/user-guide/branching_a_project.txt'
3185--- doc/ja/user-guide/branching_a_project.txt 1970-01-01 00:00:00 +0000
3186+++ doc/ja/user-guide/branching_a_project.txt 2009-10-29 17:00:30 +0000
3187@@ -0,0 +1,100 @@
3188+プロジェクトをブランチする
3189+===========================
3190+
3191+ブランチのURL
3192+--------------
3193+
3194+誰かがあなたの作品のコピーを手に入れる前に、転送プロトコルを理解する必要があります。
3195+ブランチのトップレベルのディレクトリを、Windowsユーザーが慣れ親しんだ方法で、\
3196+ネットワーク上で共有することを決定するとします。
3197+LinuxとOS Xのユーザーは、大抵のSSHサーバーに組み込まれているセキュアなプロトコルである、\
3198+SFTPを通してアクセスする方が望ましいです。
3199+Bazaarは下記で一部が示されるたくさんのプロトコルのサポートに関して *とても* 柔軟です。
3200+
3201+ =========== ==========================================================================
3202+ スキーム 説明
3203+ =========== ==========================================================================
3204+ file:// 標準ファイルシステムを利用してアクセスする (デフォルト)
3205+ sftp:// SFTPを利用してアクセスする (大抵のSSHサーバーはSFTPを提供する)
3206+ bzr:// Bazaarのスマートサーバーを利用した高速のアクセス
3207+ ftp:// パッシブFTPを利用してアクセスする
3208+ http:// ウェブサーバーによってエクスポートされたブランチへの読み込み限定のアクセス
3209+ =========== ==========================================================================
3210+
3211+上記で示されるように、ブランチは転送プロトコルを示すスキームを伴うURLを使用して識別されます。
3212+スキームが無ければ、通常のファイルの名前が想定されます。
3213+サポートされるプロトコルの完全なリストに関しては、
3214+``urlspec`` のオンライントピックもしくはBazaarのユーザーリファレンスの
3215+`URLの識別子 <../user-reference/bzr_man.html#url-identifiers>`_
3216+のセクションを参照してください。
3217+
3218+.. _a-reminder-about-shared-repositories:
3219+
3220+共用レポジトリに関するリマインダ
3221+---------------------------------
3222+
3223+ブランチのコピーを手に入れる前に、ファイルシステム上に設置する場所を少し考えて\
3224+みましょう。
3225+最大限のストレージの効率性のために、共用リポジトリとしてセットアップされた\
3226+ディレクトリの元でブランチを作ることを推奨します。
3227+(よく使われるレイアウトについては、 `作業スペースを構成する
3228+<organizing_your_workspace.html>`_ の中の `ブランチの機能
3229+<organizing_your_workspace.html#feature-branches>`_
3230+を参照してください)
3231+たとえば::
3232+
3233+ bzr init-repo my-repo
3234+ cd my-repo
3235+
3236+誰からでもブランチを入手して好きなようにする準備ができました。
3237+
3238+ブランチのコマンド
3239+-------------------
3240+
3241+既存のブランチに基づいたブランチを手に入れるためには、 ``branch``
3242+コマンドを使用してください。構文は次のとおりです::
3243+
3244+ bzr branch URL [directory]
3245+
3246+ディレクトリの名前が渡されない場合、URLの最後の部分に基づいてディレクトリが作成されます。
3247+ドライブ名 (M:/) とSFTPのURLを示すそれぞれの例は次のとおりです::
3248+
3249+ bzr branch M:/cool-trunk
3250+ bzr branch sftp://bill@mary-laptop/cool-repo/cool-trunk
3251+
3252+新しいブランチを使うために明示的にディレクトリの名前を渡す例は次のとおりです::
3253+
3254+ bzr branch /home/mary/cool-repo/cool-trunk cool
3255+
3256+時間とスペースへの考慮
3257+-----------------------
3258+
3259+転送されるブランチのサイズと コンピュータとソースのブランチの間のネットワーク帯域と
3260+レイテンシによっては、この初期の転送は少し時間がかかります。
3261+その後の更新は変更のみが転送されるので遙かに速くなります。
3262+
3263+Bazaarは最新のスナップショットではなくブランチの完全な履歴を転送することを覚えておいてください。
3264+結果として、 ``branch`` を完了させた後でネットワークから離脱しても、
3265+ブランチの履歴に対して ``log`` と ``diff`` を好きなだけ行うことができます。
3266+さらに、履歴がローカルで保存されているのでこれらのオペレーションは速いです。
3267+
3268+Bazaarはバージョンの履歴を保存するために求められるディスクスペースの総量を\
3269+最小限にするスマートな圧縮技術を使うことに注意してください。
3270+多くの場合、プロジェクトの完全な履歴は最新バージョンの作業コピーよりも少ない\
3271+ディスクスペースを占めます。
3272+
3273+後の章で説明するように、Bazaarはブランチの軽量チェックアウト、
3274+すなわち履歴のローカルなストレージなしの作業ツリーもサポートします。
3275+もちろん、接続しない使い方は利用できませんが、ローカルディスクスペースが\
3276+本当に厳しいのであればそれはあなたが決めることができるトレードオフです。
3277+現在、制限された履歴の振り返りのためのサポート - *履歴の水平線(history horizon)* -
3278+は開発段階にあります。
3279+
3280+ブランチの情報を閲覧する
3281+-------------------------
3282+
3283+配布元も含むブランチの情報を見たいのであれば、 ``info`` コマンドを使います::
3284+
3285+ bzr info cool
3286+
3287+ブランチが引数として渡されなければ、現在のブランチの情報が表示されます。
3288
3289=== added file 'doc/ja/user-guide/browsing_history.txt'
3290--- doc/ja/user-guide/browsing_history.txt 1970-01-01 00:00:00 +0000
3291+++ doc/ja/user-guide/browsing_history.txt 2009-10-29 17:00:30 +0000
3292@@ -0,0 +1,93 @@
3293+履歴を閲覧する
3294+================
3295+
3296+bzr log
3297+-------
3298+
3299+``bzr log`` コマンドは以前のリビジョンの一覧を表示します。
3300+
3301+``bzr diff`` と同じように, ``bzr log`` は ``-r`` の引数をサポートします::
3302+
3303+ % bzr log -r 1000.. # リビジョン1000とその後のすべて
3304+ % bzr log -r ..1000 # r1000とそれまでのすべて
3305+ % bzr log -r 1000..1100 # 1000から1100までの変更
3306+ % bzr log -r 1000 # リビジョン1000のみの変更
3307+
3308+マージされたリビジョンを見る
3309+------------------------------
3310+
3311+Bazaarのような分散型のVCSは集中型のVCSツールよりもマージが非常に簡単なので、
3312+ブランチの履歴は、メインラインから分離してその後メインラインにマージされる\
3313+ようなラインを含むことがあります。
3314+技術的には、無数のリビジョンノード間の関係は無閉路有向グラフ(Directed Acyclic Graph: DAG)として知られます。
3315+
3316+多くの場合、まずはメインラインを見てそのあとに別のラインを見たいものです。
3317+そのため、log のデフォルトの動作はメインラインを表示して、マージされた\
3318+リビジョンがあるある場所を指示します。::
3319+
3320+ bzr log -n0 -rX
3321+
3322+全てのリビジョンと全てのマージされたリビジョンを見る場合は::
3323+
3324+ bzr log -n0
3325+
3326+-n オプションは表示するレベルを意味し、0の場合は全てを意味することに注意してください。
3327+もしそれがゴミゴミしているなら、値を変更して調整することが容易にできます。
3328+たとえば、もしあなたのプロジェクトがトップレベルのgatekeeperがチームレベルのgatekeeperからマージするように構成されている場合、\
3329+``bzr log`` はトップレベルgatekeeperの履歴だけを表示し、 ``bzr log -n2``
3330+はチームのgatekeeperの履歴を表示します。
3331+しかし、ほとんどの場合においては ``-n0`` で十分でしょう。
3332+
3333+
3334+出力をチューニングする
3335+-----------------------
3336+
3337+``log`` コマンドは出力を調整するために便利ないくつかのオプションを持ちます。次のものが含まれます:
3338+
3339+ * ``--forward`` はログを年代順で表します。
3340+ すなわち最新のリビジョンが最後に表示されます。
3341+
3342+ * ``--limit`` オプションは表示されるリビジョンの最大数を制御します。
3343+
3344+出力の調整方法の詳しい情報に関してはユーザーリファレンスのlogコマンドのオンラインヘルプを参照してください。
3345+
3346+ファイルの履歴を閲覧する
3347+-------------------------
3348+
3349+特定のファイルのみに適用されるように履歴をフィルタリングすることが便利であることがよくあります。
3350+これを行うためには、ファイルの名前を ``log`` コマンドに提供します::
3351+
3352+ bzr log foo.py
3353+
3354+古いバージョンのファイルを閲覧する
3355+-----------------------------------
3356+
3357+指定されたバージョンでファイルの内容を取得するには、次のように ``cat`` コマンドを使います::
3358+
3359+ bzr cat -r X file
3360+
3361+``X`` はリビジョンの識別子で ``file`` はファイルの名前です。
3362+これは出力を標準出力ストリームに送信しますので、次のように\
3363+閲覧ツール( ``less`` や ``more`` など)に出力をパイプで渡すか\
3364+リダイレクトするといいでしょう::
3365+
3366+ bzr cat -r -2 foo.py | less
3367+ bzr cat -r 1 foo.py > /tmp/foo-1st-version.py
3368+
3369+グラフィカルな履歴ビューワ
3370+----------------------------
3371+
3372+履歴のブラウジングはGUIツールが人生を本当に楽にしてくれる領域です。
3373+QBzrとbzr-gtkを含めてこの機能を提供するBazaarのプラグインがたくさんあります。
3374+これらがまだインストールされていなければ `プラグインを利用する <plugins.html>`_ で詳細なインストール方法をご覧ください。
3375+
3376+QBzrからグラフィカルビューワを使うには::
3377+
3378+ bzr qlog
3379+
3380+bzr-gtkからグラフィカルビューワを使うためには::
3381+
3382+ bzr viz
3383+
3384+``viz`` は実際には ``visualize`` の組み込みのエイリアスなので望むのであれば長い方のコマンド名を使います。
3385+
3386
3387=== added file 'doc/ja/user-guide/bug_trackers.txt'
3388--- doc/ja/user-guide/bug_trackers.txt 1970-01-01 00:00:00 +0000
3389+++ doc/ja/user-guide/bug_trackers.txt 2009-10-29 17:00:30 +0000
3390@@ -0,0 +1,49 @@
3391+バグトラッカー
3392+===============
3393+
3394+Bazaarにはコミットをプロジェクトのバグトラッカーのバグに関連づけできる機能があります。
3395+コミットとバグの間のハイパーリンクを生成する、もしくはコミットを含むブランチで閉じた\
3396+バグを自動的にマークするために、他のツール (もしくはフック) はこの情報を使うことができます。
3397+
3398+コミットとバグを関連付ける
3399+---------------------------
3400+
3401+コミットを行うとき、 ``commit`` の ``--fixes`` オプションを利用することでバグと関連付けることができます。例です::
3402+
3403+ $ bzr commit --fixes lp:12345 -m "Properly close the connection"
3404+
3405+このコマンドの実行によってコミットとLaunchpdのバグ12345とリンクするBazaarのメタデータが記録されます。
3406+異なるバグトラッカーを使う場合、( ``lp`` の代わりに) 独自のトラッカーコードを渡して代わりに使うことができます。
3407+Bugzilla、Trac、Roundupとその他のバグ/問題トラッカーに対してこれを設定する方法の詳細に関しては、
3408+Bazaarユーザーリファレンスの `バグトラッカーの設定`_ を参照してください。
3409+
3410+.. _バグトラッカーの設定: ../user-reference/bzr_man.html#bug-tracker-settings
3411+
3412+メタデータの記録 vs バグトラッカーの更新
3413+------------------------------------------
3414+
3415+コミット時に修正されたバグに関するメタデータの記録は完全なバグトラッカーの統合機能の中で唯一必要なものです。
3416+Bazaarは分散型VCSなので、ユーザーがオフラインでコミットしているためバグトラッカー自身へのアクセスが不可能な場合があります。
3417+代わりに、プロジェクトのワークフローに適切な中心位置に変更をpushするとき、\
3418+バグトラッカーを更新するためにフックをインストールすることが推奨されます。
3419+
3420+注: この2番目の処理段階はLaunchpadの外部もしくはホストされているブランチがスキャンされるときに
3421+Launchpadによって提供される統合機能の一部です。
3422+
3423+訂正をする
3424+-----------
3425+
3426+リビジョンとバグを関連付けるこの方法にはいくつかの制限があります。
3427+最初のものは関連づけはコミット時のみにしかできないことです。
3428+このことは、コミットするもしくは修正した後でバグが報告することを忘れた場合、
3429+一般的に後から差し戻してリンクを追加できないことを意味します。
3430+
3431+これに関連したことは関連づけは不変であるという事実です。
3432+バグがあるコミットによって修正されたものとしてマークされたが、リビジョンがバグを十分に解決しない、
3433+もしくは後で回帰がある場合、差し戻してリンクを削除できません。
3434+
3435+もちろん、正しいオプションで行うために最新コミットをアンドゥする ``bzr uncommit`` が常に使われます。
3436+これは正しくないコミットメッセージを訂正するためによく行われ、(たとえば ``--fixes`` を通した)最新コミットに
3437+記録されたメタデータを訂正するために等しく当てはまります。
3438+
3439+注: 正しくないリビジョンが公開される前に ``uncommit`` を行うのがベストです。
3440
3441=== added file 'doc/ja/user-guide/bzrtools_plugin.txt'
3442--- doc/ja/user-guide/bzrtools_plugin.txt 1970-01-01 00:00:00 +0000
3443+++ doc/ja/user-guide/bzrtools_plugin.txt 2009-10-29 17:00:30 +0000
3444@@ -0,0 +1,32 @@
3445+BzrTools
3446+========
3447+
3448+概要
3449+-----
3450+
3451+BzrToolsは便利なBazaar強化機能のコレクションです。
3452+インストールの手引きに関しては、BzrToolsのホームページを参照してください:
3453+http://bazaar-vcs.org/BzrTools.
3454+よく使われるコマンドのサンプルは下記のとおりです。
3455+
3456+
3457+shell
3458+-----
3459+
3460+``bzr shell`` はBazaarのコマンドを理解する以上のことを行うコマンドインタープリタを起動します。
3461+これはいくつかの利点を持ちます:
3462+
3463+ * すべてのコマンドの冒頭で ``bzr`` を入力する必要が無くなります。
3464+
3465+ * インテリジェントな自動入力補完が提供されます。
3466+
3467+ * Bazaarのライブラリを毎回ロードする必要がないのでコマンドは少し速く動作します。
3468+
3469+
3470+cdiff
3471+-----
3472+
3473+``bzr cdiff`` は GNU/Linux、UNIXとOS Xで ``bzr diff`` の出力の色つきバージョンを提供します。
3474+次のようによく使われます::
3475+
3476+ bzr cdiff | less -R
3477
3478=== added file 'doc/ja/user-guide/central_intro.txt'
3479--- doc/ja/user-guide/central_intro.txt 1970-01-01 00:00:00 +0000
3480+++ doc/ja/user-guide/central_intro.txt 2009-10-29 17:00:30 +0000
3481@@ -0,0 +1,32 @@
3482+集中型の開発
3483+=============
3484+
3485+動機
3486+-----
3487+
3488+並行して作業をして時折マージするよりも、ロックステップ、\
3489+すなわち複数の人が継続して変更を中心位置にコミットして\
3490+すべてのコミットの前に彼らの作業内容を最新の内容にマージすること、\
3491+で一度に作業をすることは有用であることがあります。
3492+
3493+このワークフローはSubversionとCVSのような集中型のVCSツールのユーザーには\
3494+とても慣れ親しまれています。
3495+単独の開発者が複数のマシンに取り組む場合にも応用できます。たとえば、\
3496+通常はデスクトップで作業をするが旅行の間はラップトップ、\
3497+もしくは(インターネットに接続した)ホームコンピュータで\
3498+勤務時間外に事務作業を完了させるといった具合です。
3499+
3500+あなたのチームがすでに集中型の開発でうまくいっているのであれば、それは\
3501+素晴らしいことです。
3502+多くのチームはこの方法でBazaarを使い始め、後で代替のワークフローを実験します。
3503+
3504+集中型のワークフロー
3505+---------------------
3506+
3507+下記のダイアグラムは *集中型のワークフロー* の概要を提供します。
3508+
3509+.. image:: images/workflows_centralized.png
3510+
3511+あなたのチームがより分散型のワークフローを利用することを計画しているとしても、
3512+この章でカバーされる多くのタスクは、とりわけブランチを公開する方法に関して\
3513+あなたにとって有用です。
3514
3515=== added file 'doc/ja/user-guide/configuring_bazaar.txt'
3516--- doc/ja/user-guide/configuring_bazaar.txt 1970-01-01 00:00:00 +0000
3517+++ doc/ja/user-guide/configuring_bazaar.txt 2009-10-29 17:00:30 +0000
3518@@ -0,0 +1,54 @@
3519+Bazaarを設定する
3520+==================
3521+
3522+Bazaarにあなたの名前を教える
3523+-----------------------------
3524+
3525+バージョン管理システムの機能の1つは誰が何を変更したのかを追跡することです。
3526+分散型のシステムでは、その機能を実現するためにグローバルにユニークな\
3527+それぞれの著者のための識別子が必要です。
3528+大抵の人はそれらの1つを持っています: Eメールアドレスです。
3529+Bazaarはあなたのユーザー名とホスト名を探し出してEメールアドレスを自動的に\
3530+生成します。
3531+Bazaarが行う推測を望まないのであれば、あなたが望む識別子を設定するために
3532+``whoami`` コマンドを使います::
3533+
3534+ % bzr whoami "Your Name <email@example.com>"
3535+
3536+``whoami`` は引数なしで使われると、現在の値が表示されます。
3537+
3538+設定ファイル
3539+-------------
3540+
3541+設定ファイルはLinux/Unixの場合 ``$HOME/.bazaar`` に、
3542+Windowsの場合 ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0`` にあります。
3543+この場所には3つの主要な設定ファイルがあります:
3544+
3545+* ``bazaar.conf`` はデフォルトの設定オプションを記述します。
3546+
3547+* ``locations.conf`` は特定のブランチの位置を記述しますd
3548+
3549+* ``authentication.conf`` はリモートサーバーのためのクレデンシャルな情報を記述します
3550+
3551+それぞれのブランチも特定の値をそのブランチに設定する設定ファイルを含みます。
3552+このファイルはブランチの中の ``.bzr/branch/branch.conf`` で見つかります。
3553+このファイルは **ブランチのすべてのユーザー** に見えます。
3554+あなたに固有の設定を持つブランチのための値の1つを上書きしたいのであれば、
3555+``locations.conf`` でそれを行うことができます。
3556+
3557+``whoami`` コマンドを使用してEメールアドレスを設定した後の ``bazaar.conf`` の内容のサンプルは次のとおりです::
3558+
3559+ [DEFAULT]
3560+ email = Your Name <email@example.com>
3561+
3562+サポートされる構文と構成設定の詳細については、
3563+Bazaarのユーザーリファレンスの `構成設定 <../user-reference/bzr_man.html#configuration-settings>`_ の項目を参照してください。
3564+
3565+
3566+ルールベースのプリファレンス
3567+-----------------------------
3568+
3569+いくつかのコマンドとプラグインは特定のパターンにマッチするファイルのカスタムの処理機能を提供します。
3570+ユーザーごとにルールベースのプリファレンスが ``BZR_HOME/rules`` で定義されます。
3571+ルールが検索される検索方法と関連ファイルの詳細な構文に関する詳細については、
3572+Bazaarのユーザープリファレンスの `ルール <../user-reference/bzr_man.html#rules>`_ の項目を参照してください。
3573
3574=== added file 'doc/ja/user-guide/controlling_registration.txt'
3575--- doc/ja/user-guide/controlling_registration.txt 1970-01-01 00:00:00 +0000
3576+++ doc/ja/user-guide/controlling_registration.txt 2009-10-29 17:00:30 +0000
3577@@ -0,0 +1,91 @@
3578+ファイルの登録を制御する
3579+=========================
3580+
3581+Bazaarは何を追跡するのか？
3582+--------------------------
3583+
3584+前に説明したように、 ``bzr add`` は現在のディレクトリの元でBazaarがバージョン管理すべきだと考える
3585+すべてのものを見つけ登録します。登録するものは次のようなものになります:
3586+
3587+ * ファイル
3588+ * ディレクトリ
3589+ * シンボリックリンク
3590+
3591+Bazaarは興味を持つファイルと興味を持たないファイルに関してデフォルトのルールを持ちます。
3592+後で説明される `ファイルを無視する`_ のようにこれらのルールを調整できます。
3593+
3594+他の多くのVCSツールとは異なり、Bazaarはディレクトリを第一級の項目として扱います。
3595+結果として、空のディレクトリは正しくサポートされます -
3596+ディレクトリが追跡されプロジェクトのエクスポートに含まれることを保証するために
3597+ディレクトリ内部にダミーファイルを作る必要はありません。
3598+
3599+シンボリックリンクに関しては、シンボリックリンクの値は追跡され、
3600+シンボリックリンクが指し示すものの内容は追跡されません。
3601+
3602+注: プロジェクトの中のプロジェクトを追跡するサポート機能 ("入れ子ツリー") は現在開発中です。
3603+この機能の開発を手伝うもしくはテストすることにご興味がありましたらBazaarの開発者に連絡して下さるようお願いします。
3604+
3605+登録を選ぶ
3606+-----------
3607+
3608+いくつかの事例において、登録したいものをBazaarに発見を任せるよりも明示的に指名したいことがあります。
3609+これを行うためには、パスを引数として ``add`` コマンドに提供します::
3610+
3611+ bzr add fileX dirY/
3612+
3613+ディレクトリを追加すると暗黙的にそのディレクトリの中の関心のあるすべてのものが追加されます。
3614+
3615+ファイルを無視する
3616+-------------------
3617+
3618+エディタのバックアップ、オブジェクト、バイトコードのファイル、ビルドされたプログラムなど、
3619+多くのソースツリーはバージョン管理する必要のないファイルを含みます。
3620+単純にこれらを追加しないでおくと、これらは常に未知のファイルとして現れます。
3621+ツリーのトップでこれらを ``.bzrignore`` と呼ばれるファイルに追加することでBazaarにこれらのファイルを無視するように指示することもできます。
3622+
3623+このファイルは一行ごとにファイルのワイルドカード(もしくは "globs")の一覧を含みます。典型的な内容は次のとおりです::
3624+
3625+ *.o
3626+ *~
3627+ *.tmp
3628+ *.py[co]
3629+
3630+globがスラッシュを含む場合、ツリーのトップからのパス全体がマッチします;
3631+さもなければファイルの名前だけにマッチします。以前の例では
3632+すべてのサブディレクトリ内の ``.`` の拡張子を持つファイルが無視されますが、
3633+次の例ではトップレベルでは ``config.h`` だけと ``doc/`` の中のHTMLが無視されます::
3634+
3635+ ./config.h
3636+ doc/*.html
3637+
3638+どのファイルが無視され何のパターンにマッチするのかについての一覧表を得るためには、 ``bzr ignored`` を使います::
3639+
3640+ % bzr ignored
3641+ config.h ./config.h
3642+ configure.in~ *~
3643+
3644+無視するパターンがバージョン管理されていないファイルのみにマッチし、それらが"unknown"もしくは"ignored"として扱われるのかを制御します。
3645+ファイルが明示的に追加されると、無視するパターンにマッチするかに関わらずバージョン管理されたままです。
3646+
3647+``.bzrignore`` ファイルは通常はバージョン管理されるので、ブランチの新しいコピーは同じパターンを見ます::
3648+
3649+ % bzr add .bzrignore
3650+ % bzr commit -m "Add ignore patterns"
3651+
3652+``bzr ignore PATTERN`` コマンドはPATTERNを ``.bzrignore`` ファイルに手軽に追加するために使われます
3653+(必要でBazaarによって追跡するために登録する場合、作られます)。
3654+``.bzrignore`` ファイルを直接編集することでパターンの除去と修正が行われます。
3655+
3656+グローバルで無視する
3657+---------------------
3658+
3659+プロジェクト固有のものではないが、ユーザー固有の無視されるファイルがいくつかあります。
3660+編集者用の一時ファイルもしくは個人の一時ファイルのようなものです。
3661+これらを無視するようにすべてのプロジェクトに追加するよりも、
3662+bzrは ``~/.bazaar/ignore`` の中でグローバルで無視するファイルをサポートします [#]_ 。
3663+これはプロジェクト単位で無視するファイルと同じ構文を持ちます。
3664+
3665+.. [#] Windowsにおいて、ユーザーの設定ファイルはアプリケーションデータディレクトリで見つかります。
3666+ ``~/.bazaar/branch.conf`` の代わりに、設定ファイルは次のように見つかります:
3667+ ``C:\Documents and Settings\<username>\Application Data\Bazaar\2.0\branch.conf``
3668+ 同じことが ``locations.conf`` 、 ``ignore`` 、と ``plugins`` ディレクトリにも当てはまります。
3669
3670=== added file 'doc/ja/user-guide/core_concepts.txt'
3671--- doc/ja/user-guide/core_concepts.txt 1970-01-01 00:00:00 +0000
3672+++ doc/ja/user-guide/core_concepts.txt 2009-10-29 17:00:30 +0000
3673@@ -0,0 +1,121 @@
3674+コアの概念
3675+===========
3676+
3677+単純なユーザーモデル
3678+---------------------
3679+
3680+Bazaarを使うために理解する必要のある概念は4つあります:
3681+
3682+* **リビジョン(Revision)** - 取り組むファイルのスナップショット
3683+
3684+* **作業ツリー(Working tree)** - バージョン管理されたファイルとサブディレクトリを含むディレクトリ
3685+
3686+* **ブランチ(Branch)** - ファイルの履歴を記述する、順序づけされたリビジョンの集合
3687+
3688+* **リポジトリ(Repository)** - リビジョンの貯蔵場所
3689+
3690+それぞれを詳しく見てみましょう。
3691+
3692+リビジョン
3693+-----------
3694+
3695+リビジョンはファイルとディレクトリの内容と形を含むそれらのツリーの状態の **スナップショット** です。
3696+リビジョンはそれ自身に関連づけされたメタデータをいくつか含みます。メタデータには次のようなものが含まれます:
3697+
3698+* コミットした人
3699+* コミットした時間
3700+* コミットメッセージ
3701+* そのリビジョンの元になった親のリビジョン
3702+
3703+リビジョンは不変で、グローバルかつユニークに **リビジョンid (revision-id)** で識別できます。
3704+リビジョンidの例は次のとおりです::
3705+
3706+ pqm@pqm.ubuntu.com-20071129184101-u9506rihe4zbzyyz
3707+
3708+リビジョンidはコミットする、もしくは他のシステムからインポートする時点で生成されます。
3709+リビジョンidは内部で利用するときや外部ツールとの統合に必要ですが、
3710+ブランチ固有の **リビジョン番号** (*revision numbers*)の方が人間に好まれるインタフェースに\
3711+なります。
3712+
3713+リビジョン番号は 1 や 42 や 2977.1.59 のようにドットで区切られた10進法の識別子で\
3714+ブランチに対するリビジョン番号のグラフを通してパスを追跡します。
3715+リビジョン番号は一般的にリビジョンidよりも短く、単独のブランチの範囲では
3716+それらの関係を理解するためにそれぞれを比較できます。
3717+たとえば、リビジョン10はリビジョン9の直後のメインライン(下記を参照)のリビジョンです。
3718+リビジョン番号はコマンドが実行されているときに生成されます。
3719+これらはブランチ内でどのリビジョンがチップ(すなわち最新のリビジョン)であるかに依存するからです。
3720+
3721+Bazaarで指定できるリビジョンとリビジョンの範囲のいくつかの方法に関しては、付録の
3722+`リビジョンを指定する <specifying_revisions.html>`_ を参照してください。
3723+リビジョンの番号付けの詳細に関しては `リビジョン番号を理解する <zen.html#understanding-revision-numbers>`_
3724+を参照してください。
3725+
3726+.. *TODO: add diagram*
3727+
3728+作業ツリー
3729+------------
3730+
3731+作業ツリー(working tree)は ユーザーが編集できるファイルを保持する
3732+*バージョン管理されたディレクトリ* です。
3733+作業ツリーは *ブランチ* に関連付けされます。
3734+
3735+多くのコマンドは作業ツリーをそれぞれの文脈で使います。
3736+たとえば、 ``commit`` コマンドは作業ツリーの中のファイルの\
3737+現在の内容を利用して新しいリビジョン番号を作ります。
3738+
3739+.. *TODO: add diagram*
3740+
3741+ブランチ
3742+---------
3743+
3744+最もシンプルな場合、ブランチは *順序づけされた一連のリビジョン* です。
3745+最終リビジョンは *チップ(tip)* として知られます。
3746+
3747+ブランチは分かれたりその後再結合(*marged* back)されたりして、\
3748+グラフの形をとります。
3749+技術的にいえば、グラフは(親と子のリビジョンの間)の有行な関係を表し、\
3750+ループが存在しないので、 *directed acyclic graph* (DAG) として\
3751+言及されるかもしれません。
3752+
3753+この名前にギョッとするかもしれませんが、ご心配なく。
3754+覚えておくべき重要なことは次のとおりです:
3755+
3756+* DAGの範囲内での開発の主要なラインは *メインライン(mineline)*,
3757+ *トランク(trunk)*, もしくは単に *左側(left hand side: LHS)* と呼ばれます。
3758+
3759+* ブランチはメインラインではない開発ラインを持つことがあります。
3760+ そのとき、別のラインはある時点で始まり別の時点で終わります。
3761+
3762+.. *TODO: add diagram*
3763+
3764+レポジトリ
3765+-----------
3766+
3767+レポジトリはシンプルにいえば *リビジョンの保管場所* です。
3768+最もシンプルな事例では、それぞれのブランチが独自のレポジトリを持ちます。\
3769+別の事例では、ディスクの使用量を最適化するためにブランチに対してレポジトリを\
3770+共用しています。
3771+
3772+.. *TODO: add diagram*
3773+
3774+概念をまとめる
3775+---------------
3776+
3777+上記の概念を把握したら、Bazaarのさまざまな使い方が理解しやすくなります。
3778+Bazaarの最もシンプルな使い方は *スタンドアロンツリー(standalone tree)* で、\
3779+これは1つの位置に作業ツリー、ブランチとレポジトリのすべてが含まれます。
3780+他のよくあるシナリオには次のようなものがあります:
3781+
3782+* `共用リポジトリ(shared branch) <branching_a_project.html#a-reminder-about-shared-repositories>`_
3783+ - 作業ツリーとブランチは同じディレクトリにありますが、リポジトリは高い階層の\
3784+ ディレクトリに存在します。
3785+
3786+* `スタックブランチ(stacked branch) <stacked.html>`_
3787+ - 親のリポジトリと共通なリビジョンは親のリポジトリのものを利用することで、
3788+ ブランチはユニークなリビジョンだけを保存します。
3789+
3790+* `軽量チェックアウト(lightweight checkout) <using_checkouts.html#getting-a-lightweight-checkout>`_
3791+ - 作業ツリーとは別の場所にブランチが保存されます。
3792+
3793+Bazaarを使う最良の方法は、あなたのニーズ次第です。
3794+次に共通のワークフローを見てみましょう。
3795
3796=== added file 'doc/ja/user-guide/distributed_intro.txt'
3797--- doc/ja/user-guide/distributed_intro.txt 1970-01-01 00:00:00 +0000
3798+++ doc/ja/user-guide/distributed_intro.txt 2009-10-29 17:00:30 +0000
3799@@ -0,0 +1,24 @@
3800+分散型の開発
3801+=============
3802+
3803+動機
3804+----
3805+
3806+分散型のVCSツールは共同作業の新しい方法を提供します。
3807+これは私達が生きる現代の世界をより反映したものでより高い品質の\
3808+成果を可能にします。
3809+
3810+分散型の共用のメインラインのワークフロー
3811+-----------------------------------------
3812+
3813+このワークフローにおいて、それぞれの開発者は1つもしくは複数の\
3814+独自のブランチに加えて、メインブランチのチェックアウトを持ちます。
3815+開発者は個人のブランチに取り組み、準備ができたら、それをメインラインに\
3816+マージします。
3817+
3818+.. image:: images/workflows_shared.png
3819+
3820+他の分散型のワークフローはこの章の後ろの方で検討します。
3821+
3822+..
3823+ vim: tw=74 ft=rst
3824
3825=== added file 'doc/ja/user-guide/entering_commands.txt'
3826--- doc/ja/user-guide/entering_commands.txt 1970-01-01 00:00:00 +0000
3827+++ doc/ja/user-guide/entering_commands.txt 2009-10-29 17:00:30 +0000
3828@@ -0,0 +1,36 @@
3829+コマンドを入力する
3830+===================
3831+
3832+ユーザーインターフェイス
3833+-------------------------
3834+
3835+Bazaarに対して利用可能な数多くのユーザーインターフェイスが存在します。
3836+コアパッケージは **bzr** と呼ばれるコマンドラインツールを提供し
3837+グラフィカルユーザーインターフェイス(GUI)はプラグインとして利用できます。
3838+
3839+bzrを使う
3840+---------
3841+
3842+構文は次のとおりです::
3843+
3844+ bzr [グローバルオプション] command [オプションと引数]
3845+
3846+グローバルオプションはBazaarの動作方法に影響を与え ``command`` の前後に現れます。コマンド特有のオプションはコマンドの後で指定しなければなりませんが、コマンド固有の引数の前後と間で指定することができます。
3847+
3848+共通のオプション
3849+-----------------
3850+
3851+下記で示されるいくつかのオプションはすべてのコマンドに対して有効です。
3852+
3853+ ========== ========= =================
3854+ 短い形式 長い形式 説明
3855+ ========== ========= =================
3856+ -h --help get help
3857+ -v --verbose be more verbose
3858+ -q --quiet be more quiet
3859+ ========== ========= =================
3860+
3861+Quietモードはエラーと警告のみを表示します。これはスクリプトで使う際に便利です。
3862+
3863+注: 大抵のコマンドは1つのレベルの冗長性だけをサポートします。今後これは変更されるかもしれません。
3864+高度な冗長性を求めるためには、-vオプションを複数回指定するだけです。
3865
3866=== added file 'doc/ja/user-guide/filtered_views.txt'
3867--- doc/ja/user-guide/filtered_views.txt 1970-01-01 00:00:00 +0000
3868+++ doc/ja/user-guide/filtered_views.txt 2009-10-29 17:00:30 +0000
3869@@ -0,0 +1,165 @@
3870+Filtered views
3871+==============
3872+
3873+Filtered view の紹介
3874+--------------------------
3875+
3876+Viewはtreeに対するマスクを提供し、ユーザーはtreeの一部分に集中できる\
3877+ようになります。
3878+このマスキングが役に立ついくつかの場面があります。たとえば、大きな\
3879+プロジェクトの技術ライターやテスターはプロジェクトのうち一部のディレクトリ\
3880+やファイルだけを扱います。
3881+
3882+開発者は大規模な変更をviewを使っていくつかのコミットに分解したいと思う\
3883+かもしれません。 ``shelve`` ``unshelve`` がいくつかの変更を後のコミットまで\
3884+とっておくのに対して、viewは次のコミットに(何を含めないかではなく)何を\
3885+含めるかを指定します。
3886+
3887+viewを作った後は、ファイルリストをサポートするコマンド - status,
3888+diff, commit, etc - に暗黙的に毎回そのファイルリストが渡されます。
3889+それらのコマンドに明示的にファイルリストを渡すことも可能ですが、\
3890+指名するファイルは現在のviewの中にないといけません。
3891+対照的に、ツリーを対象とするコマンド - pull, merge, update, etc -
3892+はviewが作られた後もツリー全体に対して操作しますが、現在のviewに\
3893+関係するもののみを報告します。
3894+どちらのケースでも、Bazaarはユーザーに毎回viewが使われていることを\
3895+報告するので、操作や出力がマスクされていることが判ります。
3896+
3897+.. 2aになったらこのnoteは要らない
3898+.. Note: Bazaar's default format does not yet support filtered views. That
3899+ is likely to change in the near future. To use filtered views in the
3900+ meantime, you currently need to upgrade to ``development-wt6`` (or
3901+ ``development-wt6-rich-root``) format first.
3902+
3903+
3904+view を作る
3905+---------------
3906+
3907+次のように, ``view`` コマンドにファイルやディレクトリを指定することで\
3908+viewを作ります::
3909+
3910+ bzr view file1 file2 dir1 ...
3911+
3912+出力は::
3913+
3914+ Using 'my' view: file1, file2, dir1
3915+
3916+
3917+現在のviewをリストする
3918+------------------------
3919+
3920+現在のviewを見るには、 ``view`` コマンドに引数をつけないで実行します::
3921+
3922+ bzr view
3923+
3924+もしviewが無ければ、 ``No current view.`` というメッセージが出力されるでしょう。
3925+そうでなければ、現在のviewの名前と内容が次のように表示されます::
3926+
3927+ 'my' view is: a, b, c
3928+
3929+
3930+viewを切り替える
3931+-----------------------
3932+
3933+ほとんどの場合、viewは「変更を選択するために作られて、\
3934+変更がコミットされると削除される」という具合に短い期間で使われます。
3935+それ以外の場合では、viewに名前をつけてそれを切り替えたい場合がある\
3936+かもしれません。
3937+
3938+名前つきviewを宣言してそれに切り替えるには::
3939+
3940+ bzr view --name view-name file1 dir1 ...
3941+
3942+たとえば::
3943+
3944+ bzr view --name doc NEWS doc/
3945+ Using doc view: NEWS, doc/
3946+
3947+名前つきviewを見るには::
3948+
3949+ bzr view --name view-name
3950+
3951+名前つきviewに切り替えるには::
3952+
3953+ bzr view --switch view-name
3954+
3955+全ての名前つきviewの一覧を得るには::
3956+
3957+ bzr view --all
3958+
3959+
3960+一時的にviewを無効にする
3961+----------------------------
3962+
3963+現在のviewを削除せずに無効にしたい場合、 ``off`` という名前の仮想viewに\
3964+切り替えることができます。これは、ツリー全体を一つか二つのコマンドで操作する\
3965+必要があり(例: merge)、しかしその後に元のviewに戻りたい場合に便利です。
3966+
3967+現在のviewを削除せずに無効にするには::
3968+
3969+ bzr view --switch off
3970+
3971+ツリー全体に対する操作が終わったら、元のviewの名前を指定して戻ることが\
3972+できます。たとえば、デフォルトの名前が使われて他のであれば::
3973+
3974+ bzr view --switch my
3975+
3976+
3977+viewを削除する
3978+--------------
3979+
3980+現在のviewを削除するには::
3981+
3982+ bzr view --delete
3983+
3984+名前つきviewを削除するには::
3985+
3986+ bzr view --name view-name --delete
3987+
3988+全てのviewを削除するには::
3989+
3990+ bzr view --delete --all
3991+
3992+
3993+注意点
3994+---------------------
3995+
3996+view を定義しても作業ツリー内のほかのファイルを削除するわけでは\
3997+ありません。単に作業ツリーに対する "レンズ" を提供するだけです。
3998+
3999+view は作業ツリーのメタデータとして保存されます。pull, push, update
4000+といったブランチコマンドを使っても他の作業ツリーに伝播しません。
4001+
4002+view はファイルパスの形で定義されます。もしview内のファイルをview外に
4003+移動したのであれば、view はそのファイルを追跡しません。
4004+たとえば、viewが ``doc/`` と定義されていて ``doc/NEWS`` を ``NEWS``
4005+に移動しても view は ``doc/`` に定義されたままで、 ``doc/`` と ``NEWS``
4006+のように変更されたりはしません。同じように、view内のファイルを削除しても\
4007+viewからはそのファイルパスは削除されません。
4008+
4009+
4010+現在のviewを利用するコマンドは:
4011+
4012+* status
4013+* diff
4014+* commit
4015+* add
4016+* remove
4017+* revert
4018+* mv
4019+* ls
4020+
4021+ツリー全体に対する操作だけれども現在のviewの中だけを報告するコマンドは:
4022+
4023+* pull
4024+* update
4025+* merge.
4026+
4027+現在のところ、多くのコマンドがviewを無視します。ニーズがある\
4028+コマンドから徐々に上の対応リストに追加されていくでしょう。
4029+いくつかのコマンドは全体図を見るのがより適しているために、\
4030+viewを無視したままになるでしょう。このタイプのコマンドには\
4031+次のものがあります:
4032+
4033+* log
4034+* info
4035
4036=== added file 'doc/ja/user-guide/getting_help.txt'
4037--- doc/ja/user-guide/getting_help.txt 1970-01-01 00:00:00 +0000
4038+++ doc/ja/user-guide/getting_help.txt 2009-10-29 17:00:30 +0000
4039@@ -0,0 +1,19 @@
4040+helpを表示する
4041+==============
4042+
4043+Bazaarは組み込みのオンラインヘルプシステムを搭載しています。
4044+トピックの一覧を見るためには::
4045+
4046+ bzr help topics
4047+
4048+コマンドの一覧を見るためには::
4049+
4050+ bzr help commands
4051+
4052+トピックのxxxもしくはコマンドのxxxのヘルプを表示するためには::
4053+
4054+ bzr help xxx
4055+
4056+ヘルプを検索するもしくは大きなドキュメントとして読みたい場合、
4057+情報はBazaarのユーザーリファレンスでも手に入ります。
4058+
4059
4060=== added file 'doc/ja/user-guide/hooks.txt'
4061--- doc/ja/user-guide/hooks.txt 1970-01-01 00:00:00 +0000
4062+++ doc/ja/user-guide/hooks.txt 2009-10-29 17:00:30 +0000
4063@@ -0,0 +1,59 @@
4064+フックを利用する
4065+================
4066+
4067+フックとは？
4068+------------
4069+
4070+Bazaarのふるまいをカスタマイズする1つの方法は *フック(hook)* です。
4071+フックによって特定のBazaarの特定のオペレーションの前後でアクションを実行できます。
4072+オペレーションは ``commit`` 、 ``push`` 、 ``pull`` 、と ``uncommit`` を含みます。
4073+フックとパラメータの完全なリストに関しては、ユーザーリファレンスの
4074+`フック <../user-reference/bzr_man.html#hooks>`_ を参照してください。
4075+
4076+大抵のフックはクライアントで実行されますが、サーバーで実行されるものもわずかにあります。
4077+(サーバーサイドのオペレーションの特殊なケースを扱うものは `bzr-push-and-update`_ プラグインも参照。)
4078+
4079+.. _bzr-push-and-update: https://launchpad.net/bzr-push-and-update/
4080+
4081+
4082+フックを使用する
4083+-----------------
4084+
4085+フックを使用するには、 `プラグインを書きます <#writing-a-plugin>`_ 。
4086+新しいコマンドを作成する代わりに、このプラグインはフックを定義してインストールします。例です::
4087+
4088+ from bzrlib import branch
4089+
4090+
4091+ def post_push_hook(push_result):
4092+ print "The new revno is %d" % push_result.new_revno
4093+
4094+
4095+ branch.Branch.hooks.install_named_hook('post_push', post_push_hook,
4096+ 'My post_push hook')
4097+
4098+この例を使用するには、 ``push_hook.py`` という名前のファイルを作り
4099+``plugins`` サブディレクトリに設置します。
4100+(プラグインをインストールしていなければ、 ``plugins`` ディレクトリを作る必要があります)。
4101+
4102+以上です！次回にpushすると、"The new revno is..."が表示されます。
4103+もちろん、Pythonのフルパワーを思いとおりにできるので、フックはこれよりもはるかに手が込んでいます。
4104+これでフックの使い方を理解したので、それらで何をするかはあなたしだいです。
4105+
4106+プラグインのコードは2つのことを行います。
4107+最初に、これは ``push`` が完了した後に実行する関数を定義します。
4108+(代わりにインスタンスメソッドもしくは呼び出し可能なオブジェクトを使用することもできます。)
4109+すべてのpushフックは単独の引数 ``push_result`` をとります。
4110+
4111+2番目に、プラグインはフックをインストールします。
4112+最初の引数 ``'post_push'`` はフックがインストールされている場所を特定します。
4113+2番目の引数はフック自身です。3番目の引数は ``'My post_push hook'`` という名前で、
4114+これは進行メッセージとエラーメッセージで使用されます。
4115+
4116+
4117+フックをデバッグする
4118+---------------------
4119+
4120+インストールされたフックの一覧を表示するには、 ``hooks`` コマンドを使います::
4121+
4122+ bzr hooks
4123
4124=== added file 'doc/ja/user-guide/http_smart_server.txt'
4125--- doc/ja/user-guide/http_smart_server.txt 1970-01-01 00:00:00 +0000
4126+++ doc/ja/user-guide/http_smart_server.txt 2009-10-29 17:00:30 +0000
4127@@ -0,0 +1,221 @@
4128+FastCGIでBazaarを提供する
4129+==========================
4130+
4131+このドキュメントでは、Apache 2.0とFastCGIもしくはmod_pythonを利用して
4132+Bazaar HTTPスマートサーバーをセットアップする1つの方法を説明します。
4133+
4134+スマートサーバーに関する詳細な情報とそれを設定する他の方法に関しては、
4135+メインのスマートサーバーのドキュメントを参照してください。
4136+
4137+例
4138+---
4139+
4140+プレーンなHTTPで `/srv/example.com/www/code` を `http://example.com/code/...` として
4141+すでに公開しているとします。これはbzrのブランチと `/srv/example.com/www/code/branch-one`
4142+と `/srv/example.com/www/code/my-repo/branch-two` のようなディレクトリを含みます。
4143+既存のHTTP形式のアクセス権限に加えてリードオンリーのスマートサーバーのアクセス権限を
4144+これらのディレクトリに提供したい場合を考えます。
4145+
4146+Apache 2.0を設定する
4147+--------------------
4148+
4149+FastCGI
4150+~~~~~~~
4151+
4152+最初に、mod_fastcgiを設定します。たとえば次の行をhttpd.confに追加します::
4153+
4154+ LoadModule fastcgi_module /usr/lib/apache2/modules/mod_fastcgi.so
4155+ FastCgiIpcDir /var/lib/apache2/fastcgi
4156+
4157+我々の例では、`http://example.com/code` で `/srv/example.com/www/code` をすでに提供しているので
4158+既存のApacheの設定は次のようになります::
4159+
4160+ Alias /code /srv/example.com/www/code
4161+ <Directory /srv/example.com/www/code>
4162+ Options Indexes
4163+ # ...
4164+ </Directory>
4165+
4166+.bzr/smartの形式で終わるURLに対するすべてのリクエストを扱うために
4167+次のように変更する必要があります::
4168+
4169+ Alias /code /srv/example.com/www/code
4170+ <Directory /srv/example.com/www/code>
4171+ Options Indexes FollowSymLinks
4172+ RewriteEngine On
4173+ RewriteBase /code
4174+ RewriteRule ^(.*/|)\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
4175+ </Directory>
4176+
4177+ # bzr-smart.fcgiはDocumentRootの元に存在しないので、実行されるように
4178+ # AliasはこれをURLの名前空間のエイリアスにする。
4179+ Alias /srv/example.com/scripts/bzr-smart.fcgi /srv/example.com/scripts/bzr-smart.fcgi
4180+ <Directory /srv/example.com/scripts>
4181+ Options ExecCGI
4182+ <Files bzr-smart.fcgi>
4183+ SetHandler fastcgi-script
4184+ </Files>
4185+ </Directory>
4186+
4187+この設定はFastCGIを通して `/code` 内部の `/.bzr/smart` で終わるURLに対する
4188+Bazaarのスマートサーバーへのリクエストを扱うようにApacheに指示します。
4189+
4190+詳細な情報は mod_rewrite_ と mod_fastcgi_ のドキュメントを参照してください。
4191+
4192+.. _mod_rewrite: http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
4193+.. _mod_fastcgi: http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
4194+
4195+mod_python
4196+~~~~~~~~~~
4197+
4198+最初に、次のようなコードをhttpd.confに追加してmod_pythonを設定します::
4199+
4200+ LoadModule python_module /usr/lib/apache2/modules/mod_python.so
4201+
4202+FastCGIと同じ方法でmod_rewriteを用いて書き換えルールを定義します::
4203+
4204+ RewriteRule ^(.*/|)\.bzr/smart$ /srv/example.com/scripts/bzr-smart.fcgi
4205+
4206+変更は次のようになります::
4207+
4208+ RewriteRule ^(.*/|)\.bzr/smart$ /srv/example.com/scripts/bzr-smart.py
4209+
4210+mod_fastcgiのように、スクリプトがどのように扱われるのかも定義します::
4211+
4212+ Alias /srv/example.com/scripts/bzr-smart.py /srv/example.com/scripts/bzr-smart.py
4213+ <Directory /srv/example.com/scripts>
4214+ <Files bzr-smart.py>
4215+ PythonPath "sys.path+['/srv/example.com/scripts']"
4216+ AddHandler python-program .py
4217+ PythonHandler bzr-smart::handler
4218+ </Files>
4219+ </Directory>
4220+
4221+この設定はmod_pythonを通して `/code` 内部の `/.bzr/smart` で終わるURLに対するリクエストを
4222+Bazaarのスマートサーバーに渡すように指示します。
4223+
4224+注: bzrlibがPATHの中に存在しない場合、次の行を変更する必要があります::
4225+
4226+ PythonPath "sys.path+['/srv/example.com/scripts']"
4227+
4228+変更後は次のようになります::
4229+
4230+ PythonPath "['/path/to/bzr']+sys.path+['/srv/example.com/scripts']"
4231+
4232+
4233+詳細な情報は mod_python_ のドキュメントを参照してください。
4234+
4235+.. _mod_python: http://www.modpython.org/
4236+
4237+
4238+Bazaarを設定する
4239+-----------------
4240+
4241+FastCGI
4242+~~~~~~~
4243+
4244+`/srv/example.com/scripts/bzr-smart.fcgi` でスマートサーバーを実行するためにApacheを設定しました。
4245+これはスマートサーバーを設定するために書く必要のある単なるシンプルなスクリプトで
4246+サーバーをFastCGIのゲートウェイに結びつけます。次のようになります::
4247+
4248+ import fcgi
4249+ from bzrlib.transport.http import wsgi
4250+
4251+ smart_server_app = wsgi.make_app(
4252+ root='/srv/example.com/www/code',
4253+ prefix='/code/',
4254+ path_var='REQUEST_URI',
4255+ readonly=True,
4256+ load_plugins=True,
4257+ enable_logging=True)
4258+
4259+ fcgi.WSGIServer(smart_server_app).run()
4260+
4261+　`fcgi`のモジュールはhttp://svn.saddi.com/py-lib/trunk/fcgi.pyで見つかります。
4262+これは flup_ の一部です。
4263+
4264+.. _flup: http://www.saddi.com/software/flup/
4265+
4266+mod_python
4267+~~~~~~~~~~
4268+
4269+`/srv/example.com/scripts/bzr-smart.py` でスマートサーバーを実行するためにApacheを設定しました。
4270+これはスマートサーバーを設定するために書く必要のあるシンプルなスクリプトでサーバーをmod_pythonの
4271+ゲートウェイに結びつけます。次のようになります::
4272+
4273+ import modpywsgi
4274+ from bzrlib.transport.http import wsgi
4275+
4276+ smart_server_app = wsgi.make_app(
4277+ root='/srv/example.com/www/code',
4278+ prefix='/code/',
4279+ path_var='REQUEST_URI',
4280+ readonly=True,
4281+ load_plugins=True,
4282+ enable_logging=True)
4283+
4284+ def handler(request):
4285+ """Handle a single request."""
4286+ wsgi_server = modpywsgi.WSGIServer(smart_server_app)
4287+ return wsgi_server.run(request)
4288+
4289+`modpywsgi` モジュールは
4290+`http://dev.pocoo.org/projects/pocoo/browser/pocoo/wrappers/modpy.py` で見つかります。
4291+これは pocoo_ の一部です。modpywsgi.pyをbzr-smart.pyと同じディレクトリ
4292+(すなわち/srv/example.com/scripts/)に設置していることを確認してください。
4293+
4294+.. _pocoo: http://dev.pocoo.org/projects/pocoo/
4295+
4296+クライアント
4297+------------
4298+
4299+これで `bzr+http://` 形式のURLを利用できます::
4300+
4301+ bzr log bzr+http://example.com/code/my-branch
4302+
4303+プレーンなHTTP形式のアクセスも持続します::
4304+
4305+ bzr log http://example.com/code/my-branch
4306+
4307+
4308+高度な設定
4309+-----------
4310+
4311+BazaarのHTTPスマートサーバーはWSGIアプリケーションなので、
4312+WSGI標準に準拠するサードパーティのWSGIのミドルウェアもしくはサーバーで利用できます。
4313+唯一の要件は以下のとおりです:
4314+
4315+ * 　`SmartWSGIApp` をコンストラクトするためには、それが提供する **root transport** を指定する必要があります。
4316+ * それぞれのリクエストの `environ` dict は **'bzrlib.relpath'** 変数の設定を持たなければなりません。
4317+
4318+この例で使われている `make_app` ヘルパーは それに渡される `root` パスに基づいたトランスポートを伴う
4319+`SmartWSGIApp` をコンストラクトし、引数 `prefix` と`path_var` に基づくそれぞれのリクエストに対する
4320+　`bzrlib.relpath` を算出します。
4321+上記の例において、これは (Apacheによって設定される)'REQUEST_URI' を取り、接頭辞の '/code/' と接尾辞の '/.bzr/smart'
4322+をはぎ取り、それを 'bzrlib.relpath' として設定するので、 '/code/foo/bar/.bzr/smart' に対するリクエストは
4323+'foo/bzr' の 'bzrlib.relpath' になります。
4324+
4325+`SmartWSGIApp` を直接コンストラクトすることで、ローカルではないトランスポートに対して
4326+スマートサーバーを設定するもしくは任意任意のパスの変換を行うことは可能です。
4327+詳細な情報に関しては `bzrlib.transport.http.wsgi` のdocstringsと `WSGI標準`_ を参照してください。
4328+
4329+.. _WSGI標準: http://www.python.org/dev/peps/pep-0333/
4330+
4331+
4332+``bzr+http://`` を通してpushする
4333+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4334+
4335+httpスマートサーバーを通してデータをプッシュすることは可能です。
4336+これを行うための最も簡単な方法は、 ``wsgi.make_app()`` コールに ``readonly=False`` を
4337+提供するだけです。ただし、スマートプロトコルは認証機能が含まれないので注意してください。
4338+書き込みのサポートを有効にする場合、
4339+実際にシステム上のデータを書き込みできる人を制限するために、 ``.bzr/smart`` URLへの権限を制限するとよいでしょう。
4340+
4341+現時点では、同じURLに対して読み込み限定の人と読み込みと書き込みの人を分けることはできません。
4342+(認証を行う)HTTPレイヤーにおいて、すべては単なるPOSTリクエストだからです。
4343+しかしながら、HTTPSアクセスの場合に認証が必要な書き込みサーバーを使い、
4344+プレーンなHTTPは読み込み限定のアクセスを許可することは確実にできます。
4345+
4346+
4347+..
4348+ vim: ft=rst tw=74 et
4349
4350=== added directory 'doc/ja/user-guide/images'
4351=== added file 'doc/ja/user-guide/images/workflows_centralized.png'
4352Binary files doc/ja/user-guide/images/workflows_centralized.png 1970-01-01 00:00:00 +0000 and doc/ja/user-guide/images/workflows_centralized.png 2009-10-29 17:00:30 +0000 differ
4353=== added file 'doc/ja/user-guide/images/workflows_centralized.svg'
4354--- doc/ja/user-guide/images/workflows_centralized.svg 1970-01-01 00:00:00 +0000
4355+++ doc/ja/user-guide/images/workflows_centralized.svg 2009-10-29 17:00:30 +0000
4356@@ -0,0 +1,1542 @@
4357+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
4358+<!-- Created with Inkscape (http://www.inkscape.org/) -->
4359+<svg
4360+ xmlns:dc="http://purl.org/dc/elements/1.1/"
4361+ xmlns:cc="http://web.resource.org/cc/"
4362+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4363+ xmlns:svg="http://www.w3.org/2000/svg"
4364+ xmlns="http://www.w3.org/2000/svg"
4365+ xmlns:xlink="http://www.w3.org/1999/xlink"
4366+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
4367+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
4368+ width="1052.3622"
4369+ height="744.09448"
4370+ id="svg2"
4371+ sodipodi:version="0.32"
4372+ inkscape:version="0.45.1"
4373+ version="1.0"
4374+ sodipodi:docbase="/home/ian/Desktop/talk/workflows"
4375+ sodipodi:docname="workflows_centralized.svg"
4376+ inkscape:output_extension="org.inkscape.output.svg.inkscape"
4377+ inkscape:export-filename="/home/ian/Desktop/talk/workflows/workflows_centralized.png"
4378+ inkscape:export-xdpi="90"
4379+ inkscape:export-ydpi="90">
4380+ <defs
4381+ id="defs4">
4382+ <radialGradient
4383+ xlink:href="#linearGradient5992"
4384+ r="33.156250"
4385+ inkscape:collect="always"
4386+ id="radialGradient6000"
4387+ gradientUnits="userSpaceOnUse"
4388+ gradientTransform="matrix(1.000000,0.000000,0.000000,1.693685,0.000000,-197.9515)"
4389+ fy="285.36218"
4390+ fx="495.50000"
4391+ cy="285.36218"
4392+ cx="495.50000" />
4393+ <linearGradient
4394+ y2="187.57059"
4395+ y1="225.40080"
4396+ xlink:href="#linearGradient5963"
4397+ x2="458.91232"
4398+ x1="383.95898"
4399+ inkscape:collect="always"
4400+ id="linearGradient5969"
4401+ gradientUnits="userSpaceOnUse" />
4402+ <linearGradient
4403+ id="linearGradient3586">
4404+ <stop
4405+ style="stop-color:#000000;stop-opacity:1.0000000;"
4406+ offset="0.0000000"
4407+ id="stop3588" />
4408+ <stop
4409+ style="stop-color:#ffffff;stop-opacity:0;"
4410+ offset="1"
4411+ id="stop3590" />
4412+ </linearGradient>
4413+ <linearGradient
4414+ inkscape:collect="always"
4415+ id="linearGradient5963">
4416+ <stop
4417+ style="stop-color:#ffffff;stop-opacity:1;"
4418+ offset="0"
4419+ id="stop5965" />
4420+ <stop
4421+ style="stop-color:#ffffff;stop-opacity:0;"
4422+ offset="1"
4423+ id="stop5967" />
4424+ </linearGradient>
4425+ <linearGradient
4426+ inkscape:collect="always"
4427+ id="linearGradient5992">
4428+ <stop
4429+ style="stop-color:#ffffff;stop-opacity:1;"
4430+ offset="0"
4431+ id="stop5994" />
4432+ <stop
4433+ style="stop-color:#ffffff;stop-opacity:0;"
4434+ offset="1"
4435+ id="stop5996" />
4436+ </linearGradient>
4437+ <linearGradient
4438+ y2="-0.45783132"
4439+ y1="3.3012049"
4440+ xlink:href="#linearGradient893"
4441+ x2="0.92957747"
4442+ x1="-2.3960868e-17"
4443+ id="linearGradient4284" />
4444+ <linearGradient
4445+ y2="-0.033519555"
4446+ y1="2.0837989"
4447+ xlink:href="#linearGradient893"
4448+ x2="0.99074072"
4449+ x1="-0.77314812"
4450+ id="linearGradient4283" />
4451+ <linearGradient
4452+ y2="1.8771822"
4453+ y1="-0.033741195"
4454+ xlink:href="#linearGradient902"
4455+ x2="0.48453596"
4456+ x1="0.47041038"
4457+ id="linearGradient2740"
4458+ gradientTransform="scale(0.997153,1.002855)" />
4459+ <linearGradient
4460+ y2="1.9025002"
4461+ y1="-0.043652620"
4462+ xlink:href="#linearGradient902"
4463+ x2="0.48481107"
4464+ x1="0.47042510"
4465+ id="linearGradient1506"
4466+ gradientTransform="scale(0.995847,1.004170)" />
4467+ <linearGradient
4468+ y2="1.8570156"
4469+ y1="-0.024853170"
4470+ xlink:href="#linearGradient902"
4471+ x2="0.48548824"
4472+ x1="0.47157744"
4473+ id="linearGradient1505"
4474+ gradientTransform="scale(0.997825,1.002180)" />
4475+ <linearGradient
4476+ y2="182.99154"
4477+ y1="169.09755"
4478+ xlink:href="#linearGradient892"
4479+ x2="88.996957"
4480+ x1="88.755695"
4481+ id="linearGradient1404"
4482+ gradientTransform="scale(1.3695887,0.7301462)"
4483+ gradientUnits="userSpaceOnUse" />
4484+ <radialGradient
4485+ xlink:href="#linearGradient1317"
4486+ r="0.34964636"
4487+ id="radialGradient1316"
4488+ fy="0.18269235"
4489+ fx="0.50352114"
4490+ cy="0.50000006"
4491+ cx="0.50000000" />
4492+ <radialGradient
4493+ xlink:href="#linearGradient1317"
4494+ r="0.41197181"
4495+ id="radialGradient1315"
4496+ fy="0.26666668"
4497+ fx="0.47535211"
4498+ cy="0.53333336"
4499+ cx="0.47887325" />
4500+ <linearGradient
4501+ y2="173.03153"
4502+ y1="177.77768"
4503+ xlink:href="#linearGradient902"
4504+ x2="95.100155"
4505+ x1="101.10657"
4506+ id="linearGradient1171"
4507+ gradientTransform="scale(1.3601783,0.7351977)"
4508+ gradientUnits="userSpaceOnUse" />
4509+ <linearGradient
4510+ y2="1.8378206"
4511+ y1="-0.016295359"
4512+ xlink:href="#linearGradient902"
4513+ x2="0.48655096"
4514+ x1="0.47284532"
4515+ id="linearGradient1170"
4516+ gradientTransform="scale(0.998371,1.001632)" />
4517+ <linearGradient
4518+ y2="81.477602"
4519+ y1="224.57898"
4520+ xlink:href="#linearGradient893"
4521+ x2="74.533693"
4522+ x1="146.69923"
4523+ id="linearGradient1169"
4524+ gradientTransform="scale(1.1870691,0.842411)"
4525+ gradientUnits="userSpaceOnUse" />
4526+ <linearGradient
4527+ y2="133.54711"
4528+ y1="228.39311"
4529+ xlink:href="#linearGradient888"
4530+ x2="88.447016"
4531+ x1="141.60217"
4532+ id="linearGradient1167"
4533+ gradientTransform="scale(1.1838753,0.8446836)"
4534+ gradientUnits="userSpaceOnUse" />
4535+ <linearGradient
4536+ y2="148.78619"
4537+ y1="131.25248"
4538+ xlink:href="#linearGradient1317"
4539+ x2="107.04918"
4540+ x1="111.49758"
4541+ id="linearGradient1166"
4542+ gradientTransform="scale(1.223869,0.8170809)"
4543+ gradientUnits="userSpaceOnUse" />
4544+ <linearGradient
4545+ y2="176.28694"
4546+ y1="269.85831"
4547+ xlink:href="#linearGradient888"
4548+ x2="-16.224496"
4549+ x1="51.460928"
4550+ id="linearGradient1157"
4551+ gradientTransform="scale(2.4217071,0.4129318)"
4552+ gradientUnits="userSpaceOnUse" />
4553+ <linearGradient
4554+ y2="234.26866"
4555+ y1="178.48862"
4556+ xlink:href="#linearGradient888"
4557+ x2="25.220815"
4558+ x1="25.220815"
4559+ id="linearGradient1156"
4560+ gradientTransform="scale(2.4217071,0.4129318)"
4561+ gradientUnits="userSpaceOnUse" />
4562+ <linearGradient
4563+ y2="105.42543"
4564+ y1="76.277559"
4565+ xlink:href="#linearGradient892"
4566+ x2="8.346058"
4567+ x1="35.190362"
4568+ id="linearGradient1150"
4569+ gradientTransform="scale(1.3283861,0.7527932)"
4570+ gradientUnits="userSpaceOnUse" />
4571+ <linearGradient
4572+ y2="20.481863"
4573+ y1="49.507656"
4574+ xlink:href="#linearGradient892"
4575+ x2="70.224305"
4576+ x1="39.690614"
4577+ id="linearGradient1148"
4578+ gradientTransform="scale(1.329144,0.7523639)"
4579+ gradientUnits="userSpaceOnUse" />
4580+ <linearGradient
4581+ y2="113.71949"
4582+ y1="90.197025"
4583+ xlink:href="#linearGradient892"
4584+ x2="17.876529"
4585+ x1="39.810948"
4586+ id="linearGradient1146"
4587+ gradientTransform="scale(1.3207392,0.7571517)"
4588+ gradientUnits="userSpaceOnUse" />
4589+ <linearGradient
4590+ y2="251.21892"
4591+ y1="203.499"
4592+ xlink:href="#linearGradient892"
4593+ x2="31.617281"
4594+ x1="31.449743"
4595+ id="linearGradient1144"
4596+ gradientTransform="scale(2.1051174,0.4750329)"
4597+ gradientUnits="userSpaceOnUse" />
4598+ <linearGradient
4599+ y2="-0.45783132"
4600+ y1="3.3012049"
4601+ xlink:href="#linearGradient888"
4602+ x2="0.92957747"
4603+ x1="0.00000000"
4604+ id="linearGradient1141" />
4605+ <linearGradient
4606+ y2="232.24952"
4607+ y1="110.4447"
4608+ xlink:href="#linearGradient888"
4609+ x2="41.967061"
4610+ x1="45.685757"
4611+ id="linearGradient1140"
4612+ gradientTransform="scale(1.9102155,0.5235012)"
4613+ gradientUnits="userSpaceOnUse" />
4614+ <linearGradient
4615+ y2="75.912531"
4616+ y1="375.92199"
4617+ xlink:href="#linearGradient1806"
4618+ x2="-268.25407"
4619+ x1="-249.72067"
4620+ id="linearGradient1138"
4621+ gradientTransform="scale(1.087146,0.9198397)"
4622+ gradientUnits="userSpaceOnUse" />
4623+ <radialGradient
4624+ xlink:href="#linearGradient1133"
4625+ r="68.589222"
4626+ id="radialGradient1132"
4627+ fy="39.288476"
4628+ fx="72.107883"
4629+ cy="56.485935"
4630+ cx="60.004654"
4631+ gradientTransform="scale(1.2267534,0.8151598)"
4632+ gradientUnits="userSpaceOnUse" />
4633+ <linearGradient
4634+ y2="11.699047"
4635+ y1="208.43991"
4636+ xlink:href="#linearGradient888"
4637+ x2="95.644441"
4638+ x1="-77.726178"
4639+ id="linearGradient905"
4640+ gradientTransform="scale(1.0964158,0.9120627)"
4641+ gradientUnits="userSpaceOnUse" />
4642+ <linearGradient
4643+ xlink:href="#linearGradient1806"
4644+ id="linearGradient901" />
4645+ <linearGradient
4646+ y2="91.07699"
4647+ y1="-3.9104078"
4648+ xlink:href="#linearGradient888"
4649+ x2="27.674331"
4650+ x1="92.437968"
4651+ id="linearGradient891"
4652+ gradientTransform="scale(1.2267534,0.8151598)"
4653+ gradientUnits="userSpaceOnUse" />
4654+ <linearGradient
4655+ id="linearGradient888">
4656+ <stop
4657+ style="stop-color:#626262;stop-opacity:1.0000000;"
4658+ offset="0.0000000"
4659+ id="stop889" />
4660+ <stop
4661+ style="stop-color:#fff;stop-opacity:1;"
4662+ offset="1"
4663+ id="stop890" />
4664+ </linearGradient>
4665+ <linearGradient
4666+ id="linearGradient892">
4667+ <stop
4668+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
4669+ offset="0.00000000"
4670+ id="stop893" />
4671+ <stop
4672+ style="stop-color:#fff;stop-opacity:1;"
4673+ offset="1"
4674+ id="stop894" />
4675+ </linearGradient>
4676+ <linearGradient
4677+ id="linearGradient902">
4678+ <stop
4679+ style="stop-color:#000000;stop-opacity:0.00000000;"
4680+ offset="0.00000000"
4681+ id="stop903" />
4682+ <stop
4683+ style="stop-color:#000000;stop-opacity:0.22000000;"
4684+ offset="1.0000000"
4685+ id="stop904" />
4686+ </linearGradient>
4687+ <linearGradient
4688+ id="linearGradient1098">
4689+ <stop
4690+ style="stop-color:#ffffff;stop-opacity:1.0000000;"
4691+ offset="0.00000000"
4692+ id="stop1099" />
4693+ <stop
4694+ style="stop-color:#ffffff;stop-opacity:0.22314049;"
4695+ offset="0.50000000"
4696+ id="stop1101" />
4697+ <stop
4698+ style="stop-color:#ffffff;stop-opacity:0.00000000;"
4699+ offset="0.59930235"
4700+ id="stop1102" />
4701+ <stop
4702+ style="stop-color:#ffffff;stop-opacity:0.60330576;"
4703+ offset="1.0000000"
4704+ id="stop1100" />
4705+ </linearGradient>
4706+ <linearGradient
4707+ id="linearGradient1133">
4708+ <stop
4709+ style="stop-color:#8bb7df;stop-opacity:1.0000000;"
4710+ offset="0.00000000"
4711+ id="stop1134" />
4712+ <stop
4713+ style="stop-color:#2a6092;stop-opacity:1.0000000;"
4714+ offset="0.76209301"
4715+ id="stop1136" />
4716+ <stop
4717+ style="stop-color:#375e82;stop-opacity:1.0000000;"
4718+ offset="1.0000000"
4719+ id="stop1135" />
4720+ </linearGradient>
4721+ <linearGradient
4722+ id="linearGradient1317">
4723+ <stop
4724+ style="stop-color:#000000;stop-opacity:0.52892560;"
4725+ offset="0.00000000"
4726+ id="stop1318" />
4727+ <stop
4728+ style="stop-color:#000000;stop-opacity:0.17355372;"
4729+ offset="0.50000000"
4730+ id="stop1320" />
4731+ <stop
4732+ style="stop-color:#000000;stop-opacity:0.00000000;"
4733+ offset="1.0000000"
4734+ id="stop1319" />
4735+ </linearGradient>
4736+ <linearGradient
4737+ id="linearGradient893">
4738+ <stop
4739+ style="stop-color:#000;stop-opacity:1;"
4740+ offset="0"
4741+ id="stop895" />
4742+ <stop
4743+ style="stop-color:#fff;stop-opacity:1;"
4744+ offset="1"
4745+ id="stop896" />
4746+ </linearGradient>
4747+ <radialGradient
4748+ xlink:href="#linearGradient1806"
4749+ r="11.574221"
4750+ id="radialGradient1977"
4751+ fy="39.410465"
4752+ fx="42.280806"
4753+ cy="39.007645"
4754+ cx="42.007257"
4755+ gradientUnits="userSpaceOnUse" />
4756+ <linearGradient
4757+ id="linearGradient1806">
4758+ <stop
4759+ style="stop-color:#000000;stop-opacity:0.35051546;"
4760+ offset="0.0000000"
4761+ id="stop1807" />
4762+ <stop
4763+ style="stop-color:#000000;stop-opacity:0.13402061;"
4764+ offset="0.64999998"
4765+ id="stop3276" />
4766+ <stop
4767+ style="stop-color:#000000;stop-opacity:0.0000000;"
4768+ offset="1.0000000"
4769+ id="stop1808" />
4770+ </linearGradient>
4771+ <linearGradient
4772+ inkscape:collect="always"
4773+ xlink:href="#linearGradient1806"
4774+ id="linearGradient5281"
4775+ gradientUnits="userSpaceOnUse"
4776+ gradientTransform="scale(1.087146,0.9198397)"
4777+ x1="-249.72067"
4778+ y1="375.92199"
4779+ x2="-268.25407"
4780+ y2="75.912531" />
4781+ <linearGradient
4782+ inkscape:collect="always"
4783+ xlink:href="#linearGradient1806"
4784+ id="linearGradient5283"
4785+ gradientUnits="userSpaceOnUse"
4786+ gradientTransform="scale(1.087146,0.9198397)"
4787+ x1="-249.72067"
4788+ y1="375.92199"
4789+ x2="-268.25407"
4790+ y2="75.912531" />
4791+ <linearGradient
4792+ inkscape:collect="always"
4793+ xlink:href="#linearGradient1806"
4794+ id="linearGradient5285"
4795+ gradientUnits="userSpaceOnUse"
4796+ gradientTransform="scale(1.087146,0.9198397)"
4797+ x1="-249.72067"
4798+ y1="375.92199"
4799+ x2="-268.25407"
4800+ y2="75.912531" />
4801+ <radialGradient
4802+ xlink:href="#linearGradient4362"
4803+ r="5.5130484"
4804+ inkscape:collect="always"
4805+ id="radialGradient1828"
4806+ fy="61.38567"
4807+ fx="86.542037"
4808+ cy="61.38567"
4809+ cx="86.542037"
4810+ gradientTransform="matrix(-0.8164966,0,0,1.2247449,262.80373,-280)"
4811+ gradientUnits="userSpaceOnUse" />
4812+ <radialGradient
4813+ xlink:href="#linearGradient4362"
4814+ r="11.123441"
4815+ inkscape:collect="always"
4816+ id="radialGradient1824"
4817+ fy="58.887858"
4818+ fx="118.06427"
4819+ cy="58.54025"
4820+ cx="117.17439"
4821+ gradientTransform="matrix(-0.6229142,0,0,1.6053575,262.80373,-280)"
4822+ gradientUnits="userSpaceOnUse" />
4823+ <radialGradient
4824+ xlink:href="#linearGradient4362"
4825+ r="22.00904"
4826+ inkscape:collect="always"
4827+ id="radialGradient1822"
4828+ fy="87.892895"
4829+ fx="45.50637"
4830+ cy="88.322677"
4831+ cx="45.139623"
4832+ gradientTransform="matrix(-1.0914815,0,0,0.9161859,262.80373,-280)"
4833+ gradientUnits="userSpaceOnUse" />
4834+ <radialGradient
4835+ xlink:href="#linearGradient4362"
4836+ r="18.836343"
4837+ inkscape:collect="always"
4838+ id="radialGradient1818"
4839+ fy="33.351633"
4840+ fx="48.40165"
4841+ cy="32.467054"
4842+ cx="48.40165"
4843+ gradientTransform="matrix(-1.1146027,0,0,0.8971807,262.80373,-280)"
4844+ gradientUnits="userSpaceOnUse" />
4845+ <linearGradient
4846+ y2="74.834393"
4847+ y1="57.093738"
4848+ xlink:href="#linearGradient4376"
4849+ x2="50.203204"
4850+ x1="50.52668"
4851+ inkscape:collect="always"
4852+ id="linearGradient1815"
4853+ gradientTransform="matrix(-1.3516689,0,0,0.7398261,262.80373,-280)"
4854+ gradientUnits="userSpaceOnUse" />
4855+ <linearGradient
4856+ id="linearGradient4384">
4857+ <stop
4858+ style="stop-color:#ffffff;stop-opacity:0.77513230;"
4859+ offset="0.0000000"
4860+ id="stop4385" />
4861+ <stop
4862+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
4863+ offset="1.0000000"
4864+ id="stop4386" />
4865+ </linearGradient>
4866+ <linearGradient
4867+ id="linearGradient4376">
4868+ <stop
4869+ style="stop-color:#000000;stop-opacity:0.52645504;"
4870+ offset="0.0000000"
4871+ id="stop4377" />
4872+ <stop
4873+ style="stop-color:#000000;stop-opacity:0.0000000;"
4874+ offset="1.0000000"
4875+ id="stop4378" />
4876+ </linearGradient>
4877+ <linearGradient
4878+ id="linearGradient4362">
4879+ <stop
4880+ style="stop-color:#ffffff;stop-opacity:0.66666669;"
4881+ offset="0.0000000"
4882+ id="stop4363" />
4883+ <stop
4884+ style="stop-color:#ffffff;stop-opacity:0.0000000;"
4885+ offset="1.0000000"
4886+ id="stop4364" />
4887+ </linearGradient>
4888+ <linearGradient
4889+ id="linearGradient4358">
4890+ <stop
4891+ style="stop-color:#000;stop-opacity:1;"
4892+ offset="0"
4893+ id="stop4359" />
4894+ <stop
4895+ style="stop-color:#fff;stop-opacity:1;"
4896+ offset="1"
4897+ id="stop4360" />
4898+ </linearGradient>
4899+ <radialGradient
4900+ inkscape:collect="always"
4901+ xlink:href="#linearGradient1806"
4902+ id="radialGradient5536"
4903+ gradientUnits="userSpaceOnUse"
4904+ cx="42.007257"
4905+ cy="39.007645"
4906+ fx="42.280806"
4907+ fy="39.410465"
4908+ r="11.574221" />
4909+ <linearGradient
4910+ inkscape:collect="always"
4911+ xlink:href="#linearGradient1806"
4912+ id="linearGradient5538"
4913+ gradientUnits="userSpaceOnUse"
4914+ gradientTransform="scale(1.087146,0.9198397)"
4915+ x1="-249.72067"
4916+ y1="375.92199"
4917+ x2="-268.25407"
4918+ y2="75.912531" />
4919+ <linearGradient
4920+ inkscape:collect="always"
4921+ xlink:href="#linearGradient1806"
4922+ id="linearGradient5540"
4923+ gradientUnits="userSpaceOnUse"
4924+ gradientTransform="scale(1.087146,0.9198397)"
4925+ x1="-249.72067"
4926+ y1="375.92199"
4927+ x2="-268.25407"
4928+ y2="75.912531" />
4929+ <linearGradient
4930+ inkscape:collect="always"
4931+ xlink:href="#linearGradient1806"
4932+ id="linearGradient5542"
4933+ gradientUnits="userSpaceOnUse"
4934+ gradientTransform="scale(1.087146,0.9198397)"
4935+ x1="-249.72067"
4936+ y1="375.92199"
4937+ x2="-268.25407"
4938+ y2="75.912531" />
4939+ <linearGradient
4940+ inkscape:collect="always"
4941+ xlink:href="#linearGradient1806"
4942+ id="linearGradient5544"
4943+ gradientUnits="userSpaceOnUse"
4944+ gradientTransform="scale(1.087146,0.9198397)"
4945+ x1="-249.72067"
4946+ y1="375.92199"
4947+ x2="-268.25407"
4948+ y2="75.912531" />
4949+ <linearGradient
4950+ inkscape:collect="always"
4951+ xlink:href="#linearGradient888"
4952+ id="linearGradient5546"
4953+ gradientUnits="userSpaceOnUse"
4954+ gradientTransform="scale(2.4217071,0.4129318)"
4955+ x1="25.220815"
4956+ y1="178.48862"
4957+ x2="25.220815"
4958+ y2="234.26866" />
4959+ <linearGradient
4960+ inkscape:collect="always"
4961+ xlink:href="#linearGradient888"
4962+ id="linearGradient5548"
4963+ gradientUnits="userSpaceOnUse"
4964+ gradientTransform="scale(2.4217071,0.4129318)"
4965+ x1="51.460928"
4966+ y1="269.85831"
4967+ x2="-16.224496"
4968+ y2="176.28694" />
4969+ <linearGradient
4970+ inkscape:collect="always"
4971+ xlink:href="#linearGradient893"
4972+ id="linearGradient5550"
4973+ gradientUnits="userSpaceOnUse"
4974+ gradientTransform="scale(1.1870691,0.842411)"
4975+ x1="146.69923"
4976+ y1="224.57898"
4977+ x2="74.533693"
4978+ y2="81.477602" />
4979+ <linearGradient
4980+ inkscape:collect="always"
4981+ xlink:href="#linearGradient888"
4982+ id="linearGradient5552"
4983+ gradientUnits="userSpaceOnUse"
4984+ gradientTransform="scale(1.9102155,0.5235012)"
4985+ x1="45.685757"
4986+ y1="110.4447"
4987+ x2="41.967061"
4988+ y2="232.24952" />
4989+ <linearGradient
4990+ inkscape:collect="always"
4991+ xlink:href="#linearGradient888"
4992+ id="linearGradient5554"
4993+ gradientUnits="userSpaceOnUse"
4994+ gradientTransform="scale(1.0964158,0.9120627)"
4995+ x1="-77.726178"
4996+ y1="208.43991"
4997+ x2="95.644441"
4998+ y2="11.699047" />
4999+ <radialGradient
5000+ inkscape:collect="always"
The diff has been truncated for viewing.

Subscribers

People subscribed via source and target branches