Subversionとは何ですか？なぜ存在するのですか？ ¶

Subversionは、オープンソースの中央集中型バージョン管理システムです。Subversionが存在する理由については、フロントページの「私たちのビジョン」をご覧ください。手っ取り早く見たいですか？「クイックスタート」をご覧ください。

Subversionはプロプライエタリソフトウェアですか？ ¶

いいえ、Subversionはオープンソース/フリーソフトウェアです。いくつかの企業（CollabNet、WANdisco、VisualSVN、elegoなど）が一部のフルタイム開発者の給与を支払うか、過去に支払っていましたが、このソフトウェアには、Apache Licenseが付与されており、これはDebianフリーソフトウェアガイドラインに完全に準拠しています。言い換えれば、Subversionを自由にダウンロード、変更、再配布できます。いかなる企業や個人からの許可も必要ありません。

Subversionの安定性はどの程度ですか？ ¶

Subversionは非常に安定しています。成熟したソフトウェアであり、強力な互換性保証があります。Subversionの開発コミュニティは、その安定性と堅牢性を非常に重視しています。

Subversionは2000年から開発が開始され、1年後には自己ホスティングになりました。1年後に「アルファ」を宣言したとき、Subversionはすでに数十の個人開発者や企業で実際の作業に使用されていました。その後、バグ修正と安定化にさらに2年を費やし、バージョン1.0に到達しました。他のほとんどのプロジェクトはおそらくもっと早く製品を「1.0」と呼んだでしょうが、可能な限り長くそのラベルを遅らせることを意図的に決定しました。多くの人がSubversionを使用する前に1.0を待っており、そのラベルの意味について非常に具体的な期待を抱いていることを知っていたからです。そこで私たちは同じ基準を固守しました。

Subversionのクライアント/サーバーの相互運用性ポリシーは何ですか？ ¶

クライアントとサーバーは、メジャーリリースバージョンが1つ以上離れていなければ動作するように設計されています。たとえば、1.Xクライアントはすべて1.Yサーバーで動作します。ただし、クライアントとサーバーのバージョンが一致しない場合、特定の機能が利用できない場合があります。このような制限は、常にリリースのリリースノートに記載されています。

当社のクライアント/サーバーの相互運用性ポリシーは、Subversionコミュニティガイドの「互換性」セクションに記載されています。

Subversionはどのオペレーティングシステムで実行できますか？ ¶

すべての最新のUnix、Windows、BeOS、OS/2、macOS。

SubversionはANSI Cで記述されており、移植性レイヤーとしてApache Portable RuntimeライブラリであるAPRを使用します。Subversionクライアントは、APRが実行されるほとんどの場所で実行されます。Subversionサーバー（つまり、リポジトリ側）も同様ですが、Berkeley DBはWin9xプラットフォーム（Win95/Win98/WinME）では共有メモリセグメントの問題があるため、Berkeley DBリポジトリをホストしません。FSFSリポジトリ（バージョン1.1で導入）にはこの制限はありません。ただし、Win9xのファイルロックサポートの制限により、Win9xでは動作しません。

繰り返しますが、Subversionクライアントは、APRが実行される任意のプラットフォームで実行できます。SubversionサーバーもAPRが実行される任意のプラットフォームで実行できますが、Win95/Win98/WinMeではリポジトリをホストできません。

この新しいファイルシステムとは何ですか？ ext2のようなものですか？ ¶

いいえ。「Subversionファイルシステム」は、オペレーティングシステムにインストールするカーネルレベルのファイルシステムではありません。代わりに、これはSubversionのリポジトリインターフェイスであり、リビジョンごとに状態が記憶されるディレクトリツリーを格納するという意味で「バージョン管理されたファイルシステム」です。リポジトリにアクセスするプログラムの作成は、他のファイルシステムAPIを使用するプログラムの作成に似ています。主な違いは、この特定のファイルシステムは書き込み時にデータを失わないことです。古いツリーの状態は、最新の状態と同じくらい簡単に取得できます。

Subversionサーバーを実行するためにどのようなハードウェアが必要ですか？ ¶

サーバーの要件は、ユーザー数、コミットやその他のサーバー関連操作の頻度、リポジトリサイズ、カスタムリポジトリフックによって生成される負荷など、多くの要因によって異なります。Apacheを使用する場合、メモリ使用量における最大の要因はApache自体になる可能性があります。

同じサーバーで実行されている他のアプリケーションも考慮に入れることを忘れないでください。たとえば、リポジトリブラウザーもSubversionとは関係なくリソースを使用します。

一般的に、同等のCVSリポジトリよりも必要なサーバーメモリははるかに少ないと予想できます。

SubversionはApache拡張機能だと聞きました。サーバーには何を使用するのですか？ ¶

いいえ。Subversionはライブラリのセットです。それらを使用するコマンドラインクライアントが付属しています。Subversionサーバープロセスは2つあります。1つはcvs pserverに似た小さなスタンドアロンプログラムであるsvnserve、もう1つは特別なmod_dav_svnモジュールを使用するApache httpd-2.0です。svnserveはカスタムプロトコルを使用し、mod_dav_svnはネットワークプロトコルとしてWebDAVを使用します。詳細については、Subversion本の第6章を参照してください。

これは、Subversionを使用するためにApacheを設定する必要があるということですか？ ¶

簡単に言うと、いいえ。

詳しく言うと、リポジトリにアクセスするだけの場合は、Subversionクライアントをビルドするだけで済みます。ネットワーク化されたリポジトリをホストする場合は、Apache2または「svnserve」サーバーを設定する必要があります。

ネットワークアクセス可能なSubversionサーバーの設定の詳細については、Subversion本の第6章を参照してください。

現在Apache 1.xを実行しており、Subversionリポジトリを公開するためだけにApache 2.0に切り替えることはできません。これは、Subversionサーバーを実行できないという意味ですか？ ¶

いいえ、Subversionサーバーとしてsvnserveを実行できます。これは非常にうまく機能します。

WebDAVやApacheサーバーに付属するその他の「グッズ」が必要な場合は、Apache 2.0が必要です。Apache 1.xをポート80で実行し続けながら、別のポートでApache 2.0を実行することは常にオプションです。異なるバージョンのApacheは、同じマシン上で問題なく共存できます。httpd.confのListenディレクティブを「Listen 80」から「Listen 8080」または必要なポート番号に変更し、リポジトリURLを公開するときにそのポートを指定してください（例：http://svn.mydomain.com:8080/repos/blah/trunk/).

SCMシステムYのようにXをしないのはなぜですか？ ¶

Subversionは、既存のすべてのSCMシステムのすべての機能を模倣しようとしているわけではありません。私たちのビジョンをご覧ください。

なぜリポジトリ全体が同じリビジョン番号を共有するのですか？各プロジェクトに独自のリビジョン番号を持たせたいのですが。 ¶

まず、Subversionにはプロジェクトの概念がないことに注意してください。リポジトリは、バージョン管理されたディレクトリツリーを格納するだけです。特定のサブツリーをプロジェクトと見なすことができますが、Subversionは他のサブツリーとは異なって扱いません。したがって、リポジトリでプロジェクトを構成するものの解釈は、完全にユーザーに委ねられています。（これは、ブランチやタグが、Subversion自体に組み込まれた基本概念ではなく、コピーの上に構築された慣例であるのと似ています。）

変更をコミットするたびに、リポジトリはリポジトリツリー全体の新しいリビジョンを格納し、新しいツリーに新しいリビジョン番号を付けます。もちろん、ツリーの大部分は変更した部分を除いて、前のリビジョンと同じです。

新しいリビジョン番号は、そのリビジョンで触れたファイルとディレクトリだけでなく、新しいツリー全体に適用されるシーケンシャルなラベルです。ただし、口語的には、リビジョン番号は、そのリビジョンでコミットされた変更を参照するために使用されます。たとえば、「r588の変更」（「r588」は「リビジョン588」の略）は、実際には「リポジトリツリー587と588の違い」、または別の言い方をすると、「ツリー587を作成してツリー588を生成するために行われた変更」を意味します。

したがって、進むリビジョン番号は、リポジトリ全体の進行状況を示します。通常、リビジョン番号を監視して、リポジトリ内の特定のプロジェクトの進行状況を測定することはできません。また、リビジョン番号は、リポジトリ内の特定のプロジェクトの公開表示可能なリリース番号として使用しないでください。そのためには、タグを使用するなど、リリースを区別する別のメカニズムを考案する必要があります。

Subversionにはチェンジセットはありますか？ ¶

この質問は少し誘導的です。なぜなら、誰もが「チェンジセット」の定義が少し異なっているか、少なくとも、バージョン管理システムに「チェンジセット機能」があるという意味について少し異なる期待を持っているように見えるからです。

この議論の目的のために、チェンジセットの簡単な定義を次に示します。それは、一意の名前を持つ変更のコレクションです。変更には、ファイルの内容に対するテキスト編集、ツリー構造の変更、メタデータの調整などが含まれる場合があります。より一般的な言い方をすると、チェンジセットとは、参照できる名前を持つパッチにすぎません。

Subversionは、バージョン管理されたツリーを第一級オブジェクトとして管理し（リポジトリはツリーの配列です）、チェンジセットは（隣接するツリーを比較することによって）導出されるものです。ArchやBitkeeperのようなシステムは、その逆の方法で構築されています。それらは、チェンジセットを第一級オブジェクトとして管理するように設計されており（リポジトリはパッチのバッグです）、ツリーはパッチのセットを一緒に構成することによって導出されます。

どちらの哲学も絶対的な意味で優れているわけではありません。議論は少なくとも30年前から続いています。2つの設計は、異なるタイプのソフトウェア開発で優れているか劣っています。ここではそれについては議論しません。代わりに、Subversionで何ができるかの説明を次に示します。

Subversionでは、グローバルリビジョン番号「N」はリポジトリ内のツリーの名前です。これは、N回目のコミット後のリポジトリの状態です。また、暗黙のチェンジセットの名前でもあります。ツリーNをツリーN-1と比較すると、コミットされた正確なパッチを導き出すことができます。

このため、「リビジョンN」を単なるツリーではなく、チェンジセットとしても考えるのは簡単です。バグを管理するために問題トラッカーを使用する場合、リビジョン番号を使用して、バグを修正する特定のパッチを参照できます。たとえば、「この問題はリビジョン9238で修正されました。」その後、誰かが「svn log -r9238」を実行して、バグを修正した正確なチェンジセットについて読み、また、「svn diff -r9237:9238」を実行して、パッチ自体を確認できます。また、svnのmergeコマンドもリビジョン番号を使用します。merge引数で名前を付けることで、特定のチェンジセットを1つのブランチから別のブランチにマージできます。「svn merge -r9237:9238 branchURL」は、チェンジセット＃9238をワーキングコピーにマージします。

これは、チェンジセットを主要オブジェクトとして構築されたシステムほど複雑ではありませんが、CVSよりもはるかに便利です。

次のリリースはいつですか？ ¶

ロードマップページをご覧ください。

Subversionはシンボリックリンクをサポートしていますか？ ¶

Subversion 1.1 (およびそれ以降) では、通常のsvn addコマンドを使って、(unix) シンボリックリンクをバージョン管理下に置くことができます。

詳細: Subversionのリポジトリには、シンボリックリンクの内部的な概念はありません。「バージョン管理されたシンボリックリンク」は、'svn:special'プロパティが付いた通常のファイルとして保存されます。svnクライアント (unix) は、このプロパティを見て、作業コピー内のファイルをシンボリックリンクに変換します。

Windowsでは、svnクライアントは現在、バージョン管理されたシンボリックリンクをWindowsのシンボリックリンクのバリアント(ジャンクションポイントなど) に変換する機能はサポートされていません。チェックアウトされたオブジェクトは、通常のファイルとして表示されます。これを一般的にサポートすることを困難にしている問題の1つは、デフォルトでは管理者のみがWindowsでシンボリックリンクを作成できることです。詳細については、issue SVN-3570を参照してください。

Subversionのロゴの高解像度版が必要なのですが、どこで入手できますか？ ¶

Subversionのロゴには、以下のバージョンがあります。

• SVG バージョン
• EPS バージョン
• Adobe Illustrator ドキュメント

追加のアートワークは、Subversionのソースツリーの notes/logo の下、およびこのWebサイトで入手できます。

他に質問があります。どこで詳細情報を入手できますか？ ¶

このFAQを閲覧しても答えが見つからない場合は、他にいくつかのリソースがあります。

• Subversion Book (オンラインで無料で読めます)
• Subversion Users メーリングリスト users@subversion.apache.org (詳細 (公開アーカイブ、購読、購読解除を含む)；モデレートあり)
• Subversion Users IRCチャンネル #svn (irc.libera.chat) (ウェブインターフェースまたはMatrixまたは任意のIRCソフトウェアを使用します。アーカイブはこちらにあります)。(IRCチャンネルは、2021年5月までfreenode.netでホストされていました。現在も存在している可能性がありますが、公式チャンネルとは認められなくなりました。)
• svnforum.org。メーリングリストとほぼ同じターゲットオーディエンスを持つ、非公式のウェブベースのフォーラム。

メーリングリストに投稿が表示されないのはなぜですか？ ¶

私たちのメーリングリストは、スパムが通過するのを防ぐためにモデレートされているため、リストへの最初の投稿は、モデレーターが許可するまで遅れる可能性があります。その投稿が許可されると、同じアドレスからの後続のすべての投稿は自動的に承認されるため、それ以上の遅延は発生しません。もちろん、送信元アドレスが変更された場合は、再度モデレーションを受ける必要があります。

Subversionは、夏時間 (DST) の変更によってどのように影響を受けますか？ ¶

夏時間の変更には、Subversionコードに対する特別な変更や修正は必要ありません。Subversionは、主に日付/時刻を使用して、変更がリポジトリにコミットされた日時を記録します。このコードはサーバー上で実行され、オペレーティングシステムから現在の日付/時刻を取得し、オペレーティングシステムが提供するルーチンを使用してUTCに変換します。Subversionクライアントは、これらの日付をサーバーから受信し、クライアントオペレーティングシステムが提供するルーチンを使用して、表示のためにローカルタイムゾーンに変換します。したがって、オペレーティングシステム用に提供されたパッチをインストールするだけで済みます。また、サーバーの時刻が夏時間に合わせて適切に調整されていることを確認するだけで済みます。

SubversionはSHA-1ハッシュの衝突によってどのように影響を受けますか？ ¶

GoogleとCWIによる最初の既知のSHA-1衝突の公開により、SubversionでのSHA-1の使用におけるいくつかの関連する問題が明らかになりました。Subversionのコアはコンテンツインデックス作成にSHA-1に依存していませんが、次の補助機能でそのような目的で使用されていました。

• リポジトリデータ重複排除機能 ("rep cache")、および
• ワーキングコピーでのコンテンツ重複排除機能。

リポジトリデータ重複排除機能について言えば、これにより、衝突するSHA-1値を持つファイルにアクセスできなくなったり、そのようなファイルでデータが失われたりする可能性があります。同一のSHA-1を持つ異なるコンテンツがリポジトリに保存されるのを防ぐには、1.9.6または1.8.18にアップグレードしてください。これらはデフォルトで、そのような衝突を持つデータの保存を防ぎます。詳細については、SHA-1に関するアドバイザリーを参照してください。

これらの新しいリリースへのアップグレードが利用可能になるまで、Unixベースのサーバーは、ここにあるプリコミットフックを使用できます。ちなみに、Windowsプラットフォーム用のプリコミットスクリプトをWindowsの開発者から提出することを歓迎します。提出の詳細については、こちらを参照してください。

ワーキングコピーは、保存されたコンテンツの重複排除にSHA-1を使用しており、パフォーマンス上の理由から、クライアントは同じSHA-1チェックサムを持つコンテンツのフェッチを回避します。この問題の回避策は、まず衝突するオブジェクトの保存を防ぐことです。1.9.6へのアップグレードまたは前述のプリコミットスクリプトのインストールを通じて防ぐことができます。

SHA-1衝突のあるコンテンツの保存はサポートされていません。SHA-1ハッシュ値が衝突するコンテンツがある場合は、衝突を完全に回避するために、コミットする前にgzipで変換することをお勧めします。さらに、将来の重複の挿入を防ぐために1.9.6へのアップグレードを強くお勧めします。

Subversionのコードをチェックアウトするにはどうすればよいですか？ ¶

Subversionクライアントを使用します。

	$ svn co https://svn.apache.org/repos/asf/subversion/trunk subversion

これにより、Subversionソースツリーのコピーがローカルマシンのsubversionというディレクトリにチェックアウトされます。

リポジトリを作成するにはどうすればよいですか？ データをインポートするにはどうすればよいですか？ ¶

クイックスタートを参照してください。詳細については、Subversion Bookのクイックスタート手順を参照してください。

リポジトリのセットアップと管理の詳細については、Subversion Bookの第5章を参照してください。

既存のCVSリポジトリをSubversionリポジトリに変換するにはどうすればよいですか？ ¶

cvs2svn変換ツールが、ほとんどの人が使用しているツールであるようです。ソースはhttps://github.com/mhagger/cvs2svnでホストされています。LinuxまたはBSDベースのシステムを実行している場合、ディストリビューションにcvs2svnパッケージが含まれている場合があります。

cvs2svnがニーズを満たさない場合は、Lev Serebryakovが作成したrefinecvsをhttp://lev.serebryakov.spb.ru/refinecvs/で試してください。

プロキシの背後にいる場合はどうなりますか？ ¶

Subversionクライアントは、プロキシを使用するように構成すると、プロキシを介して接続できます。まず、"servers"構成ファイルを編集して、使用するプロキシを指定します。ファイルの場所は、オペレーティングシステムによって異なります。LinuxまたはUnixでは、 "~/.subversion"ディレクトリにあります。Windowsでは、 "%APPDATA%\Subversion"にあります。( "echo %APPDATA%"を試してください。これは隠しディレクトリであることに注意してください。)

