Подвижный к подвижному к проблеме рабочего процесса подверсии
Мы мигрируем от Подверсии до Подвижного. Для упрощения миграции мы создаем промежуточный Подвижный репозиторий, который является клоном нашего репозитория Подверсии. Все разработчики будут, начинают переключаться на Подвижный репозиторий, и мы будем периодически продвигать изменения от промежуточного Подвижного репозитория до существующего репозитория Подверсии. После промежутка времени мы будем просто устаревший, репозиторий Подверсии и промежуточный Подвижный репозиторий станут новой системой записи.
Dev 1 Local --+--> Mercurial --+--> Subversion
Dev 2 Local --+ +
Dev 3 Local --+ +
Dev 4 -------------------------+
Я проверял это, но я продолжаю сталкиваться с проблемой, когда я продвигаю изменения от своего локального репозитория в промежуточный Подвижный репозиторий, и затем в наш репозиторий Подверсии.
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/01.png
На моей локальной машине у меня есть changeset, который фиксируется и готов быть продвинутым в наш промежуточный Подвижный репозиторий. Здесь Вы видите, что это - пересмотр № 2263 с хешем 625...
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/02.png
Я продвигаю только этот changeset в удаленный репозиторий.
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/03.png
До сих пор все выглядит хорошим. changeset был продвинут.
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
Затем, я продвигаю изменение до Подверсии, работает отлично. На данном этапе изменение находится в репозитории Подверсии, и я возвращаю внимание назад к моему локальному клиенту.
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/04.png
Я вытягиваю изменения в своей локальной машине. Ха? Я теперь получил два changesets. Мой исходный changeset появляется как локальное ответвление теперь.
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/05.png
Другой changeset имеет новый пересмотр номер 2264 и новый хеш 10c1...
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/06.png
Так или иначе я обновляю свой локальный repo к новому пересмотру.
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/07.png
Я теперь переключаюсь.
сопроводительный текст http://bmurphy.mediafly.com.s3.amazonaws.com/images/mercurial/08.png
Так, я наконец нажимаю "determine and mark outgoing changesets" и как Вы видите Подвижный, все еще хочет выставить мой предыдущий changesets даже при том, что они были уже продвинуты.
Очевидно, я делаю что-то не так.
Я также не могу объединить эти два изменения. Если я объединяю эти два изменения на своей локальной машине, я заканчиваю с фиксацией "слияния". Когда я выставляю ту фиксацию слияния в промежуточный Подвижный репозиторий, я больше не могу выставлять изменения в нашем репозитории Подверсии. Я заканчиваю со следующей проблемой:
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.
и я должен откатывать слияние для возвращения к рабочему состоянию.
Что я пропускаю?
2 ответа
Вы не делаете ничего плохого, на самом деле в вашей ситуации поведение, которое вы видите, является ожидаемым (если несколько сбивает с толку нового пользователя Mercurial).
hgsubversion действительно хорош для двух вещей:
- использования Mercurial в качестве клиента для Subversion без обмена изменениями вне svn
- Преобразования репозиториев Subversion в Mercurial
Вы пытаетесь использовать его как более обобщенный шлюз, что является гораздо более сложной проблемой. У Subversion очень жесткий взгляд на мир, и мы должны работать с ним. На самом деле хеш ревизии можно рассматривать как окончательный только при использовании hgsubversion после того, как ревизия была извлечена из Subversion. Таким образом, если ваши разработчики когда-либо делятся наборами изменений между репозиториями Mercurial напрямую, без Subversion в качестве посредника, это произойдет.
Перемещение выполняется автоматически и не является обязательным по очень фундаментальной причине: Subversion выполняет это изменение при нажатии. Если у вас были невыполненные изменения, когда вы нажимали, Subversion сделала это за вас, и в случае успеха (с глупо простым алгоритмом перебазирования) она принимает фиксацию без каких-либо указаний на то, что перебазирование произошло. Мы собираем вместе две разные модели.
Я бы порекомендовал всем сразу перейти на Mercurial - такой гибридный подход только сделает использование Mercurial более трудным в краткосрочной перспективе, чем должно быть, и потенциально запутает пользователей, плохо знакомых с DVCS.
Во-первых, позвольте мне сказать, какое удовольствие было прочитать такой подробный вопрос. :)
Проблема возникает, когда вы выполняете 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, находит новую ревизию, а затем выполнение перебазирования вашего набора изменений 10c1 после (потомка) только что вытянутой ревизии. Команда rebase берет истории ветвления и превращает их в линейные истории, но при этом меняет родителей наборов изменений, что изменяет их хэши, что похоже на то, что происходит с вами.
Опять же, я не пользователь hg-subversion, поэтому я не могу сказать, всегда ли должно происходить это извлечение / перебазирование и как это должно работать, но на вики-странице hgsubversion написано:
Вы можете использовать обычные команды Mercurial для работы с этим репозиторием. Если у вас есть серия коммитов в данной ветке и вы хотите переместить их в {{1} }} в конце этой ветки, используйте команду hg rebase --svn, находясь на совете своей работы, и эти ревизии будут автоматически перемещены поверх {{ 1}} новых работ в восходящем направлении.
, что делает звук обычно не автоматическим.
Из вашего вступления я не мог точно сказать, создаются ли новые наборы изменений в svn или они создаются только в меркуриальном режиме?
Если они создаются только в меркуриальном режиме, то одним из способов решения этой проблемы будет установка создайте репозиторий svn-gateway в удаленной системе и выполните push оттуда и никогда не возвращайтесь из этого репо в mercurial. Тогда наборы изменений в этом репо будут иметь разные хеши из-за перебазирования, но они не будут возвращаться в основное удаленное репо и системы конечных пользователей.
Более серьезное исправление состоит в том, чтобы выяснить, почему «hg push svn: // .. сбрасывает все исходящие ревизии». Ответьте на этот вопрос, и поведение прекратится.