Я недавно обновил репозитории Subversion со старой версии 1.2.3 до 1.6.0 через svnadmin dump/load. Все старые репозитории использовали один и тот же UUID (репозитории были созданы с использованием копирования репозитория шаблонов). Я изменил UUID на нескольких новых репозиториях через svnadmin setuuid, чтобы они были уникальными. Я не могу просто переместить мои существующие рабочие копии этих репозиториев, потому что UUID разные. Я знаю об экспорте рабочей копии и извлечении из нового репозитория, но мне было интересно, есть ли способ просто изменить UUID рабочей копии на месте, как то, что svnadmin setuuid делает для репозиториев.
13
5 ответов
16
Новый ответ начиная с 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 прежде чем вызывать запрос на обновление. Почти нет шансов, что у вашего объекта хранилища другой идентификатор или в этой таблице несколько строк, но вы можете проверить, если вы получите неожиданные результаты.
8
Вот команда, которая делает трюк для SVN 1.6 и ниже:
find . -type f -name entries -exec sed -i 's/old-uuid/new-uuid/g' {} \;
Замените old-uuid и new-uuid фактическими идентификаторами.
3
Вам необходимо отредактировать все «записи» файлов в вашем репо. Если в репозитории много каталогов, скрипт find + sed быстро справится с задачей.
2
Ответ Ива Мартина отлично сработал для нас на ряде рабочих копий с 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'"1
В разделе « Управление UUID репозитория » в svn red-bean book может быть ответ, который вы ищете.