不对 .dproj 进行版本控制的优势

Question

我在一篇关于Version Insight的博客 (http://www.delphifeeds.com/go/s/77066) 中看到 JCL （JEDI Code Library）没有将其 .dproj 文件纳入版本控制，我想知道这样做的好处是什么。

尤其是因为我和我的同事经常使用我们自己喜欢的调试设置彼此“骚扰”，例如他喜欢优化开启，而我则希望关闭。此外，由于 Delphi 2007 经常出现故障依赖导致 dproj 文件失败的问题。版本控制是否对这些问题有所帮助呢？

我们目前正在使用 Starteam 作为我们的版本控制系统。

- Bascy

---

我不知道Delphi 2007是否已经支持此功能，但您可以使用单独的构建配置来处理不同的调试设置。 - Moritz Beutel

是的，它确实可以，但这是一个非常微妙的系统，因为你对设置所做的每个更改都会被保存在所选的构建配置中，不需要任何问题。 - Bascy

是的，那就是它应该的方式 :) - Moritz Beutel

问题在于，您无法临时更改编译器选项... 您必须记得手动将它们设置回来。dproj已更改并不表示如此，因为它可能已因其他原因（例如新源）而更改。 - Bascy

请参见：https://www.uweraabe.de/Blog/2017/01/18/dproj-changed-or-not-changed/ - Gabriel

Answer 1

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

选项集基本上是一组设置，这些设置通常驻留在DPROJ中（您需要对其进行版本控制），但实际上存储在.OPTSET文件中（您不需要对其进行版本控制）。

使您的DPROJ包含所有开发人员都共享的设置，除非经过全面协商，否则任何人都不能更改这些设置。

接下来，在项目管理器（D2009及以上版本）中，右键单击“DEBUG”配置节点，然后右键单击“RELEASE”配置节点，选择“新建选项集”。将此选项集命名为“Local Developer Debug Settings.optset”和“Local Developer Release Settings.optset”。

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

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

IDE将从选项集应用更改后的设置，而不会修改原始的DPROJ。设置按层次结构应用，选项集是最后应用的。

- LachlanG

---

这就是为什么我写了第二个回答。我不希望它对 Bascy 有所帮助，除非它能说服他升级，但它可能会对其他人有所帮助。选项集并不是很常见，但它们真的非常有用。 - LachlanG

http://meta.stackexchange.com/questions/25209/what-is-the-official-etiquette-on-answering-a-question-twice - LachlanG

@David: 我完全不在乎这个愚蠢的声誉游戏。合适的时候，我会发布多个答案，因为这可以为他人提供最佳的长期资源。 - LachlanG

@Marjan：是的，我看到了Jeff的回答，并注意到他没有得到任何赞同。我链接的两个元问题中，绝大多数答案和赞同都支持在提出非常不同的方法时提供多个答案。正如Jeff Atwood在他的博客中一遍又一遍地说的那样，他不是运行StackOverflow社区的人，而是社区在运行。这两个问题是我能找到的最好的代表社区意见的问题。 - LachlanG

@Marjan：完全归功于Jeff Atwood，他并未在一个明显与大多数人意见相左的问题上否决社区的决定。 - LachlanG

Answer 2

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

如果您使用的Delphi版本经常破坏.dproj文件，那么版本控制肯定可以帮助您应对。

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

- David Heffernan

---

你的构建过程中是否使用了.dprof文件？如果是的话，那么你需要对它们进行版本管理。 - David Heffernan

在我的经验中，只有当自动构建编号增加时，dproj文件才会出现问题。当两个开发人员同时构建时，它们都会被递增，这会导致版本控制系统中的冲突。除此之外，你实际上必须将它们添加到版本控制中，否则你会失去许多需要的数据，例如单元别名，一旦丢失，将会引起很多问题。 - Tuncay Göncüoğlu

@TuncayGöncüoğlu 嗯，我不会使用任何 IDE 的版本控制功能，因为我认为它们都不好。 - David Heffernan

同意在那里，但这是个人喜好的问题。我自己比较偏爱使用GIT，带有smartgit或者只使用它默认的git-gui，甚至命令行也很棒。 - Tuncay Göncüoğlu

@TuncayGöncüoğlu 不，我说的不是那个。我说的是版本信息、自动构建编号增量。那是你所谈论的。更改控制是另一回事。 - David Heffernan

Answer 3

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

• 一个批处理文件，调用命令行编译器并指定所需的编译器选项和路径。
• 一个Finalbuilder项目（比批处理文件更容易）
• 一个msbuild脚本（我自己从未尝试过，但我认为这是可能的）。

- LachlanG

Answer 4

解决此问题的一个方法是更加谨慎地选择允许检查的DPROJ（以及DFM文件）的部分。

您没有提到使用的版本控制系统，但TortoiseHg在其提交过程中具有块选择功能，使您可以选择要提交的更改文件中的单个行，并仍然保留其他行未提交。

我使用此方法从未检查DPROJ中的垃圾更改（例如将活动配置从RELEASE更改为DEBUG）和DFM中的更改（例如对ExplicitHeight和ExplicitWidth属性的更改）。

- LachlanG

---

我们正在使用Starteam，我不知道是否有这样的功能。如果有的话，那将是非常棒的，因为我可以看到它解决了我们的几个问题。 - Bascy

ExplicitHeight可以通过DDevExtensions处理 - 您可以设置选项，在流式传输时排除这些属性。 - David Heffernan

@David 谢谢你的提示。终于知道如何摆脱这个烦人的行为了。 - Michael Küller

如果垃圾的变化和真正的变化不会自动保存，那就更好了。例如，每次打开并进行其他更改时，TBitmap属性在DFM中的图像上以似乎随机的十六进制更改重新流式传输。 - Warren P

@Warren同意，但是谁会把位图放在.dfm文件中呢？图像和其他二进制文件应该作为资源包含在内。将它们放在.dfm文件中会使版本控制变得非常困难。 - David Heffernan

Answer 5

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

- Warren P

---

这是一个有趣的想法，生成DPROJ文件。您知道DPROJ生成代码本身是否作为JCL本身的一部分发布吗？ - LachlanG

Answer 6

Delphi XE4、5、6 和 XE7 的后续版本非常稳定，可以构建 .dproj XML 文件。我使用 git 版本控制 .dproj 和 .groupproj 文件没有任何问题。使用 IDE 编辑器更新这些文件会导致预期的整洁变化。

- Chau Chee Yang