ローカルファイルを置き換えずに、既存のディレクトリをSVNワーキングコピー（WC）に変換するにはどうすればよいですか？
私は大規模なSubversionリポジトリを持っており、約15GBのデータが約500,000のファイルに分散しています。次に、このリポジトリをリモートホストにチェックアウトする必要があります。これは完了するまでに数日かかります。
私がチェックアウトしているホストには、リポジトリ内のデータの完全なコピーがすでにあります。しかし、ファイルがリポジトリから直接チェックアウトされていないため、それらは作業コピーを構成していません（「.svn」フォルダーはありません）。
特にターゲットホストにすでに存在する場合は、このすべてのデータをネットワーク経由でコピーすることは避けたいと思います。ローカルファイルをリポジトリからの同一のコピーに置き換えることなく、既存のディレクトリを作業コピーに変えるために使用できるトリックはありますか？
SVN 1.7以降（以前はそうではありません）、これは次の方法で簡単に実行できます。
svn co --force http://path/to/repo
これにより、ローカルコピーが既存のものとして尊重され、出力の各ファイル名の前に既存の「E」が表示されます：E some/existing/file
ファイルがリポジトリと異なる（新規または変更された）場合、 本 に従ってそれも適切に処理されます。
バージョン1.7より前では、チェックアウト自体が作成したファイルまたはサブディレクトリを含む既存のディレクトリの上にあるディレクトリをチェックアウトしようとすると、Subversionはデフォルトで文句を言います。 Subversion 1.7はこの状況を異なる方法で処理し、チェックアウトを続行できるようにしますが、妨害しているオブジェクトをツリーの競合としてマークします。 --forceオプションを使用して、このセーフガードをオーバーライドします。 --forceオプションを指定してチェックアウトすると、通常はチェックアウトを妨げる、チェックアウトターゲットツリー内のバージョン管理されていないファイルはバージョン管理されますが、Subversionはその内容をそのまま保持します。それらの内容がそのパスのリポジトリファイル（チェックアウトの一部としてダウンロードされた）と異なる場合、ファイルにはローカルの変更が含まれているように見えます。チェックアウトしたバージョン管理されたファイルをチェックアウト前のバージョン管理されていないファイルに変換するために必要な変更out-チェックアウトが完了したとき。
また、SVN 1.7は、これがより一般的な問題（おそらくソリューションの動機付け）になる状況につながる可能性があることにも注意してください。 subディレクトリをディスク上の新しい場所に移動すると、この問題が発生します。 1.7より前では、それは.svnディレクトリを一緒に移動し、それだけで問題なく独立していました。 1.7では、ディレクトリは事実上バージョン管理されていません。しかし、svn co --forceはその日を救った。
再配置コマンドがあります： http://svnbook.red-bean.com/en/1.1/re27.html
編集：ローカルファイルがリポジトリにリンクされていない場合は、ローカルリポジトリを作成し、そこにファイルをインポートしてから、relocateコマンドを使用できます。
または、両方のマシンに物理的にアクセスできる場合は、リポジトリをローカルでチェックアウトしてから、外部HDを介してファイルをリモートマシンにコピーできます。
ネットワーク上のどこかでsvnの制御下にある作業コピーがすでにある場合は、rsyncを使用してみることができます。
次のコマンドは、すべての.svnディレクトリを削除することです。
chmod -R 0755 project_dir
find /project_dir -type d -name .svn -exec rm -rf '{}' +
すでにチェックアウトバージョンをお持ちの場合は、それらをコピーしてみてください.svnフォルダは、rmをcpに置き換えます。しかし、私は試しませんでした。
svn co --force https://PATH/TO/REPO/ .
最後の.は、作業中のSVNコピーに変換したいディレクトリ内にすでにいることを前提としています。
たとえば、public_htmlディレクトリをリポジトリの作業用svnコピーにしたい場合は、次のようにします。
cd /home/username/public_html; svn co --force https://PATH/TO/REPO/ .
サーバーでチェックアウトを実行し、ローカル（サーバーに対してローカル）で作業コピーを作成してから、その作業コピーを既存のディレクトリ構造を介してリモートシステムにrsyncします。
Subversion 1.7を使用してください。そうすれば、ファイルの元のコピーを持つ.svnがなくなります。
ネイティブのsvnコマンドはいずれも、既存のファイルの一致をチェックサムしてダウンロードしません。
リポジトリにアクセスするためにどのプロトコルを使用していますか？ httpsの場合、それが問題である可能性があります。ネイティブのsvnプロトコル（svnserveを使用）またはsvn + sshを試してください。または、svnリポジトリをホストしているサーバー上のfile：// URLを介してチェックアウトを行い、rsyncを使用してネットワークを介して転送することもできます。
バイトあたりの帯域幅がpayingでない限り、「svn co --force」をNiceまたは（WindowsではSTART/LOW）で実行し、無駄にしないのが理にかなっているかもしれません。自分の時間。チェックアウトプロセス中にローカルファイルシステム上の何も使用できなくなりません。
最後に、チェックアウトが非常に遅い理由がわかりません...ギガビットLAN上のhttps経由で約6分でチェックアウトする500Kのファイルリポジトリがあります。確かに、すべてのファイルははるかに小さいです（合計1GB）。レイテンシーの観点から、サーバーからどのくらい離れていますか？
リポジトリをローカルでチェックアウトしてから、.svnディレクトリのみを転送することができます（注意してください。これらにはワークスペースファイルのコピーが含まれています。明らかに、それらをコピーする必要はありません）。正しい作業コピーの正確なファイルがあるので、これは機能するはずです。
もちろん、.svnファイルを転送するために何らかのスクリプトを作成する必要があります。 Unixシステムでは、findやfriendsを使用してそれを行うことができます。
これらの15GBを宛先に転送せずに解決策があるとは思いません。そこにリポジトリをコピーしてローカルチェックアウトを行う方がおそらく速くて簡単でしょう。
ローカルコンピューターに作業リポジトリがあり、Eclipseがクラッシュしたときにすべての.svnフォルダーが削除されました。
リモートSVNリポジトリに接続できた唯一の方法は、見つけたブログから次の手順に従うことでした（壊れたSubversion作業コピーの回復）：
# Backup your project in case you run into trouble
cp -Rp /path/to/project /temporary/location
# Strip out the old .svn folders (if any)
find /path/to/project -name .svn -print0 | xargs -0 rm -rf
# Check out a clean copy
svn co http://repo/location /temporary/location2
# Move the .svn folders from the clean copy into the correct relative
# place in the broken copy
cd /temporary/location2
find . -name .svn -print0 | xargs -0 -I {} mv '{}' '/path/to/project/{}'
# Remove the clean copy
rm -rf /temporary/location2