「妥当」な Mercurial ãƒãƒ¼ã‚¸ãƒ§ãƒ³ã®æƒ…å ±

※ 2015-01-19 更新

重要なお知らせ: 1.9 ⇒ 2.0、2.9 ⇒ 3.0、3.9 ⇒ 4.0 といったバージョン番号の増加でも、Mercurial のコンセプト／操作性／互換性等における大きな改変はありません。通常の定例アップデートに過ぎませんので、従来の版を元に書かれている情報の多くは、そのまま適用可能です。

現状でそこそこ妥当な Mercurial の版は以下の通りです。

由来不詳のリビジョンを含むリポジトリから履歴情報を取り込む可能性がある場合は、3.2.3 以降の使用を強く推奨
それ以外の場合は 1.8.1 〜 最新版
（使用状況によっては 2.2 〜 2.2.1 および 2.3 〜 2.3.2 の使用回避を推奨）

また、個別のケースにおいて回避を推奨する版の情報を以下に示します。

• revsets 記述によるリビジョン指定を多様する場合は、2.5 版以上を推奨(詳細はこちらのエントリを参照)。それ以前の版を使う場合は、2.3 版の使用を回避することを推奨 (詳細はこちらのエントリを参照) ※ 2013/02/07 æ›´æ–°
• cp932 (Shift-JIS) 環境でファイル名に日本語を使用する場合:
  • 2.3 〜 2.3.2 版の使用は回避することを推奨 (詳細は日本語 ML への投稿を参照) ※ 2012/10/11 追記 (2.4 版で解消済み)
  • 2.0 〜 2.1 版での largefiles エクステンションの使用は回避することを推奨 (※ 2.1.1 版で解消済み)
  • 1.9 版の使用は回避することを推奨　(※ 1.9.1 版で解消済み)
• 2.3 版と非同梱エクステンションを併用する場合、そのままでは動作しないケースがありますので、非同梱エクステンションを（対応済みの）最新版に更新するか、2.3 版以降の利用を回避してください(詳細は日本語 ML への投稿を参照) ※ 2012/08/16 追記
• TortoiseHg 経由で strip 操作を行う場合、上記と同じ原因で正常に機能しませんので、2.3 版 (+ TortoiseHg 2.4.3) の利用を回避してください ※ 2012/08/23 追記
• MacOS でのインストール (ソースからのビルド／パッケージ管理システムの使用) が失敗する場合、2.1.1 版を回避するか、バイナリ版のインストールしてください (※ 2.1.2 版以で解消済み)
• Windows/Mac OS などの case insensitive filesystem 上で MQ と併用する場合は、2.0.2 版の使用は回避することを推奨 (※ 2.1 版で解消済み)

「この版にはこういった問題がある」といった情報がありましたら、以下の方法などでお知らせください。

• 日本語ユーザグループのコミュニティハッシュタグ #mercurialjp 付での tweet
• 本エントリへのコメント／トラックバック
• 日本語ユーザグループへの投函

「妥当な版」情報の公開にあたって

ツール等の導入は、常に最新版に追従するのが良いのでしょうが、必ずしも追従可能な状況ばかりとは限りません。時間的／精神的な余裕から、開発環境の保守が滞る事は珍しくありません。

また、機能拡張によるバグの発生といった可能性もあるため、使用する機能の範囲で問題が無ければ、現状維持というのは妥当な判断です。

かく言う私自身も、仕事用環境の一部では未だに 0.9.5 版を使っていたりします(笑)。っつーか、厄介な grep 検索や、面倒なマージ処理が無ければ、1.0 前後の版で既に必要十分な機能が揃っている(or 問題があっても代替機能で迂回可能)ので、以下のような使い分けをすることで、環境更新コストを抑えています。

• ビルド／テストを行う環境は旧版のまま
• ソースの調査／参照を行う環境には極力新版を入れる

しかし、Mercurial のリリース毎 ChangeLog を見ても修正の詳細は明記されていませんから、アップデート要否の判定はなかなか難しいものがあります。

