Subversionでのソース管理

Subversion

会社で今のSubversionでのソース管理を見直すべくシステムを再構築することになった関係でSubversionを調査することになった。
ほとんどSubversionというものを知らないところからある程度知識がついたと思うので忘れないようにメモ。

Subversionで頻繁に使うことになるコマンド

まぁほとんどGUI(TortoiseSVN)で操作するわけだけど、よく使うコマンドは以下。

  • checkout
  • commit
  • add
  • update

コマンド意識して使うのはここら。あとは merge, diff もよく使うコマンドだ。

運用方法

まずSubversionでは慣習として

  • trunk
  • branch
  • tag

という3つのリポジトリを作る。これらはバージョンを管理するためのディレクトリ（と言ってしまおう）だ。特に理由がない限りはこの3つを使い分ける。それぞれの意味はこんな感じだ。

  • trunk - 現在のバージョンを管理
  • branch - 次のバージョンやバグ処理など、trunkから修正・追加を行う
  • tag - branchの修正が終わるなどしてリリースできる状態になった時点のスナップショット

幹(trunk)から枝(branch)を派生させていき、最終的に枝分かれしたものは幹へマージさせる。そしてマージ時点のスナップショット(tag)を取る。
これはhttp://pinoki.la.coocan.jp/wiki/?Subversion%2F%B1%BF%CD%D1%CA%FD%CB%A1にある図がかなり分かりやすかった。ここで示されてるtrunk, branch, tagの使い方に沿うのがいいかなと思う。

Webサイトをを管理してると小さなバグの修正とかは頻繁にある。その度にbranchを切って作業し、修正作業が完了したらtrunkへマージしてリリース。規模の小さいサイトならサービス全体を単位としてバージョン管理すればいい。規模が大きくなるとサーバー側とクライアント側のソースを分ける必要がある。
その場合に考えないといけないのがバージョン管理してるソースをどうやって実稼働サーバーにデプロイしていくかという問題。
常にtrunkにあるソースをデプロイするようにすればいいのか、branchを見るようにしたらいいのか。
最終的な公開サーバーにデプロイするときはtrunkのソースをデプロイでいいだろうね。その時点をtagとして切って使うようにしたほうがいいかもしれないけど。でもテストをするとき、trunkってのは常に最新であるわけじゃないからbranchのソースを使うようにするといい。

  • ソースの修正作業が必要になったらまずtrunkからbranchを切る。
  • branchで修正作業。ソースをいじるときは常にbranch。
  • 修正が済んだらbranchのソースをテスト。テスト。テスト。
  • テストが済んでリリースできるようになったらtrunkへマージ。
  • trunkからリリースバージョンとしてtagを切る。
  • tagをリアルサーバーへデプロイ。

こんな順序がいいのかな。たぶん今作ってるシステムはtagは使わないんだけど。個人的には使いたいんだけどまぁちょっと無理そうだからそれは次回かなぁ…。
いやでも2年以内くらいに使うようにしよう。そうじゃないとバージョン管理してる意味があまりない。ロールバックが発生するたびにあたふたする羽目になる。

Subversionでのソース管理は今までバージョン管理をしたことがなかった僕にとって結構面白い。
Subversionが主流になる前はCVSってのがあったみたいだけど何が違うんだろなー。
今はGitってのもあるけど、会社でもそっち使うようにならないかなー。（Subversionでの管理考えながら）

まだまだ調べることはたくさんありそうだ。