How do you manage your Delphi Projects with third-party components in Version Control?

Question

Installing third-party components always take a long time specially if you have large ones, but also it take more time if you setup the environment in more than one computer.

Answer 1

It's worth mentioning that some companys like LMD offer remote access to their own SVN repository for customers with support subscription. I find that a good way of getting fast bugfixes for critical issues.

Answer 2

Firstly, I'll agree with both Ken and Fabricio that you must have the source code for all components you are using in a project. Anything else is just asking for trouble.

We don't use Subversion for our Source Control, but I'm guessing what we do would still be applicable...

Each project that we work on has a full copy of all components (source) used in that project. When we release, we create a release branch that includes the components as well as the project source. Each project includes it's own BPL directory.

We always create separate shortcuts to run Delphi for each project (or branch of a project) that we want to work on, and use the -R command-line parameter to set a unique Registry key for the Delphi settings for that project.

We then make sure we override the Path environment variable within Delphi to point to our project BPL directory instead of the normal Delphi BPL directory.

We set the BPL and DCP output directories for all components to be the local project BPL directory.

This allows us to have multiple versions of Delphi, with multiple versions of projects using different versions of components without any problems.

Answer 3

I agree with Ken White on this: delphi 3rd party components' used in production code

must have the source code

Period. Compiled binaries-only distributions are for evaluation purposes ONLY. It's our policy here.

As for the question: I actually does not put them on VCS. Actually I use the latest version that my projects compiles and works. The mess with system, search, library, etcetera... paths doesn't worth. 2 JVCL on the same machine or comimg back and forth versions by any new project? ARRRRGH.

If I have to use an old version to a maintenance system, drop a new VM and install the latest version. It works? Ok. Not? It stay on the VM until I discover a way to integrate on the main environment.

One version of each thing is more than enough.

Answer 4

With Subversion, I use the externals feature. It makes it easy to use the third-party stuff in multiple projects; when you check out a project, you get the external dependencies as well.

If you don't have it already, you should get a copy of Pragmatic Version Control Using Subversion. It's a great book about Subversion functionality and how to do things. While it references SVN from the command-line, the info is also easily translatable to the GUI in TortoiseSVN.

For reinstalling the components into Delphi for older projects, I usually export the registry entries for whatever version of Delphi used into the project's folder and then check that .REG file into Subversion along with the project. You can easily check out the project, export your existing Delphi registry section for the corresponding version of Delphi, import the .REG file from your project source folder, and then start Delphi with all of the components installed.

As far as the "binary BPL" issue, shame on you! If you have projects depending on third-party tools, you should buy the source for them. That way you're protected against that company going out of business, or dropping support for the components, or new releases of Delphi that aren't compatible. I always get source for third-party components; if the source isn't available, I find a different product or write the code myself. It's called self-preservation. :-)

Answer 5

If we have the source, then we include that in our repository, under a separate folder.

If we don't have the source, then we just keep the most recent binaries (bpl, dll, whatever) in the repository, and include installation / usage instructions in a setup document.

It looks like this:

\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