Mercurial и инструменты для слияния? - PullRequest
8 голосов
/ 09 июля 2010

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

Или он сначала видит, может ли он сам объединить файл, и только если он не может добавить его к внешнему инструменту?

Причина, по которой я спрашиваю, заключается в том, что я (еще раз) перечитываю учебник , написанный Джоэлем Спольски по Mercurial , и он говорит одну вещь, сравнивая, как Subversion и Mercurial объединяются, заключается в том, что :

В отличие от этого, пока мы работали отдельно в Mercurial, Mercurial занимался серией изменений. И поэтому, когда мы хотим объединить наш код, Mercurial на самом деле имеет гораздо больше информации: он знает, что каждый из нас изменил и может применить эти изменения, а не просто смотрит на конечный продукт и пытается угадать, как его поместить. вместе.

Только мой опыт подсказывает мне, что, по-видимому, задействуется внешний инструмент слияния, когда две ветви имеют изменения в одинаковых файлах. И поэтому, разве это не делает приведенный выше аргумент неверным?

Или мне следует интерпретировать это следующим образом:

  • Subversion объединяет только конечное состояние двух ветвей и выполняет больше работы в одном модуле
  • Mercurial объединяет каждый набор изменений по отдельности, что позволяет ему работать с меньшими единицами изменений, с более высокой вероятностью успеха объединения

Может кто-нибудь пролить свет на это?


Редактировать : Позвольте мне привести пример:

@echo off

setlocal

if exist repo rd /s /q repo

md repo
cd repo
hg init .

rem --- version 0 ---
echo 1 >test.txt
echo 2 >>test.txt
echo 3 >>test.txt
echo 4 >>test.txt
echo 5 >>test.txt
hg add test.txt
hg commit -m "v0"

rem --- version 1 ---
echo 1 >test.txt
echo 2 v1 >>test.txt
echo 3 >>test.txt
echo 4 >>test.txt
echo 5 >>test.txt
hg commit -m "v1"

rem --- version 2 ---
hg update 0
echo 1 >test.txt
echo 2 >>test.txt
echo 3 >>test.txt
echo 4 v2 >>test.txt
echo 5 >>test.txt
hg commit -m "v2"

rem --- merge ---
hg update 1
hg merge 2

Сначала создается файл со следующим содержимым:

1
2
3
4
5

Затем он меняется на:

1
2 v1
3
4
5

Затем он возвращается к исходной версии (changeset) и изменяет ее на:

1
2
3
4 v2
5

Затем он пытается объединить два.

Теперь, согласно (в настоящее время) единственному ответу, это не должно создавать проблем, поскольку изменения не находятся в конфликте.

Однако на этом этапе запускается Beyond Compare (мой внешний инструмент слияния).

Ответы [ 2 ]

6 голосов
/ 10 июля 2010

Большая разница между mercurial merging и svn merger заключается в том, что алгоритм mercurial merge имеет доступ к последнему общему предку между двумя объединяемыми ревизиями. Если ваша история выглядит как

A--B
 \-C

svn превратит ваши инструменты слияния в потери B и C. Mercurial запустит ваш инструмент с A, B и C, и некоторые инструменты справятся с этим лучше.

Mercurial выполняет собственное внутреннее слияние перед запуском вашего инструмента, где он использует A, B и C, чтобы сделать некоторые из очевидных выборов сам. Вы можете отключить это, изменив настройку premerge для инструмента.

Ваш тест не дает хороших результатов, потому что вы объединяете 2 со своим предком. Если вместо этого вы делаете hg update 0 перед созданием набора изменений 2, то у вас есть фактическая история ветвления, подобная этой:

@  changeset:   2:790856e061f4
|  tag:         tip
|  parent:      0:bfba1d8f77af
|  user:        Ry4an Brase
|  date:        Fri Jul 09 16:50:34 2010 -0500
|  summary:     added v2
|
| @  changeset:   1:7a9c581561b6
|/   user:        Ry4an Brase
|    date:        Fri Jul 09 16:50:16 2010 -0500
|    summary:     added v1
|
o  changeset:   0:bfba1d8f77af
   user:        Ry4an Brase
   date:        Fri Jul 09 16:49:29 2010 -0500
   summary:     first

тогда когда вы hg merge вы получите:

1
2 v1
3
4 v2
5

без запуска инструмента слияния.

3 голосов
/ 09 июля 2010

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

Кроме этого, фактический алгоритм слияния не основан на изменениях, он основан на файле, чтобы обеспечить наилучшие результаты слияния.См. Mercurial Wiki для получения более подробной информации.

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

...