akky’s log

検索エンジンから来られた方と未来の自分へmantisからtracへのデータ移行を行った記録を記す。移行に使うmantis2trac.pyを編集していますが、pythonは今回が初めてなので適切ではない変更を行っている可能性があります。また、ここの内容を実行する際には自己責任でお願いします。データの破壊等が発生しても当方では補償しかねます。

環境

OS

CentOS 4.4

uname -a

Linux locahost.localdomain 2.6.9-42.ELsmp

mysql

5.0.37をソースからコンパイル

sqlite

sqlite-3.3.3-1.2、python-sqlite-1.1.7-1.2をprmからインストール

mantis2trac.3.pyを入手

# wget http://trac.edgewall.org/attachment/wiki/TracImport/mantis2trac.3.py?format=raw
# mv mantis2trac.3.py?format=raw mantis2trac.3.py

mantis2trac.3.pyでデフォルトエンコードの指定

266行目付近の

sys.setdefaultencoding('latin1')

を

sys.setdefaultencoding('utf8')

に変更。mantisが使うMySQLのDB、OS、tracが使うsqliteのDBの全てをUTF-8に統一していても移行後のtracで文字化けが発生する。tracにINSERTする各所で文字列に対しては「value.encode(’utf-8′)」
をしているのが原因。当初は文字化けに対してtracへ実行しているSQL文をデバックライトで画面に表示させそれをスクリプトファイルに編集していたが、作業が破綻してしまったし、繰り返しの作業が面倒になってきた。

LAST_INSERT_IDの取得を無効

392行目近辺の

        c.execute('''SELECT LAST_INSERT_ID()''')
        eturn c.fetchall()[0][0]
        eturn self.db().db.sqlite_last_insert_rowid()

をコメントアウト。LAST_INSERT_IDが無いと言われるが。
changelogに

Changes since version 1.1:
  - Made it work against Trac running on MySQL (specifically, changes to the
    LAST_INSERT_ID() call on line 382 (in the addTicket function))

という記述があり大事そうだけどないものは無い。

カスタム項目の移行

カスタム項目に相当する列はticketテーブルにないので実行時に

 * ERROR: unable to add ticket(#114) change "発生要因": "" -> "詳細設計不備" (2007-05-31 19:58:04)
          The bug id, field name, and time must be unique

とエラーになる。ticket_customテーブルに値を設定すればよい。
trac.iniで

[ticket-custom]
factor = select
factor.label = 発生要因
factor.options = 仕様変更|仕様不明確|仕様誤認|機能設計不備|詳細設計不備|コーディング不備|データ誤り|既存機能理解不足

と設定していれば、上のエラーメッセージからSQL文をエディタで編集して

INSERT INTO ticket_custom values (114,'factor','詳細設計不備');

とする。これをsqliteのコマンドラインインターフェイスから実行

添付ファイル

mantis2trac.3.pyが移行してくれる。

mantisのデータ整理

mantisに登録した件名がDBの列長を超えていると、有無を言わさず超えている部分をカットされてしまう。マルチバイトの途中でもお構いなし（ちょほほ）。mantisで見ると件名の末尾が文字化けしているデータは移行したtracでUTF-8への変換に失敗すると仰られ表示できなかった。mantisでフィルタを外して1件ずつ手直し。

mantis2trac.3.pyを実行

MySQLでのmantisのDBユーザ

bugtracker

MySQLでのmantisのDBユーザのパスワード

btspass

tracのプロジェクトの位置

/usr/local/trac/prj1/

とした場合に

./mantis2trac.3.py --db bugtracker -u btsuser -p btspass --tracenv /usr/local/trac/prj1/

と実行する

先日インストールしたtracだけど、データ移行をして使い方を考えた結果mantisに戻ることにしました。

mantisと比較して

trac よいと思ったこと
　roadmapがある
　Subversionのリポジトリビューアが変更管理を前提に考えられている
　wikiが一体化している
　Subversionとのアカウントを統合できる
　RSSで障害の状態を見れる

trac よくないと思ったこと
　サブプロジェクトを作れない
　新しいwiki文法か・・・
　pythonは使ったことないです
　ワークフローとして使えない（未検証）

当初はmantisからtracへの移行を考えていたのだけど、実務での基準になる一セットのプログラムを案件毎にカスタマイズすることを考えるとサブプロジェクトが無いため運用が破綻すると思い移行を断念。代替方法を考えてみたのだけども一つのリポジトリに対してBTSが複数になってしまうとどこかで辻褄が合わなくなりそう。特にリポジトリのフックスクリプトを使いBTSと連携する機能を作りこんでいってもどこかで無理がでそう。
また、mantisの開発版（1.1.0a3)ではtracにはあったロードマップとwiki及びRSSが実装されているのでtracに移行する必要もないのかなと思わせる。問題はこれらの機能が安定版にマージされる日を知らないということ。それまではロードマップはカスタムフィールドで代替。

バグ管理にmantisを使っていたのだけど、いろんなメモも残すべくwikiを探している過程でtracに乗り換える事を決める。tracの存在は知っていたのだけど、pythonという未知の言語だったために敬遠。

今回tracにすることにした大きな要因はバグ管理、ソース管理、ナレッジを一つで実現できること。別々のアプリを立ち上げても良いのだが、管理メンドくさっ。となるのを避けたいのとそれぞれのコンテンツをリンクしておきたいということもある。例えば、ソース管理をSubversionで行いバグ管理をmantisで行っている中でバグ対応の差分を見たいときに、mantisに残しているリビジョンを控えておきsubversionを覗きにいっているのをワンアクションで実現できるということ。

また、マイルストーンがあるのも惹かれた。mantisでもたせられるバージョン番号はSubversionのタグ名と同じ値にしているために、修正が終ったがタグを貼っていない障害へのバージョン番号を振りにくいというものがあった。そこは、マイルストーンで上手くやって行けるのかなという淡い期待がある。また、マイルストーンで進捗を見れるものプラスポイント。

今回はお試し環境だったので、改めて環境を作り直し。そのときには手順を残したい。

参考にした主なサイト
　http://tech.feedforce.jp/trac_1.html
　http://discypus.jp/wiki/?%A5%BD%A5%D5%A5%C8%2FBug%20Tracking