SVNの使い方入門｜初心者向け基本コマンド解説

By /

SVNの使い方入門｜初心者向け基本コマンド解説

ソフトウェア開発やドキュメント作成において、「バージョン管理」は不可欠なプロセスです。どのファイルがいつ、誰によって、どのように変更されたのかを記録し、必要に応じて過去の状態に戻したり、複数の人が同時に作業したりすることを可能にします。このバージョン管理を実現するためのツールの一つが、SVN（Subversion）です。

SVNは、かつてバージョン管理システムのデファクトスタンダードとして広く利用されていました。現在ではGitなどの分散型バージョン管理システムが主流になりつつありますが、レガシープロジェクトや特定の企業文化においては、依然としてSVNが現役で使われています。また、バージョン管理の基本的な考え方を学ぶ上で、SVNは非常に理解しやすいシステムです。

この記事は、バージョン管理の経験がない初心者の方や、SVNを初めて使う方を対象に、SVNの基本的な概念から、コマンドラインを使った操作方法までを徹底的に解説します。この記事を読めば、SVNを使ったバージョン管理の第一歩を踏み出し、日々の開発や作業に役立てられるようになるでしょう。

1. はじめに：なぜバージョン管理が必要なのか？

あなたがもし、重要なドキュメントやプログラムのソースコードを作成しているとします。作業中に「やっぱりあの時の状態に戻したいな」「この変更がうまくいかなかったから、変更前の状態に戻そう」と思うことはよくあります。また、「〇〇_最終版.doc」「〇〇_最終版_本当に最終版.doc」「〇〇_最終版_田中さん確認済み.doc」のように、ファイル名を変更しながら履歴を管理した経験はありませんか？

このような手動での管理は、非常に手間がかかる上に、間違いも起こりやすく、どのファイルが最新なのか、どこが変更されたのかが分かりにくくなります。特に複数人で一つのプロジェクトに取り組む場合、誰がいつどのファイルを変更したのか、他の人の変更を取り込むにはどうすればいいのか、といった問題が発生し、混乱を招きがちです。

ここでバージョン管理システムの出番です。バージョン管理システムは、これらの問題を解決するために設計されたツールです。

  • 履歴管理: ファイルの全ての変更履歴を自動的に記録します。いつ、誰が、どのような変更を加えたのかが一目で分かります。
  • 過去への復元: 任意の時点の状態に簡単に戻すことができます。
  • 差分の表示: 現在の状態と過去の特定時点の状態との間で、どこがどのように変更されたのかを明確に表示できます。
  • 並行開発: 複数人が同時に同じファイルやプロジェクトを安全に編集し、後でそれらの変更を統合（マージ）することができます。

バージョン管理システムを利用することで、作業の効率が格段に向上し、ミスを減らし、チームでの共同作業がスムーズになります。SVNは、このバージョン管理システムの一種なのです。

2. バージョン管理システムの種類

バージョン管理システムには、主に2つのタイプがあります。

2.1 集中型バージョン管理システム (CVCS: Centralized Version Control System)

特徴:
* すべてのファイルのバージョン履歴を管理する「リポジトリ」が、中央のサーバーに一つだけ存在します。
* ユーザーは、この中央リポジトリからファイルの最新版を取得（チェックアウト/アップデート）し、自分のローカル環境（作業コピー）で作業を行います。
* 変更内容は、中央リポジトリに送信（コミット）することで共有されます。

利点:
* 管理が比較的容易です。中央リポジトリだけを管理すれば良いため、システム管理者の負担が少ないです。
* ユーザーが他のユーザーの作業状況を把握しやすいです（中央リポジトリを見れば良いため）。

欠点:
* 中央サーバーがダウンすると、バージョン管理システム全体の利用ができなくなります。
* ネットワークに接続していないと、コミットやアップデートといった操作ができません。
* 自分のローカル環境には、最新の状態しか保持されません（過去の履歴は中央リポジトリに問い合わせる必要があります）。

SVN（Subversion）は、この集中型バージョン管理システムの代表例です。

2.2 分散型バージョン管理システム (DVCS: Distributed Version Control System)

特徴:
* 各ユーザーのローカル環境に、リポジトリの全ての履歴が丸ごと複製されます。
* ユーザーは、自分のローカルリポジトリに対してコミットを行います。
* 他のユーザーと変更を共有するには、ローカルリポジトリ間の連携（プッシュ/プル）が必要です。通常、共有のための中央リポジトリ（リモートリポジトリと呼ばれることが多い）を設けることが一般的です。

利点:
* ネットワークに接続していなくても、コミットや履歴の参照ができます。
* 中央サーバーがなくてもバージョン管理が可能です（ただしチーム開発では通常リモートリポジトリを用意します）。
* ローカルに完全なリポジトリがあるので、操作が高速です。
* 個人のブランチ（開発ライン）を簡単に作成し、試行錯誤できます。

欠点:
* 概念がCVCSより少し複雑です。
* リポジトリ全体を複製するため、ディスク容量を消費します。

GitやMercurial（Hg）は、分散型バージョン管理システムの代表例です。現在、多くの新しいプロジェクトではGitが選ばれる傾向にあります。

この記事では、集中型バージョン管理システムであるSVNに焦点を当てて解説します。

3. SVN (Subversion) とは

SVN（Subversion）は、Apache Software Foundationによって開発された集中型バージョン管理システムです。Apache Subversionとも呼ばれます。

SVNは、上記の集中型バージョン管理システムの特徴をそのまま持っています。プロジェクトの全ての履歴を一元的に管理する「リポジトリ」をサーバー上に置き、開発者（クライアント）はそこからファイルを取得して作業し、変更をリポジトリに反映させます。

SVNは、ファイルシステムのような単純な構造でバージョン管理を行うため、初心者にとって概念を理解しやすいという側面があります。また、ディレクトリの移動や名前変更、コピーといった操作も、バージョン管理下で正確に追跡できるのが特徴です。

4. SVNのインストール

SVNを使うためには、まずクライアントソフトウェアをインストールする必要があります。ここでは、主要なOSでのインストール方法を簡単に説明します。SVNにはコマンドラインツールとGUIツールがありますが、基本を学ぶ上ではコマンドラインツールから始めるのがおすすめです。GUIツールはコマンドの操作を視覚的に分かりやすくしてくれるもので、慣れてきたら利用すると良いでしょう。

4.1 コマンドラインツールのインストール

多くのOSでは、パッケージマネージャーを使って簡単にインストールできます。

  • Windows:
    Windowsには標準でSVNコマンドは含まれていません。インストーラーを使ってインストールする必要があります。最も一般的なのは CollabNet Subversion や VisualSVN からダウンロードする方法です。インストーラーの指示に従ってインストールしてください。インストール時に「コマンドラインツール」を含めるオプションを忘れずにチェックしてください。インストール後、システム環境変数のPathにSVNコマンドのディレクトリ（例: C:\Program Files\Subversion\bin）を追加すると、コマンドプロンプトやPowerShellからsvnコマンドが使えるようになります。

  • macOS:
    macOSには、Xcode Command Line Toolsに含まれる形でSVNコマンドがインストールされていることが多いです。ターミナルを開いてsvn --versionと入力し、バージョン情報が表示されればインストール済みです。もしインストールされていない場合は、Homebrewなどのパッケージマネージャーを使うのが最も簡単です。
    “`bash
    # Homebrewがインストールされていない場合はインストール
    # /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

    SVNをインストール

    brew install subversion
    “`

  • Linux (Debian/Ubuntu系):
    APTパッケージマネージャーを使います。
    bash
    sudo apt update
    sudo apt install subversion

  • Linux (Fedora/CentOS/RHEL系):
    YumまたはDNFパッケージマネージャーを使います。
    bash
    sudo yum install subversion
    # または
    sudo dnf install subversion

