10

我在一篇关于 Version Insight ( http://www.delphifeeds.com/go/s/77066 ) 的博客中读到（其中包括）JCL 的 .dproj 文件不受版本控制，我想知道它的优势是什么那将是。

特别是因为我和我的同事开发人员经常在使用我们自己喜欢的调试设置检查项目文件时互相“出错”（他喜欢优化，我想要它关闭）。并且由于 Delphi 2007 的常规故障导致 dproj 文件出现各种错误的依赖关系。无论如何，版本控制对这些事情没有帮助吗？

我们目前使用 Starteam 作为我们的 VCS。

4

6 回答 6

7

如果您使用的是 Delphi 2009 或更高版本，选项集是解决此问题的完美方案。

选项集基本上是设置的集合，这些设置通常驻留在 DPROJ（您对其进行版本控制）中，而是存储在 .OPTSET 文件中（您不对其进行版本控制）。

使您的 DPROJ 包含所有开发人员通用的设置，除非是全面同意的更改，否则任何人都不得更改。

接下来在项目管理器（D2009 及更高版本）中，首先是 DEBUG 配置节点，然后是 RELEASE 配置节点，右键单击并选择“New Option Set”。将此选项设置为“Local Developer Debug Settings.optset”和“Local Developer Release Settings.optset”。

现在只将您的 DPROJ 提交给版本控制，因为它现在引用这些 .OPTSET 文件。出于这个原因，您必须在每台机器上将您的选项集命名为完全相同。

当您想对项目配置进行本地更改而不是编辑项目配置时，右键单击项目管理器中的选项集并选择“编辑选项集”。

IDE 将应用选项集中更改的设置，而不修改原始 DPROJ。设置是分层应用的，选项集是最后应用的。

于 2011-02-20T21:19:02.773 回答
4

msbuild我将用于构建过程的设置存储在我的 .dproj 文件中。例如，条件定义、编译器设置等。如果您这样做，那么您需要对它们进行版本控制。

如果您使用的是 IDE 定期破坏 .dproj 文件的 Delphi 版本，那么版本控制肯定会帮助您反击。

我看不出不对它们进行版本控制有什么好处。

于 2011-02-20T20:12:53.493 回答
2

如果您选择不对您的 DPROJ 进行版本控制，那么在创建发布版本时，我建议您使用您执行版本的某种单独的构建脚本，例如

  • 一个批处理文件，它调用命令行编译器并指定所需的编译器选项和路径。
  • Finalbuilder 项目（比批处理文件容易得多）
  • 一个 msbuild 脚本（我自己从未做过，但我认为这是可能的）。
于 2011-02-20T21:40:08.897 回答
1

此问题的一种解决方案是更清楚地了解您允许签入的 DPROJ（以及 DFM 文件）的哪些部分。

你没有提到你正在使用什么版本控制系统，但是 TortoiseHg 有一个大块选择功能作为它的提交过程的一部分，它可以让你在一个更改的文件中选择单独的行来提交，并且仍然保留其他行未提交。

我使用这种方法从不检查来自 DPROJ（例如将活动配置从 RELEASE 更改为 DEBUG）和 DFM（例如更改 ExplicitHeight 和 ExplicitWidth 属性）的垃圾更改。

于 2011-02-20T20:59:11.410 回答
1

我能想到不使用版本控制 DPROJ 文件的唯一原因是，如果像 JCL 一样，您可以在构建过程中重新生成它们。JCL 是一个类库（代码库）而不是应用程序，它针对 Delphi 的多个版本，它们的 .dproj 文件存在差异。事实上，2005 年之前的 delphi 版本根本不使用 .dproj 文件。

于 2011-02-21T17:06:49.737 回答
0

Delphi XE4、5、6 和 XE7 的更高版本在构建 .dproj XML 文件时非常稳定。我没有抱怨使用git版本.dproj和.groupproj文件。使用 IDE 编辑器更新这些文件只会导致预期的整洁和干净的更改。

于 2014-09-08T05:57:33.067 回答