はい、承知いたしました。「これで完璧!svn clone
コマンドでSVNリポジトリをコピーする方法」と題し、SVNにおけるリポジトリのコピーや取得に関する詳細な記事を約5000語で記述します。ただし、Subversion (SVN) には直接 svn clone
というコマンドは存在しません。この記事では、ユーザーが「svn clone
」という言葉で意図しているであろう操作(リポジトリのコピー、ローカルへの取得など)を実現するためのSVNのコマンドと方法について、詳細に解説します。
これで完璧!SVNリポジトリをコピー・取得する詳細ガイド(svn clone
に代わる方法)
はじめに:バージョン管理システムSubversion (SVN) と「クローン」という概念
ソフトウェア開発やドキュメント管理において、バージョン管理システムは不可欠なツールです。その中でも、Subversion (SVN) は長年にわたり多くのプロジェクトで利用されてきた集中型バージョン管理システムです。ファイルやディレクトリの変更履歴を効率的に管理し、チームでの共同作業を円滑に進めることができます。
近年、Gitのような分散型バージョン管理システムが普及するにつれて、「クローン(clone)」という操作が広く認知されるようになりました。Gitにおける git clone
コマンドは、リモートリポジトリのすべての履歴を含んだ完全なコピーをローカルに作成し、そのリポジトリでの作業を開始するための最初のステップとなります。
さて、もしあなたがSVNを使っている、あるいはこれから使おうとしていて、「Gitの clone
のように、SVNリポジトリを丸ごと手元に持ってきたい」「別の場所にリポジトリのバックアップやレプリカを作りたい」と考えている場合、まず知っておくべき重要な点があります。それは、SVNには svn clone
という名前のコマンドは直接存在しない、ということです。
Gitが各ローカルリポジトリに完全な履歴を持つ「分散型」であるのに対し、SVNは中央の単一リポジトリがすべての履歴を管理する「集中型」です。このアーキテクチャの違いが、「クローン」という操作の存在や意味合いに影響を与えています。
しかし、SVNでリポジトリ全体を取得したり、別の場所にコピーしたりする方法がないわけではありません。ユーザーが「svn clone
」という言葉で表現しようとしている目的は、SVNの他のコマンドや組み合わせによって実現可能です。
この記事では、「SVNでリポジトリをクローンする」というユーザーの意図を汲み取り、それを実現するための具体的なSVNコマンドと手順について、詳細かつ網羅的に解説します。あなたが達成したい目的が、単にリポジトリの内容を作業用として手元に持ってくることなのか、それともリポジトリ全体の完全なコピーを作成することなのかによって、使用すべきコマンドが異なります。それぞれの目的に合わせた最適な方法を、コマンドのオプションや使用例、注意点を含めて深掘りしていきます。
具体的には、以下の3つの主要なシナリオと、それぞれのシナリオに対応するSVNコマンドに焦点を当てます。
- シナリオ1:リモートリポジトリの内容をローカルで作業するために取得したい
- 対応コマンド:
svn checkout
- 対応コマンド:
- シナリオ2:SVNリポジトリ全体(全履歴含む)を別の場所に完全にコピーしたい
- 対応コマンド:
svnadmin dump
およびsvnadmin load
- (ネットワーク経由版)
svnrdump dump
およびsvnrdump load
- 対応コマンド:
- シナリオ3:SVNリポジトリの更新を追随するミラー(レプリカ)を作成したい
- 対応コマンド:
svnsync
- 対応コマンド:
これらの方法を理解することで、「svn clone
」というコマンドが存在しないSVNでも、Gitのクローンに近い操作や、リポジトリを完全に管理するための操作を自在に行えるようになります。さあ、それぞれの方法について詳しく見ていきましょう。
SVNにおける「クローン」に近い操作とは?目的別コマンド解説
Gitの git clone
は、リポジトリの全履歴をローカルにコピーし、元のリポジトリを追跡するリモート設定を行う操作です。SVNにはこれと全く同じ操作はありませんが、ユーザーが「クローンしたい」と考える状況には、いくつかのパターンが考えられます。ここでは、その目的を明確にし、それぞれの目的に対するSVNの主要なコマンドを紹介します。
目的1:リポジトリの特定パスの内容をローカルで作業できるようにする – svn checkout
これが最も一般的なSVNの利用シナリオかもしれません。リモートリポジトリにあるプロジェクトのコードやドキュメントを自分のコンピュータに持ってきて、編集や追加を行い、変更をコミットしたい場合に使います。
Gitの clone
がリポジトリ全体(全履歴)をローカルに持ってくるのに対し、svn checkout
(または svn co
) は、リポジトリ内の指定されたパス(通常は /trunk
や /branches/feature-x
など)の、特定の時点(最新リビジョンがデフォルト)のスナップショットをローカルディレクトリに取得します。このローカルディレクトリは「作業コピー (Working Copy)」と呼ばれ、変更の追跡やコミットなどの操作が可能になります。
svn checkout
で取得されるのは、指定した時点のファイルやディレクトリの内容と、それをバージョン管理下に置くためのメタデータ(.svn
ディレクトリ内に格納される)です。Gitのようにリポジトリ全体の履歴データがローカルに複製されるわけではありません。履歴を参照したい場合は、svn log
などのコマンドを使って中央リポジトリに問い合わせる必要があります。
もしGitユーザーが「SVNをクローンしたい」と言う場合、多くの場合、この svn checkout
の操作を指している可能性があります。つまり、「リモートリポジトリからプロジェクトの内容を取得し、ローカルで作業を開始したい」という意図です。
目的2:SVNリポジトリ全体(全履歴含む)を別の場所に完全にコピーする – svnadmin dump
& svnadmin load
/ svnrdump dump
& svnrdump load
Gitの git clone
が、リモートリポジトリの全履歴を含む完全なコピーをローカルに作成する操作であるという点では、SVNでこのレベルの「完全なコピー」を作成する操作に最も近いのは、svnadmin dump
と svnadmin load
を組み合わせる方法です。
この方法は、既存のSVNリポジトリからその内容(ファイル、ディレクトリ、すべてのリビジョン、すべての履歴、すべてのリビジョンプロパティなど)をダンプファイルとして抽出し、そのダンプファイルを別の場所にある新しい(または既存の)リポジトリにロードするという手順を踏みます。これは、リポジトリのバックアップを作成したり、リポジトリを別のサーバーに移行したり、リポジトリを完全に複製したりする際に使用されます。
svnadmin
コマンドは、通常、リポジトリが格納されているサーバー上のファイルシステムに直接アクセスして実行されます。つまり、ローカルリポジトリの操作や、サーバーにログインして実行する場合に使われます。
もし、リポジトリがリモートにあり、サーバーに直接ログインできないが、ネットワーク経由でリポジトリ全体をコピーしたい場合は、svnrdump
コマンドを使用します。svnrdump dump
はリポジトリのURLを指定してネットワーク経由でダンプを取得し、svnrdump load
はリポジトリのURLを指定してネットワーク経由でロードを行います。これは svnadmin dump/load
のネットワーク版と考えることができます。
この方法で作成されるコピーは、元リポジトリと全く同じ履歴を持つ独立したリポジトリとなります。
目的3:SVNリポジトリの更新を追随するミラー(レプリカ)を作成する – svnsync
もう一つの「クローン」に近い操作として、「ミラーリング」があります。これは、元となるリポジトリの更新を自動的または定期的に別のリポジトリに反映させ、常に元リポジトリの最新状態に追随するレプリカ(ミラー)を作成する方法です。この目的には svnsync
コマンドを使用します。
svnsync
は、元リポジトリから新しいリビジョンの変更を読み取り、それをミラーリポジトリに適用することで同期を行います。これは、元リポジトリのリアルタイムに近いバックアップを作成したり、負荷分散のために読み取り専用のレプリカを提供したりする場合に有用です。
svnsync
で作成されたミラーリポジトリは、svnadmin dump/load
で作成されたコピーと同様に全履歴を持ちますが、こちらは増分的に同期される点が異なります。また、ミラーリポジトリは通常、同期専用として扱われ、直接コミットを行うべきではありません(フック設定で制限するのが一般的です)。
各コマンドの詳細解説
それでは、それぞれの目的を達成するためのSVNコマンドについて、さらに詳しく見ていきましょう。
シナリオ1: ローカルでの作業用コピーを取得する – svn checkout
svn checkout
コマンドは、指定したリポジトリURLの特定のパス、特定の時点の内容を作業コピーとしてローカルに作成します。これが、SVNで開発作業を開始するための基本的なステップです。
コマンド構文:
bash
svn checkout URL[@REV] [PATH] [--depth ARG] [-r REV] [--force] [...]
svn co URL[@REV] [PATH] [--depth ARG] [-r REV] [--force] [...]
URL
: チェックアウトしたいリポジトリ内のパスのURL。@REV
(オプション): URLにリビジョンを指定する場合。URLの末尾に@
を付けてリビジョン番号やキーワード(HEAD
など)を指定します。PATH
(オプション): 作業コピーを作成するローカルディレクトリのパス。省略すると、URLの最後の要素名(例:/trunk
ならtrunk
)がディレクトリ名として使用されます。指定したディレクトリが存在しない場合は作成されます。--depth ARG
(オプション): チェックアウトする深さを指定します。非常に重要なオプションです。-r REV
(オプション): チェックアウトするリビジョンを指定します。省略すると最新リビジョン (HEAD
) が使用されます。URLで@REV
を指定した場合、-r
は無視されます。--force
(オプション): ローカルに既存のファイルやディレクトリがあっても上書きします(衝突する場合を除く)。- その他のオプション:
--quiet
,--ignore-externals
,--non-interactive
,--username
,--password
など。
--depth
オプションの詳細
このオプションは、チェックアウトするディレクトリ階層の深さを制御します。特に大きなリポジトリや、特定の部分だけが必要な場合に役立ちます。指定できる引数 (ARG
) は以下の通りです。
infinity
(デフォルト): 指定したパス以下のすべてのファイルとサブディレクトリを再帰的にチェックアウトします。empty
: 指定したパスのディレクトリ自体だけをチェックアウトします。そのディレクトリ内のファイルやサブディレクトリはチェックアウトしません。後からsvn update --depth infinity
などで内容を取得できます。files
: 指定したパスのディレクトリ自体と、そのディレクトリ直下のファイルだけをチェックアウトします。直下のサブディレクトリはチェックアウトしますが、その内容までは取得しません。immediates
: 指定したパスのディレクトリ自体、そのディレクトリ直下のファイル、およびそのディレクトリ直下のサブディレクトリをチェックアウトします。ただし、サブディレクトリの内容(ファイルやさらに下のサブディレクトリ)は取得しません。
使用例:
-
リポジトリの trunk の最新版を現在のディレクトリにチェックアウト:
bash
svn checkout https://example.com/svn/myproject/trunk
または
bash
svn co https://example.com/svn/myproject/trunk trunk
これにより、現在のディレクトリにtrunk
という名前のディレクトリが作成され、その中に/myproject/trunk
の最新版の内容が取得されます。 -
特定のリビジョンのタグをチェックアウト:
bash
svn checkout https://example.com/svn/myproject/tags/1.0 -r 1234 myproject-1.0
リビジョン1234時点の/myproject/tags/1.0
の内容がmyproject-1.0
ディレクトリにチェックアウトされます。 -
リポジトリの特定のディレクトリの内容をファイルのみでチェックアウト(サブディレクトリは空):
bash
svn checkout https://example.com/svn/myproject/branches/feature-x --depth files feature-x-filesonly
/myproject/branches/feature-x
ディレクトリ直下のファイルと、そのサブディレクトリ(中身は空)がfeature-x-filesonly
に取得されます。 -
巨大なリポジトリのルートを空ディレクトリとしてチェックアウトし、必要な部分だけ後から取得:
bash
svn checkout https://example.com/svn/largeproject --depth empty largeproject-skeleton
cd largeproject-skeleton
svn update submoduleA --depth infinity # 後から必要な 'submoduleA' ディレクトリの中身を取得
Gitの clone
との違い:
- 履歴:
svn checkout
は履歴全体をローカルに持ちません。svn log
などで履歴を参照する際は、中央リポジトリへの問い合わせが必要です。Gitのclone
は履歴全体をローカルに持ちます。 - ブランチ/タグ: SVNではブランチやタグは
/branches
,/tags
といった慣習的なディレクトリで管理され、これらも単なるディレクトリとしてチェックアウトできます。Gitではブランチやタグはリビジョンへのポインタとして扱われ、git clone
時にリモートのブランチ情報などが設定されます。 - アーキテクチャ:
svn checkout
は集中型モデルの操作です。ローカル作業コピーはあくまで中央リポジトリの一部のスナップショットを編集するためのものであり、それ自体が完全なリポジトリではありません。
結論として、Gitの clone
の「リモートリポジトリの内容を取得して作業を開始する」という側面に最も近いのが svn checkout
です。ただし、履歴の扱いやブランチ/タグの概念に違いがあることを理解しておく必要があります。
シナリオ2: リポジトリ全体を完全にコピーする – svnadmin dump
& svnadmin load
/ svnrdump dump
& svnrdump load
この方法は、リポジトリの全履歴を含む完全な複製を作成したい場合に用います。これは、Gitの git clone --mirror
に近い操作、またはリポジトリ自体のバックアップや移行手段と考えられます。
方法A: svnadmin dump
& svnadmin load
(ローカルアクセス)
この方法は、SVNリポジトリの物理的なパスにアクセスできる環境(通常はSVNサーバー上)で実行します。
-
リポジトリから内容をダンプファイルとして抽出 (
svnadmin dump
)bash
svnadmin dump REPOS_PATH [-r LOW_REV[:HIGH_REV]] [--incremental] [--deltas] > DUMP_FILEREPOS_PATH
: ダンプしたいSVNリポジトリへのファイルシステムパス。-r LOW_REV[:HIGH_REV]
(オプション): ダンプするリビジョンの範囲を指定します。省略すると全リビジョンがダンプされます。--incremental
(オプション): 指定したリビジョン範囲の変更を、その範囲の開始リビジョンからの差分としてではなく、直前のリビジョンからの差分として出力します。全リビジョンをダンプする場合は不要です。増分バックアップなどに使用します。--deltas
(オプション): ファイルの内容の差分(テキストデルタ)やプロパティの差分をダンプファイルに含めます。これによりダンプファイルサイズが小さくなる可能性があります。通常は指定するのが良いでしょう。> DUMP_FILE
: 標準出力されるダンプ内容をファイルにリダイレクトします。
ダンプファイル形式について:
ダンプファイルは人間が読めるテキスト形式(ただしバイナリデータはエンコードされる)で、各リビジョンまたは増分変更の情報がブロックとして含まれます。ヘッダー情報、リビジョンプロパティ、ファイル・ディレクトリの追加/変更/削除情報、ファイル内容などが含まれます。 -
新しい(または既存の)リポジトリにダンプ内容をロード (
svnadmin load
)bash
svnadmin load NEW_REPOS_PATH [--ignore-uuid] [--force-uuid] [--parent-dir DIR] < DUMP_FILENEW_REPOS_PATH
: ロード先のSVNリポジトリへのファイルシステムパス。このリポジトリは事前にsvnadmin create
で作成しておく必要があります。--ignore-uuid
(オプション): ダンプファイルに含まれるリポジトリUUIDを無視し、ロード先リポジトリの既存UUIDを使用します。別のリポジトリに移行・コピーする場合は通常指定します。--force-uuid
(オプション): ダンプファイルに含まれるリポジトリUUIDを強制的にロード先リポジトリに設定します。元リポジトリと全く同じUUIDを持つリポジトリを作成したい場合に指定します(あまり一般的ではないかもしれません)。--parent-dir DIR
(オプション): ダンプファイルの内容を、ロード先リポジトリの指定したディレクトリ以下にロードします。例えば、ダンプがリポジトリのルートから取得されている場合に、それを/projects/myproject
以下に配置したい場合などに使用します。< DUMP_FILE
: 標準入力としてダンプファイルを読み込みます。
ロード時の注意点:
ロードはダンプファイルの内容をリビジョン順に新しいリポジトリに適用していきます。リポジトリのサイズや履歴の量によっては時間がかかります。ロード中は、ロード先の新しいリポジトリにはアクセスしないようにする必要があります。また、ロード先のフック(特にpre-revprop-change
やpre-commit
)がロード処理に影響を与える可能性があるため、ロード前に無効化したり、ロード専用の設定にしたりすることがあります。
使用例:
-
既存リポジトリ
/var/svn/repos/myproject
の全履歴をダンプ:
bash
svnadmin dump /var/svn/repos/myproject --deltas > myproject.dump -
新しいリポジトリ
/var/svn/repos/myproject_copy
を作成し、ダンプ内容をロード:
bash
svnadmin create /var/svn/repos/myproject_copy
svnadmin load /var/svn/repos/myproject_copy --ignore-uuid < myproject.dump
これで、/var/svn/repos/myproject_copy
は/var/svn/repos/myproject
の完全なコピーとなります。 -
増分ダンプ(リビジョン1001から最新まで):
(事前にリビジョン1000までのフルダンプまたは増分ダンプを取得している場合)
bash
svnadmin dump /var/svn/repos/myproject -r 1001:HEAD --incremental --deltas > myproject.incremental.dump
この増分ダンプをロードする場合、既にリビジョン1000までロードされているリポジトリに対してロードします。bash
svnadmin load /var/svn/repos/myproject_backup < myproject.incremental.dump
方法B: svnrdump dump
& svnrdump load
(ネットワークアクセス)
svnadmin dump/load
はサーバー上のファイルシステムアクセスが必要でしたが、svnrdump
はURLを指定してネットワーク経由で同様の操作を行います。これは、サーバーにログインできない場合や、リモートにあるリポジトリを手元にコピーしたい場合に便利です。
-
リモートリポジトリから内容をダンプファイルとして抽出 (
svnrdump dump
)bash
svnrdump dump URL [-r LOW_REV[:HIGH_REV]] [--incremental] [--deltas] > DUMP_FILEURL
: ダンプしたいリモートリポジトリのURL。- その他のオプション (
-r
,--incremental
,--deltas
) はsvnadmin dump
と同様です。 - 認証が必要な場合は、
--username
,--password
,--non-interactive
などのオプションを使用します。
-
リモートまたはローカルの新しいリポジトリにダンプ内容をロード (
svnrdump load
)bash
svnrdump load NEW_REPOS_URL [--ignore-uuid] [--force-uuid] [--parent-dir DIR] < DUMP_FILENEW_REPOS_URL
: ロード先のSVNリポジトリのURL。これはローカルリポジトリのfile:///path/to/repos
形式のURLでも、リモートリポジトリのsvn://...
,http://...
,https://...
形式のURLでも構いません。ロード先の新しいリポジトリは、事前にsvnadmin create
(ローカルの場合)またはリモートで作成しておく必要があります。- その他のオプション (
--ignore-uuid
,--force-uuid
,--parent-dir
) はsvnadmin load
と同様です。 - 認証が必要な場合は、
--username
,--password
,--non-interactive
などのオプションを使用します。
使用例:
-
リモートリポジトリ
https://example.com/svn/myproject
の全履歴をダンプ:
bash
svnrdump dump https://example.com/svn/myproject --deltas > myproject.dump
(認証が必要な場合は--username myuser --password mypass --non-interactive
などを追加) -
ローカルに新しいリポジトリ
/home/user/svn/myproject_local_copy
を作成し、ダンプ内容をロード:
bash
svnadmin create /home/user/svn/myproject_local_copy
svnrdump load file:///home/user/svn/myproject_local_copy --ignore-uuid < myproject.dump -
リモートの別の場所に新しいリポジトリ
https://backup.example.com/svn/myproject_backup
を作成し、ダンプ内容をロード:
(事前にリモートサーバーbackup.example.com
に新しいリポジトリを作成しておく必要があります)
bash
svnrdump load https://backup.example.com/svn/myproject_backup --ignore-uuid < myproject.dump
(認証が必要な場合は--username backupuser --password backuppass --non-interactive
などを追加)
svnadmin dump/load
または svnrdump dump/load
を使うべきケース:
- リポジトリの完全なバックアップを作成したい場合。
- リポジトリを別のサーバーや別の場所に移行したい場合。
- 元リポジトリとは独立した、全履歴を持つコピーを生成したい場合。
svnsync
が利用できない(例:pre-revprop-change
フックを設定できない)環境でミラーを作成したい場合(ただし、この場合は手動またはスクリプトでの定期的なダンプ&ロードが必要)。
これらの方法はリポジトリのサイズが大きい場合、非常に時間がかかる可能性があることに注意が必要です。
シナリオ3: リポジトリの更新を追随するミラー(レプリカ)を作成する – svnsync
svnsync
コマンドは、あるリポジトリ(ソースリポジトリ)の変更を、別のリポジトリ(デスティネーションリポジトリ、またはミラーリポジトリ)に逐次的にコピーするために使用します。これは、継続的なバックアップや、読み取り専用のレプリカ提供に最適です。
svnsync
の仕組み:
svnsync
は、ソースリポジトリから新しいリビジョンが発生するたびに、そのリビジョンの変更内容(ファイルやプロパティの変更)を読み取り、それをデスティネーションリポジトリに新しいリビジョンとしてコミットします。デスティネーションリポジトリには、同期元のURLと最後に同期したリビジョン番号がリポジトリプロパティとして記録されます。これにより、次回実行時に前回の続きから同期を再開できます。
svnsync
は、デスティネーションリポジトリへのコミット権限が必要ですが、通常のコミットとは異なり、リビジョンプロパティ(svn:author
, svn:date
, svn:log
など)もソースリポジトリからそのままコピーします。通常、これらのリビジョンプロパティはコミット時に自動的に設定され、後から変更するには特別な権限と svn propset --revprop
コマンドが必要であり、さらにリポジトリ側の pre-revprop-change
フックで明示的に許可されていなければなりません。svnsync
を利用するには、デスティネーションリポジトリ側で pre-revprop-change
フックを設定し、svnsync
がリビジョンプロパティを変更することを許可する必要があります。これは svnsync
を使う上で最も重要な設定手順です。
基本的な手順:
-
デスティネーションリポジトリを作成する:
svnadmin create /path/to/destination/repos
-
デスティネーションリポジトリに
pre-revprop-change
フックを設定する:
リポジトリディレクトリ内のhooks
ディレクトリにpre-revprop-change
という名前の実行可能ファイルを作成します。このフックは、誰がどのリビジョンプロパティを変更しようとしているかをチェックし、許可する場合は終了コード0を返します。svnsync
が使う特定のリビジョンプロパティ(svn:sync-from
,svn:sync-last-merged-rev
, および同期されるリビジョンプロパティsvn:author
,svn:date
,svn:log
,svn:original-date
など)の変更を、svnsync
を実行するユーザーに対して許可するように記述します。簡単な例(すべてのリビジョンプロパティ変更を許可する – 非推奨、危険):
“`bash!/bin/sh
exit 0
より安全な例(`svnsync` ユーザーによる特定のプロパティ変更のみ許可):
bash!/bin/sh
USER=”$3″
PROPNAME=”$4″
if [ “$USER” = “syncuser” ]; then # ‘syncuser’ は svnsync 実行ユーザー名に置き換える
case “$PROPNAME” in
svn:log|svn:author|svn:date|svn:original-date|svn:sync-from|svn:sync-last-merged-rev)
exit 0 # 許可するプロパティ
;;
*)
# その他のプロパティ変更は拒否
echo “Changing revision property ‘$PROPNAME’ is not allowed by user ‘$USER’.” >&2
exit 1
;;
esac
else
# svnsync ユーザー以外のリビジョンプロパティ変更は拒否
echo “User ‘$USER’ is not allowed to change revision properties.” >&2
exit 1
fi
``
pre-revprop-change
(ファイル名:, 実行権限を付与:
chmod +x pre-revprop-change`) -
デスティネーションリポジトリを初期化する (
svnsync initialize
)
このコマンドは、デスティネーションリポジトリに同期情報を設定し、ソースリポジトリの最初のコミットをデスティネーションリポジトリにコピーします。bash
svnsync initialize file:///path/to/destination/repos https://example.com/svn/source/reposfile:///path/to/destination/repos
: デスティネーションリポジトリのURL。svnsync
コマンドを実行するユーザーが書き込み権限を持つURLを指定します。ローカルリポジトリ、svn://
,http://
,https://
など。https://example.com/svn/source/repos
: ソースリポジトリのURL。読み取り権限が必要です。- 認証が必要な場合は
--username
,--password
,--non-interactive
などを追加します。 --allow-non-empty
: 初期化対象のデスティネーションリポジトリが空でない場合でも初期化を強制します(通常は空のリポジトリに対して行います)。
初期化が成功すると、デスティネーションリポジトリのプロパティに
svn:sync-from
(ソースリポジトリのURL) とsvn:sync-last-merged-rev
(初期化時のリビジョン番号、通常0) が設定されます。 -
同期を実行する (
svnsync synchronize
)
このコマンドは、ソースリポジトリのsvn:sync-last-merged-rev
以降の新しいリビジョンをデスティネーションリポジトリにコピーします。定期的に実行することで、ミラーを最新の状態に保ちます。bash
svnsync synchronize file:///path/to/destination/reposfile:///path/to/destination/repos
: デスティネーションリポジトリのURL。初期化時と同じURLを指定します。- 認証が必要な場合は
--username
,--password
,--non-interactive
などを追加します。
このコマンドを実行すると、
svnsync
はソースリポジトリをチェックし、前回同期したリビジョンの次のリビジョンから最新リビジョンまでを順番にデスティネーションリポジトリにコピーしていきます。各リビジョンがコピーされるたびに、デスティネーションリポジトリのsvn:sync-last-merged-rev
プロパティが更新されます。
svnsync
を使うべきケース:
- ソースリポジトリの変更に常に追随する、ほぼリアルタイムのバックアップを作成したい場合。
- 読み取り専用のレプリカを作成し、メインリポジトリへのアクセス負荷を分散したい場合。
- 定期的な同期ジョブ(cronなど)を設定して、自動的にミラーを最新に保ちたい場合。
svnsync
の注意点:
- デスティネーションリポジトリへの
pre-revprop-change
フック設定が必須です。 - 同期は一方向のみです(ソース → デスティネーション)。デスティネーションリポジトリに直接コミットすることは推奨されません(通常、フックで禁止します)。
- リビジョンプロパティの変更も同期されますが、デスティネーション側でリビジョンプロパティを変更した場合、
svnsync
はその変更を上書きする可能性があります。 - ソースリポジトリで歴史の書き換え(例:
svnadmin dump/load
で一部履歴をスキップするなど)が行われた場合、svnsync
はエラーになる可能性があります。
どの方法を選択すべきか?目的別ガイド
ここまで、SVNでリポジトリを「クローン」する(コピー・取得する)ための複数の方法を見てきました。あなたがどの方法を選択すべきかは、最終的にあなたの「目的」によって決まります。
-
目的:リポジトリの内容をローカルで編集・コミットしたい(開発作業)
- →
svn checkout
を使用します。これはGitでいう一般的なgit clone
に最も近く、開発作業用のローカル作業コピーを作成します。履歴全体はローカルに持ちませんが、.svn
ディレクトリを通じて中央リポジトリと連携します。
- →
-
目的:リポジトリ全体(全履歴含む)を別の場所(ローカルまたはリモート)に完全にコピーしたい
- リポジトリのファイルシステムに直接アクセスできる場合:
svnadmin dump
&svnadmin load
を使用します。 - ネットワーク経由でリモートリポジトリをコピーしたい場合:
svnrdump dump
&svnrdump load
を使用します。 - これらの方法は、リポジトリのバックアップ、移行、または独立した複製作成に適しています。作成されるのは元リポジトリと全く同じ履歴を持つ新しいリポジトリです。
- リポジトリのファイルシステムに直接アクセスできる場合:
-
目的:リポジトリの更新に追随するリアルタイムに近いミラー(レプリカ)を作成したい
- →
svnsync
を使用します。ソースリポジトリの変更をデスティネーションリポジトリに逐次コピーし、常に最新の状態に近いレプリカを維持します。pre-revprop-change
フックの設定が必要です。
- →
SVNとGit:「クローン」概念の根本的な違い
改めて、SVNに svn clone
コマンドが存在しない理由と、Gitの clone
との概念的な違いについてまとめます。
Git (分散型バージョン管理システム)
- 各ユーザーのローカルマシン上のリポジトリが、プロジェクトの全履歴を含む完全なコピーです。
git clone
は、リモートリポジトリからこの完全な履歴をローカルに複製し、さらに元のリモートリポジトリを「origin」などの名前で追跡対象として設定します。- ローカルでのコミットは、すぐにリモートに送信する必要はありません。複数のコミットをまとめて
push
したり、ローカルでブランチを自由に作成・マージしたりできます。
SVN (集中型バージョン管理システム)
- プロジェクトの全履歴は、中央の単一のリポジトリにのみ存在します。
- ユーザーがローカルに持つのは、中央リポジトリの特定のパス、特定のリビジョンの作業コピー (Working Copy) です。作業コピーは履歴全体ではなく、その時点のスナップショットと、中央リポジトリとの連携に必要なメタデータ(
.svn
ディレクトリ)を含みます。 - 変更を共有するには、作業コピーで変更を行い、中央リポジトリに
commit
する必要があります。他のユーザーの変更を取得するにはupdate
します。
このアーキテクチャの違いにより、Gitでは「リポジトリ全体をまるごと複製する」という clone
操作が基本となるのに対し、SVNでは「中央リポジトリから特定のパスの内容をローカルに取得して作業コピーとする」という checkout
操作が基本となります。SVNでGitの clone
に相当する「リポジトリ全体の完全なコピー」が必要な場合は、svnadmin dump/load
や svnrdump dump/load
といった、リポジトリ管理の側面が強いコマンドを使用することになります。また、継続的なレプリカとしては svnsync
を使用します。
「svn clone
」という言葉に縛られず、SVNのアーキテクチャと提供されているコマンドを理解し、目的に合わせて最適な方法を選択することが重要です。
まとめ:SVNでのリポジトリコピー・取得をマスターする
この記事では、「svn clone
コマンド」というユーザーの問い合わせを起点に、Subversionにおいてリポジトリをコピーしたり、ローカルに取得したりするための実際的な方法について、詳細な解説を行いました。
繰り返しになりますが、Subversionには svn clone
という直接的なコマンドは存在しません。これは、SVNが集中型バージョン管理システムであることに由来します。Gitのような分散型システムとは、「クローン」という操作が持つ意味合いや必要性が異なるためです。
しかし、SVNでも以下の方法によって、Gitの clone
が達成するような目的や、リポジトリのコピー・管理に関する様々なニーズを満たすことができます。
-
ローカルで開発作業を始めたい:
svn checkout (svn co)
コマンドを使用します。リポジトリの特定のパスの特定リビジョンのスナップショットを作業コピーとして取得します。Gitの一般的なclone
に最も近い操作ですが、履歴全体はローカルに保持しません。--depth
オプションで取得する深度を制御できます。
-
リポジトリ全体(全履歴含む)を完全に複製・バックアップ・移行したい:
- リポジトリにファイルシステムアクセスできる場合:
svnadmin dump
でダンプファイルを作成し、svnadmin load
で別のリポジトリにロードします。 - ネットワーク経由で操作したい場合:
svnrdump dump
でダンプファイルをネットワーク経由で取得し、svnrdump load
でネットワーク経由またはローカルにロードします。 - これらの方法は、リポジトリの完全なコピーを作成し、独立した新しいリポジトリとして利用したり、長期保存用のバックアップとしたりするのに適しています。
- リポジトリにファイルシステムアクセスできる場合:
-
リポジトリの更新を継続的に追随するミラー(レプリカ)を作成したい:
svnsync
コマンドを使用します。デスティネーションリポジトリを初期化 (svnsync initialize
) し、定期的に同期 (svnsync synchronize
) することで、ソースリポジトリの変更を自動的に取り込みます。デスティネーションリポジトリでのpre-revprop-change
フック設定が必須です。主にバックアップや読み取り専用レプリカとして利用されます。
これらのコマンドとそのオプション、使用例、そしてそれぞれの方法が適しているシナリオを理解することで、あなたはSVNリポジトリの取得、コピー、管理に関する様々なタスクを自信を持って実行できるようになります。
SVNは成熟した安定したバージョン管理システムであり、適切に運用すれば大規模なプロジェクトでも十分に機能します。この記事が、あなたがSVNをより深く理解し、Gitの「クローン」のような操作をSVNで自在に行うための一助となれば幸いです。
SVNのコマンドは、リポジトリの構造やアーキテクチャと密接に結びついています。それぞれのコマンドの役割と目的を正しく理解することが、効果的なSVN運用への鍵となります。ぜひ、この記事で解説した各コマンドを実際に試して、その挙動を確認してみてください。
これで、SVNリポジトリをコピーまたは取得するための様々な方法についての詳細な解説は終わりです。あなたのSVNでの作業が、より効率的で生産的になることを願っています。
注記: 上記の記事は、ユーザーの「svn clone
」という表現をSVNでのリポジトリコピー/取得に関するニーズと解釈し、SVNでその目的に最も近い操作を実現するコマンド群について、詳細な解説を行ったものです。Subversionのバージョンによっては、コマンドのオプションや挙動に若干の違いがある場合があります。ご利用のSVNクライアントおよびサーバーのバージョンに合わせて、公式ドキュメントも参照することを推奨します。コマンドの使用にあたっては、特に svnadmin
や svnsync
の操作はリポジトリ全体に影響を与える可能性があるため、十分な理解と注意が必要です。