ファイルには、実行する内容を説明するコメントがあります。そのファイルがない場合は、最新のSubversionクライアントを入手して、任意のコマンドを実行してください。これにより、構成ディレクトリとテンプレートファイルが作成されます。

次に、プロキシサーバー自体が、Subversionが使用するすべてのHTTPメソッドをサポートしていることを確認する必要があります。一部のプロキシサーバーは、デフォルトではこれらのメソッドをサポートしていません: PROPFIND, REPORT, MERGE, MKACTIVITY, CHECKOUT。一般に、これを解決する方法は、特定のプロキシソフトウェアによって異なります。Squidの場合、構成オプションは次のとおりです。

   #  TAG: extension_methods
   #       Squid only knows about standardized HTTP request methods.
   #       You can add up to 20 additional "extension" methods here.
   #
   #Default:
   # none
   extension_methods REPORT MERGE MKACTIVITY CHECKOUT

(Squid 2.4以降は、すでにPROPFINDについて知っています。)

プロキシを介して許可する追加のHTTPメソッドに関するアドバイスについては、「Subversionが使用するすべてのHTTPメソッドは何ですか？」も参照してください。

プロキシでSubversionトラフィックを許可することが困難または不可能な場合でも、Subversionソースをチェックアウトしたい場合は、プロキシを迂回できる場合があります。ポート80をフィルタリングする一部のプロキシは、ポート81で何もかも許可します。他の多くの場合、プロキシはhttpsをhttpほど厳密にフィルタリングしません。svn.apache.orgリポジトリサーバーは、httpだけでなくhttpsでもリッスンします。次のコマンドを試してください。

   svn checkout https://svn.apache.org/repos/asf/subversion/trunk subversion

これで、プロキシが許可してくれるかもしれません。

もちろん、svnクライアントはsslサポートでビルドされている必要があります。 'https'スキームがサポートされているかどうかを確認するには、次のコマンドを実行します。svn --version.

リバースプロキシの背後にSubversionを配置する必要があります ¶

Subversionサーバーがインターネットに直接接続されていない場合は、リバースプロキシを使用できます。公開されているサーバーからSubversionサーバーにHTTP/HTTPSトラフィックを転送し、HTTPS暗号化を削除する可能性があります。また、複数の異なるHTTPサーバーを同じポートで提供する必要がある場合にも役立ちます。

Subversionは、WebDAV/DeltaVプロトコルのサブセットを使用します。詳細については、このFAQ項目を参照してください。プロキシサーバーに関する限り、SubversionはプレーンなWebDAVプロトコルを使用します。いつおよびsvn moveコマンドでは、追加のHTTP_DESTINATIONヘッダーが使用されます。これは別途書き換える必要があります。

いくつかの異なるプロキシサーバーの詳細な手順が提供されています。これらの例からアイデアをコピーすることは非常に簡単です。

Apache HTTPDの詳細な手順

以下の情報は、Konrad Rosenbaumが作成し、もともとhttp://silmor.de/proxysvn.phpにあった記事に基づいています。許可を得てコピーしました。

Apacheのプロキシ側では、mod_proxyが機能する必要があります。多くのLinuxディストリビューションには、アクティブ化できる既製の構成ファイルがありますが、それ以外の場合は、httpd.confにこの構成を挿入してください。

#load the module
LoadModule proxy_module modules/mod_proxy.so
#per default disallow all requests (for security)
ProxyRequests Off
<Proxy *>
  Order deny,allow
  Deny from all
</Proxy>
ProxyVia On

プロキシ仮想ホストのVirtualHostディレクティブで、subversionディレクトリ（ここではsvnとします）へのリクエストが実際

ProxyPass /svn/ http://realsvnserver/svn/
<Location /svn/>
        ProxyPassReverse /svn/ http://realsvnserver/svn/
        <Limit OPTIONS PROPFIND GET REPORT MKACTIVITY PROPPATCH PUT CHECKOUT
               MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
          Order Deny,Allow
          Allow from all
          Satisfy Any
        </Limit>
        
        RewriteCond %{HTTP:Destination} .+/(svn/.*$)
        RewriteRule ^/svn/.* - [E=MyDestination:http://realsvnserver/%1,PT]
        RequestHeader set Destination %{MyDestination}e env=MyDestination
</Location>

ProxyPassディレクティブは、/svn以下のリクエストをsubversion-Apache (http://realsvnserver/svn) にリダイレクトするようにApacheに指示します。ProxyPassReverseディレクティブは、リクエストヘッダー(Location、Content-Location、およびURI)をターゲットサーバーと一致するように変更するように指示します。Apacheのバージョンと構成によっては、/svn/またはhttp://realsvnserver/svn/のいずれかを省略する必要がある場合があります。可能であれば、両方のサーバーで同じパスを使用する必要があります（そうしないと、DAVが問題を起こす可能性があります）。Limitディレクティブは、すべてのクライアント（Allow）からのすべてのDAVリクエストをApacheに許可し、実際のsubversionサーバーに認証を処理させる（Satisfy）ように指示します。Rewriteルールは、HTTP_DESTINATIONヘッダーを正しいサーバー/プロトコルに更新します。

Microsoft IISの詳細な手順

まず、iis.netからURL Rewriteモジュールをダウンロードしてインストールします。以下の例は、IIS 10およびURL Rewrite 2.1でテストされています。
次に、HTTP_DESTINATIONサーバー変数を許可するようにURL Rewriteを構成します。IISマネージャーの[URL書き換え]で、右側のウィンドウで[サーバー変数の表示]をクリックし、[HTTP_DESTINATION]を追加します。
最後に、いくつかの書き換えルールを作成します。

• "ToHttps"。すべてのSubversionトラフィックを暗号化する場合は、リクエストが暗号化されていない場合に、HTTPリダイレクトをクライアントに送信します。
• "ProxyWithDestination"。HTTP_DESTINATIONサーバー変数を含むすべてのリクエスト（つまり、すべてのいつおよびsvn moveリクエスト）をキャプチャします。HTTP_DESTINATIONヘッダーが書き換えられ、トラフィックがSubversionサーバーに転送されます。
• "ProxyRest"。その他すべてのトラフィックをSubversionサーバーに転送します。

<system.webServer>
 <rewrite>
  <rules>
   <clear />
   <rule name="ToHttps" stopProcessing="true">
    <match url="(.*)" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
     <add input="{HTTPS}" pattern="^OFF$" />
    </conditions>
    <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}"/>
   </rule>
   <rule name="ProxyWithDestination" enabled="true" patternSyntax="ECMAScript" stopProcessing="true">
    <match url="(.*)" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
     <add input="{HTTP_DESTINATION}" pattern="https://(.*)"/>
    </conditions>
    <serverVariables>
     <set name="HTTP_DESTINATION" value="http://{C:1}" />
    </serverVariables>
    <action type="Rewrite" url="http://127.0.0.1:81/{R:0}" logRewrittenUrl="true" />
   </rule>
   <rule name="ProxyRest" patternSyntax="ECMAScript" stopProcessing="true">
    <match url="(.*)" negate="false" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="Rewrite" url="http://127.0.0.1:81/{R:0}" logRewrittenUrl="true" />
   </rule>
  </rules>
 </rewrite>
 <security>
  <requestFiltering allowDoubleEscaping="true" />
 </security>
</system.webServer>

管理者から Subversion 用に HTTP サーバーを立てることを許可されていません。リモートから使用したい場合はどうすればいいですか？ ¶

簡単なオプションは、Apache の代わりに svnserve サーバーを使用することです。詳細については、Subversion の書籍の第6章を参照してください。

ただし、管理者が Apache の実行を許可しない場合、ポート 3690 でカスタムサーバープロセスを実行することも許可しない可能性が高いです。したがって、この回答の残りの部分は、管理者が既存の SSH インフラストラクチャを使用することに同意していることを前提としています。

以前に CVS を使用していた場合、CVS サーバーにログインするために SSH を使用していたかもしれません。Subversion の ra_svn アクセス方法は、Subversion でこれを行う同等の方法です。Subversion リポジトリ URL に "svn+ssh" プレフィックスを使用するだけです。

$ svn checkout svn+ssh://your.domain.com/full/path/to/repository

これにより、SSH プログラムはリモートボックスでプライベートな 'svnserve' プロセスを起動し、それがあなたの UID としてリポジトリにアクセスし、暗号化されたリンクを介して情報をトンネルします。

ただし、別の解決策として、SSH ポートフォワーディングを利用して ra_dav 経由で保護されたサーバーに接続することもできます。Subversion サーバーにアクセスできるファイアウォールの背後にあるマシンに SSH 経由で接続します。この SSH サーバーは、Subversion がインストールされている場所と同じである必要はありません。同じでも構いませんが、必須ではありません。

次に、Subversion リポジトリを格納する HTTP サーバーに接続するローカルポートフォワードを作成します。このローカルポート経由で Subversion リポジトリに「接続」します。すると、リクエストは SSH サーバー経由で「トンネル」され、Subversion サーバーに送信されます。

例：Subversion ra_dav セットアップは、社内ファイアウォールの背後にある 10.1.1.50 (svn-server.example.com と呼びます) にあります。あなたの会社は、一般にアクセス可能な ssh-server.example.com を介した SSH アクセスを許可しています。内部的には、http://svn-server.example.com/repos/ours 経由で Subversion リポジトリにアクセスできます。

例：ポートフォワーディングを使用して ssh-server に接続し、ポートフォワード経由でチェックアウトするクライアント

% ssh -L 8888:svn-server.example.com:80 me@ssh-server.example.com
% svn checkout http://localhost:8888/repos/ours

svn-server.example.com の httpd インスタンスを、信頼されていないユーザーが権限のないポートで実行することもできます。これにより、Subversion サーバーが root アクセスを必要としなくなります。

Joe Orton の注釈

The server is sensitive to the hostname used in the Destination header
in MOVE and COPY requests, so you have to be a little careful here - a
"ServerAlias localhost" may be required to get this working properly.

SSH ポートフォワーディングに関するいくつかのリンク

• http://www.onlamp.com/pub/a/onlamp/excerpt/ssh_11/index3.html (archive.org)
• https://engineering.purdue.edu/ECN/Support/KB/Docs/SSHIntroductionToSSH

Subversion で複数の異なるプロジェクトを管理するにはどうすればよいですか？ ¶

これは、関係するプロジェクトによって異なります。プロジェクトが関連していて、データを共有する可能性が高い場合は、次のようにいくつかのサブディレクトリを持つ 1 つのリポジトリを作成するのが最善です。

	$ svnadmin create /repo/svn
	$ svn mkdir file:///repo/svn/projA
	$ svn mkdir file:///repo/svn/projB
	$ svn mkdir file:///repo/svn/projC

プロジェクトが完全に無関係で、データが共有される可能性が低い場合は、個別の無関係なリポジトリを作成するのがおそらく最善です。

	$ mkdir /repo/svn
	$ svnadmin create /repo/svn/projA
	$ svnadmin create /repo/svn/projB
	$ svnadmin create /repo/svn/projC

これら 2 つのアプローチの違いは次のとおりです (Ben Collins-Sussman <sussman@collab.net> による説明)

• 最初の場合、コードはプロジェクト間で簡単にコピーまたは移動でき、履歴が保持されます。（'svn cp/mv' は現在、単一のリポジトリ内でのみ機能します。）
• リビジョン番号はリポジトリ全体で適用されるため、最初の場合のいずれかのプロジェクトへのコミットは、グローバルなリビジョン番号の増加を引き起こします。そのため、誰かが「projB」をチェックアウトしていて、10件のリビジョンが発生したことに気付いても、projB がまったく変更されていない場合は、少し奇妙に感じるかもしれません。実際には大したことではありません。最初は少し奇妙なだけです。以前、raidsvn が同じリポジトリにあったときに、raidsvn にコミットするたびにこれが svn で発生していました。 :-)
• 2 番目のケースは、セキュリティ保護が容易になる可能性があります。Apache のアクセス制御を使用して、プロジェクトを互いに (ユーザーとアクセス許可の点で) 分離するのがより簡単です。最初のケースでは、プロジェクトを区別する("このユーザーはこの特定のサブディレクトリにコミットすることを許可されていますか?")ためのリポジトリに高度なフックスクリプトが必要になります。もちろん、そのようなスクリプトはすでに用意されており、使用できます。

完全に分離された 2 つのリポジトリをマージするにはどうすればよいですか？ ¶

リポジトリの 1 つのすべての履歴を保持することを気にしない場合は、1 つのプロジェクトのリポジトリの下に新しいディレクトリを作成し、もう一方をインポートするだけで済みます。

両方の履歴を保持することを気にする場合は、'svnadmin dump' を使用して 1 つのリポジトリをダンプし、'svnadmin load' を使用して他のリポジトリにロードできます。リビジョン番号はずれがありますが、履歴は残ります。

Peter Davis <peter@pdavis.cx> は、CVS モジュールに相当する svn を使用する方法も説明しています。

マージが個別のディレクトリツリーで行われる限り、svn の CVS モジュール版を使用できます。

元のディレクトリがチェックアウトされるたびに、他のリポジトリからディレクトリをチェックアウトするように、ディレクトリのsvn:externalsプロパティを設定します。リポジトリは分離されたままですが、ワーキングコピーでは、それらがマージされたように見えます。インポートされたディレクトリにコミットすると、外部リポジトリに影響します。

マージは完全にはクリーンではありません。インポートはワーキングコピーにのみ影響するため、最初のリポジトリの URL を使用して、2 番目のリポジトリからインポートされたモジュールにアクセスすることはできません。それらは別々の URL のままです。

また、いくつかのリポジトリをマージするときにリビジョンを選択および並べ替えるための便利なツールもインターネット上に存在します。たとえば、基本的な操作用の svn-merge-repos.pl perl スクリプトと、高度な再編成用の SvnDumpTool python クラスです。

NFS サーバーにリポジトリ/ワーキングコピーを保存する必要がありますか？ ¶

FSFS リポジトリバックエンドを使用している場合（Subversion 1.2 以降はデフォルト）、リポジトリを最新の NFS サーバー（つまり、ロックをサポートするサーバー）に保存しても問題ありません。

Berkeley DB バックエンドを使用するリポジトリ（Subversion 1.0 および 1.1 で作成されたリポジトリのデフォルトで、それ以降はデフォルトではありません）を使用している場合は、リポジトリをリモートファイルシステム（NFS など）に保存することはお勧めしません。Berkeley DB データベースとログファイルはリモートファイルシステムに保存できますが、Berkeley DB 共有領域ファイルはリモートファイルシステムに保存できないため、リポジトリは単一のファイルシステムクライアントのみが安全にアクセスでき、その 1 つのクライアントでもすべての Subversion 機能を利用できるわけではありません。

ワーキングコピーは NFS に保存できます（一般的なシナリオの 1 つは、ホームディレクトリが NFS サーバーにある場合です）。Linux NFS サーバーでは、ファイルのチェックアウト時に Subversion 内部で使用される名前変更の量が多く、一部のユーザーから 'サブツリーチェック' を無効にする必要があるとの報告があります (デフォルトでは有効になっています)。サブツリーチェックを無効にする方法の詳細については、NFS Howto サーバーガイドおよびexports(5) を参照してください。

SMB 経由でアクセスした後、ワーキングコピーが動かなくなったという報告が少なくとも 1 件ありました。問題のサーバーは、かなり古いバージョンの Samba (2.2.7a) を実行していました。新しい Samba (3.0.6) では、この問題は再発しませんでした。

リポジトリのアクセス許可を正しく設定するにはどうすればよいですか？ ¶

できるだけ少ないユーザーがリポジトリにアクセスするようにしてください。たとえば、apache または 'svnserve -d' を特定のユーザーとして実行し、リポジトリをそのユーザーが完全に所有するようにします。他のユーザーが次を介してリポジトリにアクセスすることを許可しないでくださいfile:///URL を使用し、'svnlook' および 'svnadmin' はリポジトリを所有するユーザーとしてのみ実行してください。

クライアントが次を介してアクセスしている場合file:///またはsvn+ssh://、複数のユーザーによるアクセスを回避する方法はありません。その場合は、第6章の最後のセクションを読み、「チェックリスト」のサイドバーに特に注意してください。このシナリオをより安全にするためのいくつかの手順の概要が示されています。

通常の Unix アクセス許可に加えて、SELinux ではすべてのファイル、ディレクトリ、プロセスなどに「セキュリティコンテキスト」があります。プロセスがファイルにアクセスしようとすると、Unix のアクセス許可をチェックすることに加えて、システムのプロセスセキュリティコンテキストがファイルのセキュリティコンテキストと互換性があるかどうかもチェックします。

Fedora Core 3 は、他のシステムの中でも特に、SELinux がデフォルトでインストールされ、Apache がかなり制限されたセキュリティコンテキストで実行されるように構成されています。Apache の下で Subversion を実行するには、Apache アクセスを許可するようにリポジトリのセキュリティコンテキストを設定する必要があります（または、これすべてが過剰であると思われる場合は、Apache の制限をオフにします）。chconコマンドは、ファイル（同様にchmod従来の Unix アクセス許可を設定します）のセキュリティコンテキストを設定するために使用されます。たとえば、あるユーザーは、このコマンドを発行する必要がありました

   $ chcon -R -h -t httpd_sys_content_t PATH_TO_REPOSITORY

セキュリティコンテキストを設定して、リポジトリに正常にアクセスできるようにします。

リポジトリの履歴からファイルを完全に削除するにはどうすればよいですか？ ¶

ファイルまたはコミットのすべての証拠を破棄する必要がある特別なケースがあります。（おそらく誰かが誤って機密文書をコミットしたのでしょう。）Subversion は情報を決して失わないように意図的に設計されているため、これはそれほど簡単ではありません。リビジョンは、互いに構築する不変のツリーです。履歴からリビジョンを削除すると、ドミノ効果が発生し、後続のすべてのリビジョンに混乱が生じ、すべてのワーキングコピーが無効になる可能性があります。

