Преобразование svn проектов в git, но разрешить слияние исправлений, сделанных в svn

Question

У меня есть репозиторий svn со многими проектами, но меня интересуют только некоторые (части сервера и полного клиента).

trunk 
    server 
    src 
     src-that-should-be-in-client 
     other-src-that-belongs-to-server 
    cfg 
     cfg-that-should-be-in-client 
     other-cfg-that-belongs-to-server 
    client 
    docs 
    foo 
    bar 

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

Я хочу, чтобы объединить исправления, сделанные в ветвях svn поддержки, в git (и, возможно, наоборот). Хорошо, что это легко, я знаю, как это сделать (я не заинтересован в старых ветвей и тегов):

# create mirror of client 
git svn clone --prefix=svn/ --trunk=trunk/client http://svn-server client 
cd client 
git remote add mirror path_to_remote_mirror 
crontab -e # automatically call git svn rebase and git push mirror 
# repeat for server 

Работа будет осуществляться на вилке удаленного зеркала. Чтобы объединить исправления, сделанные в svn, просто добавьте зеркало как удаленное и продолжите, как описано в другом месте (например, github). Cherry-Picking в другом направлении немного более продвинутый, но возможно.

Но я хочу переместить части сервера на клиент после перехода на git-без потери истории и возможности слияния исправлений.

Один из способов, я думал об изменении команды git svn clone с использованием --trunk=trunk и добавлении --include-paths=(?:server|client). Теперь у меня есть зеркало как сервера, так и клиента в одном репозитории git. Я бы раскошелил его, переместил части, принадлежащие клиенту, удалил папку с сервером и, наконец, переместил все под клиентом в корень (конечно, с промежуточными коммитами).

Другой способ сделать это - создать вилку клиента и subtree merge части сервера.

Я вижу, что одна проблема с первым подходом, который добавляется в файл svn в код сервера, также будет объединена, а файлы, измененные в коде сервера (и удаленные в git), могут привести к конфликтам слияния. Обход проблемы: используйте git merge --no-commit, чтобы проверить сервер-каталог, если он создан во время слияния, если он содержит файлы, принадлежащие клиенту, переместить их, удалить server-dir, commit. Но кроме этого, кажется, достаточно легко сделать не-git-wizzards. Может быть, его можно улучшить, вызвав потом фильтр-фильтр?

Для второго подхода я не уверен, если слияния даже будут работать. По крайней мере, это кажется более продвинутым и, возможно, не выполнимым не-git-wizzards.

Какой подход лучше? Или есть лучший подход?

Answer 1

У меня была эта же проблема раньше. Во-первых, я создал несколько сценариев оболочки Bash, чтобы помочь в миграции:

https://github.com/gburghardt/Git-Extensions

Тогда я был один Git-SVN гибридное хранилище на одной машине. Он выполнял «git svn pull» каждый час или около того через задание cron и толкал эти коммиты в другой репозиторий в ветви с именем «svn_trunk». Никто никогда не совершал или не объединял ничего в svn_trunk, поэтому он состоял исключительно из коммитов от моего гибрида Git-SVN.

Тогда все разработчики, использующие Git и не SVN просто нужно сделать это:

git fetch 
git merge origin/svn_trunk 

Для наших целей, это основной пробой:

Repository (Git-SVN гибрид)

1. каждого час, сделать git svn pull
2. Нажмите на новые фиксации на Repository_B/svn_trunk

Repository B

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

У нас был разветвление схемы:

master 
\ 
-- development 
    | 
    +-- feature_branch_1 
    | 
    +-- feature_branch_2 

Чтобы получить исправление ошибок из SVN, разработчики:

git checkout development 
git fetch 
git merge origin/svn_trunk 
git push origin HEAD 
git checkout feature_branch 
git merge development 

Когда мы первоначально создали "Repository B", я создал мастер от кончика svn_trunk. Затем разработка была создана у кончика мастера.