回答:
基本的には、「マージ後方」に必要-現在および以前のバージョンとの間の差分を適用するには、再びコミットし、その後、現在のバージョン（古いバージョンのように見える作業コピーで終わるようにする）と。たとえば、リビジョン150（現在）からリビジョン140に戻るには、次のようにします。
svn update
svn merge -r 150:140 .
svn commit -m "Rolled back to r140"
Subversion Red Bookには、これに関する良いセクションがあります。
svn merge -r HEAD:140ます。
新しい変更をコミットできるのは、Subversion履歴の先頭のみです。
PCにある適切なコピーで直接何もできないのは、その.svnフォルダーが過去のコードであることをフォルダーが認識しているため、コミットする前に更新が必要だからです。
必要な古いコピーのリビジョン番号を見つけます。
現在のリビジョンを取得するには：
svn info --show-item revision
# or
svn logまたは、プロジェクトの古いバージョンを確認するには、次のコマンドを使用します。
svn update -r <earlier_revision_number>正しいリビジョン番号が見つかるまで。
適切なリビジョン番号を書き留め123ます（以下の例を想定）。
最新のリビジョンに更新：
svn update必要なリビジョンと最新バージョンの間のすべての変更を元に戻します。
svn merge -r HEAD:123 .
svn commit "Reverted to revision 123"（上記のJon Skeetの回答と同じです。）
古いコピーが見つからず、現在PCにあるファイルをコミットしたい場合：
適切なバージョンのコピーを作成します（ただし、.svnフォルダーはありません）。
cd ..
rsync -ai --exclude=.svn project/ project-good/次に、最新バージョンであることを確認します。
cd project
svn update
# or make a fresh checkout
svn checkout <url>作業コピーの上に適切なバージョンをコピーします。
このコマンドは、作業ツリーから適切なコピーにないファイルをコピーして削除しますが、既存の.svnフォルダーには影響しません。
cd ..
rsync -ai --exclude=.svn --delete project-good/ project/rsyncがない場合は使用できますcp -aが、不要なファイルを手動で削除する必要もあります。
あなたは今持っているものをコミットできるはずです。
cd project
svn commit "Reverted to good copy"この行を使うだけ
svn update -r yourOldRevesion
次のコマンドを使用すると、現在のリビジョンを確認できます。
SVN情報
必要な場合は、マージを使用してチェックイン全体を元に戻す標準的な方法が適切に機能します。ただし、場合によっては、1つのファイルを元に戻すだけです。これを行う正当な方法はありませんが、ハッキングがあります。
svnのexportサブコマンドを使用します。
svn export http：// url-to-your-file @ 123 / tmp / filename
（ここで、123はファイルの適切なバージョンのリビジョン番号です。）次に、その1つのファイルを移動またはコピーして、古いファイルを上書きします。変更したファイルをチェックインすれば完了です。
svnですか？
svn cat -r 123 path-in-your-working-copy > path-in-your-working-copy
もう少し古い学校
svn diff -r 150:140 > ../r140.patch
patch -p0 < ../r140.patch
その後、通常
svn diff
svn commit
以前の回答のほとんどはリバースマージを使用しており、それが通常正しい回答です。ただし、そうではない状況が1つあります（ちょうど私に起こりました）。
小さな変更を加えると、誤ってUnixの行末を含むファイルをDOSの行末に変更してコミットしました。これは、行末を変更して再度コミットするか、リバースマージによって簡単に元に戻すことがsvn blameできますが、リストをファイルのすべての行のソースとして編集するという効果があります。（興味深いことに、Windows上のTortoiseSVNはこれによる影響を受けませんsvn blame。コマンドラインのみです。）
によって報告された履歴を維持したい場合svn blameは、次のことを行う必要があると思います。
削除は少し怖いですが、ファイルは常にリポジトリに保存されているので、復元しても大したことではありません。手順を説明するためのコードを次に示します。それxxxが最後の適切なコピーのリビジョン番号であると仮定します。
svn rm svn+ssh://path/to/file
svn copy svn+ssh://path/to/file@xxx svn+ssh://path/to -m"Restore good copy"
svn update
<restore the edits>
svn commit -m"Restore edits"
リポジトリのコピーの場合、宛先はファイル名ではなくディレクトリである必要があることに注意してください。
ジョンスキートの答えは、一言で言えばほとんど解決策ですが、私のような人なら、説明が必要かもしれません。Subversionマニュアルではこれをaと呼んでいます
マニュアルページから。
この形式は「チェリーピック」マージと呼ばれます。「-r N：M」は、リビジョンNとMの間のソースブランチの履歴の違いを指します。
'reverse range'を使用して、変更を元に戻すことができます。たとえば、ソースとターゲットが同じブランチを参照している場合、以前にコミットされたリビジョンを「元に戻す」ことができます。リバースレンジ、N「はN -r：M」でMよりも大きい、または「-c」オプションは、負の数と一緒に使用される：「-c -M」と等価である「-r M：」。このような変更を元に戻すことは、「リバースマージ」の実行とも呼ばれます。
ソースがファイルの場合、差分がそのファイルに適用されます（以前の変更を逆マージするのに役立ちます）。それ以外の場合、ソースがディレクトリの場合、ターゲットのデフォルトは「。」です。
通常の使用では、作業コピーは、ローカルの変更や切り替えられたサブツリーがなく、単一のリビジョンで最新でなければなりません。
例：
svn merge -r 2983:289 path/to/file
これにより、ローカルコピー[2983]（上記の引用によれば、サーバーと同期している必要があります-ユーザーの責任）がサーバーのリビジョン289に置き換えられます。変更はローカルで発生します。つまり、クリーンなチェックアウトがある場合、変更をコミットする前に検査できます。