Лучшие практики для того, чтобы разработать и пользоваться общими библиотеками в управлении версиями?
Из того, что я вижу от специфических особенностей центра программного обеспечения, баннер выставки является просто средством продвинуть программное обеспечение или набор программного обеспечения. Баннеры, кажется, не рекламное пространство, и при этом разработчики не платят, чтобы показать их программное обеспечение там. Просто, центр программного обеспечения devs просто продвигает часть программного обеспечения с самым высоким рейтингом, доступного через центр программного обеспечения.
Read больше о баннерах выставки:
7 ответов
Как уже упоминалось другими, внешние элементы SVN - хороший способ сделать это. Через них вы можете ссылаться на другие части вашего репозитория (или другие репозитории, FTM). Проект может ссылаться на заголовок другого (библиотечного) проекта, ветки или тега. Последние два обеспечивают стабильность, а первый - постоянное обновление библиотеки.
Я видел различные схемы в этом направлении с использованием CVS (здесь нет внешних элементов, так что это были зарегистрированные скрипты, которые необходимо было выполнить) и SVN. В компании, в которой я сейчас работаю, у нас есть разные папки верхнего уровня для проектов и общих библиотек. Проекты могут ссылаться на библиотеки. В стволе проекта эти внешние ссылки обычно относятся к головкам библиотек, в тегах и ветвях проекты относятся к тегам библиотек (или, иногда ветки).
При использовании Subversion я бы использовал svn: externals , которые позволяют создавать зависимости одного репозитория Subversion от другого.
Да.
Разделяйте многократно используемые «подбиблиотеки» в отдельные проекты на раннем этапе и часто.
Посмотрите на методы с открытым исходным кодом: большинство вещей - это множество небольших проектов, которые собраны вместе.
Создавайте множество небольших проектов.
Избегайте проверки двоичных файлов. Опять же, следуйте практике открытого исходного кода. Сохранять исходный код в Subversion.
Скомпилировать двоичные файлы и поместить их в каталог «общего ресурса проекта» отдельно от исходного кода.
Subversion позволяет вам иметь ссылки на другие пути с помощью свойства svn: externals .
Тем не менее, часто вам может понадобиться немного больший контроль над состоянием проекта, чем просто «взять все, что находится в заголовке разделяемой библиотеки». В этом случае я бы предложил передать скомпилированный двоичный файл библиотеки в каждый из других проектов, которые его используют. Таким образом, у вас есть контроль над развертыванием библиотеки для каждого из ее клиентов.
Мы храним код из общих библиотек в SVN в их собственных папках проекта. Мы также фиксируем двоичные файлы в другой папке «проекта» под названием Dependencies. Мы используем svn: externals для добавления необходимых ссылок в проекты.
Правильный инструмент для решения этой проблемы - Maven . Первоначально разработанный для Java, он может использоваться для любого существующего языка программирования.
Maven создает на вашем компьютере репозиторий, в котором находятся все модули. Вы также можете создать публичный репозиторий модулей, позволяющий другим людям загружать модули оттуда.
Каждый модуль имеет список зависимостей, которые автоматически разрешаются (считываются загруженными). На этапе сборки проекта соответствующий плагин для вашего языка программирования поместит все зависимости в определенные места, чтобы исходный код видел их.
Maven - отличный многофункциональный инструмент, но его очень сложно освоить, это только минус.
Я даже не понимаю вопроса. Если foo зависит от libbar, почему вы хотите сохранить исходный код для libbar в VCS foo? Вы связываете с libbar или импортируете модуль bar, если это подходит для языка. Зачем вам путать дерево исходных кодов для вашего проекта? Привет, мир! проект зависит от libc. Как и мое "привет, Долли!" проект. Ни один из проектов не хранит исходный код libc в своей кодовой базе. Это было бы безумием. Почему в этом отношении внутренние библиотеки обрабатываются иначе, чем сторонние библиотеки? Короче говоря, лучшая практика: не делайте этого. Если в вашей библиотеке есть исправления, которые необходимо распространить на ваши проекты, используйте динамическую компоновку.