世界で最も単純なSubversionによるバージョン管理手法

Top - 世界で最も単純なSubversionによるバージョン管理手法

Subersionの用語説明

Repository

サーバ上に存在する唯一の本体です。お亡くなりになると、夜行列車で北へ向かいましょう。プロジェクトごとに作成します。

Update

レポジトリから差分をローカルにダウンロードします。

Commit

ローカルコピーの差分をレポジトリに反映させます。

Checkout

レポジトリからローカルにダウンロードします。基本的には、最初に1回だけ行います。バージョン管理システムの視点で、名前が付けられているので、最初は分かり難いと思います。

チェックイン

Commitと同じ意味です。

Revert

ローカルコピーをレポジトリのリビジョンに合わせます。とても便利です。

リビジョン番号

Commitするたびに上がっていきます。ファイル単位ではなく、レポジトリ全体に対して付けられます。いつでも特定のリビジョン番号のファイル一式を取り出せます。

レポジトリの構成

repos
  |
  |--branches
  |    |--RB-1.0
  |    |--RB-2.0
  |
  |--tags
  |    |--REL-1.0
  |    |--REL-2.0
  |
  |--trunk
       |
       |--doc
       |
       |--src
       |

branches

今回の管理手法では不要です。いずれお世話になる時が来るでしょう。

tags

すべてのリリースの歴史を記録します。

trunk

開発の本体です。

具体的な管理の流れ

要件定義フェーズ

Repositoryを作成し、trunk/docの下で文書を管理します。

開発フェーズ

trunkをチェックアウトし、trunk/src下で開発・単体テストを行います。

統合テスト

trunk/srcを指定したリビジョン番号でテスト環境へチェックアウト／アップデートします。

統合テストが完了するまで、以上を繰り返します。

リリース

指定したリビジョン番号でtrunk/srcをtags/REL-1.0にコピーします。

tags/REL-1.0を本番環境へチェックアウトします。

リリース後の不具合対応

基本的には、開発フェーズ～統合テスト～リリースの手順を繰り返すだけです。

次のリリース予定のコードと不具合対応のコードが混在した場合は、前者の作業をキリのいいところで中止し、不具合対応を優先します。

一部次回リリース予定のコードも含まれてしまいますが、前倒しで納品したという事で、お客さんには喜んでもらいましょう。

しかし、次回リリース予定の作業がなかなかキリのいいところで終わらない場合はどうしたらいいのでしょうか？ そんな時は、以下の格言を思い出すと良いでしょう。

人生諦めが肝心

それでも諦めがつかない人は、ココをクリック。 今まで説明したことを守っていれば、その時になって慌てても何とかなります。

ローカル開発環境を持たない開発者のための妥協

サーバを一台用意します。

ローカル開発環境を持たないすべてのユーザをそのサーバにご案内します。

個々のユーザ同士は仲良くしましょう。ゆずりあいの精神を忘れてはいけません。

コミットする時は、慎重に！他人が修正したファイルをコミットしてしまうかも知れません。

Topへ戻る[U]