彷徨えるフジワラ

年がら年中さまよってます

Mercurial に関するコミュニティ由来の成果(2013年版)

mercurial hg-hack hg-community 年越し

本エントリは、2013年の一年間に、ML/twitter/勉強会といったコミュニティから上がった情報／要望の中で:

  • Mercurial 本体に取り込まれた修正の契機になったもの
  • Mercurial 本体に取り込まれてはいないものの、何らかの成果に結びついたもの
  • 『今後の作業のネタ』(＝ バックログ)として認識されているもの

上記に該当するものを、情報提供への感謝の意味も込めて、列挙したものです（2012年版もあります）。

『気になった点に関して、情報提供をする』だけでも、十分開発に貢献できる事の証拠とも言えます。

今後も、Mercurial に関して疑問／質問／要望等があれば、お気軽に情報をお寄せください ＞ 利用者の皆様

情報をお寄せ頂く手段に関しては、"Mercurial で困った時に" をお読みください。

また、抽出が大変だったので本エントリでは列挙しませんでしたが、メッセージ翻訳に関する不具合報告／要望等も随時反映しておりますので、こちらに関してもお気軽にお知らせください＆お知らせ頂いた皆様、ありがとうございました！

本体に取り込まれた修正(changed by 藤原)

以下に列挙するものは、コミュニティからの情報を元に私が提案した修正のうち、Mercurial 本体に取り込まれたものです。

なお、私の手による修正履歴一覧から、記憶を頼りに目視で抽出したものなので、『俺の情報を元にパッチ作成しておいて手柄を独り占めかよ！？』的なものに心当たりがある方は、お気軽に情報をお寄せください(笑)。

● Windows 向け hg.bat での hg.exe パス指定

というツイートを元に提案した、以下の修正が取り込まれました。

※ BTS にも issue 2512 として報告されているのを見つけました

● Windows でのパスワードプロンプトの文字化け

去年の年末時点で、以下の障害を把握はしていたのですが:

手が空かずに、原因究明を後回しにしていたところ:

との情報を頂き、Python側実装の確認をした上で提案した、以下の修正が取り込まれました。

● ローカルタグによる上書き

というツイートを元に提案した、以下の修正が取り込まれました。

  • cb95716da5fe: tags: update tag type only if tag node is updated (issue3911)
  • 335a558f81dc: tags: write tag overwriting history also into tag cache file (issue3911)

● 同名ファイル／ディレクトリの予期せぬ衝突回避

というツイートを元に提案した、以下の修正が取り込まれました。

● "hg help -k KEYWORD" での異常終了

というツイートに対して、TortoiseHg コミッタの西原さんから:

というコメントがあったので、西原さんからのパッチ投函を期待していたのですが、一向に投函が無かったので、私の方でやっつけることに(笑)。

単純に『ui 引数の追加(+ 内部的な表示の破棄)』で済むかと思っていたら、本質的には『エクステンション引き当てでの名前指定の非互換』の問題だったようで、最終的に以下のような修正が取り込まれました。

  • 83d79a00cc24: help: use full name of extensions to look up them for keyword search

● 不正な rebase 状態情報への対応

Mercurial 2.7 以降から、rebase/histedit/graft/transplant が完了しない間は、update や commit、strip をできなくする、というガード機能が入りました。

しかし、それ以前の版では、rebase/histedit/graft/transplant が未完了でも update や strip ができるため、コマンドの内部管理情報が整合性を失ってしまう可能性があります。

Mercurial を 2.7 以降に更新した際に、旧来のリポジトリを clone して、clone 先に乗り換えてしまえば良いのですが、（最も一般的なケースである）そのまま使い続けた場合には、忘れて放置されていた未完了の rebase/histedit/graft/transplant 状態情報のために、以下のような問題が発生する可能性があります。

この問題、最初は単に『未完了な rebase 状態情報がクリアできればOK』と思っていたので:

などと返信したのですが、実のところ rebase/histedit/graft/transplant の完了待ち周りは、以下のようになっています。

未完了の処理update(状態クリア)--abort機能(状態クリア／履歴破棄)
graft 許可 なし
transplant 許可 なし
rebase 禁止 あり
histedit 禁止 あり

rebase や histedit の状態をクリアするためには、--abort オプション付きでの実行が必須となりますので、当初のツイートのような『--abort 実行ができない』というケースでは、八方塞りになってしまうわけです。

そこで、以下のような修正を提案し、取り込まれました。

  • 577f4c562d52: rebase: catch RepoLookupError at restoring rebase state for abort/continue

また、未完了状態に関する同様の問題の修正として、以下のものも取り込まれました。

  • e7fa36d2ad3a: rebase: catch RepoLookupError at restoring rebase state for summary
  • 45c3086880c7: histedit: suggest "histedit --abort" for inconsistent histedit state

● 複数ヘッド push 時のヒントメッセージの改善

昨年末に見つけて、個人的なバックログに積んであった上記ツイートに対処するための、以下の一連の修正が取り込まれました。

  • bfc6ed892349: push: hide description about "-f" in the hint to prevent from using it easily
  • 4f53de036af8: push: add more detailed explanation about "--force" to online help document

