Шаги, необходимые для того, чтобы клон SVN hgsubversion отодвинул - PullRequest
Новая
       24

Шаги, необходимые для того, чтобы клон SVN hgsubversion отодвинул

7 голосов
/ 17 марта 2011

Я работаю в команде, которая в основном использует SVN, тогда как я предпочитаю использовать Mercurial, когда это возможно. Я настроил hg-клон SVN-репозитория с помощью hgsubversion, и несколько базовых операций «подтягивания» / «фиксация» / «подталкивание», казалось, работали нормально.

Теперь, после 2 недель локальной разработки (в течение которых я несколько раз сливал изменения из внешнего репозитория hg и сливался с изменениями из репозитория SVN), я пытался перейти в репозиторий SVN, но не удалось с этим сообщением:

abort: К сожалению, не удается найти svn-родитель ревизии слияния.

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

Как лучше всего исправить ситуацию, не теряя своих коммитов? (С пошаговыми инструкциями?)

1 Ответ

9 голосов
/ 17 марта 2011

Вы не можете нажать hg merge в хранилище subversion, так как SVN не может их понять. Вам необходимо отменить ваши изменения поверх последнего коммита SVN.

Редактировать Шаги для выравнивания истории:

Предупреждение, будьте готовы к множеству конфликтов слияния

Вам нужно активировать расширение mq и rebase

Первым шагом является создание резервного хранилища, так как оно понадобится вам в качестве ссылки для предстоящих конфликтов слияния (ожидайте многих из них).

Скажем, ваш график выглядит так: 

C1--C2--C3------M1--C5--C6--C7---M2--
  \            / \              /
   \--B1--B2--/   \--B3--B4-B5-/

Тогда второй шаг - перебазировать B1 + B2 поверх C3: hg rebase -b B2 -d C3

-b использует общую базу обеих ветвей в качестве начала перебазирования ветви, поэтому Mercurial обнаруживает, что B1 является первым коммитом отклонения, и использует это, даже когда вы говорите B2 для перебазирования. -d указывает назначение перебазированной ветки.

Если вы столкнетесь с конфликтами слияния, убедитесь, что результат B2 '= M1, иначе вы получите множество конфликтов в следующих ревизиях.

После этого Merge M1 исчез, и ваш график выглядит так: 

C1--C2--C3--B1'--B2'--C5'--C6'--C7'---M2'--
                   \                 /
                    \--B3'--B4'-B5'-/

и теперь вы делаете то же самое для второго слияния: hg rebase -b B3' -d C7', что делает ваш репо похожим на это: 

C1--C2--C3--B1'--B2'--C5'--C6'--C7'--B3''--B4''--B5''

Повторяйте, пока у вас не будет всей линейной истории версий.

После того, как вы сгладили историю, вам нужно изменить порядок ваших коммитов поверх svn коммитов. Скажем, ваш репо теперь выглядит так (S = коммит subversion, C = локальный коммит): 

S1--S2--S3--C1--C2--S4--S5--C3-C4--C5--C6--C7--S6--S7

Теперь вы импортируете все из (включая) C1 в ртутную очередь (hg qimport -rC1:). Для просмотра всех созданных патчей используйте hg qseries.

Затем вы отменяете все патчи (hg qgoto C1.diff [this is the first one in qseries], затем hg qpop). Затем вы удаляете подрывные (hg qdelete S4.diff S5.diff S6.diff S7.diff).

Теперь настало время для повторного получения SVN-коммитов (hg pull »svn-remote«). Затем вы повторно применяете все локальные исправления, один за другим с hg qpush, и исправляете все возникающие конфликты слияния. Когда вы закончите с одним конфликтом, вы можете переместить текущий патч в ртутный коммит с помощью hg qfinish -a и отправить свое текущее состояние с помощью hg push »svn-remote«.

...