Перенос репозиториев Subversion на серверы

Мы находимся в процессе перемещения серверов, и один из последних элементов перемещается по репозиториям svn.

Есть около 10 концертов различных хранилищ svn. Они были созданы с помощью этой команды: svnadmin create --fs-type fsfs

Сервер A (оригинал) имеет svn 1.4, тогда как сервер B (цель) имеет svn 1.6.

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

Большинство онлайн-руководств говорят только о перемещении 1 репозитория за раз, например, используя svnadmin hotcopy, но мне нужно перемещать около 100 или около того. Правильно ли это?

Ответы

Ответ 1

Subversion FSFS довольно стабильна при выполнении копий и движений даже в разных ОС. В то время как mliebelt правильно делает это с помощью перезагрузки dump, требуется age для перемещения 10 ГБ!

Вот почему я бы рекомендовал следующую процедуру:

  • Скопируйте репозитории через файловую систему на новый сервер.
    например $ scp -r /var/repos/ [email protected]:repos/

  • Сделайте $ svnadmin upgrade для обновления в репозитории для 1.6 (это необязательно, но настоятельно рекомендуется, если вы хотите использовать функции 1.5/1.6, такие как отслеживание слияния, разреженные проверки и т.д.)

  • Сделайте $ svnadmin verify в каждом репозитории, чтобы проверить, что все ревизии в порядке (вы можете сделать это на уже запущенном сервере).

По этой процедуре вам нужно в 10-10 раз меньше времени:

например. для захоронения репозитория обычно требуется приблизительно 1 ГБ в час (в значительной степени в зависимости от скорости HD), файлы дампа намного больше, чем хранилища (в SVN 1.4!) Поэтому вам нужно переместить файл большего размера на новый сервер и сделать там дамп-нагрузку, которая также занимает около 1 часа/ГБ. Сравните это с копией файловой системы, которая обычно ограничена только сетевым соединением (100 Мбит прибл. 10 МБ/с) или HD (около 100 МБ/с), если у вас есть GBit-LAN.

Ответ 2

Прежде всего, я не администратор Subversion, но я много работаю с ними. Поэтому не доверяйте моим словам, проверяйте и другие источники.

Мой опыт за последние 5 лет:

  • Чтобы переместить репозитории Subversion, вы должны использовать инструменты администрирования Subversion dump и load. Они написаны только для этой работы.
  • dump и load дополнительно проверьте, что все в порядке. Используя их, вы получаете дополнительную "страховку", чтобы все двигалось нормально.
  • Мы никогда не переносили более двух основных версий, но перешли от одной основной версии к другой. Вы должны хотя бы проверить, поддерживается ли переход с 1.4.x на 1.6.x. Часто новая версия сервера поддерживает прямую предыдущую версию и поддерживает перенос. Поэтому, возможно, вам нужно выполнить миграцию для каждого репозитория дважды.
  • Вы можете работать с старыми репозиториями, пока они перемещаются, потому что subversion позволяет вам добавлять более поздние версии.
  • Поскольку все может быть выполнено с помощью командной строки, вы можете автоматизировать большинство из них, а администраторы subversion должны только проверять, что все работает хорошо.

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

Ответ 3

Для получения дополнительной информации о svnadmin dump и svnadmin load для svn 1.6 см. здесь. Он предлагает некоторое обсуждение dump и load, а также такие параметры, как --deltas, --incremental и другие.

Также следует предупредить, что если вы выполняете прямое копирование и обновление svnadmin, вы сэкономите время, но состояние хранилища может оказаться не оптимальным. С помощью svnadmin:

svnadmin help upgrade

Использование: обновление svnadmin REPOS_PATH

Обновите репозиторий, расположенный в REPOS_PATH, до последней версии версия схемы.

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