загрузка Subversion завершается с ошибкой «нет такой ревизии»

Я пытаюсь научиться переносить репозиторий Subversion и сталкиваюсь с проблемой, которая не имеет смысла для меня. Я использовал svndumpfilterдля разделения подпроекта и удалил некоторые префиксы пути. Несколько сотен коммитов теперь импортируются корректно, но затем я получаю следующую ошибку:

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

ОК, так что я иду в файл дампа , чтобы посмотреть на пересмотров 19190 и 19098. Во- первых, пересмотр 19098 делает существует в файле дампа и был импортирован без проблем. Редакция 19190 - это слияние. В 19190 году, вот информация о последнем файле, которая, кажется, вызывает проблему:

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

Смущает, что ревизия 19100 НЕ существует в этом фильтрованном файле. Но ошибка не относится к 19100, это относится к 19098!

Что мне сделать, чтобы загрузить этот файл?

Благодарность!

Я делал такое разделение много раз. Я думаю, что все зависит от того, как вы используете фильтр и какую обработку вы выполняете в файле дампа впоследствии. Лично мне также пришлось поменять пользователя svn, кроме пути к проекту, и перенумеровать ревизии. Просто чтобы вы могли видеть, что можно сделать, вот соответствующая часть моего сценария.

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

Что происходит там, во-первых, я отфильтровываю то, что мне нужно, я отбрасываю пустые ревизии по понятным причинам и перенумеровываю их. Это дает хорошие упорядоченные изменения. Затем я отбрасываю корневой путь проекта, который в моем случае был в форме группы / клиента, потому что в новом репо это не имеет смысла (вместо этого само репо - это группа / клиент на диске) - это первые 2 sed

Затем я удаляю импорт безымянных каталогов, один из которых был получен из 2 выше seds для dir группы, а затем один для добавления dir группы / клиента.

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

Затем я загружаю его и исправляю разрешения файловой системы. Обратите внимание на 2 прокомментированных чоуна для apache, в некоторых случаях вам это понадобится. В итоге я добавил apache в группу svn.

Теперь у меня никогда не было слияний в моем репозитории SVN, поэтому мне никогда не приходилось сталкиваться с ними во время раскола. В вашем случае я бы предположил, что происходит то, что путь к исходной ревизии не импортируется, и поэтому он не находит его, даже если ошибка касается самой ревизии). Практическое правило в файле импорта svn гласит, что все, на что ссылаются в какой-то момент, должно быть уже импортировано до того, как оно будет передано. Таким образом, вы, возможно, отфильтровали что-то, что не должны делать, даже если вы этого хотите, или неправильно обновили файл дампа, чтобы отразить любые другие сделанные вами изменения.

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

Я использовал отличный инструмент svndumpsanitizer . Проблема в том, что структура хранилища Subversion слишком сложна. Когда svndumpfilter находится в ревизии 10, он не может знать, будет ли узел, который пользователь хочет отбросить, перемещен в положение, которое он хочет сохранить в ревизии 113. Поэтому он делает единственное, что может сделать - он отбрасывает узел , и в ревизии 113 выпадает, потому что он уже отбросил данные, оказывается, что он был бы необходим.

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