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

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

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

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

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

24
delphi project-structure version-control

5 ответов

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

Если у нас нет источника, мы просто сохраняем самые последние двоичные файлы (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
13

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

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

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

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

11

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

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

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

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

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

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

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

2

Я согласен с Кеном Уайтом в этом: Delphi 3rd party components ' используется в производственном коде

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

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

Что касается вопроса: я на самом деле не ставлю их на VCS. На самом деле я использую последнюю версию, которую мои проекты компилируют и работают. Беспорядок с системой, поиск, библиотека, этсетера... пути не стоят. 2 JVCL на той же машине или comimg взад и вперед версии любым новым проектом? АРРРР.

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

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

1

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

1