Отступление назад объединяется на Подвижном

Question

Отступление назад объединяется на Подвижном

77

задан Brant Bobby 23 February 2012 в 22:18

4 ответа

Я думаю, что нашел решение, которое постоянно фиксирует плохое слияние, и которое не требует, чтобы вы вручную проверили любые дифференсы. Хитрость состоит в том, чтобы вернуться в историю и генерировать коммиты, параллельно плохим сливам.

Итак, у нас есть репозиторий с отдельными ветвями в поддержанной версии одного продукта. Как и ситуация, возникающая в вопросе, все изменения сделаны на ветке более ранней версии (т. Е. Исчезаемые в этой версии) должны быть объединены в ветви более поздних версий.

Настолько конкретно, если что-то проверяется на Friend_v8, он должен быть объединен в Friend_v9.

Теперь одна из разработчиков осуществляет следующую ошибку: он объединяет все изменения из Friend_v9 на Friend_v8 (т. Е. Слияние в неправильном направлении). Кроме того, после этого плохо всего он выполняет некоторые дополнительные коммиты, прежде чем заметит его ошибку.

Итак, ситуация, как показано в графическом журнале ниже.

o BRANCH_V8 - 13 - important commit right after the bad merge | o BRANCH_V8 - 12 - wrong merge from BRANCH_V9 |\ | o BRANCH_V8 - 11 - adding comment on BRANCH_V8 (ie. last known good state) | | o | BRANCH_V9 - 10 - last commit on BRANCH_V9 | |

Мы можем решить эту ошибку следующим образом:

Обновите локальный каталог до последнего хорошего состояния Flate_v8: Обновление HG 11

Создайте новый ребенок этого последнего хорошего состояния:

Измените файл $ Editor uefer / file.txt (это необходимо, потому что Mercurial не позволяет пустым коммитарию)

совершить эти изменения HG Commance -M » Исправьте неправильно слияние из Friend_v9 "
Ситуация теперь выглядит следующим образом:
o flather_v8 - 14 - генерируя коммит на Flather_v8, чтобы исправить неправильное объединение из Friend_v9 |. |. o flather_v8 - 13 - Важный коммит сразу после плохого слива |. |. |. o flather_v8 - 12 - неправильно слияние от Flather_v9 | / |. o |. Fratch_v8 - 11 - Добавление комментариев на Friend_v8 |. |. |. o flather_v9 - 10 - последний коммит на Flather_V9

объединить вновь сгенерированную голову с пересмотром, в котором произошло плохое слияние и выбросить все изменения перед совершением. Не просто сливайте две головы, потому что вы потеряете важный коммит, который произошел после слияния!

Слияние: HG Merge 12 (игнорируйте любые конфликты)

Выбросить все изменения: HG Revert -a --no-Backup -r 14

Официальные изменения: HG Commit -M «бросать неправильно слияние от Flather_V9» Сидение теперь выглядит:
o flather_v8 - 15 - бросание неправильно слияния от Flather_V9 | \ |. o flather_v8 - 14 - генерируя коммит на Flather_v8, чтобы исправить неправильное объединение из Friend_v9 |. |. + --- o Flather_v8 - 13 - Важный коммит сразу после плохого слива |. |. o |. Flather_v8 - 12 - неправильно слияние от Friend_v9 | \ |. |. o flather_v8 - 11 - Добавление комментариев на Friend_v8 |. |. o |. Flather_v9 - 10 - последний коммит на Flather_v9 |. |.

Т.е. В Flather_V8 есть две головы: тот, который содержит исправление плохого слияния, а другой, содержащий левый важный коммит на Friend_v8, который произошел сразу после слияния.

Слияние двух головок на Friend_v8:

Слияние: HG Merge

Commit: HG Commit -M «объединены две головы, используемые для возврата от плохих слияний»

Ситуация в конце концов на Flather_V8 теперь исправлена и выглядит как Это:

o BRANCH_V8 - 16 - merged two heads used to revert from bad merge |\ | o BRANCH_V8 - 15 - throwing away wrong merge from BRANCH_V9 | |\ | | o BRANCH_V8 - 14 - generating commit on BRANCH_V8 to rectify wrong merge from BRANCH_V9 | | | o | | BRANCH_V8 - 13 - important commit right after the bad merge |/ / o | BRANCH_V8 - 12 - wrong merge from BRANCH_V9 |\| | o BRANCH_V8 - 11 - adding comment on BRANCH_V8 | | o | BRANCH_V9 - 10 - last commit on BRANCH_V9 | |

