Децентрализированная модель разработки Mercurial'а может несколько озадачить новых пользователей. Эта статья предназначена проиллюстрировать основные концепции, для большей наглядности и понимания её принципов. Для пошаговых инструкций - смотрите Tutorial.
(Translations: Brazilian Portuguese, Chinese, French, German, Italian, Japanese, Korean, Russian, Spanish )
Contents
Что такое репозиторий
Репозиторий Mercurial'а содержит рабочие директории с своей "памятью":
Это память содержит полную историю проекта. В отличии от традиционной SCMs, где есть только одна центральная копия истории, каждая рабочая директория содержит свою личную копию истории. Это позволяет распараллелить разработку.
Рабочая директория содержит копию файлов проекта в определенное время (например ревизии 2), готовых к редактированию. Поскольку теги и проигнорированные файлы тоже подконтрольны ревизии, они так же включены в копию.
Коммит изменений
Когда вы делаете коммит, состояние рабочей директории по отношению к её родителям записывается как новая ревизия:
Отметьте, тут ревизия 4 это - ветка ревизии 2, которая, в свою очередь, была ревизией рабочей директории. Теперь ревизия 4 - рабочая директория родителя.
Ревизии, Наборы изменений(Changesets), Вершины(Heads), и Tip
Mercurial группирует связанные изменения разных файлов в единые атомарные Наборы изменений(changesets), которые являются ревизиями целого проекта. Каждый из них имеет последовательный номер ревизии. Из-за того, что Mercurial допускает распределенную параллельную разработку, эти номер ревизий могут быть несогласованы между пользователями. Поэтому Mercurial также присваивает каждой ревизии глобальный ID набора изменений. Идентификаторы наборов изменений являются 40-разрядными 16-ричными числами, но могут быть сокращены до любого однозначного префикса, например "e38487".
Ветки и слияния в истории ревизий могут появляться в любой момент. Каждая неслитая ветка создает новую вершину в истории ревизий. Здесь ревизии 5 и 6 являются вершинами. Mercurial рассматривает ревизию 6 как наконечник(tip) хранилища, вершину с наибольшим номером ревизии.
Клонирование, Внесение изменений, Слияние, и Pulling
Давайте начнем с пользователем Алиса, которая имеет хранилище выглядящее так:
Боб клонирует это хранилище, и в итоге получает полную копию хранилища Алисы (хотя, его рабочая директория независима!):
Затем Боб коммитит некоторые изменения:
Алиса затем параллельно вносит свое собственное изменение:
Боб затем вытягивает(pulls) хранилище Алисы для синхронизации. Это копирует все изменения Алисы в хранилище Боба:
Из-за того, что ревизия g Алисы является новейшей вершиной в хранилище Боба, теперь она является конечной ревизией (tip). Затем Боб производит слияние, которое объединяет последнее изменение над которым он работал (f) с конечным изменением(tip), подтверждает (commit) результат, и в итоге получает:
Теперь, если Алиса вытянет изменения (pulls) от Боба, она получит изменения Боба e, f, и h, и они будут полностью синхронизованы:
Децентрализованная система
Mercurial полностью децентрализованная система, и таким образом не имеет внутреннего понятия о центральном хранилище. Поэтому пользователи вольны определять свои собственные топологии для разделения изменений (см. CommunicatingChanges):
Чего не может Mercurial
Знакомые с SVN/CVS пользователи ожидают, что в hg можно размещать и раздельно использовать несколько проектов в одном репозитории. Это действительно не то, ради чего hg был создан, и тут нужно пробывать другие варианты организации работы. Это, в особенности, означает, что вы не можете получить из репозитория только один каталог. Если вам никак не обойтись без управления несколькими проектами через некий вариант мета-репозитория, вы можете попробывать использовать ForestExtension.
Пошаговую инструкцию по использованию Mercurial смотрите в Tutorial.