Я относительно новичок в bazaar (в основном использовал cvs, затем subversion, а на моей текущей работе мы используем SourceUnsafe). Моя текущая среда разработки структурирована следующим образом:
\dev (shared repository) \trunk \project1 (branch) \project2 (branch) \branches \proj1-bugfix123 (branch of \trunk\project1) \proj1-featureA (branch of \trunk\project1)
Теперь, если я решу, что определенные аспекты project1 лучше подходят в качестве библиотеки (или сборки, поскольку это проект C#), а не классов внутри проекта, что было бы лучшим подходом для структурирования этого на базаре. я придумал две возможности, которые я считаю жизнеспособными. Первый, на мой взгляд, «правильный» путь.
\dev (shared repository) \trunk \project1 (branch) \project2 (branch) \libXXX \branches \proj1-bugfix123 \main (branch of \trunk\project1) \libXXX (branch of \trunk\libXXX) \proj1-featureA \main (branch of \trunk\project1) \libXXX (branch of \trunk\libXXX)
Проблема заключается в том, что теперь мне нужно не забыть обновлять файл решения, чтобы включать нужные проекты всякий раз, когда я делаю ветку, и не возвращать их, а также не забывать возвращать изменения как в проект, так и в библиотеку одновременно time (например, если featureA в project1 требует для работы изменений в libXXX).
\dev (shared repository) \trunk \project1 (branch) \project2 (branch) \libXXX \branches \proj1-bugfix123 (branch of \trunk\project1) \libXXX \proj1-featureA (branch of \trunk\project1) \libXXX
Проблемы с этим подходом заключаются в том, что если другой проект, скажем, project3, хочет использовать libXXX и находится в системе управления версиями, он должен быть ответвлением от project1 с удаленными файлами project1. Было бы грязно.
Я предполагаю, что есть третий вариант, когда весь ствол будет ветвью, как в Subversion, но это, похоже, противоречит тому, как, как я думаю, они должны работать на базаре.
Если бы это было сделано в SourceSafe, я бы просто сделал это, как во втором примере, но имел бы папки libxxx в обоих местах, но общие, поскольку это единственный механизм, в котором должен это сделать sourceafe.
Разве вы не хотите, чтобы какие-либо новые библиотеки имели собственное решение и создавались как часть этого, а затем на них ссылались другие проекты. Таким образом, библиотека имеет только одну строящуюся версию (вместо одной для каждого решения).
В bzr пока нет простого решения. Вам нужна поддержка вложенных деревьев, но она еще не реализована (http://bazaar-vcs.org/NestedTreeSupport), но, возможно, скоро появится.
Есть старый инструмент под названием config-manager (https://launchpad.net/config-manager).
Также есть новый плагин для bzr под названием scmproj (https://launchpad.net/bzr-scmproj), сейчас он альфа и находится в активной разработке.
Пока поддержка вложенных деревьев в Bazaar не будет исправлена или Bazaar не разработает что-то вроде Subversion 'Externals' (если я правильно их понимаю), ваша гибкость при включении библиотек в дерево ветки Bazaar ограничена.
А до тех пор поддерживайте библиотеку как отдельный проект в собственной красивой чистой «ветке». Если вам нужна библиотека, включенная в проект, например, если ее файлы находятся в собственном дереве проекта, скопируйте их. Если вы вносите какие-либо изменения в файлы в этой библиотеке, которые хотите вернуть в библиотеку, верните изменения в свою локальную ветвь этой библиотеки и выполните слияние / фиксацию там.