mercurial-users.jp speech at osc2013 tokyo/spring

Mercurial で簡単履歴管理

藤原克則

OSC 2013 Tokyo/Spring 1

自己紹介


• 藤原克則(FUJIWARA Katsunori)

@flyingfoozy

http://d.hatena.ne.jp/flying-foozy/

• Mercurial プロジェクトへの関与

– メッセージ日本語翻訳のコミッタ

– コントリビュータとして、日々修正を提案

• 『入門Mercurial』（秀和システム刊）を執筆





GUIメインの入門書を出版します！

• TortoiseHgを利用した、

GUIによる履歴管理の入門書

• ２月27日頃から順次、

店頭に並ぶ予定

（地域によって異なります）


http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-books.html#thgbook

http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-books.html



履歴管理とは？


履歴管理の機能

• ファイルの変更内容の記録／参照

– 変更内容ベースの情報：

• 変更対象ファイル(What)

• 変更箇所(Where)

• 変更内容(How)

– 変更に関するメタデータ:

• 変更実施者(Who)

• 実施日時(When)

• 変更理由(Why)


履歴管理の利点

• 特定時点の状態への復帰

– 想定外の変更の取り消し

– 以前の状態での動作確認

• 記録内容を元にした履歴の検索／情報抽出

– 障害発生時の原因となった変更の特定

– 別視点での分析：ファイル別／作業者別の変更頻度など

• 並行して実施される作業の隔離／統合

– 記録された情報をベースに行うので、何度でもやり直しができる


履歴管理ツールの世代分類


履歴管理ツールの世代分類

• Bryan O'Sullivan 氏の

『Mercurial: The Definitive Guide』における分類

– http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-

books.html#bosbook





第０世代

• （一般的な）専用ツールを、全く使用しない履歴管理

– 『履歴管理』という名の『無法地帯』

• 変更前／後ファイルの手動保存

– ファイル名末尾に日付をつけて保存

– 定期的に作業成果のアーカイブを作成

• 複数人で並行作業する場合は

– 同一領域を共有して並行作業するか、あるいは

– 各自の作業後に、成果物を共有領域に上書き


• メタデータ／変更内容の管理が面倒

– 別ファイル(テキストファイル or エクセル)で管理

– メターデータ相当の情報や、修正前の内容をコメントとして残す

– 結果として、整合性の維持が困難になったり、可読性が低下するなど

• 必要になってからの、履歴の振り返りが面倒

– 人手が介在するため、誤操作の可能性も高い

• 成果記録の安全性確保が難しい

– 操作ミスにより、他人の成果を上書きする危険性

• エトセトラエトセトラ……


第０世代の問題点

第１世代

• 履歴情報の記録場所（リポジトリ）と、作業領域が隣接

– 代表的なツール: SCCS, RCS

• 複数人で並行作業する場合

– 同一領域を共有して並行作業

– 同一ファイルへの同時変更を防止するための排他機能あり


• 履歴が記録されている、一か所でしか作業できない

• 並行作業での安全性確保が難しい

– 同一領域を共有するため、作業成果の独立性が保てない

– 排他機能を利用した場合に、排他解放漏れが多発する

• エトセトラエトセトラ… …


第１世代の問題点

第２世代

• リポジトリと作業領域が分離（『中央リポジトリ』型）

– 代表的ツール: CVS, Subversion, Visual SourceSafe etc…

• 独立した作業領域を使用できるので、

各自の作業成果の独立性が確保できる

• クライアント／サーバモデルを導入したことで、

リモートホストでも作業可能


• リポジトリへの常時アクセスが前提

– オフライン／ネットワークアクセス制限のある環境での作業が困難

– 応答性が、ネットワーク帯域やサーバ性能に左右される

• 履歴記録内容が即時リポジトリに反映

– 作業の途中成果を、バックアップ代わりに記録したりできない

• 機能実現上、並行開発に難あり

– 履歴の記録が一本道であることが前提

– 継続的なブランチ運用が困難（マージに関しての配慮が不十分）

• エトセトラエトセトラ… …


第２世代の問題点

第３世代

• リポジトリと作業領域が隣接（ただし『分散リポジトリ』型）

– 代表的ツール: Git, Mercurial, Bazaar etc …

