tracのpre/post-commit

dev

前にまとめた気がしたけど。id:ladybug:20100607だな。
pre-commitは、

  • コミットコメントには refs #999 または fixed #999 を含める必要がある。（変更はtracに登録してから）
  • 指定されたチケット番号が有効でopenであること。
  • コミット先が
    • /trunk/ で始まる場合、チケット属性targetがnullであること。（ブランチ用のチケットでトランクを変更できない）
    • /branches/NAME/ で始まる場合、チケット属性targetがNAMEであること。（ブランチ用の変更は該当のブランチへのみ）
    • /tags/NAME/ の場合、トランザクションの変更リストがAまたはDの一行であること。（タグの作成と削除のみ許可）
    • /devs/NAME/ で始まらない場合、コミットできない。（NAMEは任意）
  • svn:mime-typeにencodingが含まれる場合、記載されたエンコードであること。
  • svn:eol-styleが有効な場合、改行コードが正しいこと。（Windowsばっかりなのでかなり強引な実装）

post-commitでは、

  • コミットログを指定のチケットへコメントとして貼り付ける。
  • fixed #999 の場合、カスタム属性のprogressを100にする。
  • refs #999 の場合、続けて 99% が記載されていれば、カスタム属性のprogressを記載の値にする。（記載が無いときは何もしない）
  • fixed #999 の場合、チケットアクションresolve(fixed)を実行する。
  • refs #999 の場合、statusがacceptedでは無い場合、チケットアクションacceptを実行する。

覚えてないのが、もうちょっとあるはずだ…。
リリース時には、レポート機能で対象のtargetやversionでチケットを取得し、変更一覧として保存する。そこからExcelのVBAとtracのXMLRPC機能を使いまして、コミット時にコメントに記録されたチェンジセット番号を収集してチケット毎の変更ファイル一覧作ったり、コメントやカスタム属性で記録された出荷情報を拾い上げたりします。
たとえば、カスタム属性で『エンドユーザに影響のある変更か？』を保持していて、販売店にバージョンアップの案内や変更点の説明文書に自動的に必要な定形ドキュメントを挿入したりですね。
もうちょっと色々とやりたいところですが、当面はこんなかんじで運用していますね。実際は直販ユーザとかもいるので、そっちの管理がいまいちうまくいってないところがあったりします。