多数のリポジトリを持つSVNサーバーを新しいサーバーに移行する必要があります。古いサーバーは、問題のある古いOSに基づいて構築されたため、再構築することにしました。
私はSVNの使用の基本だけを知っており、ダンプ/ロードパスに行く必要があるのか、svnsyncを使用して新しいサーバーに移行できるのかわかりません。
私は「読み取り専用」ミラーリングのためにsvnsyncへの参照を探していました。これは私が望むものではありません。既存のSVN Server Aのすべてのデータを新しく作成されたSVN Server Bに移行しようとしています。
完了すると、サーバーAは消え、すべてのSVNユーザーはサーバーBを使用します。
これまで、新しいSVNサーバーと（空の）リポジトリを作成しました。
ベストアンサー1
同じ問題を抱えている他の人に投稿してください。問題は、svnsync がミラーリングにのみ使用できるのか、マイグレーションにのみ使用できるのかという要約です。
Google グループに Dave Anderson が参加した内容を引用するには:
これは移行を実行するために使用でき、Google Code で移行を実行する唯一の方法です。 Subversion ブックの警告は次のように読んでください。 「読み取り専用ミラーが必要な場合は、手動で何もコミットしないでください。そうしないと、svnsyncはデフォルトのストレージから同期できなくなります。」
しかし、内部的にsvnsyncは単純なプログラムです。あるサーバーでリビジョンストリームを要求し、そのリビジョンを別のサーバーで再生します。ターゲットサーバーが分岐しない限り（つまり、ソースにないコミットがない限り）、svnsyncを徐々に実行して同期を維持できます。ただし、一度だけ実行して両方のストレージを同期し、元のストレージを削除して同期コピーの使用を開始することもできます。
ダンプ/ロードとsvnsyncの違いは、svnsyncは完全にパブリックサーバーAPIを介して機能し、ダンプ/ロードはリポジトリファイルで直接機能することです。両方のメカニズムは同じデータを提供しますが、svnsyncを実装するだけでははるかに簡単です。ダンプ/ロードを実装するには追加の開発時間とリソースが必要ですが、特に利点はありません。歴史的に、ダンプ/ロードは最初は実装が簡単でしたが、時間の経過とともに増分ダンプ/ロードを実行する一般的な方法の必要性が明らかになり、svnsyncが登場しました。
したがって、結論はそうです。 svnsyncを使用してください。ドキュメントに従って、Google コードを「読み取り専用ミラー」と考えてください。同期が完了したら、ローカルストレージを削除（またはアーカイブおよびバックアップ）し、通常どおりGoogleコードストアの使用を開始してください。
これが役に立つことを願っています。 -Dave