Почему Mercurial Merge фиксирует изменения в рабочей копии?

Question

Я использую Mercurial уже несколько недель и не понимаю, почему, когда Mercurial объединяет зафиксированные изменения из двух репозиториев, он делает это в рабочей копии?

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

Просто не нужно привлекать рабочую копию. Я что-то упустил?

Answer 1

Я не писал Mercurial, поэтому не могу сказать, почему они так сделали, но вот некоторые из положительных результатов этого решения:

• Вы можете просмотреть результаты слияния, прежде чем его совершить
• вы можете отредактировать результаты слияния до его фиксации
• вам рекомендуется часто совершать

Если вы действительно хотите выполнить слияние и иметь в своем рабочем каталоге вещи, которые вы не можете перенести, не беспокойтесь о полке, просто сделайте:

cd ..
hg clone myrepo myrepo-mergeclone
hg -R myrepo-mergeclone merge
hg -R myrepo-mergeclone push myrepo

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

Answer 2

В репозитории есть только одна рабочая копия, по определению :

Рабочий каталог - это каталог верхнего уровня в хранилище, в котором простые версии файлов доступны для чтения, редактирования и сборки.

Если ваша файловая система не происходит от кота Шредингера, вы не можете иметь две версии одного и того же файла одновременно, поэтому у вас не может быть двух рабочих копий.

Тем не менее, теоретически возможно использовать нечто вроде эфемерного клона (per @ Ry4an), чтобы действовать в качестве рабочей копии слияния, разрешать конфликты там, фиксировать, а затем заставлять его исчезать. Вы получите красивый набор изменений слияния и вашу неповрежденную рабочую копию.

Я могу придумать несколько способов добиться этого:

1. Подайте ходатайство команде hg, чтобы сделать это в ядре
2. Напишите расширение для реализации эфемерного клона или каким-либо другим способом
3. Полка с временной сменой
4. Полка с MQ

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

В рабочем процессе MQ ваша рабочая копия всегда является текущим патчем. Таким образом, для ситуации слияния вы должны сделать:

1. hg qrefresh
2. hg qpop -a
3. hg update -r<merge first parent>
4. hg merge [-r<merge second parent>]
5. hg commit
6. hg update qparent
7. hg qgo <working copy patch>

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

Решение № 3 действительно то же самое, что и № 4, так как патч является временным набором изменений по определению (это действительно единственное, что вам нужно для понимания MQ). Это просто разные команды:

1. hg commit -A
2. hg update -r<merge first parent>
3. hg merge [-r<merge second parent>]
4. hg commit
5. hg update -r<working copy changeset parent>
6. hg revert -a -r<working copy changeset>
7. hg strip <working copy changeset>

Если вы хотите сохранить набор изменений рабочей копии и продолжить фиксацию, просто обновите его до # 5.

Судя по твоему вопросу, ты уже знаешь №4, но не любишь полки. Я думаю, что откладывание хорошо, потому что объединение - это принципиально иная задача, чем кодирование (изменение рабочей копии), а откладывание делает переключение контекста явным и безопасным.

Answer 3

Как упомянуто в главе «Слияние» HgInit :

Команда слияния hg merge взяла две головы и объединила их.
Затем он оставил результат в моем рабочем каталоге.
Он этого не совершал. Это дает мне возможность проверить правильность слияния .

Такая проверка может включать конфликты в слиянии, которые пользователь должен просмотреть:

В KDiff3 вы видите четыре панели

• Вверху слева находится оригинальный файл.
• Верхний центр показывает Роуз ее версию.
• Вверху справа показана Роза, моя версия.
• В нижней панели находится редактор, в котором Rose создает объединенный файл с разрешенными конфликтами.

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