そこで、日常的に使用する主要な機能に関して「この版ではこういった問題を抱えている」という情報と、それを元にした「日常利用において妥当な版」についてまとめてみました。

扱う対象は「オフライン操作における機能」に関して、「一般的な期待と異なる結果になるケース」とします。「リポジトリ間連携」や「新規機能の導入」、「表示の体裁」、「デフォルト挙動の変更」などに関しては、深刻／重要なケースでない限り、基本的には除外します。

以下、問題情報の詳細。

セキュリティ障害 CVE-2014-9390 への対応 (※ 2015-01-19 追記)

由来不詳のリビジョンを含むリポジトリから、履歴情報を取り込む可能性がある場合、Mercurial 3.2.3 よりも古い版には、管理情報の書き換えや、不正なコマンドが実行される危険があります。

CVE-2014-9390 として知られるこのセキュリティ問題の詳細は、日本語MLへの投函を参照してください。

リポジトリフォーマット不正検出時におけるメッセージ表示問題(※ 2012/09/26 追記)

詳細に関しては、こちらのエントリを参照のこと。

2.2 〜 2.2.1 版での障害(※ 2012/05/16 追記)

2.2 〜 2.2.1 版には、以下のような問題があります。

• "commit --amend" されたリビジョンから、名前付きブランチ情報が失われる (詳細)
• pretxnchangegroup フック実行の際に、参照できないリビジョンがある (詳細)
• "hg serve" 等で長時間実行される場合に、メモリリークによって処理継続ができなくなる(詳細(英語)) ※ 2.2.1 で修正済み

上記の障害発生条件に当てはまる場合は、2.2 〜 2.2.1 版の使用は回避することをお勧めします。

MacOS でのインストールの失敗 (※ 2012/03/30 追記)

XCode の版(or インストール状況)によっては、MacOS でのインストールが、以下のメッセージを表示して失敗する可能性があります。

AttributeError: 'list' object has no attribute 'splitlines'

各種パッケージ管理システム (MacPorts 等) を使用する場合、インストール時に何らかのビルド処理が実施されるようなシステムでは、同様の現象が発生します。

2.1.1 版を回避すれば、この問題は発生しません。

MacOS 版は、バイナリ版も提供されていますので、障害修正が取り込まれる 2.1.2 版のリリースまでは、そちらを使用するという回避も可能です。

largefiles エクステンションでの日本語ファイル名の不具合 (※ 2012/02/12 追記)

2.0 版で追加された largefiles エクステンションですが、ファイル名のバックスラッシュ文字の置換処理が、CP932 (いわゆる Shift-JIS) に配慮しない実装でした。

そのため、文字コード設定が CP932 で、日本語を含むファイル名を使用する場合、largefiles エクステンションを併用していると、予期せぬ挙動となる可能性があります。

既に修正が取り込まれていますので、2012/03/01 前後にリリースが予定されている 2.1.1 版以降では、問題が解消される予定です。

それまでは、文字コード設定が CP932 な環境での largefiles エクステンション利用は回避することをお勧めします。

case insensitive filesystem 上での MQ ファイル追加の不具合 (※ 2012/01/02 追記)

2.0.2 版には、case insensitive filesystem 上での挙動に関する多数の修正が入りましたが、以下の全ての条件に合致する場合に、コマンド実行が中断してしまう、という現象が発生します。

• case insensitive filesystem 上で使用 (※ Windows の NTFS、Mac OS の HFS+ など)
• Mercurial Queue (MQ) を使用
• "hg qupsh" による変更で、ファイルの新規追加が生じる (＝ "hg add" 結果の qrefresh による取り込み)
• 上記で新規追加されるファイルの名前に大文字小文字が混在している

具体的な例で言うと、この変更で追加される手順の末尾で "hg qpush -a" する時点において、ファイルの新規追加が失敗してしまいます。

