くまりゅう日記

もっと過去の日記
[.NET | BeOS | Blender | COLLADA | fossil | mono | monotone | NPR | OpenGL | PeerCastStation | Riko | Ruby | Silverlight | TRPG | XNA | ゲーム | ゲーム作り | ]

2006-04-24 起動せず

_ やばい

なんかWindowsが起動しなくなったりした。

もう単なる配信用マシンだったので、結局再インストールしたけど。Macがメインで良かったよ。

と思ったらMacも起動しなくなった!?

OS起動時のリンゴアイコンがバツアイコンなんですけど。

再起動で直った。良かった。でもなんだったんだろう。

_ メモリ

Parallels立ち上げてるとメモリ足りねーな。

でも調べたらメモリ高いのね。

iMacだとノート用になるしDDR2のPC5300って全然売ってない。

バルクを探しに秋葉原まで行くのめんどうだな。通販なら安いか。

_ [monotone] 0.26

訳しました。リリースから2週間以上たっちゃったね。

NEWSはここから。

2006年4月8日(土) 

0.26が出ました。大幅な機能拡張と内部的な書き直しがありました。
重要な変更が書いてあるので注意して読んで下さい。
特に0.26にアップグレードするにはマイグレーションに注意を払う必要があります。
他の人とプロジェクトの作業をしてる場合は要注意。
詳細についてはUPGRADEを見て下さい。

3つのプレリリースでかなり変更があり、それぞれでの変更点は下にあります。
しかし、便利なようにこのリリースノートには0.25からの全ての変更点を挙げています。
個々のプレリリースの分を読む必要はありません。

0.25からの大きな変更点:
- ユーザーから見た一番大きな変更点は、monotoneのバイナリの名前がデフォルトで'mtn'になったことです。
  つまり、'monotone checkout'、'monotone diff'、'monotone commit'とかやるかわりに
  'mtn checkout'、'mtn diff', 'mtn commit'とかになりました。
- 同じようにワークスペースの管理情報ディレクトリの名前が"MT"から"_MTN"に変わりました。
  このリリースに更新する時には普通ワークスペースを作り直すことになるので、問題にはならないはずです。
- 'execute'などのような組み込み属性も名前の頭に'mtn:'が付くようになりました。
  例えば、実行ファイルは'mtn:execute'を持ち、'true'に設定されているといった風になります。
  マイグレーションでは自動でこのプレフィックスを付けるので特に操作は必要はありません。
- ignoreファイルの名前が'.mt-ignore'から'.mtn-ignore'になりました。
  マイグレーションでは自動でこのファイル名変更を行なうので特に操作は必要はありません。
- データベースの拡張子は'.mtn'が推奨になりました。
  これらの変更は見た目の問題だけなので、機能的にはなんら変わりはありません。

- 開発者側から見た一番大きな変更点はツリーを表わすデータ構造が完全に変わり、
  それに関連するコードが書き直されたことでしょう。
  新しいデータ構造は'roster'と呼ばれます。
  この名前は覚える必要はありません。
  monotoneのハックや各種デバッグ操作を行なうのでなければrosterの名を見ることは無いでしょう。
  誰かが'roster-enabled monotone'と言った時は
  この新しいコードのことを指しているものだと覚えておくのはいいかもしれません。

  これに共なう変更は以下の通り:
  - リビジョンとマニフェストのテキスト表現が変わりました。
    概念は変わらず、以前と同じ情報を含み、同じように動作します。
    表現は経験的に分かった問題を解決し、拡張性を持つように整理されました。
    しかし、この変更によりマイグレーションは一斉に行なわれなければなりません。
    詳しくはUPGRADEを見て下さい。
  - ディレクトリはファーストクラスのオブジェクトになりました。
    空のディレクトリを追加できるようになったり、ディレクトリを消す時にはdropしたりするようになりました。
  - 属性もファーストクラスオブジェクトになりました。
    '.mt-attrs'はもうありません。
    属性はマニフェストに直接記述され、変更はリビジョンに直接反映されます。
    マイグレーションでは従来の.mt-aatrsファイルを自動的にファーストクラスの属性に変換します。
    もしカスタムの属性を付けていたら特別な手順を踏む必要があります。
    その場合はアップグレーダーがその旨を伝えます。
  - マージのコードは完全に書き換えられました。
    インターフェースは今のところそのままで(この改訂でより良いように改造し易くなりましたが)、
    以前にmonotoneはマージが楽だなと思った時のものから何が変わったのか分からないでしょう。
    しかし問題にぶち当たった時、新しいマージはあなたの人生を劇的に楽にしてくれるはずです。
    それには名前変更の完全サポート(ディレクトリとファイルの両方)、属性の賢いマージ、
    ファイル内容のマージの改良が含まれます。
    初登場のマージ機構の実装は、正しさが証明されているアルゴリズム(マルチスターマージアルゴリズム)
    に基づいており、自動化されたテストで十分テストされ一般的に十分な精度を持つ保守的なマージです。
  - 新しいコードは全般的に速くなりました。でもまだ速くできるはずです。

