Как я могу объединить серию частичных дампов 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 никогда не удавалось, когда сталкивались со всеми ревизиями одновременно?

1 ответ

Вы не упоминаете, какую версию Subversion вы используете, но до 1.8.3 была проблема с svnsync и используя библиотеку Serf http. Версии 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, которая может содержать ошибки. Их не следует использовать, но они есть. Вы можете найти подробности в этом списке рассылки users@subversion.apache.org.

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

Другие вопросы по тегам