Возможна ли двунаправленная синхронизация Git <-> Svn (с возможностью записи)? - PullRequest
9 голосов
/ 09 марта 2011

часть нашей команды узнала, что git классный, и начала использовать его в качестве svn-клиента. Таким образом, каждый разработчик имел локальный репозиторий git и синхронизировал его с svn через git-svn.

Тогда мы хотели сделать обзоры кода коммитов и отправить патчи коллегам для просмотра. Этот подход не был интуитивно понятным, поскольку контрольные суммы ревизии SAME в svn отличались для каждого локального репозитория git. Понятия не имею почему, так как содержание должно быть одинаковым. Может быть, это ошибка в svn rebase?

Итак, мы попытались создать центральный git-репозиторий на scm-сервере. Каждый разработчик, который сейчас использует git, может отправить свои изменения в этот центральный репозиторий, а другой разработчик, выполняющий обзор, может включить их в свой репозиторий. К сожалению, потому что каждый разработчик также синхронизировал с svn rebase проблема с контрольной суммой снова.

Прочитав много постов, я думаю, что лучший способ управлять командой с использованием как subversion, так и git-клиентов - это:

  1. Центральный репозиторий Subversion
  2. Центральный репозиторий Git (источник)
  3. Центральная рабочая копия Git на сервере
  4. Для каждого разработчика git локальный репозиторий git
  5. Для каждого разработчика svn обычная рабочая копия

Теперь нам нужна центральная работа для синхронизации svn с git, выполняя обычный скрипт, подобный этому, на центральной рабочей копии git на сервере.

# First transfer the commits from git to svn
git checkout svnmaster
git pull origin svnmaster
git svn dcommit

# Now from svn to git
git svn rebase
git push origin svnmaster

Мои вопросы сейчас:

  1. Это лучший подход (без перехода на git completeley)
  2. Уже есть сценарии для окон, обеспечивающие пуленепробиваемую синхронизацию?
  3. Известна ли проблема с различными контрольными суммами Обходной путь известен?

Спасибо за каждый ответ!

EDIT Недавно я нашел проект, который выглядит очень перспективным:

SubGit

Ответы [ 2 ]

5 голосов
/ 09 марта 2011

Существует проблема с вашим решением.Я рекомендую вам не совершать в svnmaster напрямую.У вас должна быть одна чистая ветка git для svn (svn-dev) и ветка отслеживания svn (svn-master).Выполните следующие шаги для фиксации в svn:

git checkout svn-master
git merge --no-ff svn-dev
git svn dcommit
git checkout svn-dev
git merge svn-master

Эта последовательность позволяет вам сохранить хэши фиксации для всех репозиториев.

2 голосов
/ 09 марта 2011

Вообще то, что вы хотите сделать, не рекомендуется (мягко говоря, реальное утверждение больше похоже на «не»).

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

Прочитайте gitОчень осторожно.Неоднократно говорится, что git-svn! = Git.В частности, git-svn << git.Конечно, это лучше, чем сам SVN, но небезопасно рассматривать его как полный «мерзавец» репозитория SVN, где вы можете делать все, что захотите, и отодвигать его назад. </p>

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...