Хранение сторонних библиотек в системе контроля версий

Question

Должны ли библиотеки, на которые опирается приложение, храниться в системе контроля версий? Одна часть меня говорит, что это должно, а другая часть говорит «нет». Неправильно добавлять библиотеку в 20 Мб, которая затмевает все приложение только потому, что вы полагаетесь на несколько функций из него (хотя и довольно сильно). Стоит ли просто хранить jar / dll или, может быть, даже распределенный zip / tar проекта?

Что делают другие люди?

Answer 1

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

Answer 2

Храните сторонние библиотеки в системе контроля версий, чтобы они были доступны, если вы проверяете свой код в новой среде разработки. Любые команды «include» или build, которые могут быть в сценариях сборки, также должны ссылаться на эти «локальные» копии.

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

Лично я получил результаты, которые мне до сих пор нравились, - хранить библиотеки в отдельном репозитории, а затем ссылаться на каждую библиотеку, которая мне нужна в других моих репозиториях, с помощью функции Subversion svn: externals. Это хорошо работает, потому что я могу хранить версионные копии большинства наших библиотек (в основном управляемых сборок .NET) в системе контроля версий, не увеличивая при этом размер нашего основного хранилища исходного кода. Хранение сборок, хранящихся в репозитории таким образом, позволяет серверу сборки не устанавливать их для сборки. Я скажу, что получить успешную сборку в отсутствие установленной Visual Studio было довольно непросто, но теперь, когда она заработала, мы довольны.

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

Answer 6

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

Answer 7

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

(и, как человек, который испытал боль - пожалуйста, сохраните копию всего, что нужно для установки элементов управления и работы на платформе dev. Однажды я получил проект, который можно было собрать, но без установочного файла и ключей reg Вы не можете вносить изменения в сторонний макет управления. Это было забавно переписать)