Mercurial に関するコミュニティ由来の成果(2014年版) - 彷徨えるフジワラ
本エントリは、2014年の一年間に、ML/twitter/勉強会といったコミュニティから上がった情報／要望の中で: Mercurial 本体に取り込まれた修正の契機になったもの Mercurial 本体に取り込まれてはいないものの、何らかの成果に結びついたもの 『今後の作業のネタ』(＝ バックログ)として認識されているもの 上記に該当するものを、情報提供への感謝の意味も込めて、列挙したものです。 『気になった点に関して、情報提供をする』だけでも、十分開発に貢献できる事の証拠とも言えます。 今後も、Mercurial に関して疑問／質問／要望等があれば、お気軽に情報をお寄せください ＞ 利用者の皆様 情報をお寄せ頂く手段に関しては、"Mercurial で困った時に" をお読みください。 また、抽出が大変だったので本エントリでは列挙しませんでしたが、メッセージ翻訳に関する不具合報告／要望等も
OS毎のシステムコール実行性能 〜 その2 - 彷徨えるフジワラ
前回は、fork および execve システムコールの実行性能を、OS毎に計測して比較してみました。 fork を比較したのなら、当然 vfork も比較したくなるのが人情ですよね？(笑) その1: fork, execve の性能計測 その2: vfork の性能計測 その3: fstat, lstat の性能計測 その4: getpid, gettimeofday の性能計測 その5: time, umask の性能計測 その6: まとめ vfork の性能比較 確認用プログラムの手順は、vfork を呼び出す以外は、fork の性能比較時と全く同じです。 引数文字列を整数に変換 0 なら終了 それ以外なら、vfork を実施 子プロセスは、即時 _exit 親プロセスは、子プロセスを wait 指定整数から 1 を減じて、手順2から繰り返し 繰り返し回数 0x10000 = 約6万
OS毎のシステムコール実行性能 〜 その1 - 彷徨えるフジワラ
Mercurial のテストセット ("make tests") を複数の環境で実行したところ、ほぼ同一性能の CPU 上での実行にも関わらず、Mac OS X 上での実行では、仮想環境上の Linux での実行よりも、大幅に時間を要することが確認できました。 仮想環境上の実行ではクロック情報の精度がよろしくないので、計測主体が仮想環境上にあるベンチマーク結果はあまり信用できない、ということを考慮に入れても、明らかに体感できるレベルで遅い（分単位の所要時間差）ので、単純に「仮想環境上の計測誤差が、良い方向に出ている」と片付けるわけにも行きません。 そこで、幾つかのシステムコールに関して、OS 間での実行性能を計測してみることにしました。 元々の比較対象が「Mercurial のテストセット」なので、比較的影響が高そうな、以下のシステムコールを計測対象にします。 fork/exec 等による
Facebook の Mercurial に対する本気度まとめ - 彷徨えるフジワラ
Facebook のエンジニアブログで "Scaling Mercurial at Facebook" と題するエントリが 2014-01-07 に公開され、大きな注目を集めました。 また、このブログエントリについて解説した InfoQ の記事 "Facebook makes Mercurial faster than Git" や、その翻訳 "Facebook、MercurialをGitよりも速くする" も、多くの人がリツイートするなどして話題にしています。 このエントリでは、上記の記事では触れていない、Facebook の Mercurial への本気具合について、まとめてみました。 人的関与 Facebook は Mercurial の主要開発者を何人も雇用しています。最も顕著な例が、Mercurial プロジェクトのリーダーである Matt Mackall 氏その人の雇用でしょうか
"Android Studio最速入門" 第32回に関する指摘 - 彷徨えるフジワラ
連載 "Android Studio最速入門〜効率的にコーディングするための使い方" における "第32回 バージョン管理─Mercurial連携の使い方" での Mercurial 連携に関する説明で、気になる点があったので、まとめておこうと思います（筆者の方には報告済み）。 ある程度 Mercurial を使い込んでいる人であれば、多分言うまでもない話かもしれませんが、Git と併用しているような人や、Mercurial 初学者の誤解を防ぐことができれば幸いです。 あちらの記事の読者が、こちらのエントリに辿りつけるのかは、微妙なところではありますが、まぁ、そこはネット（＋検索）の力を信じることにしましょう（笑）。 リポジトリを最新の状態に保つ 1ページ目の「リポジトリを最新の状態に保つ」での: つまり，hg pullはGitでいうgit fetch相当なので，git pullに相当する
あなたの知らない(筈の) Mercurial テンプレート - 彷徨えるフジワラ
このエントリは、Mercurial Advent Calendar 2012 の 19 日目です。例によって、エントリ公開の時点で日付が変わってしまっていますが、私が寝るまでが 12 月 19 日です。 暫く前になりますが、開発者用MLに『テンプレート機能を拡張したよ！』という内容のメールがMatt から投函されました。 これまでは、スタイルファイルを書いたり、場合によってはフィルタ関数を自前のエクステンション経由で追加したりしないとできなかったことが、かなりの部分まで有りモノで、しかもコマンドラインから、できるようになる機能拡張です。 default ブランチで実装されたこの拡張機能、メジャーリリースを経て無事 stable にもマージされたのですが、一向に使用方法が文書化される兆しがありません。 うーん、暫くは隠し機能のままにしておくのかな？ でも、そういう非公開機能を使うのって、なん
1.8 版以降の Mercurial を推奨 - 彷徨えるフジワラ
SSH 経由でリモートリポジトリと連携する際に、(1) 連携先ホストのシステムワイドに使用可能 (例: /usr/bin/hg 等) な hg コマンドのバージョンが低い一方で、(2) 連携先リポジトリの hg init で使用した hg コマンド (例 ${HOME} や /usr/local/bin 配下に独自インストールしたもの) のバージョンが、ある程度新しいものである場合、連携先リポジトリの指定が正しくても、以下のようなエラーメッセージが表示される可能性があります。 there is no Mercurial repository here (.hg not found)! ※ 日本語出力の場合: Mercurial リポジトリが見つかりません(.hg が不在です) 以下の2つのバージョンで、前者のみが 1.7 以前の場合は、まず間違いなくこの問題に該当するものと思われます。 s
Mercurial 2.3 版での内部 API 変更による 3rd party エクステンションのトラブル - 彷徨えるフジワラ
Mercurial 2.3 では、幾つかの内部 API の仕様が変更されたことで、3rd party エクステンションの中には、正常に動作しないものがあります。 現状、私が情報を把握しているものは以下のものです。 hggit (※ 修正済み) hgsubversion (※ 修正済み) projrc (※ 修正済み) collapse (rdiff も ?) 『※ 修正済み』表記のあるものは、既に 2.3 API に対応した版が公開されているものです。これらを併用されている方は、速やかに最新版に更新してください。 また、上記で列挙したエクステンション以外で、同様の、あるいは現象は違うけれども、2.3 での API 仕様変更の影響が疑われる現象を見かけた際には、以下のような手段で連絡頂けると助かります。 本ブログエントリへのトラックバック／コメント 私宛のツイート #mercurialjp
obsolete 機能 - 彷徨えるフジワラ
来月(８月)冒頭にリリースされる Mercurial 2.3 版から、 obsolete (marker) と呼ばれる機能が追加される。 >>>> 2012-08-04 追記： ここから 2.3 リリース直前に、デフォルトでは obsolete 設定の追加を抑止する修正が入った模様。 そのため、2.3.x 版で試験的に obsolete 機能を試してみようと思う場合、以下のようなエクステンションを使って obsolete 機能を有効にしてやる必要がある (後述する evolve エクステンションを有効にする方法も)。 from mercurial import obsolete def uisetup(ui): obsolete._enabled = True なお、リリース間際のバタバタの影響なのか、59c14bf5a48c と a1f8869f2eee の２つのリビジョンで "_ena
(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その１ - 彷徨えるフジワラ
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
Mercurial でのサブリポジトリの利用 - 彷徨えるフジワラ
ここ暫く、#TokyoMercurial (+ 懇親会)の席や twitter上などで、サブリポジトリ(subrepo)の利用に関する質問等が多かったのですが、口頭説明や、twitter の文字制限内では、なかなか正確に伝えるのが難しかったので、ブログエントリとしてまとめてみました。 っつーか、ある程度書きあがってから、僕の勘違いに突っ込みが入って、慌てて加筆修正しました(笑)。指摘感謝です！ > @yujauja 氏 サブリポジトリの利用開始 Mercurial のサブリポジトリ機能とは: Mercurial リポジトリを親に、外部のリポジトリやプロジェクトを入れ子にし、 コマンドの実行の際に、 それら一連のリポジトリに対して処理を行えるようにします。 〜 "hg help subrepos" より というものです。 サブリポジトリの追加手順は、hg help subrepos (日本語
Python Developers Festa 2012.03 - 彷徨えるフジワラ
Mercurial ハンズオンのスタッフ要員として、Python Developers Festa 2012.03 に参加してきた。 主催の id:Voluntas 氏を初めとする運営スタッフの皆様、および参加者の皆様、お疲れ様でした。 それから、私の到着、ギリギリ時間過ぎでしたね。受付のお手数をお掛けして御免なさい .... orz > Voluntas 氏 今回のハンズオンは、id:troter 氏の資料を元に、各自が黙々と作業しつつ、適宜 troter 氏や私が質問等に答える、というスタイルで実施。 とりあえず、覚えている範囲で、『入門 Mercurial』や僕のホームページでは明記してない(or 記述が少ない)話題に関しての詳細とか、思い付いたこととかをまとめておく。troter 氏のまとめも併せてご覧ください。 『作業領域』はリビジョンの一種 『作業領域』と『親リビジョン』の関係
SCMBootCamp in Tokyo 2 を振り返って - 彷徨えるフジワラ
※ 2011/11/27 追記あり 時間枠中は、Twitter のタイムラインを見ている暇が無かったので、togetter でのまとめを元に、落穂拾い的に tweet された質問／疑問に答えることに。 まとめて頂いた @shinyaa31( id:absj31 ) 氏に感謝！(※ @shinyaa31氏自身のまとめはこちら) そして、改めて主催の id:kyon_mm 氏に感謝！ 基調講演枠での tweet 講演内容は好評だったようで一安心。 SCM ツール世代分類に関して: (@oota_ken) ClearCaseはClearCaseはClearCaseは まぁ多分、「ClearCase も忘れないであげてください」ニュアンスだとは思うけど、一応答えておく事に(笑)。 私自身、ClearCase を触ったことが無いので、『パターンによるソフトウェア構成管理』に記載された情報ベースで見る
Kindle4 の携帯カバー - 彷徨えるフジワラ
さて、Kindle4 を買ったのだが、本体が無茶苦茶廉価なこともあって、画面保護シートとか専用カバーとかを付けるのは、なんだかとっても損した気分になってしまうことから、その手の保護系付属品は買わない方向で。 とは言え、「表示面に圧力掛けないでね？」と但し書きのあるデバイスを素のまま携行するのは、流石にちょっと気が引ける。鞄に放り込んで持ち歩くにしても、混雑した電車とかだとねぇ。 というわけで、手元にある材料を使って、簡易携帯カバーを自作することに。 まずは、新書用の文庫カバーに、適当に切り出したスチロールボードを貼り付ける。 手元にあったスチロールボードは片面が粘着シートな奴だったので、そのまま貼り付けた。まぁ、固定方法は両面テープとかで適当に。 次に、平織りゴムを使って、折り畳んだ文庫カバーが丁度閉じるぐらいの長さのベルトを作る。 濃紺地の文庫カバーに、黒の平織りゴムなので、ちょっと見辛
「妥当」な Mercurial バージョンの情報 - 彷徨えるフジワラ
※ 2015-01-19 更新 重要なお知らせ: 1.9 ⇒ 2.0、2.9 ⇒ 3.0、3.9 ⇒ 4.0 といったバージョン番号の増加でも、Mercurial のコンセプト／操作性／互換性等における大きな改変はありません。通常の定例アップデートに過ぎませんので、従来の版を元に書かれている情報の多くは、そのまま適用可能です。 現状でそこそこ妥当な Mercurial の版は以下の通りです。 由来不詳のリビジョンを含むリポジトリから履歴情報を取り込む可能性がある場合は、3.2.3 以降の使用を強く推奨 それ以外の場合は 1.8.1 〜 最新版 （使用状況によっては 2.2 〜 2.2.1 および 2.3 〜 2.3.2 の使用回避を推奨） また、個別のケースにおいて回避を推奨する版の情報を以下に示します。 revsets 記述によるリビジョン指定を多様する場合は、2.5 版以上を推奨(詳細
VirtualBox@Solaris での光学ドライブパススルー - 彷徨えるフジワラ
VirtualBox 最新版の 4.0.0 に更新しても、光学ドライブのパススルー(passthrough)機能の有効化が出来なかったことに納得が行かなくて、暫しネットの海を彷徨った末にやっと情報を入手。 Solaris の場合、パススルーは root 権限で実施して頂きたく あぁ〜、やっぱり root 権限が必要なのね ＞ パススルー どうりで、仮想マシン起動時に「光学デバイスへの書き出し権限がねーよ」とゴネる訳だ。 権限設定をゴニョゴニョいじって光学デバイスへの書き出し権限を確保すれば、仮想マシンの起動自体は出来るのだけど、オーディオＣＤの挿入は一切認識されなかったのは、制御コマンド発行における権限不足等が原因だったのね。 っつーか、マニュアルでのパススルーに関する記述の変遷で確認すると: 3.1.x: 「サポート対象は、データディスクのみ」 3.2.x: 「サポート対象は、データディ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
