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

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

master 05.06.09 в 19:46

Глубокое понимание Bazaar
-------------------------

master 05.06.09 в 20:03

Философия Bazaar
-------------------------

Neronyatkin 21.06.09 в 02:10

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

master 05.06.09 в 20:03

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

master 05.06.09 в 20:04

Понимание номеров ревизий
-------------------------

master 05.06.09 в 19:46

Что такое номер ревизии.
------------------------------

Neronyatkin 21.06.09 в 02:00

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

Neronyatkin 21.06.09 в 02:43

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

Neronyatkin 21.06.09 в 03:01

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

Neronyatkin 23.06.09 в 20:23

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

Neronyatkin 21.06.09 в 07:42

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

Neronyatkin 21.06.09 в 23:40

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

Neronyatkin 21.06.09 в 03:22

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

Neronyatkin 21.06.09 в 03:22

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 предлагает другие подходы, с которыми Вам стоит ознакомиться.

Neronyatkin 21.06.09 в 03:23

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

Neronyatkin 21.06.09 в 07:29

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

Neronyatkin 21.06.09 в 07:29

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

Neronyatkin 21.06.09 в 07:29

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

Neronyatkin 21.06.09 в 07:30

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

Neronyatkin 21.06.09 в 07:37

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: ...

Neronyatkin 21.06.09 в 07:38

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

Neronyatkin 22.06.09 в 00:11

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: ...

Neronyatkin 21.06.09 в 22:49

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

Neronyatkin 22.06.09 в 00:27

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: ...

Neronyatkin 21.06.09 в 22:49

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

Neronyatkin 22.06.09 в 00:32

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

Neronyatkin 22.06.09 в 00:40

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

Neronyatkin 22.06.09 в 02:15

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

Neronyatkin 22.06.09 в 02:17

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

Neronyatkin 23.06.09 в 21:03

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

Neronyatkin 23.06.09 в 21:05

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

Neronyatkin 23.06.09 в 21:06

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

Neronyatkin 23.06.09 в 21:06

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

Neronyatkin 23.06.09 в 21:07

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

Neronyatkin 23.06.09 в 21:09

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

Neronyatkin 23.06.09 в 21:12

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

Neronyatkin 23.06.09 в 21:19

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

Neronyatkin 23.06.09 в 21:17

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

Neronyatkin 23.06.09 в 21:23

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

Neronyatkin 24.06.09 в 05:25

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: ...

Neronyatkin 21.06.09 в 22:49

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

Neronyatkin 24.06.09 в 05:49

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

Neronyatkin 24.06.09 в 06:22

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

Neronyatkin 24.06.09 в 06:45

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

Neronyatkin 24.06.09 в 07:08

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

master 05.06.09 в 19:43

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

master 05.06.09 в 19:42

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

master 05.06.09 в 19:44

..
vim: ft=rst tw=74 ai

master 05.06.09 в 20:04