インストールが完了したら、ターミナル（またはコマンドプロンプト/PowerShell）を開いて以下のコマンドを実行し、バージョン情報が表示されることを確認してください。

bash
svn --version

4.2 よく使われるGUIツール

コマンドラインに慣れないうちは、GUIツールを使うのも良いでしょう。特にWindowsユーザーに人気なのは「TortoiseSVN」です。エクスプローラーに統合され、右クリックメニューからSVN操作ができます。

  • TortoiseSVN (Windows): https://tortoisesvn.net/ からダウンロードできます。インストールすると、ファイルやフォルダのアイコンにSVNの状態を示すマークが表示されるようになり、右クリックメニューにSVN関連の項目が追加されます。

  • SmartSVN (クロスプラットフォーム): https://www.smartsvn.com/ 高機能なGUIクライアントです。無料版と有料版があります。

  • IDEとの連携: EclipseやIntelliJ IDEAなどの多くの統合開発環境（IDE）は、SVNとの連携機能を標準で持っているか、プラグインとして提供しています。普段使っているIDEにSVN機能があれば、それを利用するのが最も効率的かもしれません。

この記事では、主にコマンドラインを使った操作方法を解説します。これは、SVNの仕組みを理解する上で最も基礎となり、GUIツールも内部的にはこれらのコマンドを実行しているためです。

5. SVNの基本概念

SVNコマンドを学ぶ前に、いくつかの重要な概念を理解しておく必要があります。

5.1 リポジトリ (Repository)

リポジトリは、プロジェクトの全てのファイルと、その全ての変更履歴が保管されている中央倉庫です。SVNにおけるバージョン管理の核となる部分です。通常、サーバー上の特定のディレクトリに配置されます。

リポジトリは通常、以下の標準的なディレクトリ構成を持ちます。

  • trunk: プロジェクトのメインの開発ラインです。通常、最新の安定版ではないにしろ、現在の開発作業の最先端が置かれます。
  • branches: 開発ラインから分岐して、特定の機能開発や実験的な変更を行うためのディレクトリです。
  • tags: 特定のリビジョン（後述）に名前を付けるためのディレクトリです。リリース版や重要な節目などに、その時点の状態を記録するために使われます。ここにあるファイルは通常変更されません。

このtrunk, branches, tagsという構成は必須ではありませんが、SVNを使う上での慣習となっており、多くのツールやコマンドがこの構造を前提としています。

リポジトリにアクセスするためには、プロトコルとパスを指定します。一般的なプロトコルは以下の通りです。

  • file:///path/to/repository: ローカルファイルシステム上のリポジトリにアクセスする場合。
  • svn://hostname/path/to/repository: SVN独自のプロトコル（通常svndserveプロセスが待ち受け）。認証機能など。
  • svn+ssh://hostname/path/to/repository: SSH経由で安全にSVNプロトコルを使う場合。
  • http://hostname/path/to/repository: ApacheなどのWebサーバー経由でWebDAV/DeltaVを使ってアクセスする場合。
  • https://hostname/path/to/repository: HTTPS経由で安全にアクセスする場合。

例: https://svn.example.com/myproject/trunk

5.2 作業コピー (Working Copy)

作業コピーは、リポジトリから特定の時点（通常は最新）のファイルやディレクトリを自分のローカルコンピューターにチェックアウト（取得）したものです。開発者は、この作業コピーでファイルの編集、追加、削除などの作業を行います。

作業コピー内の各ファイルやディレクトリは、その状態がSVNによって管理されています。隠しディレクトリ.svn（Windowsでは_svnという名前で表示されることもあります）が各ディレクトリに作成され、リポジトリとの関連情報や、最後にアップデート/チェックアウトした時のリビジョン情報などが格納されています。

5.3 リビジョン (Revision)

リビジョンは、リポジトリにおける変更履歴の単位です。リポジトリに対する変更（コミット）が行われるたびに、リビジョン番号が1つずつ増えていきます。リビジョン番号は、リポジトリ全体の状態を示すユニークなIDのようなものです。

例えば、リビジョン100は、リポジトリが100回目の変更を受けた後の状態を示します。いつでも任意のリビジョン番号を指定して、その時点のファイルやディレクトリの状態を取得したり、差分を確認したりできます。

5.4 コミット (Commit)

コミットとは、作業コピーで行った変更（ファイルの編集、追加、削除、移動など）を、中央リポジトリに送信して記録する操作です。コミットが成功すると、リポジトリのリビジョン番号が1つ増え、他の開発者もあなたの変更を参照できるようになります。

コミット時には、必ずその変更内容を説明する「コミットメッセージ」を記述する必要があります。良いコミットメッセージは、後から履歴を振り返る際に非常に重要になります。

5.5 アップデート (Update)

アップデートとは、他の開発者がリポジトリにコミットした変更を、自分の作業コピーに取り込む操作です。アップデートを実行することで、自分の作業コピーをリポジトリの最新の状態（または指定した任意のリビジョン）に更新できます。チーム開発では、他の人の変更を自分の作業に取り込むために頻繁に行います。

5.6 チェックアウト (Checkout)

チェックアウトとは、リポジトリからプロジェクト全体、またはその一部を初めて自分のローカルコンピューターに取得し、作業コピーを作成する操作です。通常、開発を始める際に一度だけ行います。

5.7 差分 (Diff)

差分とは、ある2つの状態（例: 作業コピーの状態とリポジトリの最新状態、または特定のリビジョン間）の間で、ファイルの内容がどのように異なるかを表示することです。どの行が追加され、どの行が削除/変更されたのかを確認できます。コミットする前に自分の変更内容を確認する際などに利用します。

5.8 ログ (Log)

ログとは、リポジトリまたは作業コピーの変更履歴（誰が、いつ、どのようなコミットメッセージで変更したか）を表示することです。過去の変更を追跡する際に利用します。

5.9 競合 (Conflict)

競合（コンフリクト）とは、複数人が同じファイルの同じ箇所を同時に変更し、SVNが自動的にそれらの変更を統合（マージ）できない状態のことです。例えば、AさんとBさんが同じファイルの10行目をそれぞれ異なる内容に編集してコミットしようとした場合などに発生します。競合が発生した場合、どちらの変更を採用するか、あるいは両方の変更を組み合わせるかなど、手動で修正作業（競合解消）を行う必要があります。

6. SVNの基本コマンド

それでは、SVNの基本的なコマンドの使い方を具体的に見ていきましょう。ここでは、コマンドラインを使った操作方法を説明します。