ただし、プロジェクトには、いつか情報を永続的に削除するタスクを実行する svnadmin obliterate コマンドを実装する計画があります。（issue 516 を参照してください。）

それまでの間、唯一の頼りは、リポジトリを svnadmin dump し、ダンプファイルを svndumpfilter （不正なパスを除外）から svnadmin load コマンドにパイプすることです。これの詳細については、Subversion の書籍の第5章を参照してください。

別の方法として、履歴からフィルター処理する必要があるパスへの読み取りアクセスを拒否する パスベースの認証ルールを構成した後、svnsync でリポジトリをレプリケートすることが挙げられます。svndumpfilter とは異なり、svnsync は、読み取り不可能なソースパスを含むコピー操作を通常の追加に自動的に変換します。これは、コピー操作を含む履歴をフィルター処理する必要がある場合に役立ちます。

コミット後にリビジョンのログメッセージを変更するにはどうすればよいですか？ ¶

ログメッセージは、各リビジョンに添付されたプロパティとしてリポジトリに保持されます。デフォルトでは、ログメッセージプロパティ（svn:log）は、コミットされると編集できません。それは、リビジョンプロパティ (svn:log がその 1 つ) を変更すると、プロパティの以前の値が永続的に破棄されるためです。Subversion は、これを誤って実行しないようにしています。ただし、Subversion にリビジョンプロパティを変更させる方法はいくつかあります。

最初の方法は、リポジトリ管理者がリビジョンプロパティの変更を有効にすることです。これは、「pre-revprop-change」というフックを作成することで行います（方法の詳細については、Subversionのドキュメントのこのセクションを参照してください）。「pre-revprop-change」フックは変更前の古いログメッセージにアクセスできるため、何らかの方法で（たとえば、メールを送信するなどして）それを保持できます。リビジョンプロパティの変更が有効になったら、svn propeditまたはsvn propsetに--revpropスイッチを渡すことで、リビジョンのログメッセージを変更できます。例えば、次のいずれかのようになります。

$ svn propedit -r N --revprop svn:log URL
$ svn propset -r N --revprop svn:log "new log message" URL

ここで、Nはログメッセージを変更したいリビジョン番号、URLはリポジトリの場所です。作業コピー内からこのコマンドを実行する場合は、URLを省略できます。

ログメッセージを変更する2番目の方法は、svnadmin setlogを使用することです。これは、ファイルシステム上のリポジトリの場所を参照して行う必要があります。このコマンドを使用してリモートリポジトリを変更することはできません。

$ svnadmin setlog REPOS_PATH -r N FILE

ここで、REPOS_PATHはリポジトリの場所、Nはログメッセージを変更したいリビジョン番号、FILEは新しいログメッセージを含むファイルです。「pre-revprop-change」フックが設定されていない場合（または何らかの理由でフックスクリプトをバイパスしたい場合）は、--bypass-hooksオプションを使用することもできます。ただし、このオプションを使用する場合は、十分に注意してください。変更のメール通知や、リビジョンプロパティを追跡するバックアップシステムなどの動作をバイパスしている可能性があります。

Subversionのパッチをどのように提出すればよいですか？ ¶

まず、Subversionコミュニティガイドをお読みください。

それを理解したら、[PATCH]という単語と件名に1行の説明を付けたメールを開発者リストに送信し、メールにパッチをインラインで含めます（MUAが完全に乱さない限り）。すると、コミッターがそれを受け取り、適用し（必要な書式設定や内容の変更を行い）、チェックインします。

基本的なプロセスは次のようになります。

	$ svn co https://svn.apache.org/repos/asf/subversion/site subversion-site
	$ cd subversion-site/publish

		[ make changes to faq.html ]
	
	$ svn diff faq.html > /tmp/foo

	$ Mail -s "[PATCH] FAQ updates" < /tmp/foo

もちろん、送信するメールには、Subversionコミュニティガイドに従って、パッチが何をするのかについての詳細な説明を含める必要がありますが、実際にはコードをハッキングする前に読んで完全に理解しているはずですよね？:)

何かやることがないか探していますか？アイデアページをご覧ください。

インプレース「インポート」（つまり、元のデータが直接作業コピーになるように、Subversionにツリーを追加する）を実行するにはどうすればよいですか？ ¶

たとえば、リポジトリ内の/etcの一部をバージョン管理下に置きたいとします。

     # svn mkdir file:///root/svn-repository/etc \
         -m "Make a directory in the repository to correspond to /etc"
     # cd /etc
     # svn checkout file:///root/svn-repository/etc ./
     # svn add apache samba alsa X11 
     # svn commit -m "Initial version of my config files"

これは、すぐには明らかにならない次の機能を利用します。svn checkout: リポジトリから既存のディレクトリに直接ディレクトリをチェックアウトできます。ここでは、まずリポジトリに新しい空のディレクトリを作成し、それを/etcにチェックアウトして変換します。/etc作業コピーになります。完了したら、通常のsvn addコマンドを使用して、リポジトリに追加するファイルとサブツリーを選択できます。

ディレクトリの内容の全体をインポートする場合（内容のサブセットではなく）、次のより短いコマンドシーケンスを使用してインポートを実行し、ディレクトリをSubversionの作業コピーに変換できます。

     # cd /etc
     # svn import file:///root/svn-repository/etc
     # svn checkout --force file:///root/svn-repository/etc .

インポートしたツリーを作業コピーに自動的に変換できるように、svn importを拡張するための問題が提起されています。 課題1328を参照してください。

Subversionサーバーをアップグレードする際に時々話題になる「ダンプ/ロードサイクル」とは何ですか？ ¶

Subversionのリポジトリデータベーススキーマは、開発中に時折変更されてきました。新機能を利用するには、バックエンドデータベースを再作成するために、リポジトリをダンプしてロードする必要がある場合があります。ただし、Subversionのほとんどのアップグレードでは、ダンプとロードは不要です。必要な場合は、新しいバージョンのリリースノートとCHANGESファイルに、それに関する目立つ通知が記載されます。そのような通知が表示されない場合は、スキーマの変更はなく、ダンプ/ロードは不要です。

ダンプ/ロードの代替手段は、svnsyncを使用してリポジトリを新しいリポジトリに複製することです。これは少し遅くなりますが、より柔軟性があり、ダンプ/ロードでは（まだ）利用できない追加の正規化機能がいくつかあります（svnsyncはプロパティをLF行末にその場で正規化し、--source-prop-encodingオプションを使用してUTF-8に変換します。これは新しいリポジトリ形式で必要です。詳細については下記を参照してください）。

注：ダンプ/ロードとsvnsyncの両方とも、リポジトリデータベースのみを対象とし、リポジトリのフックスクリプト、構成ファイル、ロックは対象外です。これらは、ソースからターゲットに手動でコピーする必要があります（以下の「複雑な手順」を参照してください）。バックエンドデータベースを再構築せずにリポジトリ全体をコピーする必要がある場合は、svnadmin hotcopyの方が適切な場合があります。

ダウンタイムが許容される小さなリポジトリの場合、これはSubversionバージョンXからYにアップグレードするための単純なダンプ/ロード手順です（より大きなリポジトリでのダウンタイムを最小限に抑えるためのより複雑な手順については、以下を参照してください）。

1. svnserve、Apache、およびリポジトリにアクセスしている可能性のあるその他のすべてをシャットダウンします。
2. svnadmin dump /path/to/repository > dumpfile.txt を、バージョンXのsvnadminを使用して実行します。
3. mv /path/to/repository /path/to/saved-old-repository
4. 次に、Subversion Yにアップグレードします（つまり、Yをビルドしてインストールし、Xを置き換えます）。
5. svnadmin create /path/to/repositoryを、バージョンYのsvnadminを使用して実行します。
6. svnadmin load /path/to/repository < dumpfile.txt を、再度バージョンYのsvnadminを使用して実行します。
7. 古いリポジトリから新しいリポジトリにフックスクリプトなどをコピーします。
8. svnserve、Apacheなどを再起動します。

メンテナンスウィンドウを最小限に抑えたい大規模なリポジトリの場合は、もう少し複雑な手順を使用できます。コツは、古いリポジトリが（チェックアウトとコミットのために）引き続きアクセス可能な状態で、新しい場所にダンプ+ロードすることです。これが完了したら（数時間、場合によっては数日、数週間かかる可能性があります）、ロードされた最後のリビジョンを記録し（または「svnlook youngest newrepos」でリビジョン番号を確認）、ダンプを「--incremental -rNEXTREV:HEAD」で開始する別のダンプ+ロードを開始します（ここで、NEXTREVはダンプする必要がある次のリビジョンです）。古いリポジトリを開いたままにしておけば、これを反復できます...最後に、新しいリポジトリを有効にしている間（注意：新しいリポジトリを古いリポジトリと同じディスクロケーションに移動し、Apache httpdを使用してサービスを提供している場合は、httpdを再起動してキャッシュをリセットしてください）、元のリポジトリを数分間アクセス不能にします。

ヒント：大規模なリポジトリの場合は、新しいリポジトリ（「svnadmin load」のターゲット）を非常に高速なストレージ（可能な場合はramdisk）に構築し、高速ストレージで「svnadmin pack」を実行し（その後、最終的なディスクにコピー）、強くお勧めします。「svnadmin load」の部分が現在非常に時間がかかるためです（これはおそらく、svn 1.10で、「svnadmin load」の--no-flush-to-diskオプションを使用して大幅に改善されるでしょう）。

コマンドは次のようになります。

1. svnadmin create NEWREPOS
   （おそらくramdiskに作成します）
2. OLDREPOS/hooksにカスタムフックスクリプトがある場合（デフォルトのテンプレートである.tmplで終わらないすべてのファイル）、それらを確認し、NEWREPOS/hooksにコピーします。カスタムフックスクリプトに対応する新しいテンプレートをチェックして、新しいオプションとコメントがあるかどうかを確認します（テンプレートの新しいコメントをカスタムフックスクリプトにコピーして、最新の状態に保つことができます）。ファイルが手順全体が完了するまで変更されないようにしてください（または、最後に変更を追加で実行してください）。
3. OLDREPOS/confからNEWREPOS/confに構成ファイルを確認してコピーします（ここでも、新しい「デフォルト構成ファイル」を見て、新しい興味深いオプションやコメントがあるかどうかを確認してください）。ファイルが手順全体が完了するまで変更されないようにしてください（または、最後に変更を追加で実行してください）。
4. svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS
   （初期のダンプ+ロード。ダンプまたはロードをより静かにするために-qを渡すこともできます）
   （-M 1024は、キャッシュのためにプロセスに1024MBの追加RAMを与えます）
5. svnlook youngest NEWREPOS
   （ロードされた最後のリビジョン-> NEXTREVはこの最後のリビジョン+1です）
6. svnadmin dump --incremental -rNEXTREV:HEAD -M 1024 | svnadmin load -M 1024 NEWRPOS
7. OLDREPOSを読み取り専用にするか、完全に利用不能にします<-- メンテナンスウィンドウの開始
8. 手順5と6の増分ダンプ+ロードを（6を開始した後に新しいコミットが発生した場合）繰り返す可能性があります。
9. OLDREPOS/db/locksからNEWREPOS/db/locksにロックをコピーします。「cp -rp SOURCE TARGET」のようなものがこれでうまく機能します。注：この手順は、ディレクトリツリーのサイズとディスクの速度に応じて、メンテナンスウィンドウ中に数分かかる場合があります。確認したい場合は、事前にテストしてください（ただし、最終的なコピー/同期を行う際は、ソースリポジトリが読み取り専用であることを確認してください。そうしないと、コピー後にロックが変更される可能性があります）。
10. NEWREPOSをオンラインにします<-- メンテナンスウィンドウの終了

注意すべき点

• 初期のダンプ+ロードを開始してから古いリポジトリをロックダウンするまでの間に発生したログメッセージの変更（またはその他のリビジョンプロパティ）に注意してください。これらは増分ダンプ+ロードでは転送されません。したがって、最初のダンプ+ロードを実行している間はpre-revprop-changeフックが「閉じている」ことを確認するか、変更されたすべてのリビジョンプロパティのログを保持し（たとえば、post-revprop-changeフックからログファイルに書き込みます）、後で新しいリポジトリに転送します（たとえば、「svnlook log」と「svnadmin setlog」を使用します）。
• 次の問題が発生する可能性があります。

  svnadmin: E125005: Invalid property value found in dumpstream; consider repairing the
  source or using --bypass-prop-validation while loading.
  
  svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property
  

  これは、リビジョンのsvn:logメッセージにLF以外の行末があることを意味します（これらは古いサーバーでは受け入れられていましたが、Subversion 1.6以降は受け入れられなくなりました）。「svnadmin load」コマンドに--bypass-prop-validationを追加することで、この小さな破損を無視できます（新しいリポジトリで後でいつでも修復できます）。または、ダンプ+ロードを実行する前に、ソースリポジトリでこれを修復することもできます（svn:logはリビジョンプロパティであるため、「履歴を書き換える」ことなく簡単に修正できます）。
• 次の問題が発生する可能性があります。

  svnadmin: E125005: Invalid property value found in dumpstream; consider repairing the
  source or using --bypass-prop-validation while loading.
  
  svnadmin: E125005: Cannot accept non-LF line endings in 'svn:ignore' property
  

  これは修復がより困難です。なぜなら、'svn:ignore' はリビジョンプロパティ（svnadmin setrevprop で操作できる svn:log とは異なり）ではなく、バージョン管理されたプロパティ（つまり履歴の一部）だからです。ここでも --bypass-prop-validation で無視できます。しかし、これは「履歴の中」の破損なので、dump+load でしか修復できません。したがって、これを修正する良い機会かもしれません（さもなければ将来再び遭遇するでしょう）。修復するには、svndumptoolのようなツールを使用できます。ただし、パイプの一部ではなく、ダンプファイルに対してのみ機能します。そのため、考えられる方法は次のとおりです。破損した単一のリビジョンをファイルにダンプし、それを修復（'svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired'）し、その単一のダンプファイルをロードし、その後、新しい「パイプ」コマンド（上記の手順（6）のように）で続行します。

ダンプとロードの詳細については、Subversion book のこのセクションを参照してください。

についてどうすればいいですか「svnadmin: E125005: 'svn:log'プロパティではLF以外の行末を受け入れられません」'svnadmin load' の実行中に？ ¶

このエラーは、ダンプファイル/ダンプストリームのリビジョンの svn:log メッセージに LF 改行ではない改行コードが含まれていることを意味します（これらは古いサーバーでは受け入れられていましたが、Subversion 1.6 以降では受け入れられなくなりました）。'svnadmin load' コマンドに --bypass-prop-validation を追加することで、新しいリポジトリへのロード中にこの小さな破損を無視できます（これは新しいリポジトリで後でいつでも修復できます）。または、dump+load を実行する前に、ソースリポジトリでこれを修復することもできます（svn:log はリビジョンプロパティであるため、「履歴を書き換える」ことなく簡単に修正できます）。また、svnsyncはこれをその場で正規化するため、dump+load よりも簡単な代替手段となる可能性があります。

svn:log プロパティの改行コードを正規化するための標準的な手順はありませんが、管理コマンド 'svnlook propget'、'svnlook log'、'svnadmin setlog' を使用することで実現できます。

• svnlook propget -r$REV --revprop $REPOS svn:logは、生の svn:log リビジョンプロパティを取得します（正規化なし、末尾に余分な改行なし）。これを使用して、それを検証し、「LF 改行ではない改行コード」を検索できます。
• svnlook log -r$REV $REPOSは、正規化されたバージョンを取得します（LF 改行、UTF8 に正規化（ロケールとして正しい「ソースエンコーディング」を設定している場合）、および末尾に余分な改行）。最後の改行を削除すると、... にフィードするのに最適な正規化されたログメッセージが得られます。
• svnadmin setlog -r$REV $REPOS --bypass-hooks（または、フックを実行したい場合は、--bypass-hooks オプションなし）は、stdin から読み取っている値を新しいログメッセージとして設定します。

これらをスクリプトにまとめて、リポジトリ内のすべてのリビジョンを処理できます。次の bash ワンライナーのように。

Find the "broken" revisions and echo the revision numbers:

bash$ YOUNGEST=`svnlook youngest $REPOS`; for (( i=1; i<=$YOUNGEST; i++ )); \
do svnlook propget -r $i --revprop $REPOS svn:log | xxd -ps -c1 | fgrep '0d' > /dev/null \
&& echo "$i" ; done; echo "Verified until revision $YOUNGEST"

Find and immediately fix the "broken" revisions with 'svnadmin setlog':

bash$ YOUNGEST=`svnlook youngest $REPOS`; for (( i=1; i<=$YOUNGEST; i++ )); \
do svnlook propget -r $i --revprop $REPOS svn:log | xxd -ps -c1 | fgrep '0d' > /dev/null \
&& echo "Fixing r$i" && svnadmin setlog $REPOS --bypass-hooks -r$i \
<( svnlook log -r$i $REPOS | sed '$d' ); done; echo "Verified until revision $YOUNGEST"

