13 531
правка
Изменения
→Схема управления рабочими копиями
Управление ветками в '''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 имеет несколько идеологических моментов. Первый — это идея , гласящая, что '''''директории — не контейнеры веток, а сами ветки'''''. В одной директории, содержащей рабочую копию, не может содержаться нескольких веток. Существуют ещё [http://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’а'''Bazaar'''’а, ещё следует отметить, что он не умеет показывать консольные ASCII-псевдографические графы ревизий. '''Git ''' и '''Mercurial ''' умеют — и это очень удобно. А разработчики Bazaar считают их отсутствие фичей — ревизии, типа, сортируются, зачем графы? ''(и правда, зачем? стройте графы сами, в голове! как это — не умеете?!!)''
[[Категория:Разработка]]