← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/ja/upgrade-guide/data_migration.txt

Turn completion assertions into separate methods.

Many common assertions used to be expressed as arguments to the complete
method.  This makes the checks more explicit, and the code easier to read.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/ja/upgrade-guide/data_migration.txt
1
 
データ移行
2
 
###############
3
 
 
4
 
データ移行の準備
5
 
-------------------
6
 
 
7
 
移行を開始する前に、最初におこなうべきことがあります。
8
 
 
9
 
1. 完全にバックアップをとってください。
10
 
 
11
 
2. 古いブランチを消去(purge)する時間をとってください。
12
 
 
13
 
完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。
14
 
 
15
 
古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを
16
 
`Finding obsolete branches`_ 　でご覧ください。
17
 
 
18
 
移行に関連するコマンドの紹介
19
 
----------------------------------
20
 
 
21
 
データ移行時には注意すべき3つの重要なコマンドがあります。
22
 
 
23
 
* **check** - リポジトリ、ブランチやツリーのデータ完全性に関するエラーのチェック。
24
 
 
25
 
* **reconcile** - データ完全性に関するエラーの修復。
26
 
 
27
 
* **upgrade** - 異なるデータフォーマットへの移行。
28
 
 
29
 
**reconcile** はめったに必要ではありませんが  **check** を **upgrade** の前後で行うことは良い習慣です。
30
 
 
31
 
これらのコマンドの詳細なヘルプは `Bazaarユーザーリファレンス`_ をごらんください。
32
 
 
33
 
.. _Bazaarユーザーリファレンス: ../user-reference/index.html
34
 
 
35
 
 
36
 
あなたのコミュニティとのコミュニケーション
37
 
---------------------------------------------------------
38
 
 
39
 
新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:
40
 
 
41
 
1. trunkの移行を行う責任者を1人きめること。
42
 
 
43
 
2. trunkの移行試験が成功すること。
44
 
 
45
 
3. trunkを移行する時間の予定をたてることと、前もってあなたのコミュニティに知らせておくこと。
46
 
 
47
 
事前に警告をしておくことによりコミュニティに所属する人々が 移行日より前に Bazaarや必要なpluginを移行するのに十分な余裕を持つことができるでしょう。
48
 
 
49
 
さらに大きなコミュニティにおいては、移行それ自身に要する時間に配慮しましょう。
50
 
試験移行の後でどのくらい移行に時間がかかるのかに関する良い案を持っておくべきです。移行を週末か金曜日に行うことで問題が発生したときにあなた自身が一息つける時間をとることができることは道理にかなっているでしょう。
51
 
 
52
 
trunkが移行したら、あなたはコミュニティに対して適切にお知らせし、彼らに彼ら自身のローカルブランチの移行説明書を示す必要があります。後ほど説明書の例を示します。
53
 
 
54
 
 
55
 
スタンドアロンブランチの移行
56
 
------------------------------------
57
 
 
58
 
作業手順は以下のとおりです。:
59
 
 
60
 
1. **bzr check** を起動します。
61
 
 
62
 
2. もしエラーが発生したら、**bzr reconcile** を使ってエラーの修復をこころみてください。もしこれが失敗したら問題を解決してあなたのtrunkをクリーンにするために私たちがお手伝いできるようバグの報告ください。もし成功したならクリーンなtrunkなうちにバックアップをとってください。
63
 
 
64
 
3. **bzr upgrade --format** を実行してください。**format** は 2a またはそれ以降のことです。
65
 
 
66
 
4. **bzr check** を起動して最終結果が正しいかどうかを確認してください。
67
 
 
68
 
 
69
 
共用リポジトリ中のブランチを移行
70
 
-----------------------------------------
71
 
 
72
 
移行は以下の手順で行ってください:
73
 
 
74
 
1. 共用リポジトリの移行。
75
 
 
76
 
2. ブランチの移行。
77
 
 
78
 
3. 軽量チェックアウトの移行。
79
 
 
80
 
スタンドアロンブランチの例のように **check** を移行の前後に行って問題が存在していないか、あるいは問題がひきおこされていないかを確認してください。
81
 
 
82
 
 
83
 
Launchpad上のブランチを移行
84
 
-------------------------------
85
 
 
86
 
公開ブランチとプライベートブランチを独立させるために、Launchpadでは共用リポジトリではなく、スタックブランチをディスク容量の効率化の中心技術として使用しています。したがってLaunchpadをコードホスティングに使用しているプロジェクトでは新しいフォーマットへの移行は個人や社内でしようしているとはことなります。
87
 
 
88
 
手順は次のようになります:
89
 
 
90
 
1. 指名された人がtrunkのコピーを持ち移行作業を実施します。
91
 
 
92
 
2. Launchpadにおいては 現在のtrunkを開発の中心(focus)からはずします。(これは *必ず* 実施してください、そうしないとこの後の手順が期待通りになりません。)
93
 
 
94
 
3. 移行した trunk をLaunchpadに push します。
95
 
 
96
 
4. 開発の中心(focus)に設定します。
97
 
 
98
 
5. 古い trunk に登録しているユーザに対して新しい trunk へ登録するよう依頼します。
99
 
 
100
 
つまり、これらの手順の意味は　古い trunk がいぜんとして有効でスタックされたブランチが存在し続けるということです。しかしながら開発の中心は移行後の trunk に切り替わっており、以後のLaunchpadにpushされるあなたのプロジェクトの新しいブランチは(移行後のtrunkに)スタックされます。
101
 
 
102
 
この時点であなたはあなたのコミュニティに対して 新しいtrunkが有効になったことを知らせ、彼らに彼らのローカルブランチを移行する説明する準備ができました。
103
 
 
104
 
 
105
 
中央の trunk が移行した後のローカルブランチ移行
106
 
-----------------------------------------------------------
107
 
 
108
 
スタンドアロンブランチの移行手順:
109
 
 
110
 
1. 中央リポジトリの場所から最新のブランチを新しいディレクトリに取得します。
111
 
 
112
 
2. 既存のブランチの中のあなたが行った修正を新しいブランチへpullあるいはmergeします。
113
 
 
114
 
ブランチを共用リポジトリに移行する手順:
115
 
 
116
 
1. 新しい共用リポジトリを新フォーマット(2aあるいはそれ以降)で作成します。
117
 
 
118
 
2. 中央リポジトリから最新のブランチを作成した共用リポジトリへ格納します。
119
 
 
120
 
3. あなたのローカルブランチで移行したいものを決定します。
121
 
   (もし決定していなければ、もちろんバックアップした後、
122
 
   `Finding obsolete branches`_ をしてそのブランチを消去するのによい時間です。)
123
 
 
124
 
4. 各ローカルブランチの移行に関して2つ選択肢があります。
125
 
 
126
 
 * 新しいリポジトリで1つ空のブランチを **init** して古いリポジトリからリビジョンを **pull** する。 
127
 
 
128
 
 * 新リポジトリにおいて、 trunkから新しいブランチに **branch** した後古いリポジトリにおいてあなたが行った変更を **merge** する。
129
 
 
130
 
前者の方法は(リビジョンの履歴という意味において)古いブランチと同一のブランチを得ることができる一方、parentブランチは古いブランチを指してしまい、新しいtrunkをさしません。もしあなたがこの方法をとった場合、おそらく branch.conf ファイルの parentブランチに関する設定をしなおしたくなるでしょう。
131
 
 
132
 
それに比較して後者の方法は parentブランチは正確に設定されます。しかし、もしあなたがすべての最新のリビジョンをtrunkからそのブランチにincludeする用意ができていない限り理想的な方法にはなりません。