Diff for "RussianUnderstandingMercurial"

Децентрализированная модель разработки Mercurial'а может несколько озадачить новых пользователей. Эта статья предназначена для иллюстрации основных концепций и объяснения её принципов с большей наглядностью. Для пошаговых инструкций - смотрите Tutorial.

(Translations: Brazilian Portuguese, Chinese, French, German, Italian, Japanese, Korean, Russian, Spanish )

Что такое репозиторий

Репозиторий 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.

CategoryRussian