On the drive home from LCA yesterday evening, Benno, Eman, and myself
brainstormed the idea of using FAM to track changes to a working copy,
in order to speed up the detection of changed files for
SCons and
baz. The theory goes like this:
stat()ing every file in a directory tree to see if the file has
changed sucks for large trees, and sucks on NFS, so let’s use a
different method for finding out changed files.
Incidentally, SCons actually detects if the file contents have
changed, which I can only assume requires more work than the
stat(). baz must do the same to work out its changesets; but
probably only diffs on the set of files that are known to have
changed (I hope!).
So lets assume that FAM can be asked to monitor a directory tree, and
then queried for information about file modification times relative to
some time of interest. Then the algorithm is pretty simple:
If we have no last-build timestamp:
Ask FAM to monitor the directory tree
Do a regular stat
Otherwise:
Query FAM for all the changes since the last-build time
If FAM has no results:
Ask FAM to monitor the directory tree
Do a regular stat
Otherwise:
Do the build with the results of the FAM query
record the timestamp at the end of the build
The local timestamp could be recorded in much the same way as SCons
already uses its .sconsign to record hashes of the file contents and
build commandlines; baz could record it in {arch} somewhere.
Update: Benno reports that FAM will only work for a long running
process that keeps a connection open to FAM, so SCons and baz, being
relatively short-lived, can’t take advantage of this scheme. That’s crap.