SubversionとTracを使って，バージョン管理をしようと思います。
truk,branches,tagsの扱い方がわからなかったりするので・・・
trunk,branches,tagsについて 
trunk,branches,tagsの役割
| trunk | 主となるドキュメントやプログラムを管理するリポジトリ。このリポジトリから直接リリースすることはしない。ここでの作業はbranchesには影響しない。 |
| branches | リリース用のパッケージ。trunkからA.B.Xと採番して分岐を作り，リリースパッケージ開発＆バグFIX用のリポジトリとする。branchesで行った修正は，まとめてtrunkにマージすることによって，trunkに反映させられる。trunkと違って，一度切られたbranchesは不具合などが出るまでは変更がないようにする必要がある。 |
| tags | branchsで実リリースを行ったときのリビジョンのスナップショット。目印や区切りを付けるために使用する，いわゆるベースラインのこと。リリース直後の一通りのソースが取得できるようにしておいて，その後の修正で何かあった場合そこまですぐに戻せたりすることがきるるので便利に活用できる。 |
リリースの手順とtrunk,branches,tagsの分岐の関係
リリースするときに，最新のtrunkから「X.Y.Z」というリリース用のブランチを作成する。
そのブランチを安定させた時点で「X.Y.0」とタグをつけて本番リリースする。
非安定版の場合は，「X.Y.0-alphaM」，「X.Y.0-betaN」，「X.Y.0-rcL」などとリリース番号にα版，β版，rc版であることを明記するようにする。
下図は，リリース用の「1.0.X」ブランチを作成し，リリースする毎に「1.0.0」，「1.0.1」，「1.0.2」などと，バージョンを採番してタグを作成している。
branchesを作成するときの注意点
必ずtrunkから分岐させる
メインラインとなるtrunkは最新開発用ブランチという役割を保つために，分岐は必ずtrunkから行うことにする。
branchesから分岐させて孫のbranches，ひ孫のbranchesをさせてしまうと，trunkへのマージ作業が複雑化し，わけがわからなくなる。
trunkは正しくビルドできる状態で保つ
開発者は，メインライン（trunk）に対して作業を行う。コミット時にコンパイルエラーが起きないようにする。
branchesの変更は，即効でメインライン(trunk)に反映させる
branchesに対するメンテナンス期間が長いほど，trunkへのマージ作業が増大し，マージ作業が困難となる。ブランチを作成して分岐した場合，その変更内容をすばやくメインラインに戻すように心がける。
リリース番号の付け方
リリース番号のつけ方を以下のようにする。
Apacheで使っている方法で，命名規則は下記のようにする。
MAJOR.MINOR.PATCH
例えば，「2.0.6」なら，「メジャーバージョン2，マイナーバージョン0，パッチバージョン6」となる。
どの階層で番号を増やすかは，下記のレベルで決める。
| PATCH | バグフィックスのような，絶対にコードを壊さない変更の場合 |
| MINOR | 新しくAPIが追加される場合（APIの削除はなし） |
| MAJOR | APIを完全にリニューアルする場合 |
番号の増やし方は以下の通り
PATCH
1.0.2⇒1.0.3のように同じMAJOR,MINOR系列でPATCHの番号を1つ増やす
MINOR
1.0.3⇒1.1.0のように同じMAJOR系列でMINORの番号を1つ増やす。PATCH番号はリセットする。
MAJOR
1.1.0⇒2.0.0のようにMAJORの番号を1つ増やす。MINOR,PATCH番号はリセットする
TracのBTSとSubversionの版管理を仲良くするためには。。。
Tracにはチケット発行管理とマイルストーン管理がある。Subversionにはtrunk,tags,branchesの管理がある。この2システムをうまく対応させたい。
チケット
チケットは作業ごとに分類して発行すればよい。
作業分類は主に以下のとおり
仕様FIX
開発するプロジェクトの仕様をFIXするタスク
仕様変更
仕様FIXしたんだけど、ユーザの気が変って仕様が変わったときの改修作業
機能追加
仕様FIXしたんだけど、ユーザに欲が出てきて、機能を追加することになった開発作業
リリース
本番へのリリース作業
バグ対応
名前の通り，バグが発生したときに発行するチケット。チケットを発行したら，コメントに暫定対応したものとかコードの修正とかを記録する。
サーバ障害
サーバ障害が発生したときに，発行するチケット。どんな対応をして対応したかををコメントに記述する
サーバ設定作業
アプリケーションを動かすのに必要な，サーバの設定。新規に導入したサーバをデータセンターに設置するとか，OSをUPDATEするとか，pluginをインストールするとか。
調査
アプリケーションを動かすのに必要なミドルウェア，サーバのスペックの調査など。
Tracでは，チケットタイプはデフォルトでは英語名だが，日本語名で管理できる。TracにAdminプラグインを追加するとGUIで管理できる。
チケットの状態遷移
チケットの寿命は主に５つの状態がある。
１．チケット発行
プロジェクトに関して，作業が発生したときにチケットを発行する。
２．作業者割り当て
作業をする担当者を決定。PMOみたいな任命奉行がいなければ自己申告で決定。
３．作業着手
今，その作業を手につけているのか。作業をしているなその作業状況をコメントに記述する。
４．チケットクローズ
作業が終了したらCLOSEする。そのチケットがコーディング作業ならば，Subversionでコミットしたリビジョンを記入する。
そのほうが，チケットとリビジョンの関連付けができる。
チケット1枚に対し，どのような改修が発生したか，Tracのリポジトリブラウザで
改修履歴を追うことができるし，改修に要したボリューム，工数を調べることができる。
５．クローズしたチケットの差し戻し
クローズしたチケットについて，再度対応しなければならないときに差し戻しをする。
FIXしたはずバグが再発したときの場合など。
ロードマップ
ロードマップの位置づけ
- ロードマップはプロジェクトの将来の開発計画と管理に役立つ。
- ロードマップはチームの所信表明演説みたいなものである。
ロードマップを実現するためには
- ロードマップはマイルストーンというで作業単位に分割してスケジュール管理する。
- マイルストーンにチケットを紐付ける。
- 紐付けると，マイルストーンを実現するためにどんな作業が必要か把握できるし，
- 全チケットのうち，チケットを消化した進み具合で，何％まで進捗が進んだのかも把握できる。
マイルストーン
- チケットはマイルストーン毎に集約させる。そうするとマイルストーンの進捗度合いがチケットのCLOSE数により，何％まで進んだか視覚的に把握できる。
- マイルストーンの名前は「プロジェクト名-A.B.X」といった命名規則にするとわかりやすい。
- マイルストーンは，アプリケーションのリリースのたびに作成すると便利。ただし，イルストーンの作成タイミングは，MINORバージョンのUPのたびに発行する。PATCHレベルの粒度では新規にマイルストーンを発行しない。
tagBranchTrunk.png
新しくコメントをつける