Question

如果您有大型组件，安装第三方组件时需要花费很长时间，但如果您在多台计算机中设置环境，则需要更长时间。

我正在考虑将它们添加到版本控制（Subversion）中，因此使用所有必需的组件检查项目总是很容易。

那么你如何管理它，以及在VCS中管理它们的最佳实践是什么？

还要考虑其中一些第三方没有来源但是作为Delphi库。（BPL）。

Answer 1

如果我们有源，那么我们将它包含在我们的存储库中的单独文件夹下。

如果我们没有源代码，那么我们只保留存储库中最新的二进制文件（bpl，dll等），并在安装文档中包含安装/使用说明。

看起来像这样：

\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

Answer 2

使用Subversion，我使用外部功能。它使得在多个项目中使用第三方内容变得容易;当您签出项目时，您也会获得外部依赖项。

如果您还没有，那么您应该获得使用Subversion的实用版本控制的副本。这是一本关于Subversion功能和如何做事的好书。虽然它从命令行引用SVN，但信息也可以轻松转换为TortoiseSVN中的GUI。

为了将组件重新安装到Delphi中以用于旧项目，我通常会将用于Delphi的任何版本的注册表项导出到项目的文件夹中，然后将.REG文件与项目一起检查到Subversion中。您可以轻松签出项目，导出现有Delphi注册表部分以获取相应版本的Delphi，从项目源文件夹导入.REG文件，然后启动Delphi并安装所有组件。

就“二元BPL”问题而言，羞辱你！如果您的项目依赖于第三方工具，则应为其购买源代码。这样你就可以防止该公司破产，或者放弃对不兼容的组件或新版Delphi的支持。我始终获取第三方组件的来源;如果源不可用，我会找到不同的产品或自己编写代码。它被称为自我保护。： - ）

Answer 3

首先，我同意Ken和Fabricio您必须拥有您在项目中使用的所有组件的源代码。其他任何事情只是在寻找麻烦。

我们不会将Subversion用于源代码管理，但我猜我们所做的仍然适用...

我们处理的每个项目都包含该项目中使用的所有组件（源）的完整副本。当我们发布时，我们创建一个包含组件和项目源的发布分支。每个项目都包含它自己的BPL目录。

我们总是创建单独的快捷方式来为我们想要处理的每个项目（或项目的分支）运行Delphi，并使用-R命令行参数为该项目的Delphi设置设置唯一的注册表项

然后我们确保在Delphi中覆盖Path环境变量，指向我们的项目BPL目录，而不是普通的Delphi BPL目录。

我们将所有组件的BPL和DCP输出目录设置为本地项目BPL目录。

这使我们可以拥有多个版本的Delphi，多个版本的项目使用不同版本的组件而没有任何问题。

Answer 4

我同意Ken White的观点：生产代码中使用的delphi第三方组件

必须包含源代码

周期。仅编译的二进制文件分发用于评估目的 ONLY 。这是我们的政策。

至于问题：我实际上并没有将它们放在VCS上。实际上我使用我的项目编译和工作的最新版本。系统，搜索，库，等等路径的混乱不值得。 2 JVCL在同一台机器上或通过任何新项目来回复制版本？ ARRRRGH。

如果我必须将旧版本用于维护系统，请删除新VM并安装最新版本。有用？好。不？它保留在VM上，直到我发现一种集成在主环境中的方法。

每件事的一个版本绰绰有余。

Answer 5

值得一提的是，像LMD这样的公司为拥有支持订阅的客户提供了对自己的SVN存储库的远程访问。我发现这是解决关键问题的快速错误修正的好方法。

如何使用版本控制中的第三方组件管理Delphi项目？

5 个答案: