革命的Subversionリポジトリ構成
2008年 03月 15日
Subversion本家推奨の構成って、どうも馴染めないのです。
プロジェクト単位で完全に独立しているならともかく、現実はそーじゃないんで。
何が問題なのかっつーと、プロジェクトが第1階層にあるから機能面での構成が
プロジェクト単位で分断されちゃってる。例えば、trunkから全プロジェクトを持って
きたいなんてときにいちいちプロジェクト毎にチェックアウトしなきゃならんのですよ。
プロジェクトのcheckoutという観点ではtagsもbranchesも要らないかんね。
ぶっちゃけ、邪魔。
やっぱ、こゆのは機能面で最適であるべきだと思うのです。
そんなわけで、俺的に最適な構成を考えてみた。
Subversion等のバージョン管理システムを使った開発というのは、リリース版,開発版,
開発メンバローカル版といった状態を管理する他に、バックアップという目的もある。
バックアップ目的なら、できるだけ頻繁にcommitかけることが好ましい。が、trunkに
対してそれやると不安定な開発版が出来上がるわけで、複数人で開発しているとき
には物凄く傍迷惑なことになる。
経験してみればわかるけど、まともに作業できないよ、これ。
かといって、安定するまでcommitを控えているとバックアップの効果が薄れるし、
更新ログも不正確になりがち。
このトレードオフを両立させるため、privというのを作った。開発メンバは各自trunk
からユーザディレクトリにブランチを作り、そこで作業する。ここなら、不安定な状態でも
他のメンバに迷惑かけないから、頻繁にcommitかけておっけ。で、安定したところで
trunkに合流してやればよい。他にも、これで個人的なメモなんかのヴァージョン管理も
できるようになるですよ。
また、カテゴリ分けなんかでツリー状の構造にすることもできるようになっている。
例えば、webページなんかで担当のディレクトリだけcheckoutとか。
従来の構成でこれやると、ディレクトリ単位でcheckoutしても余計な階層が含まれて
構造が維持できないかんね。
blanchesがないのは、機能面での構成上blanchesという集合に全く意味がないから。
プロジェクトのブランチを作るという行動には、必ずそれを他のプロジェクトに含めるか、
半独立したプロジェクトとして扱うという意味が籠められている。だとすれば、当然
それは対象となるプロジェクトとして扱うべき。前者なら含有する親プロジェクトの中に、
後者ならtrunkの直下にブランチを作る形となるわけで、専用のディレクトリは無用。
あとは、試しに使ってみてくださいまし。
使い勝手が違うですよ。超おすすめ。
プロジェクト単位で完全に独立しているならともかく、現実はそーじゃないんで。
何が問題なのかっつーと、プロジェクトが第1階層にあるから機能面での構成が
プロジェクト単位で分断されちゃってる。例えば、trunkから全プロジェクトを持って
きたいなんてときにいちいちプロジェクト毎にチェックアウトしなきゃならんのですよ。
プロジェクトのcheckoutという観点ではtagsもbranchesも要らないかんね。
ぶっちゃけ、邪魔。
やっぱ、こゆのは機能面で最適であるべきだと思うのです。
そんなわけで、俺的に最適な構成を考えてみた。
- trunk (開発中最新ヴァージョン)
- Project1
- Project2
- :
- Category1
- Project11
- Project12
- :
- Category2
- :
- tags (リリース履歴)
- Project1
- Version1
- Version2
- :
- Project2
- :
- Category1
- Category2
- :
- Project1
- priv (開発メンバ個別)
- User1
- Project1
- Project2
- :
- Other1
- Other2
- :
- User2
- :
- User1
Subversion等のバージョン管理システムを使った開発というのは、リリース版,開発版,
開発メンバローカル版といった状態を管理する他に、バックアップという目的もある。
バックアップ目的なら、できるだけ頻繁にcommitかけることが好ましい。が、trunkに
対してそれやると不安定な開発版が出来上がるわけで、複数人で開発しているとき
には物凄く傍迷惑なことになる。
経験してみればわかるけど、まともに作業できないよ、これ。
かといって、安定するまでcommitを控えているとバックアップの効果が薄れるし、
更新ログも不正確になりがち。
このトレードオフを両立させるため、privというのを作った。開発メンバは各自trunk
からユーザディレクトリにブランチを作り、そこで作業する。ここなら、不安定な状態でも
他のメンバに迷惑かけないから、頻繁にcommitかけておっけ。で、安定したところで
trunkに合流してやればよい。他にも、これで個人的なメモなんかのヴァージョン管理も
できるようになるですよ。
また、カテゴリ分けなんかでツリー状の構造にすることもできるようになっている。
例えば、webページなんかで担当のディレクトリだけcheckoutとか。
従来の構成でこれやると、ディレクトリ単位でcheckoutしても余計な階層が含まれて
構造が維持できないかんね。
blanchesがないのは、機能面での構成上blanchesという集合に全く意味がないから。
プロジェクトのブランチを作るという行動には、必ずそれを他のプロジェクトに含めるか、
半独立したプロジェクトとして扱うという意味が籠められている。だとすれば、当然
それは対象となるプロジェクトとして扱うべき。前者なら含有する親プロジェクトの中に、
後者ならtrunkの直下にブランチを作る形となるわけで、専用のディレクトリは無用。
あとは、試しに使ってみてくださいまし。
使い勝手が違うですよ。超おすすめ。
by denullpo
| 2008-03-15 07:00
| こっち関係