コマンドを実行する際は、基本的に作業コピーのルートディレクトリ、または操作したいファイルやディレクトリが存在する場所で実行します。

6.1 ヘルプを表示する (svn help)

SVNの各コマンドの使い方が分からない場合は、svn helpコマンドで確認できます。

  • SVNコマンド全体のリストを表示:
    bash
    svn help

  • 特定のコマンドの詳しい使い方を表示:
    bash
    svn help [コマンド名]
    例: svn help checkout と入力すると、checkoutコマンドの詳細な使い方が表示されます。

6.2 リポジトリから作業コピーを作成する (svn checkout または svn co)

リポジトリからプロジェクトのファイルを初めてローカルに取得し、作業を開始する際に使用します。

“`bash
svn checkout [リポジトリのURL] [作業コピーを作成するローカルパス（省略可）]

または短縮形

svn co [リポジトリのURL] [作業コピーを作成するローカルパス（省略可）]
“`

  • [リポジトリのURL]: チェックアウトしたいリポジトリ上の場所を指定します。通常は.../trunkや.../branches/my-featureなどを指定します。
  • [作業コピーを作成するローカルパス]: リポジトリの内容をチェックアウトして配置するローカルのディレクトリを指定します。省略した場合、リポジトリのURLの最後の部分と同じ名前のディレクトリがカレントディレクトリに作成されます。

実行例:

リポジトリのtrunkディレクトリの内容を、カレントディレクトリにmyprojectという名前のディレクトリとしてチェックアウトする場合。

bash
svn checkout https://svn.example.com/myproject/trunk myproject

リポジトリのtrunkディレクトリの内容を、カレントディレクトリにリポジトリ名（例: trunk）と同じ名前でチェックアウトする場合。

bash
svn checkout https://svn.example.com/myproject/trunk

チェックアウトが成功すると、指定したローカルパスにリポジトリのファイルやディレクトリが作成され、その中に隠しディレクトリ.svnが生成されます。これで、そのディレクトリはSVNの作業コピーとして管理されるようになります。

6.3 作業コピーを最新の状態に更新する (svn update または svn up)

他の人がリポジトリにコミットした変更を、自分の作業コピーに取り込む際に使用します。作業を開始する前や、自分の変更をコミットする前などに実行するのが一般的です。

“`bash
svn update [パス（省略可）]

または短縮形

svn up [パス（省略可）]
“`

  • [パス]: 更新したい作業コピー内の特定のファイルやディレクトリを指定します。省略した場合、カレントディレクトリ（とそのサブディレクトリ全て）が更新されます。作業コピーのルートディレクトリで実行することが多いです。

実行例:

カレントディレクトリを含む作業コピー全体をリポジトリの最新リビジョンに更新する場合。

bash
svn update

特定のファイルだけを最新に更新する場合。

bash
svn update my_document.txt

更新が実行されると、SVNはリポジトリの最新リビジョンと作業コピーの状態を比較し、差分があればその変更をダウンロードして作業コピーに適用します。この際、以下のようなステータスが表示されます。

  • U: 更新 (Updated)。リポジトリの変更がローカルに適用されました。
  • A: 追加 (Added)。他のユーザーによってファイルやディレクトリが追加されました。
  • D: 削除 (Deleted)。他のユーザーによってファイルやディレクトリが削除されました。
  • C: 競合 (Conflict)。他のユーザーの変更と自分の変更が競合しました。手動での解消が必要です。
  • G: マージ済 (Merged)。他のユーザーの変更が自動的に自分の変更とマージされました。
  • E: 存在しない外部参照を検出 (Existed)。外部定義されたファイル/ディレクトリが見つかりませんでした。

6.4 作業コピーの状態を確認する (svn status または svn st)

作業コピーにおいて、リポジトリに対してどのような変更が行われたか（あるいは行われていないか）を確認する際に使用します。

“`bash
svn status [パス（省略可）]

または短縮形

svn st [パス（省略可）]
“`

  • [パス]: 状態を確認したい作業コピー内の特定のファイルやディレクトリを指定します。省略した場合、カレントディレクトリ（とそのサブディレクトリ全て）の状態を表示します。

実行例:

作業コピー全体の状態を確認する場合。

bash
svn status

特定のディレクトリ以下の状態を確認する場合。

bash
svn status mydirectory/

svn statusの出力では、ファイルやディレクトリの先頭に1文字のコードが表示され、その状態を示します。主なコードは以下の通りです。

  • : 変更なし（クリーン）。
  • M: 変更あり（Modified）。ファイルの内容が変更されています。
  • A: 追加予定（Added）。svn addで追加登録されていますが、まだコミットされていません。
  • D: 削除予定（Deleted）。svn deleteで削除登録されていますが、まだコミットされていません。
  • R: 置換予定（Replaced）。削除してから同じパスに新しく追加されました（svn delete後にsvn add、またはsvn replace相当）。
  • C: 競合あり（Conflict）。アップデートやマージによって競合が発生しています。
  • ?: 未管理（Unversioned）。SVNの管理下にないファイルやディレクトリです。
  • !: 欠落または不完全（Missing / Incomplete）。作業コピーには存在しないが、SVN管理下にあると記録されているファイルやディレクトリです（手動で削除した場合など）。svn cleanupやsvn updateで解決できる場合があります。
  • ~: 型が違う（Obstructed）。作業コピーとリポジトリで、ファイルとディレクトリのように型が異なっています。

出力例:

M my_document.txt # my_document.txt は内容が変更されている
A new_file.txt # new_file.txt は追加登録されている
D old_file.txt # old_file.txt は削除登録されている
? temp_file.log # temp_file.log はSVN管理下にない

svn statusは、次に何をコミットするのかを確認するために非常に重要なコマンドです。

6.5 新しいファイルやディレクトリを追加登録する (svn add)

新しく作成したファイルやディレクトリを、次にコミットする際にリポジトリに追加するための登録を行います。

bash
svn add [ファイルまたはディレクトリのパス...]

  • [ファイルまたはディレクトリのパス...]: SVNの管理下に追加したいファイルやディレクトリを1つ以上指定します。

実行例:

新しく作成したnew_feature.cというファイルを追加登録する場合。

bash
svn add new_feature.c

dataというディレクトリと、その中にある全てのファイルやサブディレクトリを追加登録する場合。

bash
svn add data/

svn addを実行しても、すぐにリポジトリに変更が反映されるわけではありません。これはあくまで「次回のコミットでこれらのファイルを追加する」という登録です。svn statusを実行すると、追加登録されたファイルやディレクトリの先頭にAが表示されます。

6.6 ファイルやディレクトリを削除登録する (svn delete または svn del)

SVN管理下のファイルやディレクトリを削除し、次にコミットする際にリポジトリからも削除するための登録を行います。

“`bash
svn delete [ファイルまたはディレクトリのパス…]

または短縮形

svn del [ファイルまたはディレクトリのパス…]
“`

  • [ファイルまたはディレクトリのパス...]: SVNの管理下から削除したいファイルやディレクトリを1つ以上指定します。

実行例:

obsolete_script.pyというファイルを削除登録する場合。

