本エントリでは、Mercurial 3.5 から導入された "Automatic Pooled Storage for Clone" について説明します。 なお、この機能の開発を主導した、"Mozilla の中の人" こと Gregory Szorc 氏自身も、"My Contributions to Mercurial 3.5" と題したブログエントリで、この機能について言及しています。 share 機能の概要 同一のプロジェクトにおいて、複数の作業を平行して行う場合に、hg clone でリポジトリを複製し、複製先で作業することもあるでしょう。 $ hg clone src cloned1 $ hg clone src cloned2 $ hg clone src cloned3 しかし、hg clone での複製による運用は、履歴情報（図中の色つき矩形部分）が各リポジトリに散在してし
このエントリは、Mercurial Advent Calendar 2013 の11日目です。 このエントリでは、前回の「TortoiseHg の独自機能 〜 履歴の圧縮」に引き続き、TortoiseHg が独自に同梱している機能の紹介として、「変更の退避(shelve)」について説明しようと思います。 とは言いつつ、変更退避機能そのものに関する説明がメインになりますので、変更退避機能の使い方に関して詳しく知りたい方は、ウェブ上の情報や、拙著「入門 TortoiseHg+Mercurial」を参照してください（笑）。2012年の Advent Calendar での "Mercurialでshelveを使う" や、"TortoiseHgでshelveを使う" といったエントリもあります。 入門TortoiseHg+Mercurial 作者: 藤原克則出版社/メーカー: 秀和システム発売日:
Mercurialのリポジトリの履歴のフォーマットは通常のフォーマット以外にgeneraldeltaというものが有ります。 http://mercurial.selenic.com/wiki/GeneralDelta と偉そうに言ってみましたが、NetBSDリポジトリに関するMLのツイートをtwitterで見て初めて知りました。 NetBSD の git/mercurial Repository 作ろうとしている人がいるのか。 http://t.co/JgAYsvynUu— 山本 茂 (@BsdHacker) April 10, 2014 通常のフォーマットと比べるとリポジトリサイズが小さくなるらしい*1ので、pypyのリポジトリで試してみました。 有効にする .hgrcに次の設定をしてください。 [format] generaldelta = true クローンしてみる generald
備忘録代わりに「お気に入り」に入れてあるツィートの棚卸しを兼ねた、TODOリスト代わりの私的エントリですが、勝手に実装してもらえる分には大歓迎です（笑） ＞ 誰か TortoiseHg におけるファイル内容／差分ビューアでの、文字コード選択周りのトラブルに関するツィートは、定期的に見かけます。 TortoiseHg での「ファイル内容」に関する文字コードは、HGENCODING 環境変数に設定したものしか扱えません。 ※ 注意: バージョン 2.11 より前のバージョンでは、utf-8 (こちらが優先) と HGENCODING 環境変数に設定された文字コードの二択になります。 HGENCODING の推奨設定値は: UNIX系環境なら UTF-8 Windows 環境なら cp932 (Shift-JIS 相当) ですので、各環境上では、上記指定値以外の文字コードを使うファイルは、Tor
Windows 環境における、IntelliJ IDEA での Mercurial 連携における文字コード設定周りは、2013年の春先から夏にかけて大きく改善されました。 先日、"Android Studio最速入門〜効率的にコーディングするための使い方" という連載の "第31回 バージョン管理 ─Mercurial連携とBitbucket" における Mercurial の文字コード設定周りの説明に関して、筆者の方と情報交換をする機会がありましたので、折角ですから、現状に至る経緯＋現状での注意点をまとめておこうと思います。 2013年の春頃までは: といった感じでした。 ＃ cp1251 決め打ちな旧版の実装は、こちらを参照 一応: 対応修正は入ったものの: エンドユーザレベルだと、一手間掛ける必要がありました。 しかし、現状では： という状況になっています。 但し: ということから、
'hg grep'は履歴を検索してしまうし、'hg locate "set:grep('hogehoge')"'はマッチした行を表示してくれないので、この二つのコマンドの間の子を作って見ました。 https://bitbucket.org/troter/hg-grepfile 設定 [extensions] grepfile = [path to]/grepfile.py 使い方 こんな感じで管理下のファイルを検索できます。 % hg grepfile -n ctx.walk mercurial/cmdutil.py:1777: for abs in ctx.walk(m): mercurial/commands.py:283: for abs in ctx.walk(m): mercurial/commands.py:1085: for abs in ctx.walk(m): mercu
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
前回のhgwebからイシュトラッカーにリンクを張るではInterhgExtensionを利用しました。が、InterhgExtensionはMercurial-2.6からobsoleteとなりました。 というのも、InterhgExtension相当の機能はwebsubテンプレートフィルターという形でhgwebに取り込まれたからです。 http://selenic.com/hg/log?rev=websub websubをつかう 公開しているリポジトリの.hg/hgrcに次の様な設定を追加します。 [websub] # backlogの場合の例 backlog = s!(DORA-\d+)!<a href="https://demo.backlog.jp/view/\1">\1</a>! InterhgExtensionから移行する場合はセクションの部分をinterhgからwebsubに変
Mercurial-2.6から追加されたunionスキームについて調べてみた。 Mercurial-2.6からリポジトリ指定時にunionというスキームが指定できるようになりました。 unionを利用すると、次の形式で指定した2つのローカルリポジトリの履歴をミックスして閲覧できるようになります。 union:repo1+repo2 # repo1とrepo2の履歴を合算して閲覧する この機能を利用すれば、crew+main*1を手元で模倣できます。 $ hg clone http://hg.intevation.org/mercurial/ main $ hg clone http://hg.intevation.org/mercurial/crew/ crew $ MAIN_REV=$(hg -R main log -b default -l 1 --template "{node}")
※ 2015-01-19 更新 重要なお知らせ: 1.9 ⇒ 2.0、2.9 ⇒ 3.0、3.9 ⇒ 4.0 といったバージョン番号の増加でも、Mercurial のコンセプト／操作性／互換性等における大きな改変はありません。通常の定例アップデートに過ぎませんので、従来の版を元に書かれている…
このエントリはTortoiseHg Advent Calendar 2012の17日目です。既に日付が変わってしまっていますが、私が寝るまでが17日です。 後でやろうと思っていたら既にやられていた。何を言っているかわからねーと思うが(略) 全ての始まりは、以下のツイートを目にしたことでした。 それって、良くある『プログラムラウンチャ』の TortoiseHg 版みたいなのがあれば解決するよなぁ、と思って: などと返信してみたものの、そんな機能は無いだろうから、新規作成かぁ、流石に TortoiseHg のパッチ作成とかに手を出す余裕は無いよなぁ、とりあえず時間ができたらソースでも見ておくか、という流れでマイ TODO リスト入りして放置状態になること暫し。 10月頃に、ウェブ上で『カスタムツールバー』とか言う単語を目にして、何気無しに情報を辿ってみると……あれ？ TortoiseHg 2.
Atlassian Advent Calendar 2012 #augj Atlassian Advent Calendar 2012 #augj on Zusaarのエントリになります。 前日はid:sue445さんのBitbucketとGithubをゆるく比較 #augj - くりにっきです。 明日はid:troter さんです。 git-flow, hg-flow がすごいらしい 楽にブランチ戦略を試せるし、うまいことやれるし、とりあえず始めて見る分にはgit-flow, hg-flowはいいと思うのです。 あれですね。WebアプリをとりあえずつくってみたくなったときにRailsでやってみる。的な。 ですが、なんだかんだでgit-flowやhg-flowになるとコマンドをうちます。素のgitやhgよりとても簡単になってはいますが。 問題はhgのほうです。 hgは既に史上最高のGUIク
共有したい個人メモということで。会社の人とかね。 雑感。DVCSの情報は、不正確なコピペ情報が反乱していて、Git, Hgあたりは結構ひどい。有用なやつはTipsとしてまとめたけど、なかには誤読すると大変なものもある。 「急がば回れ」的に基本から勉強するのが間違える可能性がかなり低くなる。 基本から体系的に学べるものは各DVCSのガイドにした。 ガイドにあがるようなものでも、15hくらいあればハンズオンしながらでもこなせるので、仕事中に困りながら1weekうまくいかないくらいなら、基本からやって、出来る範囲だけを仕事でやるほうがいい。 正直、DVCSなくても仕事できるし、出来る前提の職場なら、職場のワークフローを先輩に聞きながら1weekくらい作業すればいい。 SCM 概念とか DVCSについてだし、書きかけ。【5分でわかるDVCS！ + 20分でわかるGit入門 by Kyon Mm o
来月(８月)冒頭にリリースされる 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
ここ暫く、#TokyoMercurial (+ 懇親会)の席や twitter上などで、サブリポジトリ(subrepo)の利用に関する質問等が多かったのですが、口頭説明や、twitter の文字制限内では、なかなか正確に伝えるのが難しかったので、ブログエントリとしてまとめてみました。 っつーか、ある程度書きあがってから、僕の勘違いに突っ込みが入って、慌てて加筆修正しました(笑)。指摘感謝です！ > @yujauja 氏 サブリポジトリの利用開始 Mercurial のサブリポジトリ機能とは: Mercurial リポジトリを親に、外部のリポジトリやプロジェクトを入れ子にし、 コマンドの実行の際に、 それら一連のリポジトリに対して処理を行えるようにします。 〜 "hg help subrepos" より というものです。 サブリポジトリの追加手順は、hg help subrepos (日本語
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 エクステンションの中には、正常に動作しないものがあります。 現状、私が情報を把握しているものは以下のものです。 hggit (※ 修正済み) hgsubversion (※ 修正済み) projrc (※ 修正済み) collapse (rdiff も ?) 『※ 修正済み』表記のあるものは、既に 2.3 API に対応した版が公開されているものです。これらを併用されている方は、速やかに最新版に更新してください。 また、上記で列挙したエクステンション以外で、同様の、あるいは現象は違うけれども、2.3 での API 仕様変更の影響が疑われる現象を見かけた際には、以下のような手段で連絡頂けると助かります。 本ブログエントリへのトラックバック／コメント 私宛のツイート #mercurialjp
"SCMBootCamp in Tokyo 3" に参加してきた (togetter によるまとめ)。 主催者の id:kyon_mm 氏はじめ、運営スタッフおよび参加者の皆様、お疲れ様でした！ 東京開催は、昨年 11 月の in Tokyo 2 以来の八ヶ月ぶり。 今回も基調講演枠でお話をさせて頂くことに。 この手の勉強会では、『周囲の構成管理ツール導入状況が思わしくない』という話を多々聞くので、そんな周囲を説得する材料になればということで準備したネタだったのに、参加者に聞いてみたら、思った以上に構成管理ツールが周囲に浸透している参加者だったのは、嬉しい話であるけれど、大誤算。 じゃぁ、真中ぐらいの話はバサっと削ってしまうか！？などと思いつつも、まぁ、そんなこともあるよね！ということで、少々時間オーバーしてしまったものの、発表は無事終了。 その後は、実際に手を動かす演習に。 以下、思った
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
TokyoMercurial #3 の懇親会において、@cointoss1973 氏から以下の様な相談が: MQ パッチを "qpop -a" して、再度 "qpush -a" する際に、適用先リビジョンが変わってしまうのは、なんとかならないだろうか？ 最初に相談された時には、何の事やらワケワカで「？？？？ 」な状態だったのだが、お互いの前提条件に関して、色々刷り合わせを行った結果、以下の様なユースケースであることが判明: ローカルリポジトリの最新版を A-base とする MQ を使って、A-base を元に機能 A に関して作業を実施 優先度の高い機能 B の作業が、割り込んで来る 機能 A の MQ パッチを一旦 "qpop -a" 共有リポジトリから最新成果を pull ＋ 作業領域の update この時点の最新版を B-base とする B-base を元に機能 B の作業を実
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
