Прилагаются ли усилия для разработки ориентированной на сборку файловой системы с автоматическим обнаружением изменений файлов?

Question

Я недавно начал использовать Git.Одной из интересных особенностей, которые я обнаружил, было использование хэшей для быстрого обнаружения изменений.

С другой стороны, я вижу, что инструменты сборки (такие как make, ant, javac и т. Д.) Пытаются обнаруживать изменения в исходном коде.файлы, проверяя временную метку файла.

Проблемы в этом подходе:

1. Если вы работаете более чем на одном компьютере, вы должны убедиться, что все часы синхронизированы, в противном случае,новый файл может считаться неизменным, потому что часы другой машины дали ему метку времени прошлого относительно машины сборки.
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, например, статистика всех файлов в вашей рабочей копии, чтобы проверить их mtimes, так что вам лучше надеяться, что это быстро.

Так что если выищите ускорение make, не смотрите на файловую систему;это, скорее всего, незначительно по сравнению с тем, что на самом деле съедает ваше время сборки.

Надежда, которая облегчает ваш разум!