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

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

Нет - я не думаю, что вам следует передавать сторонние библиотеки в систему контроля версий. Подсказка кроется в названии «контроль версий».

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

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

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

Чтобы привести конкретный пример (и я понимаю, что это вполне веб-ориентировано), веб-приложение Python может содержать файл requirements. django == 1.0
otherlibrary == 0.9

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

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

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

1. Установить IDE (например, Visual Studio)
2. Установить VCS (например, SVN)
3. Оформить заказ
4. Сборка

Что-то еще должно иметь очень хорошее обоснование.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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