Рекомендации по использованию SVN с пакетами Delphi Visual Component?

Question

С желанием иметь возможность воспроизвести данную ревизию проекта, использующего сторонние пакеты визуальных компонентов, что входит в SVN и каков наилучший способ реализовать / структурировать репозитории SVN?

Для невизуальных компонентов правило кажется простым, чтобы не полагаться на внешние репо - «ссылка svn-externals на любые внешние репо запрещена». У меня есть общее репо, которое я контролирую, и это единственная разрешенная ссылка 'svn-externals'. Это облегчает реализацию и совместное использование этих типов элементов времени исполнения с исходным кодом в различных проектах SVN. Любая ссылка на это внутреннее общее репо осуществляется через svn-externals с использованием определенного номера ревизии.

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

Раньше мы не беспокоились о сторонних компонентах, так как они не меняются часто, и у нас никогда не было действительно хорошего решения. Мне было интересно, могут ли другие найти лучший способ решения этой проблемы, так как я делаю весеннюю уборку / внутреннюю реорганизацию и хотел бы сделать это «лучше», чем раньше.

Технически, источник RTL / VCL также должен быть в репозитории SVN (если выпущено исправление / пакет обновления Delphi.)

Мое решение, вероятно, будет состоять в том, чтобы создать виртуальную машину с определенной версией среды Delphi со всеми установленными визуальными элементами управления. По мере добавления / обновления визуальных элементов управления или обновления Delphi с помощью исправлений / пакетов обновлений мы создаем новую версию виртуальной машины. Затем мы сохраняем образ этой ревизии виртуальной машины где-нибудь на полке. Это то, что вы делаете? В этом сценарии хорошо (или вообще) работает активация / лицензирование Delphi?

Спасибо

Darian

Answer 1

Вы можете подготовить сценарии «запуска IDE» (и, возможно, «построить») для своих проектов и поддерживать их по мере развития проекта в хранилище.

Независимо от вашего решения о хранении компонентов в отдельных хранилищах и использовании внешних компонентов,или включив их в один репозиторий с возможным переходом, вы также должны включать скомпилированные файлы bpl для каждой сборки компонента и для каждой ветви, подготовленной для конкретной версии Delphi.

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

Запуск сценария IDE позволяет сохранять каждый проект и среду версии Delphi отдельно настроенными для одной установки Windows.

Он должен включать необходимые ключи реестра для вашего проекта и Delphi:

Windows Registry Editor Version 5.00

[-${DelphiRegKey}\Disabled Packages]
[-${DelphiRegKey}\Known Packages]
[-${DelphiRegKey}\Library]

[${DelphiRegKey}\Known Packages]
"$(BDS)\\Bin\\dclstd${CompilerVersion}.bpl"="Borland Standard Components"
"$(BDS)\\Bin\\dclie${CompilerVersion}.bpl"="Internet Explorer Components"
"$(BDS)\\Bin\\dcldb${CompilerVersion}.bpl"="Borland Database Components"
(...)
"${CustomComponentPack}"="Custom Components"

[${DelphiRegKey}\Library]
"Search Path"="${YourLibrarySourceFolder1};${YourLibrarySourceFolder2}"
(...)

Затем вы можете подготовить пакетный файл:

regedit /s project.reg
%DelphiPath%\bin\bds -rProjectRegKey Project.dpr

Где ${DelphiRegKey} равно HKEY_CURRENT_USER\Software\Borland(or CodeGear in newer versions)\ProjectRegKey.

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

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

Answer 2

К счастью для нас, нам не нужно беспокоиться об исправлении / пакете обновления;мы все еще на Delphi 5.: D

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

• реестр
• Windows \ System
• Program Files
• Иногда даже пользовательские папки в «Данные приложения» или «Локальные настройки»

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

Однако я собираюсь сообщить, что, вероятно, не стоит слишком много усилий. Помните, что работать со старыми версиями всегда дороже, чем работать с текущей версией.

