安装第三方组件总是需要很长时间,特别是如果您有大型组件,但如果您在多台计算机上设置环境,则需要更多时间。
而且我正在考虑将它们添加到版本控制(Subversion)中,因此使用所有必需组件检查项目总是很容易。
那么您如何管理它,以及在 VCS 中管理它们的最佳实践是什么?
还要考虑其中一些第三方没有源代码,而是作为 Delphi 库。(BPL)。
安装第三方组件总是需要很长时间,特别是如果您有大型组件,但如果您在多台计算机上设置环境,则需要更多时间。
而且我正在考虑将它们添加到版本控制(Subversion)中,因此使用所有必需组件检查项目总是很容易。
那么您如何管理它,以及在 VCS 中管理它们的最佳实践是什么?
还要考虑其中一些第三方没有源代码,而是作为 Delphi 库。(BPL)。
如果我们有源代码,那么我们将它包含在我们的存储库中,在一个单独的文件夹下。
如果我们没有源代码,那么我们只需将最新的二进制文件(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
对于 Subversion,我使用外部功能。它可以很容易地在多个项目中使用第三方的东西;当您签出一个项目时,您也会获得外部依赖项。
如果你还没有,你应该得到一份 Pragmatic Version Control Using Subversion。这是一本关于 Subversion 功能和如何做事的好书。虽然它从命令行引用 SVN,但该信息也很容易转换为 TortoiseSVN 中的 GUI。
为了将旧项目的组件重新安装到 Delphi 中,我通常将使用的任何版本的 Delphi 的注册表项导出到项目文件夹中,然后将该 .REG 文件与项目一起检查到 Subversion 中。您可以轻松地签出项目,为相应版本的 Delphi 导出现有的 Delphi 注册表部分,从项目源文件夹中导入 .REG 文件,然后在安装了所有组件的情况下启动 Delphi。
至于“二进制 BPL”问题,真丢脸!如果你有依赖第三方工具的项目,你应该为它们购买源代码。这样,您就可以防止该公司倒闭,或放弃对组件的支持,或不兼容的 Delphi 新版本。我总是获得第三方组件的来源;如果源不可用,我会找到不同的产品或自己编写代码。这叫自保。:-)
首先,我同意 Ken 和 Fabricio 的观点,即您必须拥有项目中使用的所有组件的源代码。其他任何事情都只是自找麻烦。
我们不将 Subversion 用于我们的源代码控制,但我猜我们所做的仍然适用......
我们从事的每个项目都有该项目中使用的所有组件(源)的完整副本。当我们发布时,我们创建一个发布分支,其中包括组件以及项目源。每个项目都包含它自己的 BPL 目录。
我们总是为我们想要处理的每个项目(或项目的分支)创建单独的快捷方式来运行 Delphi,并使用 -R 命令行参数为该项目的 Delphi 设置设置唯一的注册表项。
然后,我们确保在 Delphi 中覆盖 Path 环境变量以指向我们的项目 BPL 目录,而不是正常的 Delphi BPL 目录。
我们将所有组件的 BPL 和 DCP 输出目录设置为本地项目 BPL 目录。
这允许我们拥有多个版本的 Delphi,多个版本的项目使用不同版本的组件没有任何问题。
我同意 Ken White 的观点:delphi 3rd party components' used in production code
必须有源代码
时期。仅编译的二进制发行版仅用于评估目的。这是我们这里的政策。
至于问题:我实际上并没有将它们放在VCS上。实际上,我使用我的项目编译和工作的最新版本。系统、搜索、库等的混乱......路径不值得。2 JVCL 在同一台机器上或任何新项目的来回版本?啊啊啊。
如果我必须在维护系统中使用旧版本,请删除新 VM 并安装最新版本。有用?行。不是?它一直在 VM 上,直到我找到一种集成到主环境中的方法。
每件事一个版本就足够了。
值得一提的是,LMD等一些公司为订阅了支持的客户提供了对他们自己的 SVN 存储库的远程访问。我发现这是为关键问题快速修复错误的好方法。