Пометить изменения как уже объединенные или преднамеренно проигнорированные с помощью hg pull/push/merge/graft?

Я перехожу на Mercurial из Subversion, где я привык использовать svnmerge.py для отслеживания изменений, которые уже были объединены или которые были заблокированы для объединения:

# Mark change 123 as having already been merged; it will not be merged again, even if a range
# that contains it is subsequently specified.
svnmerge.py merge -M -r123
#
# Block change 326 from being considered for merges.
svnmerge.py merge -X -r326
#
# Show changes that are available for merging from the source branch.
svnmerge.py avail
#
# Do a catchall merge of the remaining changes.  Neither change 123 nor change 326 will be
# considered for merging.
svnmerge.py merge

Я хочу иметь возможность сделать что-то подобное для hg pull/push/merge/graft, чтобы, если я знаю, что никогда не хочу объединять данное изменение, я мог просто заблокировать его из рассмотрения, делая последующую выборку вишни, слияние, и т. д., в более «выстрелил-забыл». Я много гуглил, но не нашел способа сделать это.

Также, по-видимому, нет возможности просмотреть список еще не внесенных изменений.

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


merge cherry-pick dvcs mercurial
person cbehanna    schedule 21.12.2011    source источник
comment
У MG есть ваши ответы ниже, его версия TL; DR: системы на основе DAG (Mercurial, Git и т. Mercurial хорошо обрабатывается -- по дизайну), то то, что уже было объединено, и то, что нужно объединить, просто сортируется.   -  person Ry4an Brase    schedule 26.12.2011
comment
Увы, в $REALWORLD вы получаете ветвь для текущей разработки и одну или несколько ветвей, представляющих стабилизацию для ожидающего релиза и выпущенную в полевых условиях, и внутри этих ветвей вполне могут быть преднамеренные расхождения. Вы хотите, чтобы рутинные исправления ошибок легко перетекали из ветки в ветку, но вы этого не делаете; например, вы хотите, чтобы новые функции передавались в ветки стабилизации или поддержки, и вы не хотите, чтобы, скажем, изменения конфигурации, устраняющие ошибку, исправленную в текущей ветке разработки, перетекали обратно из веток поддержки.   -  person cbehanna    schedule 05.01.2012
comment
Если я живу словом, отличным от $REALWORLD, мне нужны фантазии получше. Ситуация, которую вы описываете, прекрасно работает в режиме без трансплантации. Попробуйте посмотреть видео мирового турне Fogbugz 2011 года, где @bmp проведет вас через слияние исправлений в несколько выпущенных версий без использования именованных ветвей или трансплантатов. Пока вы делаете исправление дочерним для той ревизии, которая его добавила (которую hg bisect облегчает поиск), вы можете использовать hg merge, чтобы перенести его в любой выпуск или ожидающий выпуск, не добавляя никаких других наборов изменений с Это.   -  person Ry4an Brase    schedule 06.01.2012
comment
Я немного добавил к уже длинному ответу ... @ Ry4an прав, когда говорит, что вы можете добиться отличного рабочего процесса, если знаете правила трехстороннего слияния и, таким образом, объединяете вперед, а не назад.   -  person Martin Geisler    schedule 13.01.2012
comment
Я не сомневаюсь, что вы правы и что для добросовестного опытного пользователя hg ваш метод сработает. У меня есть небольшая надежда, так как люди из SCM, скорее всего, будут единственными, кто занимается оптовыми (т. е. не привилегированными) слияниями между несколькими линиями разработки. Я надеялся, что будет что-то, что я мог бы использовать, чтобы облегчить процесс для наивных пользователей hg, но, похоже, ничего нет. Есть также случай с PITA Fred, которому удается все испортить. В каждой организации есть такие, и важно разработать процессы, ограничивающие ущерб, который он может нанести.   -  person cbehanna    schedule 17.01.2012

Ответы (1)


arrow_upward
9
arrow_downward

Системы на основе DAG, такие как Mercurial и Git, — это все или ничего: когда вы объединяете две ветки, вы выполняете трехстороннее слияние общего предка и двух ветвей.

Трехстороннее слияние только связано с последним этапом каждой ветви. Например, не имеет значения, вносите ли вы изменения за 10 или 1000 шагов — результат слияния будет таким же.

Это означает, что единственный способ игнорировать набор изменений — отменить его перед слиянием:

$ hg backout BAD

Это отменит набор изменений в ветке, создав впечатление, что он никогда не производился с точки зрения трехстороннего слияния.

Если у вас есть целая ветка, которую вы хотите объединить, но игнорируете, вы можете выполнить фиктивное слияние:

$ hg merge --tool internal:local --non-interactive
$ hg revert --all --rev .

Это проходит через слияние, но возвращается к старому состоянию перед фиксацией.

Лучший совет, который я могу вам дать, — это структурировать рабочий процесс так, чтобы в приведенных выше откатах не было необходимости. Это означает исправление ошибки в самой старой аппликативной ветке. Если при создании функции X обнаружена ошибка, используйте hg bisect, чтобы выяснить, когда эта ошибка была введена. Теперь обновите до самой старой ветки, в которой вы все еще хотите исправить ошибку:

$ hg update 2.0
# fix bug
$ hg commit -m "Fixed issue-123"

затем объедините исправление со всеми последующими ветками:

$ hg update 2.1
$ hg merge 2.0
$ hg commit -m "Merge with 2.0 to get bugfix for issue-123"

$ hg update 2.2
$ hg merge 2.1
$ hg commit -m "Merge with 2.1 to get bugfix for issue-123"

Если исправление больше не применяется, вам следует по-прежнему объединить, но отбросить несвязанные изменения:

$ hg update 3.0
$ hg merge 2.2 --tool internal:local --non-interactive
$ hg revert --all --rev .
$ hg commit -m "Dummy merge with 2.2"

Это гарантирует, что вы всегда можете использовать

$ hg log -r "::2.2 - ::3.0"

чтобы увидеть наборы изменений в ветке 2.2, которые еще не были объединены в 3.0.

person Martin Geisler    schedule 21.12.2011