Теперь ситуация на Friend_v8 верна. Единственная проблема, оставаясь, что следующее слияние от Flather_V8 на Friend_v9 будет неверным, так как он будет объединяться в «Fix» для плохого слияния, которые мы не хотим на Friend_v9. Хитрость здесь состоит в том, чтобы слиться от Flather_V8 в Friend_v9 в отдельных изменениях:

первая слияние, из Friend_v8 в Friend_v9,Правильные изменения на Flather_V8 от неистового слияния.

Вторая слияние в ошибке слияния и ее исправление, и, без необходимости четкости что-либо, выбросить все изменения

В-третьих, слияние в оставшихся изменениях от Friend_v8.

Подробно:

Переключите рабочий каталог в Friend_v9: HG Update Friend_v9

Слияние в последнем хорошем состоянии Friend_v8 (т. Е. Обязатель, который вы генерируете, чтобы исправить плохое слияние). Это объединение, как любое регулярное объединение, то есть. Конфликты должны быть разрешены как обычно, и ничего не нужно выбросить.

Слияние: HG Merge 14

Commit: HG Commits-M "Слияние в последнем хорошем состоянии Flate_v8" Ситуация сейчас:
@ Flather_v9 - 17 - слияние в последнем хорошем состоянии филиала_v8 | \ |. |. o flather_v8 - 16 - объединили две головы, используемые для возврата от плохих сливок |. |. | \ |. + --- O Flatch_v8 - 15 - выброс неправильный слияние из Friend_v9 |. |. |. |. |. o |. |. Flather_V8 - 14 - генерируя фиксацию на Flather_V8, чтобы исправить неправильное объединение из Friend_v9 |. |. |. |. |. |. o |. Flather_v8 - 13 - важный коммит сразу после плохого слива |. |. | / + --- O Firen_v8 - 12 - неправильно слияние от Flather_v9 |. | / |. o flather_v8 - 11 - Добавление комментариев на Friend_v8 |. |. o |. Flather_v9 - 10 - последний коммит на Flather_v9 |. |.

Слияние в плохом слиянии на Flather_V8 + его исправление и выбросить все изменения:

Слияние: HG Merge 15

Возврат всех изменений: HG Revert -a --no-Backup -r 17

Предоставление слияния: HG Commits-C-M » Плохо слияние от Flather_V8 и его исправления и бросая все это на расстоянии " Текущая ситуация :
@ Flathion_v9 - 18 - слияние в плохом слиянии от Flather_V8 и его исправления и бросая все это | \ |. o flather_v9 - 17 - слияние в последнем хорошем состоянии Flathe_v8 |. | \ + ----- O Flatch_v8 - 16 - объединили две головы, используемые для возврата от плохих сливок |. |. |. |. o --- + | Flather_V8 - 15 - бросание неправильно слияния из Friend_v9 |. |. |. |. |. |. o |. Flather_V8 - 14 - генерируя фиксацию на Flather_V8, чтобы исправить неправильное объединение из Friend_v9 |. |. |. |. + ----- O Flather_v8 - 13 - Важный коммит сразу после плохого слива |. |. |. o --- + Friend_v8 - 12 - неправильно слияние от Flather_v9 | // |. o flather_v8 - 11 - Добавление комментариев на Friend_v8 |. |. o |. Flather_v9 - 10 - последний коммит на Flather_v9 |. |.

Слияние в левых изменениях от Friend_v8:

Слияние: HG Merge Friend_v8

Commit: Commit Commit -M «Объединение изменений из Friend_v8»

В конце концов ситуация выглядит так:

@ BRANCH_V9 - 19 - merging changes from BRANCH_V8 |\ | o BRANCH_V9 - 18 - Merging in bad merge from BRANCH_V8 and its fix and throwing it all away | |\ | | o BRANCH_V9 - 17 - Merging in last good state of BRANCH_V8 | | |\ o | | | BRANCH_V8 - 16 - merged two heads used to revert from bad merge |\| | | | o---+ BRANCH_V8 - 15 - throwing away wrong merge from BRANCH_V9 | | | | | | | o BRANCH_V8 - 14 - generating commit on BRANCH_V8 to rectify wrong merge from BRANCH_V9 | | | | o | | | BRANCH_V8 - 13 - important commit right after the bad merge |/ / / o---+ BRANCH_V8 - 12 - wrong merge from BRANCH_V9 |/ / | o BRANCH_V8 - 11 - adding comment on BRANCH_V8 | | o | BRANCH_V9 - 10 - last commit on BRANCH_V9 | |

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

50

ответ дан 24 November 2019 в 11:02
поделиться

Другие вопросы по тегам:
mercurial merge dvcs branch

Похожие вопросы:

34
Начало работы с Управлением версиями - 22 December 2011 22:39

31
Какую Систему управления версиями Вы использовали бы для 1000 + организация разработчика? Почему? [закрытый] - 16 August 2010 20:17

25
Гольф кода: объединение нескольких отсортированных списков в единственный отсортированный список - 23 May 2017 12:24

21
Что такое польза, нераспределенная, альтернатива подрывной деятельности, которая имеет превосходное ветвление и слияние поддержки? - 16 September 2008 05:10

19
Подвижный для новичков: категорическое практическое руководство - 26 June 2019 01:11

18
Используете ли вы распределенный контроль версий? - 10 April 2009 16:30

score 2 · Answer 1

В повышении можно экспортировать репозиторий в набор diffs, историю редактирования, и затем склеить назад, что Вы хотите - в новый репозиторий, таким образом, никакой риск повреждения. Вероятно, не слишком плохо для Вашего примера, но я не знаю то, на что похожа реальная история.

я сослался на эту страницу при выполнении более простой операции:

http://strongdynamic.blogspot.com/2007/08/expunging-problem-file-from-mercurial.html

score 1 · Answer 2

Таким образом, Вы хотите объединить просто некоторый changesets от B в A? Отступление changesets как Вы делало, действительно плохая идея, как Вы уже перенесли.

необходимо или использовать расширение пересадки или иметь третье ответвление, где Вы вносите общие изменения для слияния и в A и в B.

score 1 · Answer 3

После большого обсуждения с некоторыми услужливыми людьми на #mercurial на freenode mpm обеспечил неравнодушный решение, которое, кажется, работает на мой тестовый сценарий (я генерировал поддельный репозиторий, пытающийся копировать сценарий)

Однако на моем фактическом репозитории, по причинам, которые я не вполне понимаю, это еще менее, чем прекрасно.

Вот схема в настоящее время предлагаемого способа разрешить эту проблему:

[Исходное изображение, потерянное]

теперь меньше из проблемы зафиксировать, но я должен все еще сравнить diffs (т.е.: b46:b11 по сравнению с b46:b8, a43:a10 по сравнению с a43:a9), и рука редактируют, некоторые возвращаются в.

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

Важный

Любой пробующий этот материал должен клонировать их репозиторий и играть с ним как песочница сначала. Как необходимо делать с [1 111] любой процесс слияния, потому что тот путь, если это идет не так, как надо, можно просто вывести его и запуститься снова.

score 50 · Answer 4

Я думаю, что нашел решение, которое постоянно фиксирует плохое слияние, и которое не требует, чтобы вы вручную проверили любые дифференсы. Хитрость состоит в том, чтобы вернуться в историю и генерировать коммиты, параллельно плохим сливам.

Итак, у нас есть репозиторий с отдельными ветвями в поддержанной версии одного продукта. Как и ситуация, возникающая в вопросе, все изменения сделаны на ветке более ранней версии (т. Е. Исчезаемые в этой версии) должны быть объединены в ветви более поздних версий.

Настолько конкретно, если что-то проверяется на Friend_v8, он должен быть объединен в Friend_v9.

Теперь одна из разработчиков осуществляет следующую ошибку: он объединяет все изменения из Friend_v9 на Friend_v8 (т. Е. Слияние в неправильном направлении). Кроме того, после этого плохо всего он выполняет некоторые дополнительные коммиты, прежде чем заметит его ошибку.