Netsyncの変更:
- デフォルトのnetsyncポート番号が5253から4691に変更されました。
  4691はIANAに公式に割り当てられたポートです。
  ファイアウォールの設定を合わせて下さい。
- Netsyncのコードも大きく変更されました。
  新しいコードはより多くの最適化の余地をもたらすでしょう。
- 以前のバージョンとはプロトコルの互換性はありません。
  これはそれほど驚くことではありません。
  すでにデータ構造からして非互換ですから……(上記参照)。

新機能:
- 'annotate'に分かりやすい出力をする--briefオプションが追加されました。
- ログの強化:
  - 子のリビジョン(親ではなく)を表示する--nextオプションが追加されました。
  - 'log -r'にあいまいなセレクタを渡した時にあいまいさの解決をせずに、
    マッチする全てのリビジョンのログを表示するようになりました。
  - --no-filesオプションが追加されました。.
- 'show_conflicts'コマンドが追加されました。マージのドライランを実行します。
- 'ls changed'コマンドが追加されました。
- 'rename'(と別名である'mv')は様々な入力を受け入れるようになりました:
  mtn rename foo some_dir
    -> fooをsome_dir/fooにリネームします。
  mtn rename foo bar baz some_dir
    -> foo、bar、bazをそれぞれsome_dir/foo、some_dir/bar、some_dir/bazにリネームします。
- 新たなフック'validate_commit_message'はコミット時のメッセージが
  ユーザーの決めたルールに合っているか検証します。
- --logオプションが追加され、monotoneの出力をファイルに記録できるようになりました。
- 'drop --recursive'オプションでディレクトリとその中身を一度に消せるようになりました。
- ルートディレクトリがリネームできるようになりました。
  これは特に目立った機能ではありませんが、
  プロジェクトを分けたりくっつけたりする時に便利でしょう。
  詳しくは新コマンドの'pivot_root'と'merge_into_dir'を参照して下さい。

マイナーバグの修正:
- IPv6サポートがあるCライブラリとサポートの無いカーネルの組み合わせで、
  --bind引数が無い'serve'が失敗するのを修正しました。
- 内部ファイル名が正しいUTF-8であるかのチェックを厳しくしました。
- データベースがワークスペース内にあるとき、常に無視されるようになりました。
- 非ユニコードのコードセットでフランスのロケール(fr)を使った時にエラーになるのを修正しました。

その他の変更:
- パケット関連のコマンド('rdata'、'fdata'など)は'automate'に移動しました。
- データベースへのデータ格納にsqliteのblob機能をつかうようになり、
  データベースファイルのサイズは1/4程小さくなりました。
- sqlite 3.3を使うようになりました。
  これにより古いバージョンのコマンドラインクライアント
  (sqlite 3.2などで作られた'sqlite3'コマンド等)はmonotone 0.26のデータベースには使用できません。
  解決方法はsqlite3をアップグレードすることです。
  ほとんどのユーザーには関係無いものと願うのですが……。
- 訳が更新され、新たに3つの翻訳(de, it, sv)が追加されました。

信頼性についての注意:
- 新しいコードはまだ0.25でのコード程、現実に即した環境でのテストをされていません。
  2006年1月8日からmonotoneの開発に使用されてきましたが、あまり多くのバグは見つかっていません。
  見つかったバグはいずれも小さなもので、データが失われるような危険につながるものはありませんでした。
  さらに新しいアプローチには以前のものより理論的に信用でき、
  テストは新しいコードの全てのパスを試験しています。
  しかし、これらは現実での経験の代替になるものではありません
  私達はこのバージョンへのアップグレードに注意するように勧告し、
  特に果敢にアップグレードするような人は、
  アップグレードの前後にmonotoneのメーリングリストに気を配ることをお勧めします。

UPGRADEはここから。

monotoneを0.26にアップグレード
==========================

