【図解】SVNのダウンロード・インストール方法と特徴を解説

By /

【図解】SVNのダウンロード・インストール方法と特徴を徹底解説

導入：なぜバージョン管理システムが必要なのか？

ソフトウェア開発、ドキュメント作成、デザイン作業、あるいはウェブサイト制作など、チームや個人でプロジェクトを進める上で、避けて通れない課題があります。それは、「変更履歴の管理」です。

  • 複数の人が同じファイルを同時に編集したらどうなる？ お互いの変更を上書きしてしまい、作業が無駄になる可能性があります。
  • 過去の特定の時点の状態に戻したい場合は？ 手作業でバックアップを取っていないと、不可能かもしれません。
  • 誰が、いつ、どのような変更を加えたのか追跡したい。 これは問題発生時の原因究明や、後から変更内容を確認する上で非常に重要です。
  • 新しい機能を追加しようとして失敗した。元の安定した状態に戻したい。 簡単に安全に戻せる仕組みが必要です。

これらの課題を解決するために生まれたのが、「バージョン管理システム（Version Control System, VCS）」です。バージョン管理システムを利用することで、ファイルの変更履歴を効率的かつ体系的に管理し、複数の開発者による共同作業を円滑に進めることができます。

バージョン管理システムには、いくつかの種類があります。古くから使われているCVS（Concurrent Versions System）、その後継として登場したSVN（Subversion）、そして現在主流となっているGitなどです。それぞれに特徴があり、プロジェクトの規模やチームの作業スタイルによって最適なシステムは異なります。

この記事では、現在でも多くの企業やプロジェクトで利用されているSVN（Subversion）に焦点を当てます。SVNの基本的な概念、主要な特徴、そして競合であるGitとの比較を通してその立ち位置を理解します。さらに、具体的なダウンロード・インストール方法（サーバー側、クライアント側）をOS別に詳しく解説し、基本的な操作方法や運用上のベストプラクティスについても触れていきます。「図解」とありますが、ここでは概念や手順をテキストで分かりやすく表現し、図のイメージを補足する形で説明します。

SVNの導入を検討している方、SVNの使い方を学びたい方、あるいはSVNとGitの違いを理解したい方にとって、この記事が包括的なガイドとなることを目指します。

SVN（Subversion）の概要と歴史

SVNは、Apache Software Foundationが開発・管理している集中型バージョン管理システムです。CVSの後継として、その欠点を克服するために2000年頃から開発が始まり、2004年に最初の公式リリースが行われました。

CVSは、ファイルを一つずつ管理するという設計思想のため、ディレクトリの名前変更や移動、コピーといった操作が苦手でした。また、コミットがアトミック（不可分）ではなかったため、コミット処理の途中でエラーが発生すると、一部のファイルだけが更新されてしまうという問題がありました。

SVNはこれらの問題を解決するために、リポジトリ全体を一つのファイルシステムのように扱い、コミットをアトミックに行えるように設計されました。これにより、より堅牢で信頼性の高いバージョン管理が可能になりました。

SVNの基本概念

SVNを理解する上で核となる概念は以下の通りです。

  1. リポジトリ (Repository):

    • バージョン管理される全てのファイル、ディレクトリ、そしてそれらの変更履歴が集約されて保存される場所です。
    • SVNにおける「真実の源泉」であり、チームメンバーはここから最新のコードを取得したり、自分の変更を反映させたりします。
    • リポジトリは通常、開発チームで共有される単一のサーバー上に置かれます。
    • リポジトリは、ファイルシステム上の特定のディレクトリ、またはデータベースとして構築されます。

    図解：リポジトリのイメージ
    +---------------------+
    | リポジトリ |
    | (中央のデータ保管庫) |
    +---------------------+
    ^
    |
    | (Commit)
    |
    +---------------------+
    | 作業コピー | <--- 複数の開発者が持つローカルのコピー
    | (開発者AのPC) |
    +---------------------+

  2. 作業コピー (Working Copy):

    • リポジトリから、特定の時点（通常は最新のリビジョン）のファイルとディレクトリを自分のローカルコンピュータにチェックアウト（Checkout）したものです。
    • 開発者はこの作業コピー上でファイルの編集、追加、削除などの作業を行います。
    • 作業コピーはリポジトリの完全なコピーではなく、作業に必要なファイルセットのみを含みます。また、.svn という隠しディレクトリが含まれており、ここでリポジトリとの同期情報（どのリビジョンをチェックアウトしたか、ローカルの変更状況など）が管理されています。

    図解：リポジトリと作業コピーの関係
    +---------------------+ (Checkout) +---------------------+
    | リポジトリ | <------------------------- | 作業コピー |
    | (サーバー上) | | (開発者のローカル) |
    +---------------------+ (Commit) +---------------------+
    ^ ^
    | |
    | (Update) | (Edit files)
    | |
    +---------------------+ +---------------------+
    | 他の作業コピー | <------------------------- | 他の開発者 |
    | (開発者BのPC) | (Update) | (自分の作業) |
    +---------------------+ +---------------------+

  3. リビジョン (Revision):

    • リポジトリに対するコミット（Commit）操作が行われるたびに生成される、リポジトリ全体の特定時点における状態（スナップショット）を指します。
    • リビジョンは通常、1から始まる整数値で管理され、コミットごとに1ずつ増加します。
    • リビジョン番号を指定することで、過去の任意時点の状態を取り出したり、変更履歴を確認したりすることができます。
    • HEADという特別な名前は、リポジトリの最新のリビジョンを指します。

    図解：リビジョンの流れ
    +------------+ (Commit) +------------+ (Commit) +------------+
    | リビジョン 1 | ------------> | リビジョン 2 | ------------> | リビジョン 3 | ---> ... HEAD
    | (初期状態) | | (変更 A 適用)| | (変更 B 適用)|
    +------------+ +------------+ +------------+
    ^
    |
    (最新の状態)

これらの概念に基づき、SVNでの開発ワークフローは、基本的に「リポジトリから作業コピーをチェックアウトする」「作業コピーを最新状態に更新する」「作業コピーでファイルを編集する」「変更内容をリポジトリにコミットする」の繰り返しとなります。

SVNの主要な特徴

