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

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

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

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

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

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


svn tortoisesvn revision-history svndumpfilter
person mafu    schedule 20.01.2012    source источник
comment
Зачем вам серверные репозитории и клиентские репозитории? Может быть, вы имеете в виду репозиторий (всегда на стороне сервера) и рабочую копию (всегда на стороне клиента)? Дело в том, что клиентского репозитория не существует. Или, может быть, вы попробуете синхронизировать несколько репозиториев с помощью svnsync?   -  person altern    schedule 20.01.2012
comment
@altern: Да, я имел в виду клиентскую рабочую копию. Простите за путаницу, я редактировал.   -  person mafu    schedule 20.01.2012

Ответы (3)


arrow_upward
1
arrow_downward

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

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

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

person David W.    schedule 20.01.2012

arrow_upward
2
arrow_downward

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

person Pedro    schedule 20.01.2012

arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

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