bash
svn delete obsolete_script.py

temp_filesというディレクトリとその内容全てを削除登録する場合。

bash
svn delete temp_files/

svn deleteを実行すると、ローカルの作業コピーからそのファイルやディレクトリが削除されます。そして、削除されたという情報がコミット待ちの状態になります。svn statusを実行すると、削除登録されたファイルやディレクトリの先頭にDが表示されます。

注意: 手動でファイルを削除してからsvn statusを実行すると、そのファイルは!（欠落）と表示されます。この状態をコミットでリポジトリに反映させるには、手動で削除した後にsvn deleteコマンドで改めて削除登録する必要があります。

6.7 ファイルやディレクトリを移動/リネーム登録する (svn move または svn mv)

SVN管理下のファイルやディレクトリを移動または名前変更し、その変更をリポジトリに記録するための登録を行います。SVNでは、移動や名前変更は「元の場所からの削除」と「新しい場所への追加」を同時に行う操作として扱われますが、svn moveコマンドを使うことで履歴を維持したまま行えます。

“`bash
svn move [元のパス] [新しいパス]

または短縮形

svn mv [元のパス] [新しいパス]
“`

  • [元のパス]: 移動または名前変更したいファイルまたはディレクトリの現在のパス。
  • [新しいパス]: 移動先または新しい名前のパス。

実行例:

old_name.txtというファイルの名前をnew_name.txtに変更する場合。

bash
svn move old_name.txt new_name.txt

src/main.cというファイルをsource/main.cという場所に移動する場合。

bash
svn move src/main.c source/main.c

svn moveを実行すると、ローカルの作業コピーで実際にファイルやディレクトリが移動/名前変更されます。svn statusを実行すると、元のパスはDとして、新しいパスはAとして表示され、先頭にRと表示されることもあります（置換として扱われるため）。

6.8 変更をリポジトリに送信する (svn commit または svn ci)

作業コピーで行った全ての変更（ファイルの編集、svn add、svn delete、svn moveなどで登録した変更）を、中央リポジトリに送信して永続的に記録する最も重要な操作です。

“`bash
svn commit [パス（省略可）] -m “コミットメッセージ”

または短縮形

svn ci [パス（省略可）] -m “コミットメッセージ”
“`

  • [パス]: コミットしたい変更を含む特定のファイルやディレクトリを指定します。省略した場合、カレントディレクトリ（とそのサブディレクトリ全て）で行われた変更が全てコミット対象となります。通常は作業コピーのルートディレクトリで実行します。
  • -m "コミットメッセージ": このオプションを使って、コマンドラインで直接コミットメッセージを指定します。コミットメッセージは、そのコミットで何を変更したのかを簡潔かつ明確に記述する必要があります。コミットメッセージの記述は必須です。

もし-mオプションを省略した場合、SVNは設定されたテキストエディタを起動し、そこでコミットメッセージを入力するよう求めます。

実行例:

作業コピー全体の変更をコミットする場合。

bash
svn commit -m "feat: 新機能Xを追加しました"

特定のディレクトリ内の変更のみをコミットする場合。

bash
svn commit docs/ -m "docs: ドキュメントを更新"

コミットが成功すると、リポジトリのリビジョン番号が1つ増え、コミットした変更がそのリビジョンに紐づけて記録されます。

重要な注意点: コミットする前に、必ずsvn updateを実行してリポジトリの最新の状態を自分の作業コピーに取り込み、他の人の変更との競合がないか確認してください。競合が発生した場合は、コミット前に競合を解消する必要があります。

6.9 変更内容の差分を表示する (svn diff)

作業コピーの現在の状態と、リポジトリにある状態（通常は作業コピーのベースリビジョン）との間で、ファイル内容の差分を確認する際に使用します。コミットする前に、自分の変更内容が意図した通りになっているかを確認するのに役立ちます。

bash
svn diff [パス（省略可）]

  • [パス]: 差分を表示したい特定のファイルやディレクトリを指定します。省略した場合、作業コピー全体での変更差分を表示します。

実行例:

作業コピー全体の変更差分を表示する場合。

bash
svn diff

特定のファイルの差分を表示する場合。

bash
svn diff my_module.c

svn diffコマンドは、変更された行の前に+（追加）、-（削除）などの記号を付けて差分を表示します。これはdiffコマンドの標準的な形式（unified diff形式など）です。

応用例:

  • 特定のファイルのリビジョン間の差分:
    bash
    svn diff -r [リビジョンA]:[リビジョンB] [ファイルのURLまたはパス]
    例: リポジトリ上のmain.cファイルの、リビジョン100とリビジョン105の差分を表示。
    bash
    svn diff -r 100:105 https://svn.example.com/myproject/trunk/main.c
  • 作業コピーの現在の状態と特定リビジョンとの差分:
    bash
    svn diff -r [リビジョン]:HEAD [ファイルまたはディレクトリのパス]
    例: 作業コピーの現在の状態とリビジョン120の差分を表示。
    bash
    svn diff -r 120:HEAD .
    (HEADはリポジトリの最新リビジョンを指しますが、svn diffの作業コピーに対するデフォルトの比較対象は、作業コピーのベースリビジョンです。HEADを指定することで明示的に最新リビジョンとの比較ができます。ただし、通常は引数なしのsvn diffで十分です。)

6.10 変更履歴を表示する (svn log)

リポジトリまたは作業コピーの変更履歴（コミットログ）を表示します。誰が、いつ、どのリビジョンで、どのようなコミットメッセージとともに変更を行ったかを確認できます。

bash
svn log [パス（省略可）]

  • [パス]: 履歴を表示したい特定のファイル、ディレクトリ、またはリポジトリの場所を指定します。省略した場合、カレントディレクトリに対応するリポジトリのパスの履歴を表示します。

実行例:

カレントディレクトリに対応するリポジトリパスの履歴を表示する場合。

bash
svn log

特定のファイルの履歴を表示する場合。

bash
svn log main.c

オプション例:

  • -r [リビジョン範囲]: 特定のリビジョン範囲の履歴のみを表示します。
    例: リビジョン100から120までの履歴を表示。
    bash
    svn log -r 100:120
    例: 最新10件の履歴を表示。
    bash
    svn log -l 10
  • --limit [件数]: 最新から指定した件数だけ表示します。
  • --verbose または -v: コミットに含まれる変更されたファイルリストも表示します。
  • --quiet または -q: コミットメッセージのみ表示し、変更されたファイルリストを省略します（-vの逆）。

出力例:

“`

r 125 | username | 2023-10-27 10:30:00 +0900 (金, 27 10月 2023) | 1 line

feat: 新機能Xを追加しました

r 124 | username | 2023-10-26 15:00:00 +0900 (木, 26 10月 2023) | 2 lines

fix: バグを修正しました
テストコードを追加

…
“`

6.11 作業コピーやリポジトリの情報を表示する (svn info)

ファイル、ディレクトリ、またはリポジトリのURLに関する詳細情報を表示します。

bash
svn info [パスまたはURL（省略可）]

  • [パスまたはURL]: 情報を表示したい対象を指定します。省略した場合、カレントディレクトリの作業コピーに関する情報を表示します。

