Готовый перевод Bazaar is a distributed version control system / Базар - распределенная система контроля версий: doc/en/user-guide/zen.txt

Путь Bazaar
===========

Концепция Bazaar
---------------

Хотя Bazaar во многом похож на другие инструменты контроля версий, есть
некоторые важные различия, которые не всегда очевидны на первый взгляд. Этот
раздел пытается объяснить некоторые вещи, который пользователь должен знать
чтобы разбираться в Bazaar, т.е. глубоко его понимать.

Заметьте: чтобы использовать Bazaar совсем необязательно полностью понимать
этот раздел. Вы можете просмотреть этот раздел сейчас и вернуться к нему позже.

Номер ревизии
------------------------------

Все ревизии в пределах основной линии ветки пронумерованы по
порядку. Первая ревизия имеет номер 1, вторая 2, номер последней,
соответственно, равен количеству ревизий в ветке. Благодаря этому
вполне естественно использовать их в общении, например, Вы
можете сказать "возьми десятую ревизию из моей ветки" или
"Исправлено в ревизии 3050".

Для ревизий полученных путем слияния с другой веткой используется точечная нотация (например, 3112.1.5). Номер ревизии в таком виде состоит из трех чисел: Первое число указывает на номер ревизии в основной линии с которой начинаются различия (идет ответвление). Второе число — счетчик веток. Из одной и той же ревизии может ответвляться много веток и каждая из них будет иметь уникальный номер. Третье число — порядковый номер ревизии начиная с момента ответвления. Например, 3112.1.5 - это пятая ревизия в первом ответвлении от ревизии 3112.

