Лучшие практики для разработки и использования общих библиотек в управлении версиями?

Question

Мне всегда было интересно, как активно разработанная общая библиотека, используемая в двух или более проектах, должна храниться в системе контроля версий. Я полагаю, что он может обрабатываться не так, как сторонняя библиотека, поскольку внутренняя библиотека с большей вероятностью получит оперативные исправления, которые следует распространить на многие проекты в системе управления версиями.

Должны ли его двоичные файлы быть импортированы в проекты, которые используют его при обновлении (почти как сторонняя библиотека), или его исходный код может быть извлечен вместе с проектами? Можно ли иметь ссылки на другие пути с контролем версий в Subversion или других системах контроля версий?

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

Answer 1

Как уже упоминали другие, Внешние SVN являются хорошим способом сделать это. Через них вы можете ссылаться на другие части вашего репозитория (или другие репозитории тоже FTM). Проект может ссылаться на руководителя какого-либо другого (библиотечного) проекта или какой-либо ветви или тега. Последние два обеспечивают стабильность, а первый всегда актуален с библиотекой.

Я видел различные схемы в этом направлении, использующие CVS (здесь нет никаких внешних ссылок, так что это были проверенные сценарии, которые должны были быть выполнены) и SVN. В компании, с которой я сейчас работаю, у нас есть разные папки верхнего уровня для проектов и общих библиотек. Проекты могут ссылаться на библиотеки. В стволе проекта эти внешние ссылки обычно относятся к головкам библиотек, а теги и ветви проектов ссылаются на теги библиотек (или, иногда, ветви).

Answer 2

Я даже не понимаю вопроса. Если foo зависит от libbar, почему вы хотите сохранить исходный код libbar в VCS foo? Вы ссылаетесь на libbar или импортируете модуль bar, если это соответствует языку. Почему вы хотите запутать исходное дерево для вашего проекта? Привет, мир! Проект зависит от libc. Как и мое "привет, Долли!" проект. Ни один из проектов не сохраняет исходный код libc в своей базе кода Это было бы безумно. Почему в этом отношении внутренние библиотеки отличаются от сторонних библиотек? Короче говоря, лучшая практика: не делай этого. Если в вашей библиотеке есть исправления, которые необходимо распространить на ваши проекты, используйте динамическое связывание.

Answer 3

Мы храним код из общих библиотек в SVN в собственных папках проекта. Мы также передаем двоичные файлы в другую папку проекта, которая называется «Зависимости». Мы используем svn: externals для добавления необходимых ссылок в проекты.

Answer 4

Правильный инструмент для решения этой проблемы - Maven . Первоначально разработанный для Java, он может использоваться для любого существующего языка программирования.

Maven создает репозиторий на вашем компьютере, где находятся все модули. Вы также можете создать общедоступный репозиторий модулей, позволяя другим людям загружать модули оттуда.

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

Maven - отличный многофункциональный инструмент, но освоить его очень сложно, это всего лишь минус.

Answer 5

Да.

Разделять многократно используемые "библиотеки" на отдельные проекты рано и часто.

Посмотрите на практики с открытым исходным кодом: большинство вещей - это множество небольших проектов, которые объединены.

Создайте много маленьких проектов.

Избегайте проверки в двоичных файлах. Опять же, следуйте практикам с открытым исходным кодом. Держите источник в подрывной деятельности.

Создайте двоичные файлы и поместите их в каталог общей папки проекта отдельно от исходного кода.

Answer 6

Subversion позволяет вам иметь ссылки на другие пути, используя свойство svn: externals .

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

Answer 7

При использовании Subversion я бы использовал svn: externals , что позволит вам создавать зависимости одного репозитория Subversion от другого.