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

Question

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

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

这种方法存在的问题是:

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

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

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

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

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

我已经阅读了一些有关 Sun 的 ZFS 的内容，但我不确定它是否是一个可以加快构建速度的完整解决方案。

您如何看待这个想法？已经有这样的文件系统了吗？有没有这样的构建工具？

Answer 1

我会争辩说你试图解决的问题实际上不是问题:

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

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

关于性能，扫描整棵树在实践中往往不是问题。 stat 快得离谱(只要你不在 Windows 上)—— ls -lR >/dev/null 遍历整个 Linux 内核树(38k 文件)需要在我的系统上为 350 毫秒。

事实上，如果对所有文件进行 stat'ing 是一个问题，那么您的版本控制系统就会变慢，这将是一个比构建性能大得多的问题。每个 git status 或 git diff，例如，stats all 工作副本中的文件以检查它们的时间，所以你最好希望这是快。

因此，如果您希望加快 make 的速度，请不要查看文件系统；与实际占用构建时间的任何内容相比，它很可能微不足道。

希望这能让您放心!