Как я могу научиться понимать, как работает Mercurial, как опытный пользователь git?

Question

Я уже некоторое время пользуюсь git, и, поскольку это единственная DVCS, которую я когда-либо использовал, я многому научился полагаться на то, как она работает для моего рабочего процесса.

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

Так какие ресурсы я могу использовать для этого?

Answer 1

Довольно расширенные концептуальные отличия от официальной вики Mercurial .

Еще один вопрос от stackoverflow : Git эквиваленты наиболее распространенных команд Mercurial?

Комментарий:

Если я возобновлю: " модель ", " различия ", " философия, стоящая за различиями "и влияет на" рабочий процесс".В различиях, о которых я могу думать, есть:

• Для рабочего процесса, кроме отсутствия промежуточной области, вы должны быть в состоянии придерживаться своих старых практик (когда фиксировать, когда переходить,когда объединять, ...).
• Основное отличие философии о ветвях состоит в том, что Git клонирует только указанную ветвь, когда Mercurial клонирует все ветки (если вы хотите только одну ветку, это возможно, но это необходимоконфигурация).
• Философия слияния ничем не отличается.Git может объединять две или более голов, но Mercurial может объединять только две (вы когда-нибудь объединяли больше?).
• Философия переименования сильно отличается, и каждый дизайнер защищал свою точку зрения.Поскольку Mercurial отслеживает переименования, объединение может быть проще.Git пытается угадать переименования во время слияния, если вы используете стратегию «рекурсивный».

• Хранилище сильно отличается в реализации, но не в концепциях (как вы просили «модель», я добавлю больше деталей):

  • Git хранит данные как "объекты" ("объект фиксации", "объект дерева", "объект BLOB-объекта" или "объект тега", сохраненный какфайл, однозначно идентифицируемый там именем, которое является хешем SHA1).Это своего рода «хэш-таблица файловой системы».В последних версиях эти объекты могут быть упакованы так, чтобы в каталоге .git/objects было меньше маленьких файлов.Я не пойду дальше, мое понимание остановится здесь, так как я никогда не нашел смысла, чтобы узнать, как укладываются биты.Вы можете получить красивую печать в содержимом объекта с помощью:

    git show -s --format=raw <commitid> # changeset content
    git ls-tree <treeid> # list tree content
    git show <fileid> # blob content
    

  • Mercurial сохраняет историю каждого файла отдельно как "filelog" в "revlog (NG) "формат .Вы можете вручную проверить имена файлов в .hg/store/data (revlogNG).Обратите внимание, что специальные и прописные символы имеют кодировку «тильда-подчеркивание».

    Вы можете перечислить версии файла с помощью:

    hg debugindex .hg/store/data/<file>.i # hg debugindex <file> also works but you see less of internals
    

    Вы уже отметили, что nodeid s не являютсяодин в hg log.

    А теперь, проверьте содержимое с помощью:

    hg debugdata .hg/store/data/<file>.i <nodeid>
    

    История изменений (более или менее то, что вы видите с hg log) хранится в .hg/store/00changelog.i (проверьте его с помощью hg debugindex .hg/store/00changelog.i, вы увидите те же идентификаторы, что и в hg log в столбце nodeid).Чтобы показать одну необработанную запись истории с идентификатором XXXX, введите hg debugdata .hg/store/00changelog.i XXXX в терминале.(посмотрите на первую строку, позже она будет использоваться как YYYY)

    Состояние дерева хранится в .hg/store/00manifest.i.Соответствующий nodeid в манифесте - YYYY.

    hg debugdata .hg/store/00manifest.i YYYY
    

    . Это покажет список «filename + nodeid», добавленный.Давайте выберем файл foo/bar и отметим nodeid, добавленный к нему, и рассмотрим его ZZZZ (строка foo/barZZZZ).

    Последний шаг, доступ к содержимому файла foo/bar:

    hg debugdata .hg/store/data/foo/bar.i ZZZZ
    

  • Для различий в философии, отчетливо видных из этого базового анализа хранения данных:

    • Когда Git фиксирует, он делает (потенциально многоиз) новые файлы (которые могут быть упакованы позже).Когда Mercurial фиксирует, он добавляет к существующим файлам.

    • В Git blobid может столкнуться с treeid (или commitid или tagid), но это крайне маловероятно,В Mercurial changesetid может столкнуться только с другим changesetid (то же самое для манифестов (дерево) и файлов (блоб)), что еще более невероятно.

• В Git теги являются специальными объектами, в Mercurial это просто список в файле в хранилище (с некоторыми правилами , чтобы узнать, какая модифицированная копия того же тега победит).
• В Mercurial по умолчанию нет «изменить» или «перебазировать», и это выбор дизайна (философия?), Всегда добавляйте, никогда не удаляйте контент, так как это может вызвать проблему параллелизма. Но это возможно с расширениями.