Bazaar 2.xへのアップグレード作業は3段階あります:
Bazaar 2.xは以前のブランチのフォーマットをサポートしているので、厳密には3番目の手順は 必要ありません。しかし、Bazaar 2.xの新しいデフォルトフォーマットはより効率よく領域を使用する、 巨大なプロジェクトでより高速になる、さまざまな新しい特徴をそなえている、などの理由からほとんどのプロジェクトについて都合のよいときにでもアップグレードすることをおすすめします。
ほとんどのユーザの方は2.xへのアップグレードと新しいフォーマットへの移行に苦労しません。 しかしながら、大勢の開発者がいる(もしくは多くの開発者をようする)プロジェクトでは移行作業に手間がかかります。 この場合、注意深く計画をたてることとよいコミュニケーションが必要不可欠となります。 本文書はこの視点からの一般的なアドバイスを記載しています。 不安な点がありましたら、メーリングリストやIRCチャンネルで私たちにおたずねください。
コアソフトウェアの移行手順はオペレーティングシステムによって異なります。 Bazaar 1.xからBazaar 1.yへの移行とBazaar 1.xからBazaar 2.0への移行には特に違いはありません。手順の概要は以下のようになります。
Linuxでの移行手順:
たとえばUbuntuの正式なリリースのPPAは https://launchpad.net/~bzr/+archive です。
パッケージマネージャを使用して最新バージョンに移行する。
Windowsでの移行手順:
OS Xでの移行手順(インストーラを使用):
OS Xでの移行手順 (MacPortを使用):
インストールや移行に関する詳しい情報については 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ブランチかなどです。これらのシナリオについては次章で説明します。
移行を開始する前に、最初におこなうべきことがあります。
完全なバックアップはなにか悪いことがおきたときのセーフティネットとなります。
古いブランチの消去は移行対象となるデータを減らすことができます。これをおこなうためのいくつかのコツを `Finding obsolete branches`_ でご覧ください。
データ移行時には注意すべき3つの重要なコマンドがあります。
reconcile はめったに必要ではありませんが check を upgrade の前後で行うことは良い習慣です。
これらのコマンドの詳細なヘルプは Bazaarユーザーリファレンス をごらんください。
新しいフォーマットへのスムーズな移行を可能にするためには、以下が必須です:
事前に警告をしておくことによりコミュニティに所属する人々が 移行日より前に Bazaarや必要なpluginを移行するのに十分な余裕を持つことができるでしょう。
さらに大きなコミュニティにおいては、移行それ自身に要する時間に配慮しましょう。 試験移行の後でどのくらい移行に時間がかかるのかに関する良い案を持っておくべきです。移行を週末か金曜日に行うことで問題が発生したときにあなた自身が一息つける時間をとることができることは道理にかなっているでしょう。
trunkが移行したら、あなたはコミュニティに対して適切にお知らせし、彼らに彼ら自身のローカルブランチの移行説明書を示す必要があります。後ほど説明書の例を示します。
作業手順は以下のとおりです。:
移行は以下の手順で行ってください:
スタンドアロンブランチの例のように check を移行の前後に行って問題が存在していないか、あるいは問題がひきおこされていないかを確認してください。
公開ブランチとプライベートブランチを独立させるために、Launchpadでは共用リポジトリではなく、スタックブランチをディスク容量の効率化の中心技術として使用しています。したがってLaunchpadをコードホスティングに使用しているプロジェクトでは新しいフォーマットへの移行は個人や社内でしようしているとはことなります。
手順は次のようになります:
つまり、これらの手順の意味は 古い trunk がいぜんとして有効でスタックされたブランチが存在し続けるということです。しかしながら開発の中心は移行後の trunk に切り替わっており、以後のLaunchpadにpushされるあなたのプロジェクトの新しいブランチは(移行後のtrunkに)スタックされます。
この時点であなたはあなたのコミュニティに対して 新しいtrunkが有効になったことを知らせ、彼らに彼らのローカルブランチを移行する説明する準備ができました。
スタンドアロンブランチの移行手順:
ブランチを共用リポジトリに移行する手順:
- 新しいリポジトリで1つ空のブランチを init して古いリポジトリからリビジョンを pull する。
- 新リポジトリにおいて、 trunkから新しいブランチに branch した後古いリポジトリにおいてあなたが行った変更を merge する。
前者の方法は(リビジョンの履歴という意味において)古いブランチと同一のブランチを得ることができる一方、parentブランチは古いブランチを指してしまい、新しいtrunkをさしません。もしあなたがこの方法をとった場合、おそらく branch.conf ファイルの parentブランチに関する設定をしなおしたくなるでしょう。
それに比較して後者の方法は parentブランチは正確に設定されます。しかし、もしあなたがすべての最新のリビジョンをtrunkからそのブランチにincludeする用意ができていない限り理想的な方法にはなりません。
もしあなたが開発における各変更や個々に行っている拡張のためにブランチの機能を使っている場合、いくつかのもう必要とされないブランチを持つことになるかもしれません。たいていの場合、関係のある変更は trunkにマージされているはずです。そのほかの場合ブランチは自分あるいは他人が行った別の変更の結果、古くなっているはずです。
古いブランチをチェックするときには特に3つの点に注意があります。
ブランチのルートディレクトリに移動したあと、これらの点を個々にチェックするためのコマンドは以下です:
bzr status
bzr shelve --list
bzr missing --mine-only
もしあなたのブランチがローカルの共用リポジトリに入っているならば、(revision 159またはそれ以降の)Bazaar Explorerのリポジトリビューの中の Local Changed タブがあなたが選択したブランチについて、いまのところはshelveコマンドによって退避された変更を除き、上記の情報の概要を表示するので有用です。