Subversion実践入門 - Mike Mason

Subversion実践入門:達人プログラマに学ぶバージョン管理(第2版)

★★★★☆
subversion での開発を行う場合は事前に読んでおきたい一冊。仕事では cvs を使っているんだけど、前々からモヤモヤしてたものがスッキリするかなと思って購入したんだけど・・・・しなかった。

リリースする時はブランチ？

cvs みたいに資源ごとにリビジョン管理・タグ付けができる場合は、リリースの際に対象資源に対してタグを付けるなり移動するなりすればいいんだけど、全体でリビジョンが振られる場合はリリースブランチを作ることになるで OK なのかな？

資源管理が二重にならない？

リリースしたものに障害があった場合はリリースブランチで修正して修正内容を trunk にマージし、その後に機能追加版のリリースをする場合は trunk からまたリリースブランチを作る？既存のリリースブランチにマージする？資源管理が二重、三重になっちゃいそうな気がするんだけど、コミット単位にリポジトリが管理されるから trunk の内容をマージするのもコマンドで一発で OK だから楽ちんだよ〜なのかな？

ブランチが沢山できない？

1 ユーザに対してシステムをつくる場合はいいんだけど、パッケージとして多ユーザ向けに機能追加と障害修正を含めてリリースしたい場合はユーザ名と日付とかでブランチを切りまくるしかないのかな。んで、それぞれのブランチに対して機能追加や障害修正を当てていくしかないんだろうか。cvs だと資源ごとにバージョン管理してタグ付けできるから、ブランチ切らないでもタグを移動させれば済む(どれを移動させるのかの管理が面倒なのは置いといて)。

開発中はどうする？

開発中でまだリリースしたくない場合でもリリースブランチ切られちゃったら含まれちゃうよねぇ。タグだったらつけなきゃいいんだけど。開発用ブランチを作るのもいいんだけど、trunk に追加された機能が必要になった場合はどうするんだろ。自分専用ブランチを作って好き勝手やればいいのか。そうすると開発者 × 新機能分のブランチが乱立しちゃったりするのかなぁ・・・分からん。

で、イケてるの？

git だったらチームとか機能単位にローカルリポジトリで管理しながら動作確認して、テスト OK になったらリリース用リポジトリに push して OK になって便利なのかなぁ。その場合は個人ローカルリポジトリが乱立するだけだからいいのかなぁ。
実際運用に立ち会わないと分からないかなぁ・・・。subversion の方が優れてるんだけどケースバイケースになっちゃうのかなぁ。どういう運用でいくかだよね。