Best practices for using SVN with Delphi Visual Component packages?

7
votes

With the desire to be able to reproduce a given revision of a project that is utilizing 3rd party visual component packages, what goes in SVN and what's the best way to implement/structure the SVN repos?

For non-visual components, the rule seems simple to ensure no reliance on outside repos - "no svn-externals reference to any outside repo allowed". I have a shared repo that I control, which is the only 'svn-externals' reference allowed. This makes it easy to implement and share these types of runtime itemss with sourcecode in different SVN projects. Any reference this internal shared repo is by 'svn-externals' using a specific revision number.

Visual packages seem to go counter to being able to be version controlled easily as they may have to be reinstalled at each revision. How to best create a SVN project which is able to be recreated later at a specific revision number...is there a recommended solution?

Previously we didn't worry about 3rd party components as they don't change often and we never had a real good solution. I was wondering if others have figure out the best way to handle this problem as I'm doing a spring cleaning/internal reorganization and wanted to do it 'better' than before.

Technically, the RTL/VCL source should also be in the SVN repo as well (if there's a Delphi hotfix/service pack released.)

My solution will likely be to create a virtual machine with a particular release of the Delphi environment with all visual controls installed. As we add/update visual controls, or update Delphi with hotfixes/service packs then we create a new version of the virtual machine. We then store an image of this VM revision on a shelf somewhere. Is this what you do? Does the Delphi activation/licensing work well (or at all) in this scenario?

Thanks,

Darian

3
delphisvnversion-control
IMHO, 3rd. party component packages, visual or not, are the same thing as they have to be installed in the IDE in order to work. This is the case, for example of INDY or JCL and even JVCL (mix of visual and non visual), just to mention a couple of popular non visuals. – jachguate
If you aren't building with runtime packages and have the source, then it's a simple path issue to point at the sourcecode. So in that case, runtime packages (with source) are much easier to deal with. – Darian Miller
This doesn't solve the problem of retrieving a specific version from svn (or any version management), third party components included. – Leonardo Herrera
I was thinking along similar lines to jachguate. Perhaps the more appropriate distinction is Design Time vs. purely Run Time packages. – Disillusioned
@Leonardo, if you are referring to the VM as not being a solution to retrieve a specific version from SVN, you are correct. I just don't have another workable idea at this point. It's better than what we have currently, but certainly not 'ideal' Ideal would perhaps be VMWare LabManager but that's high $$ – Darian Miller

3 Answers

7
votes

You can prepare "start IDE" (and possibly "build") scripts for your projects and maintain them as project evolves in repository.

Regardless of your decision about keeping components in separate repositories and using externals, or including them in a single repository with possible branching, you should also include compiled bpl files for every component build and for every branch prepared for a specific Delphi version.

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

Start IDE script allows you to keep each project and Delphi version environment spearately configured on a single Windows installation.

It should include 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}"
(...)

You can then prepare 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.

Basically it is easier when you will dump your current working configuration from registry, strip it from unnecessary keys, change paths to relative and then adapt to make it work with your project.

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

3
votes

Fortunately for us, we don't have to worry about a hotfix/service pack; we're still on Delphi 5. :D

Sigh, there was a time when an entire application (settings and all) would exist within a single directory - making this a non-issue. But, the world has moved on, and we have various parts of an application scattered all over the place:

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

You are quite right to consider the impact of hotfixes/service packs. It's not only RTL/VCL that could be affected, but the compiler itself could have been slightly changed. Note also that running on the same line of thought, 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 Delphi versions alongside each other.

However, I'm going to advise that it's probably not worth going to too much effort. Remember, working on old versions is always more expensive than working on the current version.

  • Ideally you want all your dev to be be on main branch code, you want to minimise patch-work on older versions.
  • So strive to keep the majority of your users on the latest version as much as possible.
  • Admittedly this isn't always possible.
  • You wouldn't want to jump over to the 'new version' without some testing first in any case.
  • Certain agile processes do tend to make this easier.
  • By using a separate build machine or VM, 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're satisfied with the service pack, you can plan when you want to roll it to your build machine.
  • It is extremely important to keep record of the label at which the build configuration changed. (Just in case.)
  • If your build scripts are also kept in source control, this happens implicitly.
  • When you've rolled out the hotfix/service pack, fixes to older versions should be actively discouraged.
  • Of course, they probably can't be eliminated, but if it's rare enough, then even manual reconfiguration could be feasible.
  • Instead of a VM option to keep your old configuration, you can also consider drive-imaging.
  • To save on the $$$ of VMWare LabManager, look for a command-line driven VM Player.
  • You might have to keep 2 "live" machines/VMs, but should never need more than that.
  • 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.
  • Remember, working on old versions is always more expensive than working on the current version.

Third Party Packages

We went to a little bit more effort here. One of our main motivations though was the fact that we use about 8 third party packages. So doing something to standardise this in itslef made sense. We also decided running 8 installation programs was a PITA, so we devised an easy way to manually install all required packages from source-control.

Key Considerations

  • The build environment doesn't need any packages installed, provided the object and/or source files are accessible.
  • It would help if developers could fairly easily ensure they're building with the same version of third party libraries when necessary.
  • However, dev environments usually must install packages into the IDE.
    • This can sometimes cause problems with source compatibility.
    • For example new properties that get written to IDE maintained files.
    • Which of course brings us back to the second point.
  • Since Third Party packages are infrequently updated, they are placed within a slightly different area of source-control.
  • But, NB must still 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's quite easy to configure a new environment:

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

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

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

I usually structure my repository in SVN like this:

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

I have, right in the root folder (trunk) a project group (.groupproj, or .bpg on old delphi) that contains all my components. (allcomponents.groupproj).

Installing on a new machine, means opening that package, and installing the designtime components. That's a drag on all versions of Delphi older than 2010, but 2010 and XE have a lovely feature so you can see at a glance, which components are designtime components.

I also, sometimes, will save myself the trouble of installing those components by hand, by making a build.bat file, and a regcomponents.bat file. The regcomponents just runs regedit , and imports the keys needed to register all those components, after build.bat has built them, and everything else.

When you move up from one delphi version to another, it's sure good to have both a batch and reg file, and a group project, to help you. Especially if you have to go through and do a lot of opening of project/packages and saving them as MyComponent3.dpk instead of MyComponent2.dpk, or updating the package extension from 150 to 160, or whatever your packages do.