Как коммиты хранятся в порядке

Question

Быстрый вопрос по Mercurial. Предположим, у меня и моего коллеги есть обновленная копия ствола. Мы оба вносим изменения, затем мы оба толкаем / вытягиваем изменения друг от друга.

Я предполагаю, что Mercurial сохраняет изменения в порядке, основанном на дате фиксации (поскольку нет увеличивающейся ревизии, только GUID). Так что же произойдет, если дата моего компьютера отстанет на один день, а я отправлю полдня после моего коллеги. Появятся ли мои изменения за полдня раньше, чем у моего коллеги?

Answer 1

@ У Мартин есть правильный ответ, но, похоже, он не щелкает.Если это что-то прояснит, выберите его:

• Время фиксации для наборов изменений Mercurial не имеет абсолютно никакого отношения к тому, как они объединяются, чередуются или объединяются

Mercurial,и другие DVC, все отслеживание истории полностью основано на DAG (направленный ациклический граф), что означает:

• только только часть метаданных, которые имеют значение, являются родителями или родителяминабор изменений

Перед фиксацией вы можете увидеть, какой будет родитель вашей группы изменений, набрав hg parents, а после фиксации вы можете увидеть его в hg log.

В ваших примерах, если вы извлекли наборы изменений вашего коллеги и обновили свой рабочий каталог, чтобы отразить их (hg pull ; hg update), тогда его или ее набор изменений будет родителем вашего набора изменений.Если вы не вытянули / не обновили, чтобы отразить его или ее набор изменений, тогда оба ваших набора изменений будут иметь одного и того же родителя - они будут братьями и сестрами - когда при слиянии ни один из них не будет иметь приоритет над другим в любом случае.

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

Короче говоря, дата никогда не согласованав обычных операциях и является чисто метаданными , не более релевантными, чем описание автора или коммита.

Answer 2

Действительно, ваши наборы изменений имеют временную метку (внутренне хранятся как секунды с момента начала UNIX и смещение часового пояса), и при отображении набора изменений они упорядочиваются по метке времени, и ваши наборы изменений будут отображаться в неправильном месте в качестве их метки времени будут неправильными. См. https://www.mercurial -scm.org / wiki / ChangeSet

Хотя это не такая уж большая проблема; временные метки не имеют отношения к тому, как ваши изменения объединяются с изменениями вашего коллеги. Здесь имеют значение только идентификаторы изменений, и при объединении используется общий предок. Он будет следовать графику ваших наборов изменений вниз в поисках идентификатора набора изменений, который также имеется у вашего коллеги, а затем объединяет ваши и его изменения в дальнейшем. См. https://www.mercurial -scm.org / wiki / Merge

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

Answer 3

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

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

Номера ревизий (локальный целочисленный счетчик) являются всего лишь счетчиком: каждый новый набор изменений получает следующий доступный номер ревизии.Простой оператор диапазона в Mercurial работает непосредственно с номерами ревизий, поэтому X:Y означает «дать мне наборы изменений с номерами ревизий от X до Y (включительно)».Это не очень полезно, когда номера ревизий основаны только на порядке, в котором наборы изменений были созданы или извлечены в хранилище.

Используйте взамен X::Y, что дает вам наборы изменений, которые являются потомками X и предкамиY, т. Е. Следует ветвям истории.