Как вы управляете своими проектами Delphi со сторонними компонентами в системе управления версиями?

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

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

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

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

Ответ 1

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

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

Он выглядит следующим образом:

\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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

Ответ 4

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

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

Период. Скомпилированные дистрибутивы только для использования только для целей оценки. Это наша политика здесь.

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

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

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

Ответ 5

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