Svn 1.7 - Как переключить рабочую копию в перемещенное репо, когда рабочая копия имеет несуществующую ревизию

Question

Был svn-проект в svn repo http://svn/repoA/path1/. Назовите это оригинальное репо.

Было скопировано в http://svn/repoA/path2. Позвоните, пожалуйста, новый репо.

Местная рабочая копия на одной из наших машин, извлеченная из исходного репо, была обновлена ​​после этой копии.

Затем оригинальное репо было удалено.

Теперь мы хотим реинтегрировать рабочую копию в новое репо.

svn switch подходит для этого. Запуск внутри базового проекта каталога:

svn switch http://svn/repoA/path2 

Однако switch жалуется, потому что проект имеет номер версии, который не существует в новом репо.

В svn 1.6 я бы изменил номер версии в .svn/entries рекурсивно под базой данных проекта, где он хранится в виде открытого текста.

В svn 1.7 такая информация, по-видимому, хранится непрозрачно (закодирована каким-либо образом) в .svn/wc.db или других новых файлах.

Мой вопрос: как я могу заставить рабочую копию думать, что это существующая ревизия в скопированной истории изменений, чтобы я мог переключить ее в клонированную папку репо и после этого обновить ее?

Answer 1

Вы знаете, что не могли прикоснуться к этим .svn каталогам. Бьюсь об заклад, вы также открываете заднюю часть электронных приборов, хотя есть ярлык, в котором четко указано Внимание: внутри нет деталей, обслуживаемых пользователем. Не открывайте, если требуется внезапная смерть от поражения электрическим током..

Да, я тоже.

Вы все еще можете сделать svn status в старой рабочей директории, чтобы найти измененные файлы, а затем скопировать их в новый рабочий каталог. svn status будет работать, хотя старый репозиторий не существует.

Или вы можете проверить новую рабочую копию в другом каталоге, удалить все старые каталоги .svn из старой рабочей копии, а затем просто скопировать все эти файлы в новый рабочий каталог. Затем вы можете сделать svn status, чтобы узнать, что изменилось, и исправить эти проблемы.

Answer 2

Коммутатор SVN обычно удаляет файлы, которые не существуют в новом репо, и добавлять файлы, которые существуют в новом репо. Однако в вашем случае нет эквивалентной версии для переключения. Таким образом, svn switch действительно не подходит для этой работы.

Загляните в svn import, чтобы восстановить старый «оригинальный» серверный репо из проверочного рабочего репо.

В случае, если вы действительно хотите это сделать, как раньше, имейте в виду, что SVN теперь использует меньше каталогов .svn. Посмотрите на корень вашей проверки для одного каталога .svn.Также имейте в виду, что большая часть информации больше не структурирована с текстовыми файлами, а в двоичных базах SQLLite. Возможно внесение изменений в записи базы данных с помощью клиента базы данных, совместимого с SQLLite; однако, это очень не рекомендуется. Вы рискуете превратить свой рабочий репозиторий в кучу goo, чем со старыми текстовыми файлами.

Если целью было удалить большую историю изменений, но вы хотите, чтобы номер повторного соединения соответствовал, вам необходимо перестроить repo1 таким образом, чтобы в нем отсутствовала нежелательная история, но номера версий совпадают. Для этого

svnadmin dump /path/to/repo2 -r<start>:<end> > svn.dump 
svnadmin create /path/to/repo1 
svnadmin load /path/to/repo1 < svn.dump 

Или в моей поддельной например, число оборотов 8323 является последним битом истории быть, и ток тахометр 9929.

svnadmin dump /path/to/repo2 -r8323:9929 > svn.dump 
svnadmin create /path/to/repo1 
svnadmin load /path/to/repo1 < svn.dump