Как клиенты Subversion справляются с историческими изменениями в хранилище?

Question

Мне пришлось внести изменения в базу данных хранилища Subversion.Я создал дамп, отфильтровал ревизию и создал новую базу данных.

Этот новый репозиторий, конечно, делится большим количеством контента с рабочими копиями клиентов старого репозитория, уже извлеченными, однако в нем отсутствуетrevision inbetween.

Удаленная ревизия не добавила никаких данных, она только изменила некоторые файлы.

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

В целом, как клиенты Subversion справляются с изменением структуры на стороне сервера?Меня в первую очередь интересует TortoiseSVN.

Answer 1

Однажды у нас была проблема с поврежденной регистрацией, которая потребовала, чтобы я удалил ее из репозитория.После того, как работа была завершена, я провел несколько тестовых проверок, поэтому номер последней ревизии был, по крайней мере, таким же (если не больше), чем у других разработчиков на их коробке.У нас не было проблем с этим.

Answer 2

Пока номера ревизий не были изменены в дампе и UUID сохранен, это не должно иметь большого значения.Subversion отслеживает номер редакции файлов рабочей копии, а также UUID и URL-адрес хранилища.Даже если история была изменена, она не должна влиять на рабочие копии.

ОДНАКО , всегда есть разница между теорией и фактом.Прежде чем делать дамп и загрузку, я заранее предупрежу разработчиков.Я их проверяю в своем коде.Затем я делаю дамп и загружаю, а затем говорю разработчикам сделать чистую проверку.

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

Answer 3

Исходя из моего опыта, клиент Tortoise SVN 1.7 постоянно увеличивает свой каталог .svn и уменьшает его только при запуске «очистки» поверх рабочей копии.

Кроме того, если TSVN уже видел сообщение журнала (и другие подробности) отфильтрованной ревизии, он продолжит показывать его пользователю, пока он не очистит этот конкретный кеш (что возможно с GUI).

Я бы не пытался сохранить старые рабочие копии, если вы отфильтровали целую ревизию, включая ее отдельный номер ревизии (чтобы следующая ревизия теперь получала отфильтрованный номер ревизии).

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

• запустить «svnadmin verify» в новом (отфильтрованном) хранилище

Еще больше ваша загрузка svnadmin (или загрузка svnrdump ) уже должна была наткнуться на пропущенную историю («дельта»). Но я предлагаю собрать больше доказательств того, что сервер действительно доставляет:

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

1. извлекает как минимум файлы, на которые влияет ваша фильтрация, и - для правильной оценки - каталоги над этими файлами. (Кажется, каталоги не должны содержать другие файлы и подкаталоги.)
2. обновить эту проверку до одной ревизии до отфильтрованной, затем до одной ревизии после отфильтрованной
3. попытаться получить / обновить отфильтрованную ревизию, если она все еще имеет номер ревизии
4. test (2.) не доказывает слишком много, если файлы не изменяются в этих ревизиях, поэтому обновляйте до ревизий по мере необходимости, чтобы переключать все файлы назад и вперед, между их состояниями до и после другой модификации до и после отфильтрованный, если имеется. Чтобы увидеть, если «разрыв» в истории вызывает проблемы.