Как вы храните сторонние библиотеки в вашей системе контроля версий?

Question

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

Когда вы будете хранить бинарные файлы в вашем контроле исходного кода?

Когда бы вы сохранили код в вашем контроле исходного кода?

Будешь ли ты хранить оба? В каких ситуациях вы бы это сделали?

(Кстати, я использую .NET, но для этого вопроса это не имеет значения)

Answer 1

Об исходном коде и скомпилированных библиотеках (скорее всего, автономных):

Если я не использую сторонние компоненты (скомпилированные библиотеки) или предоставленный исходный код для создания собственных программных компонентов, я просто беру их с полки и устанавливаю их в соответствии с предписаниями (которые могут включать в себя код компиляции, pl / sql пример). Я бы не стал устанавливать их в репозитории для управления зависимостями или в любой системе контроля версий по той простой причине, что я не хочу, чтобы они были включены случайно или иным образом в компоненты, которые я создаю, и я не хочу отслеживать их в любом программном цикле. Это актив (программный актив), который следует отслеживать с помощью других инструментов. Если я не использую их для разработки программного обеспечения, я не вижу и не должен видеть их в инструментах, которые я использую для разработки программного обеспечения.

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

Answer 2

Когда вы будете хранить двоичные файлы в вашем контроле исходного кода?

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

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

Answer 3

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

Редактировать: О, и я называю мой "BinRef":)

Answer 4

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

Answer 5

Концептуально вам нужно хранить как минимум двоичные файлы (и заголовки, если вы делаете C / C ++) Это обычно единственный способ для сторонних библиотек, где у вас нет исходного кода.

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