彷徨えるフジワラ

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

SCMBootCamp in Nagoya #2

勉強会 mercurial scmbc

SCMBootCamp in Nagoya #2 に講師枠で参加してきました。運営お疲れ様でした！ ＞ id:kyon_mm

今回、Mercurial 枠の応募者3名のうち、2名は Git 経験者、1名は SVN 経験者だったので、それらのツールと Mercurial 利用時の違いに関する説明がメインでした。

SVN 経験者には:

  • SVN の1アクションに相当する機能が、複数の操作から構成される
    • "svn update" は、"hg pull" + "hg merge" 相当
    • "svn commit"は、"hg commit" + "hg push" 相当、等々
  • SVN 的な、未コミット成果ベースのマージもできるけど、コミット済み成果ベースのマージの方が安全＆お薦め

Git 経験者には:

  • 「ブランチ」の概念が全く違う
  • 「ステージング」の概念が無い
  • 多くの Git 同等機能はエクステンションとして提供 (rebase/histedit/record/progress/color 等々)

といったあたりが、説明の中心だったでしょうか？他には、コマンド UI の方針（単機能化／オプションの統一）とかの話もありましたね。
また:

rebase せずに merge 主体の運用では、マージ実施リビジョンが増えることで履歴ツリーが多少複雑にはなるが、-M/--no-merges オプションや revsets 記述 ("not merge()") 等により、マージ実施リビジョンを hg log の表示対象から除外できるので、あまり気にしなくても大丈夫

という話を契機に、「revsets が如何に素晴らしいか？」な話なども (^ ^ ;;;)

振り返り＋Q&A 枠では、以下のような話題に触れました。

  • 大容量ファイルに関して:
    • Windows 32bit 版の Mercurial 3.0 では、より理論上限に近いサイズのファイルを扱えるようにする修正が入っている
    • largefiles エクステンション万歳
    • 本来であれば、大容量ファイルを生成するツール側で、比較・マージ機能を持つのが筋じゃねぇ？
  • DVCS 運用時の作業内容衝突 (conflict) に関して:
    • プロジェクト運営における作業担当割り当てや、設計における機能分割などでも、発生頻度を減らせる筈
    • プロジェクトのフェーズ (立ち上げ・安定・保守等々) によっても、発生頻度が違う筈
    • DVCS だと「品質担保」の方法を色々工夫可能: pull request／patch & review／チーム単位での階層化・局所化 ＋ push ゲートウェイ etc ....
    • 運用形態・管理対象に応じたベストプラクティスを、今まさに皆が模索中

最後に、ちょっとだけ発表枠をもらって、以下のような (ネタ) 発表をさせてもらいました。

発表資料中の「編集エディタ起動処理の統一」の修正 19 件は、レビュー〜取り込み準備用の clowncopter リポジトリに昨晩取り込まれたばかりで、公式リポジトリへの反映時に変わる可能性があることから、ハッシュIDは未記載としています。

「テンプレートを変更する機能」自体はまだ取り込まれていませんが、取り込み済みの「編集エディタ起動処理の統一」によって、コミットメッセージ入力処理に関する処理が、全て cmdutil.getcommiteditor とそれが返す2つの関数に集約されるようになりましたので、これらをフックすることで、「テンプレートを変更する機能」の実現自体は可能になっています。対応完了を待ちきれないせっかちな Python Hacker は、こちらの方法でどうぞ（笑）。

厳密には、gpg エクステンションの hg sign、shelve エクステンションの hg shelve および hg backout での --message によるコミットログ指定に関しては、対応範囲から漏れているのですが、まぁ、「全て集約されている」と言って良いでしょう (^ ^ ;;;) 今後の修正提案の過程で、これらも網羅される予定です。

最終的には、hg log --template TEMPLATE で言う「テンプレート」機能を使って、エディタ起動時の初期表示内容を簡単に書き換えられるようにする予定ですので、面倒臭がりの方は、もう暫くお待ちください。