Hatena::ブログ(Diary)

彷徨えるフジワラ このページをアンテナに追加 RSSフィード

2030-12-31

「妥当」な 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 版以上を推奨(詳細はこちらのエントリを参照)。それ以前の版を使う場合は、2.3 版の使用を回避することを推奨 (詳細はこちらのエントリを参照) ※ 2013/02/07 更新
  • cp932 (Shift-JIS) 環境でファイル名に日本語を使用する場合:
    • 2.3 〜 2.3.2 版の使用は回避することを推奨 (詳細は日本語 ML への投稿を参照) ※ 2012/10/11 追記 (2.4 版で解消済み)
    • 2.0 〜 2.1 版での largefiles エクステンションの使用は回避することを推奨 (※ 2.1.1 版で解消済み)
    • 1.9 版の使用は回避することを推奨 (※ 1.9.1 版で解消済み)
  • 2.3 版と非同梱エクステンションを併用する場合、そのままでは動作しないケースがありますので、非同梱エクステンションを(対応済みの)最新版に更新するか、2.3 版以降の利用を回避してください(詳細は日本語 ML への投稿を参照) ※ 2012/08/16 追記
  • TortoiseHg 経由で strip 操作を行う場合、上記と同じ原因で正常に機能しませんので、2.3 版 (+ TortoiseHg 2.4.3) の利用を回避してください ※ 2012/08/23 追記
  • MacOS でのインストール (ソースからのビルド/パッケージ管理システムの使用) が失敗する場合、2.1.1 版を回避するか、バイナリ版のインストールしてください (※ 2.1.2 版以で解消済み)
  • Windows/Mac OS などの case insensitive filesystem 上で MQ と併用する場合は、2.0.2 版の使用は回避することを推奨 (※ 2.1 版で解消済み)

「この版にはこういった問題がある」といった情報がありましたら、以下の方法などでお知らせください。

続きを読む

2029-12-07

執筆書籍一覧

各書籍に関するご意見・ご要望・誤記情報等ありましたら、対応するサポート受け付けエントリへのコメントや、@flyingfoozy へのツイートなどでお寄せ頂けると助かります。

lsを読まずにプログラマを名乗るな!

サポート受け付けエントリ

入門TortoiseHg+Mercurial

入門TortoiseHg+Mercurial

入門TortoiseHg+Mercurial

サポート受け付けエントリ

アセンブラで読み解くプログラムのしくみ

サポート受け付けエントリ

俺のコードのどこが悪い?

俺のコードのどこが悪い?

俺のコードのどこが悪い?

サポート受け付けエントリ

入門Mercurial

入門Mercurial Linux/Windows対応

入門Mercurial Linux/Windows対応

サポート受け付けエントリ

2016-12-30

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

本エントリは、2016年の一年間に、ML/twitter/勉強会といったコミュニティから上がった情報/要望の中で:

  • Mercurial 本体に取り込まれた修正の契機になったもの
  • 『今後の作業のネタ』(= バックログ)として認識されているもの

上記に該当するものを、情報提供への感謝の意味も込めて、列挙したものです。

『気になった点に関して、情報提供をする』だけでも、十分開発に貢献できる事の証拠とも言えます。

今後も、Mercurial に関して疑問/質問/要望等があれば、お気軽に情報をお寄せください > 利用者の皆様

情報をお寄せ頂く手段に関しては、"Mercurial で困った時に" をお読みください。

なお、以前のものは、以下から参照できます。

本体に取り込まれた修正(changed by 藤原)

以下に列挙するものは、コミュニティからの情報を元に私が提案した修正のうち、Mercurial 本体に取り込まれたものです。

なお、私の手による修正履歴一覧から、記憶を頼りに目視で抽出したものなので、『俺の情報を元にパッチ作成しておいて手柄を独り占めかよ!?』的なものに心当たりがある方は、お気軽に情報をお寄せください(笑)。

続きを読む

2016-12-22

Python library for ZFS (pyzfs) のバグを修正する

本エントリは Solaris Advent Calendar 2016 の 22 日目です。

Python library for ZFS

libzfs の zfs_iter_*() 系 API 利用について、ソースツリーを網羅的に調べた際に、Python から ZFS を利用するためのライブラリが提供されているのに気付きました (ソースツリー上の格納先から、以下このライブラリを pyzfs と呼びます)。

OpenIndiana 環境であれば、/usr/lib/python2.6/vendor-packages 配下に zfs パッケージとしてインストールされており、システムデフォルトの Python 処理系から事前準備等無しで使用できる筈です。

しかし実際に使ってみると幾つか不具合があったので、これらを修正してみました。

修正版ソースは Bitbucket 上で公開しています。本ブログエントリに関するコードは pyzfs ディレクトリ配下にあります。

illumos 本家に正式に修正要求出さないとなぁ……

続きを読む

2016-12-20

厳密な順序での ZFS スナップショットの列挙

本エントリは Solaris Advent Calendar 2016 の 20 日目です。

動機

既存の ZFS なファイルシステムから、別プールに複製を作成する場合、zfs send + zfs receive を使うのが一般的です。

しかし、そもそも zfs send で指定するスナップショットは、どうやって特定すればよいでしょうか?

例えば、「最新」のスナップショットを使って zfs send を実行する場合、手動での実行なら「目視判定」でも構わないでしょうが、スクリプト等で自動化するなら、何らかの新旧判定基準が必要です 。