(the "sed '$d'" strips off the extra newline that's added by "svnlook log")

SSPI 認証を使用して、クライアントが Windows ドメインコントローラに対して認証できるようにするにはどうすればよいですか？ ¶

この FAQ エントリは 2003 年から更新されておらず、もはや正確または関連性のない情報が含まれていることがわかっています。

TortoiseSVN には、Windows に Subversion サーバーをセットアップする方法を説明した優れたドキュメントがあります。https://tortoisesvn.dokyumento.jp/docs/release/TortoiseSVN_en/tsvn-serversetup.html#tsvn-serversetup-apache-5 にアクセスして、SSPI 認証に関するセクションを参照してください。

構成の重要な部分は、次の行です。

   SSPIOfferBasic On

この行がないと、SSPI をサポートするブラウザはユーザーの資格情報を求めるプロンプトを表示しますが、Subversion など SSPI をサポートしないクライアントはプロンプトを表示しません。（Subversion の HTTP ライブラリである Neon の現在のリリースでは、基本的な認証のみを処理します。）クライアントが資格情報を要求しないため、認証が必要なアクションはすべて失敗します。この行を追加すると、mod_auth_sspiはクライアントとの基本的な認証を使用しますが、資格情報を認証するには Windows ドメインコントローラを使用します。

".svn" ディレクトリ名が好きではなく、"SVN" またはその他の名前を使用したいのですが。どうすれば変更できますか？ ¶

可能であれば、".svn" をそのまま使用することをお勧めします。ただし、Windows で Visual Studio 2002 または 2003 を使用している場合は、こちらで説明されているように、環境変数 SVN_ASP_DOT_NET_HACK を設定する必要がある場合があります。

または、管理ディレクトリに完全にカスタムの名前を使用することもできます。ただし、作業コピーがカスタマイズしたクライアント以外の Subversion クライアントでは動作しない可能性が高いため、これをお勧めしません。ただし、どうしてもこれを行う必要がある場合は、subversion/include/svn_wc.hのこの行を、

#define SVN_WC_ADM_DIR_NAME   ".svn"

（たとえば）次のように変更し、

#define SVN_WC_ADM_DIR_NAME   "SVN"

クライアントを再コンパイルします。

ファイル名の大文字と小文字を変更するにはどうすればよいですか？ ¶

この問題は 2 つの状況で発生します。Windows などの大文字と小文字を区別しないファイルシステムでファイルを追加する場合、ファイル名の大文字と小文字が間違った状態で誤ってファイルを追加してしまうことがあります。または、リポジトリ内の既存のファイルの大文字と小文字を変更することにした場合もあります。

大文字と小文字を区別するファイルシステムで作業している場合、これはまったく問題ありません。ファイルを新しい名前に移動するだけです。例：

svn mv file.java File.java

Subversion 1.7 以降では、大文字と小文字を区別しないファイルシステムを使用している場合でも、Windows でもこれが機能します。

Windows で Subversion 1.6 以前を使用している場合、または Windows 以外のオペレーティングシステムで大文字と小文字を区別しないファイルシステムを使用している場合、この手法は機能しません。この場合、ファイルを一時的な場所にコピーし、Subversion からファイルを削除してから、正しい大文字と小文字でコピーを追加することでこれを実現できます。または、より良い方法は、Subversion URL を使用して移動操作を実行することです。URL を使用することをお勧めします。これは、ファイルの履歴が保持され、すぐに反映されるためです。

ただし、どちらの方法でも、Windows の作業コピーに問題が残ります。これは、Windows が競合するファイル名を更新しようとしたときに混乱する可能性があるためです。（次のようなメッセージが表示されます。svn: ファイル 'File.java' を追加できませんでした: 同じ名前のオブジェクトが既に存在します）。問題を解決する 1 つの方法は、作業コピーを削除して再度チェックアウトすることです。これを行いたくない場合は、2 段階の更新を実行する必要があります。

大文字と小文字が間違っているファイルごとに、次のコマンドで大文字と小文字が変更されます。

svn mv svn://svnserver/path/to/file.java svn://svnserver/path/to/File.java

作業コピーを更新するには、関連するディレクトリに移動して、次のように実行します。

svn update file.java
svn update

最初の更新で、file.javaが作業コピーから削除され、2 番目の更新で、File.javaが追加され、正しい作業コピーが残ります。または、問題のあるファイルがたくさんある場合は、次のように作業コピーを更新できます。

svn update *
svn update

ご覧のとおり、大文字と小文字を区別しないファイルシステムを持つオペレーティングシステムでは、大文字と小文字が間違ったファイルを追加すると、修正が難しくなります。ファイルを最初に追加するときに、正しく入力するようにしてください。そもそも問題が発生するのを防ぐために、ファイルcheck-case-insensitive.plを呼び出す pre-commit フックを作成できます。このファイルは、Subversion ソース tarball のディレクトリcontrib/hook-scripts.

CVS で使用していたように、タグを使用してブランチからトランクに変更をマージすることはできませんか？ ¶

以下に示すように、1 つのリビジョン番号を覚えていなくても、ブランチからトランクにマージすることが可能です。またはその逆（例では示されていません）。

以下の例は、/home/reposにある既存のリポジトリで、barという名前のブランチを開始したいと想定しており、fooという名前のファイルが含まれており、編集する予定です。

ブランチマージを追跡する目的で、このリポジトリは、tags/branch_traces/にタグを保持するように設定されています。

# setup branch and tags
$ svn copy file:///home/repos/trunk \
           file:///home/repos/branches/bar_branch \
           -m "start of bar branch"
$ svn copy file:///home/repos/branches/bar_branch \
           file:///home/repos/tags/branch_traces/bar_last_merge \
           -m "start"

# checkout branch working copy
$ svn checkout file:///home/repos/branches/bar_branch wc
$ cd wc

# edit foo.txt file and commit
$ echo "some text" >>foo.txt
$ svn commit -m "edited foo"

# switch to trunk and merge changes from branch
$ svn switch file:///home/repos/trunk
$ svn merge file:///home/repos/tags/branch_traces/bar_last_merge \
            file:///home/repos/branches/bar_branch

# Now check the file content of 'foo.txt', it should contain the changes.

# commit the merge
$ svn commit -m "Merge change X from bar_branch."

# finally, update the trace branch to reflect the new state of things
$ svn delete -m "Remove old trace branch in preparation for refresh." \
             file:///home/repos/tags/branch_traces/bar_last_merge
$ svn copy file:///home/repos/branches/bar_branch                     \
           file:///home/repos/tags/branch_traces/bar_last_merge       \
           -m "Reflect merge of change X."

$Revision$ キーワードが私の望む動作をしないのはなぜですか？ ファイルの最終変更リビジョンに展開されますが、ファイルの現在のリビジョンに展開されるものを望んでいます。 ¶

Subversion はリポジトリ全体のリビジョン番号をインクリメントするため、キーワードをその番号に展開することはできません。更新とコミットのたびに、作業コピー内のすべてのファイルを検索して変更する必要があるからです。

必要な情報（作業コピーのリビジョン）は、次のコマンドから取得できます。svnversion。パスを指定すると、作業コピーのリビジョンレベルに関する情報が得られます（svnversion --helpで詳細を確認してください）。

ビルドまたはリリースプロセスに組み込んで、必要な情報をソース自体に取得できます。たとえば、GNU makeに基づくビルド環境では、このようなものをMakefile:

##
## To use this, in yourfile.c do something like this:
## printf("this program was compiled from SVN revision %s\n",SVN_REV);
##

SVNDEF := -D'SVN_REV="$(shell svnversion -n .)"'
CFLAGS := $(SVNDEF) ... continue with your other flags ...

に追加します（これは GNU バージョン以外のmakeでは動作しないことに注意してください。ビルドプロセスがポータブルである必要がある場合は、使用しないでください）。

または、次のレシピを試してください。

##
## on every build, record the working copy revision string
##
svn_version.c: FORCE
    echo -n 'const char* svn_version(void) { const char* SVN_Version = "' \
                                       > svn_version.c
    svnversion -n .                   >> svn_version.c
    echo '"; return SVN_Version; }'   >> svn_version.c

##
## Then any executable that links in svn_version.o will be able
## to call the function svn_version() to get a string that
## describes exactly what revision was built.
##

Windows ユーザーは、SubWCRev.exeを TortoiseSVN ダウンロードページから利用できます。これは、指定されたファイル内のすべての$WCREV$タグを現在の作業コピーのリビジョンで置き換えます。

もう 1 つの代替手段は、'svn commit' のラッパーを作成することです。これにより、コミット前にファイル内で自動的な置換が行われます（ただし、注意して、物事を混乱させないようにしてください。コミット直前のファイルのサイレント操作は、ユーザーにとって怖い場合があります）。そうすることで、必要なメタデータを注入できます（そして、それはファイルの通常のコンテンツとともにリポジトリにコミットされます）。

Subversion には、CVS の $Log$ のように動作するキーワードがありますか？ ¶

いいえ。CVS の $Log$ キーワードに相当するものはありません。特定のファイルのログを取得する場合は、'svn log your-file-name' または 'svn log url-to-your-file' を実行できます。メーリングリストから、$Log$ が良くない理由についての説明があります。

"$Log$ is a total horror the moment you start merging changes
between branches. You're practically guaranteed to get conflicts there,
which -- because of the nature of this keyword -- simply cannot be
resolved automatically."

そして

Subversion log messages are mutable, they can be changed by setting
the svn:log revision property. So the expansion of $Log:$ in any
given file could be out of date. Update may well need to retrieve the
appropriate log message for each occurrence of the $Log:$ keyword,
even if the file that contained it was not otherwise updated.

私はそんなことは気にしません。とにかく使用したいのです。実装していただけますか？

いいえ。私たち自身で実装したり、この機能を実装するパッチを受け入れたりする予定はありません。何らかの変更ログを含めてファイルを配布したい場合は、ビルドシステムでこの制限を回避できる可能性があります。

私のプロジェクトにすべての開発者が変更する必要があるファイルがありますが、それらのローカルな変更をコミットしたくありません。どうすれば 'svn commit' でファイルを無視できますか？ ¶

答えは次のとおりです。そのファイルをバージョン管理下に置かないでください。代わりに、ファイルのテンプレートを "file.tmpl" のようにバージョン管理下に置きます。

次に、最初の 'svn checkout' 後に、ユーザー（またはビルドシステム）にテンプレートの通常の OS コピーを適切なファイル名に実行させ、ユーザーにコピーをカスタマイズさせます。ファイルはバージョン管理されていないため、コミットされることはありません。必要に応じて、ファイルを親ディレクトリの svn:ignore プロパティに追加して、'svn status' コマンドで '?' として表示されないようにすることができます。

svn+ssh を使用してリポジトリにアクセスすると、パスワードが ~/.subversion/auth/ にキャッシュされません。頻繁に入力する必要をなくすにはどうすればよいですか？ ¶

ssh には独自のパスフレーズと独自の認証キャッシュスキームがあります。その認証キャッシュは Subversion の外部にあり、Subversion とは独立して設定する必要があります。

OpenSSHには、キーを作成するssh-keygen、パスフレーズをキャッシュするssh-agent、そしてエージェントのキャッシュにパスフレーズを追加するssh-addが含まれています。ssh-agentの使用を簡単にするための一般的なスクリプトはssh-agentは、keychainです。Windowsでは、PuTTYが一般的な代替sshクライアントです。OpenSSHキーをインポートするにはPuTTYgen、パスフレーズをキャッシュするにはpageantを参照してください。

セットアップssh-agentはこのドキュメントの範囲外ですが、「ssh-agent」をGoogle検索すると、すぐに答えが見つかります。

私svnserveバイナリはユーザーのデフォルトにないディレクトリにありますPATH、彼らはsvn+sshを使用しており、彼らのPATHを変更する方法がわかりませんsvnserve。 ¶

注：これはすべて、OpenSSHを使用していることを前提としています。他のssh実装も存在し、おそらく同様のことができるでしょうが、詳細はまだ不明です。

あなたは、次のようなさまざまなログインファイルをいじってみましたが、.bash_profile、何も機能しません！それは、Subversionクライアントがsshを呼び出すときに、sshがこれらのファイルを無視するためです。しかし、変更する必要はありませんPATH。代わりに、sshにsvnserveコマンドのフルネームを直接渡すことができます。方法は次のとおりです

svn+sshアクセスを必要とする各ユーザーに対して、通常ログイン用ではなく、Subversionでのみ使用する新しいssh公開鍵/秘密鍵ペアを生成します。キーペアに、次のような特徴的な名前を付けさせます。~/.ssh/id_dsa.subversion。サーバーマシンの~/.ssh/authorized_keysファイルに、キーの公開部分を追加します。その際、最初にssh-rsaまたはまたはのように、行の先頭に少し魔法のコードを挿入してから、

明らかに、/opt/subversion/bin/svnserveを、システムに適した内容に置き換えてください。また、コマンドでSubversionリポジトリへのフルパスを指定すると（-rオプションを使用）、ユーザーの入力の手間を省くことができます。

このcommand=という魔法のコードにより、リモートマシンのsshdは、ユーザーが別のコマンドを実行しようとした場合でも、svnserveを呼び出すようになります。詳細については、sshd(8)マニュアルページ（セクションAUTHORIZED_KEYS FILE FORMAT）を参照してください。

ユーザーがSubversionクライアントを実行するときは、次のようにして（Bourne Againシェルの場合）、キーペアの秘密鍵を「指す」SVN_SSH環境変数が設定されていることを確認してください。

SVN_SSH="ssh -i $HOME/.ssh/id_dsa.subversion"
export SVN_SSH

このファイルでは、このトピックについて詳しく説明しています。

svn+ssh://経由でのアクセスを許可したいのですが、心配です。各ユーザーにログイン権限を与えるのは嫌です。そうすると、マシン上で何にアクセスできるか、できないかを心配しなければならなくなります。 ¶

のハッキングに関するセクションを参照してください。この別の質問への回答のファイル; 取得に関する内容は無視してください~/.ssh/authorized_keysあなたのPATH上。svnserveリポジトリ内のすべての項目に特定のプロパティを設定するにはどうすればよいですか？また、リポジトリに入るすべての新しいファイルにこれらのプロパティを設定するにはどうすればよいですか？ ¶

Subversionはデフォルトではファイルの内容を変更しません。変更するには、ファイルに

svn:eol-styleまたはまたはsvn:keywordsプロパティを明示的に設定する必要があります。そのため、SubversionはCVSのデフォルトの動作よりもはるかに安全ですが、その安全性の代わりに、いくらかの不便さも伴います。

最初の質問に答えます。リポジトリに既にあるすべてのファイルにプロパティを設定するには、面倒な方法で実行する必要があります。できることは、すべてのファイル（作業コピー内）に対してsvn propsetを実行し、次にsvn commitを実行することだけです。スクリプトを使用すると、これに役立つ可能性があります。

しかし、将来のファイルについてはどうでしょうか？残念ながら、コミットされるファイルにプロパティを自動的に設定するサーバーメカニズムはありません。これは、すべてのユーザーが、ファイルをsvn addファイルにするたびに、特定のプロパティを設定することを覚えておく必要があることを意味します。幸いなことに、これを支援するクライアント側のツールがあります。書籍のauto-props機能について読んでください。すべてのユーザーが、クライアントのauto-props設定を適切に構成していることを確認する必要があります。

新しいファイルにプロパティを追加するのを忘れたコミットを拒否するpre-commitフックスクリプトを作成できます（たとえば、https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/check-mime-type.plを参照してください）。ただし、このアプローチは過剰になる可能性があります。誰かがまたはを設定するのを忘れた場合など、別のOSで他の誰かがファイルを開くとすぐに気付くでしょう。気付いたら、簡単に修正できます。プロパティを設定してコミットするだけです。

注：多くのユーザーが、auto-props設定などの実行時設定をサーバーがクライアントに自動的に「ブロードキャスト」する機能について問い合わせています。この機能については、すでに機能リクエストが提出されています（issue 1974）。ただし、この機能は開発者によってまだ議論されており、まだ作業されていません。

エディターパスにスペースがある場合、どうすれば対処できますか？また、エディターのコマンドラインオプションを定義するにはどうすればよいですか？ ¶

Subversionコマンドラインクライアントは、環境変数SVN_EDITORで定義されたエディターを呼び出します。この環境変数は、ログメッセージを入力/編集するために使用される一時ファイルの名前とともに、オペレーティングシステムに直接渡されます。

SVN_EDITOR文字列がシステムのコマンドシェルにそのまま渡されるという事実のため、エディター名またはエディターへのパス名にスペースが含まれている場合は、エディター名が引用符で囲まれていない限り機能しません。

たとえば、WindowsでエディターがC:\Program Files\Posix Tools\bin\viにある場合は、次のように変数を設定します。

   set SVN_EDITOR="C:\Program Files\Posix Tools\bin\vi"

Windowsシェルでは、引用符がsetコマンドの構文の一部ではないため、エスケープする必要はないことに注意してください。

UNIXシステムでは、シェル固有の方法に従って変数を設定する必要があります。たとえば、bashシェルでは、次の方法で動作するはずです。

   SVN_EDITOR='"/usr/local/more editors/bin/xemacs"'
   export SVN_EDITOR

エディターの呼び出しにコマンドラインオプションが必要な場合は、コマンドラインで使用する場合と同じように、SVN_EDITOR環境変数のエディター名の後に追加します。たとえば、上記の編集者に対して-nx -rオプションが必要な場合は、以下のようにオプションを指定します。

Windowsの場合

   set SVN_EDITOR="C:\Program Files\Posix Tools\bin\vi" -nx -r

UNIX/bashの場合

   SVN_EDITOR='"/usr/local/more editors/bin/xemacs" -nx -r'
   export SVN_EDITOR

SVN_EDITORは、エディターの選択のためのSubversion固有の環境変数設定であることに注意してください。Subversionは、より一般的なEDITOR変数を使用することもサポートしていますが、Subversionで特別な動作が必要な場合は、SVN_EDITOR変数を使用するのが最適です。

リポジトリでWebサイトを管理しています。コミットするたびに、ライブサイトを自動的に更新するにはどうすればよいですか？ ¶

これは常に実行されており、リポジトリにpost-commitフックスクリプトを追加することで簡単に実現できます。書籍の第5章でフックスクリプトについて読んでください。基本的な考え方は、「ライブサイト」を通常の作業コピーにし、post-commitフックスクリプトで「svn update」を実行することです。

実際には、注意すべき点がいくつかあります。コミットを実行するサーバープログラム（svnserveまたはapache）は、post-commitフックスクリプトを実行するのと同じプログラムです。つまり、このプログラムには、作業コピーを更新するための適切な権限が必要です。言い換えれば、作業コピーは、svnserveまたはapacheが実行されているのと同じユーザーが所有している必要があります。少なくとも、作業コピーには適切な権限が設定されている必要があります。

サーバーが所有していない作業コピー（たとえば、ユーザーjoeの~/public_html/領域）を更新する必要がある場合、1つの手法は、更新を実行するための+sバイナリプログラムを作成することです。Unixでは、スクリプトが+sで実行されるのを許可しないためです。小さなCプログラムをコンパイルします。

#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
  execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
        (const char *) NULL);
  return(EXIT_FAILURE);
}