• 並行開発への配慮

– 履歴の枝分かれ／ブランチ運用の簡便化（＝マージの簡便化）

– 履歴管理で今最も熱い話題の１つが『ブランチ運用方法』なのは、

第２世代での不満の反動か？（笑）

• 個々のリポジトリが、完結した(completed)履歴情報を保持するため、

他リポジトリと連携できない（オフラインな）状況でも、単独で動作可能

• リポジトリ間で、相互に履歴情報の伝搬が可能

– 複数の手段／経路を選択可能

– 負荷分散が容易


• 難しい（と思われている）

– 『分散リポジトリ』という肩書が問題？

• 運用の自由度が高い

– ブランチ運用などは、最終的に組織としての、

『開発プロセス』や『品質保証方針』などとの兼ね合いになる

– それぞれの組織にとっての『最適解』に到達するには、

ある程度の試行錯誤が必要かも？


第３世代の問題点

Mercurialの利点


• 分散リポジトリ型（第３世代）の履歴管理ツール

http://mercurial.selenic.com/

• コマンド名は “hg”

– “Mercurial” の名前の由来である『水銀』(mercury)の元素記号

• Pythonをはじめとする各種OSSの履歴管理で採用

– 『A list of projects using Mercurial』

http://mercurial.selenic.com/wiki/ProjectsUsingMercurial


Mercurialとは？

http://mercurial.selenic.com/

http://mercurial.selenic.com/wiki/ProjectsUsingMercurial

概念モデルが簡単

• 記録された履歴は、常に参照可能

– デフォルトの履歴一覧で常時出力される

– 『HEAD を移動させると記録した履歴が見えなくなる』といったことが無い

– 『一定期間参照されない履歴が破棄される』といったことが無い

• 履歴の枝分かれ／ブランチの概念が単純

– Mercurialの『（名前付き）ブランチ』は、CVS/Subversionの『ブランチ』に近い概念

– Gitの『ブランチ』は概念レベルで別物

http://d.hatena.ne.jp/flying-foozy/20120801 参照

• CVS/Subversion経験者や、履歴管理初心者にとって、

理解の障壁が低い


http://d.hatena.ne.jp/flying-foozy/20120801





コマンドラインUIが簡単

• 『１機能１コマンド』

• 最小限の基本コマンドセットで履歴管理可能

• オプションの名称／用途がコマンド間で統一

• オンラインヘルプ／出力メッセージが、

(ほぼ)100%日本語翻訳済み

– 折角の翻訳メッセージファイルが同梱されていない、

残念なパッケージを公開しているディストリビューションもありますが …


• 複雑な条件指定でのリビジョン抽出が可能

– コミット実施ユーザ名

– コミット実施日時（期間指定可能）

– 特定のリビジョンの子孫、あるいは祖先のみの抽出

– 特定のファイル／フォルダに関する修正実施リビジョン

– マージ実施の有無

– エトセトラエトセトラ…

– さらに、and/or や括弧(優先度指定)による任意の条件の組み合わせ

• 使用例に関しては以下のブログエントリ等を参照

– http://d.hatena.ne.jp/flying-foozy/20120511/


強力な履歴検索機能

http://d.hatena.ne.jp/flying-foozy/20120511/



TortoiseHgなら簡単GUI操作


• 詳細は Mercurial の Wiki ページで

– 『Information about other tools that work with Mercurial. 』

http://mercurial.selenic.com/wiki/OtherTools


各種IDE向けプラグイン

http://mercurial.selenic.com/wiki/OtherTools

エクステンションによる機能拡張

• 標準同梱の『エクステンション』を有効にすることで、

Gitと比較して遜色のない機能を使用可能

– 履歴改変: rebase, histedit, MQ

– CUI利用時に便利な機能: color, progress, pager, record

– 挙動拡張: eol, keyword, largefiles

• 基本機能と分離することで

– 初期導入のコスト（覚えなければならない事）を下げる

– 不慣れな利用者による履歴破壊の危険を回避


Mercurial導入の障壁


情緒的な障壁

• 履歴管理ツール自体に対する無理解

– 『履歴管理ツールなんて必要ない』、『手動管理で十分』

– 『自前のツールの方が良い』、『OSSは品質が不安』

