1
===============================
2
Работа в централизованном стиле
3
===============================
11
Этот документ описывает один из возможных подходов к использованию
12
Bazaar_. А именно, использование распределенной системы контроля версий
13
Bazaar_, в централизованном стиле. Bazaar_ разработана, что бы быть гибкой
14
и допускать различные подходы к работе, начиная от полностью
15
децентрализованного, до практически централизованного. Подход описанный
16
здесь позволяет новым пользователям проще вникнуть в более продвинутое
17
использование Bazaar_ и смешивать централизованные и децентрализованные
20
В общем случае, данный документ интересен для пользователей переходящих с
21
централизованных систем, таких как CVS, или Subversion. В таких системах
22
обычно есть единственный центральный сервер на котором хранится код
23
проекта и участники команды работают над этим кодом, синхронизируя свою
24
работу. Такой режим так же подходит для разработчика-одиночки,
25
работающего на нескольких различных машинах.
27
.. _Bazaar: http://bazaar.canonical.com
36
В самом начале, для более удобной работы с Bazaar_, желательно осуществить
37
достаточно простые шаги по настройке.
40
Настройка e-mail пользователя
41
-----------------------------
43
Строка идентифицирующая пользователя сохраняется при каждой фиксации. Хотя
44
она не обязательно должна быть аккуратной или уникальной она будет
45
использоваться в сообщениях журнала и аннотациях, таким образом лучше что
46
бы она была похожа на что-то реальное.
50
% bzr whoami "Иван Пупкин <ivan@pupkin.ru>"
53
Настройка локального репозитория
54
--------------------------------
56
В общем случае ветки Bazaar_ копируют полную историю изменений вместе с
57
собой, что, кстати, позволяет работать в полностью децентрализованном
58
стиле. Как оптимизация для связанных веток возможно объединять их
59
хранилища таким образом, что отпадает необходимость в копировании полной
60
истории изменений при создании новой ветки.
62
Лучший способ сделать это - создать `Разделяемый репозиторий`_. В общем
63
случае, ветки будут разделять хранилище если они находятся в подкаталоге
64
этого репозитория. Давайте создадим `Разделяемый репозиторий`_ в нашем
65
домашнем каталоге и таким образом все ветки которые мы будем создавать
66
под ним будут разделять хранилище истории.
70
% bzr init-repo --trees ~
73
Настройка удаленного репозитория
74
--------------------------------
76
Во многих случаях нужно создавать место где данные хранятся отдельно от
77
рабочего каталога. Такой подход необходим для централизованных систем
78
(CVS/SVN). Обычно эти каталоги находятся на различных машинах, хотя и не
79
всегда. На самом деле это достаточно хороший подход, особенно в рабочей
80
среде. Так как здесь существует центральная точка, где могут быть сохранены
81
все данные и даже если что-то случится с машиной разработчика
82
зафиксированная работа не будет потеряна.
84
Давайте создадим разделяемое место для нашего проекта на удаленной машине
85
и назовем его ``centralhost``. Мы снова используем `Разделяемый
86
репозиторий`_ для оптимизации использования дисков.
90
% bzr init-repo --no-trees sftp://centralhost/srv/bzr/
92
Можно рассматривать этот шаг как похожий на установку CVSROOT, или
93
репозитория Subversion. Опция ``--no-trees`` указывает Bazaar не
94
создавать рабочий каталог в репозитории. Нам это подходит, т.к. никто
95
не будет напрямую что-то изменять на ветках в центральном репозитории.
98
Миграция рабочего проекта в Bazaar
99
==================================
101
Теперь, когда у нас есть репозиторий давайте создадим проект под контролем
102
версий. В большинстве случаев у вас уже есть какой-то код с которым вы
103
работаете и для хранения которого вы хотели бы использовать Bazaar_. Если
104
код изначально уже был под контролем версий существует много способов
105
конвертировать проект в Bazaar_ без потери истории изменений. Но эти
106
способы находятся вне тем рассматриваемых в данном документе. Смотрите
107
`Отслеживание изменений на основной ветке`_ для некоторых способов (секция
108
"Конвертирование и сохранение истории").
110
.. _Отслеживание изменений на основной ветке: http://wiki.bazaar.canonical.com/TrackingUpstream
113
TODO: На самом деле нам нужен другой документ для описания
114
конвертирования проекта. Но пока ссылка выше - это лучшее.
117
Разработчик 1: Создание первой ревизии
118
--------------------------------------
120
Сначала нам нужно создать ветку в нашем удаленном репозитории, там где мы
121
хотели бы хранить наш проект. Допустим, что у нас уже есть проект "sigil",
122
который мы хотели бы хранить под контролем версий.
126
% bzr init sftp://centralhost/srv/bzr/sigil
128
Это можно рассматривать как ветку "HEAD" в терминах CVS, или как "trunk" в
129
терминах Subversion. Назовем это веткой разработки ``dev``.
131
Я предпочитаю работать в подкаталоге моего домашнего каталога, что бы
132
избегать коллизий со всеми другими файлами которые в ней находятся. Также
133
нам понадобится каталог для проекта где мы сможем хранить различные ветки
134
проекта над которыми работаем.
143
% bzr checkout sftp://centralhost/srv/bzr/sigil dev
147
% bzr commit -m "Первый импорт Sigil"
149
Выше мы создали пустую ветку ``/sigil`` на ``centralhost`` и затем
150
загрузили эту пустую ветку на нашу рабочую машину что бы добавить файлы из
151
нашего старого проекта. Есть много способов настроить свой рабочий
152
каталог, но шаги выше упрощают дальнейшую работу с ветками для работы
153
над ошибками, или новыми функциями. И одна из наиболее сильных сторон
154
Bazaar_ - это именно отличная работа с ветками.
156
На этом этапе, т.к. мы создали рабочую копию (checkout) удаленной ветки,
157
все фиксации которые будут сделаны в ``~/work/sigil/dev/`` будут
158
автоматически сохранены и локально и на ``centralhost``.
161
Разработчик N: Получение рабочей копии проекта
162
----------------------------------------------
164
Так как первый разработчик проделал всю работу по созданию проекта все
165
остальные разработчики могут просто получить рабочую копию ветки. Хотя
166
**они все еще должны следовать** разделам `Настройка e-mail пользователя`_ и
167
`Настройка локального репозитория`_.
169
Получим рабочую копию текущего дерева разработки::
172
% bzr checkout sftp://centralhost/srv/bzr/sigil dev
174
Теперь, когда два человека имею рабочую копию
175
``sftp://centralhost/srv/bzr/sigil`` будут ситуации когда одна из копий
176
будет не синхронизирована с текущей версией. Во время фиксации Bazaar_
177
проинформирует пользователя об этом и не допустит фиксации. Для получения
178
последних изменений нужно использовать ``bzr update``. Эта команда может
179
потребовать разрешения конфликтов если были изменены одни и те же файлы.
182
Разработка на отдельных ветках
183
==============================
185
До этого момента все работали и фиксировали изменения на одну и ту же
186
ветку. Это значит, что каждый должен периодически обновлять свою ветку и
187
иметь дело с изменениями других разработчиков. Так же если один
188
разработчик фиксирует что-то, что приводит к ошибкам, то после
189
синхронизации эта проблема коснется каждого.
191
Обычно лучше вести разработку на различных ветках и затем, как только
192
изменения достаточно стабильны, интегрировать их обратно на основную
193
ветку. Это одно из наибольших изменений по сравнению с работой в CVS/SVN.
194
Обе эти системы позволяют работать с отдельными ветками, но их алгоритмы
195
объединения достаточно слабы и поэтому с ними сложно держать все
196
синхронизировано. Bazaar_ отслеживает что уже было объединено и может даже
197
прикладывать изменения к файлам которые были переименованы.
200
Создание и работа на новой ветке
201
--------------------------------
203
Мы бы хотели, что бы наши изменения были доступны другим даже если они
204
пока еще не закончены. Таким образом мы создадим новую публичную ветку на
205
``centralhost`` и будем отслеживать ее локально.
210
% bzr branch sftp://centralhost/srv/bzr/sigil \
211
sftp://centralhost/srv/bzr/sigil/doodle-fixes
212
% bzr checkout sftp://centralhost/srv/bzr/sigil/doodle-fixes doodle-fixes
215
Теперь у нас есть место где мы можем исправлять все ошибки для ``doodle``.
216
И мы не будем прерывать никого кто работает над другими частями кода. Так
217
как у нас есть рабочая копия (checkout) все фиксации которые мы делаем на
218
``~/work/sigil/doodle-fixes/`` так же появятся и на ``centralhost``.
219
[#nestedbranches]_ Также возможно, что бы два разработчика совместно
220
работали над одной из этих веток, так же как они совместно работают над
221
веткой ``dev``. [#cbranch]_
223
.. [#nestedbranches] Может показаться странным иметь ветку в подкаталоге
224
другой ветки. Но это нормально, можно думать об этом как о
225
иерархическом пространстве имен где вложенная ветка является
226
производной от внешней ветки.
228
.. [#cbranch] Когда используется множество независимых веток каждый раз
229
набирать полный URL занимает много времени. Мы рассматриваем различные
230
методы, что бы обойти это, например псевдонимы для веток и т.п. Но пока
231
плагин bzrtools_ предоставляет команду ``bzr cbranch``. Эта команда на
232
основе базовой ветки создает новую публичную ветку и рабочую копию этой
233
ветки всего одной командой. Конфигурирование ``cbranch`` не входит в
234
рамки описания этого документа, но финальная команда выглядит следующим
239
% bzr cbranch dev my-feature-branch
241
.. _bzrtools: http://wiki.bazaar.canonical.com/BzrTools
244
Объединение изменений обратно
245
-----------------------------
247
Когда решено что некоторые изменения из ``doodle-fixes`` готовы для
248
объединения на основную ветку нужно просто сделать следующее::
250
% cd ~/work/sigil/dev
251
% bzr merge ../doodle-fixes
253
Теперь изменения доступны на ветке ``dev``, но они пока еще не были
254
зафиксированы. В этот момент нужно просмотреть финальные изменения и
255
проверить, что код компилируется и проходят все тесты. Команды ``bzr
256
status`` и ``bzr diff`` хорошие инструменты для этого. Так же нужно
257
разрешить возможные конфликты. Bazaar_ не допустит фиксации пока не будут
258
разрешены все конфликты. В этом случае вы случайно не зафиксируете маркеры
259
конфликта. Команда ``bzr status`` покажет конфликты и изменения, или можно
260
использовать ``bzr conflicts`` что бы увидеть только конфликты.
261
Используйте ``bzr resolve file/name``, или ``bzr resolve --all`` как
262
только конфликты были разрешены. [#resolve]_ Если существуют конфликты
263
которые особенно сложно разрешить можно использовать команду ``bzr
264
remerge``. Эта команда позволит использовать другие алгоритмы объединения
265
и также позволит увидеть строки оригинального кода (``--show-base``).
267
.. [#resolve] Некоторые системы позволяют разрешать конфликты как часть
268
процесса объединения. Мы обнаружили, что обычно проще разрешать
269
конфликты когда можно просматривать полное дерево, а не только
270
отдельные файлы. Это дает намного больше контекста и также позволяет
271
запускать тесты когда проблема будет решена.
274
Рекомендации по созданию веток
275
------------------------------
277
Один из часто используемых способов работы с набором веток - это дать
278
каждому разработчику свою собственную ветку и собственное место для работы
279
на центральном сервере. Это можно сделать так::
281
% bzr branch sftp://centralhost/srv/bzr/sigil \
282
sftp://centralhost/srv/bzr/sigil/user-a
283
% bzr branch sftp://centralhost/srv/bzr/sigil \
284
sftp://centralhost/srv/bzr/sigil/user-b
286
Это дает каждому разработчику собственную ветку для работы. И они смогут
287
легко создать новые ветки с помощью [#cbranch]_
290
% bzr branch sftp://centralhost/srv/bzr/sigil/user-a \
291
sftp://centralhost/srv/bzr/sigil/user-a/feature
293
% bzr checkout sftp://centralhost/srv/bzr/sigil/user-a/feature myfeature
299
Разделяемый репозиторий
300
-----------------------
302
Bazaar_ поддерживает концепцию "Разделяемый репозиторий". Эта концепция
303
похожа на традиционные концепции репозиториев в других системах контроля
304
версий, таких как CVS, или Subversion. Например, в Subversion у вас есть
305
удаленный репозиторий, где хранится вся история и локально история не
306
хранится, а хранится только рабочая копия файлов. Конечно "Разделяемый" в
307
данном контексте значит, что он разделен между ветками. Он *может* быть
308
разделен между людьми, но отдельные ветки также могут быть разделены между
311
В Bazaar_ термин "Разделяемый репозиторий" - это место где несколько веток
312
могут *разделять* их историю ревизий. Что бы поддерживать
313
децентрализованную схему работы каждая ветка может хранить свою
314
собственную историю ревизий. Но часто это не эффективно, т.к. зависимые
315
ветки разделяют историю и они могут так же разделять и хранилище истории.
319
vim: tw=74 ft=rst spell spelllang=en_us
added
removed
doc/ru/tutorials/centralized_workflow.txt
