Проблема рабочего процесса 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 вашего changeset 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 или новее)