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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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