S-JIS[2009-01-27/2011-09-23] 変更履歴
|
trunk/sample/bin/test.txtのリビジョン54のファイルをワーク（作業コピー）へ復活させる例。
まず、URL（リポジトリーのルート）を確認する。
C:\> cd C:\svnwork\sample\bin C:\svnwork\sample\bin> svn info パス: . URL: svn://localhost/sample/trunk/sample/bin リポジトリのルート: svn://localhost/sample 〜
そして、リポジトリーのリビジョン54からカレントディレクトリー（ワーク）へのコピーを実行する。
（実のところ、昔あった場所とは違う場所へもコピー可能）
C:\svnwork\sample\bin> svn copy svn://localhost/sample/trunk/sample/bin/test.txt@54 . A test.txt ←ワークに追加される
この後、コミット（svn commit）する。
なお、（コミット前でも、）svn logによって履歴を確認できる。（復活させたファイルのそれまでの変更履歴が残っており、引き続き使えるということ）
svn copyによらず同名の新規ファイルを作って内容だけコピーしてきたような場合は、そこから新規ファイル扱いとなって、過去の履歴は引き継がれない。
コピー元とコピー先にURLを指定すれば、ワークディレクトリー（作業コピー）を経由しなくても直接リポジトリー上に復活させることが出来る。
この場合、コピー時点でコミットされる為、コミットコメントの指定も必須。
> svn copy svn://localhost/sample/trunk/sample/bin/test.txt@54 svn://localhost/sample/trunk/sample/bin/test.txt -m"復活させて直接コミット"
削除したファイルを復活させたいのだから、そのファイルの在ったパス名・ファイル名は分かっているはず。
あとはリビジョン番号さえ分かればそのリビジョンから復活させることが出来る。
というわけで、削除ファイルの在りし日の最新リビジョンを探してみる。
svnlook historyを使っても、最新版（最新リビジョン）にはそのファイルは存在しないので、履歴を確認することは出来ない。
> svnlook history C:\svn\sample trunk/sample/bin/test.txt
リビジョン パス
-------- ----
svnlook: File not found: revision 68, path 'trunk/sample/bin/test.txt'
適当に古いリビジョン番号を指定すれば見つかるかもしれないが、それが最新であったとは限らない。
（そのリビジョン番号を指定してhistoryを実行しても、それ以前の履歴は表示されるが、それ以降に変更があっても表示されない）
そこで、ファイルを削除した場合はそのディレクトリーに対する変更でもあるので、test.txtの在ったディレクトリーに対して履歴を見てみる。
> svnlook history C:\svn\sample trunk/sample/bin
リビジョン パス
------- ----
68 /trunk/sample/bin
66 /trunk/sample/bin
65 /trunk/sample/bin
64 /trunk/sample/bin
63 /trunk/sample/bin
62 /trunk/sample/bin
55 /trunk/sample/bin
53 /trunk/sample/bin
8 /trunk/sample/bin
そのリビジョンでどういう変更がコミットされたのかは、svnlook
changedで確認することが出来る。
changedにはリビジョンを指定できるので、historyで表示されたリビジョンを最新から順番に一つずつ確認していけばよい。
…とゆーか、一つずつ確認していくしか無さそう(苦笑)
> svnlook changed C:\svn\sample -r 68 U trunk/sample/bin/build.xml > svnlook changed C:\svn\sample -r 66 U trunk/sample/bin/zzz.txt … > svnlook changed C:\svn\sample -r 55 D trunk/sample/bin/test.txt ←Dが付いているので、このリビジョンで削除が実行されたと分かる！
これで削除されたリビジョンが分かったので、その一つ前のリビジョン番号が、ファイルの存在していた最後の（最新状態の）リビジョンであることが分かる。
でもこんなの手作業でやってられっかー！という訳で、この作業を行うバッチを作ってみた。
以下のバッチファイルをパスの通っている場所に置く。
@echo off set REP=%1 set DIR=%2 set FILE=%3 if "%3" == "" ( echo find SVN deleted file. by hishidama 2009-01-27 echo usage: %0 REPOSITORY_PATH DIR FILE [-r REVISION] echo ex: %0 C:\svn\sample trunk/sample/bin test.txt -r 54 exit/b 1 ) for /f "usebackq tokens=1,*" %%i in (`svnlook history %REP% %DIR% %4 %5`) do call :search %%i exit/b 0 :search set REV=0 set/a REV=%1 2> nul if %REV% LEQ 0 exit/b echo REV:%REV% svnlook changed %REP% -r %REV% | findstr %DIR%/%FILE%
> svnhis C:\svn\sample trunk/sample/bin test.txt REV:68 REV:66 REV:65 REV:64 REV:63 REV:62 REV:55 D trunk/sample/bin/test.txt REV:53 A trunk/sample/bin/test.txt REV:8
↑リビジョン53でファイルが追加され、リビジョン55で削除されたと分かる。
最新リビジョンでディレクトリーすら削除されている場合は、以下のようなエラーが出る。
> svnhis C:\svn\sample trunk/sample/dir test.txt svnlook: File not found: revision 68, path 'trunk/sample/dir
だがしかし、ディレクトリーに対してもsvnhis.batは使うことが出来る。
> svnhis C:\svn\sample trunk/sample dir REV:68 REV:67 REV:66 〜 REV:56 D trunk/sample/dir/ REV:54 U trunk/sample/dir/abc.txt U trunk/sample/dir/def.txt REV:52 〜
↑ディレクトリーに含まれるファイルの変更も履歴として出てきてしまうのでログの量は多くなってしまうが、一番上（リビジョン56）が削除であることはほぼ間違いない。
で、ディレクトリーが存在していた頃のリビジョン番号を指定して、改めてファイルの履歴を確認してみる。
> svnhis C:\svn\sample trunk/sample/dir test.txt -r 55 REV:55 REV:54 REV:52 REV:51 A trunk/sample/dir/test.txt REV:49 〜
ファイルに対する削除の履歴が見つからない…つまりこれは、ディレクトリーごと消されたということだろう。
> svnlook tree C:\svn\sample trunk/sample/dir/test.txt -r 55 test.txt ←見つかった > svnlook tree C:\svn\sample trunk/sample/dir/test.txt -r 56 svnlook: File not found: revision 56, path '/trunk/sample/dir/test.txt' ←見つからなかった
旧PCのリポジトリーを新PCのリポジトリー（別バージョンのSVN）に移行する手順。[2011-09-23]
参考： koshianohagiさんのSVNリポジトリの移動(サーバー移行)
SVN1.5.5からSVN1.6.6へ移行してみた。
C:\svn\sampleというリポジトリーがある前提 旧PC> cd C:\svn 旧PC> svnadmin dump sample > sample.dump.txt
↓sample.dump.txtを新PCへ転送
D:\svn\sampleというリポジトリーを作る 新PC> D: 新PC> mkdir svn 新PC> cd svn 新PC> svnadmin create sample 新PC> svnadmin load sample < D:\temp\sample.dump.txt
リポジトリーに含まれる全リビジョンに対して1つずつデータを作成するので、作業が完了するまでけっこう時間がかかる。
それと、リポジトリーの下のconf（ユーザー情報やパスワード）はダンプされないので、別途コピーする必要がある。