підривне навантаження не вдається з "немає такої ревізії"

Я намагаюся навчитися мігрувати репо в 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 секціями для групи dir, а потім один для додавання dir групи / клієнтів.

нарешті, я сів автора, щоб змінити його на новий. Цей також був дещо складним, оскільки вимагав оновлення довжини визначення властивості.

Потім я завантажую його і виправляю дозволи файлової системи. Зверніть увагу на 2 коментовані чауни для апачу, в деяких випадках вам це знадобиться. Я врешті-решт додав apache до групи svn.

Тепер я ніколи не мав злиття у своїх репортажах SVN, тому мені ніколи не довелося мати справу з ними за розкол. У вашому випадку я б міг уявити, що те, що трапляється, шлях редагування джерела не імпортується, і тому він не знаходить його, хоча помилка скаржиться на саму редакцію). Основне правило у файлі імпорту svn полягає в тому, що все, про що йдеться в одному пункті, повинно бути вже імпортовано до його пересилання. Таким чином, ви, можливо, відфільтрували щось, чого не слід, хоч і цього хочете, або не оновили файл дампа правильно, щоб відобразити будь-які інші зміни, які ви внесли.

Якщо ви надасте відповідну структуру свого оригінального репо-репортажу, включаючи об'єднаний вихідний шлях, а також ваші дзвінки з параметрами, я можу вам повідомити, що ви пропустили. Мої гроші знаходяться на джерелі злиття.

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

Svndumpsanitizer працює по-іншому. Він кілька разів сканує вузли, щоб виявити, які саме вузли насправді потрібно зберігати. Після того, як він визначив, які вузли зберігати, він записує лише ці вузли у поточний файл. Нарешті - якщо потрібно - додається команда, яка видаляє будь-які небажані вузли, які потрібно було зберегти, щоб не зламати сховище.