従来型patchからソース配付版への移行

tritonn-1.0.2.mysql-5.0.41.senna-1.0.5からmysql-5.0.41.senna.diffを入手。
mysql-5.0.41.tar.gzを展開。cdしておく。
patch -p1 < mysql-5.0.41.senna.diffを実行。特に問題なくあたるはず。
従来通り、autotools、touchを実行してからconfigure、makeを実行する。
make distを実行。新しいmysql-5.0.41.tar.gzができる。
本家のmysql-5.0.41.tar.gzと新しいmysql-5.0.41.tar.gzを同一ディレクトリに展開。新しい方は名前に.sennaをつけておく。
diff -urdp mysql-5.0.41 mysql-5.0.41.senna を実行。-Nは付けない。mysql-5.0.41.senna-new.diffとでもしておく。→新型パッチの成果物。
再度、本家のmysql-5.0.41.tar.gzをどこかに展開、cdしておく。
patch -p1 < mysql-5.0.41.senna-new.diffを実行。問題無くパッチがあたる〜^^。
autotools/touchは不要。いきなりconfigure、makeを実行。
make test-full-qaを実行。独自テストスイートを実行。
make distを実行。→ソース配付版ができあがり
make bin-distを実行。→あれれ、バイナリ配付版もできあがり？？

MySQLオリジナルソース配付版を入手。Tritonnソース配付版を入手。
オリジナルソース配付版を展開する。mysql-5.0.41みたいなディレクトリ。シンボリックリンクorigを付与。
Tritonnソースディレクトリを展開。mysql-5.0.41.sennaみたいなディレクトリ。シンボリックリンクsaveを付与。
再度Tritonnソースディレクトリを展開。mysql-5.0.41.senna.devみたいなディレクトリ。シンボリックリンクdevを付与。
newを使って改造。バグ修正とか新しい機能の実装とか。
改造が終わったらその場でmake test-full-qaと独自テストスイートを実施。問題があれば１つ戻る。
必要に応じてmake bin-distを実行、性能評価を実施。問題があれば2つ戻る。
newにてmake distを実行。
新しくできたtar.gzを展開してmysql-5.0.41.senna.newとし、シンボリックリンクnewを付与。
diff -urdp save newを実行。diffをsourceforge.jpの該当タスクのところにuploadする。レポジトリの次期リリース用個別patch置き場に置いておく。

MySQLオリジナルソース配付版の新旧を入手。Tritonnソース配付版(旧)を入手。
オリジナル(旧)とTritonn(旧)のdiffを取ってpatchを作成する。
オリジナル(新)にpatchをあてる。configure/Makefile/lex.h/sql_yacc.ccなどの自動生成されるファイルへのHunk/Failedは無視。それ以外のファイルへのHunk/Failedは手動で修正する。
autotools/touch/configure/makeを実行。コンパイルエラーが出たら１つ戻る。
make test-full-qaと独自テストスイートを実行。問題があれば２つ戻る。
make distを実行。
生成されたtarballを一度解凍し、ディレクトリ名をmysql-5.0.XXからmysql-5.0.XX.sennaに変更して再度tarball化。

こうしてみると、独自テストスイートを"make test-full-qa"に相乗りできるようにすれば自動化が楽になりそうな雰囲気。

あと、subversion等のソースコード管理ツールはいまは使っていない^^ パッチが主体だったからとかmakeした後の環境でsvn commitするとエラーになるとかそんな理由があって。でもmake distを使えばsubversionへの移行もできるようになるかな？

あー、なんかすごくsubversionにいける気がしてきた！ついでにやっちまうかぁ。上記手順考えたけど、移行したら意味なしw　まあいいや。