この問題を回避するための修正は、次のメジャーリリースで公開される default ブランチ側に取り込まれていますので、2012/02/01 にリリースが予定されている 2.1 版では解消される見込みです。

先述した条件に合致する恐れのある場合は、2.0.2 版の使用を回避することをお勧めします。

多バイト文字コードでのファイル名チェックの不具合 (※ 2011/07/16 追記)

プラットフォーム間での相互運用性を向上させるために、Windows 環境固有の特殊文字や、文字大小によるファイル名衝突の可能性に関して、1.9 版から各所にチェック機構が導入されました。

＃ add や update における中断／警告等

この処理を実現するに当たって、検証対象となるファイル名がバイト列として扱われているため:

• 2バイト目に ':*?"<>|' のいずれかを含む文字が不正文字扱いになる
• 2バイト目に A(0x41) 〜 Z(0x5a) を持つ文字が衝突要因の嫌疑を掛けられる

という現象が発生してしまいます。

＃ 詳細は日本語 ML での議論を参照してください

「Windows 環境のことなんぞ知ったことか！ファイル名も EUC や UTF-8 しか使わんもんね！」という方であれば問題ないのですが、日本語ファイル名の利用や、Windows 環境との相互運用の可能性がわずかでもある場合には、1.9 版の使用は回避することをお勧めします。

2011/08/02 追記 >>>> ここから

1.9.1 版で、この問題に対処するための修正が取り込まれましたので、日本語ファイル名を使用する可能性のある場合は、1.9.1 版を使用してください。

2011/08/02 追記 <<<< ここまで

名前つきブランチ間でのマージ挙動の変更 (※ 2011/03/06 追記)

1.8 版から、名前つきブランチ間でのマージにおける挙動が変更されました。

いわゆる fast-foward と呼ばれる形式で、履歴を極力直線化する方向に舵が切られています。

しかし、この挙動は「従来の merge とは異なる」ことと、「fast-forward 形式でのマージを回避する方法が無い」ことから、「fast-forward 以外は必要無い！」という嗜好の持ち主でもなければ、既存ユーザの乗り換えはあまり推奨できません。

なお、2011/03/06 時点で、好みに応じて fast-forward を抑止可能な変更の提案を開発者 ML に投函済みですので、上手く行けば、1.8.1 あたりで取り込まれるかもしれません。

2011/03/15 追記 >>>> ここから

fast-forward 形式のマージに関しては、開発者間でもあまり認識されていなかった模様で、検討の結果、採用を見送ることとなりました。

1.8.1 において、fast-forward 形式でのマージ機能は除去されています。

fast-forward 形式のマージを行ったリビジョンは、事後にマージ実施リビジョンであることを判定できませんので、1.8 の利用は推奨できません。

2011/03/15 追記 <<<< ここまで

-r によるリビジョン指定とファイル名指定併用時の挙動問題

log/grep コマンドにおいて、-r によるリビジョン指定とファイル名指定を併用した場合、処理の対象となるリビジョンを正しく認識できないことから、期待と異なる結果となる版があります。

この挙動は 1.6.3 〜 1.7 で発生しますので、この版の使用は推奨できません。

log コマンドの挙動問題

1.4 版より前の版では、log コマンドに -k オプションで複数のキーワードを指定した場合、すべてのキーワード指定が合致しないと、表示対象から除外されてしまいます。

対象ファイルの変更履歴を表示する場合、単純なファイル名指定だと期待と異なる結果となる可能性があるため、ファイル指定を -k で行う必要性も考えると、1.4 版以降の使用を推奨します。

grep コマンドの挙動問題

1.3 版より前の版では、grep コマンドにおける「該当記述の出現／消失」の判定が、「対象リビジョン〜その親リビジョン」の間ではなく、「対象リビジョン〜リビジョン番号上で1つ前のリビジョン」の間での差分を元に実施されてしまいます。

そのため、履歴上に分岐がある場合、期待と全く異なる結果となる可能性があります。