Как я могу объединить серию частичных дампов svn в один репозиторий?

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

Из-за какой-то проблемы, которую нам еще предстоит выявить, ни svnsync, ни svndump, ни что-либо еще, что я пробовал, не удается при одновременном запуске со всем хранилищем. В какой-то момент во время операции произойдет сбой с сообщением типа «время ожидания соединения истекло» или «невозможно получить доступ к блоку» или аналогичными сообщениями. Нам не удалось найти источник проблемы, это может быть проблема с программным обеспечением на сервере, поврежденный репозиторий или, возможно, просто ненадежное сетевое соединение. Независимо от того, в чем проблема, человек, контролирующий сервер, очень медленно помогает нам решить проблему, поэтому мы пытаемся обойти ее, если сможем.

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

svnrdump dump -r0:499 https://server/svn/respository > 0-499.dump
svnrdump dump -r500:999 https://server/svn/respository > 500-999.dump
svnrdump dump -r1000:1499 https://server/svn/respository > 1000-1499.dump

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

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

Я пытался сделать это с пустым локальным репозиторием:

svnadmin load repository < 0-499.dump
svnadmin load repository < 500-999.dump

Первая команда работает, а вторая не работает. Сообщение об ошибке предполагает, что он пытается добавить файл, который уже существует, и сдается. Я обнаружил, что могу сделать это вместо этого:

svn mkdir batch1
svnadmin load --parent-dir "batch1" repository < 0-499.dump
svn mkdir batch2
svnadmin load --parent-dir "batch2" repository < 500-999.dump

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

Я также знаю, что я мог бы использовать --incremental переключатель при создании дампов, но я не уверен, что это хорошая идея, поскольку я подозреваю, что в инкрементных данных могут быть некоторые повреждения (одна из причин, по которой я подозреваю, что это потому, что запуск svnsync или git svn clone в репозитории иногда приводит к ошибкам с несоответствием контрольной суммы)

Могу ли я каким-то образом объединить неинкрементные последовательные дампы, которые у меня есть, в единый новый репозиторий? Если нет, то какой другой метод я должен использовать для этого, учитывая, что svnsync и svnrdump никогда не срабатывали при одновременном запуске со всеми ревизиями?


person Joshua Carmody    schedule 10.11.2013    source источник


Ответы (1)


Вы не указываете, какую версию Subversion вы используете, но до 1.8.3 была проблема с svnsync и использованием http-библиотеки serf. Версии Subversion новее 1.8.0 всегда используют serf для http/https. 1.5.0–1.7.x могут опционально использовать это в зависимости от времени сборки и конфигурации времени выполнения. Сделанное нами изменение отображается в файле CHANGES как:

* svnsync: fix high memory usage when running over ra_serf (r1515249 et al)

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

Это высокое использование памяти часто приводило к очень странным и случайным ошибкам. В некоторых случаях результирующее использование подкачки на машине приводило к тайм-аутам и другим странным ошибкам.

Итак, прежде всего попробуйте обновиться до Subversion 1.8.4 (более новая версия на данный момент) и посмотрите, не сможете ли вы сделать дамп всего репо сейчас.

Теперь вернемся к вашему первоначальному вопросу. Для того, чтобы делать то, что вы должны были делать, вам действительно нужно использовать --incremental для дампов после первого дампа. Ваша проблема с загрузкой полностью связана с отсутствием использования --incremental в этих более поздних дампах. На выходе svnadmin help dump:

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

Поскольку вы не прошли --incremental, эта первая ревизия включает в себя полное дерево, а не только изменения, поэтому возникают конфликты при попытке загрузить его.

Ваши проблемы с ошибками контрольной суммы, которые вы видели с помощью svnsync, не должны отличаться. --incremental только изменяет поведение вывода первой версии в запрошенном вами диапазоне. На самом деле использование --incremental заставляет сервер выполнять меньше работы и с меньшей вероятностью столкнется с проблемами, поскольку предоставление полного дерева может потребовать от него вернуться к ревизиям, которые ему могут не понадобиться.

Вероятно, есть способы исправить отсутствие использования параметра --incremental, но вам, по сути, придется удалить первую версию каждого дампа. Преобразуйте его обратно в добавочный набор изменений, а затем примените его. Возможно, это удастся сделать, загрузив его в репозиторий, а затем экспортировав дерево через wc checkout всего дерева, проверив его, а затем исправив реквизиты редакции (журнал, автор, дата и т. д.) постфактум.

Но все это кажется огромной работой, когда можно просто использовать --incremental.

Что касается ошибок контрольной суммы, которые вы упомянули. Я несколько задаюсь вопросом, не связаны ли они с проблемами zlib, которые мы недавно заметили. Вы не указываете, на какой платформе вы работаете, но версии Subversion для Windows обычно создаются с оптимизированной для сборки версией zlib, которая содержит ошибки. Их не следует использовать, но они есть. Подробности можно найти на странице это сообщение списка рассылки [email protected].

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

person Ben Reser    schedule 11.11.2013
comment
Мой клиент — Tortoise 1.8.3, связанный с Subversion 1.8.4 в 64-разрядной версии Windows 8.1 Professional. Это сервер Linux, но я не знаю, какая версия Subversion на нем запущена. Сервер очень непрозрачен для нас. - person Joshua Carmody; 11.11.2013
comment
Я только что пытался делать инкрементные дампы, но обнаружил, что есть 4 ревизии, которые svnrdump не будет выгружать с включенным параметром --incremental. Он также зависнет и умрет, если дойдет до них в середине партии при выполнении дампа. Однако, если я запускаю неинкрементный дамп с этим номером версии, он работает нормально. - person Joshua Carmody; 11.11.2013
comment
Есть ли шанс, что это общедоступный сервер, которым вы могли бы поделиться? Может быть, есть ошибка. - person Ben Reser; 11.11.2013
comment
Я не боюсь. Сервер находится в ведении ИТ-отдела компании, связанной с той, в которой я работаю. Они должны поддерживать его работу для нас. К сожалению, мы не так важны для них, как некоторые другие их проекты. - person Joshua Carmody; 11.11.2013