• В идеале вы хотите, чтобы все ваши разработчики были в основной веткекод, вы хотите свести к минимуму патч-работу на старых версиях.
• Поэтому старайтесь, чтобы большинство ваших пользователей использовали последнюю версию как можно больше.
• По общему признанию, это не всегда возможно.
• В любом случае вы не захотите переходить к «новой версии» без предварительного тестирования.
• Некоторые гибкие процессы, как правило, облегчают эту задачу.
• Используя отдельную сборочную машину или виртуальную машину, у вас уже есть мера контроля.
• TIP: I would also suggest that the build process automtically copy build output to a different machine, or at least a different hard-drive.
• Как только вы будете удовлетворены пакетом обновления, вы можете планировать, когда захотитесверните его на свой компьютер сборки.
• Чрезвычайно важно вести учет метки, на которой изменилась конфигурация сборки.(На всякий случай.)
• If your build scripts are also kept in source control, this happens implicitly.
• После того, как вы установили исправление / пакет обновления, исправления для более старых версий следует активно не поощрять.
• Конечноих, вероятно, нельзя устранить, но если это достаточно редко, то возможно даже ручное изменение конфигурации.
• Instead of a VM option to keep your old configuration, you can also consider drive-imaging.
• Чтобы сэкономить на $$$ VMWare LabManager, посмотритедля VM Player, управляемого из командной строки.
• Возможно, вам придется сохранить 2 «живые» машины / виртуальные машины, но больше никогда не потребуется.
• It's okay for an automatic build script to fail because the desired configuration isn't available. This will remind you to set it up manually.
• Помните, что работать со старыми версиями всегда дороже, чем работать с текущей версией.

Сторонние пакеты

Мы пошлинемного больше усилий здесь.Одной из наших основных мотивов было то, что мы используем около 8 сторонних пакетов.Так что делать что-то, чтобы стандартизировать это по-своему, имело смысл.Мы также решили, что запуск 8 программ установки - это PITA, поэтому мы разработали простой способ ручной установки всех необходимых пакетов из системы управления исходным кодом.

Ключевые аспекты

• Среда сборки не 'не требуется никаких пакетов установленных при условии, что объект и / или исходные файлы доступны.
• Было бы полезно, если бы разработчики могли довольно легко убедиться, что они собирают с той же версией сторонних библиотекпри необходимости.
• Однако среды разработки обычно должны устанавливать пакеты в IDE.
  • Это может иногда вызывать проблемы с совместимостью с исходным кодом.
  • Например, новые свойства, которые записываются в файлы, поддерживаемые IDE.
  • Что, конечно, возвращает нас ко второму пункту.
• Поскольку сторонние пакеты нечасто обновляются, они помещаются в несколько иную область контроля версий.
• Но, NB все еще долженссылаться через относительные пути.

Мы создали следующую структуру папок:

...\ThirdParty\_DesignTimePackages //The actual package files only are copied here
...\ThirdParty\_RunTimePackages //As above, for any packages "required" by those above
...\ThirdParty\Suite1
...\ThirdParty\Suite2
...\ThirdParty\Suite3

В результате этого довольно легко настроить новую среду:

• Получить последнюю версию всех файлов ThirdParty.
• Добавление _DesignTimePackages и _RunTimePackages к пути Windows
• Open Delphi
• Выберите Установить компоненты
• Выберите все пакеты из _DesignTimePackages.
• Готово!

---

Редактировать : Дариан был обеспокоен возможностью возникновения ошибок при переключении переключающих версий пакетов разработки. Однако такой подход позволяет избежать подобных проблем.

• Добавляя _DesignTimePackages и _RunTimePackages в путь к Windows, Delphi всегда найдет необходимые пакеты в одном и том же месте.
• В результате вы вряд ли столкнетесь с «кошмаром пакетов» несовместимых версий.
• Конечно, если вы делаете что-то глупое, например, перестраиваете некоторые из ваших пакетов и регистрируете новую версию, вы можете ожидать проблем - независимо от того, какой подход вы используете.

Answer 3

Я обычно структурирую свой репозиторий в SVN так:

/trunk/app1
/trunk/comp/thirdparty1
/trunk/comp/thirdparty2
/trunk/comp/thirdparty3...

У меня в корневой папке (транке) есть группа проектов (.groupproj или .bpg на старом delphi), которая содержит все мои компоненты. (Allcomponents.groupproj).

Установка на новом компьютере означает открытие этого пакета и установку компонентов времени разработки. Это тормозит все версии Delphi старше 2010 года, но в 2010 и XE есть замечательная функция, так что вы можете сразу увидеть, какие компоненты являются компонентами времени разработки.

Я также иногда избавляю себя от необходимости устанавливать эти компоненты вручную, создавая файл build.bat и файл regcomponents.bat. Regcomponents просто запускает regedit и импортирует ключи, необходимые для регистрации всех этих компонентов, после того, как build.bat их собрал, и все остальное.

Когда вы переходите от одной версии Delphi к другой, очень полезно иметь как пакетный, так и reg-файл и групповой проект, чтобы помочь вам. Особенно, если вам приходится многократно открывать проект / пакеты и сохранять их как MyComponent3.dpk вместо MyComponent2.dpk, или обновлять расширение пакета со 150 до 160, или как там ваши пакеты.