『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

Redmine実践ガイドの５章の終わりに「Tracユーザーから見たRedmine」というコラムを書きました。先日のRxTstudyに参加して、Redmineのチケット番号の一意性の優位点について書き忘れている事に気付きました。

具体的には、あきぴーさんの発表のスライドの「PJ分割ルールの効果」のところで、

第15回RxTstudy 『大規模組織や 多様な業務における Redmineの課題』 from akipii Oga

「そんなの、1プロジェクトにバージョン管理ツールの1リポジトリがあたりまえじゃん！」（なぜか浜っ子風）と、思った時に気付きました。

Tracは1プロジェクトに1リポジトリが基本です。複数プロジェクトでリポジトリを共有する際は、リポジトリからTracへの参照にプトジェクトを示すプレフィックスが必要になります。

でも、Redmineではそんなのお構いなしで、一つのリポジトリを、親子であろうと無かろうと、複数のプロジェクトから参照できます。

このような違いが出るのは、Tracのチケット番号がプロジェクト毎に0から始まるのに対して、Redmineのチケット番号は全てのプロジェクトで通し番号になっているからです。常にチケット番号が一意に決まるので、リポジトリからの参照にプロジェクトのプレフィックスが不要になります。

機能的には同じですしツールを使っているなら大きな違いはありません。でも、Tracの場合はあらかじめプレフィックッスを付けて運用を始めないといけないので、同じプロジェクトでずっと運用する事になりがちです。

一方、Redmineの場合はとりあえず始めておくことができます。そして、予算等の管理単位や派生開発等で構成メンバーが異なるなど、1つのプロジェクトでやりにくくなった場合に別のプロジェクトや子プロジェクトに分ける事ができます。

Redmineはチケット番号が通し番号なので、見ていないチケットがあるかどうかがわかりにくいという面もありますが、プロジェクトが長期にわたったり、大きくなると有利な面があるのですね。

追記：

このような理解ができて、ようやく赤羽根さんが努力されている価値がわかりました。Redmineを複数立てない事がRedmineの活用につながると思います。

Redmineチューニングの実際と限界 - Redmine performance tuning from Kuniharu AKAHANE