Связывание существующего репозитория Git с существующим удаленным SVN без общей истории

Недавно я унаследовал проект и хотел бы очистить рабочий процесс «доставки кода», связав наш внутренний репозиторий Git с репозиторием SVN клиента.

Обзор репозитория

Моя компания разработала программный комплекс для клиента. Мы отслеживаем наши изменения, используя репозиторий Git. Совершенно отдельно мы предоставляем случайные пакеты кода и выпускаемые двоичные файлы в репозиторий SVN клиента. Файловая структура репозитория SVN клиента является своего рода подмножеством нашей собственной файловой структуры — она содержит некоторые файлы и папки, но не все.

Желаемый рабочий процесс

В конечном счете, я думаю, что хотел бы создать ветку в нашем репозитории git под названием «ClientSVNDelivery». Эта ветвь должна отражать состояние репозитория SVN клиента. Всякий раз, когда мы хотим доставлять обновления клиенту, я хотел бы git merge переносить наши изменения в эту ветку (из «мастера»), а затем git-svn dcommit эти изменения до их удаленного сайта.

Проблема

Проблема, с которой я столкнулся, с точки зрения логистики, является отправной точкой. Поскольку оба репозитория имеют длинную полностью не связанную историю, а структура папок не идентична (опять же, проект SVN является подмножеством папок в нашем внутреннем репозитории git), я не уверен, как создайте ассоциации, необходимые для настройки моей промежуточной ветки «ClientSVNDelivery» (а именно, как сформировать общего предка, который позволит слиянию действительно работать). Честно говоря, у меня даже возникают проблемы с описанием того, что я хочу сделать!

Буду ли я создавать ветку нашей последней внутренней ревизии? Какая-то произвольная более ранняя версия? Или вместо этого я бы отказался от истории remove-svn?

Вопрос

Кто-нибудь имел дело с таким сценарием раньше? Удалось ли вам упростить процесс и какие шаги вы предприняли для создания промежуточной ветки? Как вы создали исторические ассоциации?


git version-control git-svn staging svn
person BTownTKD    schedule 27.02.2014    source источник
comment
Не знаю быстрого и красивого решения для того, что вы описали, но я думаю, что одним из возможных способов является создание ветки Git из последней ветки SVN - это даст вам возможность доставлять код клиенту с помощью Git. Затем вы можете продолжить работу со своими ветками в Git и cherry-pick изменить только указанные пути к этой ветке ClientSVNDelivery, как описано здесь (вы можете написать хук перед фиксацией, чтобы отменить изменения в путях, которые вам не нужны, в ветке ClientSVNDelivery)   -  person tijs    schedule 27.02.2014
comment
Это отличный вариант. Если нет возможности установить общего предка между двумя ветвями, я думаю, что это вариант, с которым я могу пойти. (Вы должны опубликовать ответ; даже если есть лучший вариант, он обязательно получит мой голос.)   -  person BTownTKD    schedule 27.02.2014

Ответы (2)


arrow_upward
1
arrow_downward

Не знаю быстрого и красивого решения для того, что вы описали, но я думаю, что одним из возможных способов является создание ветки Git из ветки последней SVN - это даст вам возможность доставлять код клиенту с помощью Git. Затем вы можете продолжить работу со своими ветками в Git и cherry-pick изменить только указанные пути к этой ветке «ClientSVNDelivery», как описано здесь (вы можете написать хук pre-commit, чтобы отменить изменения в путях, которые вам не нужны, в ветке "ClientSVNDelivery" )

person tijs    schedule 28.02.2014
comment
На данный момент я принял этот ответ с ворчащим предостережением о том, что может быть настоящей болью в заднице, чтобы выбрать каждый соответствующий коммит, который я хочу отправить на сервер SVN моего клиента. - person BTownTKD; 06.03.2014

arrow_upward
-1
arrow_downward

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

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

person vonbrand    schedule 27.02.2014
comment
Спасибо за вклад, однако я уже упомянул «git svn» в своем вопросе; Я намерен использовать его. Вопрос больше о стратегии создания ассоциаций и «общих предков» между двумя несвязанными историями — одна создана «git svn», а другая является основной, ранее существовавшей историей git. - person BTownTKD; 28.02.2014
comment
Как вы хотите сшить вместе две отдельные истории? В качестве первого шага вам нужно перенести оба в более гибкую систему (git), а затем импортировать один в другой. Я объединил два репозитория, фактически вытащив один из них и исправив слияние, но я заранее убедился, что только несколько файлов являются общими для обоих. Если это действительно то, что вам нужно, вам придется предоставить намного больше деталей. И я сомневаюсь, что кто-то, кто не может подойти поближе, не сможет помочь. - person vonbrand; 28.02.2014