最近、Subversionリポジトリを古い1.2.3バージョンから1.6.0にsvnadmin dump/loadで更新しました。古いリポジトリはすべて同じUUIDを使用していました(リポジトリはテンプレートリポジトリをコピーして作成されました)。 svnadmin setuuidを介して、いくつかの新しいリポジトリのUUIDを一意になるように変更しました。 UUIDが異なるため、これらのリポジトリの既存の作業用コピーを再配置することはできません。作業コピーのエクスポートと新しいリポジトリからのチェックアウトについては知っていますが、svnadmin setuuidのように、作業コピーのUUIDをインプレースで変更する方法があるかどうか疑問に思いました。リポジトリ。
プルしたリポジトリ内のすべての「エントリ」ファイルを編集する必要があります。リポジトリに多数のディレクトリがある場合、find + sedスクリプトを使用するとタスクが短時間で完了します。
Subversion 1.7作業コピー形式以降の新しい回答。 sqlite3
コマンドラインユーティリティが必要です。
作業コピーのルートディレクトリには、SQLiteデータベースを含む単一の.svn/
フォルダーがあります。作業コピーで知られている現在のリポジトリ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を使用した多数の作業コピーでうまく機能しましたが、機能しない場合がありました。
「whereid = 1」なしでYvesのコマンドを実行すると、すべての場合に機能しました。
$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032"'
これが発生した理由を調査したところ、リポジトリを再配置するときに複数のUUIDが保存されていることがわかりました。これは、これが発生するべきではないというYvesの直観に反しています。
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 bookの「 Managing Repository UUIDs 」セクションには、探している答えがあるかもしれません。