呼吁洞察:修订控制和二进制文件

Nyl*_*lon 8 git version-control mercurial

人类编写源代码

版本控制用于记录源代码中的更改

工具处理源代码并生成机器可读的东西(exec,libs,GUI代码等)

每隔一段时间我就想保存工具输出的副本(例如保存ARM的beta版本的可执行文件).我可以手动保存工具的输出,给它一个反映修订控制历史记录中的点的名称(例如使用标签名称).这似乎很尴尬,容易出错.

我想深入了解两件事:

  1. 使用修订控制在修订历史记录图表中的特定位置存储工具生成的输出的优缺点是什么?您使用哪些非RCS工具作为替代方案?

  2. 在mercurial,git中,什么是在特定修订中包含工具生成的输出而不是其他修改的最佳方法

Wim*_*nen 8

我相信二进制文件不应与其源代码一起存储在版本控制中.

缺点:

  • 它鼓励大型项目中的错误构建实践.最佳实践是完全自动化完整构建(不仅包括源代码编译,还包括运行自动化测试,文档打包,生成设置等).提交二进制文件使您可以忽略:"只需手动为已更改的部分进行构建".
  • 较慢的更新和提交
  • 每次在构建之后更新时都需要处理二进制文件的冲突
  • 更改源代码而不是相应二进制文件的提交将导致开发人员之间的混淆.你如何发现存在不匹配?
  • svn update 将更新二进制文件的时间戳,混淆您的构建工具,这会错误地认为二进制文件比源代码更改更新.
  • 它在存储库中使用更多磁盘空间.(根据您的项目,这可能会微不足道.)

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

相反,使用持续集成服务器在每次提交时自动重建(并运行测试).如果需要,让这个构建服务器在某个地方(SVN外部)发布二进制文件,就像网络上的共享文件夹一样.