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