RUDE

Разработка библиотеки в распределенной системе контроля версий (базар)

Я относительно новичок в 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.


428
3

Ответы:

Решено

Разве вы не хотите, чтобы какие-либо новые библиотеки имели собственное решение и создавались как часть этого, а затем на них ссылались другие проекты. Таким образом, библиотека имеет только одну строящуюся версию (вместо одной для каждого решения).


В 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 ограничена.

А до тех пор поддерживайте библиотеку как отдельный проект в собственной красивой чистой «ветке». Если вам нужна библиотека, включенная в проект, например, если ее файлы находятся в собственном дереве проекта, скопируйте их. Если вы вносите какие-либо изменения в файлы в этой библиотеке, которые хотите вернуть в библиотеку, верните изменения в свою локальную ветвь этой библиотеки и выполните слияние / фиксацию там.