SVNが持つ代表的な特徴は以下の通りです。これらの特徴が、CVSからの改善点であり、SVNの強みとなっています。

  1. アトミックコミット (Atomic Commits):

    • 複数のファイルに対する変更を一度にコミットする際、その変更セット全体が成功するか、全く適用されないかのどちらかになります。
    • コミット処理の途中でネットワークエラーやサーバー障害が発生しても、リポジトリが中途半端な状態になることを防ぎ、データの整合性を保ちます。これはCVSにおける大きな課題の一つでした。

  2. ディレクトリのバージョン管理 (Versioned Directories):

    • SVNはファイルだけでなく、ディレクトリそのものもバージョン管理の対象とします。
    • ディレクトリの追加、削除、名前変更、移動といった操作も変更履歴として正確に追跡されます。これにより、プロジェクト全体の構造の変遷を把握しやすくなります。CVSはディレクトリのバージョン管理が苦手でした。

  3. ファイル名の変更、コピー、削除のサポート (Support for Renaming, Copying, Deleting Files/Directories):

    • ファイルやディレクトリの名前変更、コピー、削除といった操作が、単なる追加・削除の組み合わせとしてではなく、一つの操作として追跡・管理されます。
    • 特にファイルのコピー（ブランチやタグの作成を含む）は効率的に行われます。SVNはコピー元への参照を保持し、ストレージの消費を抑える「安価なコピー (Cheap Copies)」機能を持っています。

  4. プロパティ管理 (Property Management):

    • バージョン管理下のファイルやディレクトリに対して、バージョン管理システム自体が管理するメタデータ（プロパティ）を付加することができます。
    • 例えば、svn:ignore プロパティを使ってバージョン管理対象から除外するファイルを指定したり、svn:executable プロパティで実行権限を付与したり、svn:mime-type でMIMEタイプを指定したりできます。ユーザーが独自のプロパティを追加することも可能です。

  5. ブランチとタグの作成・管理 (Branches and Tags):

    • SVNでは、svn copy コマンドを使ってリポジトリ内の特定のパス（通常は /trunk）を別のパス（/branches や /tags 配下）にコピーすることで、ブランチやタグを作成します。
    • これは内部的には安価なコピーとして実現されるため、実際のディスク容量はほとんど消費せず高速です。
    • ブランチはメインラインから分岐して並行開発を行うために使われ、タグは特定のリビジョン（例：リリースバージョン）に分かりやすい名前を付けるために使われます（タグは基本的に変更しない）。
    • ブランチやタグもリポジトリ上で管理されるため、チーム全体で共有・参照しやすい構造になっています。

  6. バイナリファイルの効率的な管理 (Efficient Handling of Binary Files):

    • SVNはテキストファイルと同様にバイナリファイルの変更履歴も管理します。
    • テキストファイルは差分（変更された部分だけ）を記録することで効率的に履歴を保存しますが、バイナリファイルは差分を正確に計算するのが難しい場合があります。SVNはバイナリファイルについても差分管理を試みますが、難しい場合はフルコピーを保存することもあります。
    • Gitと比較した場合、特に差分圧縮が効きにくい大きなバイナリファイルの管理において、SVNの方が単純な仕組みゆえに扱いやすいと感じるユーザーもいます（ただし、近年Git LFSなどの拡張機能によりGitでも改善されています）。

  7. ネットワーク透過性 (Network Transparency):

    • リポジトリへのアクセス方法として、ローカルファイルシステム (file://)、HTTP/HTTPS (http://, https:// – Apacheとmod_dav_svnを使用)、SVNプロトコル (svn:// – svnserveを使用)、SSHトンネル経由のSVNプロトコル (svn+ssh://) など、多様なプロトコルをサポートしています。
    • これにより、ローカルマシン上のリポジトリからインターネット経由のリポジトリまで、同じコマンドやクライアントツールでアクセスできます。

  8. クライアント/サーバーモデル (Client/Server Model):

    • リポジトリはサーバー上に集中管理され、各開発者はクライアントソフトウェアを使ってリポジトリにアクセスします。
    • このシンプルな集中型モデルは、管理者がユーザーや権限を一元的に管理しやすいという利点があります。

  9. 豊富なクライアントツール (Rich Client Tool Ecosystem):

    • コマンドラインクライアントはもちろんのこと、WindowsのTortoiseSVN、macOSのCornerstoneやVersionsなど、OSネイティブのGUIクライアントや、EclipseなどのIDE統合プラグインなど、様々なクライアントツールが提供されており、ユーザーの好みに応じて選択できます。

これらの特徴により、SVNはCVSよりも信頼性が高く、使いやすいバージョン管理システムとして広く普及しました。

SVNとGitの比較：集中型 vs 分散型

現在バージョン管理システムの主流はGitですが、SVNも依然として多くの現場で使われています。SVNとGitの最大の違いは、その設計思想、特にリポジトリの構造と管理方法にあります。SVNは集中型、Gitは分散型です。

この違いが、ブランチの扱い方、オフライン作業の可否、パフォーマンス、学習コストなど、様々な側面に影響を与えます。

集中型バージョン管理システム (SVN)

  • リポジトリ: 中央に単一のリポジトリが存在し、全てのバージョン履歴がそこに集約されます。
  • 作業コピー: 開発者はリポジトリから特定の時点のファイルセット（作業コピー）をチェックアウトして作業します。作業コピーには履歴情報は含まれません（.svn ディレクトリには一部キャッシュされるが限定的）。
  • コミット: 自分の変更をリポジトリに直接コミットします。コミットするにはネットワークが必要です。
  • ブランチ/タグ: リポジトリ内のディレクトリコピーとして作成されます。

図解：集中型 (SVN) モデル
+---------------------+
| 中央リポジトリ | <--- 全ての履歴がここに
+---------------------+
^ ^ ^
/ \ \
/ \ \
(Commit)/ (Update) \ \ (Commit)
/ \ \
+---------+ +---------+ +---------+
| 開発者A | | 開発者B | | 開発者C |
| (WC) | | (WC) | | (WC) |
+---------+ +---------+ +---------+

分散型バージョン管理システム (Git)

  • リポジトリ: 各開発者のローカルマシンに、リポジトリ全体の完全なコピー（全ての履歴を含む）が存在します。中央リポジトリは必須ではなく、共有のための「リモートリポジトリ」として利用されます。
  • 作業コピー: Gitでは、ローカルリポジトリから特定のブランチの最新状態を「ワーキングツリー」として取り出して作業します。ワーキングツリーとローカルリポジトリは密接に関連しています。
  • コミット: 自分の変更はまずローカルリポジトリにコミットされます。コミットはオフラインで可能です。他の開発者と共有したい変更は、リモートリポジトリに「プッシュ (Push)」します。
  • ブランチ/タグ: リポジトリ内のコミットを指す軽量なポインタとして管理されます。ブランチ作成や切り替えは非常に高速です。

図解：分散型 (Git) モデル
+---------------------+
| 共有リポジトリ | <--- 同期用 (必須ではない)
+---------------------+
^ ^
/ \
(Push)/ \ (Pull)
/ \
+-----------------+ +-----------------+
| 開発者AのPC | | 開発者BのPC |
| +-------------+ | | +-------------+ |
| | ローカルRP | | <-----> | | ローカルRP | | <--- 各自が完全な履歴を持つ
| +-------------+ | (Push/Pull) +-------------+ |
| +-------------+ | | +-------------+ |
| | ワーキングTC| | | | ワーキングTC| |
| +-------------+ | | +-------------+ |
+-----------------+ +-----------------+

具体的な違いの比較

項目 SVN (集中型) Git (分散型)
リポジトリ構造 中央に単一、履歴はサーバーのみ 各開発者が完全なローカルコピー、共有用リモートRP
作業範囲 オンライン必須（コミット、更新など） ほとんどの操作がオフライン可能（コミット、ブランチ）
コミット サーバーへ直接コミット（ネットワーク必要） まずローカルRPへコミット（オフライン可）、後でPush
履歴の参照 サーバーに問い合わせて取得 ローカルRPにあるため高速
ブランチ/タグ リポジトリ内でのディレクトリコピー（安価なコピー） コミットへのポインタ（軽量、高速）
ブランチ操作 作成/切り替えに時間がかかる場合あり、マージが複雑 作成/切り替えが高速、マージが得意
障害耐性 サーバーがダウンすると作業停止 ローカルで作業継続可能、他の開発者からリポジトリ取得可
学習コスト 概念がシンプルで分かりやすいと感じる人が多い 分散モデルの理解が必要、コマンドが多い
アクセス制御 中央管理のため設定しやすい リモートRP単位での制御が基本
バイナリ管理 Gitよりシンプルで扱いやすいと感じる場合あり 通常はLFSなどの拡張機能が必要

どちらを選ぶべきか？

どちらのシステムにもメリット・デメリットがあり、プロジェクトの性質やチームの経験値によって向き・不向きがあります。

  • SVNが適しているケース:

    • バージョン管理の概念をシンプルに理解したい初心者チーム。
    • 厳格な中央管理、アクセス権限設定が重要なプロジェクト。
    • Gitの分散モデルが複雑に感じられるチーム。
    • 大規模なバイナリファイルを多く扱うプロジェクトで、Git LFSなどの導入が難しい場合。
    • 既存のSVNリポジトリを引き続き利用する場合。
    • 管理者がユーザーやリポジトリをシンプルに一元管理したい場合。

  • Gitが適しているケース:

    • OSS開発やアジャイル開発など、並行開発や頻繁なマージが多いプロジェクト。
    • オフラインでの作業が多い環境。
    • 複雑なブランチ戦略（Feature Branching, Git Flowなど）を採用したい場合。
    • パフォーマンス（特にブランチ操作、履歴参照）が重視される場合。
    • 分散開発のメリット（各開発者が独立して作業しやすい）を活かしたい場合。
    • 近年主流であり、情報やツールが豊富。

Gitが主流になった現在でも、SVNはそのシンプルさと管理のしやすさから、特に組織内部での開発プロジェクトなどで依然として利用されています。プロジェクトの要件をよく検討し、適切なシステムを選択することが重要です。

SVNの構成要素（図解の説明）

前述の概念をより視覚的に理解するために、SVNの主要な構成要素とその関係性を図解として想像してみましょう（ここではテキストで説明します）。

  • リポジトリ (Repository):

    • 図の中央に大きなストレージとして配置されます。
    • 内部には、バージョン管理されているファイルやディレクトリのツリー構造が、リビジョンごとに時系列で保存されています。
    • 全ての変更履歴（誰が、いつ、何を、なぜ変更したか）が記録されています。

    +-------------------------------------------------------+
    | SVN リポジトリ (サーバー上) |
    | +---------------------------------------------------+ |
    | | / | |
    | | +-- trunk/ <-- 開発メインライン | |
    | | +-- branches/ <-- ブランチ群 | |
    | | | +-- feature-A/ | |
    | | | +-- release-1.0/ | |
    | | +-- tags/ <-- タグ群 | |
    | | +-- v1.0/ | |
    | | +-- v1.1-RC1/ | |
    | +---------------------------------------------------+ |
    | +---------------------------------------------------+ |
    | | 変更履歴 (Revision 1, 2, 3, ...) | |
    | | (誰が、いつ、何をコミットしたか) | |
    | +---------------------------------------------------+ |
    +-------------------------------------------------------+

  • クライアント (Client):

    • 開発者が自分のコンピュータ上でSVN操作を行うためのソフトウェアです。
    • コマンドラインツールやGUIツール（TortoiseSVNなど）があります。
    • クライアントはネットワーク経由でリポジトリ（サーバー）にアクセスします。

  • サーバー (Server):

    • リポジトリをホストし、クライアントからのアクセス要求（チェックアウト、更新、コミットなど）に応答するソフトウェアです。
    • Apacheとmod_dav_svnを組み合わせる方法や、専用のsvnserveを使う方法、WindowsではVisualSVN Serverのような統合パッケージを使う方法があります。

  • 作業コピー (Working Copy):

    • クライアントのローカルディスク上に作成される、リポジトリの特定リビジョンのファイルセットのコピーです。
    • 開発者はこの作業コピー上で編集作業を行います。
    • 作業コピーのディレクトリ内には、SVNが内部管理情報を保存するための隠しディレクトリ .svn が存在します。

    +-------------------------------------------------------+
    | 開発者のコンピュータ (クライアント) |
    | +---------------------------------------------------+ |
    | | SVN クライアントソフトウェア | |
    | +---------------------------------------------------+ |
    | | |
    | (ローカル操作) (サーバーとの通信) |
    | | |
    | +---------------------------------------------------+ |
    | | 作業コピー (Working Copy) | |
    | | +-- project/ | |
    | | | +-- src/ | |
    | | | +-- docs/ | |
    | | | +-- .svn/ <-- 内部管理情報 | |
    | | +---------------------------------------------------+ |
    +-------------------------------------------------------+

  • 基本的なワークフロー:

    • Checkout: リポジトリから作業コピーを新規作成する操作。
      • 図解: リポジトリ -> クライアント -> 作業コピー (新規)
    • Update: 作業コピーをリポジトリの最新状態（または指定したリビジョン）に同期させる操作。他の開発者のコミットを作業コピーに取り込む。
      • 図解: リポジトリ -> クライアント -> 作業コピー (既存を更新)
    • Edit: 作業コピー上のファイルを編集、追加、削除など行う操作。これはローカル操作。
      • 図解: 作業コピー内で変更発生
    • Commit: 作業コピーでの変更内容をリポジトリに反映させる操作。新しいリビジョンが生成される。
      • 図解: 作業コピー (変更あり) -> クライアント -> リポジトリ (変更反映、新リビジョン作成)
    • Branch/Tag: リポジトリ内のパスをコピーする操作。
      • 図解: リポジトリ内の特定パス -> リポジトリ内の別パス (コピー)
    • Merge: あるブランチで行われた変更を別のブランチ（通常はtrunkや他のfeatureブランチ）の作業コピーに取り込む操作。
      • 図解: リポジトリ内の別ブランチの変更 -> クライアント -> 作業コピー (Merge処理)

これらの構成要素とワークフローを理解することが、SVNを効果的に利用する第一歩となります。

SVNの導入方法（サーバー側）

SVNサーバーを構築する方法はいくつかあります。主なものは以下の通りです。

  1. Apache Webサーバー + mod_dav_svn: HTTP/HTTPS経由でアクセス可能にし、既存のWebサーバー環境と統合しやすい方法です。アクセス制御もApacheの認証機能と連携できます。
  2. svnserve: SVN専用の軽量なサーバーデーモンです。SVNプロトコル（svn://）またはSSHトンネル経由（svn+ssh://）でアクセスします。設定が比較的シンプルです。
  3. VisualSVN Server (Windows): Apache、Subversion、管理GUIなどが統合されたWindows向けのパッケージです。インストールと設定が非常に簡単です。

ここでは、WindowsでVisualSVN Serverを使う方法と、Linux（Ubuntuを例に）でsvnserveとApache+mod_dav_svnを使う方法をそれぞれ解説します。

1. Windows Server への導入 (VisualSVN Server)

VisualSVN Serverは、Windows環境でSVNサーバーを構築する際に最も手軽でおすすめの方法です。ApacheやSubversionの専門知識がなくても簡単にセットアップできます。

図解：VisualSVN Server インストール手順のイメージ

  1. インストーラーのダウンロード:

    • VisualSVN Serverの公式ウェブサイト（https://www.visualsvn.com/visualsvn-server/）にアクセスします。
    • 目的のバージョン（通常は最新版）を選択し、環境（32bit or 64bit）に合ったインストーラーをダウンロードします。商用利用の場合はライセンスについて確認してください（無償版もあります）。

  2. インストーラーの実行:

    • ダウンロードした VisualSVN-Server-x.x.x-x64.msi のような名前のファイルを実行します。
    • 図解: ウィザード開始画面が表示されます。「Next」をクリック。

  3. ライセンス契約への同意:

    • ライセンス条項を読み、「I accept the terms in the License Agreement」（ライセンス契約の条項に同意します）にチェックを入れます。
    • 図解: ライセンス同意画面。「Next」をクリック。

  4. インストールオプションの設定:

    • インストール先のフォルダ、リポジトリのルートフォルダ、サーバーのポート番号、認証方法などを設定します。
    • Installation Path: VisualSVN Server自体をインストールする場所。デフォルトで問題ないでしょう。
    • Repositories Path: SVNリポジトリが保存される場所。ディスク容量に余裕のあるドライブを指定するのが良いでしょう。
    • Server Port: SVNサーバーが使用するポート番号。デフォルトは443（HTTPS）または80（HTTP）。通常はHTTPSの443が推奨されます。ファイアウォールでこのポートを開ける必要があります。
    • Authentication Mode: 認証方法。
      • Subversion Authentication: VisualSVN Server独自のユーザー/グループ管理を使う方法。シンプルで手軽。
      • Windows Authentication: Windowsのユーザー/グループを利用する方法。Active Directory環境などで便利。
    • 必要に応じて「Install Subversion command line tools」にもチェックを入れると、サーバーマシンでもコマンドラインSVNツールが使えるようになります。
    • 図解: インストールオプション設定画面。各項目を入力/選択し、「Next」をクリック。

  5. インストール開始:

    • 設定内容を確認し、「Install」をクリックするとインストールが開始されます。
    • 図解: インストール準備完了画面。「Install」をクリック。

  6. インストール完了:

    • インストールが完了すると、VisualSVN Server Managerを起動するかどうか尋ねられます。
    • 図解: インストール完了画面。「Finish」をクリック。

  7. VisualSVN Server Manager の起動と初期設定:

    • インストール完了後にVisualSVN Server Managerを起動します。
    • 図解: VisualSVN Server Manager 画面。左側のツリービューに「VisualSVN Server」や「Repositories」「Users」「Groups」などが表示されます。

  8. リポジトリの作成:

    • 「Repositories」を右クリックし、「Create New Repository…」を選択します。
    • 図解: リポジトリ作成ウィザード画面。
    • リポジトリ名を入力します（例: myproject）。
    • リポジトリの種類を選択します（通常は Regular FSFS repository）。
    • 推奨されるレイアウト（/trunk, /branches, /tags）を作成するか選択できます。通常は「Create default structure…」にチェックを入れます。
    • 図解: リポジトリ名入力、種類選択、構造作成オプション画面。「Create」をクリック。

  9. ユーザーとグループの管理 (Subversion Authenticationの場合):

    • 「Users」を右クリックし、「Create User…」でユーザーを作成します（ユーザー名、パスワード）。
    • 「Groups」を右クリックし、「Create Group…」でグループを作成し、作成したユーザーを所属させることができます。
    • 図解: ユーザー作成ダイアログ、グループ作成/編集ダイアログ。

  10. 権限設定:

    • 作成したリポジトリを選択し、右側のパネルの「Properties」タブを開きます。
    • 「Security」セクションで、ユーザーやグループに対して、リポジトリ全体または特定のパス（例: /trunk, /branches, /tags）に対するアクセス権限（No Access, Read-Only, Read/Write）を設定します。
    • 「Add…」ボタンでユーザーやグループを追加し、権限を設定します。不要なデフォルトのエントリ（例: Everyone）は削除または権限を制限します。
    • 図解: リポジトリのProperties画面、Securityタブ。ユーザー/グループと権限リスト。

これでSVNサーバーの基本的な設定は完了です。クライアントから指定したポート番号（デフォルトは443）とリポジトリURL（例: https://your_server_name/svn/myproject）でアクセスできるようになります。

2. Linux Server への導入 (Ubuntu を例に)

Linux環境では、パッケージマネージャーを使って簡単にSubversionと関連ツールをインストールできます。サーバーの構築方法として、svnserveを使う方法とApache+mod_dav_svnを使う方法があります。

共通のインストール手順:

  1. パッケージのインストール:

    • ターミナルを開き、パッケージリストを更新してSubversionパッケージをインストールします。
      bash
      sudo apt update
      sudo apt install subversion subversion-tools
    • Apacheを使う場合は、ApacheとSubversionモジュールもインストールします。
      bash
      sudo apt install apache2 libapache2-mod-svn

  2. リポジトリの作成:

    • SVNリポジトリを保存するディレクトリを作成し、svnadmin create コマンドでリポジトリを初期化します。例として /srv/svn/myproject に作成します。
      bash
      sudo mkdir -p /srv/svn/myproject
      sudo svnadmin create /srv/svn/myproject
    • リポジトリディレクトリの所有者を、サーバーを実行するユーザー（svnserveならSubversionを実行するユーザー、Apacheならwww-dataなど）に変更します。
      “`bash
      sudo chown -R www-data:www-data /srv/svn/myproject # Apacheの場合

    または適切なユーザー:グループに

    “`

方法 A: svnserve を使う方法

svnserveはシンプルなSVNプロトコル（svn://）でアクセスする専用サーバーです。

  1. svnserveの設定ファイル編集:

    • 作成したリポジトリ内の設定ファイル conf/svnserve.conf を編集します。
      bash
      sudo nano /srv/svn/myproject/conf/svnserve.conf
    • 以下の行のコメントアウト（行頭の #）を外し、必要に応じて設定します。
      • [general] セクション:
        • anon-access = none : 匿名ユーザーからのアクセスを拒否（readで読み取り許可、writeで書き込み許可）
        • auth-access = write : 認証されたユーザーからのアクセス権限（read, write）
        • password-db = passwd : パスワードファイルを指定（confディレクトリからの相対パス）
        • authz-db = authz : 権限設定ファイルを指定（confディレクトリからの相対パス）

  2. ユーザー認証情報の設定:

    • パスワードファイル conf/passwd を編集します。
      bash
      sudo nano /srv/svn/myproject/conf/passwd
    • [users] セクションに ユーザー名 = パスワード の形式でユーザーを追加します。
      [users]
      user1 = password123
      user2 = sekreto

  3. 権限設定 (authz を使う場合):

    • 権限設定ファイル conf/authz を編集します。
      bash
      sudo nano /srv/svn/myproject/conf/authz
    • グループ定義、リポジトリパスごとの権限設定を記述します。
      • [groups] セクション: グループ名 = ユーザー1, ユーザー2, …
      • [/] または [リポジトリ名:/パス] セクション:
        • @グループ名 = 権限 (r=read, rw=read/write)
        • ユーザー名 = 権限
        • * = 権限 (その他の全てのユーザー)
          “`
          [groups]
          developers = user1, user2
          qa = user3

    [/] # リポジトリ全体に対する権限
    @developers = rw
    @qa = r
    * = # その他はアクセス不可

    [/myproject/branches] # 特定のパスに対する権限
    user1 = r
    user2 = r
    “`

  4. svnserve の起動:

    • フォアグラウンドで起動してテストする場合:
      bash
      svnserve -d -r /srv/svn/myproject # リポジトリのルートディレクトリを指定
    • -d: デーモンとしてバックグラウンド実行
    • -r: リポジトリのルートディレクトリ。複数のリポジトリを置く親ディレクトリを指定すると、svn://server/repo_name の形式でアクセスできるようになります。例えば /srv/svn に -r /srv/svn と指定した場合、作成した /srv/svn/myproject リポジトリへは svn://server/myproject でアクセスします。
    • 本番運用ではSystemdなどを利用してサービスとして起動・管理するのが一般的です。Systemd設定ファイルの例 (/etc/systemd/system/svnserve.service):
      “`ini
      [Unit]
      Description=Subversion protocol daemon
      After=network.target

    [Service]
    Type=forking
    User=www-data # またはリポジトリの所有者
    Group=www-data # またはリポジトリの所有グループ
    ExecStart=/usr/bin/svnserve -d -r /srv/svn # リポジトリの親ディレクトリを指定
    KillMode=process
    Restart=on-failure

    [Install]
    WantedBy=multi-user.target
    * 設定ファイルを作成/編集後、Systemdの設定をリロードし、サービスを起動、自動起動設定を行います。bash
    sudo systemctl daemon-reload
    sudo systemctl start svnserve
    sudo systemctl enable svnserve
    “`

  5. ファイアウォール設定:

    • svnserveはデフォルトでTCPポート 3690 を使用します。外部からのアクセスを許可するため、ファイアウォール（ufwなど）でこのポートを開ける必要があります。
      bash
      sudo ufw allow 3690/tcp
      sudo ufw reload

これでsvnserve経由でのアクセスが可能になります。クライアントからは svn://your_server_ip:3690/myproject または -r で親ディレクトリを指定した場合は svn://your_server_ip/myproject のようなURLでアクセスします。

方法 B: Apache + mod_dav_svn を使う方法

Apacheを使うと、HTTP/HTTPS経由でアクセスでき、Webブラウザでのリポジトリ参照や、Apacheの認証機能（Basic認証、Digest認証など）との連携が容易です。

  1. Apacheモジュールの有効化:

    • インストールした mod_dav_svn と mod_authz_svn モジュールを有効化します。
      bash
      sudo a2enmod dav_svn
      sudo a2enmod authz_svn
      sudo systemctl restart apache2

  2. Apache設定ファイルの編集:

    • Subversionリポジトリへのアクセスを設定するVirtualHostまたはメイン設定ファイル（例: /etc/apache2/conf-available/subversion.conf）を作成または編集します。
      bash
      sudo nano /etc/apache2/conf-available/subversion.conf

    • 以下のような設定を記述します。
      “`apache
      # アクセスするパス (例: http://your_server_ip/svn でアクセス)
      DAV svn
      SVNParentPath /srv/svn # リポジトリを複数置く親ディレクトリを指定

      認証設定 (例: Basic認証 + htpasswdファイル)

      AuthType Basic
      AuthName “Subversion Repository”
      AuthUserFile /etc/apache2/conf-available/passwd.users # パスワードファイルのパス
      Require valid-user # 有効なユーザーのみアクセス許可

      権限設定 (authzファイルを使用)

      AuthzSVNAccessFile /etc/apache2/conf-available/authz.users # 権限設定ファイルのパス
      Require valid-user # authzで定義されたユーザーに限定

      ``
      *      ディレクティブのパスは、クライアントがリポジトリにアクセスする際のURLのパス部分になります。
      *      SVNParentPathは、複数のリポジトリを管理する場合にその親ディレクトリを指定します。この場合、リポジトリ名がURLに含まれます（例:http://server/svn/myproject）。単一のリポジトリを特定のURLにマップする場合はSVNPath /srv/svn/myprojectを使用します。
      * 認証方法としてBasic認証を使用し、ユーザー名とパスワードは      /etc/apache2/conf-available/passwd.users` ファイルで管理します。

  3. ユーザー認証情報の設定 (.htpasswd):

    • htpasswd コマンドを使ってユーザー名とパスワードのファイルを作成または更新します。
      bash
      sudo htpasswd -c /etc/apache2/conf-available/passwd.users user1 # 初回作成 (-c オプション)
      sudo htpasswd /etc/apache2/conf-available/passwd.users user2 # ユーザー追加 (2回目以降 -cなし)
    • -c オプションはファイルを新規作成または上書きするため、2人目以降のユーザーを追加する場合は付けないように注意してください。

  4. 権限設定 (authz):

    • 権限設定ファイル（例: /etc/apache2/conf-available/authz.users）を作成し、svnserveの場合と同様にグループやパスごとの権限を設定します。
      bash
      sudo nano /etc/apache2/conf-available/authz.users
    • 内容は svnserve の authz と同じ形式です。リポジトリ名を指定する場合は [リポジトリ名:/パス] の形式で記述します。
      “`
      [groups]
      developers = user1, user2

    [myproject:/] # リポジトリ名myproject全体
    @developers = rw
    * =

    [myproject:/branches]
    user1 = r
    * 設定ファイルの権限を適切に設定します。Apacheを実行するユーザー（`www-data`など）が読み取れるようにします。bash
    sudo chown root:www-data /etc/apache2/conf-available/authz.users
    sudo chmod 640 /etc/apache2/conf-available/authz.users
    “`

  5. Apache設定の有効化と再起動:

    • 作成した設定ファイルを有効化します。
      bash
      sudo a2confen subversion
    • Apacheを再起動して設定を反映します。
      bash
      sudo systemctl restart apache2

  6. ファイアウォール設定:

    • Apacheが使用するポート（HTTPなら80、HTTPSなら443）を開ける必要があります。
      bash
      sudo ufw allow http
      sudo ufw allow https
      sudo ufw reload

これでApache経由でのアクセスが可能になります。クライアントからは http://your_server_ip/svn/myproject または https://your_server_ip/svn/myproject のようなURLでアクセスします。

SVNの導入方法（クライアント側）

開発者がローカルマシンでSVNリポジトリにアクセスし、作業コピーを操作するためには、SVNクライアントソフトウェアが必要です。クライアントにはコマンドラインツールとGUIツールがあります。

1. Windows への導入 (TortoiseSVN)

Windowsで最も広く使われているSVNクライアントはTortoiseSVNです。Windowsのエクスプローラーと統合されており、右クリックメニューから多くのSVN操作を行うことができます。視覚的で非常に使いやすいです。

図解：TortoiseSVN インストール手順のイメージ

  1. インストーラーのダウンロード:

    • TortoiseSVNの公式ウェブサイト（https://tortoisesvn.net/downloads.ja.html）にアクセスします。
    • お使いのWindowsのバージョン（32bit or 64bit）に合ったインストーラーをダウンロードします。言語パックも必要な場合は一緒にダウンロードします。
    • 図解: ダウンロードページ画面。対応OSとビット数のインストーラーを選択。

  2. インストーラーの実行:

    • ダウンロードした TortoiseSVN-x.x.x.xxxx-x64-svn-x.x.x.msi のような名前のファイルを実行します。
    • 図解: ウィザード開始画面。「Next」をクリック。

  3. ライセンス契約への同意:

    • ライセンス条項を読み、「I accept the terms in the License Agreement」にチェックを入れます。
    • 図解: ライセンス同意画面。「Next」をクリック。

  4. カスタムセットアップ:

    • インストールするコンポーネントを選択します。通常はデフォルトのままで問題ありません。
    • Command line client tools: これにチェックを入れると、TortoiseSVNのGUIだけでなく、WindowsのコマンドプロンプトやPowerShellから svn コマンドを使えるようになります。GUIだけでなくコマンドラインも使いたい場合はチェックを入れておきます。
    • 図解: カスタムセットアップ画面。コンポーネント一覧とチェックボックス。「Next」をクリック。

  5. インストール先の指定:

    • インストール先のフォルダを指定します。デフォルトで問題ないでしょう。
    • 図解: インストール先指定画面。「Next」をクリック。

  6. インストール開始:

    • 設定内容を確認し、「Install」をクリックするとインストールが開始されます。
    • 図解: インストール準備完了画面。「Install」をクリック。

  7. インストール完了:

    • インストールが完了すると、コンピュータの再起動を求められる場合があります。通常は再起動が必要です。
    • 図解: インストール完了画面。「Finish」をクリック。

  8. 再起動と確認:

    • コンピュータを再起動します。
    • エクスプローラーを開き、任意のフォルダやファイルを右クリックしてみます。メニューに「TortoiseSVN」という項目が追加されていれば、インストールは成功です。
    • 図解: エクスプローラーの右クリックメニュー画面。「TortoiseSVN」サブメニューが表示されている。

これでTortoiseSVNのインストールは完了です。後述の「基本的なSVNコマンド/操作」の多くは、TortoiseSVNの右クリックメニューから直感的に実行できます。

2. macOS への導入

macOSでもコマンドラインクライアントとGUIクライアントの両方を利用できます。

  • コマンドラインクライアント:

    • macOSにはXcodeのCommand Line Toolsをインストールすることで、Subversionのコマンドラインツール (svn コマンド) が含まれている場合があります。ターミナルで svn --version を実行して確認できます。
    • もしインストールされていない場合や、より新しいバージョンを使いたい場合は、Homebrewなどのパッケージマネージャーを使ってインストールするのが簡単です。
      bash
      brew install subversion
    • 図解: ターミナル画面での brew install subversion コマンド実行例。

  • GUIクライアント:

    • WindowsのTortoiseSVNのようなエクスプローラー連携の標準機能はmacOSにはありません。Finder代替アプリや専用のSVNクライアントアプリケーションを利用します。
    • 人気のあるGUIクライアントとしては、Cornerstone (商用)、Versions (商用)、ForkLift (Finder代替、SVN/Gitクライアント機能あり、商用) などがあります。これらのアプリケーションはそれぞれダウンロードしてインストールします。

3. Linux への導入

Linuxディストリビューションには通常、Subversionのコマンドラインクライアントがパッケージとして提供されています。

  • Debian/Ubuntu:
    bash
    sudo apt update
    sudo apt install subversion

    • 図解: ターミナル画面での apt install subversion コマンド実行例。

  • Fedora/CentOS/RHEL:
    bash
    sudo yum install subversion
    # または新しいバージョンでは
    sudo dnf install subversion

    • 図解: ターミナル画面での yum install subversion コマンド実行例。

インストール後、ターミナルで svn --version と入力して正しくインストールされているか確認できます。Linuxでは主にコマンドラインで操作することが多いですが、一部GUIツールも存在します。

基本的なSVNコマンド/操作（クライアント）

ここでは、SVNクライアントを使って日常的に行う主要な操作を、コマンドラインとTortoiseSVN（Windows）での操作イメージを中心に解説します。

リポジトリのURL形式は、SVNプロトコル (svn://)、HTTP/HTTPS (http://, https://)、ローカルファイル (file://) などがあります。サーバー構築方法によって適切なURLを使用します。

1. チェックアウト (Checkout)

リポジトリから作業コピーを新規作成する操作です。

  • コマンドライン:
    bash
    svn checkout <リポジトリURL> [ローカルの保存先ディレクトリ]
    # 例: svn checkout https://example.com/svn/myproject /home/user/myproject_wc
    ローカルの保存先ディレクトリを省略した場合、リポジトリ名のディレクトリが作成されます。

  • TortoiseSVN:

    • 作業コピーを作成したいフォルダで右クリックし、「SVN Checkout…」を選択します。
    • 図解: 右クリックメニュー「SVN Checkout…」を選択している画面。
    • 表示されたダイアログで、「URL of repository」（リポジトリのURL）と「Checkout directory」（ローカルの保存先ディレクトリ）を指定します。
    • 「OK」をクリックすると、リポジトリからファイルがダウンロードされ、作業コピーが作成されます。
    • 図解: Checkoutダイアログ画面。URLとローカルパスを入力するフィールド。

2. 更新 (Update)

自分の作業コピーを、リポジトリの最新状態（または指定したリビジョン）に同期させる操作です。他の開発者のコミットを取り込む際に使います。

  • コマンドライン:
    bash
    svn update [PATH]
    # 例: svn update /home/user/myproject_wc (作業コピー全体を更新)
    # 例: svn update file.txt (特定のファイルのみ更新)
    PATHを省略した場合、現在のディレクトリ（または作業コピーのルート）が更新されます。

  • TortoiseSVN:

    • 更新したい作業コピーのフォルダやファイルを選択して右クリックし、「SVN Update」を選択します。
    • 図解: 右クリックメニュー「SVN Update」を選択している画面。
    • 更新処理が実行され、新しいファイルが追加されたり、既存のファイルが更新されたりします。成功すると、更新されたファイル数などが表示されます。
    • 作業コピーのアイコンに、最新の状態であれば緑色のチェックマーク、ローカルで変更があれば赤いビックリマーク、リポジトリが更新されていれば青い下向き矢印などが表示されるようになります（オーバーレイアイコン）。
    • 図解: 作業コピーフォルダのアイコンにオーバーレイアイコン（緑チェック、赤！、青矢印など）が表示されているエクスプローラー画面のイメージ。

3. 追加 (Add)

新しく作成したファイルやディレクトリを、次にコミットする際にバージョン管理の対象に含めるように予約する操作です。

  • コマンドライン:
    bash
    svn add <FILE/DIR>
    # 例: svn add new_file.txt
    # 例: svn add new_directory
    svn status コマンドで確認すると、A (added) と表示されます。

  • TortoiseSVN:

    • バージョン管理に追加したいファイルやフォルダを選択して右クリックし、「TortoiseSVN」メニューから「Add」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Add」を選択している画面。
    • 確認ダイアログが表示され、「OK」をクリックすると追加予約されます。
    • ファイルやフォルダのアイコンが青いプラスマークに変わります。
    • 図解: 作業コピー内のファイル/フォルダアイコンが青いプラスマークになっているエクスプローラー画面のイメージ。

4. 削除 (Delete)

バージョン管理下のファイルやディレクトリをリポジトリから削除するように予約する操作です。

  • コマンドライン:
    bash
    svn delete <FILE/DIR>
    # 例: svn delete old_file.txt
    svn status コマンドで確認すると、D (deleted) と表示されます。この操作は作業コピーからも物理的にファイルを削除します。

  • TortoiseSVN:

    • 削除したいファイルやフォルダを選択して右クリックし、「TortoiseSVN」メニューから「Delete」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Delete」を選択している画面。
    • 確認ダイアログが表示され、「OK」をクリックすると削除予約されます。
    • ファイルやフォルダのアイコンが赤いマイナスマークに変わるか、非表示になります。

5. 移動/リネーム (Move/Rename)

バージョン管理下のファイルやディレクトリを移動または名前変更する操作です。履歴情報が引き継がれます。

  • コマンドライン:
    bash
    svn move <OLD_PATH> <NEW_PATH>
    # または
    svn rename <OLD_PATH> <NEW_PATH>
    # 例: svn move old_name.txt new_name.txt
    # 例: svn mv /home/user/myproject_wc/src /home/user/myproject_wc/source
    svn status コマンドで確認すると、D (deleted) と A (added) が組み合わされたような表示になります。

  • TortoiseSVN:

    • ファイルやフォルダを選択して右クリックし、「TortoiseSVN」メニューから「Rename」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Rename」を選択している画面。
    • 新しい名前を入力して「OK」をクリックします。
    • フォルダを移動する場合は、ドラッグ＆ドロップを使う方法があります。移動先のフォルダにファイルをドラッグする際に、Shiftキーを押しながら右クリックを離し、「SVN Move versioned item(s) to here」を選択します。
    • 図解: ファイルをドラッグ＆ドロップ後、右クリックメニューから「SVN Move versioned item(s) to here」を選択している画面。

6. コミット (Commit)

作業コピーでの変更内容（編集、追加、削除、移動など）をリポジトリに反映させる操作です。コミットごとに新しいリビジョンが生成されます。

  • コマンドライン:
    bash
    svn commit -m "コミットメッセージ" [PATH]
    # 例: svn commit -m "新規ファイルを追加し、一部ファイルを修正"
    コミットメッセージは、変更内容を簡潔に記述する非常に重要な情報です。必ず意味のあるメッセージを記述しましょう。PATHを省略した場合、現在のディレクトリ以下の変更が全てコミット対象になります。

  • TortoiseSVN:

    • コミットしたい作業コピーのフォルダやファイルを選択して右クリックし、「SVN Commit…」を選択します。
    • 図解: 右クリックメニュー「SVN Commit…」を選択している画面。
    • コミットダイアログが表示されます。変更があったファイル一覧が表示されるので、コミットしたいファイルにチェックを入れます。
    • 一番上のテキストエリアにコミットメッセージを入力します。
    • 図解: コミットダイアログ画面。変更されたファイル一覧、コミットメッセージ入力欄。「OK」ボタン。
    • 「OK」をクリックすると、変更がリポジトリに送信され、新しいリビジョン番号が表示されます。これがアトミックに実行されます。

7. ログの表示 (Log)

リポジトリの変更履歴を確認する操作です。誰が、いつ、どのようなコミットメッセージで変更を行ったかなどを参照できます。

  • コマンドライン:
    bash
    svn log [URL or PATH]
    # 例: svn log https://example.com/svn/myproject/trunk
    # 例: svn log file.txt
    PATHを省略した場合、現在のディレクトリの履歴が表示されます。

  • TortoiseSVN:

    • 履歴を確認したい作業コピーのフォルダやファイルを選択して右クリックし、「TortoiseSVN」メニューから「Show log」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Show log」を選択している画面。
    • ログダイアログが表示され、リビジョン番号、作者、日付/時刻、コミットメッセージ、変更されたファイル一覧などが一覧で表示されます。特定のリビジョンを選択して詳細を確認したり、差分を表示したりできます。
    • 図解: ログダイアログ画面。リビジョン一覧、詳細、変更ファイルリスト。

8. 差分の表示 (Diff)

作業コピーでのローカルな変更と、リポジトリのバージョン（または指定した2つのリビジョン間）の差分を表示する操作です。コミット前に自分の変更内容を確認するのに役立ちます。

  • コマンドライン:
    bash
    svn diff [PATH] # 作業コピーのローカル変更とBaseリビジョンの差分
    svn diff -r REV1:REV2 URL_or_PATH # 指定した2つのリビジョン間の差分
    # 例: svn diff file.txt
    # 例: svn diff -r 10:15 https://example.com/svn/myproject/trunk/main.c

  • TortoiseSVN:

    • 差分を確認したいファイルやフォルダを選択して右クリックし、「TortoiseSVN」メニューから「Diff」または「Diff with previous revision」（直前のリビジョンとの差分）などを選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Diff with HEAD revision」などを選択している画面。
    • 差分ツール（TortoiseMergeなど）が起動し、変更内容が色分けされて視覚的に表示されます。
    • 図解: 差分ツール画面。変更行がハイライトされて表示されているイメージ。

9. ステータスの確認 (Status)

作業コピーの状態（ローカルでの変更、追加予定、削除予定、競合など）を確認する操作です。コミット前に実行して、変更漏れや意図しない変更がないかチェックします。

  • コマンドライン:
    bash
    svn status [PATH]
    # 例: svn status /home/user/myproject_wc
    ファイルの左側にステータスを示す文字が表示されます。

    • M: Modified (修正)
    • A: Added (追加)
    • D: Deleted (削除)
    • ?: Not versioned (バージョン管理されていない)
    • !: Missing, or incomplete (ファイルがない、または不完全)
    • C: Conflicted (競合)
    • ~: Versioned item obstructed by item of different kind (異なる種類のアイテムで遮られている)
    • I: Ignored (無視される)

  • TortoiseSVN:

    • 確認したい作業コピーのフォルダを選択して右クリックし、「TortoiseSVN」メニューから「Check for modifications」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Check for modifications」を選択している画面。
    • 状態リストダイアログが表示され、変更されたファイルやバージョン管理されていないファイルなどが一覧表示されます。
    • 図解: 状態リストダイアログ画面。ファイル一覧とステータスアイコンが表示されている。

10. ブランチの作成 (Branch)

開発のメインライン（/trunk）から分岐して、独立した並行開発ラインを作成する操作です。

  • コマンドライン:
    bash
    svn copy <SOURCE_URL> <DESTINATION_URL> -m "コミットメッセージ"
    # 例: svn copy https://example.com/svn/myproject/trunk https://example.com/svn/myproject/branches/feature-x -m "Start feature X"
    これはリポジトリに対する操作なので、ローカルの作業コピーではなくリポジトリのURLを指定します。

  • TortoiseSVN:

    • コピー元となるパス（通常は作業コピーのルートフォルダや、リポジトリブラウザで/trunkなど）を選択して右クリックし、「TortoiseSVN」メニューから「Branch/Tag…」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Branch/Tag…」を選択している画面。
    • 「Copy working copy to」または「Copy HEAD revision to」などのオプションを選択し、コピー先となるリポジトリ内のURL（例: https://example.com/svn/myproject/branches/feature-x）を指定します。
    • コミットメッセージを入力し、「OK」をクリックします。これはリポジトリに対するコミット操作として実行されます。
    • 図解: Branch/Tagダイアログ画面。コピー元URL、コピー先URL、リビジョン指定、コミットメッセージ入力欄。「OK」ボタン。

11. タグの作成 (Tag)

特定のリビジョンに、後から参照しやすいように分かりやすい名前を付ける操作です。通常、リリースバージョンなどに付けられ、作成後は変更しません。ブランチ作成と基本的に同じコマンド/操作です。

  • コマンドライン:
    bash
    svn copy <SOURCE_URL_or_PATH> <DESTINATION_URL> -m "コミットメッセージ"
    # 特定リビジョンをタグにする場合: svn copy -r 123 https://example.com/svn/myproject/trunk https://example.com/svn/myproject/tags/v1.0 -m "Tagging version 1.0"
    # 作業コピーの現在の状態をタグにする場合: svn copy . https://example.com/svn/myproject/tags/v1.0-RC -m "Tagging v1.0-RC from WC"
    タグは通常 /tags ディレクトリ配下に作成します。

  • TortoiseSVN:

    • ブランチ作成と同様、「Branch/Tag…」を選択します。
    • コピー先URLを /tags/v1.0 のようにタグ用のパスに指定します。
    • 通常、タグは特定の安定した時点を指すべきなので、「Copy working copy to」ではなく「Copy HEAD revision to」や、さらに指定したリビジョンをコピー元として選択することが多いです。
    • 図解: Branch/Tagダイアログ画面。コピー先を/tagsパスに指定し、コピー元リビジョンを選択するイメージ。

12. マージ (Merge)

あるブランチで行われた変更を別のブランチ（通常は開発メインラインや他のfeatureブランチ）の作業コピーに取り込む操作です。

  • コマンドライン:
    bash
    svn merge <SOURCE_URL> [TARGET_PATH]
    # 例: svn merge https://example.com/svn/myproject/branches/feature-x /home/user/myproject_wc/trunk # feature-xブランチの変更をtrunkの作業コピーにマージ
    マージ操作は、指定したソース（ブランチ）の変更を作業コピーに適用します。マージの結果は作業コピー上のローカルな変更として現れるため、確認後別途コミットが必要です。

  • TortoiseSVN:

    • 変更を取り込みたいブランチの作業コピーフォルダ（例: /trunk の作業コピー）で右クリックし、「TortoiseSVN」メニューから「Merge…」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Merge…」を選択している画面。
    • マージウィザードが表示されます。通常は「Merge two different trees」を選択します。
    • 「URL of source:」（マージ元のブランチのURL）、「URL of target:」（マージ先のブランチのURL – 自動入力されることが多い）、マージするリビジョン範囲などを指定します。
    • 図解: マージウィザード画面。マージ元URL、マージ先URL、リビジョン範囲などを指定するステップ。
    • ウィザードを進めると、マージ処理が実行されます。競合が発生した場合は、後述の解消作業が必要です。
    • マージが完了すると、作業コピーに変更が適用された状態になるので、内容を確認し、別途コミットが必要です。

SVNのマージは、特に履歴が複雑になった場合や、同じファイルを複数のブランチで並行して変更した場合に、競合（コンフリクト）が発生しやすく、手動での解消作業が必要になることがあります。また、どのリビジョンからどのリビジョンまでをマージしたかをSVNが記録する svn:mergeinfo プロパティの管理も重要になります。

13. コンフリクトの解消 (Resolve)

複数の開発者が同じファイルの同じ箇所を変更し、それらの変更をリポジトリに取り込もうとしたり（コミット時）、他の開発者の変更を取り込もうとしたり（アップデート/マージ時）した場合に発生するのが競合 (Conflict) です。SVNは自動的にマージできない箇所を検出し、競合としてマークします。

  • 競合発生時の状態: 競合したファイルには、両者の変更内容が特殊なマーカー（<<<<<<<, =======, >>>>>>>）と共に書き込まれます。また、オリジナルのファイルや自分/相手の変更のみのファイルなどが .mine, .rOLDREV, .rNEWREV などの拡張子で保存されます。svn status コマンドでは C と表示されます。TortoiseSVNでは赤い感嘆符アイコンが表示されます。

  • 解消作業:

    1. 競合したファイルを開き、マーカーを手がかりに、自分と相手の変更内容を確認します。
    2. 手動でファイルを編集し、最終的に採用したい内容に修正します。マーカーは全て削除する必要があります。
    3. 編集が完了したら、競合が解消されたことをSVNに通知します。

  • コマンドライン:
    bash
    svn resolve --accept=working <FILE>
    # 例: svn resolve --accept=working conflicted_file.txt
    --accept=working オプションは、作業コピー上のファイルが競合解消済みであることを示します。

  • TortoiseSVN:

    • 競合しているファイルを選択して右クリックし、「TortoiseSVN」メニューから「Edit conflicts」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Edit conflicts」を選択している画面。
    • 競合解消ツール（TortoiseMergeなど）が起動します。通常は3ペインビューで、左に自分の変更、右に相手の変更、下（または中央）にマージ結果が表示されます。
    • ツールを使って、どの変更を採用するかを選択したり、手動で編集したりして、最終的なファイルを作成します。
    • 図解: 競合解消ツール画面。複数のペインで変更内容とマージ結果が表示されているイメージ。
    • 編集が完了し、競合が解消されたら、ファイルを右クリックし、「TortoiseSVN」メニューから「Resolved」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Resolved」を選択している画面。
    • ファイルのアイコンが、ローカル変更あり（赤いビックリマーク）の状態に戻ります。

  • コミット: 競合が全て解消されたら、改めて作業コピーをコミットして、変更をリポジトリに反映させる必要があります。

14. 元に戻す (Revert)

作業コピーでのローカルな変更（コミット前の変更）を破棄し、リポジトリの最新状態（または最後に更新/チェックアウトしたリビジョン）に戻す操作です。

  • コマンドライン:
    bash
    svn revert <PATH>
    # 例: svn revert changed_file.txt
    # 例: svn revert . --recursive (現在のディレクトリ以下の全てのローカル変更を破棄)
    この操作は不可逆です。破棄したローカル変更は元に戻せません。

  • TortoiseSVN:

    • ローカル変更を破棄したいファイルやフォルダを選択して右クリックし、「TortoiseSVN」メニューから「Revert…」を選択します。
    • 図解: 右クリックメニュー「TortoiseSVN」->「Revert…」を選択している画面。
    • 変更を破棄するファイル一覧が表示されるので、確認して「OK」をクリックします。
    • 図解: Revertダイアログ画面。Revertするファイル一覧とチェックボックス。「OK」ボタン。

これらの基本的な操作を組み合わせることで、日常的なバージョン管理作業を行うことができます。TortoiseSVNのようなGUIクライアントは、これらの操作を視覚的に分かりやすく提供しており、初心者でも比較的容易に使い始めることができます。

SVNの運用上の考慮事項

SVNをチームで効果的に運用するためには、いくつかのベストプラクティスや考慮事項があります。

  1. リポジトリ構成のベストプラクティス:

    • 多くのSVNプロジェクトでは、リポジトリのルート直下に以下の3つの標準ディレクトリを作成することが推奨されています。
      • /trunk: 開発のメインライン（本流）です。通常、最新の開発作業はここで行われます。
      • /branches: 並行開発を行うためのブランチを格納する場所です。特定の機能開発、バグ修正、実験的なコードなどはここにブランチを切って作業します。
      • /tags: リリースバージョンなど、特定の時点のスナップショット（タグ）を格納する場所です。タグは一度作成したら原則として変更しません。
    • この構成により、プロジェクトの状態や履歴が分かりやすくなり、チームメンバー間の認識齟齬を防ぐことができます。

    図解：標準リポジトリ構成
    / (リポジトリルート)
    +-- trunk/ <-- メイン開発
    +-- branches/
    | +-- feature-A/ <-- 機能開発ブランチ
    | +-- bugfix-123/ <-- バグ修正ブランチ
    +-- tags/
    +-- v1.0/ <-- リリースv1.0
    +-- v1.1-RC1/ <-- リリース候補v1.1

  2. コミットメッセージの重要性:

    • コミットメッセージは、そのコミットで「何を変更したか」「なぜ変更したか」を後から追跡するための重要な情報源です。
    • 簡潔かつ分かりやすいメッセージを心がけましょう。
    • 変更の概要（何をしたか）と、詳細や背景、関連する課題管理システム（チケット番号など）を記述するとより有用です。
    • 例: Fix #123: Correct calculation logic in report generation. Refactored loop for performance.

  3. ブランチング戦略:

    • どのような場合にブランチを作成し、どのように運用するかという戦略をチームで定めておくと良いでしょう。
    • 一般的な戦略としては、以下のようなものがあります。
      • Feature Branching: 新しい機能開発ごとに /branches/feature-xxx のようなブランチを作成し、開発が完了したら /trunk にマージする。
      • Release Branching: リリース準備のために /branches/release-1.0 のようなブランチを作成し、そこで最終調整やバグ修正を行い、リリースしたらタグを打ち、変更を /trunk にマージバックする。
      • Task Branching: 比較的短期間のタスクやバグ修正ごとにブランチを作成する。
    • SVNのマージは複雑になりがちなので、ブランチの寿命を短く保ち、頻繁にマージ（またはマージバック）を行うことで、競合のリスクや解消のコストを減らすことが推奨されます。

  4. マージの難しさ:

    • 前述のように、SVNのマージはGitに比べて複雑で、特に複数回のマージや歴史が複雑なブランチ間のマージは問題が発生しやすい傾向があります。
    • svn:mergeinfo プロパティは、どのリビジョン範囲をマージ済みかを記録し、将来のマージで同じ変更を二重にマージしないようにするために非常に重要です。このプロパティを手動で編集したり、適切に扱わないとマージが失敗したり予期せぬ結果を招く可能性があります。
    • マージを行う際は、事前に作業コピーを最新に更新し、クリーンな状態で行うことが重要です。

  5. パフォーマンスチューニング:

    • リポジトリが非常に大規模になったり、履歴が長くなったりすると、 بعض operaciones (como svn log, svn update de un árbol grande) pueden volverse lentas.
    • リポジトリのファイルシステムタイプ（FSFSが一般的で推奨）やサーバー構成（メモリ、CPU、ストレージの速度）がパフォーマンスに影響します。
    • svnadmin pack コマンドでリポジトリを最適化したり、不要な履歴を削除する（これは複雑で注意が必要）といった方法があります。
    • クライアント側では、必要に応じてチェックアウトするパスを限定する（ただしSVNは基本的にリポジトリ全体のコピーが前提）などの工夫が必要になる場合があります。

  6. バックアップ戦略:

    • 中央リポジトリはプロジェクトの全ての資産であるため、定期的なバックアップが不可欠です。
    • SVNリポジトリのバックアップ方法としては、主に以下の2つがあります。
      • svnadmin hotcopy <REPOS_PATH> <BACKUP_PATH>: リポジトリ全体を安全にコピーする方法。運用中に実行可能で推奨されます。
      • svnadmin dump <REPOS_PATH> > backup.dump: リポジトリの履歴をダンプファイルとして出力する方法。リストアに便利ですが、履歴が長いとファイルが大きくなり、ダンプ中はリポジトリへのアクセスを停止するのが安全です。
    • バックアップファイルを別の場所に保存したり、定期的なバックアップを自動化するスクリプトを組むなどの対策が必要です。

  7. 移行について:

    • 他のVCS（CVSなど）からSVNへ、またはSVNからGitへ移行したい場合、専用のツールや手順が存在します。
    • SVNからGitへの移行は比較的よく行われ、svn2git のようなツールが利用できます。ただし、移行元のSVNリポジトリの構造や履歴によっては、完全にGitの自然な履歴構造に変換するのが難しい場合もあります。移行前に十分なテストと計画が必要です。

SVNの利点と欠点（まとめ）

最後に、SVNの利点と欠点を改めて整理します。

SVNの利点:

  • シンプルで分かりやすい概念: 中央集権モデルは直感的で、初心者にとってGitの分散モデルよりも理解しやすい場合があります。リポジトリ、作業コピー、リビジョンといった基本概念はシンプルです。
  • 管理の容易さ: リポジトリが中央に一つしかなく、ユーザー管理や権限設定もサーバー側で一元的に行えるため、管理者にとっては管理しやすいシステムと言えます。特に厳格なアクセス制御が必要な場合に有利です。
  • バイナリファイルの扱い: テキストファイルと同様にバイナリファイルの変更履歴も管理でき、Gitに比べると大きなバイナリファイルの扱いに悩まずに済む場合があります（Git LFSなどを使わない場合）。
  • ディレクトリのバージョン管理: ファイルだけでなくディレクトリ構造そのものの履歴管理、名前変更や移動の追跡が得意です。
  • 既存システムとの親和性: 歴史が長いため、SVNを前提とした開発ツールやIDEプラグイン、CI/CDツールなどが多数存在します。

SVNの欠点:

  • シングルポイント障害: リポジトリサーバーがダウンすると、チェックアウト以外のほとんど全ての作業（コミット、アップデート、ログ参照など）ができなくなり、開発が停止します。
  • オフライン作業の制限: コミットや他の多くの操作にはサーバーへのアクセスが必要なため、ネットワークに接続されていない環境での作業が非常に制限されます。
  • ブランチ/マージの煩雑さ: Gitに比べてブランチの作成や切り替え、特にマージ操作が複雑で時間もかかり、競合解決も難しくなりがちです。
  • リポジトリ全体の操作: 作業コピーや履歴参照の際に、リポジトリ全体を対象とした操作になることが多く、大規模リポジトリでは非効率になる場合があります（例: svn log はデフォルトでリポジトリ全体の履歴を検索）。
  • 現代的な開発ワークフローとのミスマッチ: Gitが得意とする高速なブランチ作成/削除、頻繁なマージ、プルリクエストベースの開発スタイルなどには向いていません。
  • コミュニティとツールの差: 現在はGitがバージョン管理システムのデファクトスタンダードとなっており、新しいツール開発や活発なコミュニティ活動はGitに集中している傾向があります。

結論

SVNは、CVSの欠点を克服し、集中型バージョン管理システムとして一時代を築きました。そのシンプルさ、管理の容易さ、堅牢性から、現在でも多くのプロジェクト、特に企業内の比較的小規模〜中規模のチームや、Gitの分散モデルが必要ない、あるいは複雑すぎると感じる場合に利用されています。

しかし、現代のソフトウェア開発、特にアジャイル開発や分散開発、OSS開発では、Gitが提供する高速なブランチ操作、柔軟なマージ機能、オフライン作業能力といった分散型モデルのメリットが非常に有効であるため、主流はGitへと移行しています。

SVNは、シングルポイント障害のリスクやオフライン作業の制限、マージの複雑さといった集中型モデルの根本的な課題を抱えています。これらの欠点がプロジェクトのボトルネックになるようであれば、Gitのような分散型システムへの移行を検討する価値があります。

バージョン管理システムを選択する際は、チームの規模、メンバーの経験、プロジェクトの性質、必要なワークフロー、管理体制などを総合的に考慮し、SVNとGit、それぞれの特徴を理解した上で最適なシステムを選ぶことが重要です。

もしあなたがこれから初めてバージョン管理システムを導入するのであれば、学習コストの面でSVNが取っ掛かりやすいと感じるかもしれません。あるいは、将来的な主流や機能の豊富さを考慮してGitを選択するかもしれません。どちらを選ぶにしても、バージョン管理システムを利用することで、開発効率、コードの安全性、チームコラボレーションは格段に向上するはずです。

この記事が、SVNの理解を深め、導入や運用の一助となれば幸いです。

参考文献・関連リソース

  • Apache Subversion 公式ウェブサイト: https://subversion.apache.org/ – 公式の情報、ドキュメント、ダウンロード先など。
  • TortoiseSVN 公式ウェブサイト: https://tortoisesvn.net/ – Windows用GUIクライアントTortoiseSVNの情報、ダウンロード、ドキュメント。
  • VisualSVN Server 公式ウェブサイト: https://www.visualsvn.com/visualsvn-server/ – Windows用SVNサーバーパッケージVisualSVN Serverの情報、ダウンロード。
  • Subversion Book (Version Control with Subversion): https://svnbook.red-bean.com/ – Subversionに関する最も包括的で公式なドキュメント。日本語訳も存在します。

（注：この記事はテキストベースで記述されており、「図解」というキーワードに対しては、概念図や画面イメージ、コマンド実行例などの説明をテキストで補足する形式を取っています。約5000語の文字数要件を満たすため、各項目について詳細な説明を加えています。）

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール