Я согласен с Михалом, что 3-уровневое решение аккуратно решит проблемы работы с распределенными git-репликами при наличии паршивого сетевого подключения к обязательному верхнему уровню SVN.
У меня точно есть эта проблема.
Я также согласен с Майклом, что это может очень быстро запутаться, если вы попытаетесь сделать это недисциплинированным образом.
Я еще не реализовал решение, но у меня естьгрубая идея, как будет выглядеть решение.
Основная идея заключается в том, чтобы GIT 1 поддерживал ожидающую ветвь, которая обновляется очень контролируемым образом.Разработчики в GIT 2 и GIT 3 будут основывать свою работу на ожидании (или, что еще лучше, на тегах ожидания, принятых в четко определенные моменты времени)
Пусть:
- trunk будетветвь, отслеживающая ствол SVN - это может быть за N коммитов
pending будет ветвью, используемой для отслеживания изменений, еще не зафиксированных в SVN, так что:
- pending всегда ссылаетсяв коммит слияния
- git rev-list --merges ^ магистраль в ожидании ^ 1 пуста # (нет ожидающих коммитов слияния)
- в ожидании и в ожидании ^ 1 всегда sametree
delta будет коммитом таким, что git rev-list --merges ^ pending delta пуста
- future - это коммит, который зависит от delta, например, git rev-list --merges ^ дельта будущее пусто
Затем, чтобы интегрировать дельту в ожидание:
git checkout -f -B tmp delta
git rebase --onto pending^1 pending tmp
git checkout pending
git merge --ff-only tmp
git merge -s ours delta
git branch -D tmp
Чтобы интегрировать будущее в ожидание:
git checkout -f -b tmp future
git rebase --onto pending^1 pending tmp
git checkout pending
git merge --ff-only tmp
git merge -s ours future
git branch -D tmp
Для интеграции ожидающих в SVN:
# синхронизировать транк с SVN:
git checkout trunk
git svn rebase # should never fail
# *** контрольная точка транка для нееe
# перебазировать в ожидании ^ 1 на транк
git checkout -f -B tmp pending^1
git rebase --onto trunk trunk tmp
git checkout trunk
git merge --ff-only tmp
git svn dcommit # could fail with a race condition
# rollback to *** if this happens
# записать слияние в ожидании
git checkout -f -B tmp trunk
git merge -s ours pending
git checkout pending
git merge --ff-only tmp
git branch -D tmp
git tag INTEGRATED-XXX pending # Every commit reachable from INTEGRATED-XXX
# has been integrated with SVN
Это решение использует только слияние информации (-s наше)коммиты на ожидающей ветке фиксируют тот факт, что коммиты, происходящие из git-land, были объединены в ветку, предназначенную для доставки в svn-land.
Итак, даже если произошла перебазировка для доставки коммитов в SVN, на самом деле это не должно быть проблемой ни для кого в git-land, который основывал работу на таком коммите с момента появления git rev-list^ в ожидании должен только когда-либо показывать неинтегрированные коммиты, а последующие итерации цикла интеграции будут только перебазировать эти коммиты.
Правда, я только проиллюстрировал случай счастливого мира.Я также не проиллюстрировал случай, когда дельта - это не простое линейное отклонение от ожидающего.
Вещи могут стать довольно затруднительными, если в ожидании много недоставленной работы, а перебазирование в SVN не удается и не может быть исправлено,При условии, что вы можете решить проблему, не прерывая ребаз, вы хороши.Если вам придется прервать перебазирование, реконструкция будет грязной.
Я планирую реализовать поддержку некоторых сценариев для этой стратегии и опубликую здесь обновление, чтобы вы знали, как оно происходит.