Это зависит от того, что вы понимаете под «проблемой». Некоторые люди работают с bzr в повседневной жизни и никогда не сталкивались с какими-либо проблемами, которые делают их работу невозможной или очень сложной. Это не значит, что в bzr нет странных особенностей или причуд. Это означает, что вы можете комфортно работать с bzr, если понимаете, что делаете.
В целом, bzr очень приятен для работы с VCS, но для его эффективного использования лучше знать свои ограничения.
Если вы начнете работать с bzr, вы должны понять, в чем разница между веткой, репозиторием, общим репозиторием и рабочим деревом. Как общий репозиторий помогает вам в вашей работе и как сохранить в нем ветки. Вы должны понимать разницу между простой веткой и оформлением заказа. Если вы хотите продолжить работу в стиле CVS, возможно, вы захотите использовать упрощенные проверки - это прямой аналог проверки CVS и локального рабочего пространства на вашем компьютере.
С bzr вам может быть немного неясно, как настроить центральный сервер и установить надлежащие права доступа для всех членов вашей команды. Конечно, это выполнимо, и в официальной документации есть несколько примеров. Но для правильного ACL потребуется большая помощь * -nix ssh tools.
Вы должны понимать, что с bzr самый простой способ сослаться на какую-либо ревизию - это использовать ее номер ревизии. Но вы должны знать, что этот номер специфичен для конкретной ветви, и разные ветви могут иметь одинаковое число N, относящееся к разным ревизиям. Поэтому иногда вам необходимо использовать уникальный идентификатор ревизии, который присутствует в bzr, но этот идентификатор ревизии не является способом по умолчанию для связи с bzr, потому что он длинный и его нельзя легко сократить до 8 или около того символов, как в git / hg. Номера редакций определяются концепцией магистрали, см. Ниже.
По состоянию на январь 2012 года вы можете соблюдать следующие ограничения.
С bzr вы будете вынуждены использовать основную концепцию истории. То есть левый родитель ревизии является особенным и формирует основную линию вашей истории, в то время как ваши объединенные ревизии составляют объединенную историю. Консоль bzr log по умолчанию показывает историю основной линии, потому что отображение полной истории с объединенными ревизиями может быть немного медленнее для действительно большой истории.
С bzr у вас не будет поддержки копий файлов, то есть нового файла, который продолжает историю существующего файла.
С bzr у вас не будет поддержки CVS-модулей как основной функции. Но его можно эмулировать, используя специальные плагины (см. Bzr-externals или scmproj), чтобы выполнить эту большую конфигурацию проекта за вас.
Список не полный, но именно это время от времени влияет на меня лично как на давнего пользователя bzr.
И последнее замечание. Основная проблема с bzr: почти все, кто использует git или hg, будут спрашивать вас каждый раз: «Почему вы выбрали Bazaar, когда все парни в их компании используют git (или hg)».
Правда в том, что git явно победил по состоянию на январь 2012 года среди других DVCS (git, hg, bzr и т. Д.), Если вы посчитаете, сколько проектов размещено на GitHub. И не только потому, что Git превосходит, но и потому, что GitHub также хорош.
(Примечание для пользователей git: я уважаю git, но использую bzr как свой собственный выбор. Не объясните мне, почему вы считаете, что git хорош, пожалуйста).