実行例:

カレントディレクトリの作業コピー情報を表示する場合。

bash
svn info

リポジトリ上の特定のURLの情報を表示する場合。

bash
svn info https://svn.example.com/myproject/trunk

出力例:

Path: .
Working Copy Root Path: /path/to/myproject/workingcopy
URL: https://svn.example.com/myproject/trunk
Relative URL: ^/trunk
Repository Root: https://svn.example.com/myproject
Repository UUID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
Revision: 125
Node Kind: directory
Schedule: normal
Depth: infinity
Last Changed Author: username
Last Changed Rev: 125
Last Changed Date: 2023-10-27 10:30:00 +0900 (金, 27 10月 2023)

Revisionは、その作業コピーが基づいているリポジトリのリビジョンを示します。Last Changed Revは、そのディレクトリまたはファイルが最後に変更されたリビジョンを示します。

6.12 作業コピーのロック解除などを行う (svn cleanup)

SVNの操作中に予期せぬエラー（例えば、操作の途中で強制終了したなど）が発生すると、作業コピーがロックされた状態になり、他のSVNコマンドが実行できなくなることがあります。このような場合にsvn cleanupコマンドを使用して、作業コピーの状態を正常に戻します。

bash
svn cleanup [パス（省略可）]

  • [パス]: クリーンアップしたい作業コピー内の特定のディレクトリを指定します。省略した場合、カレントディレクトリ（とそのサブディレクトリ全て）がクリーンアップされます。通常は作業コピーのルートディレクトリで実行します。

実行例:

作業コピー全体をクリーンアップする場合。

bash
svn cleanup

エラーが出てSVN操作ができなくなった場合に、まず試すべきコマンドの一つです。

6.13 ローカルでの変更を取り消す (svn revert)

作業コピーで行った変更を破棄し、最後にsvn updateまたはsvn checkoutした時の状態に戻したい場合に利用します。コミット前の変更のみを元に戻せます。既にコミットしてしまった変更を取り消す場合は、別の方法（後述のリバートマージなど）が必要です。

bash
svn revert [ファイルまたはディレクトリのパス...]

  • [ファイルまたはディレクトリのパス...]: 変更を破棄したいファイルやディレクトリを1つ以上指定します。

実行例:

my_config.xmlファイルに行った全ての変更を取り消す場合。

bash
svn revert my_config.xml

カレントディレクトリで行った全ての変更（変更済み、追加予定、削除予定など）を取り消す場合。

bash
svn revert . --depth infinity
--depth infinityオプションは、ディレクトリとそのサブディレクトリ全ての変更を取り消す場合に必要です。ファイル指定の場合は不要です。

注意: svn revertは、ローカルで行った未コミットの変更を完全に破棄します。実行する前にsvn diffで変更内容を確認し、本当に破棄して良いか十分に注意してください。

7. SVNの応用コマンド・概念

ここからは、より発展的なSVNの使い方に関わるコマンドや概念を説明します。

7.1 ブランチとタグ

SVNでは、ブランチもタグもsvn copyコマンドを使って作成します。どちらもリポジトリ内の既存のパスを別のパスにコピーすることで実現されます。リポジトリの標準的な構成としてtrunk, branches, tagsが推奨されるのは、ブランチとタグを分かりやすく区別し、管理しやすくするためです。

  • ブランチ (Branch):
    メインの開発ラインであるtrunkから分岐して、独立した開発を行うために作成します。特定の機能開発、バグ修正、あるいは次のメジャーバージョン開発など、メインラインに影響を与えずに並行して作業を進めたい場合に利用します。ブランチで開発した内容は、後でtrunkや別のブランチに統合（マージ）するのが一般的です。

  • タグ (Tag):
    リポジトリの特定の時点（リビジョン）に、分かりやすい名前（例: v1.0.0, release-20231027）を付けて記録するために作成します。タグは通常、変更を加えるためのものではなく、特定の時点の状態を「スナップショット」として参照するために使われます。リリース版のコードなどにタグを付けることで、後からいつでもその時点の正確なコードを取り出せるようになります。

7.1.1 ブランチ/タグを作成する (svn copy または svn cp)

svn copyコマンドを使って、リポジトリ内のパスを別のリポジトリ内のパスにコピーすることで、ブランチやタグを作成します。作業コピー内でコピーするのではなく、リポジトリ間で直接コピーする方が効率的です。

“`bash
svn copy [元のリポジトリURL] [新しいリポジトリURL] -m “コミットメッセージ”

または短縮形

svn cp [元のリポジトリURL] [新しいリポジトリURL] -m “コミットメッセージ”
“`

  • [元のリポジトリURL]: コピー元となる、リポジトリ上の既存のパス（例: .../trunk, .../branches/featureAなど）。
  • [新しいリポジトリURL]: コピー先となる、リポジトリ上の新しいパス（例: .../branches/my-feature, .../tags/v1.0.0など）。
  • -m "コミットメッセージ": ブランチ/タグ作成の理由を記述するコミットメッセージ。

実行例:

trunkから新しい機能開発用のブランチbranches/my-featureを作成する場合。

bash
svn copy https://svn.example.com/myproject/trunk https://svn.example.com/myproject/branches/my-feature -m "feat: Create branch for feature development"

リビジョン125のtrunkの状態にtags/v1.0.0というタグを付ける場合。

bash
svn copy https://svn.example.com/myproject/trunk@125 https://svn.example.com/myproject/tags/v1.0.0 -m "tag: Tagging release v1.0.0"
URLの末尾に@リビジョン番号を付けることで、特定の時点の状態を指定できます。指定しない場合は、コピー実行時の最新リビジョンが使用されます。

7.1.2 作業コピーをブランチに切り替える (svn switch または svn sw)

既存の作業コピーの内容を、別のリポジトリ上のパス（ブランチやタグ）の状態に切り替えたい場合に利用します。例えば、trunkの作業コピーを使っていて、新しく作ったブランチmy-featureでの作業に移りたい場合などに使います。

“`bash
svn switch [切り替えたいリポジトリのURL] [作業コピーのローカルパス（省略可）]

または短縮形

svn sw [切り替えたいリポジトリのURL] [作業コピーのローカルパス（省略可）]
“`

  • [切り替えたいリポジトリのURL]: 作業コピーを切り替えたいブランチやタグのリポジトリURL。
  • [作業コピーのローカルパス]: 切り替えたい作業コピーのパス。省略した場合、カレントディレクトリ（作業コピーのルートで実行することが多い）。

実行例:

trunkで作業していたカレントディレクトリの作業コピーを、branches/my-featureブランチに切り替える場合。

bash
svn switch https://svn.example.com/myproject/branches/my-feature .
.はカレントディレクトリを意味します。

svn switchを実行すると、SVNは現在の作業コピーの状態を維持しつつ、指定されたURLのリポジトリの状態に合わせてファイルを追加、削除、変更します。これにより、新しいブランチでの作業を開始できます。作業コピー内の未コミットの変更がある場合、それらは可能な限り維持されますが、競合が発生する可能性もあります。

7.2 マージ (svn merge)

