Почему mercurial притягивает коммиты из других веток?
Есть две ветки - master (прод) и default (тестовая среда). Каждая новая задача - это новая ветка от master. После выполнения она сливается с default, тестируется, потом сливается с master. Создаю новую ветку от master, вношу изменения в 3х файлах, коммичу, сливаю с default - притягиваются коммиты из других веток (те, которые сливались с master недавно) т.е. mercurial, чтобы смотреть в 3 закоммиченных файла, смотрит везде и вываливает кучу конфликтов... Нормальное ли такое поведение системы контроля версий и как это можно исправить?
Ответы (2 шт):
Это обычное поведение. Если вы одновременно с кем-то вносите изменения в одни и те же файлы, то процедура слияния, используемая по-умолчанию, всегда будет выдавать конфликты. Внешние merge tools могут разрешать некоторые типы конфликтов.
- A - Вы завершили задачу почти одновременно с другим SDE (коммиты 4, 5)
- B - Но потом тот успел раньше вас слить с default и master
- С - В то время как вы сливали с локальным default и разрешали конфликты
- D - Вы хотели сделать push, но оказалось, что на ветке default две головы
- E - Потребуется опять сливать и разрешать конфликты
Вариант, когда вы один сливаете изменения.
- C-2 - После выполнения задачи (коммит 5), вы подтягиваете изменения
- D-2 - Сливаете с default и master и разрешаете конфликты
В принципе, число конфликтов будет одинаковым, только в первом варианте разделено на две части - сначала вы сливаете изменения коммитов 3-5, потом 6-7. А во втором случае - сразу 3-6-5.
По умолчанию используется merge tool :merge. Но по мне, что :merge, что :merge3 работают одинаково плохо. Поэтому я использую kdiff3 - настраивается в .hgrc (или mercurial.ini). Только kdiff3, который поставляется с TortoiseHg весьма устарел, и похоже заброшен. Более свежий можно взять из состава KDE, только там бывают весьма нестабильные версии, надо пробовать разные.
Нормальное ли такое поведение системы контроля версий
Да, оно не только нормальное, но и правильное
как это можно исправить?
Никак. Просто навести порядок в организационных процессах в организации (и в головах):
- При merge двух бранчей
- находится последний общий предок
- находятся (и агрегируются) все изменения, произошедшие в бранче-источнике со времени этого changeset-a
- суммарный diff в итоге предыдущего пункта и будет тем, что должно и будет применяться к бранчу-приемнику
- если master ведется правильно (там нет ничего, кроме
branchpoint()+merge()в синтаксисе ревсетов), то никакие "коммиты из других веток" в принципе "притягиваться" не могут
Если нужен более разжеванный до кашицы ответ, то стоит показывать в вопросе больше информации, к примеру DAG проблемной части (hg log -G ...) с указанием, какие такие коммиты из "других ветвей" (какие? откуда?) в каком merge оказались неожиданно участвующими. Тогда будет нормальный ответ, а не гадание
HTH