fc2ブログ

Entries

git bundleでコミットを送り合うテスト

タグ: Git

Alice: リポジトリを作る。

alice$ git init
alice$ echo A > alice.txt # 適当にファイルを作ってコミット
alice$ git add alice.txt
alice$ git commit -m "alice's commit A"
alice$ echo B >> alice.txt # 適当に変更を加えてコミット
alice$ git commit -a -m "alice's commit B"
aliceリポジトリ初期状態

Alice: aliceリポジトリのバンドルファイルを作成し、Bobに送る。

alice$ git bundle create ../alice.bundle HEAD 
alice$ git branch bob # バンドルファイルを作ったリビジョンにブランチを作っておく

Bob: 受け取ったバンドルファイルをcloneしてbobリポジトリを作る。

bob$ git clone alice.bundle bob
bob$ cd bob
bob$ git checkout -b master # masterブランチを用意
bob$ git branch alice # alice.bundleの先端にブランチを作っておく
clone直後のbobリポジトリ

Bob: bobリポジトリにコミットを追加する。

bob$ echo A > bob.txt
bob$ git add bob.txt
bob$ git commit -m "bob's commit A"
bob$ echo B >> bob.txt
bob$ git commit -a -m "bob's commit B"
bobリポジトリにコミットを追加

Bob: alice.bundleの先端からの差分バンドルファイルを作成してAliceに送る。

bob$ git bundle create ../bob.bundle alice..HEAD

Alice: AliceはAliceでaliceリポジトリにコミットを追加している。

alice$ echo C >> alice.txt
alice$ git commit -a -m "alice's commit C"
alice$ echo D >> alice.txt
alice$ git commit -a -m "alice's commit D"
aliceリポジトリにコミットを追加

Alice: Bobから受け取ったバンドルファイルをbobブランチにpullする。

alice$ git remote add bob ../bob.bundle
alice$ git checkout bob
alice$ git pull bob HEAD
AliceのbobブランチにBobの変更をpull

Alice: masterブランチにbobの変更を取り込む。

alice$ git checkout master
alice$ git merge bob
AliceのmasterにBobの変更を取り込んだ

Alice: bob.bundleの先端からの差分バンドルファイルを作成してBobに送る。

alice$ git bundle create ../alice.bundle bob..HEAD

Bob: Aliceから受け取った差分バンドルファイルをaliceブランチにpullする。

bob$ git checkout alice
bob$ git pull origin HEAD
BobのaliceブランチにAliceの変更をpull

Bob: masterブランチにaliceの変更を取り込み、作業を再開する。

bob$ git checkout master
bob$ git merge alice
BobのmasterにAliceの変更を取り込んだ

Redmine Issue Importer Pluginsメモ

タグ: Redmine

RedmineのCSVファイルインポートプラグイン「redmine_importer」のどのフォークがどんな特徴を持っているかのメモ。
確認に使用したRedmineはtrunk@5505(1.1.2.devel)。


akiko-pusu/redmine_importer_org - GitHub

rchady/redmine_importer系列。
zh.ymlがエラーを吐くので取り除いたり、SJISが化けないようにしたり、親チケットのIDを指定してインポートできるようにしてしばらく使っていたが、インポートするファイルが大きいとCookieOverflowが発生するので、ファイルをセッションに格納しないバージョンがあるか探してみることにした。


leovitch/redmine_importer - GitHub

leovitch1.png leovitch2.png

rchady/redmine_importer系列。

特徴:

  • 「コラム毎の対象のフィールド」を自動的に選択してくれる(※redmine_importer_orgと同じ挙動)
  • 「一意な値」を活用することで、親チケットと子チケットを同時に登録できる
  • 少し読みづらいが、日本語化されている
  • エンコーディングにSJISを指定しても、SJISのファイルは文字化けする(※redmine_importer_orgと同じ挙動)

インポートしてみたCSV:

題名,トラッカー,担当者,開始日,期日,親チケット,対象バージョン
親機能,機能,admin,,,,leovitch
子機能1,機能,admin,2011/4/25,2011/4/27,親機能,leovitch
子機能2,機能,admin,2011/4/28,2011/4/29,親機能,leovitch