マージとは、あるブランチで行われた変更を別のブランチに取り込む操作です。例えば、branches/my-featureで開発した内容をtrunkに統合したい場合や、trunkで行われたバグ修正をbranches/my-featureにも反映させたい場合などに使用します。

マージ操作は、通常、変更を取り込みたい方のブランチの作業コピーで行います。

bash
svn merge [変更を取り込みたい元のリポジトリURL] [変更を取り込みたい元のリビジョン範囲] [マージ先の作業コピーのローカルパス（省略可）]
SVN 1.5以降では、マージ追跡機能が導入され、より簡単な構文が推奨されます。

推奨されるマージ構文 (マージ追跡機能あり):

別のブランチで行われた変更を、現在の作業コピー（マージ先）に取り込む場合。作業コピーのルートディレクトリで実行します。

“`bash

ブランチ全体をマージする場合

svn merge [変更元ブランチのリポジトリURL] [マージ先の作業コピーのローカルパス（省略可）]

特定のリビジョン範囲のみマージする場合

svn merge -r [開始リビジョン]:[終了リビジョン] [変更元ブランチのリポジトリURL] [マージ先の作業コピーのローカルパス（省略可）]
“`

  • [変更元ブランチのリポジトリURL]: 変更を取り込みたいブランチ（例: .../branches/my-feature）。
  • [マージ先の作業コピーのローカルパス]: マージ結果を適用する作業コピーのパス。省略した場合、カレントディレクトリ（通常作業コピーのルート）になります。

実行例:

作業コピーがtrunkにある状態で、branches/my-featureブランチの最新の変更をtrunkにマージする場合。

“`bash

作業コピーがtrunkにあることを確認

svn info | grep URL

…/trunk と表示されるはず

my-feature ブランチの全ての変更をtrunkにマージ

svn merge https://svn.example.com/myproject/branches/my-feature .
``
このコマンドを実行すると、my-featureブランチが作成されてから現在までの全ての変更が、現在のtrunk`の作業コピーに適用されます。

特定のバグ修正（例えばリビジョン150）がtrunkで行われたとして、その変更をbranches/my-featureにもマージしたい場合。作業コピーをbranches/my-featureに切り替えてから実行します。

“`bash

作業コピーを my-feature ブランチに切り替え

svn switch https://svn.example.com/myproject/branches/my-feature .

trunk@150 の変更を my-feature にマージ

svn merge -r 149:150 https://svn.example.com/myproject/trunk .
``-r 149:150`は、「リビジョン149から150にかけて行われた変更」を意味します。マージ追跡機能がある場合、この構文で指定された変更が既にマージ済みであればスキップされます。

マージが成功すると、作業コピーが変更された状態になります。これらの変更はまだローカルにしかないため、確認後、必ずsvn commitでリポジトリに送信する必要があります。

マージの際に、変更が競合することがあります（前述の「競合 (Conflict)」参照）。その場合、Cステータスが表示され、ファイル内に競合マーカー（<<<<<<<, =======, >>>>>>>など）が挿入されます。

競合の解消:

競合が発生した場合、手動でファイルを編集し、競合マーカーを削除して、最終的に必要な変更内容に修正します。修正が完了したら、以下のコマンドで競合が解消されたことをSVNに知らせます。

bash
svn resolve --accept [方法] [競合したファイルのパス...]
* --accept [方法]: 競合をどのように解決したかを指定します。
* base: マージ前の元のファイルの状態を採用。
* mine-full: マージ先の作業コピーで行った全ての変更を採用し、マージ元の変更を全て破棄。
* theirs-full: マージ元で行われた全ての変更を採用し、マージ先の変更を全て破棄。
* working: 手動でファイルを編集して競合マーカーを削除した場合に指定（最も一般的）。

実行例:

conflicted_file.txtの競合を手動で解消した場合。

bash
svn resolve --accept working conflicted_file.txt

競合解消後、svn statusで競合が解消されたことを確認し（Cマークが消え、Mマークなどが表示される）、問題なければコミットします。

7.3 リバートマージ (svn merge -c)

既にリポジトリにコミットしてしまった変更を取り消したい（「あのコミットは無かったことにしたい」）場合に、リバートマージを行います。特定のコミットで行われた変更を逆方向に適用する操作です。

“`bash
svn merge -c -[取り消したいリビジョン番号] [作業コピーのローカルパス（省略可）]

または特定リビジョン範囲の変更を取り消す

svn merge -c -[開始リビジョン]:[終了リビジョン] [作業コピーのローカルパス（省略可）]
``-c -[リビジョン]` のようにマイナスを付けるのがポイントです。これは「指定したリビジョンで行われた変更を取り消す」という意味になります。

実行例:

リビジョン120で行われたコミットを取り消したい場合。作業コピーのルートディレクトリで実行します。

bash
svn merge -c -120 .

リビジョン110から115にかけて行われた一連の変更を取り消したい場合。

bash
svn merge -c -110:115 .

リバートマージを実行すると、そのコミットで行われた変更の逆が作業コピーに適用されます。例えば、リビジョン120でファイルAに行が追加されていたなら、リバートマージによってその行は削除されます。この変更はまだローカルにあるだけなので、必ずsvn commitでリポジトリに送信し、取り消し操作自体を履歴として記録する必要があります。コミットメッセージには、どのリビジョンを取り消したのかを明記するのが良い慣習です。

8. 実際の開発ワークフロー