Итак, ситуация, как показано в графическом журнале ниже.

o  BRANCH_V8 - 13 - important commit right after the bad merge
|
o    BRANCH_V8 - 12 - wrong merge from BRANCH_V9
|\
| o  BRANCH_V8 - 11 - adding comment on BRANCH_V8 (ie. last known good state)
| |
o |  BRANCH_V9 - 10 - last commit on BRANCH_V9
| |

Мы можем решить эту ошибку следующим образом:

Обновите локальный каталог до последнего хорошего состояния Flate_v8: Обновление HG 11

Создайте новый ребенок этого последнего хорошего состояния:

Измените файл $ Editor uefer / file.txt (это необходимо, потому что Mercurial не позволяет пустым коммитарию)

совершить эти изменения HG Commance -M » Исправьте неправильно слияние из Friend_v9 "
Ситуация теперь выглядит следующим образом:

o flather_v8 - 14 - генерируя коммит на Flather_v8, чтобы исправить неправильное объединение из Friend_v9
 |.
 |.  o flather_v8 - 13 - Важный коммит сразу после плохого слива
 |.  |.
 |.  o flather_v8 - 12 - неправильно слияние от Flather_v9
 | / |.
o |.  Fratch_v8 - 11 - Добавление комментариев на Friend_v8
 |.  |.
 |.  o flather_v9 - 10 - последний коммит на Flather_V9

объединить вновь сгенерированную голову с пересмотром, в котором произошло плохое слияние и выбросить все изменения перед совершением. Не просто сливайте две головы, потому что вы потеряете важный коммит, который произошел после слияния!
1. Слияние: HG Merge 12 (игнорируйте любые конфликты)
2. Выбросить все изменения: HG Revert -a --no-Backup -r 14
3. Официальные изменения: HG Commit -M «бросать неправильно слияние от Flather_V9» Сидение теперь выглядит:
```
o flather_v8 - 15 - бросание неправильно слияния от Flather_V9
 | \
 |.  o flather_v8 - 14 - генерируя коммит на Flather_v8, чтобы исправить неправильное объединение из Friend_v9
 |.  |.
 + --- o Flather_v8 - 13 - Важный коммит сразу после плохого слива
 |.  |.
o |.  Flather_v8 - 12 - неправильно слияние от Friend_v9
 | \ |.
 |.  o flather_v8 - 11 - Добавление комментариев на Friend_v8
 |.  |.
o |.  Flather_v9 - 10 - последний коммит на Flather_v9
 |.  |.
 
```
Т.е. В Flather_V8 есть две головы: тот, который содержит исправление плохого слияния, а другой, содержащий левый важный коммит на Friend_v8, который произошел сразу после слияния.
Слияние двух головок на Friend_v8:
1. Слияние: HG Merge
2. Commit: HG Commit -M «объединены две головы, используемые для возврата от плохих слияний»

Ситуация в конце концов на Flather_V8 теперь исправлена и выглядит как Это:

o    BRANCH_V8 - 16 - merged two heads used to revert from bad merge
|\
| o    BRANCH_V8 - 15 - throwing away wrong merge from BRANCH_V9
| |\
| | o  BRANCH_V8 - 14 - generating commit on BRANCH_V8 to rectify wrong merge from BRANCH_V9
| | |
o | |  BRANCH_V8 - 13 - important commit right after the bad merge
|/ /
o |  BRANCH_V8 - 12 - wrong merge from BRANCH_V9
|\|
| o  BRANCH_V8 - 11 - adding comment on BRANCH_V8
| |
o |  BRANCH_V9 - 10 - last commit on BRANCH_V9
| |

Теперь ситуация на Friend_v8 верна. Единственная проблема, оставаясь, что следующее слияние от Flather_V8 на Friend_v9 будет неверным, так как он будет объединяться в «Fix» для плохого слияния, которые мы не хотим на Friend_v9. Хитрость здесь состоит в том, чтобы слиться от Flather_V8 в Friend_v9 в отдельных изменениях:

первая слияние, из Friend_v8 в Friend_v9,Правильные изменения на Flather_V8 от неистового слияния.
Вторая слияние в ошибке слияния и ее исправление, и, без необходимости четкости что-либо, выбросить все изменения
В-третьих, слияние в оставшихся изменениях от Friend_v8.

