記事検索
月別アーカイブ
アクセスカウンター

    タグ絞り込み検索

    HG

    2011年11月25日15:39MQのタグ

    hgのMQをつかうとパッチをあてたり外したりを機械的にできるようになるところが便利。

    たとえば作業ディレクトリのリビジョン番号が1234だとしよう。

      1234        1235
    __o___________o tip
      いまここ
    

    じつは作業ディレクトリもひとつのチェンジセットだとおもうと hg parent で作業ディレクトリのリビジョンが表示されることに納得。

              work
              o
      1234   /    1235
    __o_____/_____o tip
      いまここ
    

    このときに hg qpush patch3 すると、こんなグラフになる。

                  qbase           qtip,tip
              ____o_______o_______o
             /    patch1  patch2  patch3
    __o_____/______o
      qparent      one of head
    
    qparent パッチをあてた元チェンジセット
    qbase いちばん先にあてたパッチ
    qtip いちばん最後にあてたパッチ
    tip 最後にcommitしたチェンジセット

    ほんとtipって何の役にたつのかわからないが、たとえばパッチがあたった状態で hg pull してqparentの先がのびるとtipがかわる。

                  qbase           qtip
              ____o_______o_______o
             /    patch1  patch2  patch3   tip
    __o_____/______o_______________________o
      qparent                              one of head
    

    diffのとりかたも、どことどこの差分を表示するのかでいろいろあってめんどくさい。

    hg diff qtip(patch3)からworkへの変更(作業領域内での変更)
    hg export qtip リビジョンpatch2からリビジョンpatch3への変更(patch3の内容そのもの)
    hg qdiff patch3 + workの変更 (= hg export tip + hg diff)

    実際にやってみるとこんなかんじ:

    % cat -n foo
         1	export LANG=C
         2	export HGUSER=koie@example.jp
         3	rm -r repo
         4	hg init repo
         5	cd repo
         6	echo 111111111 >file
         7	hg add file
         8	hg commit -m xxx file
         9	hg qinit
        10	hg qnew patch
        11	echo 222222222 >>file
        12	hg qrefresh
        13	echo 333333333 >>file
        14	hg glog
        15	hg diff
        16	hg export qtip
        17	hg qdiff
    % sh -x foo
    + export LANG=C
    + export HGUSER=koie@example.jp
    + rm -r repo
    + hg init repo
    + cd repo
    + echo 111111111
    + hg add file
    + hg commit -m xxx file
    + hg qinit
    + hg qnew patch
    + echo 222222222
    + hg qrefresh
    + echo 333333333
    + hg glog
    @  changeset:   1:56e00314d749
    |  tag:         patch
    |  tag:         qbase
    |  tag:         qtip
    |  tag:         tip
    |  user:        koie@example.jp
    |  date:        Fri Nov 25 15:37:02 2011 +0900
    |  summary:     [mq]: patch
    |
    o  changeset:   0:e0bf2be8ddd5
       tag:         qparent
       user:        koie@example.jp
       date:        Fri Nov 25 15:37:01 2011 +0900
       summary:     xxx
    
    + hg diff
    diff --git a/file b/file
    --- a/file
    +++ b/file
    @@ -1,2 +1,3 @@
     111111111
     222222222
    +333333333
    + hg export qtip
    # HG changeset patch
    # User koie@example.jp
    # Date 1322203022 -32400
    # Node ID 56e00314d749987b2548cf4073f9202f9bb40c46
    # Parent  e0bf2be8ddd5b4b2886984b82fe9faf9713a4604
    [mq]: patch
    
    diff --git a/file b/file
    --- a/file
    +++ b/file
    @@ -1,1 +1,2 @@
     111111111
    +222222222
    + hg qdiff
    diff --git a/file b/file
    --- a/file
    +++ b/file
    @@ -1,1 +1,3 @@
     111111111
    +222222222
    +333333333
    %
    


    このエントリーをはてなブックマークに追加
    2011年11月11日21:29FreeBSD Subversionのgitミラーをhgでとってくる
    % hg clone git://git.freebsd.your.org/freebsd.git
    複製先ディレクトリ: freebsd
    importing git objects into hg
    ブランチ default へ更新中
    ファイル状態: 更新数 49159、 マージ数 0、 削除数 0、 衝突未解消数 0
    71918.132u 7618.691s 23:24:06.22 94.4%  1472+1323k 0+0io 12489pf+0w
    % du -sh freebsd/.hg
    5.7G    freebsd/.hg
    % cd freebse
    % hg tags | wc
        2099    4198  111447
    % hg bookmarks | wc
        2098    4197  104350
    % du -hs /usr/src/.hg
    800M    /usr/src/.hg   ← こっちはhgsubversionでトランクだけをとってきたやつなのでずっと小さい。
    %
    

    hg cloneでとってくる間は1スレッドでCPU100%つかって23時間かかっている。(CPUは古いんだけど)やっぱりgitとhgの速度差は大きいなぁ。

    % time git clone git://git.freebsd.your.org/freebsd.git
    Cloning into freebsd...
    remote: Counting objects: 1949218, done.
    remote: Compressing objects: 100% (463908/463908), done.
    remote: Total 1949218 (delta 1491005), reused 1912163 (delta 1453959)
    Receiving objects: 100% (1949218/1949218), 744.50 MiB | 1.25 MiB/s, done.
    Resolving deltas: 100% (1491005/1491005), done.
    198.925u 164.999s 31:31.20 19.2%        1766+1553k 0+0io 63814pf+0w
    % du -sh freebsd/.git
    802M    freebsd/.git
    %
    

    git cloneってmasterしかとってこないんだっけ?やけにリポジトリが小さいな。



    このエントリーをはてなブックマークに追加
    2011年10月28日15:33pypyでmercurialを動かしてみた

    FreeBSDの/usr/srcはhgsubversionでとってきていて、いまの/usr/srcは

    % hg tip
    changeset:   162828:8fff0f0c3911
    svnrevision: 226824
    tag:         tip
    user:        alc@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
    date:        2011-10-27 02:52 +0000 (27 hours ago)
    summary:     contigmalloc(9) and contigfree(9) are now implemented in terms of other
    % hg log -r0
    changeset:   0:6d11119de1ac
    svnrevision: 3
    user:        rgrimes@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
    date:        1993-06-12 14:49 +0000 (1993-06-12)
    summary:     This commit was generated by cvs2svn to compensate for changes in r2,
    %
    

    というかんじで、最初からとってきているのでとてもでかい。途中のリビジョンからとってくればいいんだけど、せっかくなのでそのままにしてある。チェンジセットがたくさんあるせいなのか、hgコマンドはなにするにも1秒以上かかって、ちょっとイライラする。以前は数秒もかかってほんとうにイライラしたがhgsubversionなのかhgなのか改善されてましになった。

    で、pypyというpythonの実装があるらしくて、素のpython(CPythonというらしい)よりも速いらしいので、じゃあためしてみるか、と。

    portsにpypyがないのでFreeBSDでは動かないのかとおもったがチャレンジ。

    Building from sourceをみながらpypyのインストール。

    % hg clone https://bitbucket.org/pypy/pypy
    % cd pypy/pypy/translator/goal
    % python translate.py -Ojit  ←←まだpypyがないのでCPythonでつくる
    

    途中コンパイルエラーも見えたような気がするがbuildはどんどん進んでいく。しばらくすると何かカラフルな模様がでてきて、なにかのプログレスバーかとおもってたら、上下対象の模様がみえだしてきてやっとマンデルブローだと気付いた。たしかにBuilding from sourceにも書いてある。で4GBのメモリが必要だとも書いてある。そのときは物理メモリは11GB載っているので問題ないぜ!とおもってた。もうかなりの時間がたつのに終わらないのでtopでみてみるとプロセスサイズが3.5GB(常駐3.0GB)になったところで頭打ちになってpageoutがはじまっていたので、できるだけ不要なプロセスを閉じて放置しといた。

    夜になって終わってるかみてみたらまだ何かやっていてswapin/swapoutもおこっていた。どうやらZFSのARC(adaptive replacement cache)が3GBで下げ止まっている。しかたないのでX serverを止めたりしてみたが、ほとんどのプロセスからメモリが剥されたあとだったので効果なし。放置。

    朝になったらおわっていたが、11時間ちかくかかったようだ。おそろしい。openoffice並だ。会社のpython野郎にきいてみたら自分でコンパイルしたことがないから知らんといわれた。最近の若いのはそんなんだよね。

    [translation:info] usession directory: /tmp/usession-default-0
    [translation:info] created: /home/koie/repo/pypy/pypy/translator/goal/pypy-c
    [Timer] Timings:
    [Timer] annotate                       ---  4436.3 s
    [Timer] rtype_lltype                   ---  2757.3 s
    [Timer] pyjitpl_lltype                 ---  4861.3 s
    [Timer] backendopt_lltype              ---  2436.0 s
    [Timer] stackcheckinsertion_lltype     ---   566.4 s
    [Timer] database_c                     ---  5688.6 s
    [Timer] source_c                       --- 13597.5 s
    [Timer] compile_c                      ---  4305.5 s
    [Timer] ============================================
    [Timer] Total:                         --- 38649.0 s
    

    とりあえずインストールイメージをつくってからインストール。

    いろいろGNUツールやLinuxしか考えてないようなでFreeBSDではちょっと手直しが必要だった。tarはgtarに、グループrootはwheelに。linuxってgid=0はrootなんだね。はじめてしった。

    diff --git a/pypy/tool/release/package.py b/pypy/tool/release/package.py
    --- a/pypy/tool/release/package.py
    +++ b/pypy/tool/release/package.py
    @@ -124,11 +124,11 @@
             else:
                 archive = str(builddir.join(name + '.tar.bz2'))
                 if sys.platform == 'darwin':
    -                e = os.system('tar --numeric-owner -cvjf ' + archive + " " + name)
    +                e = os.system('gtar --numeric-owner -cvjf ' + archive + " " + name)
                 else:
    -                e = os.system('tar --owner=root --group=root --numeric-owner -cvjf ' + archive + " " + name)
    +                e = os.system('gtar --owner=root --group=wheel --numeric-owner -cvjf ' + archive + " " + name)
                 if e:
    -                raise OSError('"tar" returned exit status %r' % e)
    +                raise OSError('"gtar" returned exit status %r' % e)
         finally:
             os.chdir(old_dir)
         if copy_to_dir is not None:
    
    % cd pypy/tool/release
    % python package.py ../../.. pypy-my-own-package-name
    % cd /tmp/usession-default-5/build
    % mkdir ~/tmp/pypy-a2b911e61392
    % tar xvf pypy-my-own-package-name.tar.bz2 -C ~/tmp/pypy-a2b911e61392
    % cd ~/tmp/pypy-a2b911e61392
    % ln -s pypy-a2b911e61392 pypy
    

    次はhgのビルド。

    PYTHON=$(HOME)/tmp/pypy/bin/pypy に書き換えて gmake all して、 gmake PREFIX=$HOME/tmp/hg install。

    そしてついに/usr/srcで簡単にベンチマーク。「hg log --style=compact >/dev/null」の実行時間を測ってみた。

    cpython 113.216u 16.762s 2:10.19 99.8% 1458+1471k 0+0io 0pf+0w
    pypy 149.352u 22.263s 2:51.88 99.8% 21542+28179k 0+0io 0pf+0w

    どうみてもpypyの方が遅い。なんだこれは。ふたたびpython野郎に「どういうことなんだ、これはっ!」聞いてみたら、「まぁそんなもんですよ」って返事。脱力。パイパイって音からしてはずかしいのに使うのもはずかしいとは。またしても地球温暖化に貢献してしまった。



    このエントリーをはてなブックマークに追加
    2010年12月28日14:04hg transplant

    hg transplantの基本的な使い方を覚えた。

    ~/.hgrcか.hg/hgrcにこれ↓をいれると使えるようになる。

    [extensions]
    transplant=
    

    transplantした結果は.hg/transplant/transplantsに記録されるようだ。ただhg cloneしたときに引き継がれないので注意が必要か。このへんが基本機能のmergeと扱いが違うところ。CVSではcherry pickが基本だったのでユーザがどこをマージしたのかを覚えておかなければならなかったが、hgではグラフ構造でマージ関係を覚えるのでマージがとてもわかりやすくなった一方で、特定の変更だけをとりこむことができなくなり、拡張機能として hg transplat が用意されている、とおもう。

    以下ためしてみたときのログ。画像は https://bitbucket.org/koie/hg-dot/ で作成した。

    % hg init repo
    % cd repo
    % echo "11111" >file
    % hg commit -A -m initial file
    % echo "22222" >>file
    % hg commit -m second file
    % echo "33333" >>file
    % hg commit -m third file
    % hg glog --style compact
    @  2[tip]   4c711a087ccd   2010-12-28 13:39 +0900   koie
    |    third
    |
    o  1   2a9a9bbae480   2010-12-28 13:39 +0900   koie
    |    second
    |
    o  0   7c68bdadd780   2010-12-28 13:38 +0900   koie
         initial
    
    % hg up 1
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
    % echo "XXXXX" >>file
    % hg commit -m hack file
    created new head
    % hg glog --style compact
    @  3[tip]:1   f983fc95151f   2010-12-28 13:41 +0900   koie
    |    hack
    |
    | o  2   4c711a087ccd   2010-12-28 13:39 +0900   koie
    |/     third
    |
    o  1   2a9a9bbae480   2010-12-28 13:39 +0900   koie
    |    second
    |
    o  0   7c68bdadd780   2010-12-28 13:38 +0900   koie
         initial
    

    3

    % echo "YYYYY" >>file
    % hg commit -m hack2 file
    % hg glog --style compact
    @  4[tip]   c80cf7c8095d   2010-12-28 13:43 +0900   koie
    |    hack2
    |
    o  3:1   f983fc95151f   2010-12-28 13:41 +0900   koie
    |    hack
    |
    | o  2   4c711a087ccd   2010-12-28 13:39 +0900   koie
    |/     third
    |
    o  1   2a9a9bbae480   2010-12-28 13:39 +0900   koie
    |    second
    |
    o  0   7c68bdadd780   2010-12-28 13:38 +0900   koie
         initial
    

    4

    % cat -n file
         1  11111
         2  22222
         3  XXXXX
         4  YYYYY
    % hg up 2
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
    % cat -n file
         1  11111
         2  22222
         3  33333
    % hg transplant 4
    applying c80cf7c8095d
    patching file file
    Hunk #1 FAILED at 0
    1 out of 1 hunks FAILED -- saving rejects to file file.rej
    patch failed to apply
    abort: fix up the merge and run hg transplant --continue
    % cat file.rej
    --- file
    +++ file
    @@ -1,3 +1,4 @@
     11111
     22222
     XXXXX
    +YYYYY
    % cat -n file.rej
         1  --- file
         2  +++ file
         3  @@ -1,3 +1,4 @@
         4   11111
         5   22222
         6   XXXXX
         7  +YYYYY
    % cat -n file
         1  11111
         2  22222
         3  33333
    % (EDIT)
    % cat -n file
         1  11111
         2  22222
         3  33333
         4  YYYYY
    % hg transplant --continue
    c80cf7c8095d transplanted as 22e2895df1d2
    % hg glog --style compact
    @  5[tip]:2   22e2895df1d2   2010-12-28 13:43 +0900   koie
    |    hack2
    |
    | o  4   c80cf7c8095d   2010-12-28 13:43 +0900   koie
    | |    hack2
    | |
    | o  3:1   f983fc95151f   2010-12-28 13:41 +0900   koie
    | |    hack
    | |
    o |  2   4c711a087ccd   2010-12-28 13:39 +0900   koie
    |/     third
    |
    o  1   2a9a9bbae480   2010-12-28 13:39 +0900   koie
    |    second
    |
    o  0   7c68bdadd780   2010-12-28 13:38 +0900   koie
         initial
    
    %
    

    5



    このエントリーをはてなブックマークに追加
    2010年12月18日01:16「分散バージョン管理勉強会」にいってきた

    dscn5241都営大江戸線の門前仲町から歩いた。暗いし方向音痴なのでかなり不安になりながらも、一発で到着できた。厚着してたせいで、汗をかいてしまった。

    電源の延長ケーブルは2mのをもっていったが、ちょっと足りなくて、机の上まで届かず失敗。

    WiMAXはアンテナ2本立ってだいじょうぶだった。


    [最初の挨拶]d76eaf11.jpg

    • 挙手でどのユーザが多いかみてみると:
      • git多数
      • hg少数
    • スイーツいっぱい食べてください。大福はいちご・くり・バナナ・わさび(大当り)。
    • お茶もあります。

    [一般発表]

    1. おかもとさん - 前説 分散バージョン管理システムってなんなん?

    • さわりであっておさわりではない
    • エルシャダジャイル?
      • 「そんな担当者でだいじょうぶか?」
    • Trac Lightning
    • OSSバージョン管理システムの発展
      • CVS: 共有モデル、ファイル単位の履歴
      • Subversion: アトミックなコミット(途中で死んでもだいじょうぶ)、タスク単位での履歴管理
      • 分散バージョン管理: ブランチマージモデル、ローカルコミット、ログのリファクタリング、マージトラッキング
    • いろいろ
      • git:
        • google trendsでいちばん多い。
        • linux/ruby系につかっているひとが多い。
      • hg: mercurialは盗賊の意味もある。subversionからシェアをうばってやるぞ!といういみもあるか?。スポンサーがおおい。
        • google trends: フランス(ヨーロッパ圏)で強い?
        • リビジョンがハッシュでなくて数字もあるのでわかりやすい。TortoiseHgでwindowsでばっちり。
      • bazaar:
        • gnuプロジェクト、日本語のあつかいが完璧。

    2. bleis - GitとHudsonによるきれいなリポジトリの作り方

    • ソフトウェア開発に対する思い:
      • 集中管理型だと間違った操作がすぐに全体に影響をあたえてしまう。
      • 誤操作を恐れるあまり、日付のついたディレクトリをつくってしまったり。→VCつかっている意味なし。
      • 1つのリポジトリに対して1つの作業領域しかもてない。
      • DVCSだと更新先を複数もてる。
    • DVCSだけでは解決でいない問題:
      • ビルドできなくなるとか。
    • きれいなリポジトリとは:
      • ここでは「最新版がいつでもビルド可能なリポジトリ」のこと。
    • CI(継続的統合;continuous integration)を導入する:
      • ビルドがこわれるとすぐにフィードバックがえられる。
      • 用語定義:
        • 開発者ごとのブランチ: private branch
        • 開発者ごとのリポジトリ: private repository
        • きれいなリポジトリ: central repository
      • ブランチをわける方法:
        • hookでmaterブランチにpushできないようにする。
        • ビルドに成功してもfast forward mergeできなかったら拒否する。
        • 手軽。CIを増やすだけ。
      • リポジトリを分ける方法:
        • central repositoryは外部からは取得専用に、localからのpushは許可。
        • 更新の流れ(更新の循環): centralリポジトリ→(pull)→手元のリポジトリ→(push)→中央のプライベートリポジトリ→(CI)→centralリポジトリ
        • ロールバックすれば簡単に元にもどせるのがミソ。
        • リポジトリ単位でhookを設定できるのでhookを入れる個所が多いのが利点。private repoで単体テストをやって、central repoで結合テストをするとか。
    • Q: CIのジョブはどうやって管理してるのか?
    • A: scalaで。(外野)グルービーとかがいいじゃない?
    • Q: リベースがうまくいかかいとつらい?
    • A: ?

    [休憩(15分)]

    3. ゆかわさん - TracLightningとTortoiseHgのゆるふわな連携

    • pythonで書かれている。
    • http://martinfowler.com/bliki/VersionControlTools.html
      • hgはgitよりもオススメで、gitよりも簡単!
      • bzrはどこいった!
    • hgはsubversionににている。
    • 1コマンド1機能
      • gitは1つのコマンドでいろんなことができるので、そのぶんオプションが多い。
    • MQはあえていうならgitのステージににている。
    • ブランチにいろいろある:
      • hg clone
      • hg bookmark
      • hg branch
      • 名前なしブランチ
    • hgsubvresionは重い。日本語ファイルはだめ。
    • hgでは拡張機能をつかう必要がある。基本機能だけだとちょっとつらい。

    4. riskさん - git-svn使ってみる?

    • 職場でしかコミットできないとか、客先に行かないとできないとか。そのような場合にgit-svnが便利。
    • とりあえずおぼえておくコマンド:
      • git-svn: clone dcommit rebase
      • git: branch checkout add rm revert reset status log commit merge
    • gitとsvnの対応表:
    ----------------- --------------
    git svn clone svn checkout
    ----------------- --------------
    git branch svn branch
    git checkout
    ----------------- --------------
    git commit svn commit
    ----------------- --------------
    git svn rebaes svn update
    ----------------- --------------
    git merge ???
    ----------------- --------------
    git svn dcommit svn commit
    ----------------- --------------

    5. monjudohさん - Mercurialで別オリジンのリポジトリ間で同期を取る運用の仕方について

    • 素朴なやりかた:
      • hg clone django-apps
      • cd django-apps
      • hg pull --force django-static
      • mergeできるけどやったら二度とぶんりできない。pushするとくっついてっちゃう。
    • 別のやりたかた:
      • hg update djsnag-apps-head
      • hg revert statis/ -r django-static-head
      • hg commit -m "message"
      • 履歴がきえちゃうのが問題。
    • transplantをつかうやり方:
      • hg pull django-static
      • hg update django-apps-head
      • hg transplant
    • まとめ:
    • django-apps からpull
    • ldjango-stati-headへtransplant
    • django-static個人へpush
      1. hg push django-static -f -r django-static-head
    • django-staticでrebase
    • django-staticからpull
    • django-apps-headへtransplant
      1. 必要ならtransplantした分をcommit圧縮
    • django-appsにpush
    • Q: subrepostoryの方が簡単では?
    • A: 最初からできるならsubrepositoryをつかう方が簡単だけど。途中からだと。

    [休憩(10分)]

    [LT発表]

    1. 神速さん - Git での歴史の改変方法の紹介

    • 資料はReST。その場で作成
    • rst2s5.pyでReSTからHTMLに変換。
    • add -p 部分コミット
    • rebase -i ローカルだけで 歴史の改変 順序の入れ換えがでいる

    2. iwataさん - SVNユーザのためのBazaarガイド

    • バザー。バザールではない
    • concenpts:
      • version control for human beings → バカでもつかえるバージョン管理
      • better svn
        • checkoutするとbindされた状態になる。commitするとすると自動でpushされる。集中型っぽいふるまい。もちろんlocal commitもできる。

    3. さぼてんさん - Hudsonからみるバージョン管理

    • pre-test commit
    • TeamCity
    • きれいなコミットができる
    • (ここでbleisさんのブランチを分ける方法と同じ絵がでてくる)

    4. かわにしさん - ビューティフルなデバッグの話

    • git bisect
    • しんそくさんの「ナンパ」になった時期をしらべる。
      • 事前にtwitterの内容をcommit済で、pythonで文字列"ナンパ"を探すテストプログラムをくわせる。

    [最後の挨拶]

    • - 9回目

    [後片付け]

    帰り道

    dscn5243江東区は路上喫煙okなので、けっこう吸ってる人がおおいな。

    五反田よりもずっとにぎわっている。

    忘年会シーズンなので50くらいのおっさん・おばさんが大声を出して街をさまよってた。



    このエントリーをはてなブックマークに追加
    2010年12月03日16:40hgsubversionでとってきたけどsvnのリビジョンをしりたいとき
    hgsubversionでFreeBSD svnをもってくるのつづき。

    .hg/svn/rev_mapにhgとsvnのリビジョンの対応関係が記録されているので、これをもとに.hg/localtagsを生成すれば、-r オプションで svn のリビジョンを指定できるようになる。また hg log でタグとしてsvnのリビジョンがわかる。
    ただFreeBSDのheadをとってくると2010-12-02の時点でリビジョンが157081もあり、これを全部localtagsに変換するとhgの動作が極端に遅くなるため、直近の10000個(15分の1)にすることで実用的な範囲に収めている。
    さらに、localtagsを時系列と逆順にした方が速くなるっぽいので/usr/local/bin/gtac (in sysutils/coreutils)をつかっている。
    スクリプト:

    awk 'NF==2{print $2 " svn-r" $1}' .hg/svn/rev_map | tail -10000 | gtac >.hg/localtags
    
    使用例:
    % hg log -r svn-r216107
    changeset:   157078:17db89e84c98
    tag:         svn-r216107
    user:        lstewart@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
    date:        2010-12-02 02:32 +0000 (29 hours ago)
    summary:     General cleanup of the NewReno CC module (no functional changes):
    
    %
    


    2010-12-06追加:
    hgsubversion/hgsubversion/help/subversion.rst をみると、templateで {svnrev} がつかえるとか、リビジョン指定で -r 'svnrev(500)' とできるとか、便利になってた。
    ~/.hgrc or .hg/hgrc の例:

    [ui]
    style=~/.hgstyle
    

    ~/.hgstyleの例:
    changeset = 'changeset:   {rev}:{node|short}\nsvnrevision: {svnrev}\n{branches}{
    tags}{parents}user:        {author}\ndate:        {date|isodate} ({date|age})\ns
    ummary:     {desc|firstline}\n\n'
    changeset_quiet = '{rev}:{node|short}\n'
    changeset_verbose = 'changeset:   {rev}:{node|short}\nsvnrevision: {svnrev}\n{br
    anches}{tags}{parents}user:        {author}\ndate:        {date|isodate} ({date|
    age})\n{files}{file_copies_switch}description:\n{desc|strip}\n\n\n'
    changeset_debug = 'changeset:   {rev}:{node}\n{branches}{tags}{parents}{manifest
    }user:        {author}\ndate:        {date|isodate} ({date|age})\n{file_mods}{fi
    le_adds}{file_dels}{file_copies_switch}{extras}description:\n{desc|strip}\n\n\n'
    start_files = 'files:      '
    file = ' {file}'
    end_files = '\n'
    start_file_mods = 'files:      '
    file_mod = ' {file_mod}'
    end_file_mods = '\n'
    start_file_adds = 'files+:     '
    file_add = ' {file_add}'
    end_file_adds = '\n'
    start_file_dels = 'files-:     '
    file_del = ' {file_del}'
    end_file_dels = '\n'
    start_file_copies = 'copies:     '
    file_copy = ' {name} ({source})'
    end_file_copies = '\n'
    parent = 'parent:      {rev}:{node|formatnode}\n'
    manifest = 'manifest:    {rev}:{node}\n'
    branch = 'branch:      {branch}\n'
    tag = 'tag:         {tag}\n'
    extra = 'extra:       {key}={value|stringescape}\n'
    


    このエントリーをはてなブックマークに追加
    2010年04月21日13:12hgのコミットログを直す方法

    この方法がいちばん簡単そうだ。mercurialの場合、コミットしなおすとリビジョン番号が変わってしまうので、すでに他のリポジトリにpushしてたりpullされてたりする場合には相手のリポジトリでhg stripを実行して古いリビジョンを消してもらう必要があるだろう。

    • hg qimport -rリビジョン番号
      • リポジトリにコミットされているのをMQに移す
    • hg qrefesh -e
      • コミットメッセージを書き換える
    • hg qfinish -a
      • リポジトリに戻す


    このエントリーをはてなブックマークに追加
    2010年03月30日03:23hgsubversionでFreeBSD svnをもってくる

    どうも話によるとhg convertよりもhgsubversionのほうがいいらしいということでメーリングリストの協力を得ていろいろやってみた。

    • hgsubversionのインストール
    • svn→hg
      • hg clone svn://svn.freebsd.org/base/head freebsd-head-hg
        • とても時間とメモリを消費します。わたしのところでは51時間かかって仮想メモリは13GBも必要でした。
        • python swig bindingでメモリリークしているかもしれないとの情報もあります。
      • hg clone -r1000 svn://svn.freebsd.org/base/head freebsd-head-hg
        • こうするとsvnのr1000までしか変換しません。
      • cd freebsd-head-hg; hg pull -r2000
        • こうやってすこしずつ変換していけばメモリリークも恐くありません。
        • "abort: 00changelog.i@100: no node!" とか出ますが、とりあえずリポジトリは出きているようです(hg verify調べ)。


    このエントリーをはてなブックマークに追加
    2010年02月11日17:31hgとかでファイアウォールの中のリポジトリにアクセスする方法
    ssh-agentを動かしておいて(とうぜんssh-addはしておく)、hgrcに
    [ui]
    ssh = ssh -A koie@gateway ssh
    と書いておけば、gatewayを越えてリポジトリにpush/pullできる。 windowsだったらPageantを動かしておいて(とうぜんadd keyはしておく)、$HOME\mercurial.iniとか個別のhgrcに
    [ui]
    ssh = "C:\Program Files\TortoiseHg\TortoisePlink.exe" -ssh -2 koie@gateway -A ssh
    と書く。

    このエントリーをはてなブックマークに追加
    2010年02月06日17:09MQパッチと普通の修正の競合を解決する方法

    MQで作業ディレクトリにパッチが適用されている状況で、いますぐ別の修正をコミットしたいとき、しかもMQでパッチをあててることを忘れていた場合に、どうすればよいか?

    1. hg qnew -fで修正をパッチ化
    2. hg qpop -aでパッチ適用なしの状態にする
    3. .hg/patches/seriesを編集して先頭にもってくる
    4. hg qpush; hg qrefresh -m xxx; hg qfinish -a

    パッチをあててることをすぐ忘れてしまうんだよなぁ。

    http://groups.google.com/group/mercurial-ja/t/3364304aad79e08d



    このエントリーをはてなブックマークに追加