24

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

Paul Roub
  • 36,322
  • 27
  • 84
  • 93
Mohammed Nasman
  • 10,992
  • 7
  • 43
  • 68

5 Answers5

14

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
  • 57,317
  • 63
  • 160
  • 234
  • @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 Keersmaekers Feb 12 '09 at 16:08
  • @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 Feb 12 '09 at 16:36
  • 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 Feb 12 '09 at 17:47
  • @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 Feb 12 '09 at 19:13
  • we also have a 3rd folder for packages – marius Apr 20 '09 at 06:33
  • @Andreas, I've seem to have missed your response two years ago. Very painfull as it adresses exactly the problem I faced. Good news is that we are switching to TFS and decided to start from scratch so we can still implement that solution. Thank you. – Lieven Keersmaekers Feb 24 '11 at 19:57
11

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
  • 123,280
  • 14
  • 225
  • 444
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.

Alistair Ward
  • 1,093
  • 9
  • 20
1

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
  • 3,810
  • 3
  • 28
  • 43
  • @DavidHeffernan The 3rd party source code? Not really unless you change it. What you can guard is the binaries/zip files/whatever package it came. But mantain ONLY one version installed. I tried do the "best practice" in the past and always brought more grief than its worth – Fabricio Araujo Jun 25 '14 at 15:29
  • If you don't put it under revision control you are incapable of versioning. How can you go back to previous versions? How can you maintain release branches? – David Heffernan Jun 25 '14 at 15:31
  • @DavidHeffernan I treat them like the Delphi ISO - everyone is on the same release/service pack. – Fabricio Araujo Jun 25 '14 at 15:39
  • I don't think you understand me at all. What if I need to fix a bug in an older version of my product? That is maintenance development. You want to change as little as possible. Blindly upgrading all your third party dependencies should not happen. – David Heffernan Jun 25 '14 at 15:45
  • @DavidHeffernan Internal development. There's no older version. Life is a lot easier. If I had to, still that fix would do under an isolated vm - the main development still only have one 3rd party version. – Fabricio Araujo Jun 25 '14 at 15:48
  • Life is always easier when the source is under revision control. What about when you need to understand why behaviour differs in an older version of the program? It's incredibly valuable to be able to checkout the source code from revision control. Your approach doesn't allow you to do that. The idea that installing components into a VM is simpler than a one line `svn update` command cannot be right. – David Heffernan Jun 25 '14 at 15:51
  • I would agree if we were talking of source-code only libraries - you throw it once on SVN and goes back and forth. FOr components you have to configure the IDE and that I don't mess with it. Imagine having to reinstall an monster like JVCL? I treat them like black boxes and only if CHANGE something it gets versioned. It's too much messing with PATHs for my taste and I have to live with the idiosyncrasies of appwave streamed installs too. And since the last great trouble we had was unicode strings, does not worth. For me, the simpler dependencies I have in the IDE the better. – Fabricio Araujo Jun 26 '14 at 18:54
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.

Roddy
  • 66,617
  • 42
  • 165
  • 277