Проблема рабочего процесса Mercurial to Mercurial to Subversion

Question

Мы мигрируем из Subversion в Mercurial. Чтобы облегчить миграцию, мы создаем промежуточный репозиторий Mercurial, который является клоном нашего репозитория Subversion. Все разработчики начнут переключаться на репозиторий Mercurial, и мы будем периодически выдвигать изменения из промежуточного репозитория Mercurial в существующий репозиторий Subversion. Через некоторое время мы просто устареем хранилище Subversion, и промежуточное хранилище Mercurial станет новой системой записи.

Dev 1 Local --+--> Mercurial --+--> Subversion
Dev 2 Local --+                +
Dev 3 Local --+                +
Dev 4 -------------------------+

Я тестировал это, но продолжаю сталкиваться с проблемой, когда я помещаю изменения из моего локального репозитория в промежуточный репозиторий Mercurial, а затем в наш репозиторий Subversion.

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png

На моем локальном компьютере есть набор изменений, который зафиксирован и готов к отправке в наш промежуточный репозиторий Mercurial. Здесь вы можете увидеть, что это ревизия № 2263 с хешем 625...

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png

Я помещаю только этот набор изменений в удаленный репозиторий.

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png

Пока все выглядит хорошо. Набор изменений был выдвинут.

hg update
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Теперь я переключаюсь на удаленный репозиторий и обновляю рабочий каталог.

hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed

Далее я нажимаю изменения до Subversion, прекрасно работает. На данный момент, изменение находится в репозитории Subversion, и я снова обращаю внимание на моего локального клиента.

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png

Я вытягиваю изменения на мою локальную машину. А? Теперь у меня есть две ревизии. Моя оригинальная ревизия теперь отображается как локальная ветка.

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png

Другая ревизия имеет новый номер ревизии 2264 и новый хэш 10c1...

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png

В любом случае, я обновляю свой локальный репо до новой ревизии.

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png

Я сейчас переключился.

http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png

Итак, я наконец нажимаю "определить и пометить исходящие наборы изменений", и, как вы можете видеть, Mercurial по-прежнему хочет вытолкнуть мои предыдущие наборы изменений, даже если они уже были отправлены.

Понятно, что я делаю что-то не так.

Я также не могу объединить две ревизии. Если я объединю две ревизии на моем локальном компьютере, я получу коммит "слияние". Когда я отправляю эту фиксацию слияния в промежуточный репозиторий Mercurial, я больше не могу выталкивать изменения в наш репозиторий Subversion. Я в конечном итоге со следующей проблемой:

hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

hg push
pushing to svn://...
searching for changes
abort: Sorry, can't find svn parent of a merge revision.

и я должен откатить слияние, чтобы вернуться в рабочее состояние.

Что мне не хватает?

Answer 1

Вы не делаете ничего плохого, на самом деле в вашей ситуации ожидаемое поведение (если несколько смущает нового пользователя Mercurial) является ожидаемым.

hgsubversion действительно хорош для двух вещей:

1. использование Mercurial в качестве клиента для Subversion без обмена изменениями вне svn
2. Преобразование хранилищ Subversion в Mercurial

Вы пытаетесь использовать его в качестве более обобщенного шлюза, что намного сложнее. У Subversion очень жесткий взгляд на мир, и мы должны работать над этим. Дело в том, что хэш ревизии может рассматриваться как окончательный только при использовании hgsubversion после того, как ревизия была извлечена из Subversion. Таким образом, если ваши разработчики когда-либо будут обмениваться наборами изменений между репозиториями Mercurial напрямую, без Subversion в качестве посредника, это произойдет.

Перебазирование происходит автоматически и не является обязательным по очень фундаментальной причине: Subversion выполняет эту перебазировку при нажатии. Если у вас были незаполненные изменения, когда вы нажимали, Subversion сделал эту перебазировку для вас, и в случае успеха (с тупо простым алгоритмом перебазировки) он принимает коммит без указания того, что произошла перебазировка. Мы исправляем две разные модели.

Я бы порекомендовал перенести всех на Mercurial сразу - такой гибридный подход только усложнит использование Mercurial в краткосрочной перспективе сложнее, чем это должно быть, и потенциально может запутать пользователей, впервые знакомых с DVCS.

Answer 2

Во-первых, позвольте мне сказать, как приятно было прочитать такой подробный вопрос и написать.:)

Проблема возникает, когда вы делаете hg push в репо svn с пульта. Вот что выводится из вашего примера:

hg push
pushing to svn://...
searching for changes
[r3834] bmurphy: database namespace
pulled 1 revisions
saving bundle to /srv/hg/repository/.hg/strip-backup/62539f8df3b2-temp
adding branch
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
rebase completed

Я не пользователь hg-subversion, но этот вывод говорит, что в процессе выполнения запрошенного вами push-запроса он извлекает изменения из репозитория svn, находит новую ревизию и затем выполняет rebase вашей ревизии 10c1 после (потомка) вновь вытащенной ревизии. Команда rebase берет истории ветвления и превращает их в линейные истории, но при этом она меняет родителей наборов изменений, которые изменяют их хэши, что похоже на то, что происходит с вами.

Опять же, не пользователь hg-subversion, поэтому я не могу сказать, всегда ли должно происходить это pull / rebase и как это должно работать, но вики-страница hgsubversion говорит:

Вы можете использовать обычные команды Mercurial для работы с этим хранилищем. Если у вас есть серия коммитов в данной ветке, и вы хотите переместить их в конец этой ветки, используйте команду hg rebase --svn, находясь на кончике вашей работы, и эти наборы изменений будут автоматически перебазированы поверх новая добывающая работа.

который заставляет это звучать не обычно автоматический.

Я не совсем понял из вашего вступления, новые наборы изменений все еще создаются в SVN или они создаются только в Mercurial?

Если они создаются только в Mercurial, то одним из обходных путей будет создание репозитория svn-gateway в удаленной системе, выполнение оттуда и никогда не возвращаться из этого репо в Mercurial. Тогда наборы изменений в этом репо будут иметь разные хеш-коды из-за перебазирования, но они не будут возвращаться в основное удаленное репо и в системы конечных пользователей.

Тем не менее, нужно решить, почему "hg push svn://.. перебирает все исходящие наборы изменений". Ответь, что один, и поведение остановится.

Answer 3

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

Наша цель - внести чистый вклад в проект, который использует Subversion.

• Создайте ветку Subversion для всех ваших изменений. Получите это в Mercurial.
  $ cd [svn-checkout] ; svn cp trunk branches/hg-bridge
  $ cd [hgsubversion bridge] ; hg pull ; hg update hg-bridge

• Проверьте локальное репо на наличие новых изменений
  $ hg in [repo] # shows <rev> IDs you can use later

• Вытащите изменения, которые вы хотите получить в SVN из локального репо
  $ hg pull [repo]

• Привлеките все изменения, которые вы хотите внести:
  $ hg graft [rev] [rev] # rev could be 645 or b7a92bbb0e0b. Best use the second>.
  Вы должны указать каждый оборот индивидуально,
  но вы можете привить несколько оборотов в одной команде.

• Проверьте, что вы бы нажали:
  $ hg outgoing

• Нажмите изменения:
  $ hg push
  Это может показать некоторые несвязанные изменения
  и должны показать ваши новые ревизии как вытащенные,
  вместе с путями к комплектам резервных копий (которые вам не нужны).(комментарий также можно использовать под GPLv2 или новее)