Я пытаюсь научиться переносить репозиторий 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
Затем я удаляю импорт неименованных каталогов, один из которых является результатом двух указанных выше seds для каталога группы, а другой - для добавления каталога группы / клиента.
наконец, я попросил автора поменять его на новый. Это тоже было немного сложно, так как требовало обновления длины определения свойства.
Затем я загружаю его и исправляю разрешения файловой системы. Обратите внимание на 2 закомментированных чауна для apache, в некоторых случаях он вам понадобится. В конце концов я добавил apache в группу svn.
У меня никогда не было слияний в моем репозитории SVN, поэтому мне никогда не приходилось иметь дело с ними для разделения. В вашем случае, я бы предположил, что происходит то, что путь исходной ревизии не импортируется, и поэтому он не находит его, хотя ошибка жалуется на саму ревизию). Эмпирическое правило в файле импорта svn состоит в том, что все, что упоминается в какой-то момент, должно быть уже импортировано до того, как на него будет сделана ссылка. Таким образом, вы могли отфильтровать то, что вам не нужно, даже если вы этого хотите, или неправильно обновили файл дампа, чтобы отразить любые другие изменения, которые вы сделали.
Если вы предоставите соответствующую структуру исходного репо, включая объединенный исходный путь, а также ваши вызовы с параметрами, я может быть в состоянии рассказать вам, что вы пропустили. Мои деньги находятся у источника слияния.
Я использовал отличный инструмент дезинфицирующее средство. Проблема в том, что структура репозитория Subversion слишком сложна. Когда svndumpfilter имеет ревизию 10, у него нет возможности узнать, будет ли узел, который пользователь хочет отбросить, будет перемещен в позицию, которую он желает сохранить в ревизии 113. Таким образом, он делает единственное, что может - отбрасывает узел. , и на ревизии 113 вылетает, потому что она уже отбросила данные, которые, как оказалось, были бы необходимы.
Свндумпсанитайзер работает по-другому. Он сканирует узлы несколько раз, чтобы определить, какие узлы на самом деле следует оставить. После того, как он определил, какие узлы оставить, он записывает в выходной файл только эти узлы. Наконец, при необходимости, он добавляет фиксацию, которая удаляет все ненужные узлы, которые нужно было сохранить, чтобы не сломать репозиторий.