Во-первых, спасибо Мэтью за ссылки - они помогли мне прийти к моему собственному решению этой проблемы.
Это возможно сделать, но предостережения в том, что это требует некоторой осторожности и, вероятно, имеет ограничения в отношении количества вовлеченных коммиттеров. Мой вариант использования в основном то, что описывает митжак; один пользователь, у которого есть потребность и / или желание использовать два удаленных репозитория, один SVN и другой Git. В моем случае первый работает за брандмауэром, а другой - вне офиса (также частный). Цель состоит в том, чтобы иметь возможность работать с локальной копией репозитория с помощью Git и поддерживать оба удаленных репозитория счастливыми.
Моя процедура:
Это все зависит от того факта, что git svn dcommit изменяет SHA1, связанные с исходными коммитами git. Имея это в виду, после локального коммита я [необязательно git svn rebase затем] git svn dcommit, получая окончательный SHA1. В этот момент я перехожу к своему удаленному репозиторию Git. Если, как утверждает Чакон, все, что вы хотите сделать, - это обеспечить более эффективную точку клонирования с помощью git, то все готово. Но вы также можете захотеть:
- отправка в удаленный репозиторий git из другого локального репозитория «чистого git», за которым следует
- синхронизирует гибридное хранилище git / svn, а затем
- отправка этих изменений в хранилище SVN.
Шаг 1 не представляет проблемы; после фиксации в вашем локальном репозитории "pure git" git push в удаленном репозитории git.
Шаг 2 снова не проблема; обратно в ваш гибридный репозиторий git / svn, git pull изменения из удаленного репозитория git. На этом этапе SHA1, связанные с недавно извлеченными ревизиями, синхронизируются с таковыми в удаленном репозитории git.
Шаг 3, где процесс становится немного сложнее. Вы можете git svn dcommit внести эти изменения, как описано выше, чтобы отправить их в хранилище SVN, но тогда ситуация немного отличается от описанной выше. В этом случае у вас теперь есть одинаковые ревизии в удаленных репозиториях SVN и git, но у них разные SHA1 из-за dcommit. Я справляюсь с этим следующим образом:
Во время извлечения на шаге 2 я отмечаю связанное начало SHA1; например.,
git pull
someone@example.org's password:
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From ssh://example.org/pub/scm/demonstrate
34b6260..17cd887 master -> origin/master
Updating 34b6260..17cd887
Fast forward
file3 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Итак, SHA1 представляет интерес 34b6260. git log origin должен подтвердить, что это последний коммит в удаленном репозитории git, с которым связан git-svn-id. Затем я делаю следующее:
git push -f origin 34b6260:master
выполнение принудительного обновления удаленного репозитория, чтобы исключить коммиты «чистого git», которые я сделал из локального репозитория «чистого git» - используйте с осторожностью! В этом случае я знаю, что у меня есть эти коммиты локально; у них просто разные SHA1 от dcommit. Затем я git push добавлю в удаленный репозиторий «git-svn-id» -версии коммитов, которые я только что удалил, и удаленные репозитории синхронизируются.
Повторная синхронизация локального репозитория "чистый git" с удаленным репозиторием git - это последний шаг, но подобная забота дает удовлетворительные результаты. В этом случае удаленный репозиторий git теперь содержит «git-svn-id» -versions коммитов, в то время как локальный репозиторий «git» по-прежнему содержит оригинальные SHA1. Самый простой способ справиться с этим - это git fetch из удаленного репозитория git, затем git reset --hard origin, чтобы заставить локальный репозиторий git отразить состояние удаленного.