...そしてchmod +sバイナリを実行し、ユーザー'joe'が所有していることを確認します。次に、post-commitフックで、バイナリを実行する行を追加します。

フックが機能しない場合は、「リポジトリフックが機能しないのはなぜですか？」を参照してください。

また、apacheがライブ作業コピーの.svn/ディレクトリをエクスポートしないようにすることもできます。これをhttpd.conf:

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

に追加します。最後に、更新する作業コピーがSubversionサーバーと同じマシン上にない場合は、Subversionサーバーでsvnpubsubを使用して、Webサーバー上のリッスンしているsvnwcsubクライアントにコミットを通知できます。

単一のファイルをチェックアウトするにはどうすればよいですか？ ¶

Subversionは、単一ファイルのチェックアウトをサポートしていません。ディレクトリ構造のチェックアウトのみをサポートしています。

ただし、「svn export」を使用して単一のファイルをエクスポートできます。これにより、ファイルの内容が取得されますが、バージョン管理された作業コピーは作成されません。

作業コピーで、既に行われた追加、削除、コピー、名前変更を検出するにはどうすればよいですか？ ¶

できません。試すのは悪い考えです。

作業コピーの基本的な設計には、2つのルールがあります。（1）ファイルを自由に編集し、（2）Subversionクライアントを使用して、ツリーの変更（追加、削除、移動、コピー）を行います。これらのルールに従えば、クライアントは作業コピーを正常に管理できます。Subversionの外部で名前の変更やその他の再配置が発生した場合、UIが侵害され、作業コピーが破損する可能性があります。クライアントは何が起こったのかを推測できません。

バージョン管理を「透過的に」したいという理由で、この問題が発生する場合があります。ユーザーを作業コピーを使用するように誘導し、後でスクリプトを実行して何が起こったかを推測し、適切なクライアントコマンドを実行しようとします。残念ながら、この手法は少ししか機能しません。「svn status」は、欠落している項目とバージョン管理されていない項目を表示します。スクリプトは、これらを自動的に「svn rm」または「svn add」することができます。しかし、移動またはコピーが発生した場合、どうしようもありません。スクリプトにこれらを検出する完璧な方法があったとしても、「svn mv」と「svn cp」は、アクションが既に発生した後では操作できません。

要約すると、作業コピーは完全にSubversionの管理下にあり、Subversionは透過的になるように設計されていません。透過性を探している場合は、apacheサーバーをセットアップし、書籍の付録Cで説明されている「SVNAutoversioning」機能を使用してみてください。これにより、ユーザーはリポジトリをネットワークディスクとしてマウントでき、ボリュームに加えられた変更により、サーバーで自動コミットが行われます。

Windowsでsvnserveをサービスとして実行するにはどうすればよいですか？ ¶

バージョン1.4.0以降では、こちらで手順を確認できます。

BDBを使用しているリポジトリをFSFSに、またはFSFSをBDBに変換するにはどうすればよいですか？ ¶

3つのステップがあります。

1. 古い形式から新しい形式へのdump/load。
2. フックスクリプトのコピー。
3. 構成ファイルのコピー。

リポジトリがあるとします。/svn/myreposこれはBDBバックエンドを使用しており、FSFSバックエンドを使用するように切り替えたいとします。

1. この手順中にデータが変更されないように、サーバーを閉じます。
2. fsfsバックエンドを指定して新しいリポジトリを作成します（1.2以降はデフォルトです）。例：svnadmin create /svn/myreposfsfs --fs-type fsfs.
3. からのダンプの出力をパイプします/svn/myreposへのロードの入力に/svn/myreposfsfs、例：svnadmin dump /svn/myrepos -q | svnadmin load /svn/myreposfsfs。Windowsユーザーは、2つの別々のステップでファイルにダンプしてから、そのファイルからロードする必要があります。
4. でアクティブになっているフックスクリプトをコピーします。/svn/myrepos/hooksから/svn/myreposfsfs/hooksSubversionで生成されたテンプレートが変更されている可能性があるため、すべてを無批判にコピーしないでください。
5. 以下のコマンドによって生成されるテンプレートスクリプトを比較してください。svnadmin createコマンドで配置されたものと/svn/myreposfsfs/hooksにあるものとを比較し/svn/myrepos/hooksアクティブなフックスクリプトに組み込みたい変更を反映させてください。
6. 設定ファイルを以下からコピーしてください。/svn/myrepos/confから/svn/myreposfsfs/conf(パスワードファイルを使用している場合は、パスワードファイルも忘れずに)。または、設定ファイルに加えた変更を、新しいデフォルトの設定ファイルにマージすることもできます。
7. 以下をリネームしてください。/svn/myrepos以下へ。/svn/myreposbdbそして/svn/myreposfsfs以下へ。/svn/myreposファイルパーミッションがBDBバージョンと同じであることを確認してください。
8. サーバーを再起動してください。

新しいリポジトリがすべて正常に動作していることを確認したら、古いリポジトリを削除してください。

逆にFSFSからBDBに移行するには、以下のコマンドを変更してBDBを指定してください。svnadmin createコマンドをBDBを指定するように変更します。

Subversionはどのようにバイナリファイルを処理しますか？ ¶

初めてファイルをSubversionに追加またはインポートするとき、そのファイルがバイナリファイルかどうかを判断するために調べられます。現在、Subversionはファイルの最初の1024バイトのみを調べています。いずれかのバイトがゼロである場合、または15%以上がASCII印刷可能文字でない場合、Subversionはそのファイルをバイナリとみなします。

Subversionがファイルをバイナリと判断した場合、そのファイルには「application/octet-stream」に設定された svn:mime-type プロパティが与えられます。( 自動プロパティ機能を使用するか、手動でプロパティを設定することで、常にこれを上書きできます。)svn propset.)

Subversion 1.7以降では、バージョン管理に追加されたバイナリファイルのMIMEタイプを検出するために、オプションでlibmagicのサポートを有効にしてコンパイルできます。この機能は、自動プロパティまたは mime-types-file 設定オプションを介してMIMEタイプが見つからないバイナリファイルに対してのみ使用されます。libmagicがファイルをテキストファイルとして識別した場合、Subversionはデフォルトでそのファイルをテキストファイルとして扱います。

Subversionは次のファイルをテキストとして扱います。

• svn:mime-type がないファイル
• "text/"で始まる svn:mime-type を持つファイル
• "image/x-xbitmap"と等しい svn:mime-type を持つファイル
• "image/x-xpixmap"と等しい svn:mime-type を持つファイル

他のすべてのファイルはバイナリとして扱われます。これは、Subversionが次のことを行うことを意味します。

• 受信した変更をローカルでの変更と自動的にマージしようとしません。プロジェクトにパッチを提供し、パッチが新しいファイルを追加しました。今またはsvn merge
• の一部として差分を表示しません。どうすれば
• の行ごとの属性を表示しません。svn blame

それ以外はすべて、Subversionはバイナリファイルをテキストファイルと同じように扱います。たとえば、svn:keywords または svn:eol-style プロパティを設定した場合、Subversionはバイナリファイルに対してもキーワード置換または改行変換を行います。

ファイルがバイナリであるかどうかは、そのファイルへの変更を保存するために使用されるリポジトリのスペースの量や、クライアントとサーバー間のトラフィック量には影響しないことに注意してください。保存と送信の目的のために、Subversionはバイナリファイルとテキストファイルで同様にうまく機能するdiff処理を使用します。これは「svn diff」コマンドで使用されるdiff処理とは完全に無関係です。

Subversionはバイナリファイルをどのように処理しますか？どうすれば変更されたファイルの内容ではなく、ファイル名だけを表示するにはどうすればよいですか？ ¶

どうすればにはこれを行うためのオプションはありませんが、

• たとえば、リビジョン10とその直前のリビジョンとの間の差分にのみ関心がある場合は、

  svn log -vq -r10

  がまさにそれを行います。
• それ以外の場合、Unixを使用している場合は、次の方法が任意のリビジョンの範囲で機能します。

      svn log -vq -r123:456 | egrep '^ {3}[ADMR] ' | cut -c6- | sort | uniq 

ワイルドカードまたはグロビングを使用して、一度に複数のファイルを移動するにはどうすればよいですか？ ¶

次のようなことをしたいと考えているかもしれません。

svn mv svn://server/trunk/stuff/* svn://server/trunk/some-other-dir

しかし、次のエラーで失敗します。

svn: Path 'svn://server/trunk/stuff/*' does not exist in revision 123

...またはその他の不可解なエラーメッセージ。

SubversionはURL引数で "*"のようなワイルドカードを展開しません。(技術的に言えば、Subversionはローカルパスでもワイルドカードを展開しませんが、ほとんどのオペレーティングシステムでは、シェルはコマンドラインでローカルパスのワイルドカードを展開し、結果のリストをSubversionに渡します。)

ソースURLのリストを自分で生成する必要があります。次のように行うことができます (Bashの場合)。

        s=svn://server/trunk/stuff
        items=$(svn ls "$s")
        urls=$(for item in $items; do echo $s/$item; done)
        svn mv $urls svn://server/trunk/some-other-dir -m "Moved all at once"

