開発​/バージョン管理システム​/Subversion

Subversion

Subversionは，バージョン管理システムとして広く利用されているCVSの管理スタイルを踏襲しつつ，CVSの欠点を解決したバージョン管理システムだそうだ。

Subversionはじめ

• リポジトリ(サーバー)からファイルを手元に取り出すことをcheckoutと言う。
• 手元にcheckoutしたファイルを作業コピーと呼ぶ。
• 作業コピーに加えた変更をリポジトリに反映することを，コミット(commit)と言う。
  • コミットしたファイルは，いつでも過去にコミットした時の状態で取り出すことが出来ます。バージョン管理と言われる由縁。
  • コミットすると，その時のバージョンを指す番号(リビジョン)が付く。
• 作業コピーにリポジトリのファイルの内容を反映することを更新（update）と言う。
  • 作業コピーをcheckoutしてからリポジトリに変更がコミットされたかも知れない。作業コピーをリポジトリの最新の状態に更新 (update)するのが重要。
  • 作業コピーに変更を加えられていた場合，リポジトリにコミットされている変更がマージ(merge)される。
• ファイルをバージョン管理しない状態に取り出すことをexportと言う。
• あるバージョンに付けた目印を，タグ（tag）と言う。
  • 自動的に付くタグがいくつかある。

    HEAD:作業コピーに対するリポジトリ上の最新リビジョンを指す
    BASE:作業コピーの元になっているリビジョンを指す

• バージョン管理の中心となるフォルダをトランク（trunk）と呼ぶ。
• trunkに平行してバージョン管理するフォルダをブランチ（branch）と呼ぶ。
• リポジトリは仮想的なファイルシステム。
  • ローカルのディスク上でファイルやフォルダをコピーするような感覚で使える。 現在の状態のファイルを残しておくのがtag，平行して別の変更を加える為のコピーがbranchになる。
  • リポジトリ上でコピーを行ってもファイル内容がコピーされるわけではないので，ディスク容量を気にする必要はない。

Subversionの入門

• タグもブランチも，リポジトリ上でコピーすることにより行う。 →copyサブコマンド
  • GUIクライアントには，タグやブランチのための専用UIが有るので，大丈夫かな。
  • コピーだから，HEADリビジョンは各コピー毎にあることになる。つまり，ブランチの作業コピー上でHEADリビジョンはそのブランチの最新リビジョンを指し，trunkを指さない。
• リポジトリを変更すると，リポジトリ全体のリビジョンが更新される。ファイル毎ではない。
  • タグを作成しなくても，リビジョンを指定して取り出せば全てのファイルがそのリビジョンの状態（チェンジセットに相当）で得られることになる。
• フォルダが管理されます。
• リネーム，移動が出来る。 →moveサブコマンド
• コミット前の変更の取り消しが出来る。 →revertサブコマンド
• updateすると現在の作業コピーにマージが発生するんだけど，マージには専用コマンドがある。 → mergeサブコマンド
• 作業コピーのBASEを別のリビジョン・タグ・ブランチに移動するために専用のコマンドがある。 →swicthサブコマンド

Subversionの特徴

• チェンジセットによるリビジョン管理
  CVSでは，このコミット作業はファイルごとになるんで，ファイルごとにリビジョン番号が振られちゃう。そのため，変更点が複数のファイルにまたがっている場合とかだと，変更点を把握するのがすごく大変になっちゃう。
  Subversionだと，リポジトリ全体にリビジョン番号を付けてバージョンの管理をしているので，コミット作業は関連ファイル全体を一度に行うようなっている。仕様変更によってどのファイルがどのように変更されたのか割合に分かるようになっています。このおかげでバグトラッキングシステム等の変更管理システムと一緒に利用すると，それぞれの変更の差分を確認しやすくなる。
• ファイルのコピー，リネームとかでも履歴が引き継げる
  CVSは，ファイルをコピーしたりファイルの名前を変更したりすると，ファイルの履歴を残せなかった。
  Subversionだと，ファイルをコピーする場合やファイル名の変更をする場合でも，ファイルの履歴を引き継げる。
• プロトコルにHTTPを利用できる
  CVSは，リポジトリへのアクセスは独自プロトコルか，SSH接続を使う。これだと，ファイアウォールとかあると接続出来なくて困ることがある。
  Subversionだと，WebDAVが利用できるんでHTTPプロトコルが通れば使用できる。
• 柔軟なマージ機能
  CVSは，基本的にはタグ付けからのみマージ出来たが，Subversionだと任意のリビジョン間の差分をマージできるようになっている。
• フック機能がある
  CVSと同様に，フックの機能がある。これでコミットの前後で特定の処理を実行できる。

  コミットログが記述されていない場合は，コミットさせない
  コミットログに故障管理IDや仕様変更IDが記述されていない場合は，コミットさせない
  コードチェックを行い問題があった場合，コミットさせない
  コミット後自動的にビルド／テストを行い，テスト結果やカバレッジのレポートを作成する

  といった事ができるようだ。

ドキュメント管理なんかにも使うと結構便利な気がする

1. バージョン管理
   Subversionみたいな管理ソフトがない場合，以下のような感じでファイル名などを工夫して世代を管理していると思う。

   1_企画書.ppt　→　2_企画書.ppt　→　3_企画書.ppt
   設計書_V1.doc　→　設計書_V2.doc　→　設計書_V3.doc
   20090814_設計書.doc　→　20090815_設計書.doc　→　20090816_設計書.doc

2. ベースラインの管理
   開発過程の“ある時点”で関係性を維持している状態のことを「ベースライン」と呼ぶらしい。
   お客さんとかに初めて提出したときの文書なんかがバージョン1としたら，1回目の修正で企画書だけ修正したとすると，そのときは企画書をバージョン2にして保存します（ファイル名とか変更して）。最終提出する時，微調整した企画書をバージョン3，他の文書なんかもあるんで，それをなんたら仕様書のバージョン2って感じで，これらもファイル名とかフォルダーとか作って保存しています。
   これを繰り返していくと頭の中に入っていた事も，お客さんに出した書類がどの書類がどのバージョンだったかとかわからなくなっちゃいます。これが複数のお客さんがいた時なんか尚更です。
   この場合，変更しなかった文書のバージョンも上げちゃえば少し管理が楽になる。あるお客さんに提出したのはバージョン２とか，このお客さんの時はバージョン３とか，って感じ。