Аргументы за и против включения сторонних библиотек в управление версиями?

Ответ 1

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

Ответ 2

Да, вы должны (когда это возможно).

Вы должны иметь возможность взять новую машину и построить свой проект с минимальными шагами. Для меня это:

• Установить IDE (например, Visual Studio)
• Установить VCS (например, SVN)
• заказ
• Построить

Все, что еще должно иметь очень хорошее оправдание.

Вот пример: у меня есть проект, который использует компрессор Yahoo YUI для минимизации JS и CSS. Файлы YUI.jar входят в исходный элемент управления в каталог tools рядом с проектом. Однако время выполнения Java не является - это стало предпосылкой для проекта, как IDE. Учитывая, насколько популярна JRE, это кажется разумным требованием.

Ответ 3

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

Ответ 4

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

Хотя управление версиями может использоваться для распространения и развертывания, это не его основная функция. И аргументы, которые вы должны просто проверить в своем проекте и работать, не реалистичны. Всегда есть зависимости. В веб-проекте они могут быть Apache, MySQL, сама среда программирования, скажем, Python 2.6. Вы бы не навалили все это в свой репозиторий кода.

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

• Установить VCS
• Код синхронизации
• Запустите setup script (который загружает и устанавливает правильную версию всех зависимостей)

Чтобы дать конкретный пример (и я понимаю, что это довольно веб-центр), веб-приложение Python может содержать файл требований .txt, который гласит:

simplejson == 1.2
django == 1.0
otherlibrary == 0.9

Запустите это через pip, и работа будет выполнена. Затем, когда вы хотите перейти на использование Django 1.1, вы просто измените номер версии в своем файле требований и заново запустите настройку.

Ответ 5

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

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

Если вы его не скомпилируете, тогда установите бинарный сборщик /dll/jar/module в исходный элемент управления.

Ответ 6

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

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

Ответ 7

Это может зависеть от языка и/или среды, которую вы имеете, но для проектов, над которыми я работаю, я не размещаю библиотеки (файлы jar) в исходном управлении. Это помогает использовать такой инструмент, как Maven, который извлекает необходимые вам библиотеки. (Каждый проект поддерживает список необходимых банок, Maven автоматически извлекает их из общего репозитория - http://repo1.maven.org/maven2/)

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

Ответ 8

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

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

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

Ответ 9

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

ИМХО правильное место для хранения зависимостей находится на ваших резервных копиях на магнитной ленте и в вашем депозитном депозите, если у вас есть. Если ваш конкретный проект требует этого (и проекты не все одинаковы в этом отношении), тогда также сохраняйте документ под вашей системой контроля версий, которая ссылается на эти конкретные версии.

Ответ 10

Мне нравится проверять сторонние двоичные файлы в каталоге "lib", который содержит любые внешние зависимости. В конце концов, вы хотите правильно отслеживать конкретные версии этих библиотек?

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

Ответ 11

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

• Вы можете запускать и запускать новых разработчиков
• Каждый использует те же версии различных библиотек
• Мы можем точно знать, какой код был текущим в данный момент времени, в том числе сторонние библиотеки.

Ответ 12

Если мне это удастся, я оставлю их вне контроля версий и из своей файловой системы. Лучшим случаем этого является jQuery, где я буду использовать Google AJAX Library и загружать его оттуда:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript"></script>

Моим следующим выбором было бы использовать что-то вроде Git Submodules. И если ни один из них не будет достаточным, они попадут в управление версиями, но в этот момент это будет только актуально, как вы...