上記ツイートは、間接的にではありますが、『複数ヘッドの push』に関する以下の修正の契機にもなっています。

  • b00ba31313c3: discovery: abort also when pushing multiple headed new branch
  • 8179eb28983b: discovery: revise hint message introduced by changeset b00ba31313c3

● Python モジュールの import 問題

Mercurial 日本語 ML に、『hgsubversionを使った ssh経由の接続は可能ですか?』と題して、以下のような投函がありました。

hgsubversionを入れたんだけど、ssh経由でsvnのリポジトリを扱うことはできないのでしょうか?

hg svn clone svn+ssh://svn/data/repos
こんなのはだめですか?

hgsubversion が受け付けるのは以下のような形式なので:

$ hg clone http://user:sekrit@example.com/repo
$ hg clone https://user@example.com/repo
$ hg clone svn://example.com/repo
$ hg clone svn+ssh://example.com/repo
$ hg clone file:///tmp/repo

単なる URL 指定の間違いでは？と返信したのですが、実際には Python モジュールの import で失敗しているとのこと。

実行するとエラーになるので、もしかしてssh経由のhgsubversionは実はだめなのかなと思って質問しました。

実行結果:
$ hg clone svn+ssh://svn//data/repos/
複製先ディレクトリ: repos
中止: No module named hgsubversion!

発生状況の確認をしている間に、他の方から『既知の障害なのでは？』との情報が寄せられました。

コマンド実行時のオーバヘッドを減らすために、Mercurial では Python モジュールの import を遅延させる仕組みを導入しているのですが、色々調べてみると、その実装に問題があるようです。

最終的に、以下の修正提案が取り込まれました。

  • 621a26eb3a99: demandimport: allow extensions to import own modules by absolute name

また、修正提案の過程で、エクステンション自身のモジュール import 以外にも、エクステンションから参照されるサードパーティライブラリの import でも障害が報告されていることが判明したため、追加的に提案した以下の修正も取り込まれました。

  • e3a5922e18c3: demandimport: support "absolute_import" for external libraries (issue4029)

● サブリポジトリとフェーズ指定

上記のようなツィートを見かけたので:

と返信したところ:

という結果に。

確かに当該時点では、親リポジトリでの新規コミットのフェーズの決定は、参照先サブリポジトリのフェーズを完全に無視していました。てっきり「親リポジトリ／サブリポジトリを共に MQ 管理」という運用だと思い込んでいたので、このルートは盲点でした。

最終的に、以下の修正提案が取り込まれました。

  • 4c96c50ef937: subrepo: check phase of state in each subrepositories before committing

何らかの成果に結びついたもの

以下は、Mercurial 本体には取り込まれていませんが、コミュニティからの要望を契機に、何らかの成果に結びついたものです。

● 部分コミットのためのガード機能

commitguard エクステンションは、以下のツイートを契機に実装しました。

● PyPI でのダウンロード設定

というツイートがあり、pip install mercurial の対象から rc (Release Candidate) 版を除外する必要があるなぁ、と考えていたところ:

という情報も。

インデックスファイルの修正＋tarballの pypi へのアップロードで、両方の問題を一気に解決できることから、pypi パッケージの保守担当者にメールして、設定変更を実施してもらいました。

2.7 版リリースからは、pip install mercurial が以下のように改善されました。

  • rc 版がインストールされる心配がない
  • インストール速度も大幅に向上
  • 本家の selenic.com がダウンしていてもインストール可能
● 作業領域更新不要なブランチクローズ機能

closebranch エクステンションは、以下のツイートを契機に、memctx を使った実装の練習を兼ねて実装しました。

● 256色対応

poor256color エクステンションは、以下のツイートを契機に実装しました。

● ブログエントリ

以下のツイートは、ブログエントリ執筆の必要性を感じた動機付けツイートです。

⇒ .hgignore における『無視対象に対する例外条件』指定の記述

⇒ 『Mercurial で pull request』したい Git ユーザが必要になるであろう、Mercurial におけるブランチの概念＋アルファ

⇒ 文字大小を無視する .hgignore 記述

⇒ 非 ASCII 文字出力により、Windows 上での Mercurial 実行が中断される問題

⇒ color＋pager 完全マスター

⇒ bundle マニアックス

⇒ Mercurialエクステンションで、指定パターンに合致する管理対象ファイルを取得する

⇒ パーフェクト dirstate 〜 トラブル対処編

バックログ

以下は、コミュニティにおける要望のうち、私の個人的な TODO リスト(2013 年版)に積まれているものです。

例によって、誰かが横取りしてやってくれても全然構いません。っていうか横取り大歓迎です(笑)。

● rebase での --keep 指定におけるフェーズチェック

「ポリシー設定を選択できるような設定の追加」の方向性で考えています。

● 複数行の外部プロセス実行指定での問題

