我在一篇关于版本洞察（http://www.delphifeeds.com/go/s/77066）的博客中读到了（其中包括）JCL没有版本控制下的.dproj文件，我想知道它的优点是什么。
特别是因为我和我的同事开发人员经常使用我们自己喜欢的调试设置检查项目文件而互相“错误”（他喜欢优化，我希望它关闭）。而且由于Delphi 2007的常规问题，dproj文件被各种错误的依赖项搞砸了。对这些事情，版本控制无论如何都没有帮助吗？
我们目前正在使用Starteam作为我们的VCS。
答案 0 :(得分：7)
如果您使用Delphi 2009或更高版本Option Sets是解决此问题的完美解决方案。
选项集基本上是设置的集合，通常驻留在DPROJ（你做的版本）中，而是存储在.OPTSET文件中（你没有版本）。
让您的DPROJ包含所有开发人员共有的设置，除非经过全面同意，否则不允许任何人进行更改。
接下来在项目管理器（D2009及更高版本）中首先是DEBUG配置节点，然后是RELEASE配置节点，右键单击并选择“新选项集”。调用此选项设置类似“Local Developer Debug Settings.optset”和“Local Developer Release Settings.optset”。
现在只将您的DPROJ提交到版本控制，因为它现在引用这些.OPTSET文件。因此，您必须在每台计算机上将选项集命名为完全相同。
如果要对项目配置进行本地更改而不是编辑项目配置，请右键单击项目管理器中的选项集，然后选择“编辑选项集”。
IDE将应用选项集中更改的设置，而不修改原始DPROJ。分层应用设置，选项集是最后应用的选项。
答案 1 :(得分：4)
我在.dproj文件中存储msbuild用于构建过程的设置。例如，条件定义，编译器设置等。如果你这样做，那么你需要对它们进行版本化。
如果您使用的是IDE定期打破.dproj文件的Delphi版本，那么版本控制肯定会帮助您反击。
我没有看到没有对它们进行版本控制的任何优势。
答案 2 :(得分：2)
如果您选择不对DPROJ进行版本化，那么在创建发布版本时，我建议您使用某种类型的单独构建脚本，例如。
答案 3 :(得分：1)
这个问题的一个解决方案是更清楚地了解允许签入的DPROJ（以及DFM文件）的哪些部分。
你没有提到你正在使用的版本控制系统，但是TortoiseHg在它的提交过程中有一个大块选择功能，它允许你选择要提交的已更改文件中的各个行，并且仍然保留其他行。< / p>
我使用此方法永远不会检查来自DPROJ的垃圾更改（例如将活动配置从RELEASE更改为DEBUG）和DFM（例如更改为ExplicitHeight和ExplicitWidth属性）。
答案 4 :(得分：1)
我能想到的不是版本控制DPROJ文件的唯一原因是，像JCL一样，你可以在构建过程中重新生成它们。 JCL是一个类库（代码库）而不是一个应用程序，它针对Delphi的多个版本，它们的.dproj文件有所不同。事实上，2005年之前的delphi版本根本没有使用.dproj文件。
答案 5 :(得分：0)
更高版本的Delphi XE4,5,6和XE7非常稳定，可构建.dproj XML文件。我没有抱怨使用git版本.dproj和.groupproj文件。使用IDE编辑器对这些文件进行更新只会产生预期的干净整洁。