このファイルの読みかた:
  - まずどのバージョンからアップグレードするのか調べます。例えば0.22とか。
  - 下のリストを見ていき"バージョンX以前"と書かれた所の手順を実行します(Xは0.22以上)。
    0.22からのアップグレードの例では"0.25以前"の手順と"0.23以前"の手順の両方を実行します。
  - 特何も書かれていない所では、何もすることはありません。
    例えば0.23から0.24へのアップグレードでは何もすることはありません。
  - NEWSに書かれているリリースノートは読んでおくと良いでしょう。
    コマンドラインのオプションの変更や新しいコマンドなどはそちらに書いてあります。

アップグレードする:
  - 0.25以前: このセクションをしっかり読んで下さい。
  リビジョンやマニフェストに使われていたテキスト表現が変更され、古いmonotoneでは
  新しいフォーマットを読むことは出来ず、新しいmonotoneでは古いフォーマットは変換しない
  限り読むことが出来ません。
  アップグレードの前にNEWSを読んでおいて下さい。
  プロジェクトの履歴を作り直す必要があるのですが、これは元に戻すことは出来ず、
  一斉に行なう必要があります。
  つまりプロジェクトに関わる全員が一斉に切り替える必要があるのです。

マイグレーション前のデータベースと後のデータベースでリビジョンの同期を取ることは出来ず、
各プロジェクトのマイグレーションは一つのデータベースで一度だけ実行するようにしましょう。
だれか一人が各プロジェクトについて一度ずつマイグレーションを実行したら、
その他の人はそこからpullし直すようにします。

マイグレーションの本番の前に手元でマイグレーションのテストで上手くいくか確認しておいた方が良いでしょう。
本番を実行するには:
      1) 全員コミットし、マイグレーションをするデータベース
         (もしあれば中央サーバーみたいなもの)にpushしておきます。
         ローカルなデータベースやワーキングコピーはマイグレーション以後使用できなくなります。
      2) サーバーを止めます。
      3) 'cp server.db server.db.backup'を実行します。
      4) 'mtn db migrate --db server.db'を実行します。
      5) 'mtn db rosterify --db server.db'を実行します。
      6) 上手くいったか適当に確認します。
      7) ファイアウォールを確認して新しいnetsyncのポート番号4691が接続許可されるようにして下さい。
      8) サーバーを起動します。
      9) 新しいバージョンのmonotoneを使って新規のデータベースにpullしてくるように皆に伝えます。
    このマイグレーションは"ベストエフォート"です。
    古いコードでのリネーム処理のバグでぶっこわれた部分を持つ履歴はマイグレートできません。
    しかし、出来るだけ(リネームを含む)全てを保つように努力はしますし、
    履歴グラフのエントリーやツリー構造やファイルの内容は正確に保存されることは保証します。

    アップグレード後の一番の変更は全てのリビジョンが変更され、
    結果として全てのcertが付け直されなければならないことです。
    つまり、アップグレード後は全てのcertは最初に付けた人ではなく、
    アップグレードを行なった人の署名が付くということです。
    これは署名の根本的な性質であり、これについてなんとか出来ることは
    ほぼありませんでした。

    もしあなたがプライベートなブランチを持っていて、プロジェクトの"マイグレーション係"
    ではなかったとしても、そのブランチを残すことは可能です。
    しかし、そのためには何が行なわれているのかもっと正確に把握する必要があり、
    その解説はこのドキュメントの対象からは外れてしまいます。
    その方法についてはhttp://venge.net/monotone/wiki/RosterifyingPrivateBranchesを参照して下さい。
    それでもコマンドの裏で何がどうなってるのか分からなければ、
    メーリングリスト(monotone-devel@nongnu.org)やIRC(#monotone on irc.OFTC.net)で喜んで解説します。

    リビジョン/マニフェストのフォーマット変更や大きな一斉変更は今後は無いように
    ささやかながら期待していますが、これが正しかったかどうかを示すのは経験しかありません。

    上記の手順で質問や気になるところがあれば、
    是非メール(monotone-devel@nongnu.org)で報せるか、
    IRC(#monotone on irc.OFTC.net)で話して下さい。

ほんとは、UPGRADEに0.23 or earlierとかの続きがあるんだけど省略。短いから軽く読んでね。

あと訳は適当なんで、まあ、うん、適当に。


ページのトップへ | トップ «前の日記(2006-04-17) 最新 次の日記(2006-04-30)» | 編集 | kumaryu.net by kumaryu