• 変化への抵抗

– 『変更を”管理”されるのは嫌だ！』

– 『新しいことを覚えるのは面倒だ！』


• 既に第２世代ツールが運用されている環境では

第３世代ツールのメリットがなかなか理解してもらえない

– 『小規模なら第２世代で十分』と考えがち

– 不便な現状に順応し過ぎて、問題の存在を認識できない

• ブランチ運用の困難性

• 中央リポジトリ型の運用柔軟性の低さ

• 結果として、初期導入コストに対する抵抗がある

• 組織の規模に比例して、コスト由来の抵抗は増加


導入コストの障壁

• 顧客からの使用ツール指定

• 第１～２世代ツールの開発元／販売元


政治的な障壁

ゲリラ的Mercurial導入のススメ

• 『組織へのMercurialの導入』を目的にすると大変

– 組織の論理や、情緒的な話には、付き合うだけ無駄

• とは言え、周りが使うツールに合わせることで、

自分（達）まで地獄を見る必要は無いよね？

• こっそりMercurialを使って、

せめて自分（達）だけは生き延びよう！


• 『～～で便利なので、Mercurial を導入しましょう！』

⇒ 『あーあー、やりたくなーい！面倒臭ーい！』

• 『皆さん大変ですね。私は個人的にMercurialで管理

してるから困りませんけど。おっと、口が滑った。』

