Изменить точку ветвления SVN

Question

Возможно ли переписать историю репо SVN с ветвями и тегами поддерева из сундука, чтобы все ветви и теги содержали «полные» копии ствола? Если да, то как?

Например:

branches 
    module1-feature1 
    module1-feature2 
    trunk-branch1 
     module1 
     module2 
     module3 
    trunk-branch2 
     module1 
     module2 
    trunk 
    module1 
    module2 
    module3 

В приведенном выше примере module1-feature1 ветвь содержит только код для Module1. Я хочу, чтобы он содержал папку с именем module1, а также модуль folder2 (и модуль folder3, если он существовал при создании ветки). Имя ветки не важно, но содержимое должно быть полной копией соединительной линии в то время, а не только вложенной папкой, из которой была создана ветка. Очевидно, что все изменения на этой ветке будут внутри модуля folder1.

Answer 1

Изменение точки ветвления на самом деле довольно просто, как только вы знаете, как это сделать. Однако для выполнения изменений вам понадобится дамп SVN, а затем загрузить его в новый (или сброс) репозиторий.

Я использовал Ubuntu для этой процедуры, но я не эксперт по Linux, поэтому простите меня за возможные ошибки.

Шаг 1. Получить на стороне сервера доступа к репо SVN

Если у вас нет доступа к серверной стороне репо SVN, вам нужно создать локальную копию репозитория:

svnadmin create repo_name 
cd repo_name 
cp hooks/pre-revprop-change.tmpl hooks/pre-revprop-change 

Редактировать файл pre-revprop-change, чтобы он всегда заканчивал 0 в конце.

chmod a+x hooks/pre-revprop-change 
svnsync initialize file:///path/to/repo http://url.to.repo 
svnsync synchronize file:///path/to/repo 

Шаг 2. Создание файла дампа

svnadmin dump /path/to/repo > repo.dump 

Шаг 3. Изменение дампа (это хорошая идея, чтобы сделать копию первого)

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

Node-path: branches/module1-feature1 
Node-action: add 
... 
Node-copyfrom-path: trunk/module1 

Изменение этой записи в:

Node-path: branches/module1-feature1 
Node-action: add 
... 
Node-copyfrom-path: trunk 

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

Обратите внимание, что если у вас есть записи mergeinfo, вы должны обновить их, чтобы получить правильное слияние ветвей. Например:

mergeinfo 
K 13 
svn:mergeinfo 
V 19 
/trunk/module1:2267 

должно стать:

mergeinfo 
K 13 
svn:mergeinfo 
V 11 
/trunk:2267 

Число после V должно равняться длине следующей строке. Это не так просто сделать с поиском и заменой. Если длина неправильная, дамп нельзя импортировать, и вы получите сообщение об ошибке.

До тех пор, пока у вас есть , в истории SVN-репо не произошли какие-либо ошибки разветвления, это все, что вам нужно.

Однако на практике я обнаружил, что мне пришлось использовать комбинацию из трех разных подходов.

1. Редактирование вручную для нескольких случаев, когда ветвление было выполнено таким образом, чтобы я полностью удалял запись. Я использовал emacs, но важно использовать редактор, которому вы доверяете, чтобы не менять байты, которые вы не коснулись.

2. svndumpfilter для удаления нерелевантных вещей в свалке. Мне нужен svndumpfilter для миграции GIT (если вы делаете несколько репозиториев GIT из одного SVN-репо, вы можете использовать svndumpfilter, чтобы очистить материал, который не имеет отношения к репо вашего созданного в настоящее время). Было также полезно сократить размер свалки и сделать его более понятным. Кроме того, у меня были некоторые временные ветви, о которых меня больше не интересовали, которые также трудно было исправить.

3. Автоматизированный поиск и замена, как описано выше.

Шаг 4. Загрузите файл дампа и проверить на наличие ошибок

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

svnadmin create /path/to/repo 
svnadmin load /path/to/repo < repo.dump 

проверять сообщения, напечатанные при загрузке репо, чтобы убедиться, что верно. Я не нашел хороший способ проверить новое SVN-репо напрямую, но так как я собирался перейти на GIT в любом случае, это не проблема, которую я потратил в любое время, пытаясь решить.

Шаг 5. Преобразовать в GIT (бонус)

Я использовал сценарии миграции SVN Atlassian, чтобы получить файл (авторы https://bitbucket.org/atlassian/svn-migration-scripts/downloads/svn-migration-scripts.jar), который я тогда исправленный.

Git миграция была выполнена с использованием Subgit.