Как обновить дамп SVN

Question

Я использую reposurgon, который читает svn dump, созданный просто:

svnadmin dump /svnroot/my-repo > svn_dump

Однако мне нужно обновить этот файл, потому что мы по-прежнему фиксируем хранилище, и каждый раз воссоздание всего файла занимает довольно много времени (его почти 60 гигабайт).

Итак, мой вопрос:

Есть ли способ добавить этот файл каждый раз, чтобы избежать полного повторного создания дампа?

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

---

Обновить

Мне удалось сделать это с помощью инкрементных дампов, но первые 4 строки каждого файла после первого нужно удалить.

svnadmin dump -r0 /svnroot/my-repo --incremental                   > svn_dump
svnadmin dump -r1 /svnroot/my-repo --incremental | sed -n '5,$ p' >> svn_dump
svnadmin dump -r2 /svnroot/my-repo --incremental | sed -n '5,$ p' >> svn_dump
svnadmin dump -r3 /svnroot/my-repo --incremental | sed -n '5,$ p' >> svn_dump
svnadmin dump -r4 /svnroot/my-repo --incremental | sed -n '5,$ p' >> svn_dump

# is the same as:
svnadmin dump -r0:4 /svnroot/my-repo                               > svn_dump

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

Answer 1

В Apache Subversion 1.8 добавлена ​​поддержка добавочного svnadmin hotcopy резервные копии. До версии 1.8, svnadmin hotcopy смог создать только полную резервную копию, отказавшись копировать поверх существующего хранилища с горячей копией.

Основное преимущество использования svnadmin hotcopy вместо svnadmin dump / load его производительность ограничена только скоростью дискового ввода-вывода.

Answer 2

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

Во всяком случае, есть возможность incremental свалка. Из руководства SVN:

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

Второй полезный параметр - --deltas. Эта опция заставляет svnadmin dump вместо полнотекстовых представлений содержимого файлов и списков свойств генерировать только дельты этих элементов относительно их предыдущих версий. Это значительно уменьшает (в некоторых случаях) размер файла дампа, который создает дамп svnadmin. Однако использование этой опции имеет недостатки: файлы с разделенными дампами создаются с большей интенсивностью использования ЦП, не могут обрабатываться svndumpfilter и, как правило, не сжимают так же, как их неделитированные аналоги, при использовании сторонних инструментов, таких как gzip и bzip2.

Вы можете иметь скрипт, который использует эту функциональность, как:

$ svnadmin dump /var/svn/repos -r 21 --incremental > incr.dump
* Dumped revision 21.

Вы также можете использовать другую полезную вещь - deltas! Например, вы можете иметь еженедельник full резервное копирование и ежедневное - incremental а также deltas резервное копирование.

Однако, если вы храните большие объемы двоичных данных, имейте в виду, что deltas будет очень неэффективным. В этом виноват способ, которым svn работает изнутри - он просто не предназначен для хранения бинарных файлов.

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