akiko-pusu/redmine_importer - GitHub

akiko-push1.png akiko-push2.png

juno/redmine_importer系列。

特徴:

  • 日本語化されている
  • SJISのファイルを文字化けせずに読み込める
  • 「対応させるフィールドの選択」はすべて手動で行わなければならない
  • 子チケットを一括登録する手段は用意されていない

インポートしてみたCSV:

題名,トラッカー,担当者,開始日,期日,対象バージョン
チケット1,機能,admin,2011/4/25,2011/4/27,akiko-pusu
チケット2,機能,admin,2011/4/28,2011/4/29,akiko-pusu

2つのプラグインでインポートしてみた後のチケット一覧:

imported_tickets.png

TortoiseGit rebase

タグ: Git TortoiseGit Windows

TortoiseGit 1.6.5(with msysGit 1.7.4)の使い勝手を調べていたときのお話。

tgit_rebase_1.png

この状態から

tgit_rebase_2.png

piyoブランチをmasterブランチのHEADにrebaseしようとしたら

tgit_rebase_3.png

「add piyo.txt」のコミットが消えた。

rebaseの使い方を誤ったのだろうか?
いずれにせよ、このおかしな歴史は元に戻さなければならない。
shift+コンテクストメニューでReflogを出す。

tgit_rebase_4.png
tgit_rebase_5.png

何か表示がおかしい気がするが……

tgit_rebase_6.png

Refを指定したらすっきりした。

tgit_rebase_7.png

piyo{1}を選び、「add piyo.txt」の頃にresetする。
これで無事、rebaseする前の状態に戻ることができた。

さて、この「rebaseするとコミットが消える」現象。
TortoiseGitのIssuesの方にも「時々起こる問題」として何件か上がっているが、最終的には「Issue 512: Git sync lose local commits (remote update, fetch and rebase)」にて

The issue always occurred on single-core machines, or when manually setup affinity mask of TortoiceProc to one core.

「シングルコアのマシンなら確実に起こる」というコメントと共にパッチが上げられていた。
シングルコアとは、なるほど今時のマシンでは発症しにくそうな不具合である。

では、このパッチを適用したバイナリを入れて再度rebaseしてみよう。

tgit_rebase_8.png
tgit_rebase_9.png

今度は期待通りの歴史になることが確認された。

Bazaarの中央ブランチへのpushをHudsonのビルドトリガにしたい

タグ: Bazaar Hudson
# Subversionのpost-commitフック
REPOS="$1"
REV="$2"

SVNLOOK=/usr/bin/svnlook
CHANGED_DIRS=`$SVNLOOK dirs-changed -r $REV $REPOS`

# trunkにコミットされたらHudosnにビルド要求を出す
if echo $CHANGED_DIRS | grep "^trunk" > /dev/null
then
    wget -q -O /dev/null "http://localhost:8080/job/test/build"
fi

上記はSubversionのフックスクリプトだが、これをBazaarでやりたい。

リポジトリごとにフック置き場が用意されているSubversionとは違い、Bazaarのフックはプラグインの一種として「システム全体のプラグイン置き場」か「個人のプラグイン置き場」に置かなければならない。
それはつまりフックの中で「pushされたブランチの絶対パスを特定しなければならない」ということなので、まずは下記の様なフックを用い、ブランチの位置についてどのような情報を得られるのかを確認しておくことにする。

from bzrlib import branch

def print_branch(param):
    import os
    os.system('echo "%s" >> /var/tmp/branch.txt' % param.branch);

branch.Branch.hooks.install_named_hook('post_change_branch_tip', print_branch, 'print branch')

なお、このフックのトリガは「push」ではなく「tipの変更」である。よってcommitやuncommitでも動作する。
どちらかというとこちらの方が元々の用途にはあっているし、そもそもpushはクライアント側でしかフックできないため、pushされる側に置くことができない。

実行環境:

  • MacOS X 10.6.5
  • Python 2.6.1
  • Bazaar 2.2.0
