『入門Mercurial』についてのメモ ２

入門Mercurial Linux/Windows対応

『入門Mercurial』という本を読んで
分散型バージョン管理システムについて、メモを取りながら読書しています。自分用なので読みづらいです！

その１はこちら

まだ読んでいる途中ですが、とてもわかりやすい本です。
借りた本ですけど、自分でも購入しようかと思っています。
他のバージョン管理システムを理解する手助けにもなってます。
今まで何となく使っていた（すんませんm(__)m）Egit（gitのeclipseプラグイン）もだんだんわかってきました。
まあ、実際に手を動かして使用しているわけじゃないからわかってるつもりになってるだけかもしれませんね(^^ゞ

今回はチームでMercurialを使う章なのですが、チームで整合性を取りながら開発するのは
一人でやるのより段違いで難易度があがる感じです。
そのあたりの運用ヒントがたくさんです！

前回のメモを公開したところ著者様よりコメントをいただきました。
不明な点があったらたずねてくださいというお優しいものでした。
心より感謝いたします。

ところで、このメモは本をそのまま写しているつもりではないのですが、著作権的にまずかったら
すぐに対応するつもりです。もし読んだ方で気になる点があったらコメント欄又はTwitter @sakura_bird1
あてにメンションでご意見いただけますと幸いです。

あと、前回の記事を書いた後Androidでお世話になっている @3a3k さんがこのようなタイムリーな記事を書かれていました。
とても参考になるのでリンクしておきます。
駄猫の備忘録: MercurialEclipseを使ってみてはいかがでしょう

【チーム利用】
（チーム内で作業成果を共有するための）「共有リポジトリ」の作成方法
　　通常は共有用アカウントを作成する。
　　以下、共有用アカウントを「hgproj」と表記する。
　　共有リポジトリを運用するホストhgserverにおいて共有用アカウントのホームディレクトリの配下に共有リポジトリを作成する手順

　　hgproj@hgserver $ cd ~hgproj
　　hgproj@hgserver $ mkdir -p hgrepository/ourwork
　　hgproj@hgserver $ cd hgrepository/ourwork
　　hgproj@hgserver $ hg init

　　（個人と同じ手順）

　アクセス制御の設定

　　プロジェクトのディレクトリ配下はグループ権限でのread/writeを許可しメンバー追加の際は
　　グループに追加というのは一般的な設定だと思われるが問題点あり。

　　・umask設定による書き込み制限
　　　022だと書き込みユーザー以外の書き込みができなくなる。
　　・NFS利用における権限判定
　　　16以上のグループに属するユーザーの権限判定が適切に行われないことがある。（回避不可能）
　　・root権限での操作が必須

　　これらの問題はプロジェクトメンバー全員がhgprojユーザーとしてSSHアクセスすることで解決する。
　　~hgproj/.ssh/authorized-keys ファイルにメンバー各自のSSH公開鍵を登録しておくことで
　　自分のアカウントでのSSHアクセスと同じように.hgprojとしてアクセスすることができる。

　共有の作業手順
　　1.ファイル変更・新規作成
　　2."hg commit"
　　3."hg pull"
　　4.必要に応じて"hg merge" + "hg commit"
　　5."hg push"

　　マージのなすりつけ合い（誰かがやってくれる）を避けるため「単一ヘッドルール」を設けるのがおすすめ。
　　なお特定のリビジョンを指すのはリビジョン番号でなくハッシュIDを使うこと。
　　リビジョン番号は利便性のためのもの。

　公開済みの成果の「取り消し」
　”hg backout” について
　　”hg rollback” は共有リポジトリにおいては役に立たない。誰かが既にpullしてるかもしれない。
　　しかし特定のリビジョンの変更を無かったことにしたい時。
　　↓
　　"hg backout" を使う
　　元のリビジョンの内容で新しいリビジョンを自動的に作成する。

　　”hg backout”
　　　↓
　　新しいヘッドが生成される（複数ヘッド状態）
　　　↓
　　それを指定してマージする
　　　↓
　　ヘッドひとつに

　　過去のリビジョンを飛び飛びに取り消したい時は、あらかじめ全ての取消対象に対して
　　"hg backout" を実行しておいて、順に生成されたヘッドをマージしていくとよい。

　　”hg backout” 直後の"hg rollback"をすると
　　親リビジョンが"hg update"された状態になって混乱するので注意する。

　通常作業を継続しつつリリース作業を安全に平行して行う方法について

　　通常作業側の成果がリリース向けの成果に混入する事態は避けなければいけない。（逆も）

　　リリース用の場所を確保
　　リリース作業専用にリポジトリを分離する　"hg clone"
　　　活発に共有リポジトリが更新されている状況なら念のためリビジョンを指定した方がいい。
　　担当者に通知

　　リリースリポジトリの保護のため、リポジトリのパス名にリビジョン識別番号を含めることで、
　　リリース作業のアナウンスを受けていないメンバーからのアクセスを実質的に制限するやり方がある。
　　リリース作業用サーバーを共有リポジトリ運用サーバーと分離するという方法も考えられる。

　　名前付きブランチオススメの作成方法
　　　１．作業領域を分岐元リビジョンに"hg update"
　　　２．"hg branch" でブランチ名を指定
　　　３．"hg tag" で分岐元にタグ付け
　　　名前付きブランチを他の名前付きブランチにマージする際は"hg commit" 直前に"hg branch"
　　　が表示するブランチと同じブランチに属するので注意。

　制約下での共同作業
　だんだん難しくなってきてヤバイ
　
　　共有リポジトリを経由せずに、作業結果を他のメンバーと共有する方法
　　　テキストベースで出力する場合、"hg commit"未実施なら作業元リビジョンに対する変更内容を"hg diff"
　　　で表示させるのが簡単なやり方。
　　　複数のリビジョンでの変更内容を個別に取り出したい場合は、"hg export" を使用する。
　　　バイナリベースでの成果送付には”hg bundle”/"hg unbundle"を使う。

　　共有リポジトリにアクセスできない環境の場合
　　　PCにMercurialをインストールしてLAN経由で連携できる場合
　　　”hg serve” によるスタンドアロンサーバを立ち上げる。
　　　相互連携は工夫が必要。