Подробно:

Переключите рабочий каталог в Friend_v9: HG Update Friend_v9

Слияние в последнем хорошем состоянии Friend_v8 (т. Е. Обязатель, который вы генерируете, чтобы исправить плохое слияние). Это объединение, как любое регулярное объединение, то есть. Конфликты должны быть разрешены как обычно, и ничего не нужно выбросить.

Слияние: HG Merge 14

Commit: HG Commits-M "Слияние в последнем хорошем состоянии Flate_v8" Ситуация сейчас:

 @ Flather_v9 - 17 - слияние в последнем хорошем состоянии филиала_v8
 | \
 |.  |.  o flather_v8 - 16 - объединили две головы, используемые для возврата от плохих сливок
 |.  |.  | \
 |.  + --- O Flatch_v8 - 15 - выброс неправильный слияние из Friend_v9
 |.  |.  |.  |.
 |.  o |.  |.  Flather_V8 - 14 - генерируя фиксацию на Flather_V8, чтобы исправить неправильное объединение из Friend_v9
 |.  |.  |.  |.
 |.  |.  o |.  Flather_v8 - 13 - важный коммит сразу после плохого слива
 |.  |.  | /
 + --- O Firen_v8 - 12 - неправильно слияние от Flather_v9
 |.  | /
 |.  o flather_v8 - 11 - Добавление комментариев на Friend_v8
 |.  |.
o |.  Flather_v9 - 10 - последний коммит на Flather_v9
 |.  |.

Слияние в плохом слиянии на Flather_V8 + его исправление и выбросить все изменения:

Слияние: HG Merge 15
Возврат всех изменений: HG Revert -a --no-Backup -r 17

Предоставление слияния:

 HG Commits-C-M »  Плохо слияние от Flather_V8 и его исправления и бросая все это на расстоянии "

Текущая ситуация :

 @ Flathion_v9 - 18 - слияние в плохом слиянии от Flather_V8 и его исправления и бросая все это
 | \
 |.  o flather_v9 - 17 - слияние в последнем хорошем состоянии Flathe_v8
 |.  | \
 + ----- O Flatch_v8 - 16 - объединили две головы, используемые для возврата от плохих сливок
 |.  |.  |.  |.
o --- + |  Flather_V8 - 15 - бросание неправильно слияния из Friend_v9
 |.  |.  |.  |.
 |.  |.  o |.  Flather_V8 - 14 - генерируя фиксацию на Flather_V8, чтобы исправить неправильное объединение из Friend_v9
 |.  |.  |.  |.
 + ----- O Flather_v8 - 13 - Важный коммит сразу после плохого слива
 |.  |.  |.
o --- + Friend_v8 - 12 - неправильно слияние от Flather_v9
 | //
 |.  o flather_v8 - 11 - Добавление комментариев на Friend_v8
 |.  |.
o |.  Flather_v9 - 10 - последний коммит на Flather_v9
 |.  |.

Слияние в левых изменениях от Friend_v8:
1. Слияние: HG Merge Friend_v8
2. Commit: Commit Commit -M «Объединение изменений из Friend_v8»

В конце концов ситуация выглядит так:

@    BRANCH_V9 - 19 - merging changes from BRANCH_V8
|\
| o    BRANCH_V9 - 18 - Merging in bad merge from BRANCH_V8 and its fix and throwing it all away
| |\
| | o    BRANCH_V9 - 17 - Merging in last good state of BRANCH_V8
| | |\
o | | |  BRANCH_V8 - 16 - merged two heads used to revert from bad merge
|\| | |
| o---+  BRANCH_V8 - 15 - throwing away wrong merge from BRANCH_V9
| | | |
| | | o  BRANCH_V8 - 14 - generating commit on BRANCH_V8 to rectify wrong merge from BRANCH_V9
| | | |
o | | |  BRANCH_V8 - 13 - important commit right after the bad merge
|/ / /
o---+  BRANCH_V8 - 12 - wrong merge from BRANCH_V9
|/ /
| o  BRANCH_V8 - 11 - adding comment on BRANCH_V8
| |
o |  BRANCH_V9 - 10 - last commit on BRANCH_V9
| |

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