1 files changed, 132 insertions, 0 deletions
diff --git a/doc/ja/upgrade-guide/data_migration.txt b/doc/ja/upgrade-guide/data_migration.txt
new file mode 100644
index 0000000..aa4bf89
--- /dev/null
+++ b/doc/ja/upgrade-guide/data_migration.txt
@@ -0,0 +1,132 @@
+データ移行
+###############
+
+データ移行の準備
+-------------------
+
+移行を開始する前に、最初におこなうべきことがあります。
+
+1. 完全にバックアップをとってください。
+
+2. 古いブランチを消去(purge)する時間をとってください。
+
+完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。
+
+古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを
+`Finding obsolete branches`_ 　でご覧ください。
+
+移行に関連するコマンドの紹介
+----------------------------------
+
+データ移行時には注意すべき3つの重要なコマンドがあります。
+
+* **check** - リポジトリ、ブランチやツリーのデータ完全性に関するエラーのチェック。
+
+* **reconcile** - データ完全性に関するエラーの修復。
+
+* **upgrade** - 異なるデータフォーマットへの移行。
+
+**reconcile** はめったに必要ではありませんが  **check** を **upgrade** の前後で行うことは良い習慣です。
+
+これらのコマンドの詳細なヘルプは `Bazaarユーザーリファレンス`_ をごらんください。
+
+.. _Bazaarユーザーリファレンス: ../user-reference/index.html
+
+
+あなたのコミュニティとのコミュニケーション
+---------------------------------------------------------
+
+新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:
+
+1. trunkの移行を行う責任者を1人きめること。
+
+2. trunkの移行試験が成功すること。
+
+3. trunkを移行する時間の予定をたてることと、前もってあなたのコミュニティに知らせておくこと。
+
+事前に警告をしておくことによりコミュニティに所属する人々が 移行日より前に Bazaarや必要なpluginを移行するのに十分な余裕を持つことができるでしょう。
+
+さらに大きなコミュニティにおいては、移行それ自身に要する時間に配慮しましょう。
+試験移行の後でどのくらい移行に時間がかかるのかに関する良い案を持っておくべきです。移行を週末か金曜日に行うことで問題が発生したときにあなた自身が一息つける時間をとることができることは道理にかなっているでしょう。
+
+trunkが移行したら、あなたはコミュニティに対して適切にお知らせし、彼らに彼ら自身のローカルブランチの移行説明書を示す必要があります。後ほど説明書の例を示します。
+
+
+スタンドアロンブランチの移行
+------------------------------------
+
+作業手順は以下のとおりです。:
+
+1. **bzr check** を起動します。
+
+2. もしエラーが発生したら、**bzr reconcile** を使ってエラーの修復をこころみてください。もしこれが失敗したら問題を解決してあなたのtrunkをクリーンにするために私たちがお手伝いできるようバグの報告ください。もし成功したならクリーンなtrunkなうちにバックアップをとってください。
+
+3. **bzr upgrade --format** を実行してください。**format** は 2a またはそれ以降のことです。
+
+4. **bzr check** を起動して最終結果が正しいかどうかを確認してください。
+
+
+共用リポジトリ中のブランチを移行
+-----------------------------------------
+
+移行は以下の手順で行ってください:
+
+1. 共用リポジトリの移行。
+
+2. ブランチの移行。
+
+3. 軽量チェックアウトの移行。
+
+スタンドアロンブランチの例のように **check** を移行の前後に行って問題が存在していないか、あるいは問題がひきおこされていないかを確認してください。
+
+
+Launchpad上のブランチを移行
+-------------------------------
+
+公開ブランチとプライベートブランチを独立させるために、Launchpadでは共用リポジトリではなく、スタックブランチをディスク容量の効率化の中心技術として使用しています。したがってLaunchpadをコードホスティングに使用しているプロジェクトでは新しいフォーマットへの移行は個人や社内でしようしているとはことなります。
+
+手順は次のようになります:
+
+1. 指名された人がtrunkのコピーを持ち移行作業を実施します。
+
+2. Launchpadにおいては 現在のtrunkを開発の中心(focus)からはずします。(これは *必ず* 実施してください、そうしないとこの後の手順が期待通りになりません。)
+
+3. 移行した trunk をLaunchpadに push します。
+
+4. 開発の中心(focus)に設定します。
+
+5. 古い trunk に登録しているユーザに対して新しい trunk へ登録するよう依頼します。
+
+つまり、これらの手順の意味は　古い trunk がいぜんとして有効でスタックされたブランチが存在し続けるということです。しかしながら開発の中心は移行後の trunk に切り替わっており、以後のLaunchpadにpushされるあなたのプロジェクトの新しいブランチは(移行後のtrunkに)スタックされます。
+
+この時点であなたはあなたのコミュニティに対して 新しいtrunkが有効になったことを知らせ、彼らに彼らのローカルブランチを移行する説明する準備ができました。
+
+
+中央の trunk が移行した後のローカルブランチ移行
+-----------------------------------------------------------
+
+スタンドアロンブランチの移行手順:
+
+1. 中央リポジトリの場所から最新のブランチを新しいディレクトリに取得します。
+
+2. 既存のブランチの中のあなたが行った修正を新しいブランチへpullあるいはmergeします。
+
+ブランチを共用リポジトリに移行する手順:
+
+1. 新しい共用リポジトリを新フォーマット(2aあるいはそれ以降)で作成します。
+
+2. 中央リポジトリから最新のブランチを作成した共用リポジトリへ格納します。
+
+3. あなたのローカルブランチで移行したいものを決定します。
+   (もし決定していなければ、もちろんバックアップした後、
+   `Finding obsolete branches`_ をしてそのブランチを消去するのによい時間です。)
+
+4. 各ローカルブランチの移行に関して2つ選択肢があります。
+
+ * 新しいリポジトリで1つ空のブランチを **init** して古いリポジトリからリビジョンを **pull** する。 
+
+ * 新リポジトリにおいて、 trunkから新しいブランチに **branch** した後古いリポジトリにおいてあなたが行った変更を **merge** する。
+
+前者の方法は(リビジョンの履歴という意味において)古いブランチと同一のブランチを得ることができる一方、parentブランチは古いブランチを指してしまい、新しいtrunkをさしません。もしあなたがこの方法をとった場合、おそらく branch.conf ファイルの parentブランチに関する設定をしなおしたくなるでしょう。
+
+それに比較して後者の方法は parentブランチは正確に設定されます。しかし、もしあなたがすべての最新のリビジョンをtrunkからそのブランチにincludeする用意ができていない限り理想的な方法にはなりません。