SVN: свести к минимуму свалку, необходимую для перемещения проекта в собственное репо

Question

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

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

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.

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

Любые идеи, как продолжить?

---

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

• /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 часов, чтобы сделать это.

Answer 1

Я, наконец, использовал svnrdump. Мне пришлось сбросить все исправления, но это позволило мне указать, что я только хотел/KeyManagement. С svndump и svndumpfilter я должен был бы указать /KeyManagementи/trunk/KeyManagment, так как именно там находился оригинальный проект.

К сожалению, вы не можете использовать svndumpfilter по адресу svnrdump, и поскольку все изменения были зарегистрированы, я не смог перенумеровать их и оставить пустыми.

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