Как вы храните сторонние библиотеки в вашей системе контроля версий?

Question

Как вы храните сторонние библиотеки, которые используете в своем проекте, в вашем контроле исходного кода?

Когда вы будете хранить бинарные файлы в вашем контроле исходного кода?

Когда бы вы сохранили код в вашем контроле исходного кода?

Будешь ли ты хранить оба? В каких ситуациях вы бы это сделали?

(Кстати, я использую .NET, но для этого вопроса это не имеет значения)

Answer 1

• Как: a ветка поставщика , как правило, хороший подход

• Когда (третьи стороны) : для минимизации количества задействованных ссылок: вы можете добавить эти библиотеки в отдельную внешнюю ссылку (например, Maven), но это означает, что вам нужен доступ к этой дополнительной ссылке для каждой вашей среды (разработка - интеграция - омологация - подготовка производства - производство)

• Когда (код) : для управления сложностью изменений, когда вы знаете, что необходимы обновления и исправления для текущих версий, запущенных в производство , в то время как новые разработки в процессе.

• Почему (сохраните оба) : для развертывание причина: вы можете управлять полной конфигурацией (список элементов вам нужно) в одной ссылке и запросить его, где и когда вам нужно для:

  • разработка (вы запрашиваете, что вам нужно для разработки и исполнения вашего кода, включая сторонние компоненты, необходимые для компиляции / выполнения)
  • тесты (интеграция, омологация): вы запрашиваете точные теги, которые хотите обновить в своем рабочем пространстве тестирования, с помощью
  • производство: вы точно указываете, что идет в производство из одного источника: вашего SCM.

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

Почему это важно?
Потому что, в конце концов, то, что будет запущено в производство, - это упакованная версия вашего продукта, а не ваш "перекомпилированный исходный код". Следовательно, важно сделать все ваши тесты с целевой конечной формой вашего продукта, четко сохраненной и помеченной в вашем SCM.

---

Мартин Лазар поднимает законную точку в своем ответе

Контроль источника называется контролем источника, поскольку предполагается, что он управляет источниками.

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

Плюс, что позволяет некоторым из этих SCM предлагать функцию S "C" M (как в Источник Конфигурация Управление ).
Эта SCM (конфигурация) хранит не только «набор файлов», но также их отношения (или зависимости ) между этими наборами, чтобы вы могли запросить один набор файл и «вытягивать» все остальные поставки, от которых зависит этот набор (для сборки, развертывания или запуска)

Answer 2

Как вы храните сторонние библиотеки, которые используете в своем проекте, в вашем контроле исходного кода?

как двоичный файл или источник, или оба. Зависит от библиотеки.

Когда вы будете хранить бинарные файлы в вашем контроле исходного кода?

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

Когда бы вы сохранили код в вашем контроле исходного кода?

Скажем, мы используем внутреннюю библиотеку A, но исправили некоторую ошибку, специфичную для продукта X. Тогда хранилище продукта X сохранит источник и создаст его.

Вы бы когда-нибудь хранили оба? В каких ситуациях вы бы это сделали?

Да, все последние двоичные файлы хранятся в системе контроля версий.

Итак, дерево выглядит так:

продукт

 |-- src

 |-- build

 |-- lib

       |- 3rdparty

       |- internal

...

Answer 3

Контроль источника называется контролем источника, потому что он должен управлять источниками.

В Java обычно используется некоторая система управления версиями для хранения источников и других ресурсов, таких как файлы конфигурации XML или изображения, а затем используется какой-либо инструмент управления зависимостями, например Apache Maven, который будет хранить, загружать и управлять зависимостями вашего проекта от Сторонние библиотеки. Затем, когда вы переустанавливаете свою ОС, Maven может автоматически загружать ваши зависимости из центрального репозитория (или из ваших собственных частных репозиториев) и сохранять их в локальном кэше на вашем диске. Вам даже не нужно знать, где находится кеш:)

Maven может также использоваться с другими языками, и, насколько я знаю, плагины для .net и C / C ++ доступны, но я не использовал его ни с чем, кроме Java.

Answer 4

Если вы используете .Net:

Я создаю папку «Библиотеки» в моем проекте и в управлении исходным кодом, которая содержит любые сторонние сборки.

Затем мое решение ссылается на эти сборки, и мой процесс сборки перетаскивает эту папку на наш сервер сборки.

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

Answer 5

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

Answer 6

В недавнем Java-проекте я переключился на использование Maven - это было довольно приятно, поскольку это означало, что мне не нужно было хранить какие-либо сторонние файлы jar в каталоге lib /. Во время компиляции Maven будет вытягивать зависимости. Одним из приятных побочных эффектов является то, что банки имеют номер версии в имени файла.

Answer 7

Если вы используете git (который я рекомендую) и у вас есть источник сторонней библиотеки, то отличная установка - сохранить библиотеку в собственном хранилище git и включить ее в качестве подмодуля.

• http://book.git -scm.com / 5_submodules.html
• http://git -scm.com / Docs / ГИТ-подмодуль

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

Подмодули Git позволяют указать, какая версия библиотеки требуется для проекта, что отлично подходит для обеспечения совместимости.

Answer 8

Вообще говоря, я бы сделал примерно то, что было предписано другими пользователями.

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

Это было особенно приятно для меня при разработке PHP / JS, так как нет проблем с хранением двоичных файлов. Я бы оставил внешний вид Zend Framework, Doctrine ORM и jQuery в папке / lib / проекта. Каждое обновление дало бы мне полную обновленную копию всех необходимых файлов без какой-либо дополнительной работы, кроме добавления этого URL-адреса хранилища в свойство svn.

Answer 9

Вам не нужно хранить сторонние библиотеки в вашем репозитории контроля версий. Эти библиотеки (например, SDL, libcurl и т. Д.) Всегда должны быть доступны в Интернете.
Всего две raccomandations:

• не забудьте четко указать в своем коде, какую версию библиотеки следует компилировать
• убедитесь, что эта конкретная версия всегда доступна в Интернете

Answer 10

Мой опыт заключается в создании папки "lib" и хранении всех сторонних двоичных файлов. Я создам совершенно отдельное дерево для Исходного кода для этих третьих сторон, если оно доступно.

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