There already exists tup: http://gittup.org/tup/ which does that sort of thing.
At least that's what I'd like to see - it's functionality that's orthogonal to those tools.
[1] https://developer.apple.com/library/mac/#documentation/Darwi...
Programs will still have to inspect those directories to find out what file(s) changed.
To quote https://developer.apple.com/library/mac/#documentation/Darwi...:
To better understand this technology, you should first understand what it is
not. It is not a mechanism for registering for fine-grained notification of
filesystem changes. It was not intended for virus checkers or other technologies
that need to immediately learn about changes to a file and preempt those changes
if needed. [...]
The file system events API is also not designed for finding out when a
particular file changes. For such purposes, the kqueues mechanism is more
appropriate.
The file system events API is designed for passively monitoring a large tree of
files for changes. The most obvious use for this technology is for backup
software. Indeed, the file system events API provides the foundation for Apple’s
backup technology.
IMO, only telling users what directories changed is a smart move. It means that the amount of data that must be kept around is much smaller. That allows the OS to keep this list around 'forever' (I do not know how 'forever' that actually is)This is a nice overview on FSevents
http://arstechnica.com/apple/reviews/2007/10/mac-os-x-10-5.a...