views:

845

answers:

5

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.

And I'm thinking to add them to the Version Control (Subversion), so it will be always easy to checkout the project with all it's required components.

So How you manage that?, and what's the best practice to manage them inside the VCS?

Also consider some of these third-parties come without source but as Delphi libraries. (BPL).

+10  A: 

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
JosephStyons
@Joseph, how do you handle different versions from third party vendors? Project1 could be using versionX of vendor1 while project2 has already moved to versionY of vendor1.
Lieven
@Lieven: you can either have the versions side by side (directories like component_version) or have a library directory per-project (my preferred approach)
Rytmis
If we upgrade to a newer version of a component, we usually put it in a new directory alongside the older one, as in Rytmis's first suggestion.
JosephStyons
@Lieven: We use the "delphi32.exe -rVer2.0" IDE command line switch to load the Delphi environment for an older program version. The components are in a different directory for that version (svn branch).
Andreas Hausladen
we also have a 3rd folder for packages
marius
+10  A: 

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. :-)

Ken White
Interesting point about third-party source code!
onnodb
+1  A: 

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.

Fabricio Araujo
A: 

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.

Roddy
+2  A: 

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.

Alistair Ward