$ mkdir -p /var/tmp/bzr/local
$ cd  /var/tmp/bzr/local
$ bzr init

まずはこうしてブランチを作って……

$ bzr commit --unchanged
BzrBranch7(file:///private/var/tmp/bzr/local/)

パスを省略したcommitの場合、パスはrealpathになる。

$ bzr commit --unchanged /var/tmp/bzr/local
BzrBranch7(file:///var/tmp/bzr/local/)

絶対パスを指定したcommitの場合、パスは指定した絶対パスになる。

$ bzr push bzr+ssh://idlysphere@localhost/var/tmp/bzr/remote
BzrBranch7(filtered-4319272656:///var/tmp/bzr/remote/)
RemoteBranch(bzr+ssh://idlysphere@localhost/var/tmp/bzr/remote/)

bzr+sshの場合、サーバ側のフック(前者)はプロトコル部がフィルタされた絶対パスになる。

以上のことから考えると、たとえば /var/bzr/central のブランチを監視したい場合は

from bzrlib import branch

def auto_build(param):
    import os
    from urlparse import urlparse
    if os.path.samefile(urlparse(param.branch.base).path, '/var/bzr/central'):
        import urllib
        urllib.urlopen('http://localhost:8080/job/test/build')

branch.Branch.hooks.install_named_hook('post_change_branch_tip', auto_build, 'auto build')

こんな風に書いておけば良さそう?

ClearCaseに別れを告げるために

タグ: ClearCase Subversion

cc2svn 1.0.2
http://code.google.com/p/cc2svn/

ClearCaseで管理されているファイルを、更新履歴やラベル、ブランチ含めてSubversionのダンプファイルに書き出すツール。
使用言語はPython。どのバージョンのPythonを対象に書かれているのか明記されていないが、少なくとも2.6.5では動き、2.3.4では動かないらしい。
試しにPython 1.4で実行してみたが、当然のごとくエラーを返され動作しなかった。

% python
Python 1.4 (Feb 16 1998)  [GCC 2.7.2.3]
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> ^D
% ./cc2svn.py
  File "cc2svn.py", line 216
    yield f.read(lastblock)
          ^
SyntaxError: invalid syntax

というわけでPython 2.7をインストール。
./cc2svn.py -helpくらいは動作することを確認したところで、設定ファイルconfig.pyの編集を開始。

CLEARTOOL = "/usr/atria/bin/cleartool"

cleartoolのパス。

CC_VOB_DIR = "/vobs/MY_VOB_DIR/path/to/root"

Subversionに変更履歴を引き継ぐルートディレクトリ。
ビューの指定も含めて "/view/my_view_tag/vobs/MY_VOB_DIR/path/to/root" と書いても良いが、その場合はcleartool catcscleartool setcsが正しく動作するよう、カレントディレクトリをmy_view_tag以下にする必要がある。

CACHE_DIR = "/var/tmp/cc2svn_cache"

キャッシュ作成先。

PUT_CCLINKS_TO_BRANCH = "main"

シンボリックリンクがどうのこうの。
ClearCaseでシンボリックリンクを使っていないのでよくわからない。

SVN_AUTOPROPS_FILE = THIS_FILE_DIR + "/config.autoprops"

~/.subversion/configのauto-propsと同じ。

CC_LABELS_FILE = THIS_FILE_DIR + "/labels.txt"

Subversionに引き継ぐラベル一覧ファイル。
この行をコメントアウトすると、ルートディレクトリに付けられた全てのラベルを引き継ぐことができる。

CC_BRANCHES_FILE = THIS_FILE_DIR + "/branches.txt"

Subversionに引き継ぐブランチ一覧ファイル。
CC_LABELS_FILE同様、コメントアウトすると全てのブランチを引き継げる。

CHECK_ZEROSIZE_CACHEFILE = True

サイズ0のファイルをキャッシュ内に見つけた時、ClearCaseから再度落としてくるか。

SVN_CREATE_BRANCHES_TAGS_DIRS = False

svndump.txtで/tagsと/branchesの作成も行うか。
Falseにした場合、リポジトリにsvndump.txtをsvnadmin loadする前に/tagsと/branchesを作っておく必要がある。

SVN_DUMP_FILE = "svndump.txt"

生成するSVNダンプファイルの名前。

HISTORY_FILE = "cchistory.txt"

生成するClearCase履歴ファイルの名前。

設定が完了したら./cc2svn.py -runで変換開始。

% ./cc2svn.py -run
2010/09/05 17:58:21: INFO: Loading CC history to /home/idlysphere/cc2svn/cchistory.txt
2010/09/05 17:59:11: INFO: Loading svn auto properties from /home/idlysphere/cc2svn/config.autoprops
2010/09/05 17:59:11: INFO: Processing ClearCase history, creating svn dump /home/idlysphere/cc2svn/svndump.txt
2010/09/05 17:59:12: ERROR: 'ascii' codec can't decode byte 0xbf in position 0: ordinal not in range(128)

ふむ……
ClearCaseの履歴をcchistory.txtに書き出したのち、EUCのコメントをASCIIコーデックでデコードしようとしてエラーになったようだ。
cchistory.txtは一度作られれば次回以降それを使いまわせるので、ひとまず自前で文字コードをEUCからUTF-8に変換し、cc2svn.pyでは素のまま扱うようにする。

197c197
<     return codecs.utf_8_encode(text)[0]
---
>     return text

再び実行開始。

2010/09/05 18:57:34: INFO: Processing ClearCase history, creating svn dump /home/idlysphere/cc2svn/svndump.txt
2010/09/05 19:17:12: INFO: Checking labels
2010/09/05 19:17:12: INFO: Checking LABEL1
2010/09/05 19:17:12: ERROR: Command failed: /usr/atria/bin/cleartool setcs /var/tmp/cc2svn_cache/label_config_spec_tmp_cc2svnpy
Command has non-empty error stream:
cleartool: Error: Operation stat, .: ファイルもディレクトリもありません。
cleartool: Warning: New config spec makes current working dir invisible.

「警告: 新しいconfig specは現在の作業ディレクトリを見えなくします」、か。
どれどれ……

% cleartool catcs
element * LABEL1

なるほど。config specを「LABEL1」だけにされては、上位ディレクトリpathやtoに「LABEL1」ラベルを付けていない /vobs/MY_VOB_DIR/path/to/root は見えなくなってしまう。
となると、多少大雑把ではあるが、ディレクトリについては全て可視にすることで対応してしまうのがいいか。

811c811
<                 file.write("element * " + label + "\n")
---
>                 file.write("element * " + label + "\n" + "element -directory * /main/LATEST\n")

三度実行。

2010/09/05 19:29:01: INFO: Processing ClearCase history, creating svn dump /home/idlysphere/cc2svn/svndump.txt
2010/09/05 19:49:17: INFO: Checking labels
2010/09/05 19:49:17: INFO: Checking LABEL1
2010/09/05 19:49:19: INFO: Checking LABEL2
……(略)……
2010/09/05 19:51:14: INFO: Completed

終わった\(^o^)/
こうして8083行のcchistory.txtから書きだされたsvndump.txtは、リビジョン数8033、サイズ約37MB(7z圧縮して約800KB)。それをsvnadmin loadしたSubversionリポジトリのサイズは、svnadmin packして100MB。
うーん……アトミックコミットではないから仕方ないとはいえ、変更量の割には巨大なリポジトリになってしまった。

ちなみに、試しにこのリポジトリをBazaarの2aリポジトリに変換してみたところ、obsolete_packsを除いたリポジトリのサイズは2MB程度に収まった。groupcompressの効果だろうか、Subversionと比べて大分小さい。
ただし、残念なことにこの流れ(ClearCase→Subversion→Bazaar)ではラベル(タグ)の引き継ぎがうまくいかない。cc2svnによって作成されたタグは「任意のリビジョンの別名」の体裁を取っていないため、

% bzr tags
LABEL1   ?
LABEL2   ?

このようにタグとリビジョンが紐付かなくなってしまう。

Appendix

タグ

Blog内検索