是否有努力开发具有文件自动更改检测功能的面向构建的文件系统？

Question

我最近开始使用Git。 我发现的一个有趣的功能是使用哈希来快速检测变化。

另一方面，我看到构建工具（如make，ant，javac等）尝试通过检查文件的时间戳来检测源文件中的更改。

这种方法存在的问题是：

1. 如果您不止一个人工作 机器，你必须确保所有 时钟是同步的，否则，a 可以考虑新文件 没有改变，因为其他机器的时钟给了它相对于构建机器的过去的时间戳。
2. 在一个大项目中，您必须扫描所有文件的时间戳以检测更改。

我想知道是否有人已采用Git方法来处理这些问题：

1. 每个文件都有一个唯一的哈希值，具体取决于其内容，而不是时间戳。
2. 每个目录也有其哈希值，具体取决于目录中的文件及其哈希值。
3. 即使是源代码树内部的简单更改，也会导致根目录由于上述规则而具有不同的哈希值

这种机制可以帮助使构建工具更快，因为检测源树中的更改是一种简单的哈希比较操作。如果源树根目录的哈希值发生了变化，则意味着源树中发生了更深层次的更改，因此继续以递归方式扫描树以查找更改 - 正如Git检测更改一样。

这并不一定意味着这个源代码树必须由Git管理。 我的想法是文件系统会自动提供文件的哈希代码作为其属性/元数据之一，因此构建工具可以依赖于此而不是时间戳。此外，目录哈希会自动反映其中的文件状态。

我已经阅读了一些关于Sun的ZFS的内容，但我不确定这是一个让构建更快的完整解决方案。

您如何看待这个想法？ 有没有这样的文件系统？ 是否有这样的构建工具？

Answer 1

我认为你想要解决的问题实际上是一个非问题：

使用NTP可以避免时钟偏差问题。

当然，完全消除时钟偏差问题会很好，但我们可能会同意在这个问题上投入一个相当复杂的内容跟踪系统是过度的。

关于性能，扫描整个树在实践中往往不是问题。 stat速度非常快（只要你不在Windows上） - ls -lR > /dev/null整个Linux内核树（38k文件）在我的系统上需要350毫秒。

事实上，如果对所有文件进行统计是一个问题，那么您的版本控制系统将变得缓慢，这将是一个比您的构建性能更大的问题。例如，每个git status或git diff工作副本中的统计信息所有文件都会检查他们的时间，因此您最好希望速度很快。

因此，如果您希望加快make，请不要查看文件系统;与实际占用你的构建时间的东西相比，它很可能是微不足道的。

希望能让你放松心情！