Децентрализированная модель разработки 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.