Subversion v1.4以前では、1つのコマンドで複数のパスまたはURLを「cp」および「mv」することはできませんでした。複数のコマンドを発行する必要があります。ソースファイルと宛先ディレクトリの両方をすべて含む作業コピーがある場合は、シェルのワイルドカード機能を利用して、次のように移動できます (Bashの場合)。

        for i in stuff/*; do svn mv $i some-other-dir; done
        svn ci -m "moved all the stuff into some other dir"

いずれにしても、ソースファイルの名前のリストを累積し、そのリストの各項目に対して「svn mv」を実行できます。次に例を示します。

        s=svn://server/trunk/stuff
        svn ls "$s"  | \
        while read f
           do svn mv "$s/$f" svn://server/trunk/some-other-dir -m "Moved just one file"
        done

ただし、これにより、ソースファイルごとに1つのコミットが生成されることに注意してください。これは、上記のメソッド(作業コピーを使用)が合計で1つのコミットだけを生成するのと対照的です。

Subversionに付属しているソースを持つ「svnmucc」(以前は「mucc」)というプログラムがあり、複数のコマンドを1つのコミットに結合できます。ツールとコントリビューションのページを参照してください。

Subversionを使用して、サードパーティ製ソフトウェアの変更されたバージョン(「ベンダーブランチ」)を維持するにはどうすればよいですか？ ¶

人々は、サードパーティコードへのローカルでの変更を、サードパーティからのアップグレードを跨いで追跡するために、Subversionを使用したいと頻繁に考えます。つまり、独自の分岐ブランチを維持しながら、アップストリームソースからの新しいリリースを組み込みたいと考えています。これは一般にベンダーブランチと呼ばれ(この用語はSubversionよりずっと前から存在します)、Subversionでそれを維持するためのテクニックはこちらで説明されています。

ベンダーコードがリモートのSubversionリポジトリでホストされている場合は、Pistonを使用して、ベンダーのコードのコピーを管理できます。

前のリビジョンの内容を再びHEADにするにはどうすればよいですか？ ¶

Subversionの書籍に記載されているように、「svn merge」または「svn copy」を使用してください。

svnコマンドを実行しようとするたびに、作業コピーがロックされていると表示されます。作業コピーが破損していますか？ ¶

作業コピーは破損しておらず、データも失われていません。Subversionの作業コピーはジャーナリングシステムであり、実行する前に実行しようとしているすべてのことをログに記録します。svnクライアントプログラムが(Control-Cではなく、セグメンテーション違反または強制終了によって)強制的に中断された場合、未完了の処理を記述したログファイルとともに、1つ以上のロックファイルが残されます。( `svn status` コマンドは、ロックされたディレクトリの横に「L」を表示します。)作業コピーにアクセスしようとする他のプロセスは、ロックを見たときに失敗します。作業コピーを有効にするには、svnクライアントに作業を完了するように指示する必要があります。次を実行するだけです。

svn cleanup working-copy

コミットしようとすると、Subversionで作業コピーが古いと表示されます。 ¶

これが発生する可能性のある3つの状況を説明します。

1. 失敗したコミットによる残骸が作業コピーに散らかっています。

   サーバーに新しいリビジョンが追加されたときと、クライアントがコミット後の管理タスク(ローカルのテキストベースのコピーの更新を含む)を実行したときの間に、コミットが失敗した場合です。これは、(まれに)データベースバックエンドの問題、または(より一般的には)ネットワークが非常に悪いタイミングで中断するなど、さまざまな理由で発生する可能性があります。

   これが発生した場合、今コミットしようとしている変更が実際にコミットされている可能性があります。「svn log -rHEAD」を使用して、失敗したはずのコミットが実際に成功したかどうかを確認できます。成功した場合は、「svn revert」を実行してローカルの変更を元に戻してから、「svn update」を実行してサーバーから自分の変更を取得してください。(「svn update」のみがローカルコピーを最新の状態にすることに注意してください。revertでは更新されません。)

2. 混合リビジョン。

   Subversionがコミットすると、クライアントはコミットが影響を与えるノードのリビジョン番号のみを増分し、作業コピー内のすべてのノードを増分するわけではありません。これは、1つの作業コピーで、ファイルとサブディレクトリが、最後にコミットした時間に応じて異なるリビジョンになっている可能性があることを意味します。特定の操作(たとえば、ディレクトリプロパティの変更)では、リポジトリにノードの新しいバージョンがある場合、データ損失を防ぐためにコミットが拒否されます。混合リビジョンには制限があるをVersion Control with Subversion書籍で確認してください。

   作業コピーで「svn update」を実行すると、問題を解決できます。

3. 実際に古い可能性があります。つまり、ファイルのコピーを最後に更新してから、他の人が変更したファイルへの変更をコミットしようとしている可能性があります。繰り返しますが、「svn update」がこれを修正する方法です。

コミットしようとしていますが、Subversionからワーキングコピーが最新ではないと表示されますか？プロジェクトにパッチを提供し、パッチが新しいファイルを追加しました。今が機能しません。 ¶

パッチに新しいファイルを含めるためには、おそらく以下のコマンドを実行したでしょう。svn addコマンドにより、どうすればコマンドで新しいファイルがパッチに含まれます。パッチがコードベースにコミットされ、プロジェクトにパッチを提供し、パッチが新しいファイルを追加しました。今を実行すると、次のようなエラーメッセージが表示される場合があります。「svn: ファイル 'my.new.file' の追加に失敗しました: 同じ名前のオブジェクトが既に存在します」。

このエラーが発生した理由は、ローカルコピーのファイルが作業コピーにまだ残っているためです。この問題を修正する手順は次のとおりです。

1. 以下のコマンドを実行します。なぜSubversion内でスケジュールされた追加を削除するコマンド。
2. ファイルを削除するか、作業コピーの外にある場所に移動します。
3. これで、以下のコマンドを実行できるようになります。プロジェクトにパッチを提供し、パッチが新しいファイルを追加しました。今コマンドを使って、(unix) シンボリックリンクをバージョン管理下に置くことができます。

リポジトリの新しいファイルを元のファイルと比較したい場合があります。

配布バイナリをビルドした直後に、Subversionをチェックアウトしようとすると、「認識されないURLスキーム」に関するエラーが表示されます。どういうことですか？ ¶

Subversionは、リポジトリへのアクセスを可能にするためにプラグインシステムを使用します。現在、これらのプラグインは3つあります。ra_local はローカルリポジトリへのアクセスを許可し、ra_neon または ra_serf は WebDAV を介したリポジトリへのアクセスを許可し、ra_svn は svnserve サーバーを介したローカルまたはリモートアクセスを許可します。Subversionで操作を実行しようとすると、プログラムはURLスキームに基づいてプラグインを動的にロードしようとします。「file://」URLはra_localをロードしようとし、「http://」URLはra_neonまたはra_serfをロードしようとします。

表示されているエラーは、動的リンカー/ローダーがロードするプラグインを見つけられないことを意味します。「http://」アクセスの場合、これは通常、コンパイル時にSubversionをneonまたはserfにリンクしていないことを意味します(これに関する情報は、configureスクリプトの出力とconfig.logファイルを確認してください)。また、共有ライブラリを使用してSubversionをビルドし、最初に「make install」を実行せずに実行しようとした場合にも発生します。別の原因として、「make install」を実行したが、ライブラリが動的リンカー/ローダーが認識しない場所にインストールされた場合も考えられます。Linuxでは、ライブラリディレクトリを/etc/ld.so.confに追加し、ldconfigを実行することで、リンカー/ローダーがライブラリを見つけられるようにすることができます。これを実行したくない場合、またはルートアクセス権がない場合は、LD_LIBRARY_PATH環境変数でライブラリディレクトリを指定することもできます。

リポジトリを見つけたり開いたりする際にエラーが発生しますが、リポジトリURLが正しいことはわかっています。何が悪いのですか？ ¶

この FAQ を参照してください。

リポジトリを見つけたり開いたりするときにエラーが発生していますが、リポジトリのURLは正しいです。何が問題なのですか？`を実行すると、`を実行すると、エラーが発生しますに関するエラーが表示されます。何が悪いのですか？ ¶

おそらく、古いコピーの/usr/local/bin/apr-configおよび/usr/local/bin/apu-configがシステムに存在します。それらを削除し、apr/およびapr-util/が最新であることを確認してから、もう一度試してください。

MSVC++ 6.0を使用してWindowsでSubversionをビルドする際に問題が発生しています。どうすればいいですか？ ¶

おそらく、最新のプラットフォームSDKを入手するだけで十分です。VC++ 6.0に付属しているものは、最新のものではありません。

MSVC++ 6.0を使用してWindowsでSubversionをビルドするときに問題が発生しています。どうすればよいですか？どのようにWindowsドライブ文字をURLは？ ¶

こんな感じです

svn import file:///d:/some/path/to/repos/on/d/drive

詳細はSubversion BookのSubversionリポジトリURLを参照してください。

Microsoft Visual Studio 2002および2003には、".svn"ディレクトリ名に関する問題があるようです。どうすればよいですか？ ¶

Visual StudioはASP.Net用のWebサブシステムを使用でき、これはFrontPageサーバー拡張機能を使用してIIS経由でリモート公開を行います。このサブシステムは、"."で始まるパス名を拒否します。そのため、".svn"サブディレクトリがあるため、Subversionの作業コピーをリモートで公開しようとすると問題が発生します。エラーメッセージには「プロジェクト情報を読み取ることができません」のような内容が表示されます。

これを回避するには、環境変数SVN_ASP_DOT_NET_HACKに任意の値 — を設定してください。これにより、Windowsクライアントは作業コピーでディレクトリ名として"_svn"を使用するようになります。詳細は、Subversion 1.3リリースノートの関連セクション、および管理ディレクトリ名のカスタマイズ方法についてはこの質問を参照してください。

ネットワーク経由でSubversionリポジトリへの書き込み操作を行う際に問題が発生しています。 ¶

たとえば、あるユーザーはローカルアクセスではインポートが正常に機能したと報告しています

  $ mkdir test
  $ touch test/testfile
  $ svn import test file:///var/svn/test -m "Initial import"
  Adding         test/testfile
  Transmitting file data .
  Committed revision 1.

  $ svn import http://svn.sabi.net/test testfile -m "import"
  nicholas's password: xxxxxxx

  svn_error: #21110 : <Activity not found>

  The specified activity does not exist.

REPOS/dav/ディレクトリがhttpdプロセスによって書き込み可能でない場合に、この問題が発生することを確認しています。Apacheがdav/ディレクトリ（およびdb/ディレクトリももちろん）に書き込みできるように、権限を確認してください。

Subversionクライアントとサーバー間の会話のネットワークトレースを行う最適な方法は？ ¶

/docs/community-guide/debugging.html#net-traceを参照してください。

Subversionクライアントとサーバー間の会話のネットワークトレースを行う最適な方法は何ですか？なぜ明示的なターゲットが必要なのはなぜですか？なぜデフォルトで再帰的ではないのですか？これらの動作は、ほとんどすべての他のサブコマンドとは異なります。 ¶

簡単な答え：それはあなた自身のためです。

Subversionは、バージョン管理されたデータだけでなく、あなたのデータを保護することを非常に重視しています。すでにバージョン管理されているファイルに対する変更や、バージョン管理システムに追加される予定の新しいファイルは、注意して扱う必要があります。

svn revertなぜコマンドに明示的なターゲット（そのターゲットが単に「.」である場合でも）を要求することは、それを実現する1つの方法です。この要件（およびその動作が必要な場合は、--recursive (-R)--recursive (-R)フラグを指定する必要がある）は、ファイルを元に戻すと、ローカルでの変更が永久に失われるため、実際に行っていることを本当に考えてもらうことを目的としています。

Apache（ra_dav）経由でコミットまたはインポートされたファイルに対して、SVNログが「(no author)」と表示されるのはなぜですか？ ¶

Apache経由でリポジトリへの匿名書き込みアクセスを許可すると、ApacheサーバーはSVNクライアントにユーザー名を要求せず、代わりに認証なしで書き込み操作を許可します。Subversionは誰が操作を行ったのかわからないため、このようなログになります。

$ svn log
------------------------------------------------------------------------
rev 24:  (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003)

Apacheでのアクセス制限の構成については、Subversion bookを参照してください。

Windowsで時々「アクセスが拒否されました」エラーが発生します。ランダムに発生するようです。なぜですか？ ¶

これらは、ファイルシステムの変更を監視するさまざまなWindowsサービス（ウイルス対策ソフトウェア、インデックスサービス、COM +イベント通知サービス）によるものと思われます。これはSubversionのバグではないため、修正が困難です。調査の現在の状況の要約はこちらで確認できます。ほとんどの人の発生率を減らすはずの回避策がリビジョン7598で実装されました。以前のバージョンをお使いの場合は、最新リリースにアップデートしてください。

FreeBSDでは、特定の操作（特にsvnadmin create）が時々ハングします。なぜですか？ ¶

これは通常、システムで利用可能なエントロピーが不足していることが原因です。ハードディスクやネットワーク割り込みなどのソースからエントロピーを収集するようにシステムを構成する必要があるかもしれません。この変更を行う方法については、システムのマニュアルページ、特にrandom(4)とrndcontrol(8)を参照してください。

Webブラウザでリポジトリを表示できますが、'svn checkout'を実行すると「301 Moved Permanently」というエラーが表示されます。何が問題ですか？ ¶

これは、httpd.confが正しく構成されていないことを意味します。通常、このエラーは、Subversionの仮想「location」を同時に2つの異なるスコープ内に存在するように定義した場合に発生します。

たとえば、リポジトリを次のようにエクスポートした場合<Location /www/foo>、さらにDocumentRootを/wwwに設定した場合、問題が発生します。リクエストが/www/foo/barに対して行われたとき、apacheは、/foo/barという名前の実際のファイルをDocumentRootで検索するか、mod_dav_svnに/barファイルを/www/fooリポジトリからフェッチするように要求するかを判断できません。通常、前者の方が優先されるため、「Moved Permanently」エラーが発生します。

解決策は、リポジトリの<Location>が、すでに通常のWeb共有としてエクスポートされている領域と重複したり、その中に存在したりしないようにすることです。

Webルートに、リポジトリURLと同じ名前のオブジェクトがある可能性もあります。たとえば、Webサーバーのドキュメントルートが/var/wwwで、Subversionリポジトリが/home/svn/repoにあるとします。次に、Apacheがhttp://localhost/myrepoでリポジトリを提供するように構成します。次に、/var/www/myrepo/ディレクトリを作成すると、301エラーが発生します。

AIXでxlcを使用してコンパイルすると、コンパイルエラーが発生します。何が問題ですか？ ¶

構成とビルド用の環境変数CFLAGSに-qlanglvl=extendedを追加すると、xlcが少し柔軟になり、コードがエラーなしでコンパイルされるようになります。詳細については、https://svn.haxx.se/dev/archive-2004-01/0922.shtmlとその関連スレッドを参照してください。

AIXでxlcでコンパイルすると、コンパイルエラーが発生します。何が問題なのですか？ディレクトリを非再帰的に（-Nを使用）チェックアウトしましたが、特定のサブディレクトリを「表示」させたいと考えています。しかしsvn checkout -N が機能しません。 ¶

issue 695を参照してください。svn checkout -Nsvn checkout -Nの現在の実装は非常に壊れています。エントリが欠落しているにもかかわらず、「不完全さ」を認識していない作業コピーになります。明らかに、多くのCVSユーザーはこのパラダイムにかなり依存していますが、Subversionの開発者は誰もそうではありませんでした。今のところ、プロセスを変更する以外に回避策はありません。リポジトリの個別のサブディレクトリをチェックアウトして、作業コピーを手動でネストしてみてください。

動作しません。Win32でApacheを使用してmod_dav_svnを使用しようとしていますが、モジュールが見つからないというエラーが表示されますが、mod_dav_svn.soファイルは ¶

この場合のエラーメッセージは少し誤解を招きやすいです。おそらくApacheは、mod_dav_svn.soが依存する1つ以上のDLLをロードできません。Apacheがサービスとして実行されている場合、通常のユーザーと同じPATHになりません。次のものがlibdb4*.dll, intl3_svn.dll, libeay32.dllおよびssleay32.dllのいずれかに存在することを確認してください。\Apache\binまたは\Apache\modulesに存在することを確認してください。存在しない場合は、Subversionのインストールディレクトリからコピーできます。

それでも問題が解決しない場合は、Dependency Walkerなどのツールを使用してmod_dav_svn.soで、未解決の依存関係がないか確認する必要があります。

リポジトリフックが機能しないのはなぜですか？ ¶

外部プログラムを呼び出すはずですが、呼び出しはまったく行われないようです。

Subversionは、フックスクリプトを呼び出す前に、環境からすべての変数（Unixの$PATH、Windowsの%PATH%を含む）を削除します。したがって、スクリプトは、プログラムの絶対名を記述した場合にのみ、別のプログラムを実行できます。

フックスクリプトの名前が正しく付けられていることを確認してください。たとえば、post-commitフックは、Unixではpost-commit（拡張子なし）と名前を付ける必要があります。Windowsではpost-commit.batまたはpost-commit.exeです。

デバッグのヒント

LinuxまたはUnixを使用している場合は、次の手順に従って、スクリプトを「手動で」実行してみてください。

1. "su"、"sudo"などのツールを使用して、通常スクリプトを実行するユーザーになります。これは、Apacheを使用している場合はhttpdまたはwww-dataである可能性があります。svnserveを実行していて、特別なSubversionユーザーが存在する場合は、svnなどのユーザーである可能性があります。これにより、スクリプトに発生する可能性のある権限の問題が明確になります。
2. 「env」プログラムを使用して、空の環境でスクリプトを呼び出します。post-commitフックの例を次に示します

                     $ env - ./post-commit /var/lib/svn-repos 1234
   

   「env」の最初の引数はダッシュであることに注意してください。これにより、環境が空であることが保証されます。
3. コンソールでエラーを確認します。

--diff-cmdが'-u'について不平を言うのはなぜですか？ --extensionsでオーバーライドしようとしましたが、機能しません。 ¶

外部diffコマンドを使用する場合、Subversionはかなり複雑なコマンドラインを作成します。最初は指定された--diff-cmdです。次に、指定された--extensions（空の--extensionsは無視されます）、または--extensionsが指定されていない（または '' として指定されている）場合は'-u'が続きます。3番目と4番目に、Subversionは'-L'と最初のファイルのラベル（例：「project_issues.html（リビジョン11209）」）を渡します。5番目と6番目は、別の'-L'と2番目のラベルです。7番目と8番目は、最初と2番目のファイル名（例：「.svn/text-base/project_issues.html.svn-base」と「.svn/tmp/project_issues.html.tmp」）です。

優先するdiffコマンドがこれらの引数をサポートしていない場合は、引数を破棄して最後の2つのファイルパスだけを使用する小さなラッパースクリプトを作成する必要があるかもしれません。

警告：Subversionは、外部diffプログラムが受信したファイルを変更することを想定しておらず、変更すると作業コピーがスクランブルされる可能性があることに注意してください。

詳細については、#2044を参照してください。

Subversionはどのようにしてクレデンシャル（平文および暗号化）をキャッシュしますか？ ¶

サーバー操作ごとにパスワードを入力する必要を避けるために、Subversionはクレデンシャルをキャッシュできます。

パスワードは、古いバージョンのSubversionで暗号化されていない状態でキャッシュされた可能性があります（「grandfathered in」）。Subversionは常にこれらの読み取りをサポートしています。Subversionが新しいクレデンシャルをキャッシュするかどうか、およびその方法は、アクセス方法、オペレーティングシステム、コンパイル時オプション、およびクライアントの実行時構成ファイルの設定など、いくつかの要因によって異なります。

キャッシュ内のクレデンシャルを表示するには、次を使用しますsvn authクレデンシャルは自動的に削除されることはありませんが、次のコマンドを使用して手動で削除できますsvn auth --remove.

Windows

Windowsでは、Subversionは標準のWindows APIを使用してデータを暗号化するため、ユーザーのみがキャッシュされたパスワードを復号化できます。（Subversion 1.2以降）

macOS（旧Mac OS X）

macOSでは、Subversionはシステムのキーチェーン機能を使用して、ユーザーのsvnパスワードを暗号化/保存します。（Subversion 1.4以降）

UNIX/Linux

UNIX/Linuxでは、Subversionは最大4つのクレデンシャルキャッシュをサポートします

• GNOME Keyring
• KWallet
• GPG-Agent
• ~/.subversion/auth/svn.simple/にある平文キャッシュ

Subversionクライアントがサポートするクレデンシャルキャッシュを特定するには、svn --versionコマンドを実行し、出力の最後の方にある「次の認証クレデンシャルキャッシュが利用可能です」を探してください。

GNOME KeyringとKWalletは、どちらもディスクにパスワードを暗号化して保存することを容易にします。Subversionがこれらのプログラムをサポートするためには（Subversion 1.6以降）、コンパイル時および実行時に利用可能である必要があります。

TODO：GPG-Agentについて議論します。

コンパイル時オプション（--enable-plaintext-password-storage）および実行時構成（下記参照）によっては、Subversionは平文キャッシュにパスワードを保存するようにフォールバックする可能性があります。

Subversion 1.12 で、--enable-plaintext-password-storage のデフォルト値が True から False に変更されました。これにより、明示的に有効にしない限り、プレーンテキストキャッシュは無効になりました。

キャッシュされたプレーンテキストパスワードが格納されるディレクトリ（通常は~/.subversion/auth/）のパーミッションは 700 であり、ユーザー（および root）のみが読み取ることができます。

「Subversion はプレーンテキストパスワードキャッシュのサポート付きでコンパイルされましたが、プレーンテキストキャッシュにパスワードを書き込みたくありません。」

以下のオプションは、実行時設定ファイル（ユーザーごとの ~/.subversion/config および ~/.subversion/servers、システム全体の /etc/subversion/config および /etc/subversion/servers）で利用できます。

• GNOME Keyring や KWallet のような暗号化されたストレージを許可し、プレーンテキストキャッシュは許可しない場合は、以下を設定します。store-plaintext-passwords = no.
• サーバー証明書をキャッシュすることは許可するが、パスワード（暗号化されているかどうかに関わらず）は許可しない場合は、以下を設定します。store-passwords = no.
• あらゆる種類の認証情報（暗号化されているかどうかに関わらず）の保存を無効にするには、以下を設定します。store-auth-creds = no.

「プレーンテキストキャッシュを使用したいのですが、コンパイル時に有効にされていませんでした。」

さまざまな質問やリクエストに応えて、Subversion の開発者は、プレーンテキストパスワードをキャッシュに保存できる Python スクリプトを作成しました。セキュリティ上の影響を理解し、他の代替手段を排除し、それでもディスク上にパスワードをプレーンテキストでキャッシュしたい場合は、（執筆時点では）trunk の tools/client-side/ ディレクトリにスクリプトがあります。

追加情報

パスワードキャッシュの詳細については、Subversion book の第 6 章の「クライアント認証情報のキャッシュ」を参照してください。

リポジトリのホットバックアップができません。svnadmin が 2GB より大きいファイルで失敗します！ ¶

Apache 2.0.x および Subversion 1.x が使用する APR の 0.9 ブランチの初期バージョンでは、大きなファイル（2GB 以上）のコピーがサポートされていません。「svnadmin hotcopy」の問題を解決する修正が適用され、APR 0.9.5 以降および Apache 2.0.50 以降に含まれています。この修正はすべてのプラットフォームで動作するわけではありませんが、Linux では動作します。

コミットしたばかりのファイルのログエントリが表示されません。なぜですか？ ¶

リポジトリで'svn checkout' を実行して、1 つのファイル foo.c が含まれているリビジョン 7 (r7) の作業コピーを受け取ったと仮定します。foo.c。ファイルを修正してコミットが成功すると、次の 2 つのことが起こります。

• リポジトリはサーバー上の新しい HEAD リビジョンに移動します。新しい HEAD リビジョンの番号は、作業コピーがチェックアウトされてから他のコミットがいくつ行われたかによって異なります。たとえば、新しい HEAD リビジョンは r20 になる可能性があります。
• 作業コピーでは、ファイルfoo.cのみが r20 に移動します。作業コピーの残りの部分は r7 のままです。

これで、混合リビジョン作業コピーとして知られる状態になりました。1 つのファイルは r20 にありますが、他のすべてのファイルは、コミットされるか、'svn update' が実行されるまで、r7 のままです。

   $ svn -v status
    7         7 nesscg       .
   20        20 nesscg       foo.c
   $

'svn log' コマンドを引数なしで実行すると、現在のディレクトリ（上記リストの'.'）のログ情報が出力されます。ディレクトリ自体はまだ r7 であるため、r20 のログ情報は表示されません。

最新のログを表示するには、次のいずれかを実行します。

1. 'svn log -rHEAD'.
2. 'svn log URL' を実行します。ここで、URL はリポジトリの URL です。現在のディレクトリが作業コピーの場合、URL をリポジトリのルートに短縮して^/入力の手間を省くことができます。Windows では、"^" 記号が特殊文字であり、引用符で囲む必要があることに注意してください。例：svn log "^/" --limit 10
3. 'svn log URL' を実行します。ここで、URL はログを表示したいサブディレクトリの URL です。例：svn log ^/trunk
4. ' を実行して、そのファイルのみのログ情報を要求します。svn log foo.c'.
5. 作業コピーをすべて r20 に更新してから、'svn log'.

なぜ MacOS X 10.4 (Tiger) で実行されているリポジトリから http:// 経由でチェックアウトすると、時々、一貫性のないエラーが発生するのですか？ ¶

注: これは、リポジトリが Apache 2.0.x によって提供されていることを前提としています。

Tiger で実行されている場合に存在する APR 0.9.6 のバグがあり、64KB より大きいファイルをチェックアウトしようとすると発生します。結果として、チェックアウトが失敗し、多くの場合、予測できないエラーメッセージが表示されます。以下は、クライアント側で表示される可能性のあるエラーの例です。特定のエラーは異なる場合があります。

   svn: Invalid diff stream: [tgt] insn 1 starts beyond the target view position

   svn: Unexpected end of svndiff input

   svn: REPORT request failed on '/path/to/repository'
   svn: REPORT of '/path/to/repository/!svn/vcc/default': Chunk delimiter was invalid

Apache の error_log にもエラーが発生する可能性があります。例：

   [error] Provider encountered an error while streaming a REPORT response.  [500, #0]
   [error] A failure occurred while driving the update report editor [500, #190004]

このバグの存在を確認するには、リポジトリが提供されているマシンにアクセスできると仮定して、Apache を介さずにファイルシステムに直接アクセスする file:// URL を使用してチェックアウトを試してください。結果のチェックアウトが正常に完了した場合、ほぼ間違いなくこれが問題です。

現在、最善の解決策は APR 1.2.0 以降にアップグレードすることです。

または、Apache と Subversion をそれぞれのソースから再構築し、Apache の構成を実行する前に、次の環境変数を設定できます。

   setenv ac_cv_func_poll no

または、Bourne シェルの構文で、次のようになります。

   ac_cv_func_poll=no; export ac_cv_func_poll

APR/APRUTIL を個別に構築した場合（つまり、Apache の tarball の一部として付属しているものを使用しなかった場合）、問題がある場所であるため、APR の構成を実行する前にその環境変数を設定する必要があります。

Debian GNU/Linux で作業コピーソースから Subversion をビルドできません。最終リンク段階でエラーが発生します。何が問題ですか？ ¶

Subversion trunk ソースのビルドの最終リンク段階で次のようなエラーが表示される場合

   /usr/local/apache2/lib/libaprutil-0.so.0: undefined reference to `db_create'
   /usr/local/apache2/lib/libaprutil-0.so.0: undefined reference to `db_strerror'

Debian GNU/Linux システムを使用しており、'libtool' をアップグレードする必要がある可能性があります。（また、Debian パッケージャーが 'libtool' を調整する必要があり、これが Subversion ビルドでいくつかの問題を引き起こす可能性があるとも聞いています。しかし、それは噂です。この FAQ エントリを作成する前に詳細を確認する時間がありませんでした。ただし、https://svn.haxx.se/dev/archive-2006-02/1214.shtml とそこから派生したスレッドで詳細な議論を参照してください。）

いずれにせよ、2005 年 11 月 15 日に新たに dist-upgraded された 'testing' ディストリビューションを実行している Debian GNU/Linux システムでこの問題が発生した後、解決策は、標準の "./configure && make && sudo make install" レシピを使用して、ソースから libtool 1.5.20 をビルドすることでした。その後、Subversion 作業コピーツリーで 'make clean'、'./autogen.sh'、'./configure'、'make' を実行したところ、すべて正常に動作しました。

これらの症状の別のレポートが https://svn.haxx.se/dev/archive-2003-01/1125.shtml に表示されましたが、ここで説明した解決策はそのスレッドでは言及されていませんでした。

svnserve を起動しましたが、ポート 3690 でリッスンしていないようです。 ¶

次のように起動します。svnserve以下のオプションを使用します。--listen-host=0.0.0.0オプション。Svnserve は IPv4/IPv6 デュアルスタック動作を適切にサポートしていません。issue #2382 を参照してください。

Subversion から「既にバージョン管理下にある」と言われるため、ディレクトリを追加できません。 ¶

追加しようとしているディレクトリには、既に.svnサブディレクトリが含まれています。これは作業コピーですが、追加しようとしているディレクトリとは異なるリポジトリの場所からのものです。これはおそらく、この作業コピーのサブディレクトリをコピーするか、別の作業コピーをこの作業コピーにコピーするために、オペレーティングシステムの「コピー」コマンドを使用したためです（いつの代わりに）。

手っ取り早い解決策は、追加しようとしているディレクトリに含まれているすべての.svnディレクトリを削除することです。これにより、「add」コマンドが完了します。Unix を使用している場合、このコマンドは.svn以下のディレクトリを削除します。dir:

  find dir -type d -name .svn -exec rm -rf {} \;

ただし、コピーが同じリポジトリからのものである場合は、コピーを削除するか移動し、いつを使用して適切なコピーを作成する必要があります。これにより、履歴がわかり、リポジトリ内のスペースを節約できます。

異なるリポジトリからのコピーである場合は、なぜこのコピーを作成したのかを自問自答する必要があります。また、このディレクトリを追加することで、リポジトリに不要なコピーが作成されないようにする必要があります。

svnserve を介して非公開リポジトリにアクセスすると、非常に遅くなることがあります。 ¶

これは多くの場合、APR が/dev/randomを使用するようにコンパイルされ、サーバーが十分なエントロピーを収集できない場合に発生します。Subversion がサーバーで APR を使用する唯一のアプリケーションである場合は、APR を--with-devrandom=/dev/urandomオプションを`に渡して安全に再コンパイルできます。ただし、これは、他のサービスを安全でなくする可能性があるため、APR を他のプロセスに使用するシステムでは実行しないでください。

svnserve経由で非公開のリポジトリにアクセスすると、非常に遅くなることがあります。SSLを介して大量のデータを含むSubversion操作を実行すると、次のエラーが表示されます。 ¶

これは、OpenSSL 0.9.8 の問題が原因で発生する可能性があります。古いバージョンにダウングレードする（または新しいバージョンにアップグレードする）と、この問題が修正されることがわかっています。

「このクライアントは古すぎます」というエラーが表示されます。 ¶

svn: This client is too old to work with working copy
'/path/to/your/working/copy'; please get a newer Subversion client

「このクライアントは古すぎます」というエラーが表示されます。なぜは場合によっては動作しませんか？ ¶

作業コピーにバージョン管理されていない（および無視されている可能性のある）項目がある場合、なぜエラーが発生する可能性があります。切り替えが停止し、作業コピーが半分切り替えられたままになります。

残念ながら、誤った修正アクションを実行すると、使用できない作業コピーになる可能性があります。このような状況では、ユーザーにsvn cleanupを実行するように指示されることがあります。しかし、svn cleanupもエラーが発生する可能性があります。issue #2505 を参照してください。

ユーザーは、問題の原因となっているディレクトリまたはファイルを手動で削除し、svn cleanupを実行して切り替えを続行し、この状況から回復できます。

元のクリーンなチェックアウトからの切り替えは常にエラーなしで動作することに注意してください。なぜを開発プロセスの一部として使用している場合は、3 つの方法があります。

1. 切り替えを行う前に、バージョン管理されていない（無視されているファイルを含む）ファイルで作業コピーを完全にクリーンにします。
   警告！これにより、バージョン管理されていないすべてのディレクトリ/ファイルが削除されます。削除されるものが何も必要ないことを確認してください。

   
   # Check and delete svn unversioned files: 
   svn status --no-ignore | grep '^[I?]' | sed 's/^[I?]//'
   svn status --no-ignore | grep '^[I?]' | sed 's/^[I?]//' | xargs rm -rf
   

2. きれいなクリーンなチェックアウトを維持してください。それを更新してからコピーし、別のブランチへの切り替えが必要な場合はコピーを切り替えます。
3. 危険を冒しましょう:)。クリーンアップせずにブランチを切り替えます。ただし、切り替えエラーが発生した場合は、適切に回復する必要があることを理解してください。エラーが報告された場所に、バージョン管理されていないファイルとディレクトリを削除します。次に、必要に応じて「svn cleanup」を実行し、切り替えを再開します。すべてのバージョン管理されていないファイルを削除しない限り、このプロセスを複数回繰り返す必要がある場合があります。

いくつかの例がこちら、課題2505に詳しく説明されています。問題は、svnクライアントが安全側に立ち、バージョン管理されていないものを何も削除したくないということです。

このような問題を説明するために、2つの具体的な例を以下に詳しく示します。他にも、ここで説明されていない、きれいなチェックアウトからのみ切り替えることで回避できるsvnの切り替えエラーがあります。

1. ブランチ間でディレクトリが移動または名前変更された場合、バージョン管理されていないものはすべて問題を引き起こします。この場合、次のエラーが表示されます
   

   
   wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
   svn: Won't delete locally modified directory '<dir>'
   svn: Left locally modified or unversioned files
   

   バージョン管理されていないファイルをすべて削除し、切り替えを続行すると、ここから回復します。

2. 一時的なビルドファイルが追加および削除されたことがある場合、そのバージョン管理されていないファイル（おそらくビルド後）があるリポジトリでの切り替えは失敗します。同じエラーが表示されます

   
   wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
   svn: Won't delete locally modified directory '<dir>'
   svn: Left locally modified or unversioned files
   

   この場合、バージョン管理されていないアイテムを削除しただけでは回復しません。クリーンアップは失敗しますが、「svn switch」は「svn cleanup」を実行するように指示します。

   
   wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
   svn: Directory '<dir>/.svn' containing working copy admin area is missing
   wc/$ svn cleanup
   svn: '<dir>' is not a working copy directory
   wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
   svn: Working copy '.' locked
   svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
   

   ディレクトリ（およびその他すべてのバージョン管理されていないファイル。同様のエラーで「switch」が繰り返し中断するのを防ぐため）を削除し、切り替えを続行すると、ここから回復します。

TortoiseSVNのクリーンアップエラーは少し異なります。次のようなエラーが発生する可能性があります

Subversion reported an error while doing a cleanup!
<dir>/<anotherdir> is not a working copy directory

ここでの各ケースで、「svn switch」は中断し、半分切り替えられた作業コピーが残ります。「svn status」は、切り替えられたアイテム（トップディレクトリとは異なる）、問題のあるディレクトリの!、および問題のあるファイル（およびおそらくロックされたL）をSで表示します。こんな感じです

wc/$ svn status 
!      .
!      <dir>
    S  <switched_things>
~      <dir>/<thing_that_is_now_unversioned>

Windowsで、コマンドラインクライアントを使用して更新を行うと、「指定されたパスが見つかりません」というエラーが表示され、作業コピーが破損している可能性があることが示唆されます。しかし、TortoiseSVNでは問題なく更新できます。何が起こっているのでしょうか？ ¶

ファイルの名前付けに関するWindows APIドキュメントを注意深く調べると、これが起こる最も一般的な理由がわかります。要するに、Windowsパス関数のUnicodeバージョンを使用し、相対パス指定子ではなく絶対パス指定子を提供することで、大幅に長いパス名に対処できます。幸いなことに、Subversionが使用するApache Portable Runtime（APR）ライブラリは、（C:\WorkingCopy\file.txt）のような絶対パスを、Windows APIに必要な形式（\\?\C:\WorkingCopy\file.txt）に透過的に変換し、また元に戻します。残念ながら、これらの長いパスのメリットは、絶対パスを使用する場合にのみ得られます。

パスの長さが問題の原因であるかどうかを確認するには、相対パス（または何も指定しない）ではなく、Subversionコマンドラインクライアントに絶対ターゲットパスを指定してみてください。言い換えれば、次の操作を行う代わりに

C:\> svn up WorkingCopy

またはこれの代わりに

C:\> cd C:\WorkingCopy
C:\WorkingCopy> svn up

これを実行します

C:\> svn update C:\WorkingCopy

問題が解決したら、おめでとうございます。Windowsのパス長の制限に達しました。そして、これで回避策がわかりました。

なぜこの問題はTortoiseSVNに影響しないのですか？ TortoiseSVNは常に、Subversion APIに絶対パスを提供するためです。

それでは、なぜSubversionコマンドラインクライアントは、その入力を常に絶対パスに変換して使用しないのでしょうか？ Subversion 1.7以降、変換します。

「このクライアントは、作業コピー「...」を操作するには古すぎます」というエラーが表示されました。Subversionをアップグレードせずにこれを修正するにはどうすればよいですか？ ¶

マイナーリリース間で作業コピーのメタデータ形式が非互換的に変更される場合があります。たとえば、Subversion 1.4.4で作成された作業コピーがあるが、ある日Subversion 1.5.0を試してみることにしたとします。その後、1.4.4に戻そうとすると、うまくいきません。上記のエラーが表示されるだけです。

これは、1.5.0が新しい機能（この場合は、変更リスト、keep-localフラグ、および可変深度ディレクトリ）をサポートするために作業コピー形式をアップグレードしたためです。1.4.4はこれらの新機能については何も知りませんが、作業コピー形式が処理できるよりも高いものにアップグレードされたことを少なくとも認識できます。

1.5.0が作業コピーをアップグレードしたのは正当な理由があります。1.4.4がこれらの新機能について知らず、1.4.4が今作業コピーメタデータに干渉すると、重要な情報が失われ、破損する可能性があることに気付いているためです（たとえば、課題＃2961を参照）。

Subversion 1.7.0以降は、明示的に要求しない限り、作業コピーをアップグレードしません。（ただし、作業コピーのアップグレードは必須です。Subversion 1.7.0は、以前のSubversionで作成または使用された作業コピーを操作できません。）

Subversion 1.6.x以前は、最初に作業コピーに触れたときに自動的にアップグレードします。これを永続的にインストールせずに、新しいリリースのSubversionを試したいだけの場合は、この動作は迷惑な可能性があります。このため、安全な場合に作業コピーをダウングレードできるスクリプトを配布しています

https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py

スクリプトを「--help」オプションを指定して実行し、その使用方法を確認してください。（1.6.xの作業コピーをSubversion 1.4.xおよび1.5.xで使用可能な形式にダウングレードできますが、1.7.xの作業コピーはダウングレードできません。）

Subversionの将来のバージョンがリリースされるにつれて、このFAQエントリを、ダウングレードの可能性のあるシナリオとその影響について最新の状態に保つように努めます。

64ビットLinuxでNeonライブラリをビルドしているときに、「共有オブジェクトを作成するときに、`ローカルシンボル`に対する再配置R_X86_64_32を使用できません」というエラーが表示されました。 ¶

HTTPを介してSubversionサーバーとクライアント間の通信に使用されるNeonライブラリは、通常は静的ライブラリとしてビルドされます。しかし、その後、別の共有ライブラリにリンクされます。これにより、64ビットAMDシステムで次のようなビルドプロセス中にエラーが発生します

subversion-1.4.6/neon/src/.libs/libneon.a(ne_request.o): relocation R_X86_64_32
against `a local symbol' can not be used when making a shared object;
recompile with -fPIC
/home/jrandom/subversion/subversion-1.4.6/neon/src/.libs/libneon.a: could not
read symbols: Bad value

これについては、開発者リストでスレッドがありました。

解決策は、Subversionのconfigureスクリプトに「--enable-shared」オプションを指定することです。

Apacheからチェックアウトを行うときに、「応答本文を読み取れませんでした：セキュアな接続が切断されました」というエラーが表示されるのはなぜですか？ ¶

要するに、このエラーは、Apacheが、SubversionクライアントがApacheとのネットワーク接続を維持しなくなったと誤って認識した場合に発生する可能性のある問題のクラスを表しています。SSLが接続に使用されたかどうか、またはApacheが接続を終了する必要があると判断した正確な時期に応じて、同様の状況で他のエラーメッセージが報告されています。

Subversionクライアントは、作業コピーを常に正常な状態に保つように努めています。チェックアウト中にこれを行う1つの方法は、特定のディレクトリのすべてのファイルとサブディレクトリがフェッチされるまで、チェックアウトされたファイルの元のバージョンを保存することです。ディレクトリのすべてのデータがダウンロードされると、クライアントはそのディレクトリを「ファイナライズ」し、ファイルの元のバージョンを作業領域にコピーし、管理データを修正するなどを行います。このディレクトリのファイナライズが行われている間、クライアントはそのタスクに集中しており、チェックアウトネットワークストリームに対応していません。場合によっては、特に、バージョン管理されたディレクトリに異常に多数のファイルが含まれている場合、または異常に大きなファイルが多数含まれている場合に、クライアントはディレクトリのファイナライズに多くの時間を費やし（ネットワークストリームを無視します）、Apacheはクライアントが完全に消えたと考えるため、Apacheは接続を終了します。クライアントがようやくネットワークストリームに注意を戻すと、サーバーが接続をあきらめたことを発見し、これをエラーとして報告します。

この状況の回避策の1つは、クライアントがネットワークストリームをリッスンし続けていることを証明するために、Apacheが待機する時間を長くすることです。これを行うには、ApacheのTimeout設定値を調整します。ただし、データセットを評価することをお勧めします。単一のディレクトリに大量のファイルがあることがチェックアウト中に問題を引き起こしている場合は、他の場所でも追加の問題を引き起こす可能性があります。ファイルのコレクションを、ファイル数が少ないいくつかのサブディレクトリに分割できる場合は、それが普遍的に有益であることが証明される可能性があります。

他の誰も競合する変更をコミットしていないにもかかわらず、更新時にツリー競合が発生するのはなぜですか？ ¶

コミットすると、コミットによって実際に変更されたファイル/ディレクトリのみが、作業コピーで基本リビジョンがHEADにバンプされます。他のファイル/ディレクトリ（コミット元のディレクトリを含む可能性があります）は、基本リビジョンがバンプされないため、Subversionは依然としてそれらを古いリビジョンに基づいていると見なします。この質問およびSubversionのこのセクションも参照してください。

これは混乱を招く可能性があり、特に、自分自身にツリー競合を引き起こす可能性があるためです。たとえば、ディレクトリにファイルを追加してコミットし、そのディレクトリをローカルで別の場所に移動してからコミットしようとすると、ディレクトリ自体が古いリビジョンに基づいているため、この2回目のコミットは古いエラーで失敗します。更新すると、ツリー競合がフラグ付けされます。

Subversionには、2回目のコミット中にディレクトリを古くした変更を自分自身がコミットしたばかりであることを知る方法が現在ありません。また、古いディレクトリをコミットすることを許可すると、特定のツリー競合が検出されない可能性があるため、Subversionではこれを許可できません。

この問題を回避するには、ファイルまたはディレクトリの削除、追加、移動などの構造的な変更を行う前に、必ず作業コピー全体を更新してください。

他の誰も競合する変更をコミットしていないのに、更新時にツリー競合が発生するのはなぜですか？SSLを介してSubversion操作を実行すると、次のエラーが表示されます。 ¶

これは、サーバーから報告されるホスト名が SSL 証明書で指定されているホスト名と一致しない場合に発生する可能性があります。サーバー構成で以下の正しい値を使用していることを確認してください。ServerNameおよびNameVirtualHost.

クライアント側の修正としては、OpenSSL をバージョン 1.0.0d にアップデートすることです。詳細は、Subversion 開発者メーリングリストのこの投稿を参照してください。

SSLハンドシェイクに失敗しました：SSLエラーコード-1/1/336032856"サーバー証明書の検証エラー"サーバーで SSL 証明書を正しく設定してもエラーが発生します。¶

このエラーは、証明書の発行者が SVN クライアントによって「信頼済み」として認識されない場合に発生します。Subversion は、証明書を信頼するかどうか、およびこの証明書を保存するかどうかを尋ねてきます。

$ svn info https://mysite.com/svn/repo
Error validating server certificate for 'https://mysite.com:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
Certificate information:
- Hostname: mysite.com
- Valid: from Wed, 18 Jan 2012 00:00:00 GMT until Fri, 18 Jan 2013
23:59:59 GMT
- Issuer: Google Inc, US
- Fingerprint:
34:4b:90:e7:e3:36:81:0d:53:1f:10:c0:4c:98:66:90:4a:9e:05:c9
(R)eject, accept (t)emporarily or accept (p)ermanently?

場合によっては、「p」オプションを入力してこれを受け入れたとしても、次回 SVN にアクセスしたときに同じエラーが再び表示されます。これには複数の理由が考えられます。問題は、~/.subversion ディレクトリの権限が間違っている可能性があり、そのため、資格情報を永続的に追加するたびに、svn が実際にはそれを実行できず、また、実行できないことを通知もしないという場合があります。

これは、以下のコマンドで権限を修正するか

~/.subversion/auth/svn.ssl.server

ディレクトリの内容を削除することで解決できます。削除した場合、次回リポジトリにアクセスしたときにディレクトリが自動的に作成されます。

リポジトリにファイルをインポートした後、リポジトリディレクトリにファイルが表示されません。ファイルはどこにありますか？¶

ファイルはリポジトリにあります。これは、以下のようなコマンドを実行することで確認できます。svn ls -R、またはリポジトリからワーキングコピーをチェックアウトしようとすることで確認できます。

  $ pwd
  /var/srv/repositories/foo
  $ ls -1
  conf
  db
  format
  hooks
  locks
  README.txt
  $ svnlook youngest /var/srv/repositories/foo
  1
  $ svn ls file:///var/srv/repositories/foo
  trunk/
  tags/
  branches/

バージョン管理されたファイルとディレクトリは、単にツリー形式（以前の CVS リポジトリのように）でディスクに保存されるのではなく、代わりにデータベースファイルに保存されます。BDB バックエンドは Berkeley DB データベースを使用し、FSFS バックエンドはカスタムファイル形式を使用し、将来的には SQLite データベースを使用する可能性があります。

リポジトリにファイルをインポートした後、リポジトリディレクトリに表示されません。どこにありますか？いつsvn copy作成プロパティについて？¶

一般に、いくつかの種類の間違ったマージコンフリクトを避けるために、次のルールを心に留めておくことができます。

• トランクまたはブランチ内でファイルまたはディレクトリをコピー/名前変更する場合は、ワーキングコピーでコピー/名前変更を実行します。名前変更の場合、ワーキングコピーは混合リビジョンのワーキングコピーであってはなりません。
• ブランチ全体をコピー/名前変更する場合は、リポジトリ（つまり URL を介して）でコピー/名前変更を実行します。

ソースが URL で、ターゲットが URL またはワーキングコピーのいずれかであるコピー中には、コピーターゲットに明示的なマージ情報が作成されます。これは、ブランチが以下のように作成された場合に

svn copy ^/trunk ^/branches/mybranch

svn copy ^/branches/another-branch/foo ^/branches/mybranch/bar

ソースとターゲットの両方がワーキングコピー内にあるコピー中には、コピーターゲットにマージ情報は作成されません（Subversion 1.5.5 以降）。これは、新しい子がトランク（またはブランチ）に追加され、この追加が定期的なキャッチアップマージを使用して同期を維持している別のブランチにマージされる場合を想定しています。この場合、ブランチの新しい子の継承されたマージ情報は正しいものであり、明示的なマージ情報を作成すると、子と親のマージ履歴に明らかな事実上不正確な違いが生じるため、間違ったマージコンフリクトが発生する可能性があります。

この動作に関する追加の詳細と議論については、ユーザーメーリングリストのこの投稿を参照してください。

いくつかの特殊文字を含むパスワードが機能しないように見えるのはなぜですか？¶

非 ASCII 文字を含むパスワードは、Subversion がサポートする基本的な認証メカニズムでは確実に機能しない場合があります。これは、クライアントシステムとサーバーシステム間の潜在的な文字エンコーディングの違いによるものです。詳細については、このメーリングリストの投稿を参照してください。

回避策として、Kerberos や SSPI などのシングルサインオンメカニズムを使用するように Subversion サーバーを構成できます。詳細については、Apache HTTPD サーバーのドキュメントを参照してください。svnserve を使用している場合は、Subversion ブックの「SASL で svnserve を使用する」の章を参照してください。

SSH 認証で svnserve を使用する場合、SSH キーを使用して、このパスワードの制限を回避できます。

HTTP(S) URL-to-URL コピーまたはブランチ/タグ操作に時間がかかるのはなぜですか？¶

HTTP(S) を介して提供される Subversion リポジトリで、サーバー側のコピー（別名、ブランチまたはタグ付け）が遅い場合は、課題 4531に遭遇している可能性があります。この問題は、サーバー上の httpd の mod_dav モジュールによる「コピーするツリー」のクロールが原因で発生します（コピーに SVN の通常のブランチ/タグ付けの O(1) ではなく、O(sizeof(tree)) のパフォーマンスコストがかかります）。この動作は、Apache httpd バージョン 2.2.25（以上）および2.4.6（以上）に存在します。httpd の古いバージョンは影響を受けません。このため、大きなツリーのブランチ/タグ付けに数分かかる場合があります。

この問題は、Subversion 1.8.14 の mod_dav_svn で修正されました。また、次の回避策を使用して、mod_dav が不要な作業をスキップするようにすることもできます。次のディレクティブを、サーバー上の Apache 構成に、できれば SVN 用に構成された Location ブロック内に追加してください。

SetEnvIf Request_Method COPY method_is_copy
RequestHeader set Depth 0 env=method_is_copy

これにより、各 COPY リクエストに値が 0 のリクエストヘッダー「Depth」が追加されます。これにより、mod_dav はコピーされているツリーのクロールを回避します（それでも Subversion は通常再帰的なコピーを実行できます）。

詳細については、このメーリングリストのスレッドを参照してください。

他の誰も競合する変更をコミットしていないのに、更新時にツリー競合が発生するのはなぜですか？SSL通信中にエラーが発生しました ¶

SSL 通信エラーにはさまざまな理由が考えられます。openssl バイナリを使用して SSL 接続をデバッグできます。

openssl s_client -connect example.com:443 -servername example.com

openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem

openssl s_client -connect example.com:443 -servername example.com -cert cert.pem

openssl s_client ... -CAfile path/to/authority.pem

たとえば、s_clientレポート

error setting certificate
140258270184704:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak:../ssl/ssl_rsa.c:303:

RAM ディスクでリグレッションテストを実行するにはどうすればよいですか？¶

インストールせずに、動的な Subversion バイナリでデバッガーを実行するにはどうすればよいですか？¶

unix 系システムでの make install ステップの前に、Subversion ソースツリー内の動的にビルドされた「実行可能ファイル」は、実際には libtool によって生成されたシェルスクリプトであり、実際のバイナリを再リンクして実行します。以下に示すように、これによりデバッグが複雑になります。

subversion$ gdb subversion/svn/svn

... "/path/to/subversion/subversion/svn/svn": 実行可能ファイル形式ではありません: ファイル形式が認識されません

libtool コマンドを介して gdb を実行することで、これを回避できます。実行モードの libtool コマンドは、svn コマンドが libtool ラッパースクリプトであることを検出し、適切な環境変数を設定して、gdb を実行する前にスクリプトを実際のファイルのパスに置き換える処理を行います。

コマンドラインは次のようになります。

$ libtool execute gdb subversion/svn/svn

コンパイラインライン化によってソースが難読化されないように、Subversion バイナリでデバッガーを実行するにはどうすればよいですか？¶

デフォルトでは、gcc は多くの場合、プライベート変数と関数を最適化して削除し、関連する操作をインライン化します。これにより、デバッガーでのコードのステップ実行が複雑になる可能性があります。

unix 系システムでの make ステップ中に最適化をオフにすることで、これを回避できます。

subversion$ make EXTRA_CFLAGS=-O0

(これは「ダッシュオーゼロ」です。) または、次のように configure を実行して、この変更をより永続的にすることもできます。

subversion$ ./configure --enable-debug

本番環境にインストールする場合は、ソースから Subversion をインストールする前に、追加のフラグなしで make または configure を再実行して、この操作を取り消すことを忘れないでください。

Subversion が使用するすべての HTTP メソッドは何ですか？¶

Subversion クライアントは、WebDAV/DeltaV プロトコルのサブセットを mod_dav_svn サーバーモジュールに送信します。簡潔な答えは次のとおりです。

     OPTIONS, PROPFIND, GET, REPORT,
     MKACTIVITY, PROPPATCH, PUT, CHECKOUT, MKCOL,
     MOVE, COPY, DELETE, LOCK, UNLOCK, MERGE

このリストは時間の経過とともに増える可能性があることに注意してください。Subversion 1.7+ は、1.7+ サーバーと通信するときにPOSTメソッドの使用を開始し、Subversion 1.9+ が 1.9+ サーバーと通信するときに別のメソッドの使用を開始する可能性があります。

プロトコルの詳細は、こちらに記載されています。

「バイク小屋」とは何ですか？¶

freebsd-hackers への Poul-Henning Kamp の投稿を参照してください：https://docs.freebsd.org/en/books/faq/#bikeshed-painting。

「Subversion」はどのように発音しますか？¶

Subversion に名前とリポジトリ設計の両方を与えた Jim Blandy は、「Subversion」を「Subversion」と発音します。

「バトン」とは何ですか？¶

Subversion のソースコード全体に、「バトン」オブジェクトへの参照が多数あります。これらは単なるvoid *関数にコンテキストを提供するデータ構造です。他の API では、これらはしばしば次のように呼ばれます。void *ctxまたはvoid *userdataSubversion の開発者は、これらの構造体が頻繁に受け渡されるため、「バトン」と呼んでいます。

リポジトリが「固まっている」と言う場合、それはどういう意味ですか？¶

固まっているリポジトリ

Subversion リポジトリは、ワーキングコンパートメントとストレージコンパートメントの 2 つの異なる内部パーツで構成されています。固まっているリポジトリは、ワーキングコンパートメントが何らかの理由でアクセスできないが、ストレージコンパートメントはそのままの状態のリポジトリです。したがって、固まっているリポジトリはデータの損失を被っていませんが、リポジトリにアクセスする前にワーキングコンパートメントを修正する必要があります。その方法の詳細については、こちらのエントリを参照してください。

破損したリポジトリ

破損した Subversion リポジトリとは、ストレージコンパートメントが損傷しており、リポジトリに実際にデータが失われているリポジトリです。

また、The Jargon File の「固まっている」の定義も確認してください。

CVSSv3 とは何ですか。また、スコアとベクターは何を意味しますか？¶

Subversion では、セキュリティアドバイザリーで CVSSv3 を使用しているため、アドバイザリーの「重要度」セクションには CVSSv3 のベーススコアとベクターが表示されます。CVSSv3 は、コンピュータシステムのセキュリティ脆弱性の重大度を評価するための、オープンな業界標準である共通脆弱性評価システムの現在のバージョンです。FIRST は、この標準のドキュメントを管理しています。

スコアは、0 から 10 の範囲の数値であり、リスクの低い脆弱性は低いスコアとなり、リスクの高い脆弱性は高いスコアとなります。スコアは、脆弱性のメトリクスを決定し、それらのメトリクスに基づいてスコアを計算することで算出されます。スコアがどのように決定されたかを理解するには、ベクターと標準で指定されている式の理解が必要です。

ベクターとは、脆弱性に適用されるメトリクスの省略された記述です。

CVSSv3では、基本、時間、環境という3種類のメトリクスとスコアが規定されています。Subversionプロジェクトでは、基本スコアとメトリクスのみを提供します。プロジェクトとして、さまざまなインストールの環境リスクを判断することはできないため、環境メトリクスを計算することはできません。時間メトリクスは、時間の経過とともに変化する可能性のある要因を対象としています。公開後のアドバイザリを更新しないため、これらの変化する値を追跡することはできません。

一部の脆弱性は、エクスプロイトに特定の構成または環境要因を必要とします。CVSSv3では、アクセス複雑性メトリクスで、そのような構成がどれほど一般的かを考慮するように指定しています。その結果、まれな構成を必要とする脆弱性は低いスコアになります。このスコアは、アドバイザリにどれだけ迅速に対応する必要があるかを優先順位付けするのに役立ちますが、アクセス複雑性メトリクスの結果として、脆弱性が自分のインストールにどのように影響するかを考慮する必要があります。

サーバーの脆弱性の可用性への影響メトリクスを計算する際、Subversionプロジェクトはホストシステムではなく、Subversionのコンテキスト内で完全な値を使用します。たとえば、サービス拒否攻撃を検討する場合、脆弱性によって攻撃者がSubversionサーバーを完全にアクセス不能にできる場合、可用性への影響メトリクスは「高」として計算されます。一方、攻撃によってSubversionサーバーが遅くなったり、正常な接続数が制限されたりするだけの場合は、「低」と評価されます。

サーバーの脆弱性の完全性への影響メトリクスを計算する際、Subversionプロジェクトは、Subversionリポジトリの履歴が変更される可能性がある場合、またはホストシステム上のファイルを変更できる場合、「高」の値を使用します。認証または認可の要件に違反して（適切な履歴を保持したまま）ファイルを変更する機能は「低」として扱われます。

サーバーの脆弱性の機密性への影響メトリクスを計算する際、Subversionプロジェクトは、認証または認可の要件に関係なく、リポジトリ内のすべてのファイルを読み取れる場合、「高」の値を使用します。一部のファイルのみが読み取れる場合は、「低」と見なされます。

これらの影響メトリクスの計算方法の結果として、脆弱性データベースまたはベンダーのアドバイザリで異なるスコアのアドバイザリが表示される場合があります。たとえば、Subversionのバイナリパッケージを提供するLinuxディストリビューションでは、システムでホストされているSubversionリポジトリの内容の完全な公開を「低」の機密性への影響としてのみスコア付けし、結果としてスコアが低くなる可能性があります。

目次

前のリビジョンの内容を再びHEADにするにはどうすればよいですか？

• HTTPダイジェスト認証が機能しないのはなぜですか？
• Windows XPでは、Subversionサーバーが破損したデータを送信しているように見えることがあります。これは本当に起こり得ることですか？

BDBに関する質問

• リポジトリが使用しているBerkeley DBのバージョンをどのように判断すればよいですか？
• リポジトリが非常に多くのディスク容量を使用しているのはなぜですか？
• リポジトリが常にスタックし、復旧が必要（DB_RUNRECOVERY）というエラーが発生します。原因は何ですか？
• リポジトリにアクセスしようとするたびに、プロセスがハングします。リポジトリが破損しているのですか？
• リポジトリで「メモリを割り当てることができません」というエラーが頻繁に発生します。どうすればよいですか？
• Apacheを起動すると、mod_dav_svnから「データベースバージョンが間違っています」というエラーが出て、db-4.Xではなくdb-3.Xが見つかったと表示されます。
• Red Hat 9で「関数が実装されていません」というエラーが発生し、何も機能しません。どうすれば修正できますか？
• 「svn: bdb: 呼び出しは、以前の呼び出しと矛盾するアクセス方法を意味します」というエラーが表示されます。どうすれば修正できますか？
• Berkeley DB 4.3以降にアップグレードした後、リポジトリエラーが発生しています。
• 読み取り専用操作でもリポジトリの書き込みアクセスが必要なのはなぜですか？

トラブルシューティング（廃止）：¶

BDBに関する質問：¶

$ svnadmin list-unused-dblogs /repos
/repos/db/log.000003
/repos/db/log.000004
[...]

$ svnadmin list-unused-dblogs /repos | xargs rm
# disk space reclaimed!

$ db_archive -a -h /repos/db | xargs rm
# disk space reclaimed!

   svnadmin recover /path/to/repos

  Repository lock acquired.
  Please wait; recovering the repository may take some time...
  svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
  svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass
  svnadmin: bdb: PANIC: No such file or directory
  svnadmin: bdb: PANIC: fatal region error detected; run recovery

  Repository lock acquired.
  Please wait; recovering the repository may take some time...
  svn: DB_RUNRECOVERY: Fatal error, run database recovery
  svn: bdb: DB_ENV->log_flush: LSN of 115/802071 past current end-of-log
  of 115/731460
  svn: bdb: Database environment corrupt; the wrong log files may have
  been removed or incompatible database files imported from another
  environment
  [...]
  svn: bdb: changes: unable to flush page: 0
  svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument
  svn: bdb: PANIC: Invalid argument
  svn: bdb: PANIC: fatal region error detected; run recovery
  svn: bdb: PANIC: fatal region error detected; run recovery
  [...]

   db_recover -c -v -h /path/to/repos/db