.. [#] Версии ниже bzr 1.2 используют несколько другой алгоритм.
Некоторые вложенные ветви получили бы дополнительные номера
(такие как 1.1.1.1.1) вместо более простой системы с 3 номерами.

Иерархическая история это хорошо
----------------------------

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

* Ствол проекта содержит 100 ревизий.
* Мария делает 3 правки в рамках задачи X
* Бил делает 4 правки в рамках задачи Y

Если бы разработчики работали параллельно и использовали традиционную централизованную СКВ, история проекта скорее всего была бы линейной и правки Марии и Била были бы перемешаны. История проекта могла бы выглядеть, например, так::

107: Add documentation for Y
106: Fix bug found in testing Y
105: Fix bug found in testing X
104: Add code for Y
103: Add documentation for X
102: Add code and tests for X
101: Add tests for Y
100: ...

Уже сейчас видно, что анализировать ход решения задачи X довольно затруднительно, а с каждой последующей фиксацией проблема только усугубляется.
Многие команды используют этот подход, поскольку их инструменты делают процесс ветвления и слияния сложным. В результате, чтобы уменьшить разброс своих ревизий, разработчики вынуждены как можно чаще обновлять свою рабочую копию и как можно чаще вносить свои изменения в ствол. Если Вы пожелаете, Вы можете использовать Bazaar точно так же. Однако Bazaar предлагает другие подходы, с которыми Вам стоит ознакомиться.

Альтернативный подход, поддерживаемый распределенной СКВ, заключается в том, чтобы создать отдельные ветки под каждую задачу и объединить их когда задачи будут решены. В этом случае, ветка для задачи Марии будет выглядеть так::

103: Fix bug found in testing X
102: Add documentation for X
101: Add code and tests for X
100: ...

А ветка Била так::

104: Add documentation for Y
103: Fix bug found in testing Y
102: Add code for Y
101: Add tests for Y
100: ...

Если задачи независимы и Вы хотите получить линейную историю, изменения могут быть группами помещены в ствол (Технически это можно сделать различными способами, но это уже выходит за рамки нашего разговора). Итоговая история может выглядеть так::

107: Fix bug found in testing X
106: Add documentation for X
105: Add code and tests for X
104: Add documentation for Y
103: Fix bug found in testing Y
102: Add code for Y
101: Add tests for Y
100: ...

Это уже гораздо лучше нежели случайным образом перемешанные ревизии, но все же несколько неудобно. Есть лучшее решение. Ветки могут быть объединены между собой образовав тем самым нелинейную историю. Результат мог бы выглядеть так::

102: Merge feature X
100.2.3: Fix bug found in testing X
100.2.2: Add documentation for X
100.2.1: Add code and tests for X
101: Merge feature Y
100.1.4: Add documentation for Y
100.1.3: Fix bug found in testing Y
100.1.2: Add code for Y
100.1.1: Add tests for Y
100: ...

Или скорее всего так::

102: Merge feature X
100.2.3: Fix bug
100.2.2: Add documentation
100.2.1: Add code and tests
101: Merge feature Y
100.1.4: Add documentation
100.1.3: Fix bug found in testing
100.1.2: Add code
100.1.1: Add tests
100: ...

Такой подход обладает многими преимуществами:

* История проекта становится понятнее. Связанные изменения сгруппированны между собой и однозначно разделены.

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

* Если понадобится, можно очень легко отменить изменения связанные с конкретной задачей.

* Чтобы убедиться что все тесты проходят успешно, средства непрерывной
интеграции (CI tools) можно использовать только перед тем как
зафиксировать в основной линии результат объединения. (Во многих
случаях нет смысла использовать средства непрерывной интеграции после
каждой фиксации, поскольку некоторые тесты будут проходить с ошибкой.
Фактически, добавление тестов на первом этапе — стиль TDD (Разработка
через тестирование) — гарантирует это)

Итак, основные моменты:

*Организация работы с использованием веток.*

*Объединение изменений с использованием слияния*

*Упорядоченные номера ревизий и иерархия делают историю легко отслеживаемой.*

Каждая ветка имеет собственный вид истории
---------------------------------------

Как объяснено выше, Базар делает различие между:

* ревизиями основной линии, т.е. те которые Вы зафиксировали в свою ветку, и

* объединенными ревизиями, т.е. ревизии добавленные в следствии фиксации объединения.

Каждая ветка в действительности имеет свой собственный вид истории,
т.е. в различных ветках одной и той же ревизии могут быть присвоены
различные "локальные" номера. Ревизии основной линии всегда
размещаются с единичным номером, в то время как объединенные
ревизии всегда размещаются в точечной нотации.

Продолжим предыдущий пример, после того как Мария закончит
работу над задачей и объединит ствол проекта со своей веткой
история ревизий её ветки будет выглядеть так::

104: Merge mainline
100.2.1: Merge feature Y
100.1.4: Add documentation
100.1.3: Fix bug found in testing
100.1.2: Add code
100.1.1: Add tests
103: Fix bug found in testing X
102: Add documentation for X
101: Add code and tests for X
100: ...

Ещё раз. Для Марии достаточно посмотреть на верхний уровень
*её* истории, чтобы шаг за шагом просмотреть все действия
предпринятые ею для решения своей задачи. В этом смысле,
объединение стволовой ветки (и решение любых конфликтов
возникающих при этом) это только один шаг истории.

Важно помнить, что Bazaar не меняет ни текущую историю,
ни глобальные идентификаторы ревизий. Вы всегда можете можете
использовать последние, если пожелаете. Фактически, в общении Вы
можете использовать особые номера ревизий ветки как только вы сообщили
URL ветки в качестве контекста. (В большинстве проектов Bazaar,
разработчики подразумевают стволовую ветку если они обмениваются
номерами ревизий без указания URL ветки)

Несмотря на то, что в результате объединения локальным номерам
ревизий назначаются новые номера объединенных ревизий, номера
ревизий в ветке не меняются. Bazaar изменит номера ревизий только
в одном случае, если вы явно укажете ему отразить другую ветку.

Примечание: Ревизии пронумерованы однозначным способом:
если две ветки имеют одинаковые ревизии в основной линии,
то все им родственные ревизии будут иметь одинаковые номера.
Например, если ветки Алисы и Боба совпадают в ревизии 10,
то все предыдущие ревизии так же будут совпадать.

Резюме
------

Обычно, если вы следовали ранее полученным советам - организовать вашу работу в ветках и использовать объединение для сотрудничества - вы обнаружите что обычно Bazaar делает то что вы ожидаете.

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

..
vim: ft=rst tw=74 ai

Переведено на Нотабеноиде
http://notabenoid.org/book/164/9542

Переводчики: Neronyatkin, master