新旧判定に属性情報を使用するにしても、zfs get all 出力を見る限りでは、使えそうなものが見当たりません。「作成日」を保持する creation 属性は、単位が「秒」なので、厳密な順序関係を判定する用途には不適切です(まぁ、実運用上は問題無いケースの方が多いと思いますが……)。

続きを読む

2016-12-16

beadm コマンドの舞台裏

本エントリは、Solaris Advent Calendar 2016 の 16 日目です。

「ENOSPC だと beadm destroy できない」問題

先日、久々に仮想環境ゲストの OpenSolaris 上で pkg update を実行したところ、新規ブート環境 (Boot Environment: BE) が作成された上で、大量の更新が実施されたことで、rpool の容量があふれてしまい:

  • "No space left on device" (ENOSPC) で pkg update が失敗
  • beadm destroy 新規BE も ENOSPC で失敗
  • 再起動すると、メンテナンスモードに突入
  • メンテナンスモードでも beadm destroy 新規BE は不可

上記のような、にっちもさっちもいかない状況に陥ってしまいました。

新規 BE はアクティブ化もされていない状況だったので、サクっと破棄できそうな気がするのですが、どうやら beadm destroy 新規BE の際に実施されるマウント処理が、ENOSPC で失敗してしまう模様です。

このような状況で、状態を正常化するには、beadm コマンドの内部的な実現方式を把握しておく必要があります。

続きを読む

2016-11-05

ノートPCを新調 (Let's note CF-SZ6 ドライブレスモデル)

2014 年に以下のような梃入れで延命を図った CF-J10 ですが:

  • メモリ増設 (16 GB 化)
  • キーボード補修 (Caps Lock キー交換)
  • バッテリー交換

その後もいくつか補修を行うことに。

  • Caps Lock キー以外もダメになったので、キーボード全交換
  • 冷却ファンが時折異音を発する (おそらく偏芯?) ため、冷却ユニットを交換

これで当分は安心して使えるだろう、と思っていたのですが:

  • C ドライブの SSD の空き容量が、総メモリ量の 16 GB を切ってしまった
  • 内臓 Wi-Fi が完全にダメになったが、USB の Wi-Fi モジュールだとバッテリー駆動時間が激減

前者だけなら、256 GB 程度の SSD に換装するという手もありますが、ここまで来たなら製品的な寿命と考えて、ノート PC を新調するのが良さそうです。

2014 年時点では碌な買い替え候補がなかったのですが、幸いな事に今回は多くの候補に恵まれました。

続きを読む

2016-03-25

『俺のコードのどこが悪い?』へのご意見・ご要望・誤記情報

拙著『俺のコードのどこが悪い?』に対するご意見・ご要望・誤記情報等ありましたら、本エントリへのコメントとして書き込んでいただければ、可能な範囲(私個人のサポートページへの掲載等)で対応させて頂きます。

twitter 経由なら @flyingfoozy 宛てにお願いします(1/day ぐらいしか確認してませんが ....)。

俺のコードのどこが悪い?

俺のコードのどこが悪い?

なお、副題の「コードレビューを攻略する40のルール」とか「失敗に学ぶ成功の法則とは?」といった大仰な物言いは、販売戦略上から編集さんの意見で付いたものなので、「(この内容で)それってどうよ?」みたいな意見に関しては、私に寄せられても困ります(笑)。私自身も未だにちょっと気恥ずかしいです > 煽り文

書籍中にも書きましたが、本書で取り上げた40項目は、「これさえやれば」的な項目ではなく、「少なくともこれぐらいは」的な項目です。

各自がより有用な確認項目作りをする際の、最初の叩き台として本書が微力なりとも読者のお役に立てば幸いです。

2016-03-22

渡米時のモバイル通信環境に関する備忘録

先日、Mercurial 3.8 Sprint でサンフランシスコに行った際に、現地でのモバイル通信環境を確保するために、事前調査した内容と、実際に現地で確保した通信環境を使用してみての感想を、備忘録代わりに公開しておきます。

前提条件

異郷での一人旅では、「確実にネットワークに繋がる」+「Google Map が使える」が何よりも頼もしいことを、前回のロンドンでの Mercurial 3.6 Sprint で痛感させられたので、今回も現地で SIM を調達することにしました。

前回は手元にある機材が Nexus7 だけだったので、Nexus7 用のデータ通信 SIM に加えて、通話用に別途現地で格安 Nokia 端末を入手しましたが、今回は新たに入手した ASUS ZenFone2 (ZE551ML) でデータ通信(テザリング含む)/通話/SMS を全て賄うことにします。まぁ、通話は全然使いませんけどね(笑)

ちなみに、今回の旅程は:

  • 木曜日: 現地到着(夕方)
  • 金曜日 〜 日曜日: 終日 Sprint
  • 月曜日: 終日観光 〜 深夜発の便で帰国

という感じで、あまり観光の時間が取れないことから、データ通信量は 1GB もあれば十分と思われます。

続きを読む

2016-01-01

2015 年を振り返る&2016 年の抱負 (後付け)

帰省期間に、実家の家電/IT周りを中心とした保守業務に忙殺されて書き損なってしまったのが災いして、結局ズルズル書かず仕舞いだった「2015 年を振り返る&2017 年の抱負」ですが、とりあえず記録がてら、枠を埋めるだけでも埋めておこうと思った次第です (@2017-01-01)

Mercurial 関連活動

● Mercurial 本体への貢献

2015 年の成果はコミット数ベースで 181 件 (うち翻訳作業が 7 件) なので、「コミット数ベースでは、月10件平均で総数120件」は達成できましたが、去年が 280 件だったので、気分的にはちょっと残念な感じです。

続きを読む