私は最近svnadmin dump / loadを介してSubversionリポジトリを古い1.2.3バージョンから1.6.0に更新しました。古いリポジトリはすべて同じUUIDを使用していました（リポジトリはテンプレートリポジトリをコピーして作成されました）。svnadmin setuuidを介していくつかの新しいリポジトリのUUIDを一意に変更しました。UUIDが異なるため、これらのリポジトリの既存の作業コピーを単に移動することはできません。作業コピーをエクスポートして新しいリポジトリからチェックアウトすることは知っていますが、リポジトリに対してsvnadmin setuuidが行うように、作業コピーのUUIDをインプレースで変更する方法があるかどうか疑問に思っていました。
回答:
Subversion 1.7作業コピー形式以降の新しい回答。sqlite3コマンドラインユーティリティが必要です。
作業コピーのルートディレクトリに.svn/、SQLiteデータベースのある単一のフォルダーができました。以下を使用UUIDして、作業コピーで既知の現在のリポジトリを照会できます。
$ sqlite3 .svn/wc.db 'select uuid from REPOSITORY where id=1'
b6dc3e6c-5320-4549-b231-c153d86d7525
その結果、変更UUIDは次の方法で実行できます。
$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032" where id=1'
もちろん、.svn/wc.db更新クエリを呼び出す前にファイルのバックアップを保持してください。リポジトリエンティティのIDが異なるか、そのテーブルに複数の行がある可能性はほとんどありませんが、予期しない結果が得られるかどうかを確認できます。
SVN 1.6以前のトリックを実行するコマンドは次のとおりです。
find . -type f -name entries -exec sed -i 's/old-uuid/new-uuid/g' {} \;
old-uuidとnew-uuidを実際のIDに置き換えます。
Yves Martinの答えは、SVN 1.8の多くの作業コピーでうまく機能しましたが、機能しない場合がありました。
「where id = 1」なしでYvesのコマンドを実行すると、すべてのケースで機能しました。
$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032"'なぜこれが起こったのかを調査すると、リポジトリが再配置されたときに複数のUUIDが保存されていることがわかりました。
REPOSITORYテーブルへの新しいエントリは、既存のテーブルを更新するのではなく、再配置後に追加され、新しいリポジトリルートとそのUUIDでインクリメントされたIDを格納します。したがって、正常に動作しなかったケースは、過去に既に移動された作業コピーでした。コマンドは動作しているように見えますが、現在使用されているものではなく、初期UUIDのみが変更されました。
次のコマンドを使用して、作業コピーに保存されているルートとUUIDのリストを確認できます。
$ sqlite3 .svn/wc.db 'select id,uuid,root from REPOSITORY'最後に、次のように、Windowsコマンドライン/バッチファイルに異なる引用符のセットを使用する必要があったことに注意します。
> sqlite3.exe .svn\wc.db "update REPOSITORY set uuid='1c0d1ec1-2326-0410-bef5-eb29cddfc032'"svn red-beanブックの「リポジトリUUIDの管理」セクションに、探している答えがあるかもしれません。