プログラマの思索

かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。

【元ネタ】
Subversion のフォルダ構成 - かおるんダイアリー

Subversionのフォルダ構成 | Ryuzee.com

Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所

InfoQ: 複数のアジャイルチームでのバージョン管理

【問題】
SVN直下のディレクトリは、branch/tag/trunkになっている。
ソースやドキュメントはどこに配置すべきか？

【結論】
管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag　を作った方がブランチを管理しやすいと思っていた。
最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。

でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。
思い出してみたら、下記の方法で僕も運用していた。

root.
├─branches
│ ├─1.0
│ │ └─src
│
├─tags
│ ├─1.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│ ├─1.1
│ │ └─src
│ ├─2.0
│ │ ├─doc
│ │ ├─src
│ │ └─tools
│
├─trunk
│ ├─doc
│ ├─src
│ └─tools

基本的な考え方は「InfoQ: 複数のアジャイルチームでのバージョン管理」に従えばいい。

【方針】
１・基本は、trunkにソースやドキュメント、ツールなどのフォルダを作り、それぞれを管理する。
PGやPLは、ソース修正やドキュメント修正は、trunkへコミットして、常に最新の状態にする。

２・新規開発中のtrunkからリリースする場合、trunkからtagを作り、tagにはリリースするバージョン(例：1.0, 2.0)を命名する。
この時、ソースだけでなくドキュメントもtagのバージョンに入れる。

更に、trunkからbranchにリリースバージョン(例：1.0, 2.0)を作り、本番運用中のソースは別管理とする。
ドキュメントは最新版だけあればよいプロジェクトだったから、branchには入れない。

３・本番運用中のbranchからリリースする場合、branchからtagを作り、tagにはリリースするバージョン(例：1.1)を命名する。

【注意点】
一つは、基本は、tagにはtrunkにある全ディレクトリにバージョンを付けること。
理由は、tagのバージョンがtrunkのスナップショットだから。
実際、リリース時はソースだけでなくドキュメントも一括納品しているからだ。

もう一つは、branchには派生開発する対象のディレクトリをtrunkから分岐させること。
このやり方はいわゆるメインラインモデル。
trunkは新規開発、branchは本番運用に分けて管理する手法。
僕の場合、ドキュメントは最新版だけあればよかったからbranchに入れないが、SWプロダクトラインのように製品ファミリー単位でドキュメントも管理する必要がある場合、branchに入れた方がいいかもしれない。

branchを作ると、必ずbranch→trunkへマージ作業が発生する。
ソースというテキストファイルなら作業しやすいが、ExcelやWordは正直作業しづらい。
但し、TortoiseSVNならOfficeの差分比較ができるので、マージ作業の難易度は下がっている。

つまり、trunkに成果物を全て配置するやり方がよいと思う。
その理由は、「Subversionのフォルダ構成 | Ryuzee.com」で詳しく書かれている。

実際、trunk/tag/branchに含まれないフォルダは、最新版なのか古いのか分からないからだ。

「Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所」の記事も読み合わせると、ドキュメントもソースと同じライフサイクルで管理した方が良いと思う。
理由は、ドキュメントをリリースするタイミングはソースをリリースするタイミングと同じだからだ。
普通は、システム納品と同時にマニュアルや設計書というドキュメントも納品しているはずだ。
つまり、trunk直下にドキュメントとソースを配置した方がライフサイクルを管理しやすい。

SVNだけでなく他のバージョン管理でも同様の発想をすればいいだろうと思う。