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

Question

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

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

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

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

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

Answer 1

Вы не можете нажать hg merges в хранилище 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«,