Совместное использование Mercurial приводит к нескольким коммитам с одинаковыми изменениями при использовании центрального репозитория

Question

Я использую Mercurial с центральным хранилищем.Поскольку двое или более из нас работают над изменениями, которые мы совершаем локально.В какой-то момент мы отправляем эти изменения обратно в центральное хранилище.

Проблема возникает, когда я делаю тягу.Часто встречаются файлы, которые были изменены и отправлены другим разработчиком, и они попадают в мой репозиторий с подтягиванием.Затем мне необходимо выполнить слияние, которое показывает мне разницу между моим локальным хранилищем и файлами, которые были зафиксированы.

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

Есть ли какой-нибудь способ в mercurial обновить мойхранилище и файлы, к которым я не прикасался, просто обновлять, а не записывать одно и то же изменение дважды, один раз от первоначального разработчика и один раз в моем слиянии?

Этот вопрос, кажется, поднимает ту же точку, но нене дайте ответа на мой вопрос: Почему ртутный немой при слиянии?Как я могу упростить вытягивание / объединение изменений?

Answer 1

Mercurial работает в терминах наборов изменений и ревизий.

Набор изменений - это моментальный снимок изменений, внесенных в ревизию.

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

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

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

Теперь есть способы смягчить все ветви, вы можетенапример, используйте rebase.

Произойдет следующее:

central: 1---2---3---4

local:   1---2---3---4

Вы что-то измените

central: 1---2---3---4

local:   1---2---3---4---5

Кто-то еще что-то изменит, и нажмите:

central: 1---2---3---4---5'--6'

local:   1---2---3---4---5

(я использую 'после 5, чтобы показать, что хотя это ревизия № 5 в этом хранилище, она не совпадает с ревизией № 5 в другом хранилище.)

Затем, когда вы тянете, это выглядит так:

central: 1---2---3---4---5'--6'  <-- corresponds to these <--+
                                                             |
local:   1---2---3---4---5                                   |
                      \                                      |
                       6'---7'   <-- note that these gets renumbered

Затем вы перебазируете 5, чтобы быть сверху 7 ', и вы получите это:

local:   1---2---3---4---6'--7'--5

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

Answer 2

Краткий ответ: «Не беспокойся об этом».Вам кажется, что изменения, которые сделал этот человек, снова были сделаны вами при последующем слиянии, но это только потому, что у 'diff' нет отличного способа показать слияния в любой VCS.Изменение - их, комбинация - ваша, и все получается.Два человека, подающие в суд на DVCS, в итоге получают историю, похожую на плетеную веревку, и это нормально.