Как я могу отправить/вытащить отдельный набор изменений между репозиториями в Mercurial?

У меня следующая ситуация:

  • У меня есть сайт А, на котором есть репозиторий Mercurial, и мы уже некоторое время его разрабатываем. Допустим, у A было 5 ревизий.
  • Теперь нам нужно создать сайт B, который почти идентичен сайту A, за исключением, в основном, графического дизайна. Итак, я клонировал репозиторий, запустил сайт B, и теперь в репозитории B есть вся история A, плюс наборы изменений, которые никогда не должны возвращаться к A (в основном CSS и изображения). Скажем, на эти изменения у меня ушло 3 ревизии.
  • Наконец, я внес изменение в B, которое хотел бы вернуть обратно в A, потому что оно принадлежит обоим сайтам. Это ревизия 9 в репозитории B.

Возникает вопрос: как я могу переместить ревизию 9 из репозитория B в репозиторий A, не перемещая при этом ревизии 6-8?

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

Я думал, что одной из прелестей DVCS было то, что я мог легко делать такие вещи (что в «централизованном» мире VCS я мог легко исправить с помощью ветвей и слияний, я много делал это с Vault, и это довольно легко) .

Я что-то упустил здесь?

ПРИМЕЧАНИЕ. Я изучил «MQ», но это похоже на большую банку червей, и похоже, что это повлияет на обычный цикл фиксации только потому, что он включен. Это правильно?

Любая помощь или указатели будут очень признательны. Спасибо!

Даниэль


person Daniel Magliola    schedule 11.09.2010    source источник


Ответы (3)


https://www.mercurial-scm.org/wiki/wiki/TransplantExtension

См. раздел «Использование трансплантата для выбора набора изменений»:

Transplant может управлять несколькими наборами изменений или диапазонами наборов изменений следующим образом:

hg transplant REV1:REV2 REV3

В этом примере будет выбран диапазон наборов изменений, указанный параметром REV1:REV2, и дополнительный набор изменений REV3 после ревизии рабочего каталога.

В идеале вы бы сделали это с ветками?

person supakeen    schedule 11.09.2010
comment
Ветви: Хмммм, не совсем уверен. У меня не было большого успеха в понимании Mercurial Branches :-) Это 2 разных сайта, которые на моем HD у меня есть в 2 разных папках... Я знаю, как это сделать с ветками в Vault, но как мне это сделать в ртутного столба? Когда я пытался сделать какое-то ветвление, у меня в основном была ОДНА рабочая папка, и я мог изменить (обновить), какая из ветвей там показывалась... - person Daniel Magliola; 11.09.2010
comment
Я предлагал иметь две ветки в каждой из этих папок (всего три). Один с общими фиксациями и один с фиксациями, которые никогда не попадут в другое репо. Вы объединяете общую ветку с конкретными ветками, когда вам это нужно :-) Для объяснения веток Mercurial: mercurial.selenic.com/wiki/Branch#Creating_a_Branch, если у вас есть дополнительные вопросы, задавайте :-) - person supakeen; 11.09.2010
comment
А, интересно. Я буду экспериментировать с этим. Спасибо за идею! - person Daniel Magliola; 11.09.2010
comment
Также см. отличное объяснение ветвления Hg Стива Лоша по адресу stevelosh. com/blog/2009/08/a-guide-to-branching-in-mercurial - person Yawar; 13.09.2010
comment
Наличие отдельных веток для ваших изменений графики и ваших общих коммитов означает, что ни один набор наборов изменений не имеет другого в качестве предка, и поэтому позволяет их отправлять/извлекать независимо друг от друга. - person anton.burger; 13.09.2010

Я думаю о командах так:

  • hg bundle дает вам двоичную версию набора изменений, а hg unbundle превращает пакет в точно такой же набор изменений на принимающей стороне.

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

  • hg export дает вам текстовое представление набора изменений, и если вы не используете флаг командной строки --exact для hg import, то применение этого исправления не создаст точно такой же набор изменений на принимающей стороне.

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

  • hg transplant — это просто тонкая оболочка вокруг hg export и hg import.

person Martin Geisler    schedule 12.09.2010

Если вы когда-нибудь захотите «свернуть» или пропустить историю в репозитории mercurial, вы просто обновитесь до базовой версии (перед разделом, который хотите свернуть). Если вы хотите сложить все, что выше этого, в один набор изменений (похоже, это то, что вам нужно), вы просто вернетесь к голове этой ветки и зафиксируете это (или зафиксируете только те файлы, которые хотите) . Это создаст новый набор изменений с тем, что вы хотите, чтобы вы могли отправить его на свой сайт A. То, что вам не нужно, вы просто игнорируете (или удаляете, если не можете игнорировать).

Если у вас есть несколько наборов изменений в верхней части страницы, которые вы хотите сохранить, вам следует перебазировать. Включите расширение rebase и перебазируйте #9 на #5. Если есть дети #9, они будут перемещены вместе с ним. Rebase предпочтительнее трансплантации (которая делает то же самое), потому что rebase использует механизм трехстороннего слияния для переноса наборов изменений, что повышает вероятность успеха. Трансплантация — это более или менее просто тупой экспорт-импорт, поэтому он игнорирует общую историю.

person bryancole    schedule 10.04.2011