13 521
правка
Изменения
→Схема управления рабочими копиями
Вторая идея — это '''''идея 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'' сразу следует определённое неудобство: при синхронизации '''меняется история''' твоей веток (даже твоей, любимой, неприкосновенной) ветки — — ревизии, внесённые ранее локально, могут быть перемещены в «под-узлы» ревизии-объединения, которую в свою ветку внесла удалённая сторона. А История меняется так, чтобы в конечном счёте история всех веток выглядела одинаково. То есть, «история истории» теряется, а ещё из перестановок ревизий в истории сразу следуют проблемы работы с Subversion.
Короче говоря, да, это просто очередной «хардкод». То ли — рассчитанный на то, что если дать людям свободу, они не будут в состоянии достаточно часто объединяться с основной веткой, то ли — просто унаследованный от Arch’а ([[wikipedia:GNU Arch|GNU Arch]] — прародитель Bazaar’а).
