Изменения

Идея, с моей точки зрения, далеко не лучшая. Например, из-за неё Bazaar не может, как Git и Mercurial, переключиться на произвольную ревизию и по коммиту автоматически ответвиться в сторону. В Bazaar можно только сделать <tt>revert</tt> («откат») к определённой версии. Рабочие файлы при этом изменятся, а «состояние» рабочей копии — нет. Считается, что рабочая копия ''всегда'' содержит последнюю сохранённую ревизию.

Вторая идея — это '''''идея mainline''''', то есть, идея поддержки «центральной» ветки разработки на уровне системы контроля версий. С хвалебной точки зрения про mainline можно почитать в блоге «Базарный день» (части [http://bzr-day.blogspot.com/2009/09/mainline-1.html 1], [http://bzr-day.blogspot.com/2009/09/mainline-2.html 2], и будут ещё). Я же выступлю с критической точки зрения — никакая это не гениальная практика, а просто ещё один хардкод, который можно выразить простыми словами: после синхронизации рабочих копий ''HEAD-ревизия'' (ревизия, не имеющая дочерних — в терминах Mercurial), ''всегда ровно одна''. Все другие ''HEAD’ы'' физически находятся в других директориях (= ветках), ещё не синхронизированных с данной. То есть, Bazaar заставляет пользователя объединять историю при каждой синхронизации с другой веткой.

Из ''идеи mainline'' сразу следует сразу несколько неудобствопределённое неудобство: * При синхронизации нельзя просто взять и посмотреть, а что же поменялось в основной ветке, не занимаясь объединением.* При при синхронизации ''все зафиксированные правки'меняется история' попадут в mainline. ''Неудачно обновись — и до следующей синхронизации коммитить «полуготовую» работу не придётся.''* При синхронизации меняется история твоей (любимой, неприкосновенной) ветки — ревизии, внесённые ранее локально, могут быть перемещены в «под-узлы» ревизии-объединения, которую в свою ветку внесла удалённая сторона. А из перестановок ревизий в истории сразу следуют проблемы работы с Subversion.