Как вы управляете своими проектами Delphi с помощью сторонних компонентов в системе контроля версий?

Question

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

И я думаю добавить их в систему контроля версий (Subversion), чтобы всегда было легко проверить проект со всеми необходимыми компонентами.

Итак, как вы справляетесь с этим, и как лучше всего управлять ими в VCS?

Также обратите внимание, что некоторые из этих сторонних разработчиков поставляются без исходного кода, но как библиотеки Delphi. (BPL).

Answer 1

Если у нас есть источник, то мы включаем его в наш репозиторий в отдельной папке.

Если у нас нет исходного кода, тогда мы просто сохраняем самые последние двоичные файлы (bpl, dll и т. Д.) В репозитории и включаем инструкции по установке / использованию в установочный документ.

Это выглядит так:

\root
    \third_party_stuff
        \vendor1  --we *do* have the source for this
            \src
            \bin
        \vendor2  --we *do* have the source for this
            \src
            \bin
        \vendor3  --we don't have the source for this one
            \bin
    \our_stuff
        \project1
            \src
            \bin
        \project2
            \src
            \bin

Answer 2

С Subversion я использую функцию внешних подключений. Это позволяет легко использовать сторонние материалы в нескольких проектах; когда вы проверяете проект, вы также получаете внешние зависимости.

Если у вас его еще нет, вы должны получить копию Pragmatic Version Control Using Subversion. Это отличная книга о функционале Subversion и о том, как это делать. Хотя он ссылается на SVN из командной строки, информация также легко переводится в графический интерфейс TortoiseSVN.

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

Что касается проблемы "двоичного BPL", то позор вам! Если у вас есть проекты, зависящие от сторонних инструментов, вы должны купить исходный код для них. Таким образом, вы защищены от того, что эта компания обанкротится, откажется от поддержки компонентов или от новых версий Delphi, которые не совместимы. Я всегда получаю исходный код для сторонних компонентов; если источник недоступен, я нахожу другой продукт или сам пишу код. Это называется самосохранение. : -)

Answer 3

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

Мы не используем Subversion для нашего контроля исходного кода, но я предполагаю, что то, что мы делаем, все равно будет применимо ...

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

Мы всегда создаем отдельные ярлыки для запуска Delphi для каждого проекта (или ветви проекта), над которым мы хотим работать, и используем параметр командной строки -R, чтобы задать уникальный ключ реестра для параметров Delphi для этого проекта. .

Затем мы перезаписываем переменную среды Path внутри Delphi, чтобы она указывала на каталог BPL нашего проекта вместо обычного каталога BPL Delphi.

Мы устанавливаем выходные каталоги BPL и DCP для всех компонентов в качестве локального каталога BPL проекта.

Это позволяет нам иметь несколько версий Delphi с несколькими версиями проектов, использующими разные версии компонентов без каких-либо проблем.

Answer 4

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

Answer 5

Я согласен с Кеном Уайтом в этом: сторонние компоненты delphi, используемые в производственном коде

должен иметь исходный код

Период. Скомпилированные двоичные дистрибутивы предназначены только для ознакомительных целей ТОЛЬКО . Это наша политика здесь.

Что касается вопроса: я фактически не помещаю их в VCS. На самом деле я использую последнюю версию, которую мои проекты компилируют и работают. Беспорядок с системой, поиском, библиотекой и так далее ... путей не стоит. 2 JVCL на той же машине или коммитация туда-сюда версий любого нового проекта? ARRRRGH.

Если мне нужно использовать старую версию для системы обслуживания, сбросьте новую ВМ и установите последнюю версию. Оно работает? Хорошо. Не? Он остается на виртуальной машине, пока я не найду способ интеграции в основную среду.

Одной версии каждой вещи более чем достаточно.