彷徨えるフジワラ

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

TokyoMercurial #3

mercurial tokyomercurial 勉強会

TokyoMercurial #3 に参加してきた。

＃ 公式ページは bitbucket 上に

今回も開催／運営お疲れ様でした！ > id:troter

参加のまとめを書くのが遅れてしまったのだが、2.2 のコードフリーズに向けて慌ててパッチを書いていたので勘弁して頂きたく。

モクモク課題消化状況

実際には、ボトムアップ的に話の輪が広がって、結局みんなであーだこーだ話し合っているのだけれど、建前上(笑)は『各自で課題を設定して黙々と作業』な TokyoMercurial なので、今回も自分なりの課題設定をすることに。

とは言え、個人的には、課題に集中してしまうと、話題に上がったトピックを忘れてしまったり、話題そのものに乗り遅れたりしてしまう傾向があるため、緩めの課題にした方が無難ではなかろうか？というのが結論。

TokyoMercurial 開催週は、時間枠最後で発表する『Mercurial ソースのコードランニング』に向けた資料作成や、例のごとくパッチを作成したりしていたので、user-ml／devel-ml 共に未読状態のメールが随分と。

という訳で、今回の僕の課題は『未読状態の Mercurial ML の消化』(笑)。

で、課題の消化状況はと言うと… devel-ml は消化したけど、user-ml は全然消化できなかった… orz

っちゅーか、丁度 devel-ml 上で Matt に相談していた件に関連した issue (3370) の通知がメールされていて、アドレナリンが大量分泌(笑)されていたので、user-ml の方を消化する余裕が無かったのだ。

まぁ、devel-ml が消化できただけでも良しとするか。

(K)eep (P)roblem (T)ry

(K) 名札が定着したので、今後もこの方向で。

(K) 発表枠があったのは良かったと思う。(準備含めて)一人5分でも、1時間で12人しか消化できないから、全員発表は流石に無理だけど(笑)。

(P) ACアダプタを忘れた(非常に個人的な P だけど)ので、最後の発表枠までバッテリーが持つかヒヤヒヤだった。

(P) 最小リファレンスカードの配布を忘れた(これまた個人的な P だけど)のは失敗。折角持って行ったものだったので、思い出した懇親会の席で配布。

Python Festa で配布した版から、"TortoiseHg" の "Hg" 表記を "HG" から改めたり、グループ化がわかりやすいように影を入れたりと、細かい修正が入っているので、以前の版をお持ちの方も是非最新版をダウンロードしてご利用ください。

(T) 座席表は記憶の掘り起こしに便利(個人的な感想)なので、可能であれば作成した方が良い気が。もっとも次回以降は Python mini Hack-a-thon との合同開催になる予定だから、難しいかな？

(T) Mercurial の機能利用状況とかに関して、口頭での『アンケート』とかを (自己紹介枠とは別に) 設けてみるのはどうだろう？ (参加者全員に発言する機会を設ける意味も込めて)

(T) おやつ戦争に勝利可能な戦力の投入。今回は『余った時の日持ち』等を考えて飴を持参したけど、次回はもっと破壊力のあるものを(笑)

Mac OS XCode 問題

参加者から『Mac OS でインストールできない』という相談が。

例によって 2.1.1 での問題の奴だろうと思っていたら、インストール対象は問題修正済みの 2.1.2。あれ？直ったんじゃなかったの？

症状としては『インストール処理が一向に進まない』というものなので、件の障害とは別な問題っぽい。

とりあえず稼動しているプロセスを確認してみると…… "xcodebuild -version" の終了待ち状態で止まってる？

試しに "xcodebuild -version" 単体で実行してみると……ぐはぁ！戻ってこねぇ〜！

他の参加者に情報を求めたところ:

"xcode-select -print-path" で、ちゃんとインストール先パスが表示されるか確認。パスが適切でない場合、"/Applications/Xcode.app/Contents/Developer" あたりを設定すべし。

という情報が。

早速確認してみると… "/" しか表示されない！ということで、設定変更してみたところ、無事インストールに成功。

どうやらこれも、XCode の 4.2 〜 4.3 での移行でアレしてしまうらしく、「旧版を使い続け」とか「新版を新規導入」とかのケースでは発生しない問題の模様。

自宅の Mac mini で確認したら XCode 4.2.1 だったので、4.3 系にアップグレードしたら同じ問題が発生するのかぁ〜。うぇ〜。

Cygwin ウィンドウでの日本語表示

参加者から『Cygwin で日本語ヘルプ表示が文字化けする』との相談が。

ロケール系設定の変更やら何やらと格闘すること暫し……どうやら、DOS 窓じゃないウィンドウで bash が走っている環境だったらしく、ウィンドウ自体の文字コード設定を調整する必要がある、という罠だった模様。

僕個人は、新しい環境に Cygwin を入れたら、teraterm + cygterm に速攻で切り替えるので、最近の事情に関しては、とんと疎くなってしまったのだけれど、今は DOS 窓を使わないのがデフォルトなのかな？

