Fed*_*can 5 delphi version-control delphi-7
我在我目前的Delphi 7项目(名为Project1.dpr)中有两个文件(Project1.dof和Project1.cfg),我和我的团队无法决定将其置于版本控制之下(我们使用Mercurial btw).
问题是:在上面的两个文件中指出了一些与程序员所在系统相关的库,组件和扩展路径.
我的团队由一些使用32位Windows XP的人和一些使用64位Windows 7的人(包括我)组成.
因此,这提出了一个问题:因为在64位Windows 7 Delphi扩展,组件和库位于c:\program files (x86)\...32位XP下c:\program files\...,它们就在它们之下,提交对这些文件的更改将导致打破其他同事的项目配置.
有人对这种情况有什么建议吗？
War*_* P 4
如果您继续使用 Delphi 7，或者即使您不是，我建议您签入 .DOF 文件，但您也考虑不要依赖它们进行最终构建。更新：OP决定不签入.DOF文件，并使用最终构建器。
要求 64 位用户不要检查他们的 .DOF 更改也很容易。即使他们有时忘记他们不应该进行“本地黑客”，也很容易制作一个小型实用程序来读取和修复本地案例的 .DOF 文件。每次从其他人的存储库中提取更改时都运行它。
第二个绝妙的想法是签入 .dofdefault 文件，并让 Build.Bat 文件将 project.dofdefault 复制到 project.def（如果它不存在）。问题解决了。
对于最终构建，并防止“构建因愚蠢的原因而中断”，我建议您查看 Final Builder，并将最终构建器脚本签入版本控制，并且仅发布给已通过 Final Builder 的客户构建。这样您就不必担心向客户发送您无法解释的神秘构建。
例如，您当前如何将精确的 Mercurial 变更集修订版（md5 十六进制值）与包含它的代码以及用于构建它的选项关联起来？
更明智的想法是放弃已有 10 多年历史的 Delphi 7，并考虑坚定地迈入 21 世纪。
| 归档时间： |
|
| 查看次数： |
2891 次 |
| 最近记录： |