Я знаю, что многие магазины программного обеспечения держат двоичные файлы под контролем исходного кода . Однако наш магазин пришел для хранения целых фреймворков в репозитории: среда выполнения DirectX, CUDA, nVidia Optix, что угодно.
Говорят, что это облегчает настройку машины разработчика (предположительно, получите последнюю версию и начните писать код). Однако, это значительно раздувает хранилище и обременяет его несущественной историей.
Я никогда не видел такой шаблон использования. Считаете ли вы это хорошей практикой?
[EDIT:] У меня нет проблем с изолированными бинарными файлами сторонних разработчиков. Вопрос относится ко всем средам исполнения фреймворка, обычно состоящим из 10+ двоичных файлов. В качестве крайнего примера возьмем Windows SDK (который мы не храним в хранилище, слава богу, но я не вижу принципиальной разницы).
источник
Ответы:
Двоичные файлы обычно не подходят для системы контроля версий, потому что:
cd+rm!)источник
Я в порядке с управлением версиями бинарных активов. Я против контроля версий сгенерированных файлов.
Кроме того, настройка среды отличается от разработки. Мы в основном разрабатываем на Python, и у него есть инструмент под названием virtualenv, который позволяет вам создавать легкую изолированную среду (включая библиотеки) для проекта. Когда мы проверяем наши источники, у нас есть сценарий установки, который создает этот virtualenv. Используя манифест, это указывает, какие версии библиотек необходимы и другие подобные вещи. Ничто из этого не контролируется версией. Только установочный скрипт есть.
Бросив весь фреймворк под ваш главный проект, вы загромождаете вашу историю и серьезно портите вещи. Это не часть вашего проекта и должно рассматриваться по-другому.
источник
Как правило, хорошей идеей является управление конфигурацией с помощью версий фреймворка. Если вашему коду требуется определенная версия DirectX, эта версия должна быть легко доступна, и если вы извлекаете более старую версию своего программного обеспечения, должно быть легко определить, какие внешние зависимости у него есть.
То, что я не считаю хорошей идеей, это использовать вашу типичную систему управления версиями для хранения этих двоичных файлов. В нашей компании мы храним каждую версию фреймворков, библиотек и внешних инструментов в структуре подпапок на сетевом диске. Там, где мы думаем, что это имеет смысл, у нас есть файлы readme для документирования, какая версия инструмента принадлежит какой версии программного обеспечения, или, если возможно, у нас есть сценарии для установки или использования определенной версии. Только те файлы readme и скрипты попадают в систему контроля версий.
Мы также сохраняем более старые версии инструментов и библиотек, пока мы думаем, что у нас может быть шанс перестроить и более старую версию в зависимости от этих инструментов. Таким образом, это дает нам возможность удалять некоторые очень старые библиотеки и инструменты с нашего сетевого диска, когда они устарели (конечно, на случай, если у нас есть архивы на внешних носителях).
источник
Я думаю, что двоичные файлы должны быть где-то в магазинах. Я бы предложил хранить их вне репозитория, особенно если они большие и приводят к большому времени проверки. Я не собираюсь видеть, что это плохая практика, но это также не та, которую я видел.
Это может быть хорошей идеей, если в вашей организации много проектов, ориентированных на разные версии среды выполнения. Это гарантирует, что у вас есть правильный двоичный файл времени выполнения, когда вы работаете над правильными проектами.
источник
Я лично считаю это очень плохой практикой. Я предпочитаю настраивать вики с инструкциями по установке и загружать в нее необходимые двоичные файлы. Эти файлы нужны только новым разработчикам, нет необходимости раздувать репозитории всех остальных.
источник
Для этого есть веская причина: у вас есть все, что вам нужно, в одном месте, без каких-либо внешних зависимостей.
Это гораздо важнее, чем вы думаете. По сути, это гарантирует, что вы не будете полагаться на артефакт на сервере поставщика, который может исчезнуть через несколько лет, поскольку у вас есть все внутри.
Что касается хранилища наворотов. Это проблема, только если ваша VCS хранит полную локальную копию (это делает git, а cvs нет), поскольку клонирование и / или обновление будет медленным. В свою очередь, у вас будут копии на каждом компьютере разработчика, что может спасти вашу компанию, если однажды по какой-то причине ваша централизованная схема резервного копирования не будет выполнена.
Это вопрос приоритета или политики. Пока решение является обдуманным, я буду в порядке с этим.
источник