設定する文字コードの選択に関しては、各自の『日本語ファイルを使うか否か』な事情に応じて要検討。

リポジトリ破損

参加者から『"hg update" は成功するが、"hg archive" が失敗する』という相談が。

で、色々話を聞いた結果:

  • "hg archive" 失敗時は、特定のファイルに関して『履歴情報が正しくない』云々のメッセージが表示
  • 当該ファイルは随分前に "hg add" して以降、更新が無い
  • 作業領域中の当該ファイルの内容は正常

という状況らしいので、以下の様な事情なのではなかろうかと推測:

何らかの要因で履歴情報が破損。
"hg update" は「作業領域での改変が無い」場合は、履歴からの取り出しを省略するので、正常終了。
"hg archive" は必ず履歴記録を参照するので、破損が顕在化して処理中断。

推測通りだとすると、"hg verify" でも『破損が判明』するだけなので、結局『元の内容のファイルで強制上書きしたリビジョンをコミット』ぐらいしか修復方法は無いかなぁ。

原因としては:

  • 記録媒体不良(HDD/SSD) or ファイルシステムの不整合
  • メモリ不良
  • ディスクキャッシュのフラッシュ完了前にシャットダウン
  • Mercurial からの書き出し失敗

あたりかなぁ？

『メモリ不良』を挙げているのは、以前、勤務先で余りモノの PC に Linux をインストールした際に、ツールのコンパイルをしようとしたら:

という状況で、HDD 不良を疑ったのだけれど、実はメモリ不良だった (memtest86 で確認) という経験があったため。

ちなみに『毎回同じファイルの同じ場所でコンパイル失敗』なのは、『起動〜ログイン〜ビルド』の手順が毎回ほぼ同一だったために、同一ファイルが毎回不良メモリ上にキャッシュされたためだと思われる。

なお、履歴記録の不良としては:

も忘れてはいけない。っていうか、devel-ml でこの投稿を目にして以来、『こんなニッチな障害に気が付くなんて、どんだけソースを読み込んでいるのよ？！』と思っていたので、今回丁度パッチを投函した当人が参加されていたので確認したところ:

開発で使用していたデータファイルが、たまたま該当するパターンで始まっていたので、顕在化した

とのこと。ファームウェア冒頭にバージョン番号を埋め込んでいたらしい。すげーピンポイントに地雷を踏み抜いているなぁ(笑)。

話は戻って、っていうかイマイチ戻らないけど(笑)、リポジトリ間での clone/push/pull をこまめに実施することで:

  • 転送分に対する都度整合性チェックが走ることで、早い段階で破損が顕在化
  • 複製分がバックアップになるので、機器破損や拠点災害等への対処が容易

といったメリットが享受できるので、『一人 Mercurial』の場合も、あちこちにリポジトリを分散させておくのが吉。

Subversion 連携

今回の発表枠の一つは、cointoss1973 氏による『Hgsubversionについて』と題した Subversion 連携に関するもの。

twitter 上に Subversion 連携に関する疑問が随分流れていたので、つい最近になってSubversion 連携に関してまとめてみたのだけれど、公開直後に cointoss1973 氏の TokyoMercurial での発表とネタが被っている事に気付いて大慌てだったことは内緒(笑)。

ちなみに、cointoss1973 氏とは途中まで帰路が一緒なので、車中でも色々話をしたのだけれど、その際に話題に上がったのが:

日本語ファイル名を使用する可能性の高いドキュメント類は Subversion で管理。
それ以外のソース類は Mercurial で管理。
Mercurial のサブリポジトリ機能を使うことで、必要に応じて両者の対応関係を記録。

という運用方法。

サブリポジトリでの記録の場合、親リポジトリである Mercurial 側で記録されるのは、『サブリポジトリのリビジョン情報』のみであり、リビジョン内部のパス名等は一切記録されないことから、日本語ファイル名の問題も発生しない。

『編集中はファイルをロックしたい』というニーズが生じるのは、多くの場合、MS Office 系ファイル ＝ ドキュメントファイルなので、この構成なら Subversion 側でニーズに応じることができる。

コードウォーキング

今回のもう一つの発表枠は、僕の『Mercurial ソースのコードウォーキング』。

『コードリーディング』ではなく『ウォーキング』にしたのは、『ウォークスルー』(walk-through) とか、Nike Mercurial (サッカーシューズ) とかにも掛けているけど(笑)、『読み込む』よりも少し浅めに流す感じで進めようと思っていたため。

事前知識のまとめ資料を元に、今回は "hg add" の処理過程をざっと流したのだけれど、終わってみれば『コードランニング』ないし『コードスプリント』状態だったかも？(笑)

まぁ、30分少々という時間枠だと、走らざるを得ないのは仕方が無いよねぇ……

その他

※ 随時エントリを公開してリンクを追加します