設定ファイルの文法上は、エイリアスやマージツール、encode/decode等での、外部プロセス実行指定においても、複数行の記述が可能なのですが：

  • UNIX系環境だと、各行毎に分割して実行される（シェル依存？）
  • Windows環境だと、１行目しか認識されない

という、かなり期待と異なる結果になります。

外部プロセス実行指定が複数行に渡る場合に、警告ないしは中断するパッチを提案する予定です。っていうか、実装して疎通確認までは済んでいるのですが、パッチを投函し損ねてます……orz

● 空コミットのリベース

ブランチの初回コミットは、「ファイル変更無しで、ブランチ用途をコミットログとして記録」的な用途も考えられます。

hg rebase における --keepbranches が「元ブランチ名を維持」である意味合いを考えた場合、移動先とは異なるブランチに属するものに関しては、空コミットも許すべきと思われます。

一応、修正の目途は付いているのですが、既存のテストの改修がアレなので、パッチを投函し損ねてます……orz

(2015-11-03 追記) 他の開発者の手による修正が取り込まれましたので、2015-11-01 前後にリリースされる 3.6 版以降からは、--keepbranches 指定時に空コミットも維持されるようになります。

● revsets での文字列連結

ツィート上でのやり取りの際には、datebefore() や dateafter() のような、不等号等の指定が必要ない revset 述語の提案を考えていました。

しかし、実装を眺めていたら、演算子の追加が思ったよりも簡単そうなので、「文字列／シンボル等を連結する演算子」を提案した方が汎用性が高そう、という結論に。

実装／テスト自体は済んでいるのですが、これまた他の作業に紛れて、パッチを投函し損ねてます……orz

● ファイル名衝突周りの問題

『マージにおける同名ファイル／ディレクトリの衝突』に関しては、去年の時点で:

という状況のところに、開発者MLにパッチの投稿があって、『これは動きがあるかも？』という期待が盛り上がっていたのですが、その後は特に進展がありませんでした。

issue3452 への修正の際に、衝突検出を思いっきり書き換えたこともあって、乗りかかった船ということで、『マージにおける同名ファイル／ディレクトリの衝突』に関しては、現在絶賛作業中です。

一度修正案を提案したのですが、「大規模リポジトリでは効率が悪い」という理由から却下されたので、性能周りに配慮した実装に挑戦中です。

実装中に見かけた、以下のツイートに関する対応も、見込んで修正する必要があるので、なかなかに難しい感じ……

⇒ hg update や hg merge での、非ポータブルファイルの検出

⇒ hg convert での、非ポータブルファイルの検出（文字大小衝突も）

⇒ 間接的なパスの衝突の検出（hg update や hg merge、hg convert でも実施の必要あり）

● フックのサンプル／ひな形の追加

「新規ブランチ作成は許すけど複数ヘッドは禁止」とかなると、revsets 記述を使うにしても結構複雑になります。もしも「closedだったら複数ヘッド許可」のような条件だと、おそらく Python コードじゃないと、応答性が悪くなるかもしれません。

「サーバ側のフックで防止できますよ！」とは言っても、参考にすべき「実用的な」例が無い（or 探さないといけない）のは問題な気がしていますので、hgext か contrib 扱いで「サーバ向けフック集」の追加を提案しようかと思ってます。

● エイリアスでの "$@" 置換

現状、エイリアスでの $@ 記述は、Mercurial 側で置換しているため、シェルが実行された時点で、引数が再評価されてしまいます。

UNIX系環境の場合だけ、シェル側に $@ を解釈させるようなパッチを提案してみようと思っています。

「各環境での動作互換性重視」の観点で、却下される可能性ありますが……

(2014-08-15 追記) 他の開発者の手による修正が取り込まれましたので、2014-11-01 前後にリリースされる 3.2 版以降からは、Windows/POSIX 両方で $@ が使用できるようになります。

● サブリポジトリとの同期状況確認

2012年のツイートですが、2013年になってちょっとした関わりがあったので、備忘録代わりに。

"TortoiseHg の独自機能 〜 サブリポジトリの状態表示" 末尾でも書いたように、開発者 ML 上での機能追加の提案があったものの、その後、全く動きがありません。

代替案を提案した身としては、動向が気になっています。

● 外部フックへのリポジトリルート明示

これも 2012 年のツィートですが、備忘録代わりの「お気に入り」ツィートを棚卸ししていて見つけました。

問題の原因は、cmd.exe が UNC パスをサポートしていない（＝ カレントディレクトリを移動できない）ことにありました。

TortoiseHg のカスタムツールであれば、コマンド文字列中の {ROOT} をリポジトリルートで置換したりしてくれるのですが、Mercurial の（外部）フックでは、カレントディレクトリの情報以外で、対象リポジトリルートを取得する方法がありません。

HG_ROOT あるいは HG_REPOROOT 環境変数で、対象リポジトリのルートディレクトリを渡すような修正を提案する予定です。

● オンラインヘルプの強化周り

他に、オンラインヘルプの記述を強化することで、混乱を回避できそうな件に関するツイートがいくつかあります。

hg export/hg import が encoding sensitive な件とか:

proxy 周りの設定とか: