SubversionはApacheプロジェクトですが、Apacheではオペレーティング・システム用の独自のバイナリ・ファイルをビルドしていません。サード・パーティが、すべての主要オペレーティング・システム用のバイナリ・ファイルをビルドします。

Subversionは、主なプラットフォームのどれにでもインストールできます。

sudo yum install subversion

C:\svn

svnserve --version

1. 「コントロール パネル」を開きます。
2. 「システム」→「システムの詳細設定」の順に選択します。
3. 「詳細設定」で、「環境変数」を選択します。
4. Subversionバイナリ・ディレクトリへのパスを追加して、「システム環境変数」ペインのPATH変数を編集します。

必要なときにSubversionが実行されるように、サービスとして構成します。

Subversionリポジトリは、バージョン作成されている、Subversionサーバー上のアーティファクトの集まりです。

この項では、次の項目について説明します。

• リポジトリの作成
  Subversionのインストール後、リポジトリを作成する必要があります。svnadminという名前のコマンドライン・ユーティリティは、サーバー側の管理操作の主要ツールです。
• 一貫したSubversionレイアウトの使用
  Subversionではリポジトリ内に特定のサブディレクトリ構造は必要ありませんが、このマニュアルで行われているように、規定の表記規則に従うことをお薦めします。
• 既存プロジェクトのインポート
  

SVNで作業を開始する前に、典型的なワークフローを理解する必要があります。

コードを変更するには、通常、次の操作を実行します。

1. svn updateコマンドを使用して作業コピーを更新します。

2. 変更を行います。必要に応じて、svn add、svn delete、svn copyおよびsvn moveコマンドを使用し、ファイルを編集します。

3. svn statusおよびsvn diffコマンドを使用して、変更を確認します。

4. 間違いを修正します。svn revertコマンドを使用すると、変更を取り消したり、中止することができます。

5. 競合を解決します。競合が解決したら、svn resolveコマンドを使用してマークを付けます。

6. svn commitまたはsvn ciコマンドを使用して、変更をコミットします。

図3-1は、SVN操作の完全なライフサイクルを示しています。

図3-1 SVNワークフロー

「図3-1 SVNワークフロー」の説明

継続的インテグレーションの開発プロセスでは、このワークフローはおおむね変わりません。非継続的インテグレーション・プロセスよりも、コミットされる変更のセットが小さく、より頻繁に発生する傾向があります。継続的インテグレーション・システムでインテグレーション・ビルドを実行できるように、ターゲット・リリース用のアクティブなトランクまたは分岐コードをコミットする必要があります。将来的にメインライン・コード・ベースにマージすることを意図した個人的な分岐の作成は避けてください。個人的な分岐およびマージの手法は統合を遅らせるもので、継続的インテグレーションの原則に反します。

Subversionプロジェクトを扱う際には、ファイルをローカル・ファイル・システムにチェックアウトします。次に、ファイルをリポジトリにコミットする準備ができたら、プロジェクトをチェックインします。

1. 次のコマンドを実行して、ファイルをチェックアウトします。

   svn co REPOSITORY_URL/REPOSITORY_PATH LOCAL_DIRECTORY
   

   このコマンドの内容は次のとおりです。

   • REPOSITORY_URLは、SubversionリポジトリへのURLです。

   • REPOSITORY_PATHは、チェックアウトされるディレクトリへのパスです。

   • LOCAL_DIRECTORYは、チェックアウトされたプロジェクトが格納されるローカル・ディレクトリへのパスです。

   test-projectの例は、プロジェクトのメインライン・コード開発を示しています。

   svn checkout
    svn+ssh://user@svn.mycompany.com/subversion/repository/test-project/trunk test-project
   

   この場合、test-projectというディレクトリが作成され、プロジェクトの内容は再帰的にサーバーからディレクトリにコピーされます。

2. チェックアウトされたファイルに対していくつでも変更を行うことができます。

   プロジェクトがいったんシステムにチェックアウトされた後は、そのソース・コードに対する後続のチェックアウトを実行する必要がなくなります。Subversionリポジトリの内容との同期を維持するために、チェックアウトされたディレクトリ、さらには個々のファイルに対してsvn updateを実行できます。

3. リポジトリに変更をコミットする準備が整ったら、コミットするファイルまたはディレクトリをチェックインします。すべてのコンポーネントがチェックアウトされるディレクトリのメンバーであるかぎり、チェックインされるファイルまたはディレクトリのセットが、チェックアウトされたファイルまたはディレクトリのセットに対応している必要はありません。次のコマンドを実行して変更をコミットします。

   svn commit -m "Added code and test case" test-project/src/main/java
    test-project/src/test/resources/testdata.xml
   svn resolve test-project/src/test/resources/testdata.xml
   

   競合を解決した後、通常のチェックイン操作を続行します。

4. リポジトリにローカル変更をコミットする操作の前に、svn updateコマンドを実行して、最後のチェックアウトまたは更新以降に、他のユーザーによってコードにコミットされた変更を統合します。

   svn update
   

5. 次のコマンドを実行して変更をコミットします。

   svn commit -m "description of the updates"

タグ付けによって分岐の名前付きポイント・イン・タイム・コピーが作成されます。

次の場合にタグがリリースされます。

• プロジェクトがリリースされた場合

• 重要なマイル・ストーンが発生した場合

リリースにタグを付けることが重要ですが、これは、タグによってパッチ適用リリースのための簡単なメカニズムが提供されるためです。あるリリースに不具合が見つかった場合、そのリリースのタグから分岐して、修正を行い、そのリリースのパッチを作成できます。後でこの新しい(パッチ適用済の)リリースに問題が見つかり、新しい問題に対する修正が必要になった場合には、このリリースにも同様にタグを付けます。

リリースにタグを付けなかった場合、そのリリースにビルドされている正確なコード行の取得が非常に難しくなります。

使用できるSubversionクライアントはいくつかあります。

この項では、2つの一般的なSubversionクライアントについて説明します。

• WebSVN
  
• TortoiseSVN
  

このドキュメントは、Subversionを起動して実行するクイック・ガイドとして作成されているため、Subversionの操作について詳細は書かれていません。

詳細は、次の『Subversionによるバージョン管理』を参照してください。

http://svnbook.red-bean.com