我有我当前的Delphi 7项目（姓名的人士称，Project1.dpr），两个文件（Project1.dof和Project1.cfg），这我的团队，我不能决定版本控制下把（我们使用水银BTW）。
这件事是这样的：内的两个文件上面指示某些库，组件和扩展，它是关系到系统路径的程序员是。
我的团队是由使用32位Windows XP和一些球员一些球员的（包括我在内）使用的是64位的Windows 7。
因此，这带来了一个问题：因为在64位的Windows 7德尔福的扩展，组件和库都位于c:\program files (x86)\...和32位XP，他们只是在c:\program files\...，提交更改这些文件将导致破坏其他同事的项目配置。
是否有人有这样的情况有些建议吗？
如果你住在德尔福7，或者即使你不是，我建议你在.DOF文件检查，但也考虑不依靠他们为你的最终版本。更新：在OP决定不检查在.DOF文件，并使用最后的建设者。
这也是十分容易问你的64位人不检查其.DOF变化。即使他们有时会忘记，他们不应该犯的“本地破解”，这是很容易使一个小工具来读取和修复你的.DOF文件的本地个案。运行它每次从拉其他国家的人民库变化的时间。
第二个绝妙的主意是在.dofdefault要检查的文件，并让您BUILD.BAT文件复制project.dofdefault如果它不存在于project.def。问题解决了。
对于最终的版本，并保持你的“从打破了愚蠢的原因构建”，我建议你看一下最终生成器，你检查一下你的最终构建脚本到版本控制和客户建立已经通过最终生成器仅释放。你会不会担心发送您的客户奥秘这样构建，你无法解释。
例如如何你目前确切的水银变更版本（MD5十六进制值）与含有它和用来构建它的选项的代码相关联？
更聪明的办法是将下降德尔福7，也就是现在10岁以上，并考虑扎实迈向二十一世纪。
首先：我完全同意沃伦建议。
如果你仍然想留在你当前的系统，你可以使用$(ProgramFiles)作为图书馆pathes的前缀。这应该在两个操作系统的口味工作。
你可以使用某种像SUBST或硬链接路径重定向巩固安装不同。在此之后问题已经解决，我建议在自由度文件检查，并使用如。 Dof2cfg的命令行构建生成CFG文件。
我与沃伦的建议，同意升级到德尔福的新版本。有迹象表明，已添加在过去十年这么多真正有用的功能。你可能会认为你已经相处得很好，没有他们，但一旦你开始使用它们，你就会开始想知道为什么你等了这么久。
话虽这么说，如果你要升级，我建议复制第三方组件出程序文件，并到项目树的子文件夹的位置不是。我这样做有一个Delphi 6项目，并通过这样做，我发现不是每个人都使用的组件的版本相同。
是否包括版本控制下的.dof和.cfg的是一个主观判断。如果靠他们发布版本那么他们也许应该是版本控制之下。它们可以包含编译器设置和所必需的适当的编译条件语句。这也有利于所有的开发商都使用正确的设置时，他们在自己的机器上工作。
如果您的构建过程在命令行设置这些那么它不是什么大不了的事。
巧合的是，德尔福的更高版本通过与可以包含多个配置，单个文件替换两个解决这个问题。他们还推出了一款名为选项设置功能，可以使您所有的项目都使用相同的设置链接到多个项目。