⇒『何それ？俺達にも教えろ、ゴラァ！ (#ﾟДﾟ)』


あるいはトムソーヤ的戦術

ゲリラ的Mercurial導入


• 自分（達）の作業成果は、内部的にMercurialで管理

• 対外的には、他の履歴管理ツールを使っているように

見せかける

– CVS、Subversion、あるいは第０世代ツール（＝手動管理）

• 自分（達）以外の作業履歴もMercurial側に取り込む

– 履歴検索等での利便性


ゲリラ的Mercurial導入では…

運用方針

• 連携先（＝他の履歴管理ツール）からの取り込みは自動変換

• 連携先への反映は、連携先のツールを使用

– Mercurial側のリビジョンと、連携先に反映されるリビジョンとの間での、

一対一対応の制約を回避

– 制約回避によって、Mercurial 側での内部的な履歴記録の自由度

（記録粒度／ブランチ利用等）を確保

• 構成が多少複雑でも、誤操作の余地が少ない手順

• 第０世代ツールでの取り込み／反映は、手動で頑張る…orz


全体構成


連携先からの履歴取り込み

• Mercurialリポジトリ repo-sync に、連携先から履歴取り込み

– 基本的には、標準同梱の convert エクステンションで変換可能

• CVS, Subversion, Git, Bazaar etc …

– 状況／形式次第では、3rd party エクステンション／外部ツールの利用も

• hgsubversion エクステンションや Tailor など

• 詳細は『Converting Repositories』参照

http://mercurial.selenic.com/wiki/RepositoryConversion

• 連携先でのブランチ／タグもそのまま取り込み可能

– メイントランク(main trunk)の履歴は default ブランチに記録

– それ以外は、同一名称のブランチに記録


http://mercurial.selenic.com/wiki/RepositoryConversion

連携先（の main trunk）から取り込んだ履歴は、default ブランチに記録される。


取り込み履歴の共有

• 連携先とMercurial側とのすり合わせ作業は、

sync-default ブランチで実施

– default ブランチの最新リビジョンからブランチを作成（初回のみ）

– 連携先から継続的に取り込まれた履歴は、

都度 default から sync-default にマージ

– マージ成果は、リポジトリ repo-shared に反映


default と sync-default の間では、常に default ⇒ sync-default 方向にのみマージを実施。


独自作業成果の記録

• 独自作業成果は、hg-default ブランチ上で記録

– sync-default の最新リビジョンから、ブランチを作成（初回のみ）

– 連携先から継続的に取り込まれた履歴は、

sync-default ブランチを経由して hg-default にも都度マージ

– チームメンバは、共有リポジトリ repo-shared 経由で成果を共有

– Mercurial の機能をフルに使用可能

• 独自の（＝連携先には見せない）ブランチ作成

• 名前なしブランチで複数ヘッド状態

• 共有リポジトリを経由しない履歴伝搬などなど


hg-default あるいはそこから派生したブランチ上の履歴記録は、連携先の管理モデル（e.g. 一本道）の制約を

受けずに、Mercurialの機能をフルに使用可能


独自作業成果反映用リポジトリの作成

• 作業領域の『ハイブリッド』(hybrid)化 (初回のみ)

– 連携先からのチェックアウト

“cvs checkout” や “svn checkout”

– チェックアウトした領域を、Mercurialリポジトリとしても初期化

“hg init” (+ “hg pull repo-shared”)


連携対象


• 連携先の最新リビジョンで、作業領域を更新

– 最新内容で強制的に上書き: “cvs update –C” など

• sync-default ブランチの最新リビジョンで、作業領域を更新

– 最新内容で強制的に上書き: “hg update –-clean sync-default”

• 連携先に対して、差分の有無を確認

– “cvs diff”, “svn diff” など

• 差分があるなら、『連携先からの履歴取り込み』から繰り返し

– こちらの作業中に、連携先に新規リビジョンが追加されている筈


ハイブリッド領域の同期

連携対象


ハイブリッドリポジトリの作業領域同期では、Mercurial側の同期対象が、defaultブランチではなく sync-default上のリビジョンである

点に注意。defaultは連携先からの取り込み専用として使用し、成果統合等のすり合わせ作業は、sync-default上で実施する。


連携先への独自作業成果の反映

• hg-default ブランチから sync-default にマージ

• repo-hybrid リポジトリにマージ結果を反映

• repo-hybrid の作業領域をマージ実施リビジョンで強制更新

– “hg update –-clean sync-default”

– 事前に適切に同期されていれば、

マージした独自作業成果＝連携先との差分＝連携先への反映内容

• 連携先に変更内容を記録

– “cvs commit”, “svn commit” など

– 必要であれば、新規ファイルの add や、不要ファイルの remove も、

commit 前に手動で実施


連携対象


ハイブリッドな作業領域が、先述した要領で連携先／Mercurialの両方に同期された状態から作業することで、

hg-default ブランチからマージした独自作業成果Xを、連携先にCとして適切に反映することが可能。


独自作業成果反映直後の、連携先からの取り込みでは、X と同内容の C が取り込まれるが、『B⇒C』と『b⇒X』

は全く同一の変更になることから、CとXのマージは、Mercurialでは衝突等が発生しない。


• 役割を固定化することで：

– 作業手順を固定化可能

– 『状況に応じた判断』に由来する誤操作の危険性を低減可能

• １つのリポジトリ／ブランチで、役割を兼務させると:

– うっかり他の作業を実施してしまうかも？

– 『ハイブリッド領域の同期』などで、手順が増えてしまうかも？

• これだけブランチ／マージを多用しても、

Mercurialなら楽々運用可能


リポジトリ／ブランチが多数登場するが…

日本でのコミュニティ活動の紹介


• mercurial-ja

– https://groups.google.com/forum/?fromgroups#!forum/mercurial-ja

– リリース情報／障害情報等もアナウンスしてます


メーリングリスト

https://groups.google.com/forum/?fromgroups




• 公式コミュニティアカウント

@mercurialjp

• 公式コミュニティハッシュタグ

#mercurialjp


Twitter

• http://mercurial-users.jp/

– イベント開催／参加情報

• 勉強会の開催

• 各種イベントでの出張ハンズオンなど

– 最新版の日本語オンラインマニュアルの公開

– 各種情報へのリンク

• メーリングリスト等へのリンクも！


公式サイト

http://mercurial-users.jp/




• Twitter上の発言等に由来する、

Mercurial本体に取り込まれた修正が、

2012年の一年間で10件以上

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


• 疑問／要望等あれば、どんどんお寄せください


つぶやきも立派な貢献です！




• “TokyoMercurial” と題して、

03/23(土)に勉強会を開催します

http://connpass.com/event/1855/

• お菓子を食べながらの和やかな会ですので、

『履歴管理ツールの利用は初めて』な方から、

『Mercurialの中身を知りたい』な方まで、

お気軽に参加ください！


勉強会開催情報

http://connpass.com/event/1855/

本日はありがとうございました


mercurial-users.jp speech at osc2013 tokyo/spring

Technology