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

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

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

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

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

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

@Stu Thompson упоминает о хранении документации и т. Д. В системе контроля версий. В более крупных проектах я хранил всю нашу папку «клиенты» в системе контроля версий, включая счета / счета / протоколы встреч / технические спецификации и т. Д. Весь матч по съемкам. Хотя, кхм, не забудьте хранить их в ОТДЕЛЬНОМ репозитории от того, который вы будете делать доступным: другим разработчикам; клиент; ваш "просмотр исходного кода браузера" ... кашля ... :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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