呼吁洞察：修订控制和二进制文件答案

【问题标题】：call for insight: revision control and binaries呼吁洞察：修订控制和二进制文件
【发布时间】：2011-05-13 07:53:35
【问题描述】：

人类编写源代码

修订控制用于记录源代码的变化

工具处理源代码并生成机器可读的东西（exec、libs、GUI 代码等）

每隔一段时间我想保存一份 tools' 输出的副本（例如，保存 ARM 的 beta-release 的可执行文件）。我可以手动保存 tools' 输出，为其命名，以反映修订控制历史中的点（例如，使用标签名称）。这看起来很尴尬且容易出错。

我希望您能深入了解两件事：

【问题讨论】：

【解决方案1】：

我认为二进制文件不应与其源代码一起存储在版本控制中。

缺点：

它鼓励大型项目中的不良构建实践。最佳实践是完全自动化您的完整构建（不仅是源代码编译，还包括运行自动化测试、文档打包、设置生成等）。提交二进制文件可以让您忽略这一点：“只需手动构建已更改的部分”。
更新和提交速度较慢
在构建后每次更新时都需要处理二进制文件的冲突
更改源代码但未更改相应二进制文件的提交会引起开发人员的混淆。您如何检测到不匹配？
svn update 将更新您的二进制文件的时间戳，从而混淆您的构建工具，从而错误地认为二进制文件比您的源代码更改更新。
它使用存储库中的更多磁盘空间。（根据您的项目，这可能可以忽略不计。）

一般来说，我认为您应该避免提交从其他版本化资源以确定性方式自动生成的任何内容。没有冗余 -> 没有出现不一致的机会。

相反，使用持续集成服务器在每次提交时自动重建（并运行测试）。如有必要，让此构建服务器在某处（SVN 之外）发布二进制文件，例如网络上的共享文件夹。

【讨论】：

【解决方案2】：

我建议不要将二进制文件与 DVCS 混合使用（例如 git 和 Mercurial）。主要原因是：任何不可合并的文件都是 DVCS 的问题。 DVCS 基本上依赖于高质量的文件合并，DVCS 的概念才能发挥作用（请参阅this discussion on binary files in git）。

我同意二进制文件值得存储。但它们可能应该存储在与您的源版本控制系统不同的位置。也许是具有受控写访问权限的服务器。如果您想保留所有历史记录，可能需要一个单独的集中式 VCS 存储库，例如 Subversion。

如您所说，为避免这种分离“尴尬且容易出错”，请尽量使其自动化。制定一个自动化的构建过程，确保源是版本化/标记的，进行完整的构建，并将输出（正确命名、版本化、标记等）放入指定的存储中。

【讨论】：