Best practices for using SVN with Visual Component Delphi packages?

Question

With the desire to be able to reproduce this revision of a project that uses third-party packages of visual components, what is included in SVN and what is the best way to implement / structure SVN repositories?

For non-visual components, the rule seems simple so that there is no confidence in external repositories - "no svn-externals refers to any allowed external repo." I have a common repo that I control and this is the only svn-externals link. This simplifies the implementation and separation of these types of runtime elements with source code in different SVN projects. Any reference to this internal shared repo is done using "svn-externals" using a specific version number.

Visual packages seem to contradict the fact that they are easily versioned, as they may need to be reinstalled with each revision. What is the best way to create an SVN project that can be recreated later with a specific revision number ... is there a recommended solution?

Previously, we did not worry about third-party components, since they do not change often, and we never had a really good solution. I was wondering if others would figure out a better way to deal with this problem, as I am doing spring cleanup / internal reorganization and want to do it “better” than before.

Technically, the RTL / VCL source should also be in the SVN repo (if the Delphi patch / service pack is released there.)

My solution would probably be to create a virtual machine with a specific release of the Delphi environment with all the visual controls installed. As we add / update visual controls or update Delphi using patches / service packs, we create a new version of the virtual machine. Then we save the image of this version of VM on a shelf. Is that what you do? Does Delphi activation / licensing (or in general) apply in this scenario?

Thanks,

Darian

Answer 1

You can prepare scripts to “start the IDE” (and possibly “build”) for your projects and support them as the project develops in the repository.

Regardless of your decision to store components in separate repositories and use external resources, or including in one repository with possible branching, you should also include compiled bpl files for each component assembly and for each branch prepared for a particular version of Delphi.

You should try to keep most (if not all) of the paths relative, in the worst case, use environment variables to point to your project root directory.

In the beginning, the IDE script allows you to support every project and Delphi version environment configured on one Windows installation.

It should contain the necessary registry keys for your project and 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}" (...) 

Then you can prepare the batch file:

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

Where ${DelphiRegKey} is HKEY_CURRENT_USER\Software\Borland(or CodeGear in newer versions)\ProjectRegKey .

It’s basically easier when you reset the current working configuration from the registry, separate it from unnecessary keys, change the paths to relative ones, and then adapt them to work with your project.

In this configuration, switching between projects and their branches, which have different sets of components (and / or, possibly, using a different version of Delphi), consists in checking only the repository and running the script.

Answer 2

Fortunately for us, we don’t have to worry about the fix / update package; we are still on Delphi 5 .: D

Sigh, there was a time when the whole application (settings and everything) would exist in one directory - this was not a problem. But the world has moved on, and we have different parts of the application scattered everywhere:

• registry
• Windows \ System
• Program files
• Sometimes even user folders in "Application Data" or "Local Settings"

You are absolutely right to consider the impact of fixes / service packs. This can affect not only RTL / VCL, but the compiler itself can be slightly modified. Also note that when doing the same thing, even when you upgrade Delphi versions, you need to build using the correct version. Admittedly, this is a little easier because you can run different versions of Delphi next to each other.

However, I’m going to advise that you probably shouldn’t make too much effort. Remember that working on older versions is always more expensive than working on the current version.

• Ideally, you want all your developers to be in the main code of the branch, you want to minimize patch work in older versions.
• Therefore, try to make the most of your users in the latest version.
• Admittedly, this is not always possible.
• In any case, you will not want to switch to the “new version” without any testing.
• Some flexible processes tend to make this easier.
• Using a separate build machine or virtual machine, you already have a measure of control.
• TIP: I would also suggest that the build process automtically copy build output to a different machine, or at least a different hard-drive.
• Once you are satisfied with the service pack, you can plan when you want to upgrade it to your build machine.
• It is very important to keep a label record with which the assembly configuration has changed. (Just in case.)
• If your build scripts are also kept in source control, this happens implicitly.
• When you have deployed the patch / update package, patches for older versions should be actively discouraged.
• Of course, they probably cannot be eliminated, but if this is rare enough, then even manual reconfiguration can be feasible.
• Instead of a VM option to keep your old configuration, you can also consider drive-imaging.
• To save VMWare to $$$ LabManager, find a virtual player with a command line.
• You may need to store 2 live machines / virtual machines, but they no longer need any more.
• It okay for an automatic build script to fail because the desired configuration isn't available. This will remind you to set it up manually.
• Remember that working on older versions is always more expensive than working with the current version.

3rd party packages

We went here a little more. One of our main motives was that we used about 8 third-party packages. So do something to standardize it in your understanding. We also decided that running 8 installers was PITA, so we developed an easy way to manually install all the necessary packages from a control source.

Key Considerations

• Installed packages are not required in the build environment if objects and / or source files are available.
• This would help if developers could, with a fair degree of certainty, ensure that they build with the same version of third-party libraries when necessary.
• However, development environments typically need to install packages in the IDE.
  • Sometimes this can cause source compatibility issues.
  • For example, new properties that are written to supported IDE files.
  • Which, of course, brings us back to the second point.
• Because third-party packages are rarely updated, they are placed in a slightly different source control area.
• But NB still needs to be referenced via relative paths.

We created the following folder structure:

 ...\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 

As a result of this, it is fairly easy to set up a new environment:

• Get the latest version of all ThirdParty files.
• Add _DesignTimePackages and _RunTimePackages to the Windows path.
• Open Delphi
• Select Install Features
• Select all packages from _DesignTimePackages.
• Done!

---

Edit : Darian was concerned about the possibility of errors when switching versions of Design Packages versions. However, this approach avoids such problems.

• By adding _DesignTimePackages and _RunTimePackages to the Windows Path, Delphi will always find the required packages in the same place.
• As a result, you are less likely to encounter a “package nightmare” of incompatible versions.
• Of course, if you do something stupid, like rebuilding some of your packages and register a new version, you can expect problems - no matter what approach you follow.

Answer 3

I usually structure my repository in SVN as follows:

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

I have in the root folder (trunk) a group of projects (.groupproj or .bpg on the old delphi) that contains all my components. (Allcomponents.groupproj).

Installing on a new machine means opening this package and installing development-time components. This drag and drop to all versions of Delphi older than 2010, but 2010 and XE have a great feature, so you can immediately see which components are development-time components.

I also sometimes get rid of the need to install these components manually by creating a build.bat file and a regcomponents.bat file. Regcomponents simply launches regedit and imports the keys necessary to register all of these components after build.bat has built them and everything else.

When you switch from one version of delphi to another, you probably have a batch, and reg file, and a group project to help you. Especially if you need to go through and open a lot of the project / packages and save them as MyComponent3.dpk instead of MyComponent2.dpk or update the package extension from 150 to 160 or any of your packages.