SVN: минимизировать дамп, необходимый для перемещения проекта в собственное репо.

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

У меня есть крошечный сценарий оболочки, который выглядит так:

svnadmin dump -r108917 ./repo \
    | svndumpfilter include /KeyManagement \
          --drop-empty-revs \
          --skip-missing-merge-sources \ 
          --renumber-revs > km.svndump \

while read rev
do
    svnadmin dump -r$rev --incremental ./repo \
        | svndumpfilter include /KeyManagement \
             --drop-empty-revs \
             --skip-missing-merge-sources \
             --renumber-revs >> km.svndump
done << km.revs.txt

km.revs.txt — это текстовый файл, который просто содержит ревизии, содержащие изменения в проекте /KeyManagment.

Когда я впервые сделал это, я думал, что фильтрую потом. Однако в самой первой сброшенной ревизии размер km.svndump вырос до более чем 68 гигабайт. Упс. Во второй попытке фильтрую проект через svndumpfilter.

Это работало довольно долго (я nohup делал это и просто проверял время от времени). Когда я закончил, я получил km.svndump, показывающий UUID, первую версию и ошибку недостаточно памяти. Судя по всему, мой скрипт не прошел первую ревизию для сброса.

Есть идеи, как продолжить?

У нас есть репозиторий с специальным проектом, который действительно несовместим с остальной частью репозитория. Весь репозиторий может просматривать любой пользователь из группы LDAP Development. Однако один проект содержит информацию, которую мы хотим, чтобы видели только люди, работающие над этим проектом. (Наш проект KeyManagement). Макет репо выглядит так:

• /trunk - Транк для остальной части репо
• /branches - ветки для остальной части репо
• /tags — Теги для остальной части репозитория
• /KeyManagement - Специальный проект KeyManagement.

Чтобы не допустить посторонних глаз, мы используем файл svn_acces, чтобы указать пользователей, которые могут это видеть. Это вызвало много проблем при обслуживании, и я просто хотел бы сделать KeyManagement отдельным репозиторием с собственной группой доступа LDAP. (У нас уже есть несколько репозиториев с собственной группой LDAP).

Проблема в том, что в нашем репозитории более 175 000 ревизий, и только 124 из этих ревизий связаны с проектом KeyManagement. Сброс всех 175 000 ревизий занимает около 30+ часов. Если бы я мог просто выгрузить нужные мне ревизии, я бы сделал весь дамп за пару часов.

Другая проблема заключается в следующем:

$ svn log -r108917:108918 -v $REPO
------------------------------------------------------------------------
r108917 | svnadmin | 2011-03-23 00:46:04 -0500 (Wed, 23 Mar 2011) | 1 line
Changed paths:
A /KeyManagement

New folder KeyManagement
------------------------------------------------------------------------
r108918 | svnadmin | 2011-03-23 00:47:18 -0500 (Wed, 23 Mar 2011) | 1 line
Changed paths:
A /KeyManagement/trunk (from /trunk/KeyManagement:108917)
D /trunk/KeyManagement

Move the KeyManagement
------------------------------------------------------------------------

Судя по всему, KeyManagement тоже когда-то был под /trunk. Мой предыдущий опыт работы с дампом и загрузкой с использованием svndumpfilter заключался в том, что мне приходилось выгружать и загружать и /KeyManagement, и /trunk/KeyMangement одновременно. Честно говоря, меня не волнует /trunk/KeyManagement, потому что приложение было полностью переделано, и никому нет дела до кода.

Я так понимаю, что первая ревизия дампа - это полная ревизия. Можно ли мне сделать что-то вроде этого:

$ svnadmin dump -r108917:108918 old_repo > dump_file
$ svnadmin dump -r108103 --incremental old_repo >> dump_file #Revision with KeyManagement
$ svnadmin dump -r107429 --incremental old_repo >> dump_file #Revision with KeyManagement
...

$ svnadmin load --parent-dir new_repo < dump_file

И просто дамп тех ревизий, которые связаны с KeyManagement. Меня не интересуют версии под /trunk. С тех пор проект был полностью переработан. Я знаю ревизии, я могу легко написать сценарий оболочки для этого. Ни одна из ревизий, связанных с KeyManagement, не связана с другими проектами.

Я просто не хочу тратить на это 40+ часов.