SVNを使った一般的な開発ワークフローは以下のようになります。

  1. 初めてプロジェクトに参加する:
    リポジトリから作業コピーをチェックアウトします。
    bash
    svn checkout https://svn.example.com/myproject/trunk myproject

  2. 毎日の作業開始時:
    他の開発者が行った変更を自分の作業コピーに取り込むために、アップデートします。これにより、常に最新の状態に基づいて作業できます。
    bash
    cd myproject
    svn update

  3. ファイルを編集/追加/削除する:
    コードを書いたり、ドキュメントを修正したりします。新しいファイルを作成したり、不要なファイルを削除したりします。
    “`bash
    # ファイルを編集 (好きなエディタで)
    vim src/main.c

    新しいファイルを追加

    touch docs/new_document.md
    svn add docs/new_document.md

    ファイルを削除

    svn delete old_script.py
    “`

  4. 作業コピーの状態を確認する:
    どのファイルが変更されたか、追加/削除予定になっているかなどをステータスコマンドで確認します。
    bash
    svn status

  5. 変更内容を確認する:
    差分コマンドで、具体的な変更内容を確認します。意図しない変更が含まれていないかチェックします。
    bash
    svn diff

  6. リポジトリに自分の変更を記録する:
    作業が一段落ついたら、自分の変更をリポジトリにコミットします。コミットする前に、念のためもう一度svn updateを実行し、競合がないか確認することが推奨されます。もし競合が発生したら、解消してからコミットします。
    “`bash
    # 最後の update から他の人の変更がないか確認
    svn update
    # 競合 C が出たら解消
    # svn resolve –accept working …

    問題なければコミット

    svn commit -m “feat: 〇〇機能を実装しました”
    “`
    コミットは、論理的な一区切りごとに行うのが良いプラクティスです。小さく頻繁にコミットすることで、履歴が追いやすくなり、問題発生時の原因特定や修正が容易になります。

  7. ブランチを使った開発:
    メインライン（trunk）に影響を与えずに大きな機能開発などを行う場合は、新しいブランチを作成します。
    “`bash
    # trunk からブランチを作成 (リポジトリ操作)
    svn copy https://svn.example.com/myproject/trunk https://svn.example.com/myproject/branches/my-feature -m “Create branch for my-feature”

    作業コピーを新しいブランチに切り替える

    svn switch https://svn.example.com/myproject/branches/my-feature .
    ブランチでの作業中も、他のブランチ（例: `trunk`）での変更（バグ修正など）を定期的に自分のブランチに取り込むために**マージ**を行うことがあります。bash

    trunk から現在のブランチにマージ (作業コピーで実行)

    svn merge https://svn.example.com/myproject/trunk .

    競合があれば解消し、コミット

    svn commit -m “Merge rXXX:rYYY from trunk”
    機能開発が完了したら、そのブランチの変更をメインライン（`trunk`）に**マージ**して統合します。bash

    作業コピーを trunk に切り替える

    svn switch https://svn.example.com/myproject/trunk .

    自分のブランチの変更を trunk にマージ (作業コピーで実行)

    svn merge https://svn.example.com/myproject/branches/my-feature .

    競合があれば解消し、コミット

    svn commit -m “Merge feature-branch into trunk”

    マージ済みのブランチが不要なら、削除を検討 (リポジトリ操作)

    svn delete https://svn.example.com/myproject/branches/my-feature -m “Delete merged branch”

    “`

  8. リリースなどの節目:
    特定の時点の状態を後から参照できるように、タグを作成します。
    bash
    # trunk の最新リビジョンにタグを付ける (リポジトリ操作)
    svn copy https://svn.example.com/myproject/trunk https://svn.example.com/myproject/tags/v1.0.0 -m "Tagging release v1.0.0"

9. GUIツールの紹介（TortoiseSVN）

Windowsユーザーに最も普及しているGUIクライアント「TortoiseSVN」を例に、GUIツールを使う場合の操作感を簡単に紹介します。TortoiseSVNはWindowsエクスプローラーに統合されており、ファイルやフォルダを右クリックして表示されるコンテキストメニューからSVN操作を行います。

  • チェックアウト: エクスプローラー上で任意の場所を右クリックし、「SVN Checkout…」を選択します。リポジトリのURLやチェックアウト先を入力して実行します。
  • アップデート: 作業コピーのフォルダを右クリックし、「SVN Update」を選択します。
  • コミット: 変更を加えたファイルやフォルダを含む作業コピーのフォルダを右クリックし、「SVN Commit…」を選択します。変更されたファイルリストが表示されるので、コミットしたいファイルを選び、コミットメッセージを入力して実行します。
  • ステータス/差分: 作業コピーのフォルダやファイルを右クリックし、「TortoiseSVN」サブメニューから「Check for modifications」（変更の確認）や「Diff with previous revision」（直前のリビジョンとの差分）などを選択します。
  • 追加/削除/移動: エクスプローラー上でファイルやフォルダを操作（追加、削除、名前変更、移動）した後、右クリックメニューの「TortoiseSVN」から「Add…」「Delete」「Rename」「Move」などを選択してSVNに登録します。手動で削除した場合などは、「Check for modifications」で!（欠落）と表示されたファイルを右クリックして「Delete」を選択します。
  • ログ: 作業コピーのフォルダやファイルを右クリックし、「TortoiseSVN」から「Show log」を選択します。履歴が一覧表示され、各リビジョンでの変更ファイルなども確認できます。

GUIツールを使うことで、コマンドを覚える必要がなく、視覚的に分かりやすくSVN操作を行えます。ただし、内部的な仕組み（リビジョン、作業コピーの状態など）を理解するためには、コマンドラインの概念を学ぶのがおすすめです。

10. よくあるトラブルと対処法

SVNを使い始める際やチームで利用する際によく遭遇するトラブルと、その対処法をいくつか紹介します。

10.1 競合 (Conflict) が発生した

状況: svn updateやsvn mergeを実行した際に、他の人の変更と自分の変更が同じファイルの同じ箇所で重なり、自動マージに失敗した。ファイルに競合マーカー（<<<<<<<, =======, >>>>>>>など）が挿入されている。

対処法:
1. 競合したファイルを特定: svn statusを実行し、ステータスがCとなっているファイルを確認します。
2. ファイルを編集: テキストエディタなどで競合したファイルを開き、挿入された競合マーカーを参考に、最終的に採用したい内容になるように手動で修正します。どちらか一方の変更だけを採用するか、両方の変更を組み合わせるか、新しい内容を書くかは、その状況に応じて判断します。
3. 競合を解消したことをSVNに通知: ファイルの修正が完了し、競合マーカーを全て削除したら、svn resolveコマンドを使ってSVNに競合が解消されたことを知らせます。
bash
svn resolve --accept working [競合したファイルのパス]
複数のファイルで競合した場合は、それぞれのファイルに対してこのコマンドを実行します。
4. 状態を確認: svn statusを実行し、該当ファイルのステータスがCからMなどに変わっていることを確認します。
5. コミット: 全ての競合が解消され、他の変更も問題なければ、通常通りsvn commitでリポジトリに送信します。

10.2 コミットしようとしたら「Out of date」エラーが出た

状況: svn commitを実行した際に、「Out of date」エラーが表示されてコミットに失敗した。これは、あなたが最後にsvn updateを実行してから、他の誰かがリポジトリにコミットを行ったために発生します。リポジトリの状態があなたの作業コピーよりも新しくなっているため、そのままコミットすると他の人の変更を上書きしてしまう可能性があるため、SVNがコミットを拒否します。

対処法:
1. アップデートする: エラーメッセージに従い、まずsvn updateを実行してリポジトリの最新の状態を自分の作業コピーに取り込みます。
bash
svn update
2. 競合の確認と解消: svn updateによって、他の人の変更があなたの作業コピーに適用されます。この際、あなたが行った変更と他の人の変更が競合する可能性があります。svn statusを確認し、競合が発生している場合は上記の「競合が発生した」の対処法に従って解消します。競合がなければ、他の人の変更が自動的にマージされています。
3. 改めてコミットする: svn updateが完了し、競合も全て解消したら、改めてsvn commitを実行します。
bash
svn commit -m "あなたのコミットメッセージ"
これでコミットが成功するはずです。

10.3 間違ってファイルを削除してしまった（!ステータスになった）

状況: SVN管理下のファイルをエクスプローラーやrmコマンドなどで手動で削除してしまった。svn statusを実行すると、そのファイルのステータスが!（欠落）と表示されている。

対処法:
* やっぱり削除したい: そのファイルをリポジトリからも削除したい場合は、改めてsvn deleteコマンドで削除登録します。
bash
svn delete [手動で削除してしまったファイルのパス]
これでステータスがDになります。この状態でコミットすれば、リポジトリからもファイルが削除されます。
* 削除を取り消したい: やっぱりファイルを元に戻したい場合は、svn revertコマンドで削除を取り消します。
bash
svn revert [手動で削除してしまったファイルのパス]
これにより、リポジトリにある最新の状態（または作業コピーのベースリビジョン）からファイルが復元され、ステータスが消えます。

