我最近开始使用 Git。
我发现的有趣功能之一是使用哈希来快速检测更改。
另一方面，我看到构建工具（如 make、ant、javac 等）尝试通过检查文件的时间戳来检测源文件中的更改。
这种方法的问题是：
- 如果您从事不止一项工作
机器，你必须确保所有
时钟是同步的，否则，
可以考虑新文件
不变，因为另一台机器的时钟给了它相对于构建机器的过去的时间戳。
- 在大型项目中，您必须扫描所有文件的时间戳才能检测更改。
我想知道是否有人已经采用了 Git 方法来处理这些问题：
- 每个文件都有一个唯一的哈希值，具体取决于其内容，而不是时间戳。
- 每个目录也有其哈希值，具体取决于目录中的文件及其哈希值。
- 由于上述规则，即使是源代码树内部的简单更改也会导致根目录具有不同的哈希值
这种机制可以帮助使构建工具更快，因为检测源树中的更改是哈希比较的简单操作。如果源树根目录的哈希值发生了变化，则意味着源树中发生了更深层的变化，因此继续递归地扫描树以查找变化——就像 Git 检测变化一样。
这并不一定意味着这个源代码树必须由 Git 管理。
我的想法是，文件系统将自动提供文件的哈希码作为其属性/元数据之一，因此构建工具可以依赖于此而不是时间戳。此外，目录哈希会自动反映其中文件的状态。
我已经阅读了一些有关 Sun ZFS 的内容，但我不确定它是否是一个可以加快构建速度的完整解决方案。
你觉得这个想法怎么样？
已经有这样的文件系统了吗？
已经有这样的构建工具了吗？
我认为你试图解决的问题实际上不是问题：
使用 NTP 可以很大程度上避免时钟偏差问题。
当然，完全消除时钟偏差问题固然很好，但我们可能会同意，使用相当复杂的内容跟踪系统来解决该问题是矫枉过正的。
关于性能，扫描整个树在实践中往往不是问题。stat速度快得离谱（只要你不是使用 Windows）--ls -lR > /dev/null在我的系统上，遍历整个 Linux 内核树（38k 文件）需要 350 毫秒。
事实上，如果对所有文件进行统计是一个问题，那么您的版本控制系统将会变得很慢，这将是一个比构建性能更大的问题。每一个git status or git diff，例如，统计all工作副本中的文件来检查它们的修改时间，因此您最好希望速度很快。
所以如果你想加快速度make，不看文件系统；与实际消耗构建时间的任何事情相比，它很可能微不足道。
希望能让您放心！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
