mercurial-users.jp speech at osc2013 tokyo/spring
DESCRIPTION
speech of mercurial-users.jp at OSC2013 Tokyo/Spring on 2013-02-23TRANSCRIPT
Mercurial で簡単履歴管理
藤原 克則
OSC 2013 Tokyo/Spring 1
自己紹介
OSC 2013 Tokyo/Spring 2
• 藤原 克則(FUJIWARA Katsunori)
@flyingfoozy
http://d.hatena.ne.jp/flying-foozy/
• Mercurial プロジェクトへの関与
– メッセージ日本語翻訳のコミッタ
– コントリビュータとして、日々修正を提案
• 『入門Mercurial』(秀和システム刊)を執筆
OSC 2013 Tokyo/Spring 3
GUIメインの入門書を出版します!
• TortoiseHgを利用した、
GUIによる履歴管理の入門書
• 2月27日頃から順次、
店頭に並ぶ予定
(地域によって異なります)
OSC 2013 Tokyo/Spring 4
http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-books.html#thgbook
履歴管理とは?
OSC 2013 Tokyo/Spring 5
履歴管理の機能
• ファイルの変更内容の記録/参照
– 変更内容ベースの情報:
• 変更対象ファイル(What)
• 変更箇所(Where)
• 変更内容(How)
– 変更に関するメタデータ:
• 変更実施者(Who)
• 実施日時(When)
• 変更理由(Why)
OSC 2013 Tokyo/Spring 6
履歴管理の利点
• 特定時点の状態への復帰
– 想定外の変更の取り消し
– 以前の状態での動作確認
• 記録内容を元にした履歴の検索/情報抽出
– 障害発生時の原因となった変更の特定
– 別視点での分析: ファイル別/作業者別の変更頻度など
• 並行して実施される作業の隔離/統合
– 記録された情報をベースに行うので、何度でもやり直しができる
OSC 2013 Tokyo/Spring 7
履歴管理ツールの世代分類
OSC 2013 Tokyo/Spring 8
履歴管理ツールの世代分類
• Bryan O'Sullivan 氏の
『Mercurial: The Definitive Guide』における分類
– http://www.lares.dti.ne.jp/~foozy/fujiguruma/scm/mercurial-
books.html#bosbook
OSC 2013 Tokyo/Spring 9
第0世代
• (一般的な)専用ツールを、全く使用しない履歴管理
– 『履歴管理』という名の『無法地帯』
• 変更前/後ファイルの手動保存
– ファイル名末尾に日付をつけて保存
– 定期的に作業成果のアーカイブを作成
• 複数人で並行作業する場合は
– 同一領域を共有して並行作業するか、あるいは
– 各自の作業後に、成果物を共有領域に上書き
OSC 2013 Tokyo/Spring 10
• メタデータ/変更内容の管理が面倒
– 別ファイル(テキストファイル or エクセル)で管理
– メターデータ相当の情報や、修正前の内容をコメントとして残す
– 結果として、整合性の維持が困難になったり、可読性が低下するなど
• 必要になってからの、履歴の振り返りが面倒
– 人手が介在するため、誤操作の可能性も高い
• 成果記録の安全性確保が難しい
– 操作ミスにより、他人の成果を上書きする危険性
• エトセトラエトセトラ……
OSC 2013 Tokyo/Spring 11
第0世代の問題点
第1世代
• 履歴情報の記録場所(リポジトリ)と、作業領域が隣接
– 代表的なツール: SCCS, RCS
• 複数人で並行作業する場合
– 同一領域を共有して並行作業
– 同一ファイルへの同時変更を防止するための排他機能あり
OSC 2013 Tokyo/Spring 12
• 履歴が記録されている、一か所でしか作業できない
• 並行作業での安全性確保が難しい
– 同一領域を共有するため、作業成果の独立性が保てない
– 排他機能を利用した場合に、排他解放漏れが多発する
• エトセトラエトセトラ… …
OSC 2013 Tokyo/Spring 13
第1世代の問題点
第2世代
• リポジトリと作業領域が分離(『中央リポジトリ』型)
– 代表的ツール: CVS, Subversion, Visual SourceSafe etc…
• 独立した作業領域を使用できるので、
各自の作業成果の独立性が確保できる
• クライアント/サーバモデルを導入したことで、
リモートホストでも作業可能
OSC 2013 Tokyo/Spring 14
• リポジトリへの常時アクセスが前提
– オフライン/ネットワークアクセス制限のある環境での作業が困難
– 応答性が、ネットワーク帯域やサーバ性能に左右される
• 履歴記録内容が即時リポジトリに反映
– 作業の途中成果を、バックアップ代わりに記録したりできない
• 機能実現上、並行開発に難あり
– 履歴の記録が一本道であることが前提
– 継続的なブランチ運用が困難(マージに関しての配慮が不十分)
• エトセトラエトセトラ… …
OSC 2013 Tokyo/Spring 15
第2世代の問題点
第3世代
• リポジトリと作業領域が隣接(ただし『分散リポジトリ』型)
– 代表的ツール: Git, Mercurial, Bazaar etc …
• 並行開発への配慮
– 履歴の枝分かれ/ブランチ運用の簡便化(=マージの簡便化)
– 履歴管理で今最も熱い話題の1つが『ブランチ運用方法』なのは、
第2世代での不満の反動か?(笑)
• 個々のリポジトリが、完結した(completed)履歴情報を保持するため、
他リポジトリと連携できない(オフラインな)状況でも、単独で動作可能
• リポジトリ間で、相互に履歴情報の伝搬が可能
– 複数の手段/経路を選択可能
– 負荷分散が容易
OSC 2013 Tokyo/Spring 16
• 難しい(と思われている)
– 『分散リポジトリ』という肩書が問題?
• 運用の自由度が高い
– ブランチ運用などは、最終的に組織としての、
『開発プロセス』や『品質保証方針』などとの兼ね合いになる
– それぞれの組織にとっての『最適解』に到達するには、
ある程度の試行錯誤が必要かも?
OSC 2013 Tokyo/Spring 17
第3世代の問題点
Mercurialの利点
OSC 2013 Tokyo/Spring 18
• 分散リポジトリ型(第3世代)の履歴管理ツール
http://mercurial.selenic.com/
• コマンド名は “hg”
– “Mercurial” の名前の由来である『水銀』(mercury)の元素記号
• Pythonをはじめとする各種OSSの履歴管理で採用
– 『A list of projects using Mercurial』
http://mercurial.selenic.com/wiki/ProjectsUsingMercurial
OSC 2013 Tokyo/Spring 19
Mercurialとは?
概念モデルが簡単
• 記録された履歴は、常に参照可能
– デフォルトの履歴一覧で常時出力される
– 『HEAD を移動させると記録した履歴が見えなくなる』といったことが無い
– 『一定期間参照されない履歴が破棄される』といったことが無い
• 履歴の枝分かれ/ブランチの概念が単純
– Mercurialの『(名前付き)ブランチ』は、CVS/Subversionの『ブランチ』に近い概念
– Gitの『ブランチ』は概念レベルで別物
http://d.hatena.ne.jp/flying-foozy/20120801 参照
• CVS/Subversion経験者や、履歴管理初心者にとって、
理解の障壁が低い
OSC 2013 Tokyo/Spring 20
コマンドラインUIが簡単
• 『1機能1コマンド』
• 最小限の基本コマンドセットで履歴管理可能
• オプションの名称/用途がコマンド間で統一
• オンラインヘルプ/出力メッセージが、
(ほぼ)100%日本語翻訳済み
– 折角の翻訳メッセージファイルが同梱されていない、
残念なパッケージを公開しているディストリビューションもありますが …
OSC 2013 Tokyo/Spring 21
• 複雑な条件指定でのリビジョン抽出が可能
– コミット実施ユーザ名
– コミット実施日時(期間指定可能)
– 特定のリビジョンの子孫、あるいは祖先のみの抽出
– 特定のファイル/フォルダに関する修正実施リビジョン
– マージ実施の有無
– エトセトラエトセトラ…
– さらに、and/or や括弧(優先度指定)による任意の条件の組み合わせ
• 使用例に関しては以下のブログエントリ等を参照
– http://d.hatena.ne.jp/flying-foozy/20120511/
OSC 2013 Tokyo/Spring 22
強力な履歴検索機能
TortoiseHgなら簡単GUI操作
OSC 2013 Tokyo/Spring 23
• 詳細は Mercurial の Wiki ページで
– 『Information about other tools that work with Mercurial. 』
http://mercurial.selenic.com/wiki/OtherTools
OSC 2013 Tokyo/Spring 24
各種IDE向けプラグイン
エクステンションによる機能拡張
• 標準同梱の『エクステンション』を有効にすることで、
Gitと比較して遜色のない機能を使用可能
– 履歴改変: rebase, histedit, MQ
– CUI利用時に便利な機能: color, progress, pager, record
– 挙動拡張: eol, keyword, largefiles
• 基本機能と分離することで
– 初期導入のコスト(覚えなければならない事)を下げる
– 不慣れな利用者による履歴破壊の危険を回避
OSC 2013 Tokyo/Spring 25
Mercurial導入の障壁
OSC 2013 Tokyo/Spring 26
情緒的な障壁
• 履歴管理ツール自体に対する無理解
– 『履歴管理ツールなんて必要ない』、『手動管理で十分』
– 『自前のツールの方が良い』、『OSSは品質が不安』
• 変化への抵抗
– 『変更を”管理”されるのは嫌だ!』
– 『新しいことを覚えるのは面倒だ!』
OSC 2013 Tokyo/Spring 27
• 既に第2世代ツールが運用されている環境では
第3世代ツールのメリットがなかなか理解してもらえない
– 『小規模なら第2世代で十分』と考えがち
– 不便な現状に順応し過ぎて、問題の存在を認識できない
• ブランチ運用の困難性
• 中央リポジトリ型の運用柔軟性の低さ
• 結果として、初期導入コストに対する抵抗がある
• 組織の規模に比例して、コスト由来の抵抗は増加
OSC 2013 Tokyo/Spring 28
導入コストの障壁
• 顧客からの使用ツール指定
• 第1~2世代ツールの開発元/販売元
OSC 2013 Tokyo/Spring 29
政治的な障壁
ゲリラ的Mercurial導入のススメ
• 『組織へのMercurialの導入』を目的にすると大変
– 組織の論理や、情緒的な話には、付き合うだけ無駄
• とは言え、周りが使うツールに合わせることで、
自分(達)まで地獄を見る必要は無いよね?
• こっそりMercurialを使って、
せめて自分(達)だけは生き延びよう!
OSC 2013 Tokyo/Spring 30
OSC 2013 Tokyo/Spring 31
• 『~~で便利なので、Mercurial を導入しましょう!』
⇒ 『あーあー、やりたくなーい!面倒臭ーい!』
• 『皆さん大変ですね。私は個人的にMercurialで管理
してるから困りませんけど。おっと、口が滑った。』
⇒『何それ?俺達にも教えろ、ゴラァ! (#゚Д゚)』
OSC 2013 Tokyo/Spring 32
あるいはトムソーヤ的戦術
ゲリラ的Mercurial導入
OSC 2013 Tokyo/Spring 33
• 自分(達)の作業成果は、内部的にMercurialで管理
• 対外的には、他の履歴管理ツールを使っているように
見せかける
– CVS、Subversion、あるいは第0世代ツール(=手動管理)
• 自分(達)以外の作業履歴もMercurial側に取り込む
– 履歴検索等での利便性
OSC 2013 Tokyo/Spring 34
ゲリラ的Mercurial導入では…
運用方針
• 連携先(=他の履歴管理ツール)からの取り込みは自動変換
• 連携先への反映は、連携先のツールを使用
– Mercurial側のリビジョンと、連携先に反映されるリビジョンとの間での、
一対一対応の制約を回避
– 制約回避によって、Mercurial 側での内部的な履歴記録の自由度
(記録粒度/ブランチ利用等)を確保
• 構成が多少複雑でも、誤操作の余地が少ない手順
• 第0世代ツールでの取り込み/反映は、手動で頑張る…orz
OSC 2013 Tokyo/Spring 35
全体構成
OSC 2013 Tokyo/Spring 36
連携先からの履歴取り込み
• Mercurialリポジトリ repo-sync に、連携先から履歴取り込み
– 基本的には、標準同梱の convert エクステンションで変換可能
• CVS, Subversion, Git, Bazaar etc …
– 状況/形式次第では、3rd party エクステンション/外部ツールの利用も
• hgsubversion エクステンションや Tailor など
• 詳細は『Converting Repositories』参照
http://mercurial.selenic.com/wiki/RepositoryConversion
• 連携先でのブランチ/タグもそのまま取り込み可能
– メイントランク(main trunk)の履歴は default ブランチに記録
– それ以外は、同一名称のブランチに記録
OSC 2013 Tokyo/Spring 37
OSC 2013 Tokyo/Spring 38
連携先(の main trunk)から取り込んだ履歴は、default ブランチに記録される。
OSC 2013 Tokyo/Spring 39
取り込み履歴の共有
• 連携先とMercurial側とのすり合わせ作業は、
sync-default ブランチで実施
– default ブランチの最新リビジョンからブランチを作成(初回のみ)
– 連携先から継続的に取り込まれた履歴は、
都度 default から sync-default にマージ
– マージ成果は、リポジトリ repo-shared に反映
OSC 2013 Tokyo/Spring 40
OSC 2013 Tokyo/Spring 41
default と sync-default の間では、常に default ⇒ sync-default 方向にのみマージを実施。
OSC 2013 Tokyo/Spring 42
独自作業成果の記録
• 独自作業成果は、hg-default ブランチ上で記録
– sync-default の最新リビジョンから、ブランチを作成(初回のみ)
– 連携先から継続的に取り込まれた履歴は、
sync-default ブランチを経由して hg-default にも都度マージ
– チームメンバは、共有リポジトリ repo-shared 経由で成果を共有
– Mercurial の機能をフルに使用可能
• 独自の(=連携先には見せない)ブランチ作成
• 名前なしブランチで複数ヘッド状態
• 共有リポジトリを経由しない履歴伝搬などなど
OSC 2013 Tokyo/Spring 43
OSC 2013 Tokyo/Spring 44
hg-default あるいはそこから派生したブランチ上の履歴記録は、連携先の管理モデル(e.g. 一本道)の制約を
受けずに、Mercurialの機能をフルに使用可能
OSC 2013 Tokyo/Spring 45
独自作業成果反映用リポジトリの作成
• 作業領域の『ハイブリッド』(hybrid)化 (初回のみ)
– 連携先からのチェックアウト
“cvs checkout” や “svn checkout”
– チェックアウトした領域を、Mercurialリポジトリとしても初期化
“hg init” (+ “hg pull repo-shared”)
OSC 2013 Tokyo/Spring 46
連携対象
OSC 2013 Tokyo/Spring 47
• 連携先の最新リビジョンで、作業領域を更新
– 最新内容で強制的に上書き: “cvs update –C” など
• sync-default ブランチの最新リビジョンで、作業領域を更新
– 最新内容で強制的に上書き: “hg update –-clean sync-default”
• 連携先に対して、差分の有無を確認
– “cvs diff”, “svn diff” など
• 差分があるなら、『連携先からの履歴取り込み』から繰り返し
– こちらの作業中に、連携先に新規リビジョンが追加されている筈
OSC 2013 Tokyo/Spring 48
ハイブリッド領域の同期
連携対象
OSC 2013 Tokyo/Spring 49
ハイブリッドリポジトリの作業領域同期では、Mercurial側の同期対象が、defaultブランチではなく sync-default上のリビジョンである
点に注意。defaultは連携先からの取り込み専用として使用し、成果統合等のすり合わせ作業は、sync-default上で実施する。
OSC 2013 Tokyo/Spring 50
連携先への独自作業成果の反映
• hg-default ブランチから sync-default にマージ
• repo-hybrid リポジトリにマージ結果を反映
• repo-hybrid の作業領域をマージ実施リビジョンで強制更新
– “hg update –-clean sync-default”
– 事前に適切に同期されていれば、
マージした独自作業成果=連携先との差分=連携先への反映内容
• 連携先に変更内容を記録
– “cvs commit”, “svn commit” など
– 必要であれば、新規ファイルの add や、不要ファイルの remove も、
commit 前に手動で実施
OSC 2013 Tokyo/Spring 51
連携対象
OSC 2013 Tokyo/Spring 52
ハイブリッドな作業領域が、先述した要領で連携先/Mercurialの両方に同期された状態から作業することで、
hg-default ブランチからマージした独自作業成果Xを、連携先にCとして適切に反映することが可能。
OSC 2013 Tokyo/Spring 53
独自作業成果反映直後の、連携先からの取り込みでは、X と同内容の C が取り込まれるが、『B⇒C』と『b⇒X』
は全く同一の変更になることから、CとXのマージは、Mercurialでは衝突等が発生しない。
OSC 2013 Tokyo/Spring 54
• 役割を固定化することで:
– 作業手順を固定化可能
– 『状況に応じた判断』に由来する誤操作の危険性を低減可能
• 1つのリポジトリ/ブランチで、役割を兼務させると:
– うっかり他の作業を実施してしまうかも?
– 『ハイブリッド領域の同期』などで、手順が増えてしまうかも?
• これだけブランチ/マージを多用しても、
Mercurialなら楽々運用可能
OSC 2013 Tokyo/Spring 55
リポジトリ/ブランチが多数登場するが…
日本でのコミュニティ活動の紹介
OSC 2013 Tokyo/Spring 56
• mercurial-ja
– https://groups.google.com/forum/?fromgroups#!forum/mercurial-ja
– リリース情報/障害情報等もアナウンスしてます
OSC 2013 Tokyo/Spring 57
メーリングリスト
• 公式コミュニティアカウント
@mercurialjp
• 公式コミュニティハッシュタグ
#mercurialjp
OSC 2013 Tokyo/Spring 58
• http://mercurial-users.jp/
– イベント開催/参加情報
• 勉強会の開催
• 各種イベントでの出張ハンズオンなど
– 最新版の日本語オンラインマニュアルの公開
– 各種情報へのリンク
• メーリングリスト等へのリンクも!
OSC 2013 Tokyo/Spring 59
公式サイト
• Twitter上の発言等に由来する、
Mercurial本体に取り込まれた修正が、
2012年の一年間で10件以上
– 『Mercurial に関するコミュニティ由来の成果(2012年版)』
http://d.hatena.ne.jp/flying-foozy/20130109
• 疑問/要望等あれば、どんどんお寄せください
OSC 2013 Tokyo/Spring 60
つぶやきも立派な貢献です!
• “TokyoMercurial” と題して、
03/23(土)に勉強会を開催します
http://connpass.com/event/1855/
• お菓子を食べながらの和やかな会ですので、
『履歴管理ツールの利用は初めて』な方から、
『Mercurialの中身を知りたい』な方まで、
お気軽に参加ください!
OSC 2013 Tokyo/Spring 61
勉強会開催情報
本日はありがとうございました
OSC 2013 Tokyo/Spring 62