10.4 未コミットの変更を全て破棄したい

状況: 作業コピーで行った未コミットの変更（編集、追加、削除など）を全て元に戻し、最後にsvn updateまたはsvn checkoutした時のクリーンな状態に戻したい。

対処法:
svn revertコマンドを適切に使用します。
bash
svn revert . --depth infinity
作業コピーのルートディレクトリでこのコマンドを実行すると、そのディレクトリ以下の全てのファイルとサブディレクトリで行われた未コミットの変更が全て破棄されます。この操作は取り消せないので、実行前に内容をよく確認してください。

10.5 コミットメッセージを修正したい

状況: コミット済みのリビジョンのコミットメッセージを誤って記述してしまったので修正したい。

対処法:
svn propsetコマンドを使って、特定リビジョンのsvn:logプロパティ（これがコミットメッセージとして使われる）を修正します。ただし、この操作はデフォルトでは許可されていない場合があります。リポジトリの設定（特にpre-revprop-changeフック）によっては許可されていない可能性が高いです。サーバー管理者に相談する必要があるかもしれません。

もし許可されていれば、以下のコマンドで修正できます。

bash
svn propset svn:log "新しいコミットメッセージ" --revprop -r [修正したいリビジョン番号] [リポジトリのURL]
* --revprop: プロパティをリビジョン番号に対して設定することを意味します。
* -r [修正したいリビジョン番号]: 修正したいコミットのリビジョン番号。
* [リポジトリのURL]: リポジトリのルートURL。

注意: リビジョンプロパティの変更（revprop change）は、通常のコミットとは異なり、履歴が残らない場合があります。また、リポジトリの整合性に関わるため、サーバー側で厳しく制限されていることが多いです。基本的に、一度コミットしたメッセージは修正しないのが原則です。誤りがあった場合は、次のコミットで訂正を入れるなどの方法をとるのが一般的です。

10.6 認証エラーが出る

状況: SVNコマンド実行時に、ユーザー名やパスワードを求められたり、認証エラーになったりする。

対処法:
* ユーザー名/パスワードの確認: 入力しているユーザー名とパスワードが正しいか確認してください。
* プロトコル/URLの確認: アクセスしようとしているリポジトリのURLやプロトコル（svn://, svn+ssh://, http://, https://など）が正しいか確認してください。プロトコルによっては認証方法が異なります。
* サーバー側の設定: SVNサーバー側で設定された認証方式（Basic認証、Digest認証、SSHキー認証など）に従っているか確認してください。サーバー管理者に問い合わせる必要があるかもしれません。
* キャッシュされた認証情報のクリア: 過去に誤った認証情報を入力した場合、それがローカルにキャッシュされていることがあります。以下のコマンドでキャッシュをクリアできます（パスはOSによって異なります）。
* Windows: %APPDATA%\Subversion\auth ディレクトリの内容を削除
* macOS/Linux: ~/.subversion/auth ディレクトリの内容を削除

11. SVNからGitへの移行について (おまけ)

現在、多くの新しいプロジェクトではGitがバージョン管理システムとして選択されています。SVNを長年使っている組織でも、Gitへの移行を検討するケースが増えています。

SVNは集中型モデルであり、リポジトリがサーバーに一つだけ存在するのに対し、Gitは分散型モデルであり、各ユーザーがローカルにリポジトリ全体を持ちます。この分散型モデルは、以下のようなメリットをもたらします。

  • オフラインでの作業: ネットワークに接続していなくても、コミットや履歴の参照ができます。
  • 高速な操作: ほとんどの操作がローカルで完結するため高速です。
  • 柔軟なブランチング: ブランチの作成、切り替え、マージが非常に高速かつ簡単に行えます。これにより、トピックブランチ（特定の機能や修正のための短い期間のブランチ）を頻繁に作成し、より柔軟な開発ワークフローを構築できます。
  • 堅牢性: リポジトリが分散しているため、中央サーバーがダウンしても他のユーザーのローカルリポジトリから復旧可能です。

もしあなたが新しいプロジェクトを開始する場合や、既存のSVNプロジェクトのメンテナンスに苦労している場合、Gitへの移行を検討する価値はあります。SVNからGitへの移行を支援するツール（例: svn2git）も存在します。

ただし、SVNからGitへの移行はそれなりに労力がかかります。特にチーム全体が新しいワークフローに適応するための学習コストが必要です。SVNにはSVNの良いところもあり（例えば、リビジョン番号が単純な整数で分かりやすい、ディレクトリ操作が直感的など）、既存のSVNプロジェクトをそのまま使い続けるという選択肢も十分にあり得ます。

12. まとめ

この記事では、バージョン管理システムSVNについて、その基本的な概念からコマンドラインを使った操作方法までを詳細に解説しました。

SVNは集中型バージョン管理システムであり、中央リポジトリで全ての履歴を管理します。開発者はリポジトリから作業コピーを取得し、そこで行った変更をコミットすることでリポジトリに反映させます。

この記事で解説した主要なコマンドは以下の通りです。

  • svn checkout: リポジトリから作業コピーを初めて取得する。
  • svn update: 作業コピーをリポジトリの最新状態に更新する。
  • svn status: 作業コピーの状態（変更、追加、削除など）を確認する。
  • svn add: 新しいファイルやディレクトリをSVN管理下に追加登録する。
  • svn delete: ファイルやディレクトリをSVN管理下から削除登録する。
  • svn move: ファイルやディレクトリを移動/リネーム登録する。
  • svn commit: 作業コピーの変更をリポジトリに送信して記録する。
  • svn diff: 変更内容の差分を確認する。
  • svn log: 変更履歴を確認する。
  • svn info: 作業コピーやリポジトリの情報を表示する。
  • svn cleanup: 作業コピーのロック解除などを行う。
  • svn revert: 未コミットのローカル変更を破棄する。
  • svn copy: ブランチやタグを作成する。
  • svn switch: 作業コピーを別のブランチ/タグに切り替える。
  • svn merge: ブランチ間の変更を統合する。

これらのコマンドを習得することで、SVNを使った個人開発やチーム開発の基本的なバージョン管理ができるようになります。

バージョン管理は、現代のソフトウェア開発や情報共有において必須のスキルです。SVNはGitと比べてシンプルな構造を持つため、バージョン管理の概念を学ぶ最初のツールとして適しています。

まずは今回学んだ基本的なコマンドを実際に使ってみて、バージョン管理の感覚を掴んでください。慣れてきたら、GUIツールを利用したり、IDEとの連携を活用したりすることで、さらに効率的に作業を進めることができるでしょう。

SVNを使う上で最も重要なのは、「常に最新の状態を意識すること」「こまめにコミットすること」「適切なコミットメッセージを記述すること」「競合を恐れず、適切に解消すること」です。これらの点を心がければ、SVNを効果的に活用し、プロジェクト管理をスムーズに行えるようになります。

この記事が、あなたのSVN学習の助けとなれば幸いです。頑張ってください！

コメントする

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

上部へスクロール