Управление ветками в '''Bazaar''' вначале было гораздо хуже: на 1 ветку ровно 1 рабочая копия и ровно 1 репозиторий. Однако потом появилось уникальное: <tt>checkout</tt>'ы и [http://bazaar-vcs.org/SharedRepositoryTutorial Shared Repository], имеющий опцию <tt>--no-trees</tt>. Таким образом, стало возможно иметь сколько угодно репозиториев и сколько угодно рабочих копий. В Git и Mercurial этого нет. Переключать легковесную рабочую копию с ветки на ветку Bazaar тоже умеет — командой <tt>switch</tt>, для переключения ветки её надо превратить в легковесную рабочую копию командой <tt>bind</tt>.
Однако есть и неудобстваТут надо сделать небольшое отступление: Bazaar имеет несколько идеологических моментов. Первый — это идея ''директории — не умеет переключиться на произвольную ревизию и какконтейнеры веток, напримера сами ветки''. В одной директории, Mercurialсодержащей рабочую копию, по коммиту автоматически ответвиться в сторонуне может содержаться нескольких веток. В Bazaar можно только сделать <tt>revert<Существуют ещё [http:/tt> («откат») к определённой версии/bazaar-vcs. Рабочие файлы при этом изменятсяorg/SharedRepositoryTutorial разделяемые репозитории], а «состояние» но они сами по себе не содержат рабочей копии — неткопии, а содержат директории, которые могут содержать рабочие копии.
Лично яИдея, по всей видимостис моей точки зрения, вообще против базаарадалеко не лучшая. Не Например, Bazaar не может, как Git и Mercurial, переключиться на произвольную ревизию и по причине каких-либо коммиту автоматически ответвиться в сторону. В Bazaar можно только сделать <tt>revert</tt> («откат») к определённой версии. Рабочие файлы при этом изменятся, а «состояние» рабочей копии — нет. Считается, что рабочая копия ''недоработоквсегда'', а по причине содержит последнюю сохранённую ревизию. Вторая идея — это ''идеи идея mainline''; того, что директории — то есть, идея поддержки «центральной» ветки разработки на уровне системы контроля версий. С хвалебной точки зрения про mainline можно почитать в блоге «Базарный день» (части [http://bzr-day.blogspot.com/2009/09/mainline-2.html 1], [http://bzr-day.blogspot.com/2009/09/mainline-2.html 2], и будут ещё). Я же выступлю с критической точки зрения — никакая это не контейнеры ветокгениальная практика, а сами ветки; показа отдельно «своих» и «чужих» ревизий просто ещё один хардкод, который можно выразить простыми словами: после синхронизации рабочих копий ''HEAD-ревизия'' (ревизия, не имеющая дочерних — в терминах Mercurial), ''всегда ровно одна''. Все другие ''HEAD’ы'' физически находятся в других ветках, ещё не синхронизированных с данной. То есть, Bazaar заставляет пользователя объединять историю при каждой синхронизации с другой веткой. Из ''идеи mainline'' следует сразу несколько неудобств: * При синхронизации нельзя просто взять и посмотреть, а что же поменялось в основной ветке, не занимаясь объединением; * При синхронизации ''все зафиксированные правки'' попадут в mainline. ''изменения Сделай неудачный мерж — и потери части историидо следующей синхронизации коммитить «полуготовую» работу не придётся.'' * При синхронизации меняется история твоей (плясок ревизийлюбимой, неприкосновенной) при объединенияхветки — ревизии, внесённые ранее локально, могут быть перемещены в «под-узлы» ревизии-объединения, которую в свою ветку внесла удалённая сторона. ИМХО — лучше показывать граф А из перестановок ревизий и ничего никуда не переставлятьв истории сразу следуют проблемы работы с Subversion. Короче говоря, только добавлять рёбрада — это просто очередной «хардкод». Особенно учитываяТо ли — рассчитанный на то, что базаар если дать им свободу, люди будут не в нутрях всё равно работает состоянии достаточно часто объединяться с графами основной веткой, то ли — просто унаследованный от Arch’а (а как ещё?[[wikipedia:GNU Arch|GNU Arch]] — прародитель Bazaar’а). А И если уж зашла речь о недостатках Bazaar’а, ещё следует отметить, что он не умеет показывать консольные ASCII-псевдографические графы ревизий, причём . Git и Mercurial умеют — и это очень удобно. А разработчики Bazaar считают это их отсутствие фичей — ревизии, типа, сортируются, зачем графы не нужны. ? ''(и правда, зачем? стройте графы сами, в голове! разве вы так как это — не умеете?)''
[[Категория:Разработка]]