Як змінити підривну робочу копію UUID?

Я нещодавно оновив сховища Subversion від старої версії 1.2.3 до 1.6.0 через dvna / load svnadmin . Усі старі сховища використовували один і той же UUID (сховища створені за допомогою копіювання сховища шаблонів). Я змінив UUID на декількох нових сховищах через налаштування svnadmin, щоб бути унікальним. Я не можу просто перенести існуючі робочі копії цих сховищ, оскільки UUID відрізняються. Мені відомо про експорт робочої копії та вихід із нового сховища, але мені було цікаво, чи існує спосіб просто змінити UUID робочої копії на місці, як, наприклад, що налаштовує svnadmin для сховищ.

Потрібно відредагувати всі файли "записів" у витягнутому репо. Якщо в репо є багато каталогів, пошук + скрипт sed зробить коротку роботу із завданням.

Нова відповідь з формату робочої копії 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файлу, перш ніж викликати запит на оновлення. Майже немає шансів, що у вашої сутності сховища є інший ідентифікатор або є кілька рядків у цій таблиці, але ви можете перевірити, чи отримаєте ви несподівані результати.

Ось команда, яка виконує фокус для SVN 1.6 та нижче:

find . -type f -name entries -exec sed -i 's/old-uuid/new-uuid/g' {} \;

Замініть old-uuidі new-uuidфактичні ідентифікатори.

Відповідь Іва Мартіна чудово працювала для нас на багатьох робочих примірниках з SVN 1.8, але ми все-таки стикалися з випадками, коли це не працювало.

Запуск команди Іва без "де id = 1" працював у всіх випадках для нас:

$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032"'

Досліджуючи, чому це сталося, я з’ясував, що під час переміщення сховища зберігаються кілька UUID, всупереч інтуїції Іва, що цього ніколи не повинно відбуватися.

Новий запис у таблицю REPOSITORY додається після переміщення, а не оновлення існуючого, зберігаючи інкретований ідентифікатор з новим коренем сховища та його UUID. Тож випадки, які не спрацювали належним чином, були робочими копіями, які вже були переміщені в минулому: Команда, здавалося б, працює, але змінився лише початковий 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'"

У розділі " Управління UUIDs репозиторію " у книзі svn red-bean може бути відповідь, яку ви шукаєте.