Subversionリポジトリデータベースに変更を加える必要がありました。ダンプを作成し、リビジョンを除外して、新しいデータベースを作成しました。
もちろん、この新しいリポジトリは、すでにチェックアウトされている古いリポジトリの作業コピークライアントと多くのコンテンツを共有していますが、その間にリビジョンがありません。
削除されたリビジョンはデータを追加せず、一部のファイルのみを変更しました。
既存のクライアントの作業コピーに大混乱を引き起こすことなく、古いサーバーデータベースを新しいデータベースに簡単に置き換えることは可能ですか？または、代わりにすべてのクライアントに新しいレポの新しいコピーをチェックアウトさせる必要がありますか？
より一般的には、Subversionクライアントはサーバー側の構造の変更にどのように対処しますか？私は主にTortoiseSVNに興味があります。
一度チェックインが破損するという問題があり、リポジトリから削除する必要がありました。作業が完了した後、いくつかのテストチェックインを実行したので、最新のリビジョン番号は、他の開発者がボックスに持っていたものと少なくとも同じでした（大きくはないにしても）。これを行うのに問題はありませんでした。
ダンプでリビジョン番号が変更されておらず、UUIDが保持されている限り、大きな違いはありません。Subversionは、作業コピーファイルのリビジョン番号とリポジトリのUUIDおよびURLを追跡します。履歴が変更された場合でも、作業コピーに影響を与えることはありません。
ただし、理論と事実には常に違いがあります。ダンプとロードを行う前に、事前に開発者に警告します。私は彼らに彼らのコードをチェックインさせます。次に、ダンプとロードを実行してから、開発者にクリーンチェックアウトを実行するように指示します。
安全のために、クリーンチェックアウトを行ってください。svn status古い作業コピーに対してを実行して、変更されたがコミットされていないファイルを見つけ、それらを新しいクリーンチェックアウトにコピーすることができます。はsvn statusリポジトリにpingを送信しないため、安全な操作です。
私の経験から、Tortoise SVNクライアント1.7は.svnディレクトリを着実に増やし、作業コピーの先頭で「クリーンアップ」を実行した場合にのみそれを減らします。
また、TSVNがフィルタリングされたリビジョンのログメッセージ（およびその他の詳細）をすでに確認している場合、ユーザーがこの特定のキャッシュをクリアしない限り（GUIで可能）、引き続きユーザーに表示されます。
個別のリビジョン番号を含むリビジョン全体をフィルタリングした場合（次のリビジョンがフィルタリングされたリビジョンの番号を取得するように）、古い作業コピーを保持しようとはしません。
私はあなたの質問に直接答えるためにクライアントの内部についてもっと知りません。しかし、私は同様の状況にあったので、最初にサーバーをテストすることをお勧めします。
さらに、svnadminロード（またはsvnrdumpロード）は、履歴の欠落（「デルタ」）にすでに遭遇しているはずです。ただし、サーバーが実際に提供する証拠をさらに収集することをお勧めします。
新しいリポジトリから、サーバーとお気に入りのクライアントを注意深く監視しながら、警告がないか...