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

Question

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

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

Answer 1

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

Изменить на 2017 год: Этот ответ не очень хорошо стареет :-). Если вы по-прежнему используете что-то старое, например, ant или make, вышеупомянутое применимо. Если вы используете что-то более современное, такое как maven или graddle (или Nuget на .net, например), с управлением зависимостями, вы должны запустить сервер управления зависимостями в дополнение к вашему серверу контроля версий. Пока у вас есть хорошие резервные копии обоих, и ваш сервер управления зависимостями не удаляет старые зависимости, вы должны быть в порядке. Пример сервера управления зависимостями см., Например, Sonatype Nexus или JFrog Artifcatory , среди многих других.

Answer 2

Помимо наличия сторонних библиотек в вашем репозитории, стоит делать это таким образом, чтобы было легко отслеживать и объединять будущие обновления библиотеки (например, исправления безопасности и т. Д.). Если вы используете Subversion, стоит использовать правильную ветку vendor .

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

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

@ Стю Томпсон упоминает хранение документации и т. Д. В системе контроля версий. В более крупных проектах я сохранял всю нашу папку «клиенты» в системе контроля версий, включая счета-фактуры / счета / протоколы совещаний / технические характеристики и т. Д. Весь матч по стрельбе. Хотя, хм, не забудьте сохранить их в отдельном репозитории, который вы сделаете доступным для: других разработчиков; клиент; ваш "вид из браузера" ... кашель ...:)

Answer 3

Не храните библиотеки; они не являются строго говоря частью вашего проекта и бесполезно занимают место в вашей системе контроля версий. Однако используйте maven (или Ivy для сборок ant), чтобы отслеживать, какие версии внешних библиотек использует ваш проект. Вы должны запустить зеркало репо в вашей организации (которое резервируется), чтобы убедиться, что у вас всегда есть зависимости под вашим контролем. Это должно дать вам лучшее из обоих миров; внешние банки вне вашего проекта, но все еще надежно доступные и централизованно доступные.

Answer 4

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

Answer 5

никогда не сохраняйте ваши сторонние бинарные файлы в системе контроля версий. Системы контроля версий - это платформы, которые поддерживают одновременный обмен файлами, параллельную работу, объединение усилий и историю изменений. Контроль версий не является FTP-сайтом для двоичных файлов. Сторонние сборки НЕ являются исходным кодом; они меняются, может быть, дважды за SDLC. Желание очистить рабочее пространство, вытащить все из системы контроля версий и сборки не означает, что сторонние сборки нужно застревать в системе контроля версий. Вы можете использовать сценарии сборки для управления извлечением сторонних сборок с сервера распространения. Если вас беспокоит контроль над тем, какая ветвь / версия вашего приложения использует конкретный сторонний компонент, вы можете также контролировать это с помощью скриптов сборки. Люди упоминали Maven для Java, и вы можете сделать что-то подобное с MSBuild для .Net.

Answer 6

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

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

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

Answer 7

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

1. зачем хранить файлы, которые не изменяются, в системе, специально предназначенной для управления файлами, которые меняются?
2. это резко закрепить кассы
3. каждый раз, когда я вижу «что-то.jar», хранящееся под контролем исходного кода, я спрашиваю «а какая это версия?»

Answer 8

Я поместил все, кроме JDK и IDE, в систему контроля версий.

Философия Тони - это звук. Не забудьте сценарии создания базы данных и сценарии обновления структуры данных. До выхода вики я даже хранили нашу документацию в системе контроля версий.

Answer 9

Я предпочитаю хранить сторонние библиотеки в репозитории зависимостей (например, Artifactory с Maven ), а не хранить их в Subversion.

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

Answer 10

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