Как вы храните библиотеки сторонних разработчиков, которые вы используете в своем проекте, в своем исходном элементе управления?
Когда вы будете хранить двоичные файлы в своем исходном элементе управления?
Когда вы будете хранить код в своем исходном элементе управления?
Вы бы сохранили оба? В каких ситуациях вы это сделаете?
(Btw, я использую .NET, но на этот вопрос это не имеет особого значения)
Как: a ветвь поставщика - это, как правило, хороший подход
Когда (третьи стороны): для минимизации числа связанных ссылок: вы можете добавить эти библиотеки в отдельный внешний референт (например, Maven), но это означает, что вам нужно получить доступ к этому дополнительному справочная информация для каждой вашей среды (разработка - интеграция - омологация - предварительная подготовка - производство)
Когда (код): для управления сложностью изменений, когда вы знаете, что обновления и исправления для текущих версий, запущенных в производство, понадобятся во время разработки новой разработки. p >
Зачем (хранить оба): для развертывание: вы можете управлять полной конфигурацией (список необходимых элементов) в одном референтном документе и запрашивать его где угодно и когда вам нужно:
Для тестовых и производственных сред, это также означает, что ваш собственный продукт (упакованный результат того, что вы строите) также должен войти в ваш SCM (только официальные выпуски, а не промежуточные, используемые внутри).
Если другие проекты зависят от вашего продукта, они будут создавать свой собственный проект против вашей упакованной версии, хранящейся в SCM, а не в отношении вашего исходного кода, который они каким-то образом перекомпилировали.
Почему это важно?
Потому что, в конце концов, то, что будет запущено в производстве, - это упакованная версия вашего продукта, а не ваш "исходный код, скомпилированный". Следовательно, важно сделать все ваши тесты с целевой конечной формой вашего продукта, четко сохранены и помечены в вашем SCM.
Мартин Лазар поднимает законную точку в его ответе
Контроль источника называется "источником", потому что он должен контролировать источники.
Хотя это, возможно, исторически верно, каждый текущий RCS развился в направлении SCM (Source Code Management), который не просто контролирует источники, но также управляет изменениями в документах, программах и другой информации, хранящейся в виде компьютерных файлов.
Затем двоичные файлы могут храниться (даже с двоичным дельта)
Плюс, что позволяет некоторым из этих SCM предлагать функцию S "C" M (как в Source Configuration Management).
Этот SCM (Конфигурация) не только хранит любые "набор файлов", но и их отношения (ака зависимости) между этими наборами, чтобы вы могли запросить один набор файлов и "вытащить" все другие поставки, на которых этот набор зависит от (для создания или развертывания или для запуска)
Предполагая, что вы используете .Net:
Я создаю папку "Библиотеки" в моем проекте и исходном элементе управления, который содержит любые сторонние сборки.
Мое решение затем ссылается на эти сборки, и мой процесс сборки переносит эту папку на наш сервер сборки.
Любой, вытягивающий ваш код из исходного элемента управления, должен иметь возможность компилировать его без необходимости поиска ссылок и сборок.
Как вы храните библиотеки сторонних разработчиков, которые вы используете в своем проекте, в своем исходном элементе управления?
В качестве двоичного или исходного или обоих. Зависит от библиотеки.
Когда вы будете хранить двоичные файлы в своем исходном элементе управления?
Библиотека сторонних разработчиков, для которой у нас нет исходной или внутренней библиотеки, в которую мы не вносили никаких изменений, или библиотека слишком велика для создания.
Когда вы будете хранить код в своем исходном элементе управления?
Скажем, мы используем внутреннюю библиотеку A, но сделали ошибку, определенную для продукта X. Тогда хранилище продуктов X сохранит источник и построит его.
Вы бы сохранили оба? В каких ситуациях вы это сделаете?
Да, все последние двоичные файлы хранятся в исходном элементе управления.
Итак, дерево выглядит так:
продукт
|-- src
|-- build
|-- lib
|- 3rdparty
|- internal
...
Контроль источника называется "источником", потому что он должен контролировать источники.
В Java используется общий шаблон для использования некоторой системы управления версиями для хранения источников и других ресурсов, таких как файлы или изображения XML-конфигурации, а не для использования некоторого инструмента управления зависимостями, такого как Apache Maven, который будет хранить, загружать и управлять зависимостями проекта Сторонние библиотеки. Затем, когда вы переустанавливаете свою ОС, Maven может автоматически загружать ваши зависимости из центрального репозитория (или собственных собственных репозиториев) и хранить их в локальном кеше на вашем диске. Вам даже не нужно знать, где находится кеш:)
Maven можно также использовать с другими языками, и насколько я знаю, плагины для .net и C/С++ доступны, но я не использовал его ни с чем другим, кроме Java.
Я не ставил сторонний источник или двоичные файлы в SC. Мое обоснование состояло в том, что мне не нужно было обновлять SC только для обновления библиотек. Я начинаю сожалеть об этом. Когда мне пришлось воссоздать проект, я обнаружил, что бегаю искать источники lib, а не просто синхронизировать с SC.
В недавнем проекте Java я переключился на использование Maven - это было очень приятно, так как это означало, что мне не нужно было хранить какие-либо сторонние банки в каталоге lib/. Во время компиляции maven будет тянуть зависимости. Один приятный побочный эффект - это номер версии в имени файла.
Мой опыт состоял в том, чтобы создать папку "lib" и сохранить там все сторонние исполняемые файлы. Я создам полностью отдельное дерево для исходного кода для этих третьих сторон, если оно доступно.
В некоторых местах, где это может быть по-другому, вы используете открытый исходный код и розничную стороннюю сторону, с решениями с открытым исходным кодом. Я обычно включаю код в свои проекты и не проверяю двоичные файлы.
Вам не нужно хранить библиотеки сторонних производителей в репозитории управления версиями. Эти библиотеки (подумайте о SDL, libcurl и т.д.) Всегда должны быть доступны в Интернете.
Просто две raccomandations:
Вообще говоря, я бы сделал примерно то, что было предписано другими пользователями.
В случае Subversion, и я признаю, что не могу говорить о включении этой функции в случае других систем, можно использовать ссылку External для ссылки в репозитории, поддерживаемом в другом месте. В checkout/export вы получите полную копию источника, включая обновленный код из этого внешнего репозитория, за один раз.
Это было особенно приятно для меня с разработкой PHP/JS, так как нет проблемы с сохранением двоичных файлов. Я бы сохранил внешний вид Zend Framework, Doctrine ORM и jQuery в папке/lib/проекта. Каждое обновление дало бы мне полную, обновленную копию -все-необходимых файлов без дополнительной работы, чем добавление URL-адреса репозитория в свойство svn.
Если вы используете git (который я рекомендую), и у вас есть источник сторонней библиотеки, то сохранение библиотеки в своем собственном репозитории git и включение ее в качестве субмодуля - отличная настройка.
Если исходная библиотека также использует git, вы можете клонировать свою библиотеку и нажимать ее на свой собственный сервер, чтобы вы никогда не потеряли ее.
ПодкатегорииGit позволяют указать, какая версия библиотеки требуется для проекта, что отлично подходит для обеспечения совместимости.
Концептуально вам нужно сохранить как минимум двоичные файлы (и заголовки, если вы делаете C/С++) Это обычно единственный способ с сторонними библиотеками, в которых у вас нет источника.
Если у вас есть источник, вы можете выбрать сохранение источника и сборку сторонних библиотек в процессе сборки.
У вас должна быть возможность установить новую ОС, получить исходные данные из исходного кода, создать и запустить. Итак, да, вы должны поместить их в исходный контроль.
Это зависит от того, насколько они велики. Когда двоичные файлы или инсталляторы слишком велики, это может привести к хаосу для удаленных пользователей. Поверхность хранения двоичных файлов и инсталляторов заключается в том, что все, что разработчик должен запускать и запускать, находится в исходном управлении, а версии верны. Если у вас есть отдельное место установки, версии могут быть испорчены. Итак, в общем, мне нравится хранить небольшие или умеренные двоичные файлы в исходном контроле, но больше я не могу оставить.
Изменить: О, и я называю свой "BinRef":)
Когда вы будете хранить двоичные файлы в своем исходном элементе управления?
Я сохраняю двоичные файлы в исходном элементе управления, когда хочу, чтобы они могли быстро вернуться к старой версии приложения. Есть ряд причин, по которым я бы это сделал, включая следующие:
Исходный код и скомпилированные библиотеки (скорее всего, автономные):
Если я не использую сторонние компоненты (скомпилированные библиотеки) или предоставил источник для сборки встроенных компонентов программного обеспечения, я просто снимаю их с полки и устанавливаю их как предписано (которые могут включать компиляцию, код pl/sql для пример). Я бы не устанавливал их в репозитории управления зависимостями или в какой-либо системе управления версиями по той простой причине, что я не хочу, чтобы они были случайно или иначе включены в компоненты, которые я создаю, и я не хочу отслеживать их в любом программном цикле. Это актив (программный актив), который следует отслеживать с помощью других инструментов. Если я не использую их для разработки программного обеспечения, я не вижу и не должен видеть их в инструментах, которые я использую для разработки программного обеспечения.
Если я буду зависеть от них для создания своего собственного программного обеспечения, я бы сохранил их в течение всего дня.