Производительность VCS

Читая новости OpenNet, наткнулся на несколько ссылок: bzr, git, and hg performance on the Linux tree, git/bzr historical performance comparison, и несколько более косвенно Distributed Version Control Systems: A Not-So-Quick Guide Through. У меня так и не дошли руки до полноценного исследования производительности. В данных обзорах немного расстраивает лишь отсутствие monotone.

Смущает меня только один момент. По моим скромным подсчетам на построение списка файлов уходит сравнительно немного времени, для линукс ядра это порядка 1 секунды (сильно округляю).

Но чтобы оценить изменение рабочего каталога относительно HEAD репозитория, необходимо сравнить содержимое файлов, ну это в идеальном варианте, все остальные варианты оставляют шансы на ошибку. Причем нам главное знать факт изменения файла. Изменение длины явно говорит о том, что файл изменился, так же как и изменение хеша. Но с другой стороны изменение времени вообще ни о чем не говорит, а совпадение хеша вовсе не говорит о том, что файлы идентичны. Может быть именно последний момент подталкивает некоторые системы контроля оперировать не хешами а номерами?

Но раз уж системы оперируют хешами как версиями файлов, видимо приходится принять условие, что совпадение хеша подтверждает совпадение файла. Но проблема в том, что рассчет хеша всех файлов дерева linux занимает порядка минуты, ну если соптимизировать - ну 40 секунд к примеру. И становится непонятным, как git, bzr и hg умудряются показывать статус за считанные секунды (1-5 сек).

Вероятно, они всетаки доверяют времени, и файлы с неизменным временем автоматически считаются неизмененными. Вообще я не склонен доверять времени, время может съехать, ИМХО Makefile работают совсем не правильно. :) Ну это наверное мое извечное всеотрицание. А если рассуждать трезво, то меня вовсе не радует перспектива ждать по 40 секунд для просмотра статуса изменений. Поэтому использование таймстампов файлов - это меньшее из зол.

Еще меня конечно сильно смущает возможность коллизий хеша. Насколько она велика, в лоб эту проблему конечно не решить, но не может ли появиться в системе контроля два разных файла с одинковым хешем? Это ведь может нарушить всю структуру репозитория...