Bazaar 2.0 移行ガイド

概要

移行手順の概要

Bazaar 2.xへのアップグレード作業は3段階あります:

1. コアソフトウェアの移行
2. 必要なプラグインの移行
3. 新しいデフォルトフォーマットへのデータ移行

Bazaar 2.xは以前のブランチのフォーマットをサポートしているので、厳密には3番目の手順は 必要ありません。しかし、Bazaar 2.xの新しいデフォルトフォーマットはより効率よく領域を使用する、 巨大なプロジェクトでより高速になる、さまざまな新しい特徴をそなえている、などの理由からほとんどのプロジェクトについて都合のよいときにでもアップグレードすることをおすすめします。

ほとんどのユーザの方は2.xへのアップグレードと新しいフォーマットへの移行に苦労しません。 しかしながら、大勢の開発者がいる(もしくは多くの開発者をようする)プロジェクトでは移行作業に手間がかかります。 この場合、注意深く計画をたてることとよいコミュニケーションが必要不可欠となります。 本文書はこの視点からの一般的なアドバイスを記載しています。 不安な点がありましたら、メーリングリストやIRCチャンネルで私たちにおたずねください。

コアソフトウェアの移行

コアソフトウェアの移行手順はオペレーティングシステムによって異なります。 Bazaar 1.xからBazaar 1.yへの移行とBazaar 1.xからBazaar 2.0への移行には特に違いはありません。手順の概要は以下のようになります。

Linuxでの移行手順:

1. 必要なソフトウェアのソースに関してお使いのパッケージマネージャの設定をおこなう。

   たとえばUbuntuの正式なリリースのPPAは https://launchpad.net/~bzr/+archive です。

2. パッケージマネージャを使用して最新バージョンに移行する。

Windowsでの移行手順:

1. 「プログラムの追加と削除」で古いバージョンを削除する。
2. 新しいバージョンのインストーラでインストールする。

OS Xでの移行手順(インストーラを使用):

1. 新しいバージョンのインストーラでインストールする。

OS Xでの移行手順 (MacPortを使用):

1. package metadataを更新する。 sudo port selfupdate
2. 最新のバージョンに更新する。 sudo port upgrade bzr

インストールや移行に関する詳しい情報については http://bazaar-vcs.org/Download をごらんください。

必要なプラグインの移行

多くのプラグインは特定のBazaarのバージョンに依存していないので、任意の作業です。 他のプラグイン、特にbzrtoolsとbzr-svnはBazaarのAPIにかたく結びついているので、 大体はコアソフトウェアとあわせて移行する必要があります。

WindowsやOS Xをお使いのかたは、bzrtoolsとbzr-svnはインストーラに付属していますので 移行にあたって特別な作業は必要ありません。LinuxやUNIXをお使いのかたは、bzrtools、bzr-svn や他の著名なプラグインをインストールしたり移行作業をお使いのプラットホームのパッケージマネージャ (たとえばUbuntuのSynaptic)でおこなうことができます。

新しいデフォルトフォーマットへのデータ移行

冒頭でも説明しましたように新しいフォーマットへの移行に伴う複雑さはいくつかの要因、特にプロジェクトの コミュニティの大きさに依存します。また、データがどのように保存されているかにも依存します。たとえば standaloneブランチとか、複数のブランチがshared repositoryに格納されているかとか、Launchpad上の stackedブランチかなどです。これらのシナリオについては次章で説明します。

データ移行

データ移行の準備

移行を開始する前に、最初におこなうべきことがあります。

1. 完全にバックアップをとってください。
2. 古いブランチを消去(purge)する時間をとってください。

完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。

古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを `Finding obsolete branches`_ 　でご覧ください。

移行に関連するコマンドの紹介

データ移行時には注意すべき3つの重要なコマンドがあります。

• check - リポジトリ、ブランチやツリーのデータ完全性に関するエラーのチェック。
• reconcile - データ完全性に関するエラーの修復。
• upgrade - 異なるデータフォーマットへの移行。

reconcile はめったに必要ではありませんが check を upgrade の前後で行うことは良い習慣です。

これらのコマンドの詳細なヘルプは Bazaarユーザーリファレンス をごらんください。

あなたのコミュニティとのコミュニケーション

新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:

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する用意ができていない限り理想的な方法にはなりません。

役立つヒントとコツ

古いブランチを見つける

もしあなたが開発における各変更や個々に行っている拡張のためにブランチの機能を使っている場合、いくつかのもう必要とされないブランチを持つことになるかもしれません。たいていの場合、関係のある変更は trunkにマージされているはずです。そのほかの場合ブランチは自分あるいは他人が行った別の変更の結果、古くなっているはずです。

古いブランチをチェックするときには特に3つの点に注意があります。

1. ワーキングツリーは変更の途中でないこと。
2. ワーキングツリー内にはbzr shelveコマンドによって退避された変更をふくんでいないこと。
3. どんなローカルでコミットされたリビジョンもparentブランチにマージされていること。

ブランチのルートディレクトリに移動したあと、これらの点を個々にチェックするためのコマンドは以下です:

bzr status
bzr shelve --list
bzr missing --mine-only

もしあなたのブランチがローカルの共用リポジトリに入っているならば、(revision 159またはそれ以降の)Bazaar Explorerのリポジトリビューの中の Local Changed タブがあなたが選択したブランチについて、いまのところはshelveコマンドによって退